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

Hi Erik.

I would venture a guess that this was because the standards committee
didn't get that far.  There have been other efforts that I have not been
as involved with (such as xCal and a few others), but I do know that
sites were going to start worrying about this themselves if they were
going to move into markets like Asia where the Lunar calendar is
prevalent (different per country too).

If we build this in the sites that care about it will follow the
standard.  Especially, if there are well documented translation
algorithms...

Of course, this is all IMHO.

Thanks.

Chris 

-----Original Message-----
From: Erik Wilde [mailto:dret@berkeley.edu] 
Sent: Wednesday, June 25, 2008 10:46 AM
To: Chris Butler
Cc: public-geolocation@w3.org
Subject: 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 22:22:13 UTC