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
