I'm a little confused about what this replaces, but it's definitely <i>not</i> postcodes.<p>* 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.<p>* 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.<p>* 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.<p>* 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.<p>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.<p>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.).