[georss] Quick Fire Summary

[Ron Lake]

See comments inline.

Ron

 

Quickfire summary of discussion during GeoRSS meeting. (I'm slightly

inebrietaed, so anything you have questions about, please reply rather

than assume the worst):

 

 * 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.  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.

 

 * 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.  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.  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). IN mathematics the items
x,y when talking about coordinates 1st and second as in - given a point
P x(P) = 1st coordinate of P.

 

 * 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?

     

     * Creating a "gml feature" property into which a full GML feature

       can be added -- so, if you need to transport GML information with

       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 think this is reasonable.

 

 * 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).
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. 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.

 

 * Visualization of GeoRSS in *feed readers* -- that is, making clear

   to the general world that creating a georss feed has value to

   feed consumers, rather than just producers and gis consumers.

   Bloglines, NetNewsWire, even Firefox should *do something with the

   geo* -- the lack of geo support puts geo producers in a crappy

   situation.

     * Mime type doesn't help this. There are no applications to pass

       the mime type off to. Once there are, then it makes sense to

       re-discuss the mime type issue.

 

In general: 

 

 * GeoRSS Simple is Simple Feature definition for the content-based web.

      It is not a feature definition - it is just geometry.

 * 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.

 * 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.

 * GeoRSS needs to get RSS readers to understand Geo. This is the single

   thing that most limits adoption -- no feedreaders with Geo support

   means no incentive to publish geo in RSS.

 * Styling is cool. Needed for some cases, not for most.

 * GeoRSS uses a simple feature encoding that is good for lots of things

   that aren't RSS. Accentuate that via examples and prose.

 

I think that's the essence of our conversation. Again, this isn't a

smoke-filled room: arguments welcome :)

 

-- 

Christopher Schmidt

Boy Genius, MetaCarta  

_______________________________________________

georss mailing list

georss at lists.eogeo.org

http://lists.eogeo.org/mailman/listinfo/georss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.eogeo.org/pipermail/georss/attachments/20070427/0456898a/attachment-0001.html 
-------------- next part --------------
_______________________________________________
georss mailing list
georss at lists.eogeo.org
http://lists.eogeo.org/mailman/listinfo/georss