I think that OLC and W3W have many flaws. If you want to read a critique OLC I suggest you read this: https://www.qalocate.com/whats-wrong-with-open-location-code...
At QA Locate we've been working on a similar solution that we call GeohashPhrase. Rather than encoding a location as 3 random words, or the alphanumeric code of OLC, we instead just encode a geohash as a sentence.
Encoding/decoding is relatively trivial, and can be done offline, but I've yet to write up docs I'm comfortable with other people reading.
There are some light docs you can reference here: https://www.qalocate.com/resources/
We have a video on the tech here: https://www.youtube.com/watch?v=nlscJ8MOPjM
I'm working on some better preliminary docs, but working code takes priority ;-)
Btw, the GeohashPhrase will be open source and free to use.
> Implicit, however, is that the only way to resolve that shortened code is to make a call to the Google Maps API.
Why? If OSM supports plus codes, that'll work equally well, no?
> By allowing reference locations in plus codes these codes are tied to specific political entities
Okay, but, as I understand it, you just need to point to something in the general vicinity, close enough that it can disambiguate Athens, Greece from Washington DC. Unless the city moves half a country away, the code will still work.
> If so, what I really need to know is the correct parking, or rideshare drop off, and the closest entrance, not directions to center court, which is apparently where “Q5RQ+6V Dallas, Texas” actually is!
Are you really complaining that the coordinate you set wasn't the coordinate you wanted to set? Or that Google Maps (not OLC) isn't smart enough to route you to a stadium properly?
The rest of the article is similarly seemingly looking to pick a fight with tenuous assertions, I'm afraid.
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 :
> 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.
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).
- 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)
- 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).