[georss] Quick Fire Summary

Joshua Lieberman josh at oklieb.net
Mon Apr 30 23:05:59 EDT 2007


Brian,

Whichever way sentiment was running during the meeting, my feeling is  
that it is important to have succinct proposals for those two  
additions. For example, it hasn't ever been finalized what to put  
inside georss:when or where to stop in terms of multi-geometries.  
Then there can be something definite to vote on.

Cheers,

Josh

On Apr 30, 2007, at 2:05 PM, Knoth, Brian D. wrote:

> Hi Andrew,
>
> I could have sworn that your earlier email (attached) was meant to be
> interpreted as georss:when and multi-geometries support in georss was
> accepted and finalized for version 1.1 and that any future feature
> requests would go through the process you just identified.
>
> So, is it that georss:when and multi-geometries still needs to be
> written up and voted on, or have we discussed these two issues enough
> and they are already accepted? I'm confused.
>
> Thanks,
> brian
>
> -----Original Message-----
> From: georss-bounces at lists.eogeo.org
> [mailto:georss-bounces at lists.eogeo.org] On Behalf Of Andrew Turner
> Sent: Monday, April 30, 2007 2:00 PM
> To: Peter Borissow
> Cc: georss at lists.eogeo.org
> Subject: Re: [georss] Quick Fire Summary
>
> This was discussed at the other (smaller attendance) meeting several
> weeks ago. These proposals should be summarized by their respective
> proponents and linked to from this page:
>
> http://georss.org/drupal/proposals
>
> (soon to be without the drupal/)
>
> Then in a week or so we will put up a Poll on that page and open for
> comments. Voting will be by simple majority (if my memory servers
> rigth). The roadmap is to have these resolved and announced at
> Where2.0 at the end of May (GeoRSS 1.1?)
>
> Andrew
>
> On 4/30/07, Peter Borissow <peter.borissow at yahoo.com> wrote:
>> 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
>>
>
>
> -- 
> Andrew Turner
> ajturner at highearthorbit.com      42.2774N x 83.7611W
> http://highearthorbit.com              Ann Arbor, Michigan, USA
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss
>
> From: "Andrew Turner" <ajturner at highearthorbit.com>
> Date: March 30, 2007 6:15:20 PM EDT
> To: <georss at lists.eogeo.org>
> Subject: [georss] GeoRSS meeting review
>
>
> I don't think anyone else sent out a review of the meeting. Allan was
> keeping notes in the IRC channel as the meeting progressed.
>
> Here is a quick summary of what was agreed upon:
> 1) Update the documentation on the website ASAP to fix any
> discrepancies, and make the wording on W3C deprecation stronger
> 2) Keep Simple how it is (with errata fixes)
> 3) Begin to grow GML in future versions. Nominally the roadmap is:
>
> v1.1 - for Where2.0 (May 29)
>  - Add georss:when support
>  - Add GML Multipoint and other multi geometry
>
> v1.2 - for FOSS4G2007 (Sept 24)
>  - Add geo narrative support
>
> For the future, the progression of modifications and extensions will
> be:
> 1. Propose modification/extension on the mailing list for initial
> feedback/discussion
> 2. Proposer drafts a proposal summarizing feature, intended use,
> implications to standard, actual examples of use to the website
> 3. GeoRSS community comments and votes on the proposal (on the site)
> 4. After a short period, if the proposal passes by a simple majority
> it will be brought into the next version, if it "fails", it will
> remain a proposal and provide a recorded document as to what the
> proposer perhaps still used in their own implementation. If at some
> point in the future this extension, or a variant of the
> extension/modification is accepted into a GeoRSS version, then this
> proposal will get an addendum that describes to users of this proposal
> how to migrate this format to the official format.
>
> To these ends, we've migrated the original static HTML site to a
> Drupal CMS that will allow anyone to create an account and post/edit
> content.  In addition, Polls can be added for proposals, and comments
> made on pages.
>
> Currently the site is here until we finish the migration and people
> agree that this is the way to go and that everything looks good to
> actually flip the site to the live one.
>   http://georss.org/drupal/
>
> Let us know what you think of the decisions made above and the new
> site. :)
>
> Andrew
> -- 
> Andrew Turner
> ajturner at highearthorbit.com        42.4266N x 83.4931W
> http://highearthorbit.com              Northville, Michigan, USA
> _______________________________________________
> 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

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


More information about the georss mailing list