[jxf]

I'm a little confused about what this replaces, but it's definitely not postcodes.

* Postcodes have a specific meaning: they're both a geographical area and a mail delivery zone (at least in the US). Replacing one short code with another, which requires a different and less reliable third-party service to correctly decode, doesn't seem like a good idea.

* Latitudes and longitudes are unambiguous, well-understood, and don't require a third-party service to be online in order to correctly decode. So it doesn't seem like this can replace latitudes/longitudes, unless we're talking about shortening their representation.

* Broadly speaking, while addresses have a lot of problems, they're unambiguous with human context. So this doesn't seem like it really replace addresses either.

* For things like a loose description that might not be associated with a single point (e.g. "Central Park"), I could see mapcodes being useful -- you can provide the precise boundaries of the park, where it's located, associate metadata with the mapcode like what hours the park is open, etc. That might be very helpful.

Also, won't there be multiple mapcodes for a single spot and won't that require cross-association of the respective metadata? For example, consider that Central Park is also in Manhattan, also part of NYC, also in Midtown in NYC, etc.

I guess that's not necessarily a problem, but it could lead to a lot of expensive processing for frequently updated locations/boundaries (e.g. a beach, a suburban development in progress, etc.).

[jofer]

> "Latitudes and longitudes are unambiguous..."

This is a tangent, but actually, they're not.

There have been (oil) wells fail because someone gave a lat/long without specifying the datum, and someone else assumed it was in a different datum.

Without a datum defined, latitude/longitude (no matter how precise) only gets you to within ~1km of an actual location.

The Earth is not a sphere (or even an ellipsoid). Therefore, we need models of the the absolute shape of "sea level" (i.e. an equipotential surface - varies due to density variations in the Earth) to go from a spherical coordinate system to an actual point on the Earth's surface. These are referred to as a datum.

Because our knowledge of the absolute shape of the Earth has changed over time, there are many different datums (ranging from spheres to ellipsoids to detailed gridded surfaces).

There are a large number of datums that are still in common use. WGS84 is the most common (and very accurate), but NAD83 and NAD27 are also very, very common, as well as many others. If someone gives you a lat/long in NAD27 (e.g. read off of a printed map) and you assume it's WGS84, you can wind up over a kilometer away from the original location. (NAD27 is reasonably accurate for the US, but is very inaccurate elsewhere on the planet. I regularly see it used for data everywhere, though.)

[kghose]

Thanks for teaching me about datums: http://en.wikipedia.org/wiki/Datum_(geodesy)

[jxf]

You're absolutely right, and I should have said that!

I was trying to contrast to the case of just typing it into some kind of map service, i.e. MapCodes. A lat/long pair unambiguously resolves to a single point in that service.

[diydsp]

> latitudes/longitudes, unless we're talking about shortening their representation.

That's a much smarter idea than this mapcode system. It would make sense to replace the base-10 representation with base 36.... at least in the Roman alphabet. It would probably be smarter to pick a base that works with the world's alphabets. Oh yeah, not all the world uses alphabets!

But even then, it's not that huge of an improvement, really! Every two digits of base 36 replace three digits of base 10. (36^2 = 1296). The b36 digits replace only 4 (or 4.5) base 10 digits. 4x b36 digits replace 6 base 10 digits.

I think this may actually just be the Ham radio grid system I mentioned elsewhere.

> For things like a loose description that might not be associated with a single point (e.g. "Central Park"). Here, I could see mapcodes being useful -- you can provide the precise boundaries of the park, where it's located, associate metadata with the mapcode like what hours the park is open, etc.

Heh, at this point, I'm just thinking "URL". After all, it's a Universal resource locator. How about mapcode://CentralPark/my_favorite_bench.

[lstamour]

From their developers' doc:

> Mapcodes can be easily translated between several different alphabets. The default system is based on the roman alphabet. Mapcodes in other alphabets are generated by character substitution.

