W3C home > Mailing lists > Public > public-poiwg@w3.org > June 2011

AW: "geo:" URIs

From: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
Date: Tue, 28 Jun 2011 15:11:14 +0200
Message-ID: <8BC845943058D844ABFC73D2220D46650A8C80CC@nics-mail.sbg.nic.at>
To: Jens de Smit <jens@layar.com>
CC: <public-poiwg@w3c.org>
> I've read through RFC5870 quickly and the main issue I take away from
it right
> now is that it specifically (as you already mentioned) addresses the
encoding
> of points, and nothing more complex than that.

You're prefectly right, it does only do Points.

> I believe many participants in this group have expressed a desire to
encode
> more complex geometries than that. For this reason, Raj Singh has
expressed
> his, also obviously biased :P, preference for GML/CityGML
(specifically,
> GeoRSS' profile of it), which also has a rather concise method of
expressing
> points, as well as methods for extending this into lines and polygons.
> Because the default CRS there is also WGS-84, I believe it is rather
easy to
> map those point markups to RFC5870 URIs.

I understand that, and i do believe that because of that, other
standards to express geospatial data would probable be a better fit, and
definitely the only option for thing beyond Points. However, It would be
great if the specification would include instructions on how to map a
"Point" POI onto a geo: URI.

Furthermore, what i tried to express with my previous message is that
you probably can take bits and pieces (or maybe even text) from RFC 5870
if you want to avoid the tremendous work of being very specific what a
certain field means in your spec. For  example, we found out that
stating "those are WGS-84 coordinates" is not precise enough, for
example:

- Is it decimal or radian degrees?
- Is there any significance in the number of digits  (we're saying that
78.56 is precisely the same as 78.56000 - it's misleading to interpret
the number of digits as any form of precision of the measurement)
- What about data "beyond" the "edges" (180/-180, 90/-90)?
- How are  two different geo: URIs compared? When are they identical?
- When are coordinates in a "geo:" URI considered broken?
- What's the precise definition of the "altitude"? What's it relative
to? 
- Do we allow any CRS, or (for the sake of interopability and ease of
implementation) limit that to a reasonable subset?

etc.. etc..

So, even if you can't make use of the "geo:" spec itself, then please
check whether you can re-use specifications from there. This was a lot
of work for RFC 5870, and i'd rather not want anybody else repeating
that task ;)

Also, RFC 5870 requires that if a new CRS is registered for use with the
"geo:" URI, a detailed spec of the x/y/z components must be submitted
and published, which ensures similar quality of the specification of
other CRSes. POI could re-use that registry as well.

> The one thing I don't like about GML is, that as soon as you want to
do 3-
> dimensional points, you have to explicitly specify <gml:Point
> srsName="urn:ogc:def:crs:EPSG:6.6:4979" srsDimension="3"> which is
very
> verbose. RFC5870 makes this easier, but otherwise I'm not yet
convinced
> that RFC5870 is superior to the GML profile. But, since you have spent
a lot
> more time on this, perhaps you could make us see otherwise?

RFC 5870 is definitely not superior to the GML profile in flexibility.
It's a different format that was optimized for length and the
requirements of an URI scheme. And, to your question: No, i don't know
whether there's a shorter way to express 3D-coordinates - maybe one can
define a default srs further up in the GML tag tree?

Alex
Received on Tuesday, 28 June 2011 13:11:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:48:30 UTC