Subject: [Geopriv] Fwd: I-D Action:draft-mayrhofer-geo-uri-02.txt

From: "Alexander Mayrhofer" <[email-masked]>
Date: Mon, 18 Feb 2008 18:00:47 +0100

FYI, this is an update of the 'geo' URI scheme draft presented in Prague
- this revision contains a completely new approach using a "tiling"
scheme, and extented motivation/requirements text.

Feedback appreciated.

cheers

Alex

---------------------------

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : A Uniform Resource Identifier for Geographic
Areas ('geo' URI)
	Author(s)       : A. Mayrhofer, C. Spanring
	Filename        : draft-mayrhofer-geo-uri-02.txt
	Pages           : 15
	Date            : 2008-02-18

This document specifies an Uniform Resource Identifier (URI) for
geographic areas using the 'geo' scheme name.  A 'geo' URI provides a
compact, human-readable, and protocol independent way to identify an
area by means of a hierarchical tiling scheme.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mayrhofer-geo-uri-02.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-mayrhofer-geo-uri-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-mayrhofer-geo-uri-02.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Geopriv mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/geopriv

---

From: Richard Barnes <[email-masked]>
Date: Mon, 18 Feb 2008 16:47:01 -0500

Alex,

Thanks for keeping GEOPRIV informed about your continued work on this 
draft.  As you might have guessed from Mr. Polk's reaction, it might be 
better-received if it were called draft-mayrhofer-geopriv-geo-uri :)

The new way of encoding locations introduced in -02 strikes me as way 
more complicated than it needs to be.  Could you provide some 
explanation as to why you chose that encoding over the much simpler one 
in -01?

Regardless of whether the encoding from -01 or -02 is used, it seems 
like you're trying to convey a simple lat/long point in a compact way. 
IIRC, a lot of the objections raised in Prague were based on the claim 
that by just using two numbers, you're missing a lot of the other 
semantics you get from a GML object (e.g., a coordinate reference 
system).  It seems to me that your document could avoid these objective 
by defining the semantics of a GEO URI in terms of the semantics of a 
specific GML construct.  For instance, suppose the URI format was

GEO-URI = "geo:" coord "," coord
coord = ["-"] 1*DIGIT [. 1*DIGIT]

Then you could define this as meaning the same thing as the following 
GML location (where the URI is <geo:lat,lon>):

<gml:location>
   <gml:Point gml:id="point1" srsName="epsg:4326">
     <gml:coordinates>lat lon</gml:coordinates>
   </gml:Point>
</gml:location>

This way, you could pin down all the details that need to be held 
constant in the GML template.  And as a bonus, there would be a quick 
way to convert from the URI to GML.

Hope this helps,
--Richard

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 18 Feb 2008 16:05:17 -0600

Richard, please don't propagate the use of gml:location and
gml:coordinates.

Altitude would be a nice optional addition:

GEO-URI = "geo:" coord "," coord [ "," coord ]

And you could use the BNF for the XML double type [1], which is a little
more complicated, but would translate directly.

coord = [ "-" ] 1*DIGIT [ "." 1*DIGIT ] [ "e" [ "-" ] 1*DIGIT ]

Ta,
Martin

[1] http://www.w3.org/TR/xmlschema-2/#double

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Richard Barnes
> Sent: Tuesday, 19 February 2008 8:47 AM
> To: Alexander Mayrhofer
> Cc: [email-masked]
> Subject: Re: [Geopriv] Fwd: I-D Action:draft-mayrhofer-geo-uri-02.txt
> 
> Alex,
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Richard Barnes <[email-masked]>
Date: Mon, 18 Feb 2008 18:10:48 -0500

Martin,

I apologize; I had just copied an example from RFC 4119, which, as you 
point out, uses a slightly dated version of GML.

Adding altitude and using the XML double type both seem like good ideas 
to me.  But it is Alex's document, so of course it's his call.  I'm not 
sure how you would express altitude in the -02 encoding.

--Richard

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 18 Feb 2008 17:28:48 -0600

>sure how you would express altitude in the -02 encoding.

not allowing altitude in, would seem a bit shortsighted going forward

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Tue, 19 Feb 2008 17:14:49 +0100

Richard, (and other fellow WG members)

