Re: scope and altitude

Hi Erik,

On Wed, Nov 19, 2008 at 7:16 PM, Erik Wilde <dret@berkeley.edu> wrote:
>>> The scope of this specification does not include defining new URI schemes
>>> for identifying locations.
>>> This API does not preclude the definition of a more general location API
>>> for
>>> providing access to location information based on non-geoposition
>>> concepts
>>> of location."
>>
>> I don't think this one is required. We're not claiming anywhere that
>> we're precluding the definition of any other specification, so this
>> seemed out-of-place and stating the obvious.
>
> i think the traffic on the mailing list with people trying to get civic
> addresses to be included in the API is evidence of the fact that this is not
> obvious. you do know my personal opinion about the relationship between
> lat/long information and location information, and i usually think that it
> is usually better to make something explicit, than assuming that some reader
> will have the same background. i am still hoping that the geopostion API is
> just the first indication of more things to come, and pointing that out may
> be worth the one or two sentences.
>

Again, I am pretty confident that we will have civic addresses in the
next versions of this API. If we were to rename the API to
Geoposition, would we not have to rename back to Geolocation once we
add addresses? So I think the current name is perfectly fine as it
scales well with future additions to the API.


>>> another question i have is about the altitude. right now, it says "above
>>> the
>>> WGS84 geoid", however, this is a rather imprecise way of handling
>>> altitude
>>> (at least this is my limited understanding of how good the WGS84 geoid
>>> approximates earth's real shape). EGM96 altitudes are more precise, and
>>
>> I think we decided to use WGS84, so expressing altitude in the same
>> coordinate system makes sense.
>
> EGM96 is not a different coordinate system. it is a more precise way of
> dealing with the inaccuracies of the WGS84 geoid. it is actually built into
> more modern GPS hardware, and i think ignoring it would be wrong. why
> disallow more precise measurements if the deice is capable of doing it? and
> my guess is that EGM96-capable GPS devices might not even have the option of
> giving you the less precise WGS84 measurement (that might not be true, it is
> just a guess).
>

But according to
http://earth-info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf :

"A refined WGS 84 geoid has been determined from the new gravitational
model and is
available as a 15 minute grid of geoid undulations which exhibit an
absolute accuracy of 1.0
meters or better, anywhere on the Earth. This refined geoid is
referred to as the WGS 84
EGM96 Geoid."

So as of 1996, the WGS84 Geoid has been refined based on the EGM96 model.

>>> there also are quite a large number of devices out there measuring
>>> barometric pressure for altitudes (which, if properly adjusted, is
>>> considerably more accurate than GPS-based altitudes). should these two
>>> alternative methods be excluded? i think both of these methods are pretty
>>> popular, so i think they should be supported in the API.
>>
>> But barometric altimeters are just a means to acquire an altitude
>> reading and this specification certainly does not preclude any
>> implementation from using them. We're just saying that the altitude
>> value that we expose through this interface is expressed in meters
>> over the WGS84 geoid.
>
> sure, but if we allow clients to expose values, we should allow them to
> expose values as they were acquired. if barometric elevation has to be
> exposed as WGS84 elevation, this is simply lying on the part of the client,
> so strictly speaking, it would have to not expose the value.
>
> strictly speaking, there should be a separate barometric altitude field,
> because GPS-enabled devices with barometric altitudes can expose both
> values, and in real-world scenarios it actually makes sense to get access to
> both values. GPS altitude is inaccurate for principal reasons (GPS is not
> very good at measuring altitude), barometric altitude can be extremely
> accurate, but only if calibrated properly.
>
> so maybe we should really have two altitude fields, one GPS (with the
> options of being GPS84 or EGM96), and the other barometric? in terms of
> real-world clients, that would be the appropriate API. it would then be the
> application's decision to use the value it trusts more, because it knows the
> client was calibrated recently, for example.
>

I am still not sure I understand this argument. Again, the method of
measurement (air pressure or GPS) is not necessarily connected to the
choice of datum to which the altitude is expressed. We define the API
to use WGS84. It is up to the implementation to internally convert
from whatever datum it is using to WGS84.

As for returning the most accurate reading, since this is a high level
API, it's again the implementation's responsibility to return the most
accurate value. We also don't intend to expose details like
calibration through the API.

Thanks,
Andrei

Received on Monday, 1 December 2008 16:39:39 UTC