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

i think the problem with this kind of "semantics-altering optional 
parameter" is that i would bet that in 99.9% of implementations, when i 
use a date and specified "CALSCALE:AZTEC", they would still treat all 
dates as gregorian.

Chris Butler wrote:
> Hi everyone.
> 
> One option would be to do something similar to what the iCal RFC did
> with calendar types:
> 
> http://tools.ietf.org/html/rfc2445#section-4.7.1
> 
> 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...
> 
> Thanks.
> 
> Chris 
> 
> -----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
> return 
>> 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)
> 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 
> concept.
> 
> 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.
> 
> cheers,
> 
> dret.
> 

-- 
erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
        dret@berkeley.edu  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)

Received on Wednesday, 25 June 2008 17:47:04 UTC