In the case of "floors", I do not think that this would be dishonest as the
number of floors us actually a property of the coordinate location and not
of the coordinate itself. This is the approach we took when developing the
CAP standard in OASIS. "Floors" would be no different than a building type
or type of floor (parking, maintenance, office).
Hope this helps.
Carl
----- Original Message -----
From: "Richard Barnes" <rbarnes@bbn.com>
To: "Carl Reed" <creed@opengeospatial.org>
Cc: "Alexander Mayrhofer" <alexander.mayrhofer@nic.at>; "James M. Polk"
<jmpolk@cisco.com>; <geopriv@ietf.org>
Sent: Thursday, June 11, 2009 11:39 AM
Subject: Re: [Geopriv] #8: Altitude type of 0 == no altitude - Guidance from
the OGC Geodesy community
> Carl,
>
> 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
