[georss] Quick Fire Summary

[Peter Borissow]

Thanks for the summary Christopher.

Was there any discussion as to when multiple geometries and "georss:when" might be introduced? The following paragraph suggests that these 2 proposals might be off the table:

"Extending GeoRSS should be secondary to well-documented fully exampled current-spec driven code with implementations. There are far more important things to think about than tweaking the spec to include some niche use case."


Thanks,
Peter


----- Original Message ----
From: Christopher Schmidt <crschmidt at metacarta.com>
To: georss at lists.eogeo.org
Sent: Friday, April 27, 2007 8:21:26 PM
Subject: [georss] Quick Fire Summary


Quickfire summary of discussion during GeoRSS meeting. (I'm slightly
inebrietaed, so anything you have questions about, please reply rather
than assume the worst):

* The GeoRSS Drupal website is ready to go. On Monday, we will switch
   the site to the Drupal site. If you have problems with the drupal
   site ( http://georss.org/drupal/ ) speak this weekend to get them
   fixed. 

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

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

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

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

* 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.
* GeoRSS GML is a small set of extension (georss:where) wrapped around
   GML geometry. 
* 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. 
* 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

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
_______________________________________________
georss mailing list
georss at lists.eogeo.org
http://lists.eogeo.org/mailman/listinfo/georss