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