Clarify restrictions for short codes

[bocops]

Clarify restrictions for short codes

[bilst]

That sounds good, thanks!

FWIW I think while dataset interoperability and offline are challenges, they're also present for numbered street addresses, which still manage to function well between mapping systems (and the real world). So it would be good not to emphasize that too much (which could also be discouraging for someone considering adoption of OLCs as an addressing system).

Re publishing an open dataset, too much of Google's data comes with licensing restrictions that preclude sharing freely, so that's a nonstarter (still plenty of other organizational and technical hurdles downstream though...).

I think Nominatim is a great option for someone looking for reasonable whole-world coverage. There's even an implementation of OLC geocoding/revgeo that uses Nominatim: https://gitlab.liu.se/davby02/olc

And many users of OLCs have requirements scaled to a particular region they support (e.g. if they're addressing with county names in a particular country, they only need a geocoder that handles those, which is pretty easy to put together from their own data or OSM).

Would be good to mention these viable alternatives.

[bocops]

That seems reasonable. I've now checked the available documentation, and found that the following files do not need to be changed. They either don't talk about short codes at all, or just in technical contexts where the reference location exists as a lat/lng pair:

• docs/comparison.adoc
• docs/olc_definition.adoc
• docs/specification.md
• API.txt

This leaves the following to be updated, for which I will create a PR:

• FAQ.txt
• README.md

In addition to that, I suggest that the Wiki is changed as follows, so that we end up with a URL for the "global lookup table" request that we can paste into new issues asking for that:

• add questions/answers added to FAQ.txt to FAQ as well

This needs to be done by the repository owner.

[bilst]

(Updated the FAQ)

[shutyourbeak]

That sounds good, thanks!

FWIW I think while dataset interoperability and offline are challenges, they're also present for numbered street addresses, which still manage to function well between mapping systems (and the real world). So it would be good not to emphasize that too much (which could also be discouraging for someone considering adoption of OLCs as an addressing system).

Re publishing an open dataset, too much of Google's data comes with licensing restrictions that preclude sharing freely, so that's a nonstarter (still plenty of other organizational and technical hurdles downstream though...).

I think Nominatim is a great option for someone looking for reasonable whole-world coverage. There's even an implementation of OLC geocoding/revgeo that uses Nominatim: https://gitlab.liu.se/davby02/olc

And many users of OLCs have requirements scaled to a particular region they support (e.g. if they're addressing with county names in a particular country, they only need a geocoder that handles those, which is pretty easy to put together from their own data or OSM).

Would be good to mention these viable alternatives.

A useful IRL application of OLCs that I've found in my line of work has been to use a 12-digit OLC as a distinct ID within a UK-based real estate database. Conventional addressing products like the Royal Mail PAF & OS Addressbase systems carry their own IDs which have widespread market adoption (UDPRNs & UPRNs) however both such systems are heavily dependent on the address-string and cannot capture 'future things'.

Real Estate businesses engaged in consultancy & transactional work often capture significant ammounts of data on a 'future development' i.e. the 100 houses that might get built on Field X in 5-10 years time, once someone has got planning permission, development finance, starting construction etc... Tying our information on 'future things' to conventional sddress systems is very inefficient & innaccurate; not least because in 99% of cases the address or 'name' will change multiple times over the lifespan of that development sites' evolution. This approach also asks colleagues to force the selection of one address as the 'master' when in reality a development opportunity/site spans multiple current addresses (all of which will then fall away & be supplanted as the development evolves).

In fact the only certain constant in these situations is the location - either defined as an input point (which if it is an existing address or feature, can be supplied by a 3rd party addressing system and refined by users as required) or as a calculated centroid of a site outline/polygon when we are dealing with Field X or Title Number Y.

In this way we have created a globally standardised set of "placeids" that act as unique serials in our database - with the added advantage that the serial itself contains spatial information. Proximate placeids can be easily identified based on truncating the serial by X characters.

To handle vertical stacking of places or co-location, we simply add an incrementing set of additional numeric characters to our OLC placeid