If they’re going to be dicks about keeping it proprietary then maybe it’s time for someone to come up with an open alternative.
There's https://en.wikipedia.org/wiki/Open_Location_Code from Google (AKA Plus Codes). They have a useful wiki article which compares existing systems: https://github.com/google/open-location-code/wiki/Evaluation...
I like it because if you have the coordinates of a landmark, you can easily estimate the coordinates of other nearby locations entirely in your head, and the system encodes precision so you can indicate uncertainty.
https://en.wikipedia.org/wiki/Military_Grid_Reference_System
Who knows how far away epic.region.music and epic.global.music are from just the names? While 18SUJ2163104440 and 12SVC0452723150 are 6 grid zones apart east to west.
It's actually quite pleasant to use and allows you to just truncate to the level of precision you want. S/He just posted the 1m resolution string when 18-SU-J-216-044 would get you to 100m.
All this said, I think the real issue is that we refuse to PICK a standard and so every device with a GPS and ever map has one or two of
-MGRS
-UTM (almost identical to MGRS)
-LL DD MM' SS.ss"
-LL DD.dddd...
-LL DD MM.mmmm...'
etc.
If you make a device that can output or accept a location string, make sure it can handle all LL cases and UTM/MGRS.
The top-level zones are its weakness. The further apart two coordinates are from each other, the more difficult it is to reason about their relationship. MGRS works fantastic for reasoning about coordinates on the same grid square, but gets harder as you move up to comparing between grid squares and harder still as you compare between zones.
A grid square is 100km x 100km, so it's pretty big, and coordinates in the square are easy to manipulate. If you know your office is at 4QFJ 21631 04440 and the Starbucks is about 500 meters down the road to the north, then you know Starbucks' coordinates are roughly 4QFJ 21631 04940. To indicate your uncertainty, you'd say 4QFJ 216 049, or possibly just 216 049 if the grid square was already known from context.
The system is typically extended to allow that reasoning to work even at the edges of a grid square, by allowing eastings and northings that extend past the grid square edge. This means there's more than one possible way to describe a location, though only one canonical way. Unless you're already familiar with the area, you may need a map to compare coordinates on different squares.
Some of the grid zones are also a little oddly shaped. It's mostly not a big deal because they're huge, and it really only affects which coordinate representation is the canonical one at the boundaries, but it would be nice if the top-level 6° by 8° grid zones were more regular.
What3words will be a nightmare over a weak voice radio signal, if amateur radio experiences are anything to go by
Can you comment more about "weak radio signal"? Perhaps one can deduce the a number by hearing a small sample of a sound...whereas W3W has a wider vocabulary? My guess is that if necessary, one could repeat each word several times (e.g. over a period of 10 seconds).
https://en.wikipedia.org/wiki/Maidenhead_Locator_System
What I would suggest to W3W or WFW is to have a alphanumeric "backup" similar to the gridsquare system that can be spoken over rough radio channels.
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.
> 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...
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).
That's entirely against their business model. See also the open street map wiki page on it: https://wiki.openstreetmap.org/wiki/What3words
Or any of the previous HN discussions (just some samples):
https://news.ycombinator.com/item?id=8614198
https://news.ycombinator.com/item?id=15579017
The point is to get adoption and network effect, locking users (e.g. Mongolian mail service) into a monopoly that they can eventually leverage. Since no one but them can (or rather is allowed) to do the conversion, they request payment per lookup/coordinate conversion.
There is nothing novel or innovative about their algorithm, it's downright awful in some regards, and there is little benefit to actually derive from the system in the first place (compared to established open systems). They're just really good at PR (and takedown notices) - that's their real business plan.
Their business model is more or less undercut by opensource and reverse engineered alternatives, hence the predatory DMCA takedowns. This is obviously a bad PR move. It's the 21st century; the product/IP itself provides little to no value to the average user. It's the services that does. Open source the product and make money licensing, installing, training, and integrating it into everyday life.
[0]https://www.mercedes-benz.com/en/innovation/what3words-voice...
[1] https://northyorkshire.police.uk/news/whats-what3words-and-w...
Most recently for 2018: 11.4 million GBP loss on 273k GBP of income.
But there is a great free alternative already, I use it all the time: http://www.what3fucks.com
Where in relation to curve.empty.buzz is grape.trunk.gossip? Is it closer/farther than slurs.this.shark?
The first is about 6 feet north. The second is 3600 miles east.
It's an almost intentionally terrible system designed for people to be reliant on their services.