Subject: [Geopriv] [geopriv] #8: Altitude type of 0 == no altitude

From: "geopriv issue tracker" <[email-masked]>
Date: Tue, 09 Jun 2009 04:25:52 -0000

#8: Altitude type of 0 == no altitude
---------------------------------------+------------------------------------
 Reporter:  [email-masked]  |       Owner:          
     Type:  defect                     |      Status:  new     
 Priority:  major                      |   Milestone:          
Component:  rfc3825bis                 |     Version:          
 Severity:  -                          |    Keywords:  altitude
---------------------------------------+------------------------------------
 RFC 3825 seems to indicate that an altitude type of 0 indicates that there
 is no altitude defined.  This needs to be clearer in the bis.

 Q: is altitude type 0 valid?

 Q: what meaning is attached to altitude type 0?

 Q: what is the impact of having no altitude on the existing datum
 definitions?

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/8>
geopriv <http://tools.ietf.org/geopriv/>

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 9 Jun 2009 11:40:45 +0700

>  is no altitude defined.  

Just wondering: if that is really the case, how is sea level indicated?

> This needs to be clearer in the bis.
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: Richard Barnes <[email-masked]>
Date: Tue, 09 Jun 2009 00:46:03 -0400

Note that this is altitude *type*, not altitude itself.  Altitude type 1 
is "meters", so sea level would have altitude type 1 and altitude 0 (not 
altitude type 0).

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 8 Jun 2009 23:48:04 -0500

> Just wondering: if that is really the case, how is sea level indicated?

A common question, the answer to which depends on where you are.  "sea level" is indicated by a different number depending on where you are.  Since altitude is mostly defined in relation to an abstract model of the earth, sea level rarely equates to altitude of zero.

BTW, when I say "no altitude", I mean "I don't know what the altitude is", not "this position has an altitude of sea level" for some definition of sea level.

> -----Original Message-----
> From: Glen Zorn [mailto:[email-masked]]
> Sent: Tuesday, 9 June 2009 2:41 PM
> To: [email-masked]; Thomson, Martin
> Cc: [email-masked]
> Subject: RE: [Geopriv] [geopriv] #8: Altitude type of 0 == no altitude
> 
> > ---------------------------------------+-----------------------------
> --
> > -----
> > ---------------------------------------+-----------------------------
> --
> > -----

------------------------------------------------------------------------------------------------
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]

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 8 Jun 2009 23:55:24 -0500

I'll offer my opinion.

Offering a way of stating that altitude is not known is useful.  The document should register altitude type of 0 and register the meaning to indicate that the altitude is not known (note: this does not mean that altitude = 0, any more than it indicates an altitude of 35,000km).

Information on the implications of choosing to include no altitude should be included in the description of each datum (including its impact on the EPSG code and URN).  GML conversion examples should note the impact of this attribute.

This opinion is extracted from draft-thomson-geopriv-3825bis.  Text from that document can be used to address this issue if this opinion is supported by the consensus of the working group.

--Martin

> From: geopriv issue tracker [mailto:[email-masked]]
> Sent: Tuesday, 9 June 2009 2:26 PM
> To: Thomson, Martin
> Cc: [email-masked]
> Subject: [geopriv] #8: Altitude type of 0 == no altitude
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 8 Jun 2009 23:58:29 -0500

I am assuming that if altitude is no known then the datum now becomes
EPSG:4326 and not EPSG:4979?

Cheers
James

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Thomson, Martin
> Sent: Tuesday, 9 June 2009 2:55 PM
> To: [email-masked]
> Subject: Re: [Geopriv] [geopriv] #8: Altitude type of 0 == no altitude
> 
> I'll offer my opinion.
> 
> Offering a way of stating that altitude is not known is useful.  The
> document should register altitude type of 0 and register the meaning
to
> indicate that the altitude is not known (note: this does not mean that
> altitude = 0, any more than it indicates an altitude of 35,000km).
> 
> Information on the implications of choosing to include no altitude
should
> be included in the description of each datum (including its impact on
the
> EPSG code and URN).  GML conversion examples should note the impact of
> this attribute.
> 
> This opinion is extracted from draft-thomson-geopriv-3825bis.  Text
from
> that document can be used to address this issue if this opinion is
> supported by the consensus of the working group.
> 
> --Martin
> 
---------------------------------------+-------------------------------
> >  Severity:  -                          |    Keywords:  altitude
---------------------------------------+-------------------------------
> > -----
> >  RFC 3825 seems to indicate that an altitude type of 0 indicates
that
> > there
------------------------------------------------------------------------
--
> ----------------------
------------------------------------------------------------------------
--
> ----------------------

