[georss] Quick Fire Summary
Knoth, Brian D.
bknoth at mitre.org
Tue May 1 07:04:23 EDT 2007
Andrew, Josh:
Ok, thanks for clarifying that.
Just one more question - when we last put something up for vote that I
had recommended, we got a total of about 7 votes (majority favorable or
neutral), but none-the-less, apparently not enough to spur any
decision. Do you have a minimum criteria of voting results that you
expect in order to seriously take action on those results? To be
honest, I've see about 10-15 distinct people who post to this list, so
would that amount of votes carry any weight?
Thanks and I apologize if I'm asking questions that have already been
addressed in the meetings that you've had.
Regards,
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 11:56 PM
To: Joshua Lieberman
Cc: georss at lists.eogeo.org
Subject: Re: [georss] Quick Fire Summary
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