The first specification that is using the “geo:” scheme seems to be the revision of the vCard format. vCards are “virtual business cards”, and contain a multitude of contact information about a person or an organization.

vCard GEO property

The geographic location of a person’s office is of course one of those properties – even the original specification of vCard (RFC 2426) contained an “GEO” property (defined in Section 3.4.2). That property has a range of shortcomings:

• There’s no way to specify altitude
• the Coordinate Reference System is not defined (see here [PDF] why you should care)
• Recommends to always use six decimal places (roughly one meter) rather than allowing for uncertainty values

New revision of vCard includes “geo:” URI

The current revision of the vCard specification (currently worked on in the IETF’s VCARDDAV working group) has changed the format of the “GEO” property. The new definition requires a URI rather than the lat/lon tupel as value, and notes in an example that the “geo:” URI scheme is “particularly well-suited”, although other URI schemes are allowed too. A example vCard using the “geo:” URI looks like this (edited for brevity):

BEGIN:VCARD
VERSION:4.0
FN:Simon Perreault
...
GEO;TYPE=work:geo:46.772673,-71.282945
...
CLASS:PUBLIC
END:VCARD

As outlined above, the structure of vCards allows to supply parameters for properties – in the example above, the GEO property is specified for the “work” location of the contact.

vCard applications become geo: aware

The integration of the URI scheme into the very popular vCard format means that very likely future revisions of vCard applications will be able to parse and use “geo:” URIs. Looking at the list of applications that support vCards, it looks like a bright future for our newly-born URI scheme.

RFC 5870 (“A Uniform Resource Identifier for Geographic Locations”) has finally been published by the Internet Engineering Task Force as “Proposed Standard”. The RFC contains the final, stable and approved IETF specification of the “geo” URI scheme – the 23 pages document is the result of 3 years of hard work, several presentations at IETF meetings, hundreds of email conversations about protocol details, discussing the proposal again and again, and – finally – interacting with not just one, but two sets of Area Directors in the IESG (Approval was perfectly timed with the end of the term of several Area Directors, so it had to be reviewed by the incoming IESG members as well).

Now that the “blueprint” part of the URI scheme is done, we’re looking forward to applications actually using the “geo” scheme (besides the ones we know of already). The URI scheme will also very likely see adoption in other IETF documents. If you know of an application that you think should support the “geo” URI scheme – let us know.

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!

use URI::geo;

my $guri = URI::geo->new( { lat => 55, lon => -1 } );

The current module version 0.0.4 is available from CPAN here, API documentation can be found here.

Andy, thanks for implementing and getting the module into CPAN!

Following the 20 minute presentation of the new draft version (which primarily incorporated some clarifications regarding WGS84, and the semantics of coordinates reflecting the poles), the working group was asked whether it would want to accept the “geo” URI draft as an official working group item.

The draft was accepted with overwhelming concensus, and will soon be renamed to reflect the working group adoption. That also means we’re a big step closer towards publication of the document as a draft standard RFC.
In other news, an esteemed colleage of mine discovered that Google’s mobile operating system “Android” already supports the “geo” URI! So anybody who happens to use such a phone (or has installed the emulator) can already make use of web pages containing “geo” URIs – once they are clicked, the phone starts the mapping application, and pans to the location indicated in the URI.

This is the first wide-spread implementation we’re aware of – see the relevant API documentation page. We’re quite excited, and looking forward to more platforms containing early implementations of the URI scheme.

The new version 01 (which is the second version after 00) removes the “query” part of the URI, as this was pretty much underspecified in the initial version, and has proven to be rather controversial. Since it does not actually identify the spatial location, but provides meta information (like location classification & type, preferred map scale) we decided to remove it from the specification.

Please note that this is work in progress, which also means that any feedback is appreciated.

The geo: URI proposal is on the agenda of tomorrows session of the Geographic Location/Privacy working group:

• GEOPRIV WG meeting
• March 22, 2007, 9:00 – 11:30
• IETF 68, Hilton Hotel Prague, Room “Congress I”

According to the agenda, the presentation of the “geo” URI scheme is scheduled for about 10:55.

For remote participation, session audio will be available via the IETF audio streaming effort (Channel 1), a supplemental Jabber discussion room at geopriv@jabber.ietf.org can be used as a backchannel for remote participants to ask questions and provide feedback.

Slides of the presentation

I choose to go with a Google Map because I already knew the API, so it was the easiest way. Of course one could modify the script to use any other mapping API’s, create a KML or even transfer the data to a GIS application. If I can free some time in the next weeks I’ll spice the script a little up, some more user defined parameters (e.g. map dimension, marker symbols) and the interpretation of query arguments would be nice though.

See a quick example here: the locations of a few cultural venues are marked with “geo:” anchors, scanned by the script and dynamically shown in the map below.

However, if you’re interested you can download the JavaScript file here. You’ll need a copy of jQuery (I used version 1.1.2) and a valid Google Maps key for your domain too. Then just add the corresponding 3 script elements (Google key, jQuery and geouriparser.js) into the head of your document and let the script find and display the geoURIs in your text.

The idea is heavily inspired by Gutenkarte, a presentation of MetaCarta Labs I remembered from last year’s Where 2.0 conference. Gutenkarte is based on MetaCarta’s Geoparser API, which is of course far more complex than my few lines JavaSrcipt code.

(click screenshot to install)

The extension should be compatible with Firefox 1.5 and above – You might need to allow software installations from “p.geouri.org”, and firefox will need to be restarted.

After installation, clicking on the following link should bring up a map of Vienna’s city centre:

geo:48.208333,16.372778

As usual, feedback is appreciated – please note that this extension is currently at a “proof of concept” level, subsequent versions will provide more choice of mapping services via a configuration option. The extension should detect new versions automatically as we release them.

The draft specifies syntax, format and semantics of the “geo” URI – it also requests registration of the respective Uniform Resource Identifier scheme (“geo:”) from IANA.

The draft will be presented during the session of the GEOPRIV (“geographic location and privacy“) working group on the 68th IETF meeting, taking place March 18-23, 2007 in Prague. The GEOPRIV session is currently scheduled for Tuesday, March 20, 0900 – 1130. Audio streaming will be available from here.

Comments and feedback on the Internet Draft is appreciated.