Re: Location terminology

Hi,

On Mon, Oct 20, 2008 at 3:00 AM, Doug Turner <doug.turner@gmail.com> wrote:
>
> i would agree that changing velocity to speed makes sense.
>

I agree. This has already created some confusion, so we should change
it as proposed by Martin and you.

>
> On Oct 16, 2008, at 10:58 PM, Thomson, Martin wrote:
>
>> 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.
>>

Agreed, and thanks for the comments!

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

I think you are right but maybe this is one aspect where a spec such
as this can be a little different to an IETF spec. IMHO, the accuracy
attribute, as we defined it today, is easy enough to understand.

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

To clarify, you are talking about adding some statement in the spec to
say that the API should return the accuracy at the 95% confidence
level, right (i.e. you don't mean that we should expose this through
the API). If this is the case, I am ok with it.

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

Agreed.

Many thanks,
Andrei

Received on Monday, 20 October 2008 17:10:02 UTC