I Want to Like Open Location Codes (Plus Codes) But I Can't
2023-10-24 -  8:8
So sometime in the last day, a friend of mine sent me a Google Maps link to a location in a city decently near me. I saw a strange code that was made of some letters and numbers and a plus in the middle, along with the city name. After clicking on the info icon to the right of that number, I learned about something called "Plus Codes". It turns out some folks at Google created an encoding method for Latitude and Longitude coordinates.
I fell into a bit of a rabbit hole today working on potentially implementing it in my program Syzygy, but as you might be able to tell by the title of this journal post, I decided against implementing it. Hopefully I can properly explain my thought process as to why.
Why I initially liked Open Location Codes
The fact that codes can be encoded and decoded offline is quite appealing to me. The algorithm also uses a license I'm not frustrated by, the Apache License 2.0. There's a slight difference from GPS coordinates as well that appeals to me, which is that plus codes define essentially a "rectangle" rather than a single point. This has a nice benefit of specifying where someone or something is within a chunk of space rather than a specific point.
A few useful features of this would be:
- Telling a friend where you are at a large park
- Telling a friend where you are when in order to get picked up from a drop-off point at a transit stop
- Telling a friend which specific enterance of a building you are at that has a lot of enterances
Of course, this requires the people involved to have very accurate GPS coordinates.
Why I can't like this project...
It would be generally rude of me to dislike this simply because this is a Google project, but it being a Google project initially made me feel like something sinister must be going on... Google did make and push AMP after all, and that was an open source project...
Turns out one of the big features of plus codes is that you can remove the first few digits of the code and add a city name after the code. This by itself is not a bad thing in my opinion. There's not much of a reason why you need to give the first 4-6 digits if all parties involved know the general area the code is from. Think of this kind of like if the first 4-6 digits are a kind of ZIP or Postal code and the remaining digits are the block and house number. So far so good. Not too sketchy yet.
The issue happens when you look up an address on Google Maps. Instead of giving you the full 10-11 digit plus code, you get the shortened plus code with the city name after it. If a user copies a plus code from Google Maps, they're only going to be copying the shortened one that doesn't include all of the required information.
For example, the searching for the Eiffel Tower on Google Maps returns the plus code "V75V+8Q Paris, France" as opposed to the full code of "8FW4V75V+8Q". The missing "8FW4" part of the plus code specifies the 1 degree by 1 degree (a square degree) "rectangle" with the bottom left corner at 48 degrees North and 2 degrees East. This means that if you do not know where Paris, France is in terms of Latitude and Longitute, you might not be able to figure out which of the 64800 square degree "rectangles" "V75V+8Q" belongs to.
Why is this an issue?
With the full 10-11 digit plus code, competing map programs can easily implement Open Location Codes without needing to do a Latitude/Longitude lookup for a particular city. This adds complexity which will make those competing maps programs not bother to implement these codes, thus pushing traffic to Google Maps. If plus codes somehow become heavily adopted, especially as a sort of home address system for folks without home addresses, people will be pushed to use Google Maps if only the shortened codes are given.
Embrace, Extend, and Extinguish
Google Maps has released multiple videos on Youtube discussing how entire postal services and home address systems can be built using plus codes. One of those videos talks about using these codes to make it easier for some people to be able to register to vote. These are incredibly important things, but Google Maps does not seem interested in implementing the full Open Location Code spec and instead only seems interested in the shorter codes. This certainly feels to me like Google is trying to push entire community functions to rely on Google Maps. There are at least (emphasis on at least) 64800 different short code "rectangles" that Google Maps likely won't be freely sharing with others. It is my honest belief that Google decided to turn an open specification into a proprietary one by replacing 4 digits of an open code with a secret list of cities or areas that can arbitrarily change at any time.
The full Open Location Codes of a competitor will work on Google Maps, but the short plus codes that Google Maps produce might not work on the competitor's platform. Without attempting to go too political here, a strange and frustration additional issue is that the city/location names will rely on what Google Maps decides is correct, which will likely cause issues in contested areas, areas that change city limits, or areas that change countries over time. Although not the exact issue, Tom Scott talked a little bit about how complicated things get when dealing with locations and arbitrary lines in the video I linked below.
On the surface, this open algorithm sounds very good. I really want to like it. In its full 10-11 digit form, I think it could be useful, but because Google Maps only provides the shortened codes for copying when you look up an address, I cannot like this project... This project would be in my good favors if and only if Google Maps only provides the full plus code of locations for copying.