Archive for the ‘Applications’ category

Midori web browser supports “geo:” URIs

July 16th, 2012

The lightweight “Midori” web browser supports “geo:” URIs natively since version 0.3.6. Here’s the respective release announcement (from May 2011, only discovered now):

The browser extracts latitude and longitude from a geo: URI entered or clicked on, and redirects the user to the respective location on OpenStreetMap.

Very cool.

GeoSMS – “geo:” URIs in mobile short messages

October 6th, 2010

An initiative called “GeoSMS” proposes the use of “geo:” URIs in text messages (mobile short messages – SMS). This was actually a use case that i discussed with several IETF fellows during the development of the geo: URI specification – i’m happy that someone took the effort to write a formal specification.

The proposal got an amazing amount of press coverage, including articles on  New York Times, der Standard (german), Times of India, intomobile and various other news sites in the mobile and tech industry.

It’s nice to see how the design properties of the “geo:” URI (short, simple, human-readable) are the base for another simple and straightforward standard proposal. Let’s hope that mobile phone developers implement GeoSMS (and, hence “geo:” URIs) in their future products. The GeoSMS developers themselves have already created an Android application called “I am Here”. More details and the actual specification are available here:

GeoSMS – “geo:” URIs in text messages

RFC5870 – the “geo:” URI specification

“geo:” and SIP Location Conveyance

August 6th, 2010

“geo:” is getting more attention in other areas of the Internet Engineering Task Force. After the VCARDDAV working group has included “geo:” URIs in their revision of the vCard scheme, the SIPCORE working group is now discussing the use of “geo:” in their “Location Conveyance” draft.

SIP is the IETF’s protocol for establishing Realtime Application Sessions, and is very commonly used for Voice over IP. It has gained massive popularity in recent years, and is not just be used in VoIP-Software, but also in Public Branch Exchanges from various vendors, open source products such as Asterisk, Kamailio and a wide range of carrier products. SIP is the base for telephoney in the upcoming Next Generation networks such as LTE, and a major component of IMS systems. A good percentage of phone calls being routed between carriers as of today already uses SIP.

For those reasons, the IETF is looking into ways to embed location information into SIP messages. This is important for services such as Emergency Services, but can of course be used for any other realtime application that needs to transmit location information in its session setup. An example of that could be location conveyance between contacts in a social network, or applications for “checking in”, such as Gowalla and Foursquare.

The current version of the SIP Location Conveyance Specification uses “Content ID” URIs (besides “sip”/”sips”/”pres”) to refer from the new “Geolocation:” header to a MIME body part, which then contains the location embedded in a PIDF-LO Presence/Location document. Such a geolocation header (and respective body part) would look like this:

Geolocation: <>


   <?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"
        <dm:device id="point2d">
                <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                  <gml:pos>33.001111 -96.68142</gml:pos>

PIDF-LO allows for great flexibility of location types, can contain civic addresses, and extensive privacy rules. However, conveyance of a simple “point” type location could also be achieved by using the “geo:” URI in the Geolocation header directly as follows:

Geolocation: <geo:33.001111,-96.68142>

Which, obviously, would be much more compact, probably easier to parse, and not in the need of a seperate MIME body part.

However, the “geo:” URI specifically lacks privacy rules, because an URI itself does not identify a Target, but rather reflects just a physical location in space. In SIP Location Conveyance as a “GEOPRIV Using Protocol”, privacy is required.

There is currently a discussion going on the SIPCORE mailing list, and the proposal is that a “geo:” URI (when used in an “Geolocation” SIP header) would come with implicit default rules (currently under discussion whether those default rules would be GEOPRIV’s general default rules, or defaults specific to the use of “geo:” in the context of the “Geolocation:” header).

We’ll keep watching the discussion.

“geo:” and vCards

June 10th, 2010

vCard – the first spec to use “geo:”?

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):

FN:Simon Perreault

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.

Perl module URI::geo

April 28th, 2009

Andy Armstrong of hexten has created yet another implementation of the “geo” URI scheme – this time it’s CPAN module for all the Perl fans out there: URI::geo provides a class to create and parse “geo” URIs from within Perl scripts – a simple example to create a URI from latitude and longitude information looks like this:

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!

Android implements “geo” URI, IETF accepts draft specification

April 2nd, 2009

A new version of the “geo” URI specification was discussed at the IETF’s 74th meeting in San Francisco. As more and more applications pop up around the internet, the GEOPRIV working group recognized that there is definitely a need for a simple, short, but yet standardized way to refer to a spatial location.

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.

“geo:” URI JavaScript parser

March 12th, 2007

As another proof of concept I wrote a little “geo:” URI JavaScript parser.
Basically it scans all anchors in a given text for “geo:” links, extracts location and meta information (e.g. coordinates and corresponding text), places them on a map and appends the map to the text.

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.

Firefox extension handles “geo:” URI

February 26th, 2007

The first version of a firefox extension to handle geo-URIs is now available. The plugin uses a proxy to forward ‘geo:’ requests to a mapping service (currently Google Maps, we’re planning to make this configurable RSN).

(click screenshot to install)

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

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


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.