Skip to main content

The 10:10 Code

Four years ago I wrote about a way to encode the latitude and longitude of any point on the Earth's surface to 10m of accuracy with a 10 character code. Apart from a modification to the way the check digit is calculated, the code remains unchanged.

The idea is this: instead of giving people addresses, or coordinates, you can give them something like a post code for any point on the Earth's surface. This can then be entered into a GPS device and decoded. Thus a business can provide its 10:10 code and know that people will be able to find it.

I was reminded of this, this weekend when I took the Eurotunnel to France. On their web site they say:

Now those latitude and longitude values are very hard to enter, and, although in the UK post codes are pretty accurate, they are not universal (e.g. in France and the US there's no equivalent). In contrast the 10:10 code is global.

Here's some JavaScript code that calculates the 10:10 code:

The 10:10 code of the Eurotunnel terminal in the UK is: MED 8FV N9K5

PS. Many people have pointed out that there are existing systems like this, and existing patents. As far as I am aware, none of them include a check digit. For example, there's the Military Grid Reference System, the Natural Area Code, this Microsoft patent and Geohash. The check digit is critical because it reduces operator error when entering a location on a GPS device.


You should propose this as worldwide postal code...

-- MV
Mark Russell said…
It'd be nice if the likes of Google maps (or my phone's Navigation or Maps app) understood it.

... and, if there were a web service like bitly for location that put me on the map of my choice in the right place.

... and, as an extension to that idea, if QR barcodes could link to the service.
Unknown said…
Probably shouldn't use both "8" and "B" or "D" and "0"...
Bob said…
What about using both lower- and upper-case?
R said…
This looks like simple arithmetic.

I would suggest two basic improvements...

1) Take into account that at higher latitudes, longitude need not be encoded as accurately.

