[georss] Quick Fire Summary
Allan Doyle
adoyle at eogeo.org
Mon Apr 30 12:47:06 EDT 2007
On Apr 30, 2007, at 12:41, Carl Reed OGC Account wrote:
> Hi Allan -
>
> I that actually WMS 1.1.1 is by far the most widely implemented
> version of WMS.
Right. Thanks. Too many "3"'s flying around...
>
> Cheers
>
> Carl
>
> ----- Original Message ----- From: "Allan Doyle" <adoyle at eogeo.org>
> To: <georss at lists.eogeo.org>
> Sent: Monday, April 30, 2007 10:18 AM
> Subject: Re: [georss] Quick Fire Summary
>
>
>>
>> On Apr 30, 2007, at 12:02, Peter Borissow wrote:
>>
>>> The CRS discussion has been alittle difficult to follow and someone
>>> definately needs to clarify the axis order question. Specifically:
>>>
>>> Is GeoRSS Simple lat/long or long/lat?
>>
>> GeoRSS Simple is lat/long
>>
>>>
>>> Is EPSG 4326 lat/long or long/lat? I'd love to see a specific
>>> reference document/spec that clarifies this!
>>
>> EPSG 4326 is lat/long.
>>
>> The history of the confusion stems from ca. 1999 when the OGC WMS
>> spec was defined to use EPSG codes for the CRS but the bbox values
>> were defined as decimal degrees in long/lat order.
>>
>> This was fine for a while until the EPSG purists at OGC realized what
>> was happening so WMS 1.3 actually changes the order for EPSG:4326.
>>
>> That caused another uproar and there's now a new code that you're
>> supposed to use when you want WGS84 with decimal degrees in lon/lat
>> order.
>>
>> However, the EPSG:4326 genie is out of the bottle. There was little
>> interest at OGC in a compromise that said "do the math according to
>> the EPSG values, but let the WMS representation be long/lat".
>>
>> This is one reason why WMS 1.1.3 is the most popular version.
>>
>> Allan
>>
>>>
>>>
>>> Thanks,
>>> Peter
>>>
>>>
>>> ----- Original Message ----
>>> From: Carl Reed OGC Account <creed at opengeospatial.org>
>>> To: georss at lists.eogeo.org; Christopher Schmidt
>>> <crschmidt at metacarta.com>
>>> Sent: Monday, April 30, 2007 10:34:42 AM
>>> Subject: Re: [georss] Quick Fire Summary
>>>
>>>
>>> Chris -
>>>
>>> Thanks for the notes on the meeting. Checked out the new drupal
>>> based site.
>>> No problems, although some of the colors used for headings are a
>>> bit washed
>>> out.
>>>
>>> On another topic, I happened to read more closely the section on
>>> CRS. Don't
>>> ask me why - perhaps because in the OGC right now there is a major
>>> discussion and new member collaboration on defining a common
>>> coordinate
>>> model.
>>>
>>> Anyway, the paragraph on CRS is a bit confusing and perhaps
>>> misleading. I
>>> know that we want to keep discussions on such topics as CRS a
>>> simple as
>>> possible. So perhaps a bit of rewording and some references might
>>> be in
>>> order. I am happy to take this on and provide the text for
>>> consideration.
>>>
>>> Finally, what is GeoRSS NS? - not simple :-)
>>>
>>> Thanks
>>>
>>> Carl
>>>
>>> ----- Original Message -----
>>> From: "Christopher Schmidt" <crschmidt at metacarta.com>
>>> To: <georss at lists.eogeo.org>
>>> Sent: Friday, April 27, 2007 6:21 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
>>>
>>> _______________________________________________
>>> 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
>>
>> --
>> Allan Doyle
>> +1.781.433.2695
>> adoyle at eogeo.org
>>
>>
>>
>> _______________________________________________
>> georss mailing list
>> georss at lists.eogeo.org
>> http://lists.eogeo.org/mailman/listinfo/georss
>
--
Allan Doyle
+1.781.433.2695
adoyle at eogeo.org
More information about the georss
mailing list