I’ve meant to dig into Yahoo’s new support of GeoRSS since the announcement in September.
Two cool improvements. They have GeoRSS export and polylines in GeoRSS!
Annotations purely in code denies other developers and the entire Geospatial Web of that data. For instance, Housing Maps put work into geolocating Craigslist housing ads, freeing and transforming that data, but if someone else wants to build on that, say combine Housing Maps with Chicago Crime, they can’t leverage any of that work and have to start from scratch, building screenscrapers, etc. GeoRSS is designed to fully liberate data.
Yahoo has supported GeoRSS since the beginning of their API, and now giving developers the ability to export their maps into GeoRSS is a great step at encouraging more sharing. However it could go farther. The developer must actively export, and the exported data is not available in a subscription compatible interface. True, it would be much more complex on Yahoo’s part to provide GeoRSS feeds for all of their API uses. And the developer should have some choice in the matter. But by default, we should be sharing, just like by default RSS feeds are produced for weblogs.
The Yahoo polylines are specified using <geo:line>, which was my unofficial extension to the W3C Geo namespace. Now GeoRSS.org has official support for more geometries .. lines, polygons, and boxes. Perhaps this was partially my fault, since I hadn’t updated the worldKit documentation on GeoRSS and polygons with the work of GeoRSS .. until today, where GeoRSS Simple and GML are the recommended encodings (though every other format at there is still supported).
It would be great to see Yahoo Maps update to GeoRSS.org as well. Other parts of Yahoo, like flickr, are now publishing GeoRSS Simple. And I think there’s enough in GeoRSS to do away with the need for the extra ymap namespace.
So some critical feedback. Still good stuff. Thanks ever to Yahoo for supporting GeoRSS.
A good week for open mapping in the media. I have a couple quotes in a National Geographic News article on GeoRSS, Disaster Prediction, Social Networking Boosted by Geo-Data Feeds, and in this week’s Big Issue on OpenStreetMap (the UK magazine sold by homeless as an alternative to begging .. do buy one if you have the chance), Walk This Way.
For the Mapping Medio Ambiente Workshop, I whipped up support for Image Overlays in GeoRSS, in MGeoRSS.
Here’s an example of Yahoo Maps overlayed on Google Maps Santo Domingo.
This is something I pondered before when working on imagery overlays in Google Earth for the Java Earthquake in June.
The idea is to set the relationshiptag attribute of GeoRSS Box to image-extent. The location of the image is specified in another media:content tag. The relationshiptag and featuretypetag of GeoRSS are meant to be folksonomic .. unintended ontologies and usages will be explored as developers work with the format.
<georss:box relationshiptag=”image-extent”>-70.01544 18.39777 -69.80567 18.563517</georss:box>
I’ll detail this usage in MGeoRSS next time I update there. The only additional requirement is including the excellent TPhoto extension.
This is a very useful way to specify overlays, and I hope to encourage other GeoRSS tools to adopt this convention.
A couple weeks ago, Harry at the excellent Geospatial Semantic Web Blog posted on GeoRSS and Geonames for Philanthropy. His suggestion to use Geonames to produce GeoRSS for Kiva was a good one. And a simple one. Chained together with mapufacture, this was a one minute job to produce a map of Kiva loans, an approach generally useful for the Semantic Web. From such an easy demonstration, Kiva is now thinking about how to integrate mapping more directly in their site.
A while back, I did a similar chain for Global Voices, the excellent group blog highlighting interesting global blogging. Global Voices Mapped. If anyone is connected with Global Voices, it would be great to get an intro to them to look at deeper mapping integration.
These two worked extremely well for automatic geocoding, since both sites RSS feeds contain unambiguous, prominant place names. Though ultimately, I think we want GeoRSS generated with some human input, so to precisely set the location and insure correctness, automated geocoding is a great way to jump start the wider adoption of GeoRSS. We’re looking into better integration of geocoding vanilla RSS feeds for mapufacture.
mapufacture is a GeoRSS aggregator. Here you can layer multiple GeoRSS feeds from different sources into a single map, and search the database of GeoRSS feeds by keyword and location. Search results are themselves available as GeoRSS feeds.
So you’re welcome to check it out, and feedback! If you’re at XTech this week, come find me and I’ll give you a demo. And remember this is all under development, so consider it a working prototype.