2) don't combine latitude and longitude. Keep them separate, with a space in between. That way, a human reader can tell that two encoded points are near each other.
John said…
What a great idea for a google maps mashup!
Anonymous said…
this code is made less readable by use of single character variable names. :( Is it too much to expand them please?
Unknown said…
Do you have reverse ? i.e. given the string splits to proper lan/lat ?
Very interesting!

Q1: Where in the code the radius 10m is specified? Can we produce code with 500m radius?

Q2: Does this mean all points in a radius of 10m distance of a specific point will produce the same code?
Anonymous said…
cool stuff, two comments tho, first i translated your code to perl and couldn't get the same answer, so i then tried it in js and i got the same answer i got in perl!

so i think that the location at 51.09559,1.12207 maps to MEQ N6G 7NY5

secondly, c %= 29 you probably meant c %= base
Anonymous said…
cool stuff, two comments tho, first i translated your code to perl and couldn't get the same answer, so i then tried it in js and i got the same answer i got in perl!

so i think that the location at 51.09559,1.12207 maps to MEQ N6G 7NY5

secondly, c %= 29 you probably meant c %= base
Unknown said…
It's a clever idea, but it's too clever for a stupid person like me. I look at "MED 8FV N9K5," and it's not immediately obvious to me that it describes a point north of the equator and east of 0 longitude.
Unknown said…
Here is another way to make the resolution approximately consistent across the globe.
Enclose Earth into a cube. Divide each face of the cube into a 8,000,000 by 8,000,000 grid. Project the location onto the cube. The square number is your code. There are 3.84E14 squares on the cube: that's also 10 characters in base 29 but it gives you a resolution better than 1 meter on the ground anywhere in the world.
RJ said…
It would be nice (though technically impossible) to use a system where it's easier to calculate the distance between two points.

Perhaps putting a grid over a Winkel Tripel projection would work better
Anonymous said…
I made "GLOCO" a while ago, it encodes lang/lat to a code of 5 up to 10 characters long, since takes into account populair locations in the worlds. Hence city centres have shorter codes, compared to deserts. (
Mukesh Agarwal said…
Hey Nice Idea man.. But I propose either to use alphabets only or remove some confusing (look a likes )LIke: (1 and I,l),(0,o,O),(B,8),(b,6)
tjp said…
I like this, even though practically it's not very usable. Yahoos WOEID doesn't do error checking, but does a few things that make it v powerful:

- takes accuracy into consideration
- brings some sort of place hierarchy
- helps when the geocode of a place changes (earthquakes etc)

It's a long way for WOEIDS to become something that can be put into a GPS device, but using smart metadata is always better than, er, not that smart.

London is 44418.
Jonas Hogstrom said…
I translated the code to C#, and I got MEQ N6G 7NY5 as well for the coordinates for the terminal coordinates. The SOC-algoritm from 2006 and the 1010-algorithm differs both in the calculation of the checksum and the alphabet used. the SOC-version uses a 32 character alphabet, and the 1010-version uses only 29 characters. My C# implementation (including exe) for both SOC and 1010 twoway conversions can be found at

When I converted the 1010-coordinate back to latlong for the eurotunnel terminal, I got a difference of 11.1m from the original coordinates...
Unknown said…
So far so good but once encoded how does anyone else use it? Need a decode routine ideally with a link to Gmaps. Apart from that I agree with others who suggest eliminating ambiguous characters like I 1 l
Unknown said…
This comment has been removed by a blog administrator.
Clay Shannon said…
I am not a scientist, but rather a "jack of all arts" (photography, music, and writing).

I "proposed" a similar way of uniquely encoding locations in my utopian novel "The Vavilovian Conspiracy"

Free to download from
Anonymous said…
Not a bad idea (and the checksum is nifty!). However, the GeoHash scheme has two important properties that 10:10 does not:

* arbitrary precision (to nearest 5 bits)
* lat/lon are interleaved

Bit interleaving in particular is useful because a geohash which is the prefix of another contains the other in its bounding box. Two geohashes which share prefixes are near each other. And so on.

This is great for search (e.g. google) and for use as a single database key for a location.
technogeist said…
Talk about a serendipitous finding.

I've been thinking of, and attempting to create something like this, to extend the concept universally unique identifiers. (UUIDs)
William T said…
Agree with id.php - any geo-code needs to have the ability to be humanly interpreted - so if you see two codes you can immediately tell if they are close to each other. Geohash has that ability since the left-hand characters encode enclosing (larger) areas.
mrjbq7 said…
And how about a version in Factor!

By the way, I also get "MEQ N6G 7NY5".
Nick Berardi said…
The US has something similar but it is not used. In the US it is called ZIP+4 and the +4 such as


Identifies a specific property and can be reversed to an address with the right database. However the ZIP+4 is very rarely used.
Anonymous said…
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 ( )

- MGRS ( )

- Geohash ( )

- "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.
gking said…
Maybe it's my military experience, but I find UTM or MGRS the easiest.
Holtwick said…
If you like it even shorter try my modified Geohash algorithm I used in my project.
Unknown said…
May someday every place on earth has its own barcode, visitors can learn its history from scanning its qr code.

Popular posts from this blog

Your last name contains invalid characters

My last name is "Graham-Cumming". But here's a typical form response when I enter it:

Does the web site have any idea how rude it is to claim that my last name contains invalid characters? Clearly not. What they actually meant is: our web site will not accept that hyphen in your last name. But do they say that? No, of course not. They decide to shove in my face the claim that there's something wrong with my name.

There's nothing wrong with my name, just as there's nothing wrong with someone whose first name is Jean-Marie, or someone whose last name is O'Reilly.

What is wrong is that way this is being handled. If the system can't cope with non-letters and spaces it needs to say that. How about the following error message:

Our system is unable to process last names that contain non-letters, please replace them with spaces.

Don't blame me for having a last name that your system doesn't like, whose fault is that? Saying "Your last name …

All the symmetrical watch faces (and code to generate them)

If you ever look at pictures of clocks and watches in advertising they are set to roughly 10:10 which is meant to be the most attractive (smiling!) position for the hands. They are actually set to 10:09.14 if the hands are truly symmetrical. CC BY 2.0image by Shinji
I wanted to know what all the possible symmetrical watch faces are and so I wrote some code using Processing. Here's the output (there's one watch face missing, 00:00 or 12:00, because it's very boring):

The key to writing this is to figure out the relationship between the hour and minute hands when the watch face is symmetrical. In an hour the minute hand moves through 360° and the hour hand moves through 30° (12 hours are shown on the watch face and 360/12 = 30).
The core loop inside the program is this:   for (int h = 0; h <= 12; h++) {
    float m = (360-30*float(h))*2/13;
    int s = round(60*(m-floor(m)));
    int col = h%6;
    int row = floor(h/6);
    draw_clock((r+f)*(2*col+1), (r+f)*(row*2+1), r, h, floor(m…

The Elevator Button Problem

User interface design is hard. It's hard because people perceive apparently simple things very differently. For example, take a look at this interface to an elevator:

From flickr

Now imagine the following situation. You are on the third floor of this building and you wish to go to the tenth. The elevator is on the fifth floor and there's an indicator that tells you where it is. Which button do you press?

Most people probably say: "press up" since they want to go up. Not long ago I watched someone do the opposite and questioned them about their behavior. They said: "well the elevator is on the fifth floor and I am on the third, so I want it to come down to me".

Much can be learnt about the design of user interfaces by considering this, apparently, simple interface. If you think about the elevator button problem you'll find that something so simple has hidden depths. How do people learn about elevator calling? What's the right amount of informati…