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

[Raj Singh]

Peter, once I finished writing this I saw it was very long. That's  
because I think it's an important question that deserves a complete  
answer--and one a lot of people have--not because I'm ranting.

Let's start with an anecdote.
Safe Software is a company who's entire business is geodata format  
translation.
They are simply one of the best in the business, and I've heard that  
companies like ESRI and
MapInfo don't even bother developing translation code anymore. They  
just license
Safe's libraries.

Now read this blog entry:
http://spatial-etl.blogspot.com/2007/02/skinny-on-fmes-georss- 
support.html
(or cheat and just read this quote)
"Despite my enthusiasm for web feeds and GeoRSS, early research into  
supporting both RSS and GeoRSS showed that this would involve a  
considerable amount of work."

Even a company like Safe was balking at the limited functionality you  
see today.

The problem is that for a standard to be a big win, software has to  
support *all* of it. It doesn't make as much sense for someone to  
build a GeoRSS reader if they know they can't afford to support all  
features. That puts them in a position where they don't have a clear  
idea of how valuable their application will be, because the  
information sources that might make their app great might not be  
readable.

So back to the GML geometry question, it could quite easily drive  
people away from GeoRSS if they had to not only parse the XML of  
polygons with multiple islands in them, or noncontiguous lines, or  
bezier curves, but then their application would have to figure out  
what to do with them. Remember we're still having trouble getting  
people to go beyond points and do interesting things with simple  
lines and polygons.
---
Raj


On Mar 1, 2007, at 12:56 PM, Peter Borissow wrote:

> One man's metadata is another man's data - it's all a matter of  
> perspective.
>
> I'm all for keeping things simple.
>
> In fact, what can be simpler - the GeoRSS spec can say something  
> like "we support gml geometries - use whatever gml geometry you  
> want. Here are some examples. Please refer to the gml spec for more  
> information."
>
> So the question still stands - why not support the full set of gml  
> geometries? Because it's too complicated? Because you're afraid  
> that clients will shy away from georss if it gets any more  
> complicated? I'm new to the group so I just don't understand the  
> logic.
>
> That said, I'll settle for at least multipoint, multiline, and  
> multipolygon :)