Great news for the standardization of the “geo:” URI scheme: After three years of hard work, the Internet Draft describing the URI scheme was approved by the IESG on April 16th 2010. This means that the most important hurdle for “geo:” to become a (Proposed Standard) RFC has been taken.
It will take another 3 – 4 months for the document to be edited and a final RFC number to be assigned. But with the approval of the document, the current specification is stable, and can be used as a draft reference for implementations
There are currently two implementations of the “geo:” URI scheme out:
- Andy Armstrong has written a “geo:” Perl Module available through CPAN.
- The mobile Operating System “Android” contains support for the “geo:” URI out of the box (API Documentation) – unfortunately it’s not fully compliant to the latest specs. However, this is particularly exciting because it’s out there in millions of devices.
The specification is also already being used in other IETF work: For example, the updated vCard Specification recommends to use “geo:” URIs for the GEO property of vCards, and i’m sure we’ll be seeing “geo” URIs pop up in other specifications as well!
Good to know there are some implementations already. I’m planning to add support for Emerillon and it will probably end up being a glib based library for parsing them, so expect news about it soon 😉
DeeJay,
thanks for the information – that’s good news. Let me know if you need help with understanding the specification – it should be an RFC in about one or two months.
Alex
Just a query about Android’s implementation. You mention it’s not fully compliant, but are there any “deal-breakers” in their implementation that you know of?
Hello PacoBell,
the Android implementation was done off a very early version of the spec. Android’s specification is here:
http://developer.android.com/guide/appendix/g-app-intents.html
The basic “geo:longitude,latitude†structure is identical, however, they neither support the altitude component, nor URI parameters (like “u†for uncertainty, and “crs†for alternative coordinate reference systems). On the other hand, they support some proprietory “z†(Zoom) parameter (which is very Google-Maps-centriy, and could be easily calculated from the uncertainty value, btw), and they support query strings, which is not included in the “geo:â€, which was never included in the “geo:” URI specification – it was discussed, but decided against in the IETF.
Thank, Alex. Yeah, I saw something about Google’s proprietary query string extension from a message board posting while…googling. It’s unfortunate that they decided to roll their own “zoom” parameter as uncertainty sounds much like a better generalized solution. The real downer for me was hearing about the lack of the altitude component. We live in a 3D world and can’t always assume the altitude is set to ground level. Then again, most mobile GPS receivers report altitude with an uncertainty of several tens of meters, anyway. This would need to be corrected with a calibrated barometric sensor or, at the very least, some sort of correctional table. Still, I would love see all these wonderful features implemented in a geocaching app some time (I’m looking @ you c:geo!) Congrats on the stable spec and I hope it achieves rapid adoption in the market.