The Google Open Location Code (OLC) (aka plus code) is DOA despite Google pushing it hard. It is flawed where it tries to innovate and irrelevant where it doesn’t. Let’s explore why…
Open Location Code
To help us understand what is wrong with OLC we need to first understand what OLC is. A plus code, which is what an encoded location is called within the system, is a type of geocode that derives from a fixed grid of latitudes and longitudes the label of some cell within this grid. These grid cells nest, so by appending labels together one can identify a sub-division of some cell to an arbitrary degree. Wikipedia contains a more thorough description, but the most important take away is that a plus code is an area on a fixed grid, not an arbitrary coordinate.
Entirely Google Dependent
OLC points out several times that it is free and open. To the extent, it is an encoding standard that is true. It is also entirely irrelevant. OLC is in practice useless without Google, while at the same time being nearly useless even with Google.
Let’s take as a typical example American Airlines Center in Dallas, Texas. The plus code that Google displays (as of September 24, 2019) is Q5RQ+6V Dallas, Texas.
While Google could choose to display the full code (8645Q5RQ+6V), they have instead chosen to display a “shortened” relative code (Q5RQ+6V Dallas, Texas).
| Code Type | Example |
|---|---|
| Full | 8645Q5RQ+6V |
| Relative | Q5RQ+6V Dallas, Texas |
But even for consumers, there is still an impact — it means you potentially have to have internet access to make sense of a plus code. Good luck using a plus code to help mark your backwoods hiking route!
Naive
Simplicity is usually a good thing. OLC overdoes it.
Quite simply, what happens if the fine folks of some city don’t like where you’ve placed it? Are they allowed a say in determining where their city is?
What happens as a city expands? Does the reference location – i.e. the Dallas, Texas part of the code – change? Dallas has expanded significantly in the last 50 years. Should that change what should be as fixed and immutable as a coordinate?
There is yet a deeper issue. By allowing reference locations in plus codes these codes are tied to specific political entities. Yet cities, and states, may be absorbed or renamed, which means these codes may cease to have meaning. Or have meanings with, potentially drastic, political consequences.
Awkward
There are issues too about the ergonomics of plus codes. What happens if a friend shares Q5RQ+6V Dallas, Texas as the place to meet them? Naively, I assumed that Google Maps would reverse geocode and point me to American Airlines Center after all that’s presumably where I’m going. 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!
Addresses are not Locations
Probably the most misleading aspect of OLC is the one they’ve chosen to market themselves with. “Addresses for Everyone” is the tagline they show when you load the project’s home page. Nothing could be more confused.
OLC leaps to the most naive solution and just reduces an address down to a single area. With even a moments thought this laughable in its absurdity. American Airlines Center is enormous and has multiple entrances and exits spread around the building. Surely there should be multiple associated plus codes? Even my house has a front door and a back gate. Who or what decides what my canonical “plus code address” is? Who or what can change it and when? And let’s not even think about how insufficient this is for multi-story apartment buildings.
That aside, let’s think a bit more deeply about what addresses are.
Street addresses are neither geo-coordinates nor geographic areas. Certainly there is an element of “location” to an address, but that notion is not fixed — it varies with:
- time: like it or not addresses change
- delivery context: the postman, the taxman, and the garbageman all relate to an address differently and have different requirements
- receiver context: the subtle difference in addressing a letter to an occupant vs a named individual matters a great deal
You see, street addresses are old tech and date back at least 500 years. A street address is a kind of short-hand for giving a person a set of rough directions to some destination, with those directions tailored for that person, what they are delivering or doing, and with any ambiguities resolved by them. A great source detailing just how complex addresses can be is here.
Thinking of addresses as coordinates confuses location with destination with recipient, and ignores delivery entirely. When I send a letter I’m sending to a person who happens to be someplace — not the mailbox at that place. If the recipient isn’t there I expect the letter to either be forwarded or returned. My intent is implicit even though I have provided an explicit address.
Other times I really do want to send to a mailbox and not a named person. If I’m mailing everyone on my block, say to organize a block party, I’m in fact intending to reach the occupants of the houses on my block through the proxy that is their mailbox. Much junk mail has a similar intent.
Thinking of addresses as coordinates fails to distinguish these two perspectives, both of which are valid.
On the delivery side, imagine handing that single coordinate you have, say again for American Airlines Center, to a plumber, a security guard, an attendee, a player, and a delivery driver. Each person brings a unique context and requires a different set of directions. A coordinate for center court is less than helpful to any of them – even the player needs to get to the locker room first!
Last, addresses, especially street addresses, usually fail to capture any temporal element. Yet addresses are usually only valid for a relatively short period of time. Personally, I’ve had more than 10 separate addresses in the last twenty years, with three being just for the house I grew up in! Every time I move I’m now required to find a plus code to use (of the thousands possible), hoping it’s correct, and then updating everything and every one of this code? How is this simpler than just defaulting to using postal addresses? I see no benefit and only a multitude of ways it can fail.
Integration Nightmare
So far we’ve focused on how OLC fails the average person. But what about GIS professionals? Maybe plus codes solve a critical problem in that space? Yeah right.
Like it or not the one technology that isn’t going away is Latitude/Longitude. Which means that OLC had better play nice with good ol’ lat/lon, or else get real cozy with sextants and sundials.
At first glance, it would appear as if the integration story between OLC and lat/lon is on solid ground. After all, the boundaries of a plus code area are literally defined using lat/lon — how much more central could lat/lon be to OLC? But that actually misses the point. The real divide is semantic: lat/lon are coordinates, plus codes are areas.
What does it mean to convert a plus code to a coordinate? Does the coordinate come with an error term? Do you get the center of the area or a corner? Given that the OLC grid is fixed and technically has infinite precision, should the output coordinate have infinite precision as well? If not why not?
What does it mean to convert a coordinate to a plus code? What level of precision do you output at? Do you err on being over-precise or under-precise since OLC has infinite precision? Do you output a single larger area plus code, or a collection of smaller area plus codes? What happens if the coordinate is on, or very near, a grid-line? What happens if the coordinate is at the intersection of two grid-lines?
And if that wasn’t enough… Can I get the set of plus codes corresponding to a parcel of land, or the footprint of a house, or the boundary of a park? Can I interoperate between a polygon and a collection of plus codes? Google doesn’t appear to supply the footprints of structures or places, so if you needed them how would you acquire or create them?
GIS systems are software systems. And software is, shall we say, picky about semantics. Choose incompatible semantics and its all garbage-in garbage-out. Which means that getting an old system to understand plus codes, or having a new plus-code enabled system integrate with a legacy system — absent a data mediator — is going to be both costly and foolish.
People are not Computers
One of the touted benefits of plus codes is that they are supposed to be more people-friendly. I admire this sentiment, but the implementation so badly misses the forest for the trees I hardly know where to begin.
First, the average person doesn’t care about clever encodings because they have no intention of remembering gibberish codes. In the last five years how many telephone numbers have you memorized or had to recall? Would you really make an effort to start memorizing them today if someone were to come up with a clever way they could be encoded in 7 characters instead of 10 digits?
A clever encoding of latitude and longitude doesn’t actually solve any problems because the problem isn’t with remembering codes, it’s with communicating them!
Second, no one cares if the encoding scheme can’t spell dirty words. They never intend to see the codes in the first place, and when they do it will be for as short a period as possible.
Third, people have fuzzy and incomplete memories. In the rare case where someone wants to memorize a plus code, they’ll have issues. This is because at 10 alphanumeric characters the code is already too long to be easily memorable. Furthermore, the system requires that you memorize and recall those characters in a precise order, which is among the hardest of memory-related tasks.
At best, plus codes are only good for computers, and maybe rare cases where a person would copy/paste a plus code to a friend, only to have them turn around to look it up in a maps application.
A Better Approach
If you truly want a better system for humans, then stop thinking like a computer.
The primary issue around location is communicating that location. Anything else will forevermore be left to computers. Facilitating communication between people, and from people to computers, is what has to be prioritized.
People speak using words and sentences. They write using words and sentences. We communicate using words and sentences. So why not just use words and sentences to communicate about location?
That’s what we’ve done at QALocate. A GeohashPhrase™ lets people talk about specific locations using phrases from their native language. If this sounds like a better solution than cleverly encoded gibberish you can read more here.