>I think that we agree.
>
>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
..."or below"...
>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.
I agree with (b) -- we'll lose too many
>--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
