[georss] Musings about GeoRSS

[Allan Doyle]

Maybe I had the wrong idea. Or at least only had a half-formed idea.  
Maybe instead of defining GeoRSS, we should define a content model  
for geotagging. What if we avoid the format issue entirely? That's  
sort of what we were trying to do by having a model and  
serializations. Well, what if we do that properly?

Let's say the content model for geotagging is this:
=========

Geotag Content Model
--------------------
A geotag is an association between some content and a (geographic)  
geometry.

A geometry's geographic coordinates (GC) are expressed in WGS84  
decimal degrees unless otherwise specified.

A geometry's coordinate expression is latitude followed by longitude  
unless otherwise specified

A geometry can be at least one of a Point, Polyline, Box, Boundary,  
or Circle.

A Point consists of a single GC.

A Polyline consists of at least two GC's.

A Box consists of exactly four GC's.

A Boundary consists of at least four GC's. The last pair must always  
be identical to the first pair. A boundary with three "corners" has  
four GC's.

A Circle consists of one GC, designating the center, and one decimal  
number representing the radius in meters.

A geotag optionally has a free-form string that can describe the  
relationship between the geometry and the content.

A geotag optionally has a free-form string that can describe the  
nature of the geometry.

Additional information may be "mixed-in" to a geotag.

Geotag Encoding Schemes
-----------------------
A geotag is expressed in an encoding. Anyone can define an encoding.  
However, in order to maximize the usefulness of geotagging, the  
number of encodings should be kept very small.

A geotag encoding scheme has an identifier. This identifier MUST be  
unique[1] for each encoding scheme. The identifier SHOULD be a URI  
that can be resolved to a document describing the encoding scheme.

A geotag encoding scheme MUST be able to express at least one  
geotagging geometry.

A geotag encoding scheme MUST be accompanied by documentation  
explaining the mapping of the encoding to the geotag content model.

=========

Beginning with that, it then follows that geotagging RSS is one of  
many tagging opportunities. We can define GeoRSS in terms of the  
geotagging content spec above. We can also define a GML-based  
geotagging scheme. geo and geo++ would fit as well. So would  
microformat based geotags.

So what's the point? Well, we can start to build in some certainty  
about geotags and we can document mappings between the different ones.

Also, by defining the content model without mentioning RSS, we don't  
bias anyone to think that this is strictly for RSS and we don't  
overload GeoRSS as the holder of the content model.

     Allan



[1] We can enforce this by requiring identifiers to be PURLs, or some  
similar scheme
-- 
Allan Doyle
+1.781.433.2695
adoyle at eogeo.org