The Canadian Government proposes using GeoRSS for emergency notification in their Architecture for Situational Awareness Systems. The US-centric Environmental Information Exchange Network is also considering GeoRSS to expand their spatial data smarts beyond points.

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.

Joey Tracker is a nice little app for tracking the Tufts University shuttle bus. They’re running a real time tracking system from Ublip, and receiving updates on the location of the bus via GeoRSS, and mapping that with GMaps API. Nice.

InSTEDD is an “NGO Startup” formed by Larry Brilliant in 2006, focused on building and distributing innovative technology for humanitarian response. Dr. Brilliant is now the head of Google.org, which provided seed funding for the organization. InSTEDD emerged from a year of relative quiet, releasing some simple and elegant tools. Their approach so far appears to be reuse of the best of Web 2.0 for humanitarian response.

SMS Geo-Chat builds location based chat on top of SMS, with visualization in Google Earth, and wider distribution of data with GeoRSS (hence the posting here). This is developed further in Contacts Nearby, which leverages the multi-modal communication of Twitter and the social network of Facebook.

If this sounds just a little like TwitterVision, it’s not surprising, I reckon the influence is there and that’s a very good thing; the innovation and ideas in this field are out there, and what’s really needed is a channel to get the clever hacks into the hands of responders. We’ve discussed and worked with GeoRSS for disaster response for a couple years (National Geographic had a good summary in 2006). There’s been discussions of Twitter in dsiaster response since it’s launch; SMS is the last communication channel to go down in an emergency, and the first to come back up. And Twitter is multi-modal, easily connecting SMS potentially to any other channel. These ideas had a good workout during the San Diego fires.

Just a couple critiques. The format they used to encode location in Twitter is “lat*lon*message”; rather than the nanoformats (”l:lat,lon”) used in TwitterVision and Bangladesh Boat Journey. I think nanoformats are potentially more flexible and already being used, so why invent a new format. Also, I’m not sure why they chose ASP.net to code their projects in — are most humanitarian response organizations running msft products? Or is it because some of the core team come from Microsoft? Hopefully there’s scope for full open source solutions in the future.

Chris Holmes gives a good rant about being a good GeoRSS citizen.

Andres has declared today Let Others Know about RSS Day. It may not roll off the tongue, but I think you know what to do .. if you’ve seen the light of GeoRSS, pass it on and evangelise the greatness of RSS and GeoRSS to your uninitiated colleagues.

The nice thing is that enlightenment is usually quick, it takes only two minutes to explain what it’s all about!

GeoFeeder is a new tool making it very easy to convert proprietary and/or complicated GIS formats into GeoRSS. I don’t think there’s an simpler way to transform a ShapeFile into GeoRSS, which in the words of the GeoFeeder site is “the current defacto standard for web mapping”. It’s really cool to see a tool so clearly target GeoRSS.

There are other tools which do the same — notably Safe’s FME, which does support many more formats, including raster, but at a comparable increase in price. FME is built on gdal/ogr, open source and comparably more difficult to work with, and not yet supporting GeoRSS .. maybe we can do something about that at FOSS4G next week?

In this recent interview with Michael Jones at GCN, he was asked his opinion on GeoRSS,  and he’s positive, but unfortunately gives some wrong information.

JONES: I think GeoRSS is fabulous. We’re totally supportive of that. The only issue — and it’s not a problem — is that RSS is a very simple mechanism. It says here’s a fact and there’s a Web page that holds the information about that. It’s not the actual page itself. It doesn’t really have enough information to, say, draw a line around the toxic spill. You can imagine the questions that a program like Google Earth is going to need answered to draw the scene properly. We support GeoRSS and support KML, but we’d like a richer discourse, like a word processor where you could change the font.

GeoRSS supports four geometries: points, lines, polygons, boxes. It is most definitely possible to describe a toxic spill area in GeoRSS (or more summer-positively, a pretty field of wild berries).

The question about GeoRSS vs KML is a more subtle one. Yes, GeoRSS aims for simplicity, and KML allows richer descriptions. But really, it doesn’t matter to the GeoWeb; as long as the information is out there in a machine readable format, the GeoWeb is enriched. But certainly there are cases when GeoRSS or KML is more appropriate, and it depends on the publisher and the purpose.

Andrew has some thoughts on how GeoRSS and KML could work together. He simply sums it up as HTML : RSS :: KML : GeoRSS, which seems like a useful departure point for discussion.

Sean Gillies has been experimenting with a web service, Mush. It takes two GeoRSS feeds and calculates the “sphere of influence”, or spatial intersection, of the two feeds.

Perhaps it’s part of a trend (hopefully) for more “analytical” services in “neogeography”.

The Planning Alerts GeoRSS API was used as a clever example. In combination with a GeoRSS feed of Celtic coins, it shows areas where development activities might unearth more coins — actually sounds useful!

If you’re on the fence about picking up a new iPhone, consider that it supports GeoRSS out of the box!