At least we're in agreement on the datum/crs thing... :)
> > 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...
>
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.
> > 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.
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.
> > 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..
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
------------------------------------------------------------------------------------------------
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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
