GeoRSS ::
Geographically Encoded Objects for RSS feeds

GeoRSS Proposals

GeoRSS is an open (as in speech) and evolving standard. Anyone is free to submit proposals for extensions or modifications of the standard.

To submit a proposal, first create an account and login. Then create a new page stating your proposal, its intended use and example use case, and some example format snippets.

After an initial discussion period the proposal will go up for vote by all members of the GeoRSS community. If the proposal passes by a simple majority then the proposed modification will be adopted into the next version of GeoRSS.

Referencing External Geometries

Use cases
  1. Often-updated feeds in which entries almost always refer to the same set of semi-static, and possibly complex, locations such as administrative regions. The overall application is improved by not fetching and parsing redundant literal geometry elements.
  2. Linking to locations from HTML. Foreign markup isn't welcomed by web browsers, and HTML5 doesn't welcome RDFa, so one must link to locations in other documents.

Possibilities

Note: previous source wasn't coherent, so has been removed for now. Add back in as required. --Sgillies 21:03, 29 April 2009 (UTC)

There's at least two ways to go: use of Atom/HTML links (which better serves the second use case), or use of an optional URI attribute in the georss:where element ala HTML <script> or atom:content (which better serves the first use case).

Atom and HTML links

Would require standardization of a rel type such as "where" (for HTML) or "http://georss.org/relation/where" for Atom:

...
<link
  rel="where"
  type="application/atom+xml;type=entry"
  href="http://pleiades.stoa.org/places/639166.atom#location"
  />
...

And then we'd have to nail down the semantics of "where". Would we want to refer only to georss:where elements within other XML documents using XML ids? Use KML/GML/JSON too?

External source for georss:where

More or less like HTML's <script> tag:

...
<georss:where src="http://pleiades.stoa.org/places/639166.atom#location">
  <!-- empty, filled in by fetching doc from src URI -->
</georss:where>
...

In this case, we'd only accept georss:where markup.

Multiple Locations

Use Cases

News article with multiple locations

Comment: I don't think locations mentioned in the news are always as compelling as we think. Consider this story about new federal appointee who wants to employ statistical methods to the census: http://www.nytimes.com/2009/04/03/washington/03census.html. There are 7 locations mentioned in the article:

None of these locations are very relevant to the story. GeoRSS'ing them in a feed item would geo-spam readers. The producers of the NYT feed, appropriately, gave it no geographic categorization at all. One location per entry is probably the most useful thing a feed producer can do. More locations require more semantics.--Sgillies 19:51, 29 April 2009 (UTC)

I'd disagree re relevance of story. If you are from one of the locations mentioned in the article, e.g. Ann Arbor, MI, the fact that someone from the University of Michigan is mentioned in a story is very relevant if you're pulling in a localized feed. I agree that at some level this is geo-spam, but that's a problem for editorial and post-production not data design. Edward Vielmetti 03:31, 3 May 2009 (UTC)

Sensor report that has a multi-geometry

Comment: An specific example of such sensor reports is necessary, since we usually try to measure fields at points in space, or at points along horizontal transects and/or vertical profiles. A temperature or pressure value with multiple locations makes little sense. --Sgillies 19:51, 29 April 2009 (UTC)

Suggested Solutions

multiple locations per item

<item>
  <title>..</title>
  <link>http://...</link>
  <category>..</category>
  <pubDate>..</pubDate>
  <description>...</description>
  <georss:point>[coordinate pair]</georss:point> <!—fire origin location -->
  <georss:polygon[coordinate pairs]</georss:polygon> <!—first burn area -->
  <georss:polygon[coordinate pairs]</georss:polygon> <!—second burn area --> 
    <!-- (distinct from first area, however relating to the same fire incident, such as a spot fire) -->
  <georss:polygon>[coordinate pairs]</georss:polygon> <!—third burn area -->
  <georss:polygon[coordinate pairs]</georss:polygon> <!—fourth burn area -->
</item>

Comment: Too dependent on undefined semantics. This won't fly. Better to use one polygon that envelopes everything, then put a more detailed serialization of data from your wildfire model in atom:content. --Sgillies 19:33, 29 April 2009 (UTC)

more entries

Sean Gillies made this counter-proposal The premise is that you create a single primary entry that contains the story, bounding box of locations or primary location (or no locations). Then, using atom:link with rel's, append multiple additional entries per each location or event. The rel points back to the primary article (that this is a comment or related to) and can then include snippet, author, time, and locations.

The benefit of this mechanism is that it currently works within the existing spec, so nothing "new" is added, it is just a suggested way of handling multiple locations. Additionally, there is the ability to include more information for each snippet such as time spans, categories, excerpts, etc. without GeoRSS having to extend and add all those as necessary.

