Re: [geonet/its] ways of representing 'confidence'(was: Agenda ...)

[Alexandru Petrescu <[e-mail]>]

Le 11/08/2014 21:15, Richard Roy a écrit :
>
>
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[e-mail]] Sent: Monday, August 11, 2014
>> 11:21 AM To: [e-mail]; 'Rex Buddenberg' Cc: 'Carl
>> Reed'; 'Dino Farinacci'; [e-mail];
>> [e-mail]; [e-mail]; [e-mail] Subject: Re:
>> [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at
>> 20:30; IETF registration desk
>>
>> Richard,
>>
>> I agree with what you write here.
>>
>> I just think that IP packet containing coordinatesm and trying to
>> be read by as many systems as possible, should state how sure is it
>> about them and in which reference system.
>
> [RR>] Absolutely agree! The point is that the coordinates contained
> in the IP packet are ESTIMATES of a stochastic process (the position
> (really kinematic state) of something (like a GNSS antenna phase
> center) in a "well-known" coordinate system as a function of time).
> The "how sure" is completely encapsulated in the ESTIMATE ERROR
> COVARIANCE matrix.  So, when one send X_hat (kinematic state estimate
> incl. the time coordinate), P_hat (estimate error covariance), and
> COORDINATE_SYSTEM_IDENTIFIER (identifies the "well-known" coordinate
> system being used), the receiver has everything it needs.
> "Confidence values" are no longer of any value.

So we seem to agree that a 'confidence' value may equal that 'estimate
error covariance matrix'.   We would need to tell what size that matrix
is - represented on how many bytes for each of its rows and columns.

The RFC6225 "DHCP coordinates" defines this 'uncertainty' to be a set of
three values, each along one of the 3 axis.

The PIDF-LO draft-ietf-geopriv-uncertainty-02 also seems to specify a
means to encode uncertainty.

The ETSI ITS document has a 1bit flag 'accuracy'.
(ETSI EN 302 636-4-1).

These four ways of specifying confidence are incompatible.

Not to mention they are incompatible with GPS HDOP, VDOP, HDOP.

This situation may suggest the need for conversion methods.  But
conversion methods have the inconvenient of introducing new
opportunities of precision loss: converting between ways of representing
confidence may add even more distrust to confidence.

Alex

>
> RR
>
>>
>> Alex
>>
>> Le 10/08/2014 06:21, Richard Roy a écrit :
>>> All,
>>>
>>> Statistical confidence values are of limitd use in ITS
>>> applications.
>> The
>>> statistical quantities ITS apps need are Probability Density
>>> Functions (PDFs) which provide sufficient information to make
>>> "optimal" decisions (where optimality is something engineers get
>>> to decide on).  These PDFs
>> are
>>> parameterized by means and second central moments (and other
>>> higher
>> order
>>> moments if the PDF is not Gaussian). Confidence values relate to
>>> how
>> many
>>> times one can expect the outcome of a realization of a particular
>>> random process/experiment to lie between a set of values (aka in
>>> a given region
>> of
>>> support).  That is, a 95% confidence interval gives the region
>>> of
>> support in
>>> which it is expected that 9500 outcomes out of 10000 experiments
>>> will
>> lie.
>>> ITS apps only get one shot in general, and the info they need is
>>> the PDF
>> of
>>> the estimated multivariate quantity.
>>>
>>> If, on the other hand, you are thinking of confidence
>> anthropomorphically as
>>> in ... "well, I'm pretty confident that the values I'm giving you
>>> are
>> 'good'
>>> rather than 'bad'", this in not statistical "confidence".  In
>>> fact, it's useless information to any receiver that thinks
>>> rationally, not
>> emotionally.
>>>
>>>
>>> RR
>>>
>>>> -----Original Message----- From: Rex Buddenberg
>>>> [mailto:[e-mail]] Sent: Thursday, August 07, 2014
>>>> 9:59 AM To: Alexandru Petrescu Cc: [e-mail]; 'Carl
>>>> Reed'; 'Dino Farinacci'; [e-mail];
>>>> [e-mail]; [e-mail]; [e-mail] Subject:
>>>> Re: [geonet/its] Agenda for the GeoNet informal meeting on
>> 23rd
>>>> July at 20:30; IETF registration desk
>>>>
>>>>
>>>>> there is a need of a 'confidence' value
>>>>
>>>> Alex, plowing old ground.
>>>>
>>>> Every radionav system has a considered confidence value.  We
>>>> only need to include them in the data formats, or ID the
>>>> radionav source so the user can infer properly.  Loran C uses a
>>>> 2dRMS value (95% confidence)
>> in
>>>> it's design philosophy while GPS uses Circular Error Probable
>>>> (50%). Beidou, Compass, Glonass, etc all have similar
>>>> parameters.  Google on either CEP or 2drms and you'll get what
>>>> you need.
>>>>
>>>> As discussed, the datum needs to somehow be known as well.  But
>>>> each system advertises what it uses -- GPS and Loran, for
>>>> example, both use WGS84.
>>>>
>>>>
>>>> On Thu, 2014-08-07 at 16:23 +0200, Alexandru Petrescu wrote:
>>>>> Le 01/08/2014 18:47, Richard Roy a écrit :
>>>>>> All,
>>>>>>
>>>>>> See comments below ...
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> RR
>>>>>>> -----Original Message----- From: Alexandru Petrescu
>>>>>>> [mailto:[e-mail]] Sent: Friday,
>>>>>>> August 01, 2014 7:57 AM To: Carl Reed; Dino Farinacci Cc:
>>>>>>> [e-mail]; [e-mail];
>>>>>>> [e-mail]; [e-mail]; [e-mail]
>>>>>>> Subject: Re: [geonet/its] Agenda for the GeoNet informal
>>>>>>> meeting on
>>>> 23rd
>>>>>>> July at 20:30; IETF registration desk
>>>>>>>
>>>>>>> Le 31/07/2014 17:01, Carl Reed a écrit :
>>>>>>>> Alex -
>>>>>>>>
>>>>>>>> I am not familiar with your LISP mapping database.
>>>>>>>>
>>>>>>>> However, a couple of suggestions.
>>>>>>>>
>>>>>>>> 1. Specifying a lat/long coordinate in the form
>>>>>>>> 40-35-18-N 73-40-3-
>> W
>>>> is
>>>>>>>> unusual. The vast majority of encodings for geographic
>>>>>>>> coordinates
>>>> is
>>>>>>>> done in decimal degrees. While the format you show is
>>>>>>>> perhaps nice
>>>> for
>>>>>>>> human reading it is not the norm. Also check out
>>>>>>>> http://en.wikipedia.org/wiki/ISO_6709
>>>>>>>
>>>>>>> Ok.
>>>>>>>
>>>>>>>> 2. I would check out other lightweight encodings such
>>>>>>>> as Open
>> GeoSMS
>>>>>>>> (https://portal.opengeospatial.org/files/?artifact_id=44146)
>>>>>>>> or how
>>>> geo
>>>>>>>> is encoded in vcard and icalendar and in the location
>>>>>>>> object (LO)
>>>> for
>>>>>>>> PIDF and other internet RFCs.
>>>>>>>
>>>>>>> Ok PIDF-LO.
>>>>>>>
>>>>>>>> 3. You will notice in the ISO 6709 discussion (and in
>>>>>>>> all OGC
>>>> standards)
>>>>>>>> the need to specify the CRS (coordinate reference
>>>>>>>> system) being
>>> used.
>>>>>>>> For lat/long, the typical CRS is EPSG 4326, WGS 84 2d.
>>>>>>>> The CRS information can be in the documentation and not
>>>>>>>> necessary in the physical encoding.
>>>>>>>
>>>>>>> I would argue we need the message, or the computers, to
>>>>>>> be clear
>>>> about
>>>>>>> which reference system they use.  Not only the paper
>>>>>>> documentation.
>>>>>>>
>>>>>>> In addition to the suggestions above, I would also
>>>>>>> suggest that the precision data should tag any statement
>>>>>>> about x/y/alt coordinates.
>>>> This
>>>>>>> should express the confidence one has in these
>>>>>>> coordinates to hold
>>>> true.
>>>>>>
>>>>>> [RR>] The statistically meaningful and useful quantity is
>>>>>> not
>>>> "confidence",
>>>>>> it's estimate error covariance.  [t, lat, long, alt] is an
>>>>>> estimated four-vector of "location".  (Time (t) is as
>>>>>> necessary as any of the
>>>> other
>>>>>> three!)  This estimate is a realization of a random vector
>>>>>> that has a probability distribution associated with it.
>>>>>> Using the central limit theorem, this distribution can be
>>>>>> assumed to be multi-variate
>> Gaussian
>>>> with
>>>>>> a mean and a covariance (the square-root of which is the
>>>>>> familiar
>>>> standard
>>>>>> deviation when talking about scalars).  All GPS (GNSS)
>>>>>> devices use
>>>> EKFs that
>>>>>> propagate the estimated mean AND its estimate error
>>>>>> covariance.
>>>> Position
>>>>>> services can use this information along with other
>>>>>> "external"
>>>> information
>>>>>> (such a s maps, etc.) to get more precise (lower variance)
>>>>>> estimates. That's what you want!
>>>>>
>>>>> In addition to that estimate error covariance communicated by
>>>>> the GNSS system to the terminal computer, there is a need of
>>>>> a 'confidence'
>> value
>>>>> that the computer tells how sure it is when it measures the
>>>>> lat/long/alt.  I think this is the meaning of HDOP, PDOP,
>>>>> VDOP terms
>> in
>>>>> GPS parlance.
>>>>>
>>>>> For example, when one vehicle measures its own geographical
>>>>> position
>> and
>>>>> believes it to be 2, 49, 100, it must tell other vehicles
>>>>> that it just _thinks_ to be there (i.e. HDOP==1, really there
>>>>> with a 10centimeter precision, or HDOP==5 meaning a sphere of
>>>>> radius of 100meter). Otherwise other vehicles may send
>>>>> messages to that vehicle in the
>> wrong
>>>>> place.
>>>>>
>>>>> Alex
>>>>>
>>>>> Alex
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>> Carl Reed, PhD CTO Open Geospatial Consortium
>>>>>>>>
>>>>>>>> -----Original Message----- From: Alexandru Petrescu
>>>>>>>> Sent: Thursday, July 31, 2014 8:36 AM To: Dino
>>>>>>>> Farinacci Cc: [e-mail] ;
>>>>>>>> <[e-mail]> ;
>>>> [e-mail] ;
>>>>>>>> <[e-mail]> ; <[e-mail]> Subject: Re:
>>>>>>>> [geonet/its] Agenda for the GeoNet informal meeting on
>>>> 23rd
>>>>>>>> July at 20:30; IETF registration desk
>>>>>>>>
>>>>>>>> Le 31/07/2014 16:31, Dino Farinacci a écrit :
>>>>>>>>>
>>>>>>>>>> The problem is how to know that at a particular
>>>>>>>>>> geo-location a particular IP address is situated.
>>>>>>>>>> From this problem, the
>>>> question is
>>>>>>>>>> whether or not a _mapping_ mechanism [IP address,
>>>>>>>>>> geo-location]
>> is
>>>> a
>>>>>>>>>> sufficient tool to address that problem - be it
>>>>>>>>>> solved at layer 4
>>>> or
>>>>>>>>>> other.
>>>>>>>>>
>>>>>>>>> We have this in the LISP mapping database today. The
>>>>>>>>> enclosed
>>>> screen
>>>>>>>>> shot is a mapping entry registered with a LISP
>>>>>>>>> map-server in my lispers.net <http://lispers.net>
>>>>>>>>> implementation.
>>>>>>>>
>>>>>>>> Thanks for the pointer.
>>>>>>>>
>>>>>>>> I wonder whether you see any problem with the mapping:
>>>>>>>> geo: 40-35-18-N 73-40-3-W elp: 199.123.123.123(Rps)
>>>>>>>>
>>>>>>>> Could this mapping be used to geo-disseminate IP
>>>>>>>> packets to a
>>>> particular
>>>>>>>> geographical area?
>>>>>>>>
>>>>>>>> Alex
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Dino
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________ its
>>>>>>>> mailing list [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________ its mailing
>>>>> list [e-mail] https://www.ietf.org/mailman/listinfo/its
>>>
>>>
>>>
>
>