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

Re: Position interface

From: Jon Ferraiolo <jferrai@us.ibm.com>
Date: Tue, 23 Sep 2008 08:21:41 -0700
To: Gopalakrishnan Sankarasubramanian <Gopal.KS@Charteris.com>
Cc: "public-geolocation@w3.org" <public-geolocation@w3.org>
Message-ID: <OF594D3270.8A8E1D1C-ON882574CD.0052A1E5-882574CD.005461F3@us.ibm.com>
My position: I think these ideas have merit, but as "optional" properties.

Justification: Simplicity is a feature and usually the key to success.
Simplicity greatly improves the chances that user agents will be
interoperable and therefore unleash countless application developers to
take advantage of a write-once, run-anywhere browsing world, where
developers can count on lat/long values within a particular CRS. The
current geolocation spec has appropriate simplicity and IMO shouldn't be
compromised by new features. But new features and increased robustness
aren't bad, For example, alternative CRSs should be possible. What I would
suggest is that position values in WGS84 are required and therefore
developers can count on those values always being present, but allow for an
alternate values using a different CRS system. Regarding identification of
the source of the location information, that's OK with me, also, but maybe
that's a v2 feature. In any case, it should be something that doesn't have
to be there.

Precedent: The SVG WG faced a similar issue with regard to color. Most web
developers don't really care much about color accuracy and are happy with
close-enough color values expressed as red,green,blue triplets. However, in
some graphics workflows, developers have a strong interest in precise color
and other color representations, such as HSL, CMYK, spot colors,
hexachrome, sometimes leveraging ICC color profiles. The approach taken
with SVG is that there is a default color space of sRGB (same as with
HTML/CSS), which is parallel in concept to WGS84 in that it is simple and
is suitable for most user requirements, but like WGS84, falls short in many
edge scenarios that experts in the field take very seriously. To address
high-end requirements, there is also an alternate ICC color value that can
be provided, where you identify a particular color profile (which is
parallel with an alternative CRS) and color values that represents the
parameters to the selected color profiles. User agents can use either the
sRGB color value or the ICC color value (with the choice depending on a
variety of factors that aren't relevant to this discussion). However,
developers could always count on the availability of sRGB versions of any
color values.


             n                                                          To 
             <Gopal.KS@Charter         "public-geolocation@w3.org"         
             is.com>                   <public-geolocation@w3.org>         
             Sent by:                                                   cc 
             n-request@w3.org                                      Subject 
                                       Position interface                  
             09/22/2008 06:15                                              


I have only recently become aware of this specification exercise. I have a
few thoughts, which might have already been discussed.

      1.       I think it would be useful to have an attribute on the
      Position interface that indicates the source used to retrieve the
      location information for debugging purpose. This might also be useful
      if it’s a tracking application and needs to log this data.
      2.       I think the coordinate reference system could be an
      attribute of this interface as well. This will allow coordinate
      systems other than WGS84 to be used. EPSG codes can be used as
      possible values.
      3.       Have we discussed  including the coordinate reference system
      (CRS) as an attribute of the PositionOptions interface, as  a way for
      the  application to specify what reference system it would like the
      location information to be returned in. If the underlying system API
      supports coordinate conversions, then this would be a very quick way
      for the application to get back the data it needs in the format it
      needs. Of course if coordinate conversions are not supported, then
      the coordinate reference system attribute on the Position interface
      would indicate to the application that no conversion was performed.


E-mail confidentiality notice
This message is private, confidential and may contain information of a
proprietary and/or legally privileged nature.
If you have received this message in error, please notify us and remove it
from your system.
If you require assistance, please contact our Registered Office at 39/40
Bartholomew Close, London, EC1A 7JN.
Charteris is a UK Registered public limited company, with Company
Registration Number: 3165591
Charteris is registered for VAT in the UK, with VAT Registration Number:
681 1006 67
Further information about Charteris plc is available from our Web site at

(image/gif attachment: graycol.gif)

(image/gif attachment: pic02167.gif)

(image/gif attachment: ecblank.gif)

Received on Tuesday, 23 September 2008 15:23:41 UTC

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