Re: Moving the Geolocation API to First Public Working Draft

Hi Erik,

Thanks for the suggested wording!

On Fri, Nov 14, 2008 at 10:31 PM, Erik Wilde <dret@berkeley.edu> wrote:
>
> a more explicit version could be something like this:
>
> ----------------------------------
>
> "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.

> The scope of this specification does not include providing a markup language
> of any kind.
>
> 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.

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

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

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

Thanks,
Andrei

Received on Wednesday, 19 November 2008 16:30:15 UTC