Re: scope and altitude

hello andrei.

Andrei Popescu wrote:
> On Wed, Nov 19, 2008 at 7:16 PM, Erik Wilde <dret@berkeley.edu> wrote:
> 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.

my suggestion was to specifically limit this API to geoposition, rather 
than assuming that location concepts are just a small delta which can be 
added by a new version. i am convinced that this is not the best way to 
cover location concepts more broadly, and that this approach will also 
introduce compatibility issues, because a v2 API of the current spec 
would have to make all of the current fields optional to allow 
non-positional locations, and that will create a lot of problems.

at the risk of repeating myself ad nauseum: location is much more 
complex and rich than just position, and treating it as a small add-on 
to position is not a good idea, imho. i think it is good to go for the 
low-hanging fruit now, but i also think it would be good to not assume 
that all other fruit are just a minor variation of the position variety. 
they're not, and thus it would be better to not try to create a v2 of 
the current API, but rather a more comprehensive API for location whivch 
would then incorporate the geoposition API.

in summary: i think as a more long-term goal it would be the better 
approach to have the current geoposition API *and* a more general 
location API; and to avoid confusing the two i proposed to rename the 
API discussed here to "geoposition".

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

not really. there is a EGM96 model which does improve the WGS84 geoid, 
but clients must store large amounts of data for the worldwide mapping 
of the differences between the WGS84 geoid and the EGM96 geoid. not all 
clients do this (and they're not required to do it), so it depends on 
the client's GPS "model" whether altitude is returned as WGS84 or as 
EGM96 data. since both types of clients exist, there must be a way how a 
client can signal which geoid it is using.

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

sure, but in the same way as you have an "accuracy" for the lat/long 
because you assume that a client might want to communicate additional 
information about coordinates, you might also want to have information 
about the fact that altitude has been acquired one way or the other, 
with implications for the accuracy as well (though more implicitly in 
this case). and a client equipped with both a GPS and a barometer could 
and might want to expose two altitude measurements, and it could then be 
up to the application to decide which value to use. it might even be 
smart and use both and watch drift of the barometric value over time.

cheers,

dret.

Received on Monday, 1 December 2008 20:55:01 UTC