To be entirely correct you would identify that we are using the lla version of WGS 84, not the ECEF version (i.e. XYZ):
Datum 1 identifies use of WGS 84.
If altitude is not specified (AT=0), then the resulting location uses the CRS identified by the EPSG code of 4326 (define OGC URN..)
If altitude is specified in meters (AT=1), then the resulting location uses the CRS identified by the EPSG code of 4979...
If altitude is specified in floors above a local ground level (AT=2), then the resulting location uses EPSG 4326 and includes a civic address for floors.
We can cover the implications of things like the compound location resulting from use of floors more generally, since this also applies to the other datums registered here.
Note that WGS 84 as a datum (not a CRS) is identified by an EPSG code of 6326. It only becomes 4979 or 4326 with the addition of a coordinate system (6423, 6422). I don't think that we need to be that pedantic a) because 3825 (currently) doesn't have any provision for anything other than Lat/Lng/Alt and b) that's way more detail than I think most folks are willing to tolerate.
--Martin
> -----Original Message-----
> From: James M. Polk [mailto:jmpolk@cisco.com]
> Sent: Friday, 12 June 2009 2:53 PM
> To: Thomson, Martin; Richard Barnes; Carl Reed
> Cc: geopriv@ietf.org
> Subject: RE: [Geopriv] #8: Altitude type of 0 == no altitude - Guidance
> from the OGC Geodesy community
>
> Martin
>
> I was working from the proposed text for AI#1 (EPSG correction) which
> states which WGS-84 is present.
>
> Stating how you have it below:
>
> "Stating that datum 1 is 4979 for AT 1, and 4326 for
> AT 0 or 2 is OK."
>
> is from a different starting (or leaning) point than I thought we
> were at (given Richard's proposed text).
>
> I'd prefer to state something like this
>
> Datum 1 is WGS-84. If Altitude = 1 (AT=1), then it is 4979;
> if there is no altitude (AT=0) or altitude is measured in
> floors
> (AT=2), then it is 4326.
>
> This is more in line with what we originally wanted in 3825, but
> messed up by specifying 4327 (which is an old version of WGS-84 3D),
> coupled with being perhaps too close to the reliance on AT=_ field
> that didn't end up being that clear to those not involved in the WG
> then (which is a flaw).
>
> James
>
> At 10:43 PM 6/11/2009, Thomson, Martin wrote:
> >I don't believe that this is a good idea. There is nothing that
> >states that we must have 1-1 mappings for the "datum" field and the
> >CRS code used. It also allows opens the possibility of having
> >different error conditions where the data is rejected by the
> >recipient. Further, it uses more code points from a space of only
> eight.
> >
> >Stating that datum 1 is 4979 for AT 1, and 4326 for AT 0 or 2 is OK.
> >
> >It does mean that the definition of an altitude type also needs to
> >define how this affects each datum, but that fact doesn't change no
> >matter which approach you take.
> >
> > > -----Original Message-----
> > > From: James M. Polk [mailto:jmpolk@cisco.com]
> > > Sent: Friday, 12 June 2009 12:25 PM
> > > To: Thomson, Martin; Richard Barnes; Carl Reed
> > > Cc: geopriv@ietf.org
> > > Subject: RE: [Geopriv] #8: Altitude type of 0 == no altitude -
> Guidance
> > > from the OGC Geodesy community
> > >
> > > This changes the datum IANA registrations, I believe.
> > >
> > > This affects what text we put as AI#1 (the EPSG correction).
> > >
> > > I suggest we change
> > >
> > > datum#1 to 4979
> > >
> > > This keeps the best backwards compatibility with 3825.
> > >
> > > We augment the text to say if datum=1 (4979) there MUST be AT=1
> > > (altitude in meters) present as well (even if the value is 0
> > > altitude, which means at MSL, or whatever the GML guys say is 0m
> for
> > > WGS-84).
> > >
> > > Then we add (and IANA register)
> > >
> > > datum#4, as 4326 under 1 of 2 possibilities:
> > >
> > > - we allow AT=0 to mean x/y with no altitude
> > > - we allow AT=2 to mean x/y with civic floors as altitude
> > >
> > > with something to the effect of
> > >
> > > "Datum#4 MUST have AT=0 or AT=2"
> > >
> > > James
> > >
> > > At 06:37 PM 6/11/2009, Thomson, Martin wrote:
> > > >James said it for me.
> > > >
> > > >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]
> > >
> >
> >----------------------------------------------------------------------
> --------------------------
> >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]
>
------------------------------------------------------------------------------------------------
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
