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

[Pat Cappelaere]

Good idea.
We actually have a reference implementation written in Ruby for OWS-4.
An instantiation of that can be found at http://eo1.geobliki.com.
We publish GeoRSS feeds and we are also experimenting with a WFS-B that
outputs feeds.

As CommunityMapBuilder developer, I have also implemented the Javascript
version.  Checkout: http://docs.codehaus.org/display/MAP/Home
 
Our intent is to provide an Open Generic SensorWeb Enabled Datq Node.

I am very sensitive to my user needs and want to also limit the work I have
to do to support standards.
Developing one or 2 output formats is ok, 6 is not.
Simple is good!

We have to deal with government organizations that are IT-light or do not
have developers that cannot spend time learning complex standards.

So we have real use-cases.  We are talking to actual end-users.  And we do
write a lot of code.
Parsing RSS/Atom is very straight forward these days.  Parsing some simple
GML elements is ok.  Advanced users/developers can experiment with more
complex elements.
Same with KML.

Problem is that is getting out of hand again.

Pat.


> From: Peter Borissow <peter.borissow at yahoo.com>
> Date: Fri, 2 Mar 2007 11:53:45 -0800 (PST)
> To: Pat Cappelaere <pat at cappelaere.com>, Allan Doyle <adoyle at eogeo.org>,
> <georss at lists.eogeo.org>
> Subject: Re: [georss] WAS: GeoRSS Validation Service? RETURNING TO:
> multiplelocations and time
> 
> This might sound like a crazy idea but what if we sat down and wrote some code
> instead of debating whether or not clients will adopt a more expressive form
> of GeoRSS.
> 
> Parsing RSS and Atom is a joke. Parsing GML geometries is not that complicated
> either. In fact I wrote a limited GML parser that can handle points, lines,
> and polygons + their "multi-" varients in less than an hour. Adding the GeoRSS
> "simple" geometries took even less time.
> 
> Point is, perhaps it's time for some reference implementations - something
> developers can download and use/embed in thier software (at thier own
> risk/discretion of course). I actually envision at least 5 libraries, one for
> each of the following languages:
> 
> JavaScript (think Ajax)
> Java (Using DOM or SAX - not XMLBeans or JAXB)
> VB.NET
> C#
> C++
> 
> 
> Any thoughts? 
> 
> Peter
> 
> 
> 
> 
> ----- Original Message ----
> From: Pat Cappelaere <pat at cappelaere.com>
> To: Allan Doyle <adoyle at eogeo.org>; georss at lists.eogeo.org
> Sent: Friday, March 2, 2007 11:56:20 AM
> Subject: Re: [georss] WAS: GeoRSS Validation Service? RETURNING TO:
> multiplelocations and time
> 
> 
> Who are your customers?
> Developers of Data Providers (IMHO)
> 
> For standards to be accepted, they have to be simple for a data provider
> developer to implement on the server side and to build a client for.
> 
> We need more data providers out there.
> 
> We are going to have a hard sell to say:
> 
> Guys, you need to support:
> 
> 1. GeoRSS/Atom 1.0 GML Simple
> 2. GeoRSS/Atom 1.0 GML Complex
> 3. GeoRSS/RSS 2.0 GML Simple
> 4. GeoRSS/RSS 2.0 GML Complex
> 5. GeoRSS/Atom 1.0 KML
> 6. GeoRSS/RSS 2.0 KML
> 
> As a client developer, I might not mind developing an interface for 2
> classes of data and expand on the capabilities later (Simple->Complex) if I
> want to support timespans, mulitple-geometries... GML parsing issue
> 
> Pat.
> 
> 
>> From: Allan Doyle <adoyle at eogeo.org>
>> Date: Fri, 2 Mar 2007 11:23:41 -0500
>> To: <georss at lists.eogeo.org>
>> Subject: Re: [georss] WAS: GeoRSS Validation Service? RETURNING TO:
>> multiplelocations and time
>> 
>> 
>> On Mar 2, 2007, at 10:51, Andrew Turner wrote:
>> 
>>> On 3/2/07, Pat Cappelaere <pat at cappelaere.com> wrote:
>>>> 
>>>> I really want to stay away from a simple and complex.  There is
>>>> only one
>>>> format with some best-practices.  I did not hear "let's deprecate
>>>> simple"
>>> 
>>> Actually there was :
>>> 
>>>> Jason Birch Said:
>>>> 
>>>> What I read into this is that with the acceptance GeoRSS has
>>>> gained as a defacto standard, it
>>>> would be well served to deprecate all but the following:
>>>> 
>>>> - Atom 1.0 + GML (limited)
>>>> - RSS 2.0 + GML (limited)
>>> 
>>> Which is where my vote of dissent came from. I think GeoRSS is on a
>>> great path and should continue to expand in areas that users are
>>> requesting, or show "recipes" of how best to use GeoRSS with other
>>> standards (Geonames, xCal, etc.). It's not time yet to start removing
>>> things.
>> 
>> I agree!! Don't throw out Simple.
>> 
>> -- 
>> Allan Doyle
>> +1.781.433.2695
>> adoyle at eogeo.org
>> 
>> 
>> 
>> _______________________________________________
>> georss mailing list
>> georss at lists.eogeo.org
>> http://lists.eogeo.org/mailman/listinfo/georss
> 
> 
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss
> 
> 
>  
> ______________________________________________________________________________
> ______
> Looking for earth-friendly autos?
> Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
> http://autos.yahoo.com/green_center/