Geographic syndication in a nutshell

There are three reasons to syndicate geographic resources:

  • To allow users or other agents to track updates or edits

  • To make synchronization with other systems cheap and easy

  • To generate a sitemap for search engine optimization

The third is a special case of the second. In all cases, GeoRSS permits some simple spatial analysis, filtering, and indexing of the entries in your feed. The basic recipe for syndicating geographic resources using GeoRSS follows:

  • Implement just one feed for changes and one more for deep sync and site-mapping. The different versions of RSS are interchangeable enough. Pick one format and go with it.

  • Choose Atom. There's a well designed payload element that can easily carry any media, a link relation registry, and a matching publishing protocol (used in Google Data APIs, including the Maps Data API). It's better.

  • Pick one GeoRSS flavor. Simple or GML. I prefer the "where" semantics of the latter. I wouldn't put a "time" element in any entry without specifying what time it was (created? modified?) and so I feel uncomfortable when I put an ambiguous "point" element in an entry. Granted, there aren't any location semantics other than "where" currently in use, but it feels risky (to me) to have such latent ambiguity.

  • Use zero or one location or "where" element per entry. Don't duplicate locations within an entry using different GeoRSS flavors. Your entry's content may have a geographically rich context, but that's to be described within the content using KML, GML, or whatever. GeoRSS specifies the location of the entry within feed space, and it should be as simplified a location as can be.

There's no consensus on how the concept of cartographic scale is to be applied in the context of a feed. If your feed has a global scope, you should probably use small scale representations of locations. If your feed is local, or hyper-local, scale up accordingly. Perhaps it would be helpful if GeoRSS feeds specified their spatial scale. Not in the form of a ratio as we do for paper maps, and not in the form of "zoom levels", but a form that's useful to internet engineers. Numerical precision? Surely, someone has their spatial thinking cap on and has already figured this out. I'd appreciate being clued in.

Comments

Re: Geographic syndication in a nutshell

Author: Sean

A Twitter user politely objected to my use of "cartographic scale" in the last paragraph above. As a way of explaining what I mean, consider a feed entry's summary element: it's a representation of the entry's content at the feed browsing "scale", and there's more craft to a good summary than brute filtering like truncation at 140 characters. A summary needs key words and hooks. Some of the same considerations have to be made when making a GeoRSS location representation for an entry. An entry in the spatial context of a city can't very well include a detailed 3D representation of the city within a georss:where element, and brute filtering isn't any more useful. In some feeds, this location would be represented as a point. In others, as a simplification of the municipal boundary. It's an almost cartographic decision.