Re: "geo:" URIs

Hello Alex,

Thanks a lot for your contribution to our discussions!

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.
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.

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



On Mon, Jun 27, 2011 at 10:55 AM, Alexander Mayrhofer
<> wrote:
> Hello,
> I'm one of the co-authors of RFC5870 - the "geo:" URI specification [1].
> Since there has been some discussion about the URI scheme on this list,
> i'd like to give my (obviously biased ;) view on how the POI spec could
> benefit from the "geo:" URI. I understand that ISSUE-37 has been raised
> specifically for the question whether or not geo: URIs should be used in
> the specs, however, other raised issues might be touched by it as well:
> - ISSUE-37: (obvious)
> - ISSUE-19: The "geo:" URI by definition does specify an identifier for
> a point in space (optionally "diluted" by an uncertainty parameter) -
> therefore, it would be a very compact, "geek-readable" and well
> specified way of representing a Point. Lines and Polygons, however, are
> obviously not supported. Note that lot of work went into making the
> specification as precise and umanbigious as possible (read through
> Section 3.4 of RFC 5870), and it was reviewed over and over by the
> Geospatial community as well as the IETF (internet) community.
> - ISSUE-21: A "geo:" URI always includes the specification of a
> Coordinate Reference System. A lot of work in "geo:" URI went into
> agreeing on a default Coordinate Reference System (WGS-84), but still
> allowing for a maximum of flexibility. A Registry was created at IANA
> which allows for the inclusion of more Reference Systems if needed [2].
> - ISSUE-14: Having worked on the "geo:" URI specification for more than
> 3 years, i can only urge you to make use of other standards where you
> can. If you can't use the whole standard, then refer to bits and pieces.
> It saves a lot of work and pain to not re-define the semantics of
> individual fields. Re-use where you can from stable standards. For
> example, don't start doing your own definition of lat/lon when there's
> text that has been reviewed and approved by both the geospatial as well
> as the internet community (whether that's geoURI, geoJSON, PIDF-LO... it
> doesn't really matter - but don't re-invent the wheel).
> Hope that helps - i'm more than happy to discuss further details over
> email / chat!
> Alex
> [1]:
> [2]:
> l

Jens de Smit
The Open Technology guy | | @jfdsmit | +31 628 597 403

Received on Tuesday, 28 June 2011 10:12:44 UTC