GeoRSS media type?

As Randy George finds out, the notion of a "GeoRSS format" is confusing:

There seems to be some confusion about GeoRSS mime type - application/xml, or text/xml, or application/rss+xml, or even application/georss+xml show up in a brief google search? In the end I used a Virtual Earth api viewer to consume the GeoRSS results, which isn’t exactly known for caring about header content anyway. I worked for awhile trying to get the GeoRSS acceptable to OpenLayers.Layer.GeoRSS but never succeeded. It easily accepted static .xml end points, but I never was able to get a dynamic servlet endpoint to work. I probably didn’t find the correct mime type.

There is no GeoRSS media type. Atom's is application/atom+xml. RSS 2.0 uses application/rss+xml, and RSS 1.0 might use application/rdf+xml. You should use one of those depending on whether your GeoRSS elements appear in an Atom, RSS 2.0, or RSS 1.0 feed. Why? Atom has its own processing model. When you request a feed, the server writes application/atom+xml in the response's content-type header to inform you that you'd better use the Atom content processing rules if you want to make sense of the data.

Is there anything to be gained by having a special GeoRSS media type that overrode the Atom or RSS media types?


Re: GeoRSS media type?

Author: Peter Rushforth

Given that "GeoRSS" is like Kleenex, ie there are lots of formats which can be called that, would it not be helpful to have something like application/atom+gml, application/atom+geo etc to distinguish those brands?

Re: GeoRSS media type?

Author: Sean

Nevermind that +gml and +geo media types aren't standardized -- what would they mean to a processor that's not already said by one of the standard XML media types like text/xml, application/xml, and application/*+xml?

After a read of, I'm inclined to say that GML itself should be using something like application/gml+xml. GML is based on XML, yes, but rather opaque when displayed as text.