[georss] Quick Fire Summary
Allan Doyle
adoyle at eogeo.org
Mon Apr 30 12:24:33 EDT 2007
Note that GeoRSS Simple and the GeoRSS model *do not* mention EPSG:
4326 at all. I think we should keep it that way.
On Apr 30, 2007, at 12:18, Allan Doyle wrote:
>
> 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
_______________________________________________
georss mailing list
georss at lists.eogeo.org
http://lists.eogeo.org/mailman/listinfo/georss
More information about the georss
mailing list