[georss] Quick Fire Summary

Raj Singh raj at rajsingh.org
Tue May 1 03:54:17 EDT 2007 

We also discussed having a "put-your-money-where-your-mouth-is"  
requirement--a few client and server implementations should exist  
before new functionality could go in.
---
Raj


On Apr 30, 2007, at 11:55 PM, Andrew Turner wrote:

> Hi Brian, sorry about the confusion - these two proposals get to be
> the guinea pigs. :)
>
> As Josh said, the idea is that you would put up the final proposal as
> a page on the new site. We've already discussed it a lot, so there may
> be little commenting, but anyone is free to add comments, and then you
> can amend the proposal.
>
> Then we'll call for a vote/poll on it.
>
> The general consensus at the meeting I referred to was that it would
> probably go in, but it wasn't clear in what format. However, it's all
> up to the community. This is just a process to help actually move it
> along rather than leaving it to infinite-email-discussion. :)
>
> Andrew
>
> On 4/30/07, Joshua Lieberman <josh at oklieb.net> wrote:
>> 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
>>
>> _______________________________________________
>> 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

_______________________________________________
georss mailing list
georss at lists.eogeo.org
http://lists.eogeo.org/mailman/listinfo/georss

More information about the georss mailing list