And it's not based on representation of lat/lng, which is why it's more of an improvement:

> As explained in the previous section, by reserving short codes for the most densely populated areas, mapcodes for addresses (i.e. places that people need to visit) are on average as short as theoretically possible, within the limits we set for ourselves. One such limit is to use only rectangular areas in our definitions. Another is to limit the size of the “context” data table to about 16,000 records. Probably the most relevant design choice was the choice of character set. For example, had we allowed both capital and lowercase letters, 3 times as many people could have 5-letter codes instead of 6-letter codes.

> The mapcode system allows about 100 km2 of a territory to be covered by 4-letter mapcodes. These are usually reserved for the capital city. About 6,000 km2 can be covered by 5-letter mapcodes . Roughly 250,000 km2 can be covered by 6-letter mapcodes. If a territory is larger than that, the remainder requires 7 letters. A few territories on Earth (notably, Australia, Brazil, Canada, China, India, Mexico, Russia and the USA) are large enough to merit 8 letters, but these actually consist of sub-contexts, i.e. people there live in a state, republic or oblast much like people elsewhere live in a country. Within such a sub-context, mapcodes are shorter.

[digikata]

Between this, and discussion of hardcoded magic values in lookup tables in the code, I wonder about how future population/geography shifts will be handled. It's not a dealbreaker, but it seems like a technical cost of interpreting mapcodes would be periodic required updates of the translation codes.

[Alupis]

Their own website is displaying/using MapCode's incorrectly.

For example, they have 0C.T4 and they say it's in Ireland and appears to be some bench in the picture.

However, if you use that MapCode, you will see it's the middle of some river in Amsterdam.

0C.T4 == 52.369764, 4.868898

Another:

81.J4W They seem to claim it's in Alaska, appears to be some road. However, it's another river in Amsterdam.

81.J4W == 52.508957, 4.769173

[lstamour]

Actually it's that those MapCodes are incomplete. They're missing the country/state designation. If you look up "Ireland 0C.T4" or "US-AK 0C.T4" you should get the correct results.

I'll cite a .doc file here, it's also available on the Developers page:

> 1. Codes only need to be accurate enough for public, every-day use. At the human scale, when you are within a few meters of a destination, you are “there”.

> 4. People live within a “country context”. Addresses seldom include a country name. Unless clearly stated otherwise, they can safely be assumed to be in “this” country. Codes that are known to be within a particular territory can be designed to be much shorter. For example, every location in The Netherlands can be uniquely specified with at most 6 letters . Even in a large country like India, at most 7 letters are needed.

> 6. Short codes are reserved for areas where the population density is high. For example, every locations in The Netherlands can be represented by a unique 6-letter mapcode. However, the majority of the population is concentrated in a dozen urban areas totaling less than 3,000 km2 (1,800 square miles). By reserving the 5-letter mapcodes for these areas, half the population of The Netherlands can be found using 5-letter codes. On average, mapcodes for relevant locations in The Netherlands are thus closer to 5 letters than to 6 letters. In fact, a significant percentage of the population can be found in 100 km2 of city centers, which can be covered by 4-letter mapcodes.

> Based on these ideas, we envisaged a system that would work anywhere on Earth, and would (on average) provide the shortest possible codes to everybody. By using massive amounts of data gathered over the past 30 years by mapping company Tele Atlas (merged into the TomTom Group in 2008), a data table was constructed ...

> Finally, on top of any and all national mapcodes a location may have, it also always has a 9-letter, context-less map code.

> To understand mapcode accuracy, you need to understand that a specific mapcode defines a specific location X, but represents all the locations within a certain distance meters of X. For example, the Dutch mapcode “49.4V” decodes into coordinate 52.376514, 4.908542. This does not only mean that coordinate 52.376514,4.908542 can be represented by mapcode 49.4V, but that all coordinates within roughly 5 meters of that coordinate can also be represented by mapcode 49.4V.

(it continues to describe "high-precision mapcodes")

