[georss] Quick Fire Summary
Carl Reed OGC Account
creed at opengeospatial.org
Mon Apr 30 12:12:52 EDT 2007
Peter -
Last December, the OGC members had a large forum discussion on this exact
topic during our December F2F meetings. From that forum, and with approval
of the membership, the following guidance was issued:
.Issue: WMS 1.1.1 and other OGC specifications [tbd] are incorrect in their
specification and examples of the "EPSG:4326" CRS identifier.
.In all cases, implementers and practitioners must:
-a) Use the proper URN identifier scheme for CRS per the "Definition URN
Identifier" (06-023r1) BP and "OWS Common" (05-008) documents.
-b) Use "urn-x:ogc:def:crs:EPSG:6.3:4326" to identify CRS for Geographic
coordinates with properties: datum=WGS84, axis order=Y,X (lat,lon),
uom=degrees, and coordinate representation=decimal degrees. (per 04-024)
-c) Use "urn:x-ogc:def:crs:OGC:1.3:CRS84" to identify CRS for Geographic
coordinates with properties: datum=WGS84, axis order=X,Y (lon,lat),
uom=degrees, and coordinate representation=decimal degrees. (per 04-024)
-In addition, use of the bare string "EPSG:4326" CRS identifier is *strongly
discouraged* because of its inconsistent and often incorrect implementation
and use. Continued use of this CRS identifier creates potentially dangerous
interoperability problems.
The key bullet is (b) in which the correct usage of 4326 is specified. This
is also consistent with ISO 6709. I would strongly encourage GeoRSS to
remain consistent with international best practice.
Regards
Carl
----- Original Message -----
From: "Peter Borissow" <peter.borissow at yahoo.com>
To: "Carl Reed OGC Account" <creed at opengeospatial.org>;
<georss at lists.eogeo.org>; "Christopher Schmidt" <crschmidt at metacarta.com>
Sent: Monday, April 30, 2007 10:02 AM
Subject: Re: [georss] Quick Fire Summary
> 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?
>
> Is EPSG 4326 lat/long or long/lat? I'd love to see a specific reference
> document/spec that clarifies this!
>
>
> 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
More information about the georss
mailing list