---

From: [email-masked]
Date: Tue, 9 Jun 2009 11:14:39 -0400 (EDT)

James -

Your observation raises the requirement that the document needs an
informative section on when to use 4326 and when to use 4979. For example,
it is quite valid to use EPSG 4326 and have an (x,y,z) coordinate. It is
also valid to use EPSG 4979 and have an unknown (z). Guidance for
implementers would be very useful. I can provide some words if everyone
thinks this is appropriate.

Carl

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 09 Jun 2009 15:16:38 -0500

>EPSG:4326 and not EPSG:4979?

For WGS-84, it has to.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 09 Jun 2009 15:20:58 -0500

>Just wondering: if that is really the case, how is sea level indicated?

Glen -- there are several "sea levels" actually, a few (in no particular order)

- Mean Low Tide (MLT)
- Mean Lowest Low Tide (MLLT)
- Mean Tide (MT)
- Mean High Tide (MHT)

If we are getting into the weeds of having to be specific here, then 
each datum needs to specify which vertical datum (i.e., altitude) is 
ZERO; as each of these (and a few more) are used; though some are rarely used.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 09 Jun 2009 15:32:53 -0500

>#8: Altitude type of 0 == no altitude

RFC 3825 wrote that a vertical datum was not necessary to inform a 
client of its altitude. That could either be because the client's 
altitude couldn't be determined, or it was withheld.

>This needs to be clearer in the bis.

I agree this should be clearer in the bis.

>  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.

>  Q: what meaning is attached to altitude type 0?

IMO - that there is no altitude given (or guessed or whatever)

>  Q: what is the impact of having no altitude on the existing datum

In WGS-84, the difference is merely either you're in 2D or 3D.

We could extend that rule to being applicable to all datum pairs. For 
example, NAV83 (horizontal) paired with NAVD88 (vertical).

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Wed, 10 Jun 2009 08:02:32 +0200

> 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.

> 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.

> In WGS-84, the difference is merely either you're in 2D or 3D.

+1

> 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

---

From: Richard Barnes <[email-masked]>
Date: Wed, 10 Jun 2009 07:22:29 -0400

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 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

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 10 Jun 2009 12:03:52 -0500

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?)
>
>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
>
>
>>>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.
>>- 4326 with AT 0 or 2 - 4979 with AT 1
>>>We could extend that rule to being applicable to all datum pairs. 
>>>For example, NAV83 (horizontal) paired with NAVD88 (vertical).

---

From: "Carl Reed" <[email-masked]>
Date: Thu, 11 Jun 2009 11:01:33 -0600

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" <[email-masked]>
To: "Richard Barnes" <[email-masked]>; "Alexander Mayrhofer" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, June 10, 2009 11:03 AM
Subject: Re: [Geopriv] [geopriv] #8: Altitude type of 0 == no altitude

>>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
>>
>>
>>>>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.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 11 Jun 2009 13:39:38 -0400

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:
> 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.
> 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.
> 
> ----- Original Message ----- From: "James M. Polk" <[email-masked]>
>>> 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
>>>
>>>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 11 Jun 2009 16:52:26 -0500

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."
>
>(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 -
>>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.
>>>>Does this mean that we should recommend that each datum value 
>>>>that's defined provide a definition
>>>
>>>>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
>>>>
>>>>
>>>>>>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'.
>>>>>>
>>>>>>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.
>>>>>>We could extend that rule to being applicable to all datum 
>>>>>>pairs. For example, NAV83 (horizontal) paired with NAVD88 (vertical).

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 11 Jun 2009 18:37:45 -0500

James said it for me.

WGS84+AT0 = 4326
WGS84+AT1 = 4979
WGS84+AT2 = 4326 + civic address w/ floors as a complex (RFC5491)

> Behalf Of James M. Polk
> Sent: Friday, 12 June 2009 7:52 AM
> To: Richard Barnes; Carl Reed
> Cc: [email-masked]
> Subject: Re: [Geopriv] #8: Altitude type of 0 == no altitude - Guidance
> from the OGC Geodesy community
> 
> Richard
>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 11 Jun 2009 21:25:19 -0500

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 11 Jun 2009 22:43:16 -0500

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.

> From: James M. Polk [mailto:[email-masked]]
> Sent: Friday, 12 June 2009 12:25 PM
> To: Thomson, Martin; Richard Barnes; Carl Reed
> Cc: [email-masked]
> Subject: RE: [Geopriv] #8: Altitude type of 0 == no altitude - Guidance
> > > >>>>>- 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
> > > >>>>>It's a different story what a consumer of such data may
> assume.
> > > For
> > > >>>>>>>  Q: what is the impact of having no altitude on the
> existing
> > > datum
> > > >>>>>>>  definitions?

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 11 Jun 2009 23:53:14 -0500

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.
>
>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.
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 12 Jun 2009 00:19:49 -0500

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 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

> Sent: Friday, 12 June 2009 2:53 PM
> > > altitude, which means at MSL, or whatever the GML guys say is 0m
> for
> > > WGS-84).
> > >
> > > > > I believe you would give the GIS system the floors value, but
> it
> > > will
> > > > > (i.e., the x/y is 4326, and the altitude is in civic floors,
> and
> > > not
> > > > > >ESPG 4326 CRS, while the altitude represents the floor
> designator
> > > in
> > > > > >mingling.  That is, if you were taking the location
> information
> > > from
> > > > > >>The following is guidance provided by the OGC CRS Domain
> Working
> > > > > Group.
> > > > > >>documented. The OGC members have begun using the term
> "honesty"
> > > WRT
> > > > > >>CRS codes and deviations in their use from what is actually
> in
> > > the
> > > > > >>latitude, longitude plus ellipsoidal height (the latter also
> in
> > > WGS
> > > > > >>which case the correct CRS describing those coordinates is
> code
> > > 4978.
> > > > > >>as there are many different Vertical CRSs that are based on
> MSL
> > > one
> > > > > >>way or another.
> > > > > >>So, in conclusion, the best solution is to allow multiple
> codes
> > > so
> > > > > >>neogeographers would like - expressing a simple point
> coordinate
> > > is
> > > > > >>not necessarily so simply - especially if elevation/altitude
> is
> > > > > considered.
> > > > > >>>>>>servers only ever have to remember 1 WGS-84 datum (4979)
> and
> > > if
> > > > > >>>>>>there is an altitude, include the type (and altitude
> value).
> > > If
> > > > > >>>>>>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
> > > > > >>>>>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
> > > > > >>>>>>In WGS-84, the difference is merely either you're in 2D
> or
> > > 3D.
> > > > > >>>>>+1
> > > > > >>>>>
> > > > > >>>>>Seems logical, but - obviously - someone more familiar
> with
> > > those
> > > > > >>>>>reference systems than me would need to take a look at
> this :-
> > > )
> > > > > >>>>>Alex
> > > >------------------------------------------------------------------
> ----
> > > --------------------------
> > > >------------------------------------------------------------------
> ----
> > > --------------------------
> > > >[mf2]
> > >
> >

---

From: "Carl Reed" <[email-masked]>
Date: Fri, 12 Jun 2009 11:03:19 -0600

Richard

In the case of "floors", I do not think that this would be dishonest as the 
number of floors us actually a property of the coordinate location and not 
of the coordinate itself. This is the approach we took when developing the 
CAP standard in OASIS. "Floors" would be no different than a building type 
or type of floor (parking, maintenance, office).

Hope this helps.

Carl

----- Original Message ----- 
From: "Richard Barnes" <[email-masked]>
To: "Carl Reed" <[email-masked]>
Cc: "Alexander Mayrhofer" <[email-masked]>; "James M. Polk" 
<[email-masked]>; <[email-masked]>
Sent: Thursday, June 11, 2009 11:39 AM
Subject: Re: [Geopriv] #8: Altitude type of 0 == no altitude - Guidance from 
the OGC Geodesy community

> 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."
>
>> 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:
>>
>> plus ellipsoidal height (the latter also in WGS 84 of course). This is 
>> GPS content.
>> available for this situation, as there are many different Vertical CRSs 
>> that are based on MSL one way or another.
>>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 12 Jun 2009 10:10:11 -0700

>or type of floor (parking, maintenance, office).

Hmm, I thought I was following you until you made the parallel
with building type.  Is the property of the coordinate location
the number of floors present?  It doesn't tell you, in other words,
what floor is being discussed, but instead the total of floors which
share the coordinate?

			Ted

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 12 Jun 2009 12:17:43 -0500

At 12:19 AM 6/12/2009, Thomson, Martin wrote:
>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):
>
>     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