Why did they make it?

> The mapcode system was revived and worked out in 2006 when TomTom decided to expand their operations to countries like India and China. It was difficult to sell navigation devices in these countries, among other things because a significant part of the population lives without address, lacking not just house numbers but often even street names, which often made it hard or even impossible to enter a destination. It was thought that the introduction of a simple and ubiquitous system for representing locations (and hence destinations) would in due time make navigation devices as welcome there as anywhere else.

[cabalamat]

> Actually it's that those MapCodes are incomplete. They're missing the country/state designation. If you look up "Ireland 0C.T4" or "US-AK 0C.T4" you should get the correct results.

Imagine if a URL resolved to different addresses in each country you were in. Would that be a better system than what we have now, or a worse one? I think it would self-evidently be worse.

I'm surprised they didn't make mapcodes a globally-unique identifier.

[cwp]

Globally-unique identifiers make sense on the web, where "going" to a website being served from the other side of the world is as easy as one served from across the street.

That's not true for navigation in the physical world. If you're sitting in Nebraska, how often do you have to navigate to a location in Mongolia? Approximately never! Map codes are optimized for the common case, where you want to go to a location that's nearby.

In fact, it's even more clever than that, since it defines "nearby" as a political unit. Borders may be artificial, but they're real, and crossing them has practical implications. If you're planning to buy something in another jurisdiction, there might be tax implications. You may need your passport to cross the border. You may not speak the language of that area. All of this means that having the political unit as a human-readable part of the map code is useful.

Finally, consider that some URLs do resolve differently depending on where you are. They're called relative URLs. They're very handy and very common. I'd guess that the vast majority of URLs on the web are relative. MapCodes work the same way. The code "Ireland 0C.T4" is globally unique. If you're already in Ireland, you can omit the territory, much as you would omit the country when inviting a friend to your house for dinner.

For cases where you really do have to travel to the other side of the planet, is it really so onerous to specify "Mongolia 0C.t4"?

[lstamour]

They did, it just doesn't suit the purpose they had: quick entry into GPS systems; it's true URLs or QR codes would work too, though nothing's stopping such a resolver service from popping up, except of course that non-phone GPS systems probably don't have cameras yet.

> Finally, on top of any and all national mapcodes a location may have, it also always has a 9-letter, context-less map code.

But that's too long to use every day... It would be like requiring all streets to have globally unique names. Because they're qualified by location, you could, if you wanted to, enumerate all matches in order of distance, and in 90% of cases, that would be the location you're looking for. Better here, since many cities will have the same street names in multiple places ;-)

[richardw]

Phone numbers are very similar. They have a short and long representation and the short is often duplicated in different countries. Imperfect but a very human solution: works because it's easy and 99% of the time we call the right number.

[Alupis]

Any reference to how they came up with any given Map Code? Like how 52.508957, 4.769173 became US-AK 81.J4W?

I see they have come up with them for all locations, but how can I take a given coordinate and surmise it's MapCode, or the reverse (without their API or website)?

[lstamour]

Goal #3 on their list was:

> A conversion need not just be based on formulae. A respectable amount of data may be used as part of an algorithm.

Which is why when you go to the downloads page, you'll find sources in C, JavaScript and Java, but they all include "data tables".

There are a few other restrictions, though it's somewhat unclear how relevant they are here without inspecting the tables closer:

> One such limit is to use only rectangular areas in our definitions. Another is to limit the size of the “context” data table to about 16,000 records.

So it's not something you can do without the data tables. And for ease of use, they have disambiguation routines for country/state input.

[Alupis]

Hmm, I just took a look at their Java SDK... (clearly just sample code, but intended for embedding into your project to get going quickly)

They make a lot of assumptions, and a lot of hard-coded values.

For example, they seem to have lots of city names and country names hard-coded into a giant String array. ISO country codes are hard-coded (probably a safe assumption so-long as new countries are not added), many "magic numbers".

