[georss] WAS: GeoRSS Validation Service? RETURNING TO: multiplelocations and time

[Jason Birch]

Mikel Maron wrote:

> Take a look at the difference between a Polygon in Simple and GML.

If you stick with a single outer ring (which is what most users of 
Simple would be doing) it's a couple extra tags with a single text node 
in the middle.  Nothing complicated there.  Most applications would just 
template the strings on both sides and dump the coordinates in the middle.

> [...] I'm really starting to warm to the idea of finding a way to build
 > up additional things into the GML schema.
 > Leave Simple alone .. it serves it's purpose very well, the gateway
 > drug to heavy duty GIS.

I'd be happy with this approach.  I'm not sure that the gateway drug is 
necessary, and feel that it only leads to light duty GIS (even if GeoRSS 
is extended) but that's a personal bias as a GIS geek.  As long as 
Simple is not an area that is going to be expanded, and that users with 
more sophisticated needs are pointed towards the GML profile.

> Agreed. KML is good too. But I don't know how we started talking about
> GeoRSS KML .. I don't really see how that benefits anything, just 
> complicates and confuses.

I think that the primary driver for me (and others like Sean) to start 
thinking about this Searchable KML, which provides a strong avenue of 
findability in an extremely popular client application.  I don't think 
that it would be a huge stretch for Google to start indexing GeoRSS GML 
though; it's a subset of the geometry that KML supports.

Another place where I see some benefit would be the ability to publish, 
say, an article that talks about distribution of housing values and 
being able to include multiple geometries with styling attached (for 
instance, themed red-blue).  Canned stylization of geospatial entities 
can be a compelling part of the message.  Of course, this could just as 
easily be supported with a link to an external KML document or map.

> But that's pure FUD. Any sensibly coded parser only needs to 
> support one additional routine for each flavor, not 3 ..

Thats true; logic gap on my part.  So, as a spatial client you need to 
be able to support Atom & RSS as well as the three possible GeoRSS 
representations.  I guess part of my concern was that Simple would 
continue to evolve, so that with GeoRSS 1.x++ clients would have to add 
two more representations at each release.

> Sounds sensible. I support keeping Simple as is, and focusing of key 
> extensions to the GML flavor, to keep everyone working together.

Me too.

I think the key to this is whether GeoRSS is seen as a way of tagging an 
article with location, or it is a method for providing geospatial 
meaning to an article.  If it's the former, then a point, line, polygon, 
or envelope can meet most of our needs.  If it's the latter (which is 
what I'm more interested in) then there is a need for an additional (but 
hopefully still limited) set of features.

Here are some things that I've been thinking about:

Are both Simple and GML are allowed in the same document? - If so, can 
GeoRSS state that the client should prefer the most complex form that it 
supports?  Ideally clients would support both, but I'm pretty sure that 
there will be clients out there that only choose to support Simple.

Multigeometries - often, single features (such as a single legal lot 
split by a road right-of-way, or a road that has two sections separated 
by a park) have disjoint geometry.  Multigeometries would allow for an 
accurate representation of these features.  As well, it could allow for 
stronger presentation of things like GPS data, showing both the track 
and the waypoints as a single feature.

Multiple features - often a single article will talk about multiple 
places/locations.  For instance, the city where a famous person was 
born, another where they grew up, another where they performed a 
memorable speech, etc.  An envelope does not help provide enough context 
for the article, especially if the person was a world traveller :)

Attribution - with multiple geometries, there needs to be a way to tag 
these with names or identifiers, allowing the user to relate them back 
to the article.

Time - with all of the above extensions, time can be a critical factor 
in conveying the meaning of the geometries.  Such as a series of 
earthquakes, break-ins, etc...  I personally like the solution of 
allowing a time and/or timeperiod attribute on each piece of geometry, 
and an overall timeperiod attribute on the georss:where tag.

I'm enjoying this too much.  Must have something else that I'm supposed 
to be doing right now :)

Jason