disagreeing with it?)
Does this mean that we should recommend that each datum value that's
defined provide a definition for both a 2D (AT=0,2) and 3D
representations (AT=1)? These could be the same thing, but it might be
useful to note that sometimes a datum value implicitly refers to two
things, distinguished by the AT value.
--Richard
Alexander Mayrhofer wrote:
>>> Q: is altitude type 0 valid?
>> 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
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