Overall, I think these things are acceptable... but I don't necessarily like relying on the assumptions that "things today should be the same tomorrow". With plain old coordinates, my software would never care if the ISO added new country codes or what-have-you.

I see they intent this to be mainly for human consumption -- but is US-AK 81.J4W really any more memorable than 52.508957, 4.769173? I'd probably end up writing both down personally, which means the coordinates would suit me just fine.

[frankus]

81.JW4 is a lot easier to tell someone over the phone or transcribe from a business card or billboard, and it's pretty unlikely that the US-AK part would be ambiguous in those contexts. And if it is, a simple "which 81.JW4 did you mean?" would probably disambiguate pretty effectively.

[opium_tea]

Mapcodes also have to be combined with some context. In most places it's just the country name, but in large countries it also requires the state (or equivalent).

So if you go to the interactive map on the mapcodes site, there's a little link marked context and you need to change that to Ireland. Results in this:

http://www.mapcode.com/getcoords.html?iso3=125&mapcode=0C.T4...

[Alupis]

So, they want to throw out the old coordinates system (which was absolute location regardless of any "context"), with a system that if you loose the context information, or misinterpret it, you can wind up in a very wrong location?

I've written a fairly extensive GPS library for some embedded device projects in the past, and I can attest to the computer not caring about the long coordinate system, they are just floating points really.

[nandhp]

The shorter MapCodes are within the context of a specific country, but the "I have a MapCode" box defaults to the Netherlands. If you change that to Ireland, it's 0C.T4 is in the middle of a park near Dublin.

[apoorvai]

I think you need to change your "context" country. If I look for 0C.T4 in Ireland, I see green (implying a bench).

It looks like the mapcodes are country specific, and two countries can have the same mapcode.

[6d0debc071]

From the Mapcode System Reference Document:

http://www.mapcode.com/downloads.html

'Unfortunately, a large part of the world population has no address. In India alone, well over half a billion people live in houses that have no street name. Millions of man-hours are lost every day trying to locate or deliver goods to people and businesses based on business cards like this:

------------------------------------------------------

Amri Patel, consultant New Sun Technologies, District 14, Pune Tel. [phone]

Three miles east along the airport road, take second left past the golden statue, in the fourth street left ask final directions at baker across from white house.

Figure 1. Typical Indian Business Card

------------------------------------------------------

As we all know, even having an address is only an initial step in locating a position. Knowing someone lives on Queens’ Road 123 in Brunnock still requires you to find out where Brunnock is, and where the Queen’s Road is, and where number 123 is.

The mapcode system was designed as a free, brand-less, international standard that allows any location on the surface of the Earth to be represented by a short, easy to recognize and remember “code”, usually consisting of between 4 and 7 letters and digits.'

So, your point number 2 seems closest to what they're aiming for. Indeed, later in the document, they state:

'The longer a code gets, the more awkward it becomes to use, the more difficult to remember, the more easy to make mistakes in copying or using, the less benefit it offers over more elaborate descriptions. Many other benefits depend on mapcodes being short. If length was not a problem, we might as well put our longitude and latitude on business cards and address labels.'

> Also, won't there be multiple mapcodes for a single spot and won't that require cross-association of the respective metadata?

It seems like this corresponds to a coordinate system. You say what country you're in and then this gives you an aim point. I don't think you need to say 'it's in This, which is in This which...' :/

[jib]

Yep. Swedish post codes define mail delivery areas as well.

You can effectively sort on partials and get high accuracy.

For instance, the office I used to work in handled all of 421xx, 426xx and 436xx, as well as a few of the 430xx range.

Sorting was done by bucket sort (literally) on the top 3 digits in a central distribution location (all 5 for those like 430xx that was handled out of several offices), then distribution to each mail office, then another bucket sort on the full five digits, followed by another bucket sort on (roughly) street address, followed by a final sort on route.

This appears to lose all of that functionality.