Re: Comments on the draft Geolocation API Spec.

Andrei -

Thank you for the detailed response. Your response clarifies a number of
points. My comments and suggestions are below.

Regards

Carl

> 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.

Understood. Perhaps just a statement in the document per your response to me.
>
>> 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.

Understood. Thanks for the clarification!

>
>> 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

I will look into this and provide any questions or thoughts as appropriate.

>
>> 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'.

Agree. Do not call WGS-84 "default". A simple statement that WGS-84 is the
only supported coordinate reference system works.

>
>> 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?

The normative description of WGS-84 is the NGA document. However, you need
more detail in order to correctly provide the specific details of how the
application/API is using WGS-84. For example, WGS-84 supports both 2-d and
3-d references. The following is an example of what I mean. This example
is from the OGC Open Location Services API standard and is also identical
to what is used in the OASIS CAP standard and the OMA MLP standard:

Note: It is not necessary to specify a Coordinate Reference System for
Point geometries that are used by these services because the default for
all coordinates used by the GeoMobility Server is WGS 84 as specified in
the EPSG database. The coordinate conventions are as follows:
- Default Coordinate Reference System - WGS 84 (srsName=’4326’);
- Coordinate Order - Latitude, Longitude;
- Value Type - Decimal Degrees;
- Latitude Sign is +90 at North Pole to -90 at South Pole;
- Longitude Sign is -180 west from Greenwich at the International Dateline
to +180 east from Greenwich at the International Dateline.

Therefore, the "real" normative reference is the EPSG database entry that
provides the exact parameters for the form of WGS-84 required for use in
the API. There are two publicly accessible registry services that will
provide the specific parameter values for 4326 (or any other EPSG code).

>
>> 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').

Understood. Thanks.

>
>> 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?

Understood. My bad.

>
>> 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

Thanks for the clarification.

>
>> 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.

Thanks and understand the rationale.

>
>> 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. Understand. Perhaps some words in the document to that effect.

>
> Thanks,
> Andrei
>

Received on Tuesday, 2 December 2008 15:11:16 UTC