GeoRSS Weblog

GeoRSS has gained a large acceptance in the geo-community and is being implemented and used in many desktop and web-based tools. As is probably to be expected, currently georss:point is the most commonly used element, as it is very simple to understand, obtain data, and consume. It’s safe to assume that line, box, and polygon will start becoming more used as the tools become more mature.

However, a part of the GeoRSS spec that has not gained much attention, and very little if any actual implementation, are the additional metadata that can be used to associate the geometry to the RSS item. I’m speaking of relationshiptag and featuretypetag.

Based on the standard model, they are defined as:

Feature Type Tag

GeoRSS geometry is meant to represent a real feature of the Earth’s surface. The GeoRSS model allows for a single string containing a featuretypetag. No constraints are placed on this string. The intent is to allow a Feature Type folksonomy to emerge. The default is “location”.

Relationship Tag

GeoRSS is a way of relating Web content to Earth features. The GeoRSS model allows for a single string containing a relationshiptag. No constraints are placed on this string. The intent is to allow a relationship folksonomy to emerge.The default relationship, “is-located-at” simply indicates that the subject of the content is located at the GeoRSS feature.

These definitions are rather generic and offer little help as to best practices for these tags. Josh Lieberman is heading up a W3C Working group on updating the Geo Vocabulary to support tagging and metadata between GeoRSS, RDF, SemanticWeb, et al. However, it’s a rather broad canvas to start putting ideas to and implementing.

Mikel proposed using the relationshiptag for image overlays using the tag “image-extent-is”. Josh pointed out that relationshiptag can be useful for defining parts of an otherwise very large entity, such as “summit-of” “mountain”. This could be useful for other sub-locations such as “trailhead”, “entrance”, or “former-location-of”

As for featuretypetag there is the RFC4589: Location Types Registry that provides a standard list of location names and their definitions. This includes names like: airport, hospital, residence, or school.

It seems imperative to begin defining a standard dictionary of tags that are expected in the relationshiptag and featuretypetag GeoRSS elements. While folksonomic tagging can exhibit new and interesting relationships, it also makes interconnecting these tags with user-based idioms difficult. How else does someone “find all the restaurants in my area”?

Loads of GeoRSS developments this week .. only just keeping up!

• Map24 GeoRSS Service provides a basic implementation of GeoRSS Simple visualization. via All Points Blog
• The Hindu Newspaper devotes a column to GeoRSS. via All Points Blog
• OgleEarth suggests integration opportunties for Google Earth, and GeoRSS pops up a bunch of times.

Midgard, a very full-featured CMS that is being used to replace Maemo.org has added a lot of functionality for supporting publishing & consuming GeoRSS.

Check out the Midgard’s Position module which uses a very nice PHP geographic position library. Midgard also uses RSSCreator with some geo modifications.

You can see an example of a GeoCMS built using Midgard by checking out the DeathMonkey motor cycle tour site.

Schuyler Erle announced today a new release candidate for the open-source javascript mapping library, OpenLayers. This new version adds support for displaying GeoRSS Atom Simple points. This feature was added by Sean Gilles.

Using this feature, displaying GeoRSS is as simple as adding a new layer to an OpenLayers map. All current points in the GeoRSS feed are then displayed as markers with the item description in the marker popup. consuming GeoRSS doesn’t get much simpler.

See the Release Notes for more notes and added features.

[Update: Fixed spelling of Schuyler’s name]

National Geographic has a new story about using GeoRSS: Disaster Prediction, Social Networking Boosted by Geo-Data Feeds.

In particular, it covers how GeoRSS can enable environment monitoring and notifications.

Note: it should be Raj Singh, not Ray Singh.

The content management system Drupal now has the ability to consume and produce GeoRSS.

Dan Karran released a GeoRSS module that plugs into Drupal. He also developed a plugin that supports KML for use in GoogleEarth. These modules are part of a Geospatial Content Management System (GeoCMS) demonstration system.

This project is very exciting as it is an excellent demonstration of large sites using Content Management Systems the benefits and ease of sharing and producing geospatial information.

Find out more about the plugin, and download it, from the Drupal site.

At FOSS4G, Raj Singh announced the official release of GeoRSS v1.0 this morning on the GeoRSS mailing list, and Mikel Maron presented it during his session, “What’s Next, GeoRSS”. You can see the official version release page at http://www.georss.org/1/. It’s a single page that can be referred to or printed for your archiving.

Aaron Roller of Motionbased (a cool subsidiary of Garmin) has written a very good, critical post on GeoRSS. They have just added GeoRSS feeds to Motionbased, which is great, but he has found the variations of GeoRSS confusing and frustrating. He illustrates the point with an example RSS item containing four different GeoRSS Point flavors — Simple, GML, W3C “formal” (contained with a <geo:Point>) and “casual”.

This is the most common complaint with GeoRSS, both from developers working with the format and even the wide group of people who have developed it. The last thing we want is to fracture GeoRSS in the same the RSS has been.

There are two main points I think GeoRSS.org needs to get across. First, publishers should not carry the burden of publishing in all the various flavors. Pick either Simple or GML, whatever is more appropriate for your application, and stick with that. Consumer and aggregators will be able to handle what you throw at them. Second, the W3C is aiming to resolve the differences with GeoRSS and the Geo Vocabulary with the Geospatial Incubator Group. This work should provide more clarity to the web at large.

Aaron also mentions “people at Where 2.0 were harrassing Google as if they are some sort of monster sticking to a proprietary format”. That’s me . Well I will definitely admit to some pokes and prods (like MGeoRSS, which I’ve just updated to support GeoRSS Simple Points), but with good intentions. I believe Google has everything to gain by supporting GeoRSS as Yahoo, Microsoft, ESRI, Garmin (through MotionBased), and myriads of others, are making moves to do. KML is great, but I think GeoRSS fits a different need, and really does excel through open development.

In a press release today, ESRI announced support for GeoRSS in their new ArcWeb Services JavaScript API. Welcome to Web 2.0 ESRI!

Seen on the Geospatial Semantic Web Blog…

Mikel has combined Kiva.org’s RSS feed of loan applications and some GeoNames services to generate GeoRSS which he then plots on a Mapufacture map.