>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
>
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
>
>
>----- Original Message -----
>From: "Richard Barnes" <rbarnes@bbn.com>
>To: "Carl Reed" <creed@opengeospatial.org>
>Cc: "Alexander Mayrhofer" <alexander.mayrhofer@nic.at>; "James M. Polk"
><jmpolk@cisco.com>; <geopriv@ietf.org>
>Sent: Thursday, June 11, 2009 11:39 AM
>Subject: Re: [Geopriv] #8: Altitude type of 0 == no altitude - Guidance from
>the OGC Geodesy community
>
>
>> 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
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
