scope and altitude

hello andrei.

Andrei Popescu wrote:
> On Fri, Nov 14, 2008 at 10:31 PM, Erik Wilde <dret@berkeley.edu> wrote:
>> "This specification is limited to providing an API for retrieving
>> geoposition information associated with a hosting device. The geoposition
>> information is provided in terms of coordinates of the WGS84 coordinate
>> system, and optionally an altitude.
> Done.

just to point it out: i have changed this working to "geoposition" 
because i do think there is an important difference between "location" 
and "position", or at least it would be important to be clear about the 
differences we see and to use these words in a well-defined way (well, 
at least a little bit less fuzzy than using them interchangeably).

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

>> in addition to that, i am proposing to rename the API to "Geoposition API"
>> to better reflect the scope and non-scope of the API. i think in many cases
>> saying what you don't want to do is as important as saying what you want to
>> do.
> The difference between 'position' and 'location' is really subtle
> (they are synonyms to most people) so I don't think it's worth
> changing the name of the API.

i think the problem is that "position" and "location" are vaguely 
defined and perceived as synonymous, and by using these two words in a 
more well-defined way and stating that this API is about "position" (as 
defined by lat/long) and not location (non-lat-long concepts) would make 
it much easier for people to understand what this is about. again, the 
number of questions about civic addresses are an indication that people 
have assumptions because of the fuzzyness of the terms "position" and 
"location".

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

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

cheers,

dret.

Received on Wednesday, 19 November 2008 19:17:05 UTC