PubForge Blog

After checking out an article about Google Maps that Todd Mundt pointed out, I decided to put this to the test and came up with some questions that others might find interesting.

First, Go to this article on the Google Maps API Blog:
KML and GeoRSS Support Added to the Google Maps API

then enter the following url (or an equivalent url) in the field just above the map, and to the right of the button marked “add”:

http://ws.geonames.org/rssToGeoRSS?feedUrl=http://kjzz.org/search/rss?keyword=smoking&size=3

http://kjzz.org/search/rss?keyword=immigration&size=5

or go here:

http://kjzz.org/map?keyword=immigration&size=5

or here:

http://maps.google.com/maps?q=http://kjzz.org/search/rss?keyword=immigration

Think conceptually, how this might be applicable for visualizing the range of stories covered by a local news station, by NPR, and by public broadcasting as a whole?

Think practically, should reporters be required to get latitude and longitude data for each story? When they enter a city & state for the “dateline” field, should this field be more precise? What if the relevant places for a story take place in multiple locations?

Should stations start embedding GeoRSS data in thier rss feeds?

Is anyone doing this now? What about KQED’s Quest application? How did the building of this application necessitate that they think differently about the metadata for stories, for the architecture of their site?

In answer to this question, Tim Olson and Craig Rosa from KQED chimed in here:

http://johntynan.com/archives/26#postcomment
Tags: opensourcebroadcasting, pubforge, beyondbroadcast, GeoRSS, GoogleMaps