search

google / open-location-code

Open Location Code is a library to generate short codes, called "plus codes", that can be used as digital addresses where street addresses don't exist.
https://plus.codes
Apache License 2.0
4.05k stars 467 forks source link

Clarify restrictions for short codes #500

Closed bocops closed 1 year ago

bocops commented 1 year ago

We seem to have the same or similar discussion about the availability of reference locations repeatedly. For example, the following three issues are currently open (and could be closed if this goes through):

I assume there might be additional closed issues along those lines, and we've had similar discussions on the mailing list. The underlying problem seems to be that the following caveats for short code generation and usage are either glossed over or not spelled out at all in the various parts of our documentation:

Please comment if changes along those lines would not be welcome and merged if provided via PR. Unless that is the case, I will try to suggest doc changes along those lines in the coming days.

bilst commented 1 year ago

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 commented 1 year ago

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:

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

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:

This needs to be done by the repository owner.

bilst commented 1 year ago

(Updated the FAQ)

shutyourbeak commented 1 year ago

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