AW: draft-mayrhofer-geopriv-geo-uri-00

"Alexander Mayrhofer" <alexander.mayrhofer@nic.at> Tue, 27 May 2008 16:06 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BFE93A6C34; Tue, 27 May 2008 09:06:43 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CABB228C1F7 for <ietf@core3.amsl.com>; Mon, 26 May 2008 23:17:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.826
X-Spam-Level:
X-Spam-Status: No, score=-4.826 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_AT=0.424, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+v6JEE4DO35 for <ietf@core3.amsl.com>; Mon, 26 May 2008 23:17:10 -0700 (PDT)
Received: from mail.sbg.nic.at (unknown [192.174.68.200]) by core3.amsl.com (Postfix) with ESMTP id 5246528C1DB for <ietf@ietf.org>; Mon, 26 May 2008 23:17:09 -0700 (PDT)
Received: from localhost [127.0.0.1] by mail.sbg.nic.at with XWall v3.42 ; Tue, 27 May 2008 08:17:12 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: AW: draft-mayrhofer-geopriv-geo-uri-00
Date: Tue, 27 May 2008 08:17:12 +0200
Message-ID: <8BC845943058D844ABFC73D2220D4665075B2600@nics-mail.sbg.nic.at>
In-Reply-To: <1265635667.20080521103209@pobox.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-mayrhofer-geopriv-geo-uri-00
Thread-Index: Aci7aKR/MtmvzuG9TIe5T487e5dc7wEVaihw
References: <1265635667.20080521103209@pobox.com>
From: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
To: Bill McQuillan <McQuilWP@pobox.com>, IETF Discussion <ietf@ietf.org>
X-Mailman-Approved-At: Tue, 27 May 2008 09:06:36 -0700
Cc: Christian Spanring <spanring@oir.at>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

 
Bill,

thanks for taking the time to review the document. Comments inline.

> Section 2. Introduction
>    [use of WGS84 reference system]
> 
> I wonder if it might be more forward thinking to allow for 
> the optional
> specification of the reference system being used. Perhaps 
> this could be one
> of the "URI parameters" mentioned in section 4.7

We had a long discussion about that when we started work on this
document. From the standpoint of a geographer, it would of course be
beneficiary to have multiple reference systems. 

However, from the standpoint of a common user, reference systems "do not
exist" (excuse te pun). "Coordinates" is what they read from the display
of their GPSr, or what pops up on <name favourite web mapping service>
when they click on a location.

For the sake of simplicity, we therefore decided to go for a single
reference system, and use the most predominant one. I know that
especially in the US, many maps are in NAD83 - however, i think that
WGS84 is by far the most common one in the applications that we have in
mind. Many other geo-formats mandate WGS84 as well (eg. RFC 1876).

We could, of course, add a parameter to indicate the reference system.
But:

- If parameters are optional (as we intend them to be), a parameter must
not change the meaning of the base URI components. An unknown (or
ignored) reference system might lead to interpretation of the lat/lon
components in a completely wrong way (eg. NAD83 vs WGS84 can be a couple
of 100 meters, which led to stranded cargo ships)

We could work around this if we require an application to ignore a URI
with parameters unknown to the application. 

However, there might be two classes of parameters then: "important" ones
that change the meaning of the URI completely (like reference system),
or "optional" ones that only provide more information (like a label,
uncertainty, etc..) [ok, i don't want to go down the rathole whether
"uncertainty" changes the core meaning of the coordinates]

Our conclusion was that we'd only go for more reference systems once
there is strong opinion that this is really needed. I've not seen much
use of other reference systems in other geo-formats on the internet -
essentially everybody uses WGS 84.

We'd of course appreciate comments on this.

> Section 4.4.1 Component Description
>    The number of decimal places indicates the precision of the value.
>    One degree equals 111.319,45m at the equator (40.075,004km / 360
>    degree).  Five decimal places (0.00001 degree) seem to imply a for
>    civil use sufficient accuracy.

hm.. This part of the document seems to be a leftover. We decided that a
"point is a point is a point", and any interpretation of numbers of
digits is flawed (for reference, check the "binary lci" discussions
around revision of RFC 3825).

We'll probably remove that text in the next revision, unless there are
strong opinions that the number of digits should be interpreted to
represent ... uhm.. something.

> Section 6. GML Mappings
> 
> There seems to be no explanation of what GML is, not even a Reference
> document.

Will add. I was busy with printing it out (450 pages) so that i forgot
the reference.

> Section 9.1.  Invalid Locations
> 
> Is there a recommended way to represent the poles? Dare I 
> suggest <geo:90>
> and <geo:-90>? If that is too much of a special case, should 
> the longitude
> always be zero or can it be anything between -180.00000 and 180.00000?

Good point. We will think about it. I'm a bit biased towards not
changing the ABNF, and adding text like "The poles SHOULD be represented
with the longitude component set to 0, however, applications SHOULD
accept URI instances with longitude component set to any value between
-180 and 180"... (be conservative in what you send, and liberate in what
you accept).

Opinions?

> Section 9.2.  Location Privcay
> 
> Typo: .................Privacy

Thanks - will change.

Alex

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf