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

From: Bill McQuillan <[email-masked]>
Date: Wed, 21 May 2008 10:32:09 -0700

While reading through this ID: A Uniform Resource Identifier for Geographic
Locations ('geo' URI), I found several minor issues.

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

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.

To my American eye the decimal notation (partially) used here was jaring.
Searching (briefly) for some sort of presentation standard in an RFC or
other technical document was unsuccessful. Is the use of "." and ","
standardized in the representation of real numbers in RFCs?

Section 6. GML Mappings

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

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?

Section 9.2.  Location Privcay

Typo: .................Privacy

-- 
Bill McQuillan <[email-masked]>

_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Mr Kim Sanders <[email-masked]>
Date: Wed, 21 May 2008 22:16:48 -0600

While I cannot comment specifically about RFC style, I can say (from my 
study of the use of language globally) that there are several conventions in 
use for numerical notation using the numerals 0-9, depending on usage.
- The point/period/full stop may be used to separate whole numbers from 
values smaller than 1; alternatively, the comma may be.
- Then comes the possible issue of separation on either side of the decimal, 
whether every second, every third, or every fourth place.
- If the decimal point is used, to use your terminology, then one may find a 
space or a comma as a separator on either or both sides of the decimal.
- If the decimal comma is used, then one may find a space or point as a 
separator on either or both sides of the decimal.
By the way, the word is jarring, not jaring, according to laws governing 
regular English spelling conventions worldwide.  Jaring implies a verb jare, 
the way I understand the use of English, regardless of location.
/Kim.

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Tue, 27 May 2008 08:17:12 +0200

Bill,

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

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

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

> There seems to be no explanation of what GML is, not even a Reference

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

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

> Typo: .................Privacy

Thanks - will change.

Alex