W3C home > Mailing lists > Public > public-geolocation@w3.org > June 2008

Re: skeleton Geolocation API

From: Erik Wilde <dret@berkeley.edu>
Date: Fri, 27 Jun 2008 18:04:31 -0700
Message-ID: <48658E1F.9010300@berkeley.edu>
To: public-geolocation@w3c.org
CC: Andrei Popescu <andreip@google.com>

hello andrei.

Andrei Popescu wrote:
>>> - Mentioned that we default to WGS84 for the coordinate system and
>>> added an issue about supporting other geodetic systems.
>> wgs84 is not good enough as a reference system for altitude. altitude can
>> also be measured in meters above geoids, which is the more accurate way of
>> measuring altitude (egm96 is the most common model for that). and it can be
>> measured using barometric measurements, which also is an important way of
>> measuring altitude. we really should have some people looking at that who
>> know this stuff from the inside out, i am a web person and my knowledge is
>> not all that solid...
> Sure. I added a note saying that maybe we should consider allowing a
> difference reference system to be used for altitude. I'm just not sure
> how common such implementations will be. Maybe I'm wrong.

the way how i understand it that you already have three reference 
systems that are widely used for altitudes:

- the wgs84 ellipsoid
- the egm96 geoid
- barometric

so even if your are not planning to support future developments in that 
area (i think a more exact geoid dataset is under development), there 
must be a way how implementations can signal which system they are 
using. this even should be a MUST, because only if the reference system 
is known, the consumer is able convert the data (wgs84 <-> egm96) if 

>> i still think that http://dev.w3.org/geo/api/spec-source.html#position is
>> just too limited in its model of location. a location can be a lat/long pair
>> of coordinates, but it also can be something else, like the identification
>> of a city or a state or some other place-oriented location concept. this
>> becomes critically important in the light of privacy issues, when a mobile
>> user wants to get location-based services without having to disclose his
>> coordinates. if he can still say "i am in berkeley" or "i am in california",
>> this opens a much wider range of possible scenarios than a purely spatial
>> location concept.
> I understand your point of view here and I also think that the URI
> idea is very interesting.  However, since absolutely everybody seems
> to agree that this spec should consider spatial coordinates, my
> proposal is to start with those and agree on an API that makes sense
> in this context.

i did not want to say that there should be no support for coordinates. 
of course these are very important. but not not everybody agrees that we 
should only have coordinates:


it seems to me that so far, the pretty central question of "what is a 
location?" is more or less handled on the fly, adding reference system 
info and now maybe speed and bearing. i think that it would be important 
to really think about the location concept first, and to do that based 
on use cases and scenarios and requirements derived from these. we'll 
see what the charter has to say about important this framing is going to be.

this API will, to quite some degree, shape the future of applications on 
the mobile web, and to me it seems that developing the core concept of 
the proposed API almost implicitly may not be the best way to do that.


Received on Saturday, 28 June 2008 01:05:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:49 UTC