The potential detriment is that to "vanilla" readers a single story could show up as multiple stories: the primary and each excerpt.

<feed
  xmlns="http://www.w3.org/2005/Atom"
  xmlns:georss="http://www.georss.org/georss"
  xmlns:gml="http://www.opengis.net/gml"
  >
  <entry>
    <id>urn:uuid:7e8ee974-9181-4eae-ad65-55d29175d942</id>
    <link href="http://example.org/entries/1"/>
    <title>Cedarburg Trip</title>
    <summary>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...</summary>
    <content type="html" src="http://example.org/entries/1"/>
  </entry>
  <entry>
    <id>urn:uuid:53664db3-4598-45d4-a727-022c6203322e</id>
    <link rel="related" href="http://example.org/entries/1"/>
    <title>Downtown Cedarburg, Wis.</title>
    <summary>Went to visit downtown Cedarburg...</summary>
    <georss:where>
      <gml:Point>
        <gml:pos>43.296700 -87.98750</gml:pos>
      </gml:Point>
    </georss:where>
  </entry>
  <entry>
    <id>urn:uuid:2528d1b4-b5a9-415c-be69-f83974e3e6af</id>
    <link rel="related" href="http://example.org/entries/1"/>
    <title>Convention Center</title>
    <georss:where>
      <gml:LineString>
        <gml:posList>43.296700 -87.987500 43.3 -88 -44 -89</gml:posList>
      </gml:LineString>
    </georss:where>
  </entry>
</feed>

Perhaps better yet: treat geographic annotation as commentary on the original entry using RFC 4685, the Atom Threading Extension:

<feed
  xmlns="http://www.w3.org/2005/Atom"
  xmlns:georss="http://www.georss.org/georss"
  xmlns:gml="http://www.opengis.net/gml"
  xmlns:thr="http://purl.org/syndication/thread/1.0"
  >
  <entry>
    <id>urn:uuid:7e8ee974-9181-4eae-ad65-55d29175d942</id>
    <link href="http://example.org/entries/1"/>
    <title>Cedarburg Trip</title>
    <summary>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...</summary>
    <content type="application/xhtml+xml" src="http://example.org/entries/1"/>
  </entry>
  <entry>
    <id>urn:uuid:53664db3-4598-45d4-a727-022c6203322e</id>
    <link rel="related" href="http://example.org/entries/1"/>
 
    <thr:in-reply-to
      ref="urn:uuid:7e8ee974-9181-4eae-ad65-55d29175d942"
      type="application/xhtml+xml"
      href="http://www.example.org/entries/1"
      />
 
    <title>Downtown Cedarburg, Wis.</title>
    <summary>Went to visit downtown Cedarburg...</summary>
    <georss:where>
      <gml:Point>
        <gml:pos>43.296700 -87.98750</gml:pos>
      </gml:Point>
    </georss:where>
  </entry>
  <entry>
    <id>urn:uuid:2528d1b4-b5a9-415c-be69-f83974e3e6af</id>
    <link rel="related" href="http://example.org/entries/1"/>
 
    <thr:in-reply-to
      ref="urn:uuid:7e8ee974-9181-4eae-ad65-55d29175d942"
      type="application/xhtml+xml"
      href="http://www.example.org/entries/1"
      />
 
    <title>Convention Center</title>
    <georss:where>
      <gml:LineString>
        <gml:posList>43.296700 -87.987500 43.3 -88 -44, -89</gml:posList>
      </gml:LineString>
    </georss:where>
  </entry>
</feed>

This approach could easily accommodate the desire of some producers to explicitly add locations for everything they can geocode in their content.

georss:collection

<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:point>	
</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 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.

Comment: Adding a "featurename" attribute to these locations is confusing. After all, the entry is the feature. The text excerpts are superfluous, this is what the entry summary is for. Better, I think to leave multipart geometries out of the simple GeoRSS, and encourage users to use GML multipoints (etc) in a georss:where element. --Sgillies 20:13, 29 April 2009 (UTC)

Multi-Polygons Type

This page is meant to gather information on use cases and suggested solutions to provide support for multiple polygons per story, or feed entry.

Use Cases

In several use cases it's necessary to use a multipolygon to define a location that is the aggregation of several polygons (MULTIPOLYGON) This is not an event in multiple locations, it's a item that has some kind of geometry impossible to draw in a single polygon

Some example of such non-continuous polygons are satellite data, landcover and other environmental data, some electoral districts in the US or municipalities in Portugal.


Suggested Solutions

Type Multipolygon

Allow the definition of the attribute type with the "multipolygon" as value in the where elements

<georss:where type="multipolygon">
  <georss:polygon>...</georss:polygon>
  <georss:polygon>...</georss:polygon>
</georss:where>