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

Fri Mar 2 09:34:17 EST 2007

Andrew,

I do not see any dissent here.
We need to keep evangelizing the need for GeoRSS (being Atom 1.0 or RSS 2.0)
We need to show the minimum tags to implement to enable geospatial
recognition (simple)
We can also show what is possible if you want to leverage the full potential
of GML for particular applications (Not all clients can be required to
support it)

So what we have is: GeoRSS/GML

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"

What we need to consider now is: GeoRSS/KML for another distinct market.

Pat.

> From: Andrew Turner <ajturner at highearthorbit.com>
> Date: Fri, 2 Mar 2007 08:55:47 -0500
> To: Pat Cappelaere <pat at cappelaere.com>
> Cc: Jason Birch <Jason.Birch at nanaimo.ca>, <georss at lists.eogeo.org>
> Subject: Re: [georss] WAS: GeoRSS Validation Service? RETURNING TO:
> multiplelocations and time
> 
> On 3/2/07, Pat Cappelaere <pat at cappelaere.com> wrote:
>> Jason,
>> 
>> We are talking about output formats here.
>> So best practices so far are:
>>  - Atom 1.0 + GML (limited)
>>  - RSS 2.0 + GML (limited)
>> 
>> So we let's call them:  Atom/GML and RSS/GML
>> 
>> - Simple vs complex is becoming a minor issue. On the table would be to just
>> have one that serves one community.  It is GML.
> 
> 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.
> 
> I assume there are existing tools that already handle parsing/creating
> full GML. Seems like having a "subset" of GML makes developers have to
> modify their parsers to handle just the subset is work. However, just
> being able to identify that this RSS/Atom item uses GML and then
> pushing it off on the full GML parser is an easy thing.
> 
> Based on that idea, it seems like it would be useful for any
> developers and the standard if open-libraries for parsing & creating
> GeoRSS would go a long way in convincing any company to support the
> standard. For example, GeoRSS4rb is a Ruby library for parsing all the
> current incarnations of GeoRSS. I imagine there are similar ones
> (maybe with some work) for PHP, Java, C++, Python, et al.
> 
> And for moving past a standard, Simple hasn't run out of life, it's
> just getting going. Deprecating it now will more than likely scare
> away the hundreds of users and interested parties that are just now
> getting into it. Heck, Yahoo! only supports some odd modification of
> GeoRSS, but at least they support something. Start expanding the
> "Advanced" standard (supporting full GML) and provide easy tools for
> devs to grab to add this support & *then* think about deprecating it.
> 
> Andrew
> 
> 
>> So now we can focus on:  Atom/KML and RSS/KML
>> 
>> Users can specify the output they rather want to have from a WFS :)
>> Pat.
>> 
>> 
>> 
>> 
>>> From: Jason Birch <Jason.Birch at nanaimo.ca>
>>> Date: Thu, 1 Mar 2007 22:39:28 -0800
>>> To: <georss at lists.eogeo.org>
>>> Conversation: [georss] WAS: GeoRSS Validation Service? RETURNING TO:
>>> multiplelocations and time
>>> Subject: Re: [georss] WAS: GeoRSS Validation Service? RETURNING TO:
>>> multiplelocations and time
>>> 
>>> Raj wrote:
>>> 
>>> --------------
>>> Even a company like Safe was balking at the limited functionality you
>>> see today.
>>> 
>>> --------------
>>> 
>>> Although I agree with your argument against complexity, I don't think that
>>> Dale's quote supports your reasoning to the extent that you took it.
>>> Reading
>>> further, Safe's hesitation would appear to be from the fact that they had to
>>> support a matrix of nine different "formats" for GeoRSS, not because they
>>> had
>>> to support a small subset of GML.  My guess is that GML was a minor part of
>>> the puzzle for them compared to the general RSS, Atom, and web access which
>>> their product did not support at the time.
>>> 
>>> 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)
>>> 
>>> W3C is already recommended against, and I don't see a huge difference
>>> between
>>> Simple and the subset of GML in GeoRSS, and feel that Simple's continued
>>> existence just adds barriers for proper client-level support GeoRSS.
>>> 
>>> The GeoRSS brand of GML is not especially difficult to publish.  KML
>>> supports
>>> a broader set of geometry and time elements, and there are many users taking
>>> full advantage of both of these.  As long as you support a well-defined
>>> schema
>>> that publishers can read and understand, you won't have any problems in that
>>> area.
>>> 
>>> Supporting GML may be more difficult for client applications, but you're
>>> already imposing that burden, along with the extra work of having to support
>>> W3C and Simple.  By removing these formats from the mix, you give clients
>>> the
>>> ability to legitimately support only GML and give publishers the incentive
>>> to
>>> make the short hop to limited GML.  You also set a less complicated GeoRSS
>>> baseline, from which adding time and multi-geometries might not seem like so
>>> much extra work or complexity.
>>> 
>>> I understand that the current state of GeoRSS was needed to unify geo feeds,
>>> but now you are risking what you set out to prevent.  Latecomers that want
>>> to
>>> push the standard beyond the current definition are being resisted,
>>> increasing
>>> the likelihood of that competing implementations of the same functionality
>>> will emerge, leading to diminished interoperability.
>>> 
>>> As long as I'm stepping on toes (and getting into an argument that I'll
>>> probably end up losing)...
>>> 
>>> Why not consider deprecating the existing GeoRSS formats entirely, and
>>> moving
>>> to embedding KML in feeds as an alternative rather than as an enhancement?
>>> This would give the publisher community a single geo:target while leveraging
>>> the significant support that KML has gained in the client space.  Ron's
>>> statement last week --indicating that GeoRSS in some ways has more in common
>>> with the KML than with GML -- and Carl's note today describing the problem
>>> domains of GML and KML both seem to support this approach.
>>> 
>>> Jason
>>> _______________________________________________
>>> 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
>> 
> 
> 
> -- 
> Andrew Turner
> ajturner at highearthorbit.com        42.4266N x 83.4931W
> http://highearthorbit.com              Northville, Michigan, USA