

RE: The Geolocation API must provide location data in terms of a pair of latitude and longitude coordinates.

From: Chris Butler <cbutler@dash.net>
Date: Wed, 25 Jun 2008 10:35:00 -0700
Message-ID: <470455FBB46F8749A645E9F732A72C35025AE7B7@ex-be2.dash.net>
To: "Erik Wilde" <dret@berkeley.edu>, <public-geolocation@w3.org>

Hi everyone.

One option would be to do something similar to what the iCal RFC did
with calendar types:


In the iCal case only Gregorian was ever used, but I believe the thought
was that eventually you could have Julian, Hijiri, Hebrew, Aztec, etc.

In the geo case there may be only one for now (WGS84) but it allows for
extension of that...



-----Original Message-----
From: public-geolocation-request@w3.org
[mailto:public-geolocation-request@w3.org] On Behalf Of Erik Wilde
Sent: Wednesday, June 25, 2008 10:00 AM
To: public-geolocation@w3.org
Subject: Re: The Geolocation API must provide location data in terms of
a pair of latitude and longitude coordinates.

Jon Ferraiolo wrote:
> For lay people (such as me) who until now have never heard the term 
> "geodetic system" before, perhaps the API can have the ability to
> a simple lat/long value but somewhere inside the spec there can be an 
> explanation of which geodetic system (or whatever the proper term is)
> used by default.

it seems that wgs84 more or less is the de-facto standard for
lat/long values these days, but that definitely needs to be specified. 
if you do have a gps, it very likely has some configuration screen where

you can choose from a number of reference systems. this is important 
when you want to look up coordinates on a paper map: if the gps 
reference system and you map's coordinate system do not match, it is 
very hard to actually locate the coordinates on the map (the 
transformations can be fairly complex).

as for elevation values, the reference system is much more important. 
devices can and do use different reference systems, or they may even use

barometric elevation measurements (which tend to be more precise, 
depending on the number of satellite fixes), so for the elevation to 
make any sense, there definitely needs to be a reference system. and 
because it is entirely reasonable for a device to use gps values for 
lat/long and barometric values for the elevation, the reference system 
cannot be just one for the complete location, it must be specific for 
these values.

and like i mentioned earlier, and somehow going in the same direction, i

am very interested in the API supporting URI-based locations. in a way, 
this is just another "reference system", where instead of lat/long 
values, the location is defined by a URI scheme. like i said, i am not 
very happy with the current geo: scheme proposal (in particular the 
latest version of it, which switched to a tile-based scheme), but 
narrowing down location to lat/long only is a rather limited location 

in particular, location URIs can provide a good solution for come of the

privacy issues of the location API. URI-based location may use 
coordinate-based lat/long locations (such as proposed by the current 
geo: scheme draft), but they could also represent locations providing 
better privacy, such as city names, states, or entirely user specific 
locations, which still make sense in the context of interactions among 
closed user groups (e.g. on social networking sites), but have far fewer

  privacy implications than gps-precision coordinates.


Received on Wednesday, 25 June 2008 17:35:52 GMT
