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
Pubforge.org is a resource being built by a group of folks from public broadcasting organizations interested in applying open-source solutions to common problems faced in the transition from traditional to new media. A work group met at the recent Beyond Broadcast meeting in Boston and chose this domain to be the home for discussion about these commom problems, for shared wisdom on best practices, for shared code and recommendations, and to be a repository for useful open source tools and applications.
In order to begin the work, Bill Haenel has installed this WordPress blog into the site. This is intended to be the focus for discussion. He also installed a mediawiki into the site at http://pubforge.org/pubwiki. This will be the nucleus for articles on problems, solutions, case studies, best practices, applications and projects.
We invite everyone interested in forming and exploiting a partnership between public broadcasting and the open source development community to register for this site and to contribute via the blog and the wiki.
As a means of starting the conversation here, I would like to ask people to consider the following question: What would I like to do in new media that i can’t do now with the resources capablities and knowledge now in hand?
Here are a few from my list:
-
I would like to be able to integrate content from MySpace pages created by members of my station into my station.org site
-
I would like a tool that makes it easy to create Google Map mashups for our news pages
-
I would like to be able to grab specific items out of mutiple RSS feeds to create custom topical and regional feeds
-
I want information on standards and best practices for creating video podcasts
Please post your own wish lists, then we can start identifying ones which have existing solutions, and which ones might be targets for development assistance.
