[georss] Quick Fire Summary

Fri Apr 27 21:03:04 EDT 2007

On Fri, Apr 27, 2007 at 05:39:49PM -0700, Ron Lake wrote:
>  * GeoRSS NS is simple geometry description for the web of content.   
>    This means that it can be used in much more than RSS. However, it's 
>    not 'feature description' -- its not GML. It's not meeting the needs
>    of people who need complex feature description -- it's a framework
>    for simple description of web content. (Despite what was said earlier
>    on the list, GML is *not* the de facto simple encoding of Geo Data on
>    the web, nor will it be, due to its reliance on XML Schema and its
>    relative complexity compared to GeoRSS Simple.)
> 
> It should be noted that GML is intended to provide language to create
> geo-languages. IT is currently written in XML Schema but has previously
> been written in DTD and RDF. I would not say that it is BOUND to XML
> Schema anymore than GeoRSS is bound to RSS.  

I can't claim to know enough to meaningfully disagree with this. The
feeling I get is that GML is an excellent modelling language, and a
crappy transport format: without reading some additional information, I
can't know what XML element contains my feature information. (For
example, in WFS, it is featureMember, but in other examples, it is not.)
I don't know if this is caused by an adherence to XML Schema, but this
has been my understanding. In any case, it seems clear that GML is
designed for something that GeoRSS Simple is not. 

> It is intended to support
> the encoding of geometric and feature objects (models of real world
> things) in a uniform way and this makes the encoding structure more
> complex than GeoRSS NS, but no more than KML.

Absolutely. GeoRSS is targeting the 'simplest thing' subset. GML/KML do
not.

>  * GeoRSS GML uses gml properties in the reverse way that every other
>    GML example on the web seems to use them. (i've been using lots of
>    WFS servers via OpenLayers, and they always spit out x,y, not y,x).
>    As a result of this, we should make it VERY CLEAR on all pages that
>    we are using y,x. This probably means that we should add examples
>    that are in places like new zealand, and hawaii: well outside the
>    comfortable -90 -> 90 box where there can be confusion. 
> 
> I am not at all sure what this means?  GML properties have no
> pre-assigned order of any kind. If you mean the order of coordinates in
> a tuple as in <gml:coordinates> or <gml:pos> the order is determined by
> the associated coordinate reference system, and NOTHING ELSE.  

The default CRS choice for GeoRSS does not seem to match the output of
WFS servers claiming to serve data as EPSG:4326. You're right that this
is not a GML limitation, but instead a description of the data of the
content. 

> It is NOT
> fixed anywhere in GML.  We can thus have coordinate systems (assuming
> here we are talking about geographic coordinates) in which the order is
> (lat,lon) and ones in which it is (lon, lat). This is simply a matter of
> what CRS you choose to reference. 

Yes.

> No more and no less.  Note that
> talking about x,y or y,x is not very meaningful (completely so
> independent of a coordinate reference system). 

You are correct. I meant to say 'lat,lon is what GeoRSS uses inside all
of its coordinate properties, simple or GML. Most GML I have encountered
uses lon,lat inside its properties when asked for EPSG:4326.' Again, I
don't really know enough to know whether this is right or wrong, I just
whined for a while, and Raj/Josh pushed the issue up the line to
EPSG/spec-based choices :) 

> 
>  * georss:when should be proposed, if people want it. However, in
>    general, GML properties are at best not recommended, and at worst
>    actively discouraged, in favor of two alternatives:
> 
>      * Encoding GML information inside alternative existing
>        atom-friendly namespaces
> 
> What consistitues a friendly namespace?

"Atom-friendly" meaning, in this case, "Already used with Atom", rather
than creating new namespaces and elements to do things which already
exist. I can't speak to georss:when in this case, because I've never
invesitgated the environment around Atom namespacing, which is where
this kind of thing is decided, but there are many communities using Atom
to do many things, and finding one which has a need like this is
probably possible without co-opting GeoRSS for it.

>        your GeoRSS feed, you may want to create/propose a georss:feature
>        property, which then lets you refer to a full GML Feature,
>        including 'time', full gml geometry, etc.
> 
>  
> 
> This is done in KML.  

I don't think this is done in KML. <Metadata> is not this, though it is
something in which something like this could be specified. However,
that's a different level of disagreement that is unrelated to GeoRSS. :)

>  I think this is reasonable.

Excellent.

>  * Styling via KML should probably be a 'best practice' recommendation, 
>    but probably not a 'part of GeoRSS' -- something to be described by
>    example, since it applies equally to all RSS, rather than something
>    that is a normative part of a spec. (The alternatives here are
>    basically KML / SLD -- SLD seems likely to be too complex, and lacks
>    the built in remote-refrence semantics that the KML styling mechanism
>    has -- at least to the knowledge of the participants in the conf
>    call.)
> 
>  
> 
> I think you mean presentation via KML, since styling means the
> interpretation of the GeoRSS for presentation and there is no mechanism
> in KML to express such styling (as in styling GeoRSS to KML via XSLT).

You're right. I apologize for being non-specific. Blame the
establishment we stopped at on our way out of the meeting :)

> I don't understand your comparison of SLD and KML?  KML Style has a very
> different meaning than Style in SLD. The latter is rules that interpret
> content FOR presentation. In the case of KML it IS the presentation. 

I'm not sure I understand the difference. You have content. You want it
to show up a certain color on the map. You can use SLD, or you can use
KML. Yeah? No?

> The
> Style in KML is more like a Style in SVG (KML is more like SVG than GML)
> that is it provides properties of the graphical presentation.

Yes. Does SLD do something different? that was how I understood SLD when
I tried to write it a couple months ago.

>  * GeoRSS GML is a small set of extension (georss:where) wrapped around
>    GML geometry. 
> 
>       The where property is correctly used in the sense of GML. You have
> used a foreign property (in another namespace) to hold a GML object
> (geometry) - and this is correct.

Correct.

> 
>  * Extending GeoRSS should be secondary to well-documented fully
>    exampled current-spec driven code with implementations. There are far
>    more importan things to think about than tweaking the spec to include
>    some niche use case. 
> 
> I would urge GeoRSS to stick to simple and accept what this means in
> terms of what can and cannot be done with it. That route leads to
> success.

I agree with that. I have a feeling that others on the list will
disagree. In fact, I would not complain if georss GML went away entirely
-- any GML encoding should be done on a GML feature inside a seperate
element -- but I know I'm in the minority on this. I do think that
regardless of the spec-level decisions of GeoRSS GML, simple should be
where examples concentrate first.

Regards,
-- 
Christopher Schmidt
Web Developer
_______________________________________________
georss mailing list
georss at lists.eogeo.org
http://lists.eogeo.org/mailman/listinfo/georss