Hacker News new | past | comments | ask | show | jobs | submit login
Open Location Code (github.com)
137 points by FriedPickles 9 months ago | hide | past | web | favorite | 118 comments



Reinventing the wheel without any clear advantage.

Plus codes don't seem to have any advantage over widely used MGRS (Military Grid Reference System). https://en.wikipedia.org/wiki/Military_Grid_Reference_System


I find them a lot more human-friendly, but I guess that's subjective. The example from the wiki page you linked:

MGRS: 4QFJ12345678

Plus Code: 835M+Q7 Honolulu


That's only a partial plus-code, though, which relies on external positioning of Honolulu. The full plus-code is 4 digits longer, and with the plus itself, it's 11 chars vs. 12 for MGRS at 10m precision (14 for 1m, which is more than plus-codes can do).

If MGRS was too long, it could simply get a new encoding and be done with, or add the abbreviation system.

Also, that particular plus-code you used as example is not recommended. Reference points should be small features that will have low geocoding variance. Larger points like cities, or here whole islands, as there can be very large variance to the exact location derived from the name (i.e. the pinpoint location Google Maps finds you when you just search for Honolulu).

From the README:

> Rather than a large city size feature to generate the reference location, it is better to use smaller, neighbourhood features, that will not have as much variation in their geocode results.


> That's only a partial plus-code, though, which relies on external positioning of Honolulu.

Yes, a concept that is very human-friendly.

> Also, that particular plus-code you used as example is not recommended. Reference points should be small features that will have low geocoding variance. Larger points like cities, or here whole islands, as there can be very large variance to the exact location derived from the name (i.e. the pinpoint location Google Maps finds you when you just search for Honolulu).

You should take that up with the google devs I guess. The code I gave was generated by google maps.


The problem I have is that the reference points do not respect natural or human boundaries. Around where I live, the reference points Google Maps give are variously an adjacent town (the other side of a major river!) and a small housing estate which no-one living outside that estate will be aware of.

If Google want people to use this system, they need to give a choice of reference points.


> Yes, a concept that is very human-friendly.

It's also entirely broken, rendering the system unusable if you expect sub-kilometer positioning across different geocoding providers.

Whether something entirely defective is "human friendly" doesn't really matter.

> You should take that up with the google devs I guess. The code I gave was generated by google maps.

Not my responsibility. That they cannot even use it correctly as per their own docs themselves doesn't make for a good sales pitch. In fact, Google Maps cannot process plus codes using arbitrary reference locations, making use per the plus-code documentation impossible with it.

To give an idea of why that plus code is borked:

Honolulu @ Google Maps: 21.3069444,-157.8583333

Honolulu @ Bing Maps: 21.30493,-157.85788

The difference is around 300 meters, which results in an absolutely awful error margin, and I'd argue that this is very much one of the best-case scenarios. That's worse than if they had added 2 more characters to the plus code, and just removed the Honolulu part.


I think you misunderstood the way these reference locations work. Both google maps and bing will resolve the given plus code to the exact same location – a margin of error of 0cm.

It's only important that the reference point doesn't leave the 40km square that it's supposed to be in. Google Maps might actually have a smarter implementation than the docs suggest. If the whole city is in the relevant 40km square, using it as a reference point is fine.


Yes, I misinterpreted the problem slightly. Rather than always being a problem, it is only a problem if there is uncertainty to which lat/long degree the location resides in.

It appears to search for smaller and smaller features until it finds something that does not span multiple areas, while still being within the same area as the final location. For example, for a random address on Hawaii, the plus-code becomes "74FF+W7 Ocean View, Hawaii, USA", as Island of Hawai'i spands multiple lattitude degrees.

However, this results in increasingly complex reference points, and I am not sure whether this can be done in a generic fashion. Of course, it may simply bail out to full codes at that point.


It would be nice for the code to have some kind of 'check digit', so that the code cannot resolve if the geocoding returns the wrong square, or if any letters are off-by-one or transposed.

Check digits don't work well with truncatable codes though :-(


Why not? Every letter could be a check digit. The drawback is that the same location will have many possible location codes, of course.


no, having check digits means that some code corresponds to no location and are syntactically wrong.


I realize now I meant some kind of error correcting code, combination. Like this:

1

1 can be followed by either odd numbers or even numbers. If followed by an even number, the next number must be odd.

127

Now if you truncate that to 12, crucially 12 has the same meaning as 11. 1 and 2 to have the same symbol meaning, but are using "sign" to hint at the next number.

This will greatly reduce the chance that a random number will pass for a position. This can be made more elaborate, with more or less advanced encodings. The problem is of course that you waste bits on redundancy and so addresses everything else being equal, will have more characters in them.


A much less expensive and much more normal solution would simply be to put a single CRC digit at the end.

Systems such as what you describe are too complex and non-standard.


But then you can not truncate the location.


I'd argue that this would never be done by hand anyway. The average user will not understand the encoding, and I doubt many will think "Hmm, I have this plus code, but I'd like to only have 1/20th of the precision."

Programmatic truncation would still be very easy, as it would just require a new checksum to be calculated post-truncation.


Honolulu is a city, not an island. It is more than enough information to select a rectangle roughly 40km on a side.


Ah, of course, a mistake on my end. I mixed up Honolulu, the city, and O'ahu, the island while looking up the plus-code due to misinterpreting Google Maps' peculiar choices of font cues for countries, islands and cities. I am not very familiar with Hawaiian geography.

Honolulu was the only large name on the island, with O'ahu being written in a similar font-size to all the other cities. Of course now I can see that the cue is that the island name is written in black, whereas cities are written in very dark grey...

UX, yo.


MGRS has variable precision just like Plus code.

4QFJ12345678 has precision 10 m. Example of plus code with comparable accuracy: 73F69J3M+VV

10 km accuracy in MGRS is just six letters: 4QFJ16

100 km accuracy is just 4 letters: 4QFJ


The Plus code I gave as an example addresses a 14x14m square, Not 10 km.


Wait a second. So 835M+Q7 is not a full identifier? You need to specify city too? Ain't that gonna cause problems?


It's a referenced plus-code, which "saves" 4 digits.

Instead of being a true location like the full plus code, coordinates, or MGRS, a referenced plus-code requires a referenced location to resolve (think "124 meters north of the postal office"), and the precision becomes entirely dependent on the precision of the services used to resolve the reference location (i.e. Google Maps might consider the exact location for "Honolulu" to be somewhere else on the island of Honolulu than Bing Maps).


No, they do not work relative to a point. You replace the first 4 digits of the code (the area code) with a location name that's clearly in the area, the following digits stay the same. The name resolution of the location can be off by kilometers and it still works.


While you are correct in stating that the point is only used to resolve the area, you conclusion is off by kilometers (he he he).

When using a point to resolve a 4-digit code (1x1 degree, approx 100x100km), it is true that anywhere within the same 4-digit-equivalent area will result in the same location.

However, while this improves the average case compared to point referencing, it makes the worst case absolutely horrendous: You'll end up referring to a wrong long/lat degree, meaning an error of over 100km!

The closer you are to the edge of a lat/long degree, the more vulnerable you are. If your location is, say, 10 meters from the edge, then 10 meters geocoding imprecision is all it takes to cause a >100km error.

Which is exactly why the plus-code readme says the following, as I have quoted before:

> If the reference location is derived from a town or city name, it is dependent on the accuracy of the geocoding service. Although one service may place "Zurich" close to the Google office, another may move it by a hundred meters or more, and this could be enough to prevent the original code being recovered. Rather than a large city size feature to generate the reference location, it is better to use smaller, neighbourhood features, that will not have as much variation in their geocode results.

In order for the reference system to work, references must either be close to the center of a lat/long degree (which allows great error margins on geocoding), or use points which have consistently high precision.

Neither case result in memorable reference codes like "XYZ Honolulu", so just using the extra 4 digits is the only sensible choice.


