Re: Comments on the draft Geolocation API Spec.

Hi Carl,

First of all, thanks for the comments. They are really useful! I've
copied them here and added some answers inline:

> 1. Questions regarding the statement: associated with the hosting
> device, Global Positioning System (GPS) and location inferred from
> network signals such as IP address, RFID, WiFi and Bluetooth MAC
> addresses, and GSM/CDMA cell IDs.  a. Question 1.) What is a hosting
> device? I think that a clear definition of what is meant by ?hosting
> device? would help.

By hosting device we mean the device where the Geolocation API is
running. It can be anything: a mobile phone, a desktop computer, a
car, etc.

> b. Question 2.) How about location servers? There is no mention of
> location being served by a location server. Perhaps these are
> inferred. RFC 3693 provides a set of definitions that includes a
> definition of Location Server: The entity to which a Location
> Generator publishes location objects, the recipient of queries from
> location receivers, and the entity that applies rules designed by
> the rule maker. OMA and the OGC use a similar set of definitions in
> our Location Services work.

One of the goals of the API is to be completely agnostic to the
sources of location data. Any implementation is free to use any
location data provider it wishes, including location servers. Some
sources of location information do not require any server (e.g. GPS).
It is not in the scope of this specification to define what these
sources of location information should look like.

> 2. The Security and Privacy section is TBD. I would strongly
>  encourage the Geolocation API community to look at the standards
>  work of both the IETF GeoPriv WG and OMA when working on this
>  section.

It's no longer TBD, we have updated the spec. We do have ongoing
discussions with the IETF GeoPriv group. Please see below for links to
the relevant threads:

http://dev.w3.org/geo/api/Overview.html#security

> 3. Comment on, ?The reference system used for the positioning
> attributes of this interface is the World Geodetic System
> [WGS84]?. This is an ambiguous definition for the default Coordinate
> Reference System (CRS) for use in the Geolocation API. A more
> accurate definition might be, ?Default Coordinate Reference System:
> The default is a geographic coordinate reference system, using the
> WGS84 (2d) datum, and with longitude and latitude units of decimal
> degrees.? This definition is from the GeoJSON API and is consistent
> with the work in ISO, the OGC, OASIS, the IETF, and GeoRSS. There is
> also a WGS84 (3d) definition. More on a better definition of decimal
> degrees later. Also, I would encourage a reference to the ISO and
> OGC standards document titled, ?Spatial Referencing by
> Coordinates?. This document provides definitions on all of the
> elements related to coordinates, reference systems, and so
> forth. http://portal.opengeospatial.org/files/ artifact_id=6716

Ok, I will add the references you provided. However, please note that
saying that WGS84 is the default reference system is a bit misleading
as it implies that it can also be something else. Since we only
support WGS84, I don't think we should call it 'default'.

> 4. Comment on, ?The latitude and longitude attributes are specified
>  in degrees.? This is an ambiguous definition. First, the document
>  should state ?decimal degrees? and not just ?degrees?. Second,
>  referencing a normative reference as to what is > really meant by
>  decimal degrees would be very helpful and prevent inconsistent
>  expression of how to represent decimal degrees. In this case,
>  perhaps a reference to EPSG 4326 would help. This reference would
>  also help with the more accurate > specification of what is meant by
>  WGS84 in this document. http://www.epsg-registry.org/ .

Ok, I will update the spec to say "decimal degrees". However, I
thought that the normative specification of WGS84 is the document that
is currently linked in the spec. I could not find anything better at
http://www.epsg-registry.org/ Do you have a more specific URL?

> 5. Comment on, ?The accuracy attribute denotes the accuracy level of
>  the latitude and longitude coordinates?. This is a tough topic. I
>  think we need to make the statement very clear as to whether this is
>  positional accuracy, sampling accuracy, > etc. I suspect that the
>  statement is in regard to positional accuracy or more specifically
>  horizontal position accuracy. Also, what about the confidence
>  measure for the stated horizontal accuracy?

Yes, this is horizontal position accuracy. I can clarify this in the
spec if it is not clear already. We have already added wording to the
spec about the confidence level:

http://dev.w3.org/geo/api/Overview.html#accuracy (the paragraph
immediately above the definition of 'heading').

> 6. Comment on ?Altitude?. There is an excellent article on the
> relationship of geoids, mean sea level, ellipsoids, WGS 84, and GPS
> at http://www.esri.com/news/arcuser/0703/geoid1of3.html. Obviously,
> we do not want to get into this level of detail in the Geolocation
> API. However, the concept of ?altitude?, as with accuracy, is
> potentially highly ambiguous with resultant legal implications. This
> is why perhaps a word of warning on this element as well as a
> reference for further reading . Also, a slightly more accurate
> definition for use in the API might be: ?decimal meters above the
> local reference ellipsoid?.

Thanks again for the informative reference. I am not sure, however,
about "decimal meters". "Decimal degrees" makes sense as an
alternative to expressing lat / long in degrees, minutes and
seconds. But what could "meters" be confused with?

> 7. Comment on heading: Perhaps add some additional clarification as
>  ?denotes the direction of the hosting? is slightly
>  ambiguous. Perhaps the simple addition of ?Heading refers to the
>  direction you are traveling? to avoid confusion.

You are right, this was confusing and was fixed already in the spec:

http://dev.w3.org/geo/api/Overview.html#heading

> 8. Comment on ?timestamp?. The use of DOMTIMESTAMP confuses me. I
> checked the definition and it only stated ?represents a number of
> milliseconds?. Obviously I am missing something. The IETF GeoPriv
> and the OGC use the ISO definition for how to express time. For
> example, <timestamp>2007-06-22T20:57:29Z</timestamp>. Any
> clarification appreciated.

Oh, I see. This API is intended for the Web, the natural data type for
the "timestamp" attribute is DOMTimeStamp. Interpreted as
milliseconds, the timestamp value is the number of milliseconds
between the moment when the Position object was acquired and
1970-01-01 (UTC). The DOM Core spec allows bindings to use different
types. For instance, in JavaScript, the timestamp attribute would be a
Date object. I will expand the definition of the timestamp attribute
to clarify this.

> 9. A general question: How does a browser based application that
> implements the Geolocation API keep initiate the handshake between
> the app and the location enabled device and then keep track of that
> device? Is there something like SIP or is there a unique identifier
> or handle? Again, I may be missing the simple answer.

As Doug said, this is an implementation detail. For example, Gears has
a simple JSON over HTTP protocol that it uses to talk to the location
server. There is no tracking whatsoever, the location server acts just
as a dictionary that maps network signals (GSM cell IDs, WiFi APs) to
(lat, long) coordinate pairs.

Thanks,
Andrei

Received on Monday, 1 December 2008 14:42:25 UTC