I believe you would give the GIS system the floors value, but it will
not be sent in DHC, but rather a PIDF-LO, where we've already agreed
floors would be in the civic part of the PIDF-LO, so the GIS system
should be able to determine what is being indicated fairly easily
(i.e., the x/y is 4326, and the altitude is in civic floors, and not
a misunderstanding of 4979).
James
At 12:39 PM 6/11/2009, Richard Barnes wrote:
>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
