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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
