WGS84+AT0 = 4326
WGS84+AT1 = 4979
WGS84+AT2 = 4326 + civic address w/ floors as a complex (RFC5491)
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of James M. Polk
> Sent: Friday, 12 June 2009 7:52 AM
> To: Richard Barnes; Carl Reed
> Cc: geopriv@ietf.org
> Subject: Re: [Geopriv] #8: Altitude type of 0 == no altitude - Guidance
> from the OGC Geodesy community
>
> Richard
>
> 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
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
