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.
> Examples don't need srsDimension specified.
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
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
