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

Re: skeleton Geolocation API

From: Erik Wilde <dret@berkeley.edu>
Date: Sun, 29 Jun 2008 11:11:01 -0700
Message-ID: <4867D035.7000205@berkeley.edu>
To: public-geolocation@w3c.org
CC: straup@gmail.com


> For the sake of argument, the default context could be assumed to be a 
> WSG84 URI and sorting out what anything else actually *means* is left to 
> individual developers. (Maybe of handful of known-knowns to deal with 
> situations where WSG84 is known-known to cause problems, too...)

just for the record: while wgs84 is good enough as a context identifier 
for coordinates, it is not good enough for elevation.

> At a minimum, that would allow people to identify what system is being 
> used for Plain Old Points (tm) and in the hand-waving future leave some 
> wiggle room for the kinds of things that Erik mentions and stuff no one 
> has imagined yet.

i like the general idea. this would also allow contexts in which no 
lat/long information is given at all. for each context, there would have 
to be a definition which parts of a position (lat/log, elevation, uri, 
bearing, speed) can/must be present, and how they are defined. if it is 
done that way, there would have to be at least three context identifiers 
for wgs84 coordinates, though, because elevation should at least be 
supported for plain wg84, egm96, and barometric values.

that looks kind of messy to me (the lat/log values mean the same, even 
though the context identifier is different). the alternative would be to 
have parameter-specific context identifiers, may one for lat/log, one 
for elevation, one for bearing/speed, and my hope would be that uris 
don't need context identifiers, they should be context-free (or should 
declare their own context inside of the uri scheme, if context is needed).

and i would suggest to not define implicit defaults for context. in most 
standards, implicit defaults encourage implementers to implement things 
lazily (i.e., to ignore context parameters and then interpret values in 
the wrong way, if the context is set to a non-default value). so the 
position definition should say: if there is a lat/long values, there 
MUST be a lat/long context specified. if there is an elevation value, 
there MUST be an elevation context specified... and so forth...


Received on Sunday, 29 June 2008 18:12:02 UTC

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