4 ms·

I've liked the idea of Open Location Code for some time, so when I read the following, I thought "Surely that's not right?" > Implicit, however, is that the on

I've liked the idea of Open Location Code for some time, so when I read the following, I thought "Surely that's not right?" > Implicit, however, is that the only way to resolve that shortened code is to make a call to the Google Maps API. I'd always thought OLC could encode/decode coordinates with a simple algorithm, with more or less precision based on the length of the code. Referring to their documentation, I found this [0]: > Supporting local codes.. If you have no map and cannot determine the device location, a local code is not sufficient and you should display a message back to the user asking them to provide a town or city name or the full global code. > ..extract the local code and send the remaining text to your geocoding service (Nominatim, Google, etc). What! I didn't know this about shortened codes - that need for an external service to decode plus codes diminishes my enthusiasm for the standard considerably. Thank you for the write up, will be keeping my ears open for GeohashPhrase. --- [0] https://github.com/google/open-location-code/wiki/Supporting-plus-codes-in-your-app https://github.com/google/open-location-code/wiki/Supporting...

pgeorgi 7y ago
> that need for an external service to decode plus codes diminishes my enthusiasm for the standard considerably The short code is "some place plus an override for the lower bits". You could just ship a list of common places to do that rough orientation, but the problem with the short codes is that every place is eligible as a base point, with lots of redundancy: - 65P4+PX Hünstetten, Germany - 65P4+PX Wallbach, Germany - 65P4+PX Hohenstein, Deutschland - 65P4+PX Wiesbaden, Deutschland - 65P4+PX Limburg, Deutschland - 65P4+PX Bad Ems, Allemagne all point to the same place, but for that you need to know that these towns and cities are roughly in the same place (and that Germany, Deutschland and Allemagne are the same). Meanwhile - 65P4+PX Koblenz, Deutschland is a different place, even though Koblenz is also nearby (but in the next quadrant, so the offset override points elsewhere) and - 65P4+PX Limburg, Belgien uses the same town name in a different country, therefore pointing elsewhere, too. I guess it would be an interesting challenge to try to build the smallest representation of country and town names in Nominatim to denote OLS quadrants for offline storage that still allows quick lookups (that is, no compression that takes several hours and gigabytes to seek through).

pgeorgi 7y ago

> that need for an external service to decode plus codes diminishes my enthusiasm for the standard considerably The short code is "some place plus an override for the lower bits". You could just ship a list of common places to do that rough orientation, but the problem with the short codes is that every place is eligible as a base point, with lots of redundancy: - 65P4+PX Hünstetten, Germany - 65P4+PX Wallbach, Germany - 65P4+PX Hohenstein, Deutschland - 65P4+PX Wiesbaden, Deutschland - 65P4+PX Limburg, Deutschland - 65P4+PX Bad Ems, Allemagne all point to the same place, but for that you need to know that these towns and cities are roughly in the same place (and that Germany, Deutschland and Allemagne are the same). Meanwhile - 65P4+PX Koblenz, Deutschland is a different place, even though Koblenz is also nearby (but in the next quadrant, so the offset override points elsewhere) and - 65P4+PX Limburg, Belgien uses the same town name in a different country, therefore pointing elsewhere, too. I guess it would be an interesting challenge to try to build the smallest representation of country and town names in Nominatim to denote OLS quadrants for offline storage that still allows quick lookups (that is, no compression that takes several hours and gigabytes to seek through).