Location terminology

Having read the draft and the use cases, I think that the API--long overdue as it is--takes the correct approach, particularly with regards to its simplicity.

I was involved in implementing a similar API several years ago; unfortunately, we haven't had the opportunity to follow up on the project.

To preface my future comments, as a regular participant in IETF discussions on geo-location (in the GEOPRIV working group in particular), my interest is in ensuring that there is a degree of compatibility between the approaches taken in both forums.  The goals of these working groups differ, but I see no need in creating solutions that are in conflict.

~~

I notice that in the recent discussion, the question of correct terminology has come up.  In the interests of uniform terminology across the industry, I'd like to make a few terminology suggestions.

    readonly attribute double accuracy;
    readonly attribute double altitudeAccuracy;

Accuracy is a term that can be very easily misinterpreted.  For a quantitative concept, the term "uncertainty" is preferred.  NIST advises that there are two many potential interpretations for accuracy and they prefer it to be used only for qualitative statements.

  http://physics.nist.gov/Pubs/guidelines/appd.1.html


In addition, your specification should make some statement about the expected confidence related to this uncertainty.  You will get a number of opinions on the topic: users and application providers will demand the impossible value of 100%, location providers like lower numbers (because it makes the circle look smaller).  I'd recommend picking between 67%, 90% and 95%, which are commonly used values.  The IETF favour 95% (siding with the users and application providers).


    readonly attribute double heading
    readonly attribute double velocity

Using the term "velocity" for a scalar is misleading, since velocity is a vector concept.  The combination of these two values define the velocity.  "speed" would be a more correct term for the scalar.

Regards,
Martin
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

Received on Friday, 17 October 2008 07:48:04 UTC