> Thanks for keeping GEOPRIV informed about your continued work 
> on this draft.  As you might have guessed from Mr. Polk's 
> reaction, it might be better-received if it were called 
> draft-mayrhofer-geopriv-geo-uri :)

Thanks for taking the time to look at the draft - this is very
appreciated. I'm more than happy to change the file name in a subsequent
revision - at no time we intended to "hide" from the GEOPRIV group -
quite the contrary! 

> The new way of encoding locations introduced in -02 strikes 
> me as way more complicated than it needs to be.  Could you 
> provide some explanation as to why you chose that encoding 
> over the much simpler one in -01?

Well, it depends what you consider "simpler". If you start from "raw"
coordinates, it's of course more complicated to encode/decode a URI in
the -02 encoding. However, please keep in mind that people who
understand geographic coordinates are most likely a small minority. Even
to the majority of internet users, coordinates itself are just amazingly
long numbers that are hard to read, spell and write, and they have no
specific significance to most people (if you don't believe it, ask a
taxi driver who happily uses a GPS, but has very likely no idea what
spatial coordinates are).

Since one of the goals of the draft is to provide a scheme that is easy
to handle for humans, i had that idea of "tiling", and using a different
encoding scheme than numbers. It's probably more familiar to "common"
people than coordinates, and using a hierarchical identifier scheme is
inline with a lot of other identifiers that everybody deals with almost
on a daily basis, namely:

- domain names
- postal codes
- phone numbers

The hierarchy aspect of the new encoding scheme allows to recognize
"similar" locations by looking at the URI itself - much like people
immediately recognize phone numbers within their local area code. For
example, even without decoding, it's clear that those two "geo" URIs are
related somehow:

  geo:QXHZC     (roughly resembling the area of the city of Vienna,
Austria) 
  geo:QXHZ2JCAS (the location of our office in Vienna, Austria)

compared to:

  geo:ZHIG  

which is a completely different URI, and happens to be spatially
disjoint as well (region around the Island of Mauritius, however, the
capital of Mauritius is similar, again: geo:ZHIOYI).

(those examples were done using a proof-of-concept implementation at
http://nona.net/tool/geouri/ - feel free to play around - there might be
bugs, though.)

> Regardless of whether the encoding from -01 or -02 is used, 
> it seems like you're trying to convey a simple lat/long point 
> in a compact way. 

That's true for the -01 encoding, not for -02. A geo: URI in -02
encoding always reflects an area, which a) gets me around the "point
thickness" problems :) and b) allows reflecting larger areas as well
(see examples below).

> IIRC, a lot of the objections raised in Prague were based on 
> the claim that by just using two numbers, you're missing a 
> lot of the other semantics you get from a GML object (e.g., a 
> coordinate reference system).  It seems to me that your 
> document could avoid these objective by defining the 
> semantics of a GEO URI in terms of the semantics of a 
> Then you could define this as meaning the same thing as the 
> following GML location (where the URI is <geo:lat,lon>):
> 
> <gml:location>
> This way, you could pin down all the details that need to be 
> held constant in the GML template.  And as a bonus, there 
> would be a quick way to convert from the URI to GML.

Point taken regarding the GML mapping / semantics - I can provide a GML
mapping in the next revision - i simply didn't think of that,
actually... expect a "Dereferencing to GML" section in the next
revision..

If you want to reflect location for a point (and potentially altitude)
to a community that is sound with basic GIS concepts, lat/lon is
definitely the way to go - however, as i said above, i tried to look as
things from a different perspective - the "requirements" section in the
document elaborates about the arguments for the new scheme.

Additionally, i think (and i guess you'll agree) that the computational
effort for converting almost any scheme into GML is not really that
relevant - i bet even my mobile phone could do several thousand
conversions per second :-)

However, if the group feels that a simple "geo:<lat>,<lon>[<alt>]"
format would be a better way to move forward, i'm happy to go back to
the -01 encoding scheme, even though i feel it doesn't provide the same
level of usability. 

Comments welcome - i'll be in Philly do discuss things face-to-face,
too.

cheers 

Alex

---

From: "Carl Reed" <[email-masked]>
Date: Tue, 19 Feb 2008 12:29:05 -0700

Martin et. al.

Now that GML 3.2.1 is also an ISO standard, should we update the examples 
and schemas for the GML PIDF-LO document to be consistent?

Regards

Carl