[grey-area]

Objections:

1. This mapcode is country specific (!)

2. Many locations need altitude or fine lat,lon differences to differentiate them (e.g. blocks of flats, offices).

3. What's wrong with altitude, lat and lon on a given projection which can be as precise/imprecise as you want?

IMO it'd be better to have a hash of lat,lon,altitude which was globally unique for each level of precision.

A system like this needs to be globally unique without specifying country, or you may as well use a postcode. The only advantage over postcodes at present is it's slightly shorter.

[jisaacso]

There exists a hash of lat, long globally unique for each level of precision, a geohash [1]. One common application utilizes a space filling Hilbert curve to define an arbitrary precision bounding box around a set of coordinates. You can see an example hash [2].

[1] http://en.wikipedia.org/wiki/Geohash [2] http://geohash.org/9q8yyvfekk8h

[javadocmd]

If you'll pardon the reckless self-promotion, there's a few Java implementations to do Geohash calculations: https://code.google.com/p/simplelatlng/

[mxfh]

I'm pretty certain one could make a geohash compatible partly human readable hybrid that performs way better than this proprietary obscurity.

Something like DE.BERLIN.2.1H

First, human readable part defines a look-up to defined geohash of center of region on a given level.

So DE.BERLIN could resolve to u33, u33d or u33db (length/level 5) the last one seems reasonable, since a few multiples of the area cover the whole city of Berlin

http://geohash.2ch.to/u33db

Second, optional, part encodes offset of Z-Curve index of location at same zoom level.

Z-Curve on globe: http://www.bigdatamodeling.org/2013/01/intuitive-geohash.htm...

This enables global coverage at any level if needed, and makes the code robust to administrative changes that affect the area of the given region! The offset part could start at 1 and alternate the sign with each increment.

isOdd(offsetPart) ? -(offsetPart-1)/2 : offsetPart/2;

1 → 0, 2 → 1, 3 → -1, 4 → 2

An offset part of 1 equals an offset of 0 and could be omitted.

The third part adds to the precision of that given cell.

Brandenburg Gate, within area of origin cell of region part. could be written as DE.BERLIN.1.2M3 or short DE.BERLIN.2M3

http://geohash.2ch.to/u33db2m3

DE.Berlin.2.1H would be the area and center point of the Berliner Fernsehturm with sufficient accuracy u33db + 1 = u33dc

http://geohash.2ch.to/u33dc1h

This example uses base 32 to comply with geohash but other more error robust encodings and variations (e.g. second part as base ten numerals) could be used as well.

Add optional checksum part based on unshortened geohash if needed to verify integrity.

Variants: since geohash, covers a varying amount of area depending on the latitude. A similiar approach could be realized on a UTM based grid like MGRS if a precise area is required (https://en.wikipedia.org/wiki/MGRS)

[grey-area]

I reckon you need to include latitude as well, or it's not really going to be useful for specifying position in cities.

[sp332]

It's a bit buried, but only some of the mapcodes are country-specific. "Every location on Earth has an "international" mapcode, completely independent of territorial borders. So any location that has a national mapcode also has an international mapcode." http://www.mapcode.com/popup_alts.html