GeoRSS Weblog

A couple of months ago, Yahoo! released the beta of their location brokering service, FireEagle. The service just recently came out of private beta and is now open to anyone to store and retrieve their current location.

One feature that was purposefully (so far) left out of FireEagle was getting a location history. Queries only return a unique XML markup of the user’s current location.

EagleFeed is a simple solution to this - it’s sole feature is providing a GeoRSS feed of your FireEagle location.

Since FireEagle allows a user to specify their location accuracy per application - you can choose to just provide a city or neighborhood level response to EagleFeed - making it a nice, variable granularity, location tracker.

Personally, I use it in my blog to provide a small badge on my location. Using SimplePie, a PHP RSS parser, I can easily pull in my location and do caching without having to deal with the complexities of OAuth for just a simple widget.

I’ve never really got into the whole Twittering thing, but I’m sure this will be of interest to some. I just came across GeoTwitter, which is an open source .NET code base that does what you think. Start here with the background details.

Flickr has had GeoRSS support for awhile, but it was subtle in that it used to require you to add &georss=1 to the end of feed URL’s.

Dan Catt recently announced on his blog that Flickr now puts the links to the GeoRSS and KML front and center.

Look for the geoFeed link in the RSS section at the bottom of a group or tag page. Dan’s example of UFO’s looks like http://api.flickr.com/services/feeds/geo/?tags=ufo&lang=en-us&format=rss_200.

What’s really neat now is if you mix Minimap Firefox plugin I mentioned earlier, drag and drop the GeoRSS feed from the Flickr tags into it, and now you can view a map of the Flickr photos in the sidebar while you browse the actual photos on the Flick Page.

I’m not sure why I had not noticed this before, but Jeremy Cothran has been working on ObsRSS and now, ObsKML as a means of managing geographically oriented observations from ocean observing platforms (i.e. buoys).

(Note that the links above will result in showing you some login dialogs. Just click “Cancel” twice and you can still see the pages.)

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”?

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.

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.

Dan Brickley of W3C Geo fame announced the formation of the W3C Geospatial Incubator Group.

One of the topics the group will be discussing is GeoRSS. This kind of brings the whole topic full circle, at least relative to W3C.

Note that “Non-Members may join W3C or ask the Chair of an Incubator Group to participate as an Invited Expert, subject to W3C’s policy for approval of Invited Experts” so you, too, could wangle a seat at this particular table.

This was also noted in the W3C News:
“2006-07-05: W3C is pleased to announce the creation of the Geospatial Incubator Group, whose mission is to begin addressing issues of location and geographical properties of resources for the Web of today and tomorrow. The group is sponsored by W3C Members the Open Geospatial Consortium, Oracle Corporation, SRI International, Stanford University, and the University of Southern California Information Sciences Institute (USC ISI). W3C Members may use this form to join the group. Read about the Incubator Activity, an initiative to foster development of emerging Web-related technologies.”

Adena at AllPoints noted that MapInfo will be supporting GeoRSS. The original article is at GISCafe Weekly.

Once again, no indication of which flavor they will be using. That’s something we still have to sort out.

In my presentation at Where 2.0, I warned that my brief survey of support would be out of date by the end of the conference. I talked to many folks about GeoRSS, and so many had plans to implement, cause it is simply so easy that not supporting it would be more work! Here’s a few GeoRSS developments I noticed coming out of Where..

• GeoTagThings, “a simple way to assign any web resource - anything with a url - a location in the normal, human physical world”, launched with GeoRSS support.
• Flagr added GeoRSS to its feeds.
• Plazes quietly added GeoRSS to some of its feeds, and has more complete support across their service in the works.
• VirtualEarth is pushing forward its support of GeoRSS, and has even reborrowed my borrowed hype about “GeoRSS as the Unix pipe of Geo data”
• Yahoo, at their lunch meetup, mentioned they are looking into GeoRSS export from their API .. a step towards unlocking data from all the AJAX based mashups out there, that I’ve been pushing for a while.