[georss] WAS: GeoRSS Validation Service? Also, Simplification

[Carl Reed OGC Account]

What a great and challenging discussion!

A couple of thoughts.

Definitely keep GeoRSS Simple. It does meet a market requirement very well.

Keep the GML serialization and provide guidance on how to do extensions 
(yes, I keep repeating myself!)

The following is mostly informative, so use the info as you will in these 
discussions:

I think no matter what we need continue to keep GML as a valid serialization 
of GeoRSS. Why? This is the GeoRSS serialization that a number of major 
enterprises (government and commercial) want to use or are beginning to use. 
Why? Because GML has become one of their mandated standards for use in those 
organizations. As Allan states, the Genie is out of the bottle. Further, a 
simple GML profile is now the preferred payload encoding for a variety if 
Internet standards (see PIDF-LO and all the internet standards that 
reference it) and soon a number of OASIS standards.

Funny, but the GML point definition is identical in the various OASIS, IETF, 
IEEE, and GeoRSS specifications. If you are wondering about PIDF-LO and 
related standards, they are being driven by the telecommunications, location 
services, and emergency services communities in relation to the deployment 
of IPV-6. There is a great reference document, "The IETF Geopriv and 
Presence Architecture: Focusing on Location Privacy". The point is that 
other communities have been and continue to discuss simple, lightweight 
encodings. Perhaps that is why the definitions are almost identical (if not 
identical).

Now to GeoRSS KML.  As Google staff (and I believe Jason also pointed out) 
have stated, KML utilizes GML 2.1.2 elements for the 2-d geometry 
constructs. We (OGC) have already discussed the possibility of migrating the 
geometry elements of KML to GML 3.2. This will be one of the open topics for 
discussion on the public list a bit later this year. Anyway, perhaps we 
should think about KML leveraging GeoRSS GML instead of the other way 
around. Just a thought.

Have a good weekend

Carl

----- Original Message ----- 
From: "Jason Birch" <jb-georss at jasonbirch.com>
To: <georss at lists.eogeo.org>
Sent: Saturday, March 03, 2007 3:07 PM
Subject: Re: [georss] WAS: GeoRSS Validation Service? RETURNING TO: 
multiplelocations and time


> 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
>
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss