Subject: [Geopriv] draft-ietf-geopriv-geo-uri-00 brief comments

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 4 Jun 2009 02:01:11 -0500

Notes on comparison (which likely cannot be held true if the whole datum thing happens, another reason not to entertain the idea further...):

  Latitude <-90 or >90 should compare as -90 or 90 respectively.

  Longitude <-180 or >180 should compare as lng+360n and lng-360n respectively, where n is such that the longitude ends up in the range (-180,180].

Alternatively you could tighten the abnf, although that significantly harms readability it does remove the problems inferred by S9.1.

A value of 40.323 should compare equal to a value of 40.3230 (I assume that this is what you mean by mathematically equal, but we've had problems with that in the past..)

4.4.3 says that "Hence, an altitude value of 0 MUST NOT be interpreted as "on earth's surface"."  Given that this is occasionally, if rarely, the case you would be better to state: "Hence, an altitude value of 0 cannot automatically be assumed to be either ground or sea level."

4.9 contact can also refer to this WG.

Examples don't need srsDimension specified.

Examples should use the Point forms from RFC 5491 which don't include an explicit EPSG database version in the srsName URN.

--Martin

------------------------------------------------------------------------------------------------
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: "Alexander Mayrhofer" <[email-masked]>
Date: Thu, 4 Jun 2009 10:36:55 +0200

Martin, 

Thanks for the review - comments inline: 

> Notes on comparison (which likely cannot be held true if the 
> whole datum thing happens, another reason not to entertain 
> the idea further...):

That's exactly what my concern would be, too. Comparsion would pretty
much be limited to URIs within one reference system, given that
transformations always involves calculations that have limited
precision. Of course, one could calculate whether one URI was
sufficiently "nearby" another, but that's not equality, which is the
subject of that section of the URI registration, afaik.
 
>   Latitude <-90 or >90 should compare as -90 or 90 respectively.
 
Section 9.4 briefly talks about "invalid locations" (which is possibly
not "sharp" enough, could be renamed to "invalid URIs" - i am tempted to
exclude such "invalid URIs" from comparison. But of course, this is up
for discussion. 

Thinking about it, maybe 4.4.1 should include a description of invalid
URIs (clipping to -90/90 -180/180 respectively?) - again, this limit
would, for example, not apply to reference systems that have "easting"
and "northing" values...

>   Longitude <-180 or >180 should compare as lng+360n and 
> lng-360n respectively, where n is such that the longitude 
> ends up in the range (-180,180].

See above :-)

> Alternatively you could tighten the abnf, although that 
> significantly harms readability it does remove the problems 
> inferred by S9.1.

We had that "tighter" ABNF in an unpublished revision, and a
"non-expert" reviewer found it to be too confusing. But of course, it's
possible to change it that way.
 
> A value of 40.323 should compare equal to a value of 40.3230 
> (I assume that this is what you mean by mathematically equal, 
> but we've had problems with that in the past..)

I'm open to rephrasing that. Please keep in mind i'm
"austrian-german-english" speaker only..

> 4.4.3 says that "Hence, an altitude value of 0 MUST NOT be 
> interpreted as "on earth's surface"."  Given that this is 
> occasionally, if rarely, the case you would be better to 
> state: "Hence, an altitude value of 0 cannot automatically be 
> assumed to be either ground or sea level."

Thanks. Much better wording, will change that accordingly in the next
revision.

> 4.9 contact can also refer to this WG.

Will change.

>From what i get skimming through the documentation, it is an attribute
that can be derived from the crs? Will remove, hence.
 
> Examples should use the Point forms from RFC 5491 which don't 
> include an explicit EPSG database version in the srsName URN.

Ok, will change.

Thanks!

Alex

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 4 Jun 2009 18:24:21 -0500

Hi Alex,

At least we're in agreement on the datum/crs thing... :)

> would, for example, not apply to reference systems that have "easting"

This is a choice.  You can either:

a) restrict values
b) allow any value, but don't define anything regarding comparison (must be exactly the same)
c) allow any value and define comparison rules (clamp latitude to -90/90 and wrap longitude %360)

I see that the abnf only goes a little way towards (a) by limiting the number of digits and the text does (c) only for one specific value.

> possible to change it that way.

It's very easy to make ABNF unreadable.  Good ABNF is possible though:

  uptoninety =  [%x31-38] DIGIT ["." *DIGIT]
  ninety = "90" ["." *"0"] 
  latitude = ["-"] (ninety | uptoninety)

  uptohundred =  2DIGIT ["." *DIGIT]
  hundreds =  "1" %x30-37 DIGIT ["." *DIGIT]
  oneeighty = "180" ["." *"0"] 
  longitude = (["-"] (uptohundred | hundreds)) | oneeighty

That's a complete restriction that should be clear enough.  This prevents -180 longitude.

You do need to consider how hard it is for a user to break this unintentionally.  I don't think that's a big risk, but advising application of Postel's principle might be wise.

> "austrian-german-english" speaker only..

It's so easy to forget...  I'm sorry, this was a major point of contention in the 3825 wars.  It might be appropriate to add an example as above to make this particular point absolutely clear.

--Martin

---

From: Andy Mabbett <[email-masked]>
Date: Tue, 9 Jun 2009 13:12:24 +0100

In message <[email-masked]>, 
"Thomson, Martin" <[email-masked]> writes

>Notes on comparison (which likely cannot be held true if the whole 
>datum thing happens, another reason not to entertain the idea 
>further...)

Why is that a reason not to entertain the idea further?

-- 
Andy Mabbett

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 9 Jun 2009 18:12:19 -0500

The points I made on comparison would not be valid for another CRS.  That means reduced flexibility if a CRS code is introduced.

You need stronger justification for your case than an existence proof.  Aside from the rhetoric, that's all I've seen so far.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Andy Mabbett
> Sent: Tuesday, 9 June 2009 10:12 PM
> To: GEOPRIV
> Subject: Re: [Geopriv] draft-ietf-geopriv-geo-uri-00 brief comments
> 
> In message
> <[email-masked]>,
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv