The 10:10 code - global position in ten characters | Hacker News Reader

The 10:10 code - global position in ten characters

blog.jgc.org

64 pointsjgrahamc39 comments

The article mentions GeoHash [1] and suggests 10:10 is better as it contains a check digit. The advantage of a GeoHash is you can have arbitrary accuracies. For example, if you take the GeoHash for Buckingham Pallace (gcpuuwme9mzp3) and remove the last 6 characters (to give gcpuuwm) then the GeoHash covers a large area of London.

[1] http://en.wikipedia.org/wiki/Geohash

Fair enough, but that's not the use case for the code. It's designed to get someone who's using a consumer navigation device to a location with reasonable accuracy with high accuracy in entering the location itself.

You've said "that's not the use case" 4 times already, which is almost half the number of comments. Perhaps this is a clue that your proposal needs a bit of work.

That's the great thing about hacker news -- you can throw an idea at them, get some feedback, and iterate while it's still cheap to change.

Or it's an indication that people are throwing up use cases that weren't what I was designing the code for.

For example, people have said that the ability to compare two codes is important to see how close they are. They've said this without justification and it is not a use case for which I designed the code.

Also, people have said that arbitrary levels of accuracy are important, they are not needed for a navigation device being used by an individual to get to a location.

Others have brought up the issue of using it instead of postcodes. It was not designed for that either.

But isn't it the case that a system for encoding location is more likely to be widely accepted if it can be universally applied to a wide range of use-cases?

Maybe wide acceptance isn't the use case!

It's okay to intend a tool for a specific purpose! It's okay to do one thing well.

Then the blog post should mention what it does well. In my case, I figured out one place where it would: http://news.ycombinator.com/item?id=2674732

This post left too many blanks, and we are trying to fill them in. If you don't show people why we should use your tool, and why it is better than the alternatives, people may not figure them out.

"For example, people have said that the ability to compare two codes is important to see how close they are. They've said this without justification and it is not a use case for which I designed the code."

So, actually, that property would be pretty helpful for deduplication.

>For example, people have said that the ability to compare two codes is important to see how close they are. They've said this without justification and it is not a use case for which I designed the code.

I've raised this objection, but I still think it is quite valid.

Compare "43 Montgomery St" to KN4 HNA M33B. First off, I'll tell you immediately which one I find more memorable! I can use any number of mnemonics to store the first; the second is near incomprehensible.

Ignoring even that, people have quite a bit of experiential knowledge of local street addresses. Give most people an address -- even an unfamiliar one -- and they can provide with some degree of accuracy what's around, a way to get there, etc.

For local use only, this encoding doesn't make sense to me. But, if we assume that the typical user of SOC would be a person who strictly uses their GPS to navigate from point to point, this encoding has some advantages.

Another possible use case would be for travelers. Costa Rican addresses are based on distances from landmarks, and as a traveler I quickly learned that many of the landmarks refer to buildings that were demolished in the 1970s! In that case, 75 m Norte de la Coca Cola means exactly as much to me as HFW QMJ BBBE, and this encoding could actually be entered into my GPS.

I kicked this back and forth a bit. IMO, the idea has merit but the presentation wasn't narrowly tailored. It took me ~20 minutes, but I came up with a fairly strong use case: travel.

When I traveled to Costa Rica, I quickly learned that no formal addressing system exists, and instead everything is based on landmarks. This made use of GPSes extremely difficult, to the point that many people say using a GPS in Costa Rica is fairly worthless.

If I was back in Costa Rica, I'd love to be able to type HFW QMJ BBBE and be directed to my destination, rather than trying to parse "75 m Norte de la Coca Cola" -- first, where's "Coca Cola"? Wait, it's a bus station?! It was a Coca Cola plant back in the 1970s? Gee, that's helpful...

More generally: this is why everyone MUST narrow your idea's scope and build everything around that. When I hear "positioning code", my mind jumps to using this code to locate a new restaurant that opened downtown. That's worthless. Just tell me the damn street address instead.

