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

[Raj Singh]

Jason let me just say that we were making these arguments a year and  
a half ago. I think the main deal-breaker was the  
<gml:exterior><gml:LinearRing> elements in <Polygon>, which seemed  
too verbose.

But that's not the real point I want to make. I think it's great that  
we're having this debate, and that there's now such a larger  
community that knows what GML is compared to 18 months ago. From my  
OGC perspective, that makes the whole GeoRSS effort a success right  
there.

Now onto the future, I've been fighting adding features to GeoRSS GML  
these last few weeks, but I'm not fighting the idea of creating more  
simple expressions of geography. I've been quiet because I didn't  
know what to propose, but I like the idea of having other kinds of  
simple GML that could be put into a <where> element. I'm just not  
convinced they should be called GeoRSS.

Maybe a starting point for these feature discussions is to say that  
GML geometries found under <georss:where> are limited to Envelope,  
Point, Line and Polygon. New features should include a new child  
element of <georss:where>, such as  for time
<georss:where>
    <georss:mobileobject>
       <gml:Point>...
       <gml:Point>...
       <gml:Point>...
    <georss:mobileobject>
<georss:where>

or for multi-geometry objects (simplefeature alludes to the  
geometries allowed in the GML Simple Features specification available  
here: http://www.opengeospatial.org/standards/gml)

<georss:where>
    <georss:simplefeature>
       <gml:MultiPoint>...
       <gml:MultiPoint>...
       <gml:MultiPoint>...
    <georss:simplefeature>
<georss:where>

Encapsulating and naming functionality this way makes it easier for  
parsers to find the bits they can't handle, and for developers to  
make decisions about what to support.
---
Raj


On Mar 3, 2007, at 2:42 AM, Jason Birch wrote:

> Andrew Turner wrote:
>> Let me be the first to cast in my vote of dissent on this. Simple has
>> been embraced and is understandable by non-GIS professionals who want
>> to map (let us call them 'Neogeographers'). It is the 'gateway drug'
>> that gets them interested in the larger Geo-standards that they will
>> grow into.
>
> Hi Andrew :)
>
> I really shouldn't have posted that note knowing that I wouldn't be  
> able
> to come back to it right away.  Sorry for stirring the pot then
> disappearing.
>
> I just don't feel that the differential between Simple and GML is  
> enough
> to justify having two active "standards".  Does anyone really have
> difficulty with this:
>
> <georss:where>
>    <gml:Point>
>      <gml:pos>45.256 -71.92</gml:pos>
>    </gml:Point>
> </georss:where>
>
> instead of this:
>
> <georss:point>45.256 -71.92</georss:point>
>
> That's like saying that someone wouldn't be able to create a bold
> italicized string because it involves nesting <strong><em>the
> tags</em></strong>.  I don't think that you're giving neophyte users
> enough credit.  Of course they'll prefer to use Simple (it's easier),
> but I don't think that GML is hard enough to dissuade anyone.  Not  
> even
> a high-school birdwatcher (who would likely be using a WordPress  
> plugin
> anyway)
>
> OK, let's look at this the other way...
>
> If GeoRSS is resistant to supporting additional GML constructs beyond
> what is currently in the specification, why does it bother with the  
> GML
> version at all?  You're adding complexity without the additional value
> required to convince your users to "take a hit" of the arguably more
> powerful drug.  At this point, even KML allows much more expression  
> than
> GeoRSS GML.
>
> Not that swapping GML for KML is really an answer.  As much as I love
> KML (mostly because of the compelling client software and the  
> incredible
> findability that Google brings to the table) I have no idea how it  
> could
> be successfully integrated into feeds without duplicating feed content
> within the Placemark tags as name/snippet/description.
>
> In general, it feels to me like GeoRSS has prevented a  
> proliferation of
> "standards" by saying that they're all OK and wrapping them in the
> GeoRSS name (*). While this is successful from a marketing  
> perspective,
> and has brought all of the interested parties into a single room, I
> don't think that it is a wise long-term strategy.  Especially if, now
> that you have a level of simplicity that you're happy with, you're
> willing to let people leave the room because they require more
> expressiveness than the current specification supports.
>
> I don't ever want to see GeoRSS become as open-ended as GML (that's  
> just
> way too complex for most people that are not developing data  
> interchange
> specifications) but it would be nice to have a single approved  
> standard
> on which to build approved extensions, leveraging existing standards
> where possible.  What I see right now is the potential for the
> possibilities to mushroom to the extent that no client software
> developer will want to take the time to support all of them.
>
> * I know that this is oversimplifying things and I'm sorry to  
> trivialize
> the important efforts of the folks who worked on GeoRSS just to  
> make my
> point...
>
> Jason
>
>
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss