学步园

GeoRSS is beginning its life as a well defined standard. With surging interest, especially following Yahoo!’s support of the format last summer, and recognition of the key role that any common data interchange format will have in the ‘Geospatial Web’, an informal working group coalesced together to focus all the emergent activity. A motley group of OGC standard bearers, Semantic Web enthusiasts, RSS & map hackers, and GIS pros, engaged in open discussion to conceive, extend, resolve ambiguities, and flesh out common and best practices. This article traces how GeoRSS developed, the current results, and where we see GeoRSS heading in the Geospatial Web.

Where We’re Coming From

The chaotic development of RSS (1.0, 2.0 and Atom syndication) has given rise to a free wheeling environment of bottom up innovation. Originally intended to syndicate news and weblogs, the extensibility, ubiquity, and simplicity led to RSS repurposed as a default way to transport content over the web, for podcasts, events and reviews, to name a few. Ray Ozzie, CTO of Microsoft, calls RSS “the UNIX pipe of the internet”. This technique of overloading RSS is sometimes thought of as Structured Blogging.

In early 2003, hacker discussions looked at a simple way to embed location in RSS. The W3C RDF interest group had recently published a simple way to express latitude and longitude coordinates in RDF, gathered from many examples already in the wild. This was applied as an RSS extension to add location to an RSS item. This format was adopted by worldKit, an easy to use web mapping application (and my own personal project, now open source), to represent map annotations. RSS insured relatively easy creation by non-specialists, and integration with many weblog and CMS programs already producing RSS. Subsequently many low profile publishers, and a few high profile organizations like the USGS and European Commission, began publishing GeoRSS. When Yahoo went looking for a data format for version 1 of their maps API, GeoRSS was the only common format suitable for representing map annotations.

A proposed GeoRSS subscription button.

There are of course other geodata formats in use, which deserve a look as alternatives to GeoRSS. KML is used in Google Earth, and loads of data layers have been published by an active community. However, KML is very tied to its application, with features specifically aimed for 3D spinny globes, and the spec is controlled by a single organization. GPX, for data interchange between GPS units, is again very tied to specifics of GPS units. GML is a feature rich vocabulary for encoding geographic information, but its complexity has been daunting for unversed developers, and its proper use misunderstood. GML is similar to RDF, defining a number of primitive objects that can be assembled into Profiles for particular purposes. In fact, a GML profile for GeoRSS is a result of the new standard.

georss.org

The group that formed to work on GeoRSS brought several technical philosophies to the table. From the OGC and GIS centered side of things, the need was to retain the rigor contained in GML definitions, while still simplifying to address the needs of 90% of people’s needs. Web developers’ experience showed that adoption of specifications is led by quick comprehension of the core of the idea. GML can be verbose, and it’s hard for the up and coming map hacker to see the rational, for example, in using four child tags to represent a polygon; a <gml:Polygon> is constructed that way for good reason, but it’s hard to perceive that without a bit of education. A compromise bridged these positions well.

GeoRSS can be expressed in two encodings, GML and Simple. Both express the same core concepts of GeoRSS, and can both be serialized in various flavors of RSS, or RDF, or XHTML. Through a common conceptual model, the serializations are easily mapped and converted into other variations if necessary.

The GeoRSS Model

GeoRSS describes a way to associate geometry with a chunk of content. The GeoRSS model uses four geometric shapes: “point”, “line”, “polygon” and “box”. The coordinate reference is assumed to be WGS84. Altitude can be expressed in one of two ways: an “elev” tag specifies the height in meters about the WGS84 CRS, as is common in GPS devices, and “floor” designates the floor number in a building (the floor numbering system is assumed to be the one local to that building). "radius" indicates the size in meters of a radius or buffer around a geometry object, for example, radius of circular area around a point geometry. Initially, GeoRSS contained a “circle” geometry, but due to difficulty for mapping clients to accurately project a circle on a map, “radius” is a less formal way to specify the same idea. “featuretypetag” and “relationshiptag” are free-form strings to define the type of feature the geometry describes, and how the RSS content relates to the feature. For example, the feature could describe the boundaries of an election district, with the relationship being the current elected representative for that district. Rather than attempt the near impossible task of building a formal ontology for these attributes, a folksonomic approach is taken (ie, let the web figure it out).

The GML encoding consists of a container element in the georss namespace (“georss:where”), with gml child elements. This is syntactically correct GML, so the geometries can easily be extracted by a GML aware application. In Simple GeoRSS, each geometric shape is represented a single element (“georss:point”, “georss:line”, etc), only containing the coordinate pairs. In both, coordinates are specified as “latitude longitude”, as in common usage; and only space separated, as commas are used in some languages to signify the decimal point.

The “geo” namespace is of course quite commonly produced and supported, and will continue to be for some time. To differentiate, that serialization is referred to as W3C GeoRSS. While the new GeoRSS serializations are very much encouraged, it is definitely recommended that GeoRSS parsers continue to support W3C Geo.

The result is a specification approachable by both GIS professionals and web developers, and is now making its way towards an official OGC specification. GML is given wider exposure on the web, for those who may need to express more complicated geometries than available in GeoRSS; and GIS is given entry to the robust ecosystem of RSS services. The core tools and libraries are already being developed to handle both variations, so developers are free to choose whichever format best suits their application.

A word or two on the “GeoRSS” moniker and namespace. It has gained wide recognition fairly quickly, and proven useful in communication. However, it is not intended strictly for RSS. Atom, RDF, and XHTML microformats can all make use of the GeoRSS model and serializations. The “georss” label for the namespace is not ideal, and some have made efforts to start a W3C Incubator Activity to fold the GeoRSS concepts into the “geo” namespace; however, “georss” is already very much in the wild, and it may be too late to change the namespace now.

Support

A standard is only worth something when it gets put to use. Even in these early days, GeoRSS has received a warm welcome, many notes of intention, and even some implementations.

Many of the open source web mapping tools are developing or released GeoRSS support. This includes MapBuilder, OpenLayers, and worldKit clients, the WorldWind 3d globe, and the GeoServer publisher. FoFRedux is an open source RSS feed reader, now with support to visualize GeoRSS. There is work proceeding on a WordPress plugin, an extension for the Java Rome library, and tests in the RSS feed validator.

Microsoft has announced intention to support GeoRSS in their suite of web mapping products. Microsoft is currently innovating heavily with RSS and microformats, so this should be interesting. Yahoo has also signaled interest, and of course if a big supporter of W3C GeoRSS with their mapping api, and GeoRSS feeds of weather, traffic, and upcoming events. An experimental mobile app from Yahoo called Checkmates layers GeoRSS feeds on phones.

Google is the enigma of the big 3. Many interpreted Google joining the OGC as a signal of interest in GeoRSS, but nothing definite has been voiced. Some hackers have taken matters into their own hands, and implemented extensions to Google’s products to support GeoRSS. MGeoRSS (another project of mine) is an extension to the GMaps API, and a challenge to Google to implement it in the main code. The Acme GeoRSS viewer mirrors support for Yahoo Maps API in Google Maps. GeoRSS2KML will load feeds in Google Earth.

Other commercial implementors are Ning, the social web development community, which supports GeoRSS in its applications, and CadCorp, a suite of OGC compliant GIS tools for Windows.

Edit monitoring app for GeoNames.org built with GeoRSS

Among the first publishers are Geograph, a collaborative photography project, the Platial social atlas, the OpenStreetMap collaborative street map, & GeoNames, a publicly editable gazateer. The GeoNames recent changes GeoRSS feed has been visualized with a simple configuration of worldKit which produces a real time wiki monitoring app. And of course, the many many publishers of W3C GeoRSS publishers, such as those featured at Yahoo and worldKit, will continue to be relevant.

In truth, it’s already impossible to keep track of all the activity around GeoRSS. GeoRSS is out and wild.

Possibilities

What does a GeoRSS enabled Geospatial Web look like? An easy way to build web mashups is good, but certainly there’s more. What killer apps are going to emerge? Here’s some ideas on what could be.

One example already exists, built on W3C GeoRSS. Over two years ago, the USGS began publishing GeoRSS earthquake alerts. Following the Asian Tsunami, the Joint Research Centre at the European Commission built a real time tsunami alert system, by triggering an online tsunami simulation based on USGS published earthquake events, then publishing the results for subscription and visualization in GeoRSS. Soon after, the JRC and several UN humanitarian aid agencies began cooperation on construction of a common alert and coordination system for natural disasters, GDACS. Information from several separate organizations needed to be gathered, processed and republished. They chose to use GeoRSS, with the addition of their own domain specific extensions. RSS was simply the fastest way they could come to agreement, and get on with their crucial work.

Visualization of a Tsunami model from GeoRSS

Aggregation is a crucial component in the RSS ecosystem, so expect Geo aware RSS aggregators to be a powerful tool. Users and developers will be able to layer numerous sources of GeoRSS and search RSS with a particular location. Think of it a true web native GIS. Following the GMaps API, many services have sprung up to enable users to easily build their own maps without any programming. Among Wayfaring, Platial, Tagzania, Plazes, and the rest, there’s a desire to tear down their walled gardens early on and share their user contributed data. GeoRSS aggregation could be the key here. Keep an eye on mapufacture for more developments in aggregation (an effort I’m involved in).

Time is expected to become more core to mapping and GIS. With the world changing at an ever faster pace, tools to visualize and come to grips with how places change over time will be crucial. With GeoRSS, time comes for free, as every RSS item has a timestamp. worldKit utilizes time in RSS to visualize population change and the spread of avian flu.

Finally, the Big 3 APIs could make a further move to boost the Geospatial Web. Currently there’s no way to extract the geodata from a Google, Yahoo or Microsoft map mashup; it’s all locked away in Javascript. It’s ironic, since map mashups are the poster child for open Web 2.0 data. The GeoRSS extraction hack in Google Maps Hacks (I contributed this) is one experiment at unlocking mashup data, but not really for widespread use. What would be killer is the APIs themselves publishing GeoRSS from any of their mashups. Due to browser constraints, a microformat implementing GeoRSS would be most appropriate for this task.

Beyond this, the future is open and exciting, and what I’ve covered here probably already yesterday’s news. Have fun!