But if you told me that this code could let me navigate to a restaurant in a city I've just traveled to for the first time, in a country that doesn't speak my native language, and doesn't do street addresses like I'd expect? I'd say you were an absolute genius.

This happens because the post focused on the idea, and barely spent a single line talking about the applications. Thus, I do what everyone else does -- I filled in the blanks. Don't let people fill in your idea's blanks!

I can easily imagine a consumer navigation device showing me ever-more precise maps as I enter a geohash code. This would be very valuable for orienting myself. I don't just have to arrive there; I want to see where the place is!

I use geopo rather than geohash: http://geopo.at/intl/en/developer/ Can't remember why (the database schema calls the column geohash) but it is great in either system to be able to do a really fast lookup based on a substring and then use proper distance algorithms to narrow down to what's actually close. You need to over shoot as mentioned in the Geohash article because boundaries could be very close to the position.

We don't need a twelfth system for encoding lat/lon tuples. Pick an existing one and start using it.

Currently, we have:

- decimal lat/lon

- d/m/s lat/lon

- UTM ( http://en.wikipedia.org/wiki/Universal_Transverse_Mercator_c... )

- MGRS ( http://en.wikipedia.org/wiki/Military_grid_reference_system )

- Geohash ( http://geohash.org/ )

- "Natural Area Code" ( http://en.wikipedia.org/wiki/Natural_Area_Code )

Please, suggesting something like this and encouraging people to implement it is like coming out with a device that only charges over micro-USB. Just... don't.

I completely agree, but was mystified by this statement...

*Please, suggesting something like this and encouraging people to implement it is like coming out with a device that only charges over micro-USB. Just... don't."

What's wrong with micro-USB? I look for it whenever I buy a new device, just 'cause all new phones, cameras, etc. use it (and only it) for charging. It's a nice standard. No?

Maybe he's complaining about needing a computer to charge something, i.e. he doesn't have a wall-plug usb charger.

I said micro-USB, not mini-USB.

Yes, micro-USB is the standard which most phones, and some other devices like the Sony Reader, conform to these days. What's wrong with that? I've never seen another phone connector standard become as popular; before micro-USB it was mostly proprietary connectors.

No, before micro-USB it was mini-USB, which worked great on fucking everything from portable hard drives to Blackberries (remember those?) for years and years.

Seriously, micro-USB is a solution looking for a problem.

Do any of those include a check digit to ensure that the right code is being entered?

you could reduce the number of letters required without losing accuracy by being less precise at the poles (a simple lat/lon is over-precise there because the lines of longitude get closer together). it would require a slightly more complex transformation, but not by much (for example, you could make it uniform in lambert equal area - http://en.wikipedia.org/wiki/Lambert_cylindrical_equal-area_...). in other words, by taking the sine of the latitude and then converting that to letters you can truncate more digits (because you the resolution you need at the equator and at the poles is the same).

also, i suspect geohash could be improved by using a fractal approach like http://xkcd.com/195/ (http://blog.xkcd.com/2006/12/11/the-map-of-the-internet/) which should reduce the need for worrying about boundaries (ie make things more efficient).

in fact, you could combine the two.... [edit: although the fractal approach with equal area would mean that the distances of "nearby" points changed with latitude; it would be better to use an equal-distance projection.]

Ham radio operators use a "grid square" code to specify locations, see

http://en.wikipedia.org/wiki/Maidenhead_Locator_System

this is particularly used in VHF/UHF operation where something special is happening if you contact somebody more than 200 miles away. (Last month I talked to somebody across Lake Ontario about 280 miles away with my handheld thanks to a tropospheric duct.)

Grid square codes range from 4 characters to 8 depending on how detailed you want to get. Less detailed than jgc's system, but already in use.

I like this idea but since it requires changing everything in the world to deal with it, I think a better way to enter longitude/latitude co-ordinates would be better.

Or maybe not, since search will make all of this irrelevant :)

It really doesn't require much change. The major GPS vendors could support it plus the online map services (so that's only a handful of people) and then businesses could start publishing the 10:10 code of their location.

My car won't support it.

Loads of GPS vendors and loads of online map services isn't "much change"?

Truly, it's not that much change. It would be a small update to allow GPS devices to accept a 10:10 code and validate it, and the online mapping services could quickly add recognizing the codes with a regexp + check the checksum.

A small update in a well written desktop app? In the poorly written firmware that exists on many embedded device, that's a large change.

And given that there's thousands of devices, even it was just a small change it would be a huge massive change because of the number of places that need to change.

That's a pessimistic reading.

Firstly, there's no requirement for universal vendor support for the coding system to be useful. Obviously the motivation for support is higher as is the critical mass of support, but it's not all or nothing.

Secondly, by definition one can convert from existing lat/long values to this programmatically. The burden at either input or output end to support this is relatively low and can be calculated from existing data; frankly the greatest burden is in UI, which is hardly insurmountable.

That said I'm still not necessarily persuaded this is the right idea or the best implementation, but I think you're overstating the barriers to adoption.

I'd suggest that you go after end-user consumers first by adding 10:10 support to their personal GPS devices -- iPhone, Windows Phone, Android. If people like the idea, then major manufactures of single-purpose devices are more likely to adopt it. Plus, it's pretty cheap to build an "app for that".

Although that's interesting, there is a lot of advantages to a code based on postal areas. In both cases you can find out where on earth a code is, but with a postal code you can figure out how 2 points are related, and you can easily aggregate statistical data.

If you have 2 10:10 codes/lat lon pairs/geohashs you have no way of knowing if they are in the same town, or are separated by a big lake. The longer the common prefix of the 2 post codes, the more likely the 2 locations are to be in the same place. If you're looking for "ABC 123", and you're outside "ABC 124", you're probably close.

When collecting statistics, you can ask people for the postal code, and then aggregate the data based on where people live by just truncating the postal code.

I understand that but that wasn't the primary use case for the 10:10 code.

Firstly that's specific to how a particular region encodes its postal coding, which isn't worldwide.

Secondly, it's less true than you'd think within the UK. From http://en.wikipedia.org/wiki/File:London_postcodes.png, compare the locations of W2 and W3 or W12 and W13.

I agree. Canada uses a concept of FSAs (forward sortation areas) that correspond to regions. I don't think it's safe to rely on truncation under the Canadian postal system. I believe only the first three letters/numbers identify a geographic area, and this is the triple used by politicians and people who need to split up regions of provinces. As you might expect, FSAs are way smaller in major cities than out in rural areas.

A lot of places rather distant from Paisley have PA postcodes - e.g. on the Isle of Mull.

Also there are non-geographic postcodes:

http://en.wikipedia.org/wiki/Postcodes_in_the_United_Kingdom...

e.g. SAN TA1 - which is my favourite :-)

Small changes to the inputs can result in dramatic changes in the output.

For example: I know that (50,1.11) is pretty damn close to (50,1.12); how do I begin to think about the distance from MEQ N6G 7RN4 to MEQ QYD 901Q?

In my mind, that's a pretty huge distance -- look how many places changed!

Not so: that's the difference between (51.0955, 1.13) and (51.0965, 1.13). Pull that up in a map. That's a difference of, what, a hundred feet or so?

IMO, a location encoding that can't indicate at a glance that two close locations are -- well, close -- isn't helpful.

http://spotwoo.com/

My weekend project a couple of weeks ago, an attempt to solve this sort of problem. I was picking up a friend, and there was no easy way for his smart phone to tell me where he was. So I wrote a site to let 'im. I haven't finished testing it, but folks might be interested.

If you are to make such a change, why settle for such low accuracy? What about height/floor numbers?

Also, what about geological changes such as the japanese earthquake? thousands of misdelivered letters...

It's not designed for postal delivery. It's designed for everyday navigation.

There are cases where navigation codes won't be more practical than postal codes: Old cities with narrow streets and heavy buildings where GPS has no reception. Try navigating Venice, Italy with a phone GPS to get the idea.

Reply on news.ycombinator.com