Thanks for assembling this information. I believe the current approach
for WGS84 is to have a single indicator for WGS84 in the Datum field,
but to specify that the underlying CRS is either 4326 or 4979, depending
on the Altitude Type field (i.e., if an altitude in meters is present
(AT=1), then the CRS is 4979; if no altitude (AT=0), then 4326).
The only subtlety arises when there is an altitude, but it is expressed
in floors (AT=2). In this case, the CRS for the lat/long is clearly
4326, but then again, 4326 doesn't have any altitude. Would it be too
dishonest meld the two? You might envision some text like "The lat/long
represent a 2-D point in the ESPG 4326 CRS, while the altitude
represents the floor designator in a building sited on that point."
Perhaps the fact that "floor" is more of a civic address designator
(rather than a geodetic concept) could help forgive this mingling. That
is, if you were taking the location information from a DHCP option and
giving it to, e.g., a GIS system, you wouldn't pass on the "floors"
attribute anyway, so you really would be giving it EPSG 4325 information.
--Richard
Carl Reed wrote:
> All -
>
> The following is guidance provided by the OGC CRS Domain Working Group.
>
> The fundamental concern of the group is that interoperability be
> enabled. As such, the EPSG codes need to be used correctly and in the
> proper context. Deviations from what a particular code "means" in terms
> of the metadata for a given CRS must be properly documented. The OGC
> members have begun using the term "honesty" WRT CRS codes and deviations
> in their use from what is actually in the EPSG database. In other words,
> if the CRS code states that the software should expect latitude and
> longitude only, you shouldn't slip in a height, depth or whatever, not
> even if you document that separately. Otherwise, interoperability is
> comprimised.
>
> Now, from the experts:
>
> 1. Code 4326 refers to WGS 84 two-dimensional Geographic CRS. You use
> that when you only have WGS 84 latitude and longitude - no
> elevation/altitude
> 2. Code 4979 refers to WGS 84 three-dimensional Geographical CRS. This
> is used to describe the situation where you have WGS 84 latitude,
> longitude plus ellipsoidal height (the latter also in WGS 84 of course).
> This is GPS content.
> 3. Another possibility is where Geocentric X,Y,Z is available in which
> case the correct CRS describing those coordinates is code 4978.
> 4. If the altitude is above MSL, then you need to use what is called a
> compound CRS. So, if there is an "altitude" or "z-value, where a user
> has WGS 84 latitude and longitude, supplemented by e.g. Mean Sea Level
> (MSL) height, then this be modelled as a Compound CRS. No EPSG code is
> readily available for this situation, as there are many different
> Vertical CRSs that are based on MSL one way or another.
>
> In other words, if code 4326 is used, then elevation (altitude) should
> not be expressed. There is an ISO document 19111: Spatial Referencing by
> Coordinates that provides the conceptual model for coordinate systems
> and coordinate reference systems. This model provides the fundamentals
> and underpins the CRS work for the EPSG database as well as the use of
> CRS in the OGC.
>
> So, in conclusion, the best solution is to allow multiple codes so that
> we have truth in advertizing - use the correct code for the coordinates
> being encodes and communicated. I know that this group strives for
> simplicity but unfortunately - regardless of what the neogeographers
> would like - expressing a simple point coordinate is not necessarily so
> simply - especially if elevation/altitude is considered.
>
> Of course, one can ignore geodetic best practice and "pick" the best
> overall solution and document in the spec as such.
>
> Not sure if this all helps :-)
>
> Carl
> OGC
>
>
>
> ----- Original Message ----- From: "James M. Polk" <jmpolk@cisco.com>
> To: "Richard Barnes" <rbarnes@bbn.com>; "Alexander Mayrhofer"
> <alexander.mayrhofer@nic.at>
> Cc: <geopriv@ietf.org>
> Sent: Wednesday, June 10, 2009 11:03 AM
> Subject: Re: [Geopriv] [geopriv] #8: Altitude type of 0 == no altitude
>
>
>> At 06:22 AM 6/10/2009, Richard Barnes wrote:
>>> This line of reasoning makes sense to me (and I don't see anyone
>>> really disagreeing with it?)
>>>
>>> Does this mean that we should recommend that each datum value that's
>>> defined provide a definition
>>
>> ...and IANA registration (right?)...
>>
>>> 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
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