In my opinion, a big disavantage of MGRS is that it is based on UTM. These days nobody uses UTM and UTM is hard to grasp if all you are used to is lat/lon coordinates.

So the clear advantage of Plus Codes over MGRS is that it is based on lat/lon


Nobody uses UTM? Whaaaat? UTM is widely used in many many geographic endeavours. It was the de-facto standard for almost any analytical work during my master's and I bet still is. When you're dealing with smaller areas than a country or the whole planet, there's a ton of value of using linear units instead of arcs.

Once you try to do any meaningful spatial analysis, you're projecting your lat/lng to a linear unit. And UTM is possibly your first choice of projection depending on context.


Spherical coordinates systems are always a tradeoff between usability and simplicity.

Plus Codes are certainly simple, easier to calculate, and consistent, but UTM has clear advantages in that it utilizes a Mercator projection adjusted for the contour of the earth, so that distances remain close to scale within any given grid zone…

…except in Norway.

In Plus Codes, the scaling is lost, and the distance covered by coordinates of equal precision changes dramatically with latitude.

Of course, there is also the fact that the mapping ellipsoid used by UTM changed at some point, so old coordinates can be off by up to 200 meters compared to the current mapping. But the current system has been in use long since the advent of GPS, so it's really not an issue.


UTM is widely used and is the standard way of expressing position within many countries, where lat/lon is second-class citizen on everything but phone navigators.


I imagine that you wanted to put focus on "second-class", but if we focus on "everything" we would have a compelling argument for lat/lon as a base for a transmission format.


MGRS doesn't allow you to ommit the larger value coordinate chars instead of a city/place name.

MGRS doesn't use a charset that doesn't have ambiguous charachters.

Just two. Might be minor, but it's not no advantage at all.


Couldn't you "kinda" achieve the same with MGRS?

I've seen a few maps where the first page states what grid zone and 100,000-meter zone the map is in (for the honolulu-example, "Honolulu" would imply 4QFJ).



My exact thought. This is identical to MGRS, except that you lose the "cartesian coordinates locally" feature.


I’m not so sure 6GCRPR6C+24 is a great replacement for an address, but maybe I just don’t know.

Although I could memorize my own address, I’d have a hard time memorizing my friends’ addresses. Yes, nobody knows each other’s phone numbers anymore, but those were a very temporary relic from a very short span of time (the telephone era). Humans have always known each other’s addresses, and have always spent a lot of time telling each other their locations in the form of a spoken address.

On a more technical note, I am guessing this works super-well for auto-completion, but didn’t see any example of that in the README...

All of the various geonaming systems seem very Esperanto at the moment. I think we (as in all of us, the global community) could build upon Google’s effort to come up with a much more human-friendly system to provide easy global addressing. Yes, the address format system is way too localized and breaks down at both scale and small distances; whatever that code was at the beginning of my post (I’ve already forgotten it, and I’m too lazy to re-paste it) is just not nearly as easy to remember as “100 Ocean Drive” or whatever. I also have no clue how I might represent the building next door.


There's a feature that vastly improves the human usability for Plus Codes. The least-precision, first-four characters can be omitted and replaced with the City / Region name: e.g., "Nairobi PR6C+24". Considering that uniquely identifies just a few square meters of space on Earth that seems pretty good.


That makes sense.

"9C3XFWG3+2G" is barely any shorter than using coordinates, but "FWG3+2G, London" is significantly easier to read or write down than coordinates.



Surely the point of truncated codes is that they are used in contexts where other information makes clear the rest? So if I'm talking about things in the UK and someone says they live/work/whatever at "FWG3+2G, London", I already know which London.


Does Melbourne resolve to Melbourne, Australia, or Melbourne, Florida?


Surely the point of truncated codes is that you would only use them in a context where things like this were already clear?


I think Google Maps picks whichever is closest to you when you enter the code.


Or Melbourne, Québec, Canada?


> my friends’ addresses

I guess this isn't really aimed at you.

As https://xaddress.org/ says, "4 BILLION PEOPLE DO NOT HAVE A FUNCTIONAL ADDRESS ACCORDING TO A UNITED NATIONS ESTIMATE" (Not sure why they say it in caps, sorry.)


It's not a replacement for an address, it's for places that have no address.


This feels like an accidentally arrogant, Western-centric way of looking at addresses that might not conform to our description of an address. Like, “the White house on the hill in John’s village” is as much of an address as 12 Whitehouse Lane, Johnsvillage CA or whatever.

This is the same as saying people don’t have money because their wealth is in forms that aren’t immediately liquid, or translatable into dollars... We need to tread carefully here. Especially if we want people to actually embrace this over far more human-friendly existing forms.


> This feels like an accidentally arrogant, Western-centric way of looking at addresses

nope, many places simply do not have addresses. many places do not have streets. And unless you can find a more global addressing format that does not require translation of complex sentences we can only use location based addresses for a lot of places.

Essentially a plus code is something that you can paste on amazon for a delivery.

Now we could say that web giants like amazon are a danger to the world, a danger ever so ominous as so alluring. Still to the aim of identifying a place for delivery many places do not have addresses.


The primary users of these codes are places where politics prevent addresses from being assigned (government doesn't want to admit people live there). The codes give them a real address that your phone can navigate to, and for them it's working just fine.


A shoutout to Rober Dam who built Xaddress, "Give 7 billion people an instant physical address": http://xaddress.org/


Have people here heard of "what3words"? It's a similar encoding scheme that is much more human-memorable (for English speakers, at least).

The same spot, to +-1.5m is universe.renovated.upon as opposed to 6GCRPR6C+24


Proprietary. Charges for business use.


> for English speaker.

Almost all English speaker do not need these codes.

Also the complexity of the implementation is not trivial.


I have asked this question to a member of the Google maps team, and have not gotten a precise answer. Is there some scheme which can distinguish between floors of a building? This is very useful, for example, store locations inside malls. The LatLong scheme does not seem to be enough. I'm guessing that it will have to be 3D, but I have never heard of a standard location scheme which incorporates this information.


Lat, long, elevation. The original and best for delivering an ICBM to your door.


This may work, I should try this. Can current smartphone resolution decide the elevation difference between the first and the second floors of a building?


They already been doing that for couple of years. Maps already knows which floor I'm on in certain malls if I have the gps+wifi on.


This does rely on an ongoing wifi mapping effort but is the most effective for regular simple smartphones without fancy sensors.


lots of phones have barometric sensors that can be used for more accurate elevation differences. sadly it seems to be a "premium" feature and i can't find it in any phone <300 dollars in price https://ieeexplore.ieee.org/document/6817923


Those sensors you are referring to are not reliable enough to tell elevation accurately. In addition to that, buildings may have different pressure to the outside


They are sufficient if you have other phones in the same vicinity at known locations.

If bobs phone is 10 meters higher than alex's phone, and they're in a 2 floor building, bob must be on the top floor and alex on the bottom.

This principle can be used at scale by people like apple and google.


i have successfully told the difference between the ground and 3rd floor with a galaxy note 3's barometric sensor(for triggering home routines only when actually at home vs just arriving at the location)

maybe that was just a particularly good sensor...


My 2013 Moto X has a barometric sensor. When graphing the raw sensor output, I can see a ~6ft elevation change with little difficulty.


GPS elevation data is pretty poor in my experience. Especially inside buildings.


To reliably triangulate elevation from GPS data you need quite a lot of satellites. Air pressure gives a better signal, but obviously needs to be calibrated for weather etc.


To some degree, but not quickly and reliably.


What's wrong with just using floor names, e.g. "First floor"?


Yes, this is the current solution. I am a bit dissatisfied that it is not a "uniform" address scheme. It would be nice if an app can guide you to the exact store on the exact floor based on one location code.


Floors can be weird; I’m not sure how you’d handle a hotel skipping the 13th floor, for instance. Also, are floors 0 indexes or 1 indexed? It therefore probably shouldn’t be built into the protocol.


Or it should be built into the protocol and specify a specific ruleset -- if a country/building follows another, it's up to the user to translate.


In some places it can be -1 or 2 indexed so that a building can have more floors than legally specified.


Also some buildings could have been added to after building and a basement turned into a living area, so -1.


Who determines what is the "first floor"? Last week I had a medical appointment. The doctor's office was on the 6th floor; but, it was 7th floor counting up, as the building's ground floor is the "Lobby."


This is normal in many countries but it's extremely uncommon in theUS, where as you implied the ground floor is typically the "first" (in the numerical sense) floor.


This is a very common numbering scheme in some countries (at least most of Europe) but very uncommon in the US.


The startup I'm involved with has a solution that solves this problem.

Edit: Sorry about the terseness. I decided about half-way through to write a top-level comment that delved more deeply.

In short, our solution is this: http://qalocate.bamsaas.com/wp-content/uploads/2018/12/QA-Lo...

The AliLocator is flexible enough that whole structures can be sub-divided by any arbitrary criteria, with floor as potentially one of many. Since the AliLocator itself would be a bit awkward to use, you'd just want to create an LNS entry that then pointed to it.


right, I can't see anything about distinguishing floors and doors. I'm pretty sure there are large amounts of people who need a floor and door added to their identifier in order to - what was it again "receive deliveries, access emergency services, register to vote – and more."


So, did they just reinvent the Maidenhead locator ( https://en.wikipedia.org/wiki/Maidenhead_Locator_System ) or any of the previous systems?


There's a pretty solid evaluation of the new system in terms of the old ones at: https://github.com/google/open-location-code/wiki/Evaluation...

Indeed maidenhead seems to be the strongest of the previous approaches, they rejected it because it can include words.


"Codes that are similar are located closer together than codes that are different."

I dug hoping to find out how they handle boundary effects, and gave up.

The numbers 0.999999 and 1.000000 are far apart in Hamming distance but close in position. What bounds are achievable for the maximum Hamming distance between two nearby locations, in any such system? Do they approach the theoretical limit here, or is "that are similar" a crock that only sometimes holds?

For example, for a base 12 location code one could overlay a dodecahedron onto the earth, then rotate it by a low-discrepancy sequence of quaternions for successive digits. This would have very nice bounds for the maximum Hamming distance between nearby locations, at the expensive of efficiency: each successive digit subdivides the location by far less than a factor of 12. As locations approach each other, vanishingly few rotations will distinguish them.

One can imagine easy fixes for this scheme, but what is the theory? Do they have a theory? Do they implement it?


HAM radio locator grid does pretty much the same thing, with I would say roughly the same precision.

example: http://k7fry.com/grid/?qth=JN17EB67UN

I only knew of the 6-character location code, which is typically used when identifying yourself, but it seems there's the expanded version of up to 10 characters.

What I don't understand is the usage scenario. Plus codes are not human-friendly like street addresses, so I'm assuming they're meant for machine processing. But there you have all these other systems like HAM location codes or MGRS, that I don't see added value.


Why wouldn't they use 36 (Letters+digits) to break it down in a 6x6 area instead? Much more precise at the same length.

At 6 length, you're already down to the kilometer precision at the equator. At 9 length you're down to 4 meters.

And that's with a dumb grid division, which is very uneven on the globe, the cube projection is probably a better way to deal with it.


The larger the alphabet, the larger the risk of glyph confusion.

Here's the alphabet they chose:

  // The character set used to encode the values.
  var CODE_ALPHABET_ = '23456789CFGHJMPQRVWX';
It omits easily-confused glyphs like "0oOD", "1lLI" etc.


This is an interesting alphabet, even Base58 (Bitcoin addresses) have "o" and "1".

There's some information on how they generated it here in the spec[1].

The characters that are used in Open Location Codes were chosen by computing all possible 20 character combinations from 0-9A-Z and scoring them on how well they spell 10,000 words from over 30 languages. This was to avoid, as far as possible, Open Location Codes being generated that included recognisable words. The selected 20 character set is made up of "23456789CFGHJMPQRVWX".

[1]: https://github.com/google/open-location-code/blob/master/doc...


https://github.com/google/open-location-code/wiki/Evaluation...

One of the design decisions was to avoid ambiguous characters, so that cuts out at least 9 (I1L 0OB8).


Others have noted ambiguous character, but an equally important factor was to avoid swear words in all the languages that use the Latin alphabet (or have a latinized form like Russian, Chinese and others)

It is almost impossible to make words out of the allowed characters


For those wondering why they invented yet another grid coding system, here's their justification : https://github.com/google/open-location-code/wiki/Evaluation...

The XKCD on competing standards comes to mind…


Perhaps there's an underlying psychological advantage to using Plus Codes. This past week I had to manually transfer coordinates of various locations from one handheld google machine to another google machine. It was less tedious to use the Plus Codes.


I want an address that a drone can use to drop a package on my 3rd floor patio.


I remember that there is another project that is similar to this. They divided the whole world in to grids and assign a code to each one.


Yeah, that's what3words (https://what3words.com/), which (IMO) makes for easier to remember words. It's available in multiple languages too, for the non-english speaking world.


And it is (falsely[0]) patented, proprietary and generally deemed a bad thing by programmers and geofolk all around. Some previous criticisms:

https://news.ycombinator.com/item?id=8614198

https://news.ycombinator.com/item?id=17423251

https://news.ycombinator.com/item?id=15579017

[0]: https://news.ycombinator.com/item?id=15580809


I do work in rural Kenya, and the big problem what 3 words has is that the words are totally randomly allocated around the world. A REALLY important attribute of addresses is that they can be vague.

"He's on High and 23rd", "I live on Monroe", "Near Jomo Kenyatta Airport", etc.

The biggest mistake what 3 words made was not making the first two words be a geocoding of the approximate area and the last word could provide additional precision. It looks like google plus codes fixed this which is actually a huge improvement.


could you explain this a bit more ? not able to understand the implication of this design flaw


Knowing your neighbors address tells you nothing about your own address. To be able to get your address, you need a smart phone, and at that point you could just send me a pin with your exact latitude and longitude.

Approximate locations are dramatically more useful for navigating in much of the rural developing world. "How do I get to village X" will have an answer for 10 miles around. "How do I get to X lat/lng?" will be met with a shrug, both from google maps which will suggest you drive through a field and from anyone you ask.

If you can make something that works at the village level, you can bootstrap people getting their location. If the first word provided approximately "country" level information, the second provided approximately 1km bands (what you get if you evenly divide the three little words partitions), and the third gave you the 3m resolution grid, people without addresses could know their approximate address from others.

Basically, there's a bootstrapping problem and a usefulness problem. Right now, no one knows their 3 little words number. To become useful, most people need to know their 3 little words. How do you cross that gap? One way would be to have it be useful to know "2 words" or some approximate identifier for your region and then after locating you approximately, your service provider can tell you your last word.


This is a general problem with solutions in the space. Part of the niceness of say geohashes is that they telescope down.

The startup I'm involved with has developed what we call a geohash phrase. The core idea is to map English (or whatever language) words to the characters of a geohash. We usually map a word two-characters at a time, giving us 10-bits of precision for each additional word. So your location might be something like: "The big dog walks near the red house."

What is nice is that the phrase telescopes. So you can be vague when you want and only provide say the first three words of your location.


This is what I understood: Imagine your address is "massive heart will" but your next door neighbor's address is "correct position delay".


It's beautiful except that (1) it could vanish instantly and irreparably if they went bust, because it's not a public database and (2) I'd rather not have a single corporate entity be a gatekeeper of my ability to locate things.


It's somewhere in their FAQ but they pleaged that the dataset becomes open/free if the company goes bust.


That may not be in their power to grant if it counts as a valuable asset.


Unfortunately (or fortunately, since it's rather controversial), they made it proprietary, which means it's basically dead regardless of merit.

Also, I believe that they require large dictionaries, which makes it hard for apps to support it on low-end mobile. Wikipedia says ~10 MB for their database.


Their own site says 20mb


It appears not to be "open" and can in some circumstances cost money, though.


In my first naïve thought this seems trivial. "Just" map WGS84 coordinates to a less clunky identifier. What am I missing?



This is all I found about it:

> Cheap GPS devices have existed for at least 14 years [etrex], and yet latitude and longitude coordinates are still not widely used by people to specify locations. We think that this shows latitude and longitude have too many disadvantages to be adopted for a street addressing solution.

But still, isn't their solution just a "wrapper" around gps coordinates? How is it different than encoding 2 decimal numbers into a short text identifier?


I wish delivery services (mainly food delivery) would accept directions using this, like "Appartment block entry at XXXX+XX with entry code YYYY, building entry XXXX+XX with door code ZZZZ" (with code parsing somehow).

They keep getting things wrong for my location, but things like that (= simple and integrated with maps) would make it easy.


What's neat about this is its simplicity; its unencumbered nature; and its independence from any particular mapping or ontology beyond "a rectangularish portion of the surface of a sphere".

One neat application is for biologists recording locations of field samples.


Aside, if you ever have to do location based matching, having an index on hashes for rough locations with neighboring locations in multiple passes will often be faster than geo indexing.


This is really cool, but not really that much easier than coordinates. The good thing about coordinates is that you can choose the kind of granularity you want.

But kudos to Google for doing this.


These support truncation better than coordinates. With coordinates, truncation indicates a different location, with these it indicates a larger area.


This doesn't seem to work in the UK. The closest box to my house partially covers three homes, and would be interpreted as my neighbour's.


If you then zoom in further you should be able to get a smaller box.


Add (pairs of) digits until it covers a small enough area.


Thank you, don't know how I missed that.


Zoom in more for smaller boxes.


How is this any different or better than current geo-hashing solutions?


Small hack: You can Google a code, and it finds it on the map, already :-D


And it does it incorrectly according to their own spec.

It's supposed to be a square, not a point.


I'm involved with a startup that I believe has a wonderful solution to this and other related problems. Our website: http://qalocate.com/

Our platform: http://qalocate.bamsaas.com/wp-content/uploads/2018/12/QA-Lo...

The biggest issue with solutions like this isn't that they aren't clever, or even that they aren't better than say a geohash or lat/lon, but that they have the wrong target. Computers don't really care since its just as easy to parse a geohash, a lat/lon, or an open location code. The tricky bit is when humans get involved.

Its humans that have way more limitations when it comes to using complex systems. And frankly, humans still use addresses because the system co-evolved with us and our needs. Addresses solve the problem well enough, and have "outs" for when they don't work. For a bit more in-depth discussion on this see: http://qalocate.bamsaas.com/2018/04/04/addresses-are-complic...

So if we want to replace addresses, then we really have to think outside the box. Fortunately, the web has done a lot of the heavy pushing by introducing all kinds of new, useful, and exploitable semantics that we can apply in other domains.

Humans are pretty good at using names for things. When computers were first networked, we soon replaced IP addresses with names. Thus was DNS born. We then combined that with another id, and soon we had email.

We believe that a similar system can be used for locations. No one really cares about the exact geohash or lat/lon of a location, or the niftyness of your coordinate system. Instead, what we need are memorable names. So why not just use names?

That's what LNS (http://qalocate.bamsaas.com/wp-content/uploads/2018/12/QA-Lo...) is. It works very similarly to DNS and allows one to link arbitrary names to exact coordinate locations, structures, or even regions.

For example, I can have "thelittlenag.frontdoor" if I want to point someone to the exact coordinate of my front door. If I want drone deliveries, then maybe I tell Amazon to use "thelittlenag.deliverydrone". The lawn guy can use "thelittlenag.propertyboundaries" to figure where my property lines start and end. And "thelittlenag.house" and "thelittlenag.gardenshed" can logically reference as entities(!) the two structures we have on our property.

PM me if you have any questions.


I too have developed and patented a location encoding system. Perhaps we could work together. i don't know how to PM you. If I make a contact request on your website, will that work.




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: