>
> It has to be, if the server can't figure out what the altitude of the
> client is, then the easiest way to to tell the client this is to use
> datum EPSG:4326 and altitude type of '0'.
>
> We could sidestep having 2 WGS-84 datums registered and simply have
> 4979 delivered with an altitude type of '0', meaning servers only
> ever have to remember 1 WGS-84 datum (4979) and if there is an
> altitude, include the type (and altitude value). If there is no
> altitude value, set the altitude type to 0, which the client converts
> to 4326 if it informs another entity its location.
I think it would be logically flawed to return 4979 without an altitude
- that's what 4326 is for. Plus, i feel it would also be incorrect to
use 4979 with Altitude Type 2 (floors), because that's not what 4979
uses as the value for the third dimension.
Therefore, i think allowing only the following makes sense:
- 4326 with AT 0 or 2
- 4979 with AT 1
Everything else does - strictly speaking - not "fit" the definitions of
the reference systems.
> > Q: what meaning is attached to altitude type 0?
>
> IMO - that there is no altitude given (or guessed or whatever)
Agreed.
It's a different story what a consumer of such data may assume. For
example, what we use in the "geo" URI is that the client MAY assume that
this means "on earth's surface" (on ground, or on surface of water
bodies), which seems "natural" to what people would expect from
coordinate pair without altitude.
>
> > Q: what is the impact of having no altitude on the existing datum
> > definitions?
>
> In WGS-84, the difference is merely either you're in 2D or 3D.
+1
> We could extend that rule to being applicable to all datum pairs. For
> example, NAV83 (horizontal) paired with NAVD88 (vertical).
Seems logical, but - obviously - someone more familiar with those
reference systems than me would need to take a look at this :-)
Alex
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
