Just a bit than one year ago the Internet Engineering Task Force has released the RFC5870 that specifies how references to locations have to be written in the URI scheme. This basically provides a technical standard for sharing locations in a human and machine readable way. This is extremely cool because now you  can embed references to locations in space just like you would link normal HTML documents.

This standard is an important step to move location-based services from prototypes to the mainstream. In this article I outline a few ideas how existing web-solutions can lead to new usages using this standard.  

Why are URIs so important?

URI is the acronym for Uniform Resource Identifier a slightly more general form of the famous URL (uniform resource locator). Everybody knows that URLs are basically the backbone of the Word Wide Web. Without a standardized format for defining the location of a document on the internet it would be impossible to create hyperlinks in the generic way as we got used to do today. Therefore both URIs and URLs are very important to identify and locate resources. 

The best thing about these identifiers is that the format is standardized. Thanks to the WWW this format got so common that most people can understand the basic information when they see it. Even more importantly, information systems can provide generic "parsers" that can read the information and connect appropriate activities to them. This enables to build complex systems based on the same technological principles. 

For example, all web-browsers allow users to enter URLs in the location bar. Commonly, such a URL starts with http: (unsecured hypertext protocol) or https: (secured hypertext protocol) followed by a reference to the location of the resource. The first bit is important, because it tells the browser that the requested information is something it should handle itself. Alternatively and also very common is the ftp: prefix. This tells the web-browser that the information is not on the Web but in a file repository. Today this is often handled by your browsers as well, but not too long ago one needed a different program for accessing file repositories using the file transfer protocol (FTP). Through the ftp:-prefix in a link your web-browser can identify if it is able to handle a link or if it needs to start  a different software. In order to do so your FTP software tells web-browsers that it can handle a certain type of links associated to a specific prefix.

Skype uses a similar trick for linking Skype information into web-pages. It informs the web-browsers that it can handle the skype: prefix. If you visit a web-page with a skype link from a device with skype installed, you will find that your skype client pops up and tries to call the linked contact when you click on the link.

However, with standardized URI formats you do not only gain flexibility over choosing capable software for link handling, but you also get precise details how to interpret the rest of the information that is provided in the link (which is not the case for skype links, for instance).  

Locations as resources

While it is possible to link to resources, such as documents, audio-files, or videos, or to services, such as Google maps, twitter, or delicious, it was not possible to link  locations in a generic way, compact and machine-readable manner.

The common approach for linking to locations is to link to a Mapping service. The main drawback is that no two of these services share the same format for referring to locations. Therefore, using link to a mapping service is not really a reference to a location, rather than to the information of that mapping service for that location. Furthermore, the format for linking locations is bound to the data-formats and protocols of the underlying service - are typically not compact and easy to understand, as the geo URI RFC points out in its introduction. 

However, locations share many characteristics with resources, such as documents or videos.

First of all, locations refer to resources in a physical way. For example, if you visit the Eifel Tower in Paris, the Funkturm in Berlin, or the Golden Gate Bridge in SF, you will experience the presence of the resource steel in its functional industrialized form. 

Secondly, locations have functions. All culturally related locations are functional. A bio-technology laboratory offers different functions and acting opportunities than a open space office, a Garden allows different kinds of actions than they are possible at gas-station, or a restaurant serves a different function than a factory. 

Thirdly, locations serve as information resources. In the most basic sense this means that certain things can be observed at specific locations. For example, cave drawings can be best observed in their original location such as the Chauvet Cave (although the access is limited) or the Louvre for studying the Mona Lisa. Another view on locations as information resources is described already in the classic rhetoric. In this context, locations are anchors for other information - that are made available through the location (or referring to the location). In terms of contemporary technology this would be called "augmented reality". 

Finally, locations are identifiable through reference systems. For identifying locations, we use reference systems. This could be linear or spherical coordinate systems. Geographic locations refer usually to the spherical system of longitude and latitude. With these two dimensions it is possible to identify places on the surface of our planet. When you include the third parameter altitude you can describe every location on our globe. Altitude can be important if you need to differentiate locations at street level from locations on the 25th floor in a Manhattan Skyscraper. 

How does geo URI work?

The idea of geo URI is that we need a simple and compact way to pass around references to locations that plays along nicely with other references, namely URLs. Such a reference form was missing, because other semantics for geo-spacial information is not suitable for using them with HTML href-attributes or XML's XLink syntax. Therefore, geo URI aims for a compact pointer to geo-locations that is as simple as a reference to any other resource on the web. 

The first part of geo URI is the geo prefix. This allows a software to recognize that the following information is related to a geographic location.

The prefix is followed by the coordinates of the location separated by commas. The first coordinate refers to the latitude, the second coordinate to the longitude and the third coordinate to the meters above sea level (altitude). Additionally, geo URIs can have additional parameters. These parameters are separated with semicolons from the location. geo URI reserves the parameters 'u' (uncertainty) and 'crs' (coordinate reference system). crs parameter is only of interest if you visit different planets, so in most cases this can be ignored. the u parameter describes the radius of a circle around the point mentioned. This allows to describe the area around a point or to indicate the uncertainty of a measuring instrument (like my iPhone that hardly ever gets better than 10m). An application may decide to use additional parameters in a geo URI to provide additional information to the application. However, because this information is outside of the specification this information might be ignored. 

In the simplest form a geo URI contains only the latitude and the longitude. 

geo:50.87783,5.958737 

This URI points to the Chiba building of the Open University of the Netherlands.

You notice, that this URI lacks of a bunch of slashes that we are used to see in http URLs. The famous two slashes in an internet URL inform a browser that the following part refers to a location on a server on the internet using TCP/IP. Geographic coordinates have nothing to do with Internet protocols and therefore don't need the additional slashes. 

Of course providing a single point is not really the best solution for describing a building, because a building takes space and is not a point. In order to indicate that something is around a certain point you can indicate that you really mean the space around a point by indicating the uncertainty in meters. Lets assume 40m uncertainty to match me within the building (and a bit around it).

geo:50.87783,5.958737;u=40

geo:50.87783,5.958737,108;u=40

With this basic information I can do already quite some interesting things. However, by adding additional information I could provide additional information in a custom parameter to the application that could enrich the user experience.

geo:50.87783,5.958737,108;u=40;room=Chi-1.28

This really goes too far, because the truth is that this room does not help you a lot, because I don't have a fixed office in the first place.

Now I can use this nice URI to link the location of the CELSTEC laboratories just as I would link any other resource on the internet, as the following example shows.

<a href="geo:50.87783,5.958737,108;u=40">CELSTEC Laboratories</a> 

Conclusions

The geo URI specification is still fresh and so far not many applications provide native support for these URIs. However, the simple format allows to embed geo location information just as normal hyper-textual references. This provides the power to extend existing web-applications with location awareness without binding these applications to a specific geo information service.