GeoRSS Multiple Locations
A commonly requested feature addition to GeoRSS has been multiple locations per entry. Currently, GeoRSS only adds a single geometry per RSS or Atom entry. This was pragmatic and served the general goals of GeoRSS.
There are several commonly encountered use cases. News reports typically mention several locations. Bloggers using GeoPress may tell a story about a trip and want to reference several spots along their trip – especially if they are documenting a tour that includes a path and sites along that path such as in EveryTrail. Dan Schultz talks about why “One Location Doesn’t Cut It”, citing other examples from news journalism.
Adrian and I recently sat down together to quickly brainstorm on what this may look like. The features we were looking to add were: multiple geometries, excerpt for that geometry, and toponym for that location (venue, city, etc.) Additionally, we didn’t want to break current compatibility.
Other services are already including multiple locations in different ways. Flickr outputs a single location in two different formats of GeoRSS: Simple, and some odd form of deprecated W3C. MetaCarta’s RSS-to-GeoRSS converted currently just dumps multiple locations into the entry, but without identifying if these are unique locations, or just variations in format type or hierarchy.
We wanted to call out that this is in fact a different type of geometry – a multi-geometry. Both KML and WKT support multi-geometry, but without being able to reference what the points are individually about. That’s useful if you are, say, marking all the holes in a field, but not for narratives.
Another feature we wanted to try and support was to be able to reference geometries stored elsewhere. Currently in GeoRSS feeds you’ll typically see references to a City or Country just include a point to the center of that geography. Not really indicative of what the article was about, or useful when trying to find all the geographic data about an area. So it’s important to include lines and areas as appropriate. However, including huge outlines of states or nations, potentially multiple times within a single feed, can have drastically bad consequences of increasing feed file size and complexity.
Here is a snippet of what we are proposing:
<description>
We went to visit downtown Cedarburg before
the conference. Had some great sandwiches at Joe's.
If you haven't been to Cedarburg, Wisconsin, then
you haven't really experienced the MidWest...
</description>
<georss:collection>
<georss:point
excerpt="Went to visit downtown Cedarburg..."
featurename="Downtown Cedarburg, Wis.">
43.296700 -87.987500
</georss:point>
<georss:polygon
rel="geometry"
src="http://geonames.org/geometries/5867680"
excerpt="..."
featurename="Cedarburg, Wisconsin"
type="application/vnd.google-earth.kml+xml"/>
<georss:line
featurename="Convention Center">
43.296700 -87.987500 43.3 -88 -44, -89
</georss:line>
</georss:collection>
The first part to notice is that we wrapped the multiple geometries in a georss:collection. This allows current parsers to not be confused by encountering multiple georss elements unwrapped and being unclear if they are multiple representations of the same geometry, or different geometries.
We also included a excerpt attribute that allows you to include some text referencing what this location is specifically about. This can be text from the article itself, or some other useful information. One concept we had considered was using some reference to the text wrapped in the article itself, but this seemed burdensome and prone to problems using an attribute of one element to embedded text in another element.
The second element is a georss:polygon that includes a src reference to the geometry stored elsewhere. The rel tag specifies that it is the geometry of this element, and the type helps the tool know what the representation is of the stored geometry. This way a tool that is consuming the GeoRSS can go and fetch the geometry if it wants, or if it already has a cached version, say referenced elsewhere in this same feed, then it doesn’t have to request it again.
Of course, with a standards development, it is useful to consider how a user interface might provide for including multiple locations in an entry. Here is a mockup of how I imagine a simple interface would appear, and probably how we’d implement it in something like GeoPress:
Article: We went to visit downtown Cedarburg before the conference. Had some great sandwiches at Joe’s. If you haven’t been to Cedarburg, Wisconsin, then you haven’t really experienced the MidWest…
Locations:
– Excerpt: Went to visit downtown Cedarburg…
– Type: Point
– Geometry: 43.296700 -87.987500
– Name: Cedarburg, Wis.
To promote ideas and discussion around these and other proposals, I’ve created proposals at GeoRSS.org on multiple location and referencing external geometry. Please let us know what you think about the idea and format. We know that we can’t please everyone, but like the origins of GeoRSS, we’re just trying to address a real need with a simple format.
My name is
March 18th, 2008 at 12:27 am (#)
Awesome, Andrew, thanks for writing this up. Please let me know what I can do to help implement this in GeoPress or in any other way. This is a huge step forward for GeoRSS.
March 18th, 2008 at 11:19 am (#)
Verrry interesting!
Not being able to represent multiple locations hasbeen a major drwaback for representing our geocoded news (I’m working at the german news agency) within georss.
Since our main feed format is NITF (NewsIndustryTextFormat http://www.nitf.org) we first had to come up with a notation of our geocoded news in NITF. We choose to use georss:point within NITF (see example below)
<identified-content>
<location>
<state state-code=”07000000″ code-source=”AGS”>Rheinland-Pfalz<georss:point>8.27104591236
49.9966008543</georss:point></state>
<country iso-cc=”DEU”>Deutschland</country>
</location>
<location>
<region region-code=”10041000″ code-source=”AGS”>Stadtverband Saarbrücken<georss:point>6.
99763293966 49.2358453373</georss:point></region>
<state state-code=”10000000″ code-source=”AGS”>Saarland<georss:point>6.99763293966 49.2358
453373</georss:point></state>
<country iso-cc=”DEU”>Deutschland</country>
</location>
</identified-content>
From my experience an even more important freason or external references than the drawback of increasing the feed size is the fact that typically
license restrictions from commercial data providers do not allow to include the geometries of the counties, city, neighbourhood borders etc.
And at least in Germany there are only commercial providers for the geometries, since every city is selling the geometries for ridicolous prices and wven more ridicoulous licensing terms.
Hence we are only able to include the centroid (resp. some official representant designated by some authority) of the polygon within our feeds. But in order to enable our customers to identify which geometry to associate with the locations and do the computations you mentioned above we had to come up with a way to communicate an identifier for that geometry. To our advantage NITF already provides code-source and *-code attributes that we could use for these purposes.
I would like to be able to come up with similar possibilities in GeoRSS. IMHO, generalizing external references via src attributes from georss:polygon into a separate tag, e.g. georss:ref, georss:external or whatever it should be named seems to be a good idea for doing so. Given the rel attribute maybe using georss:link would be a good idea as a tag name. Having a separate tag would be similar to the handling of external images via the img tag as well as the link tag in HTML and allow for flexible representation schemes for the external data as well as coping with some shortcomings of your proposal. e.g. the result being not a polygon but a point or a line.
I’m also not sure if the attributes excerpt and featurename are really necessary and shouldn’t be handled via additional namespaces or tags. I definitely think that excerpt shouldn’t be an attribute. It also makes sense for me to rename featurename to name.
PS.: I’m attending Where2.0 and WhereCamp (and currently are still free on May 15-16th) and would be most interested to discuss these issues. Anybody else interested?
BTW.: I’m reporting on my efforts of becoming the dpa the first news agency worldwide to geoceode their news on by blog in a miniseries to be found at http://relations.ka2.de?tag=goingplaces and would be most interested in getting feedback.
March 18th, 2008 at 12:01 pm (#)
Sounds like a good plan to me. I’m not entirely clear on how the collection element helps me or the parser tell if I’m dealing with multiple places or a hierarchy of places.
May be we can discuss this more next week in St Louis?
Ian
March 18th, 2008 at 12:34 pm (#)
Andrew, I prefer multiple entries to multiple location items. Feed entries are cheap: http://zcologia.com/news/711/multiple-locations-in-georss/.