Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 01 Aug 2014 16:54:36 +0200

Hi Dino,

Thanks for the message.

Le 31/07/2014 16:59, Dino Farinacci a écrit :
>
>> 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)
>
> I do not. Right now the implementaiton puts geo-coordinates in RLOC
> records, but as I was saying in our impromtu meeting in Toronto, I
> envision "geo prefixes" which can be a circle, triangle, square or
> multi-point geometric shape be used as an EID record.

I think this is a good idea "geo prefix" to mean a larger area which 
contains several smaller areas and further multiple points (like an IPv6 
prefix /64 contains several /68 sub-prefixes and many /128 fully addresses).

> So I could describe a geo-prefix to be the "New York" area. That is
> registered that can yield a list of RLOC addresses of ETRs an ITR
> could encapsulate to. So when someone wants to know if Alex is in new
> york, we take your geo-coorindate "point" and do a longest match
> lookup and find the EID-prefix "New York".

I can understand.  But I do not know for sure a longest-match lookup is 
better than an exact-match, or some other 3-dimensional scheme 
(longest-match and exact-match lookups are for for 1-dimensional addresses).

> I have working through how to change the LISP Geo-Coordiante LCAF
> type to accommodate different "shapes'.
>
> The only missing piece is how an overlay device, like a LISP xTR
> knows what to lookup. This could be a control-plane play only.

The LISP example is handy for understanding.

In private I receive comments about DNS mapping as well, together with 
its shortcomings.

>> Could this mapping be used to geo-disseminate IP packets to a
>> particular geographical area?
>
> Only when the geo-coordinate is used as an EID lookup into the LISP
> mapping database.

But not all applications in the Internet know how to use EID.  They 
rather prefer to use an IP address, or an fqdn for that matter. (is an 
EID an IP address?  can it be an IPv6 address).

Alex

> Dino

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 01 Aug 2014 16:57:17 +0200

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.

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: [email-masked] ; <[email-masked]> ; [email-masked] ;
> <[email-masked]> ; <[email-masked]>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 1 Aug 2014 08:51:24 -0700

> But not all applications in the Internet know how to use EID.  They rather prefer to use an IP address, or an fqdn for that matter. (is an EID an IP address?  can it be an IPv6 address).

Applications today already use an EID. Reason being because they don't know it is an EID. The definition of an EID happens at a lower-level. By definition if the address is in the mapping database, it is an EID. Meaning an ITR has a place to encapsulate a packet for the destination EID.

Dino

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Aug 2014 16:23:10 +0200

Le 01/08/2014 18:47, Richard Roy a écrit :
> All,
>
> See comments below ...
>
> Cheers,
>
> RR
>> -----Original Message-----
>> From: Alexandru Petrescu [mailto:[email-masked]]
>> Sent: Friday, August 01, 2014 7:57 AM
>> To: Carl Reed; Dino Farinacci
>> Cc: [email-masked]; [email-masked]; [email-masked];
>> [email-masked]; [email-masked]
> [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

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 07 Aug 2014 09:58:36 -0700

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

---

From: <[email-masked]>
Date: Sun, 10 Aug 2014 06:41:28 +0000

Hi Richard,

I agree with you on the issue that in several cases PDFs and CDFs are needed in addition to confidence values of average values. Such cases arre e.g., maximum values of delays, of packet drops, etc.
The only remark I have is that when a 95% confidence interval for an average value is applied, usually it gives the region of support in which it is expected that 
500 from the 10000 experiments might lie.

Best regards,
Georgios

________________________________________
Van: Richard Roy [[email-masked]]
Verzonden: zondag 10 augustus 2014 6:21
Aan: 'Rex Buddenberg'; 'Alexandru Petrescu'
CC: 'Carl Reed'; 'Dino Farinacci'; Karagiannis, G. (EWI); [email-masked]; [email-masked]; [email-masked]
Onderwerp: RE: [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk

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

> From: Rex Buddenberg [mailto:[email-masked]]
> Sent: Thursday, August 07, 2014 9:59 AM
> To: Alexandru Petrescu
> Cc: [email-masked]; 'Carl Reed'; 'Dino Farinacci';
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Aug 2014 19:56:33 +0200

Le 07/08/2014 18:58, Rex Buddenberg a écrit :
> Every radionav system has a considered confidence value.  We only
> need to include them in the data formats,

I agree.  It just reminds me ETSI specifications of geonetworking do not
consider any form of confidence attached to coordinates - only
coordinates are exchanged.  This is one reason I think improvement is
necessary.

> 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.
>
> system advertises what it uses -- GPS and Loran, for example, both
> use WGS84.

Right, and not everything is WGS84 projection.  For example, the list of
water stations in a particular place (the stations warning about high
water risks) do not use WGS84.

I really think WGS84 is something used by many systems, but in practice
it may be a minority.  For comparison, IP is used everywhere in the same
way, but WGS84 has many other incompatible equivalent systems.

If striving to achieve same sense of universality, any IP message
containing coordinates should state in which reference system is that.

Alex

>>>> [mailto:[email-masked]] Sent: Friday, August 01,
>>>> 2014 7:57 AM To: Carl Reed; Dino Farinacci Cc:
>>>> [email-masked]; [email-masked]; [email-masked];
>>>> [email-masked]; [email-masked] Subject: Re: [geonet/its]
>>>> Agenda for the GeoNet informal meeting on 23rd July at 20:30;
>>>> IETF registration desk
>>>>
>>>>> 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
>>>>> (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:
>>>>> [email-masked] ; <[email-masked]> ;
>>>>> [email-masked] ; <[email-masked]> ; <[email-masked]>
>>>>> Subject: Re: [geonet/its] Agenda for the GeoNet informal
>>>>> meeting on 23rd July at 20:30; IETF registration desk
>>>>>
>>>>>>> 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.
>>>>>
>>>>> _______________________________________________ its mailing
>>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/its
>>>>>
>>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________ its mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/its
>
>
>
>

---

From: "Carl Reed" <[email-masked]>
Date: Mon, 11 Aug 2014 11:42:58 -0600

Sidebar -

In terms of a standard approach to encoding such confidence info/probability 
functions, check out UnCertML. http://www.uncertml.org/

Cheers

Carl

-----Original Message----- 
From: Richard Roy
Sent: Saturday, August 09, 2014 10:21 PM
To: 'Rex Buddenberg' ; 'Alexandru Petrescu'
Cc: 'Carl Reed' ; 'Dino Farinacci' ; [email-masked] ; 
[email-masked] ; [email-masked] ; [email-masked]
Subject: RE: [geonet/its] Agenda for the GeoNet informal meeting on 23rd 
July at 20:30; IETF registration desk

All,

RR

> standards)
> "confidence",

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Aug 2014 20:17:25 +0200

Le 10/08/2014 01:38, Richard Roy a écrit :
[...]
>> measures the lat/long/alt.
>
> [RR>] No.  Again, any statistically meaningful and optimal
> computation on the kinematic state estimates requires the estimate
> error covariance.  HDOP values are no where close to the necessary
> statistical information.

Look, I may not know these things too well.

But specifications which send messages containing coordinates without
any form of confidence attached to it (be it DOP or error covariance
estimations) are less useful.

As users, we are used to see screens positioning me on the roof of the
building whereas I am just next to it.  We just smile knowing the
shortcomings of that software.  But in vehicle to vehicle communications
these can not laugh - they need precision data.

>> I think this is the meaning of HDOP, PDOP, VDOP terms in GPS
>> parlance.
>
> [RR>] DOP is not a "confidence value".  DOP stands for Dilution Of
> Precision and is a consequence of the geometry of the satellites in
> view when a position "fix" is being made.  It is not a statistical
> "confidence" value of any kind.  Furthermore, the estimate error
> covariance matrix has ALL the "geometry" already taken into account.
> With the covariance matrix, there in no need for the DOP indicators.

Ok, I may have just invented the use of that word confidence in this
context, or maybe I've seen elsewhere.

The DOP is something that the end device can calculate independently.
This value is very useful if the end device receives badly the
covariance matrice supposedly computed by the satellites.

An end device which believes to be at 2, 49, 100, and receives a
covariance matrix 100% sure, bad under bad receive condition - may have
it all wrong.

On another hand an end device which believes to be at 2, 49, 100 and
realizes itself (by DOP means) that this data is foggy, may be better
informed than relying on the externally computed covariance matrix.

(I hope I used correctly this term covariance matrix).

>> 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.
>
> [RR>] Not so.  HDOP == 1 doesn't mean 10 cm "precision" in any
> coordinate.

I think HDOP==1 means 100% correct signal, as computed by the end device
itself.  Just as if it is at the exact reasonance, like an A.

10cm is the highest precision on some paying GPS systems, if I am not wrong.

HDOP is only for GPS devices, if I am not wrong.

> As I indicated below, these DOP numbers are meaningless once one has
>  the estimate error covariance matrix.  By sending the estimate error
>  covariance, the receiver has the information necessary to make
> optimal decisions!

Yes, as long as the device is sure to receive the estimate error
covariance in good conditions.  If that data is sent to the device via a
reliable link (i.e. an additional wifi interface of the computer) then
yes, that is good to rely on.  But if that data is sent on the same
channel as the satellite localiwation signal, then it may be error
prone, maybe not very good to rely on.

It's like a server telling an end user data that user knows better.

Alex

> The DOP values are useless in this regard.
>
>>
>> Alex
>>
>> Alex
>>>
>>>
>>>
>>>>
>>>> Alex
>>>>
>>>>>
>>>>> Regards
>>>>>
>> [email-masked] ;
>>>>> <[email-masked]> ; <[email-masked]> Subject: Re:
>>>>> [geonet/its] Agenda for the GeoNet informal meeting on
>> 23rd
>>>>>>> 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.
>>>>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Aug 2014 20:21:18 +0200

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.

Alex

---

From: "Carl Reed" <[email-masked]>
Date: Mon, 11 Aug 2014 12:32:29 -0600

Alex -

I would suggest checking out

Dynamic Host Configuration Protocol Options for Coordinate-Based Location 
Configuration Information

http://tools.ietf.org/html/rfc6225

May be very close to what this group is looking for in terms of a go forward 
"template"

Cheers

Carl

-----Original Message----- 
From: Alexandru Petrescu
Sent: Monday, August 11, 2014 12:21 PM
To: [email-masked] ; 'Rex Buddenberg'
Cc: 'Carl Reed' ; 'Dino Farinacci' ; [email-masked] ; 

Richard,

Alex

---

From: "Carl Reed" <[email-masked]>
Date: Mon, 11 Aug 2014 13:47:16 -0600

Alex et. al.

WGS 84 is not a projection. WGS 84 is an Earth-centered, Earth-fixed 
terrestrial reference system and geodetic datum (NGA). The expression and 
use of WGS 84 as a reference system is proscribed in how the coordinates are 
specified by the defining parameters. There are "flavors" for the defining 
parameters, typically whether the WGS 84 coordinate is 2d or 3d.

This is why the OGC and many other organizations use the EPSG CRS definition 
database as a normative reference for the defining parameter set for a WGS 
84 CRS (as well as a couple of thousand other CRS's!)

The OGC standards quite often reference EPSG 4326 for the CRS for 2d WGS 84 
coordinate sets.

A short WGS 84 EPSG CRS reference is: http://epsg.io/4326

The full EPSG database reference is here:

http://www.epsg-registry.org/report.htm?type=selection&entity=urn:ogc:def:crs:EPSG::4326&reportDetail=long&title=WGS%2084&style=urn:uuid:report-style:default-with-code&style_name=OGP%20Default%20With%20Code

As to the ubiquity of the use of WGS 84, this can be argued but from the OGC 
community perspective, WGS 84 is ubiquitous and should always be considered 
when modeling geographic information. The main issue is that programmers or 
systems ignore the CRS definition and create inconsistent representations 
that then inhibit interoperability and can actually cause life threatening 
situations.

Alex - In dealing with the hydrology/water community and can state that the 
majority (all?) hydrology/water sensor systems actual generate raw data 
using WGS 84 lat/long coordinates. Subsequent processing transforms the raw 
data from lat/long to some other CRS, such as State Plane in the US. This is 
because many GIS system users work in UTM or State Plane or some other 
reference system.

Cheers

Carl

-----Original Message----- 
From: Alexandru Petrescu
Sent: Monday, August 11, 2014 11:56 AM
To: Rex Buddenberg
Cc: [email-masked] ; 'Carl Reed' ; 'Dino Farinacci' ; 
[email-masked] ; [email-masked] ; [email-masked] ; 
[email-masked]
Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23rd 
July at 20:30; IETF registration desk

Alex

---

From: <[email-masked]>
Date: Tue, 12 Aug 2014 16:57:17 +0000

Hi Richard,

Thanks for the explanation!
Regarding the confidence interval definition, yes I agree with you. 
95% of the experiments run will result in an estimate within the 95% confidence interval!
I thought that in your previous email you meant that 5% of the experiments will result in an estimate within the 95% confidence interval!

Best regards,
Georgios

________________________________________
Van: Richard Roy [[email-masked]]
Verzonden: zondag 10 augustus 2014 21:28
Aan: Karagiannis, G. (EWI); [email-masked]; [email-masked]
CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Onderwerp: RE: [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk

> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, August 09, 2014 11:41 PM
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> I agree with you on the issue that in several cases PDFs and CDFs are
> needed in addition to confidence values of average values. Such cases arre
> e.g., maximum values of delays, of packet drops, etc.

[RR>] To reiterate, the confidence interval is an estimate of a support
region for the outcome of multiple experiments.  It's just not all that
useful for making decisions based on a particular outcome of an "experiment"
(i.e. a particular output of a GNSS device [t, lat, long, alt] and its
estimate error covariance).

> The only remark I have is that when a 95% confidence interval for an
> average value is applied, usually it gives the region of support in which
> it is expected that

[RR>] Actually it's 9500.  That is, 95% of the experiments run will result
in an estimate within the 95% confidence interval.

RR

> CC: 'Carl Reed'; 'Dino Farinacci'; Karagiannis, G. (EWI);
> [email-masked]; [email-masked]; [email-masked]
> > > >>> 1. Specifying a lat/long coordinate in the form 40-35-18-N 73-40-
> 3-W
> > is
> > > >>> (https://portal.opengeospatial.org/files/?artifact_id=44146) or
> how
> > geo
> > > > theorem, this distribution can be assumed to be multi-variate
> Gaussian
> > with
> > > >>> Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting
> on
> > 23rd
> > > >>>>> 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.
> > > >>>>
> > > https://www.ietf.org/mailman/listinfo/its=

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 25 Aug 2014 15:41:21 +0200

Le 11/08/2014 20:32, Carl Reed a écrit :
> Dynamic Host Configuration Protocol Options for Coordinate-Based
> Location Configuration Information
>
> May be very close to what this group is looking for in terms of a go
>  forward "template"

Thank you for this pointer, I didn't know about that RFC.

It may be a good template to follow in a use-case where an object needs
to acquire its position from a DHCP Server.  But I would think that a
moving vehicle would need to determine their position from their onboard
Galileo receiver, and maybe less from a DHCP Server along the route.

It is interesting to note that this RFC considers several reference
datums (data?): WGS84, NAD83+NAVD88 and NAD83+MLLW.  Whereas other
documents consider only one such reference datum (e.g. ETSI EN 302
636-4-1 'Geographical addressing and forwarding...' which considers
WGS84 exclusively).

Also, if I am not wrong, there exist more reference data, or reference
'systems', currently in use.  One example is ED50 (and not WGS84) is
used in some places to specify the places where the IEEE 802.11p 5GHz
frequencies must not be used.  Imagine writing software on-board a
vehicle which needs to determine by itself whether or not it can turn on
its 802.11p radio.

Additionally, some systems specify the placement of objects by
coordinates in a projection, not on a geoid.  Such projections are
incompatible with WGS84.  For example, again sorry repeating, list of
hydrostations in France are Lambert II Coordinates 'x' and 'y' (and not
WGS84 reference datum latitude longitude).

Not to mention that, if I understand correctly, the Galileo coordinates
are with respect to ITRF (and not WGS-84).

Finally, it is interesting to note that RFC6225 does consider uncertainty.

Alex

>
> Cheers
>
> Carl
>
>
> -----Original Message----- From: Alexandru Petrescu Sent: Monday,
> August 11, 2014 12:21 PM To: [email-masked] ; 'Rex Buddenberg'
> [email-masked] ; [email-masked] ; [email-masked] Subject: Re:
> [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at
> 20:30; IETF registration desk
>
> Richard,
>
> read by as many systems as possible, should state how sure is it
> about them and in which reference system.
>
> Alex
>
>> 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:[email-masked]] Sent: Thursday, August 07, 2014
>>> 9:59 AM To: Alexandru Petrescu Cc: [email-masked]; 'Carl
>>> Reed'; 'Dino Farinacci'; [email-masked];
>>> [email-masked]; [email-masked]; [email-masked] Subject:
>>> Re: [geonet/its] Agenda for the GeoNet informal meeting on 23rd
>>> 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
>>> 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.
>>>
>>>
>>>>>> [mailto:[email-masked]] Sent: Friday, August
>>>>>> 01, 2014 7:57 AM To: Carl Reed; Dino Farinacci Cc:
>>>>>> [email-masked]; [email-masked];
>>>>>> [email-masked]; [email-masked]; [email-masked]
>>>>>> meeting on
>>>>>>> 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
>>>>>>> or how
>>>>>>> is encoded in vcard and icalendar and in the location
>>>>>>> object (LO)
>>> for
>>>>>>> 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.
>>>>>>
>>>>>> clear
>>> about
>>>>>> 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.
>>>>>
>>>>> 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.
>>>>
>>>> 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
>>>>>>>
>>>>>>>>> geo-location a particular IP address is situated.
>>>>>>>>> From this problem, the
>>> question is
>>>>>>>>> geo-location] is
>>>>>>>>> sufficient tool to address that problem - be it
>>>>>>>>> solved at layer 4
>>> or
>>>>>>>>> other.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>> geo: 40-35-18-N 73-40-3-W elp: 199.123.123.123(Rps)
>>>>>>>
>>>>>>> _______________________________________________ its
>>>>>>> mailing list [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 25 Aug 2014 15:58:06 +0200

Le 11/08/2014 21:15, Richard Roy a écrit :
>> [mailto:[email-masked]] Sent: Monday, August 11, 2014
>> 11:21 AM To: [email-masked]; 'Rex Buddenberg' Cc: 'Carl
>> [email-masked]; [email-masked]; [email-masked] Subject: Re:
>> 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
> [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

>>> 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
>> 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
>> 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
>>>
>>>> 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.
>>>>
>>>>>>> [mailto:[email-masked]] Sent: Friday,
>>>>>>> August 01, 2014 7:57 AM To: Carl Reed; Dino Farinacci Cc:
>>>>>>>> 40-35-18-N 73-40-3-
>> W
>>>>>>>> 2. I would check out other lightweight encodings such
>>>>>>>> as Open
>> GeoSMS
>>>>>>>> the need to specify the CRS (coordinate reference
>>>>>>>> system) being
>>> used.
>>>>>>> I would argue we need the message, or the computers, to
>>>>>>> be clear
>>>> about
>>>>>>> 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.
>>>>>>
>>>>>> that has a probability distribution associated with it.
>>>>>> Using the central limit theorem, this distribution can be
>>>>>> assumed to be multi-variate
>> Gaussian
>>>> with
>>>>> the GNSS system to the terminal computer, there is a need of
>>>>> a 'confidence'
>> value
>>>>> lat/long/alt.  I think this is the meaning of HDOP, PDOP,
>>>>> VDOP terms
>> in
>>>>> GPS parlance.
>>>>>
>>>>> 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
>>>>>>>>
>>>>>>>> Sent: Thursday, July 31, 2014 8:36 AM To: Dino
>>>>>>>> Farinacci Cc: [email-masked] ;
>>>>>>>> <[email-masked]> ;
>>>> [email-masked] ;
>>>>>>>>>> geo-location]

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 28 Aug 2014 15:17:23 +0200

Carl,

I agree WGS84 is not a projection.  Maybe I would have better said ("not 
everything is a reference system and not everything is a projection").

WGS84 is a reference system.

Lambert II is a projection.

The position of one object can be specified either as WGS84 
lat/long/alt, or as Lambert II X/Y.

It is like networked Computers: their address can be specified either as 
an IP address or as a name.

The hydrology comment: thank you for the recommendation of mentioning 
that it is sensors who output the WGS84 data - it is useful to use it in 
some conversations.  But, I would like to add that in some places the 
position of a hydrology station is not output by a sensor, but it is 
known and mapped since hundreds of years when sensors did not exist, and 
it is this data that gets published on the web, directly from the paper 
archives.  The same situation (publication from paper archive to web, 
not from sensor to web) happens also with describing the positions of 
buildings in some places.

Alex

Le 11/08/2014 21:47, Carl Reed a écrit :
> terrestrial reference system and geodetic datum (NGA). The expression
> and use of WGS 84 as a reference system is proscribed in how the
> coordinates are specified by the defining parameters. There are
> "flavors" for the defining parameters, typically whether the WGS 84
> coordinate is 2d or 3d.
>
> This is why the OGC and many other organizations use the EPSG CRS
> definition database as a normative reference for the defining parameter
> set for a WGS 84 CRS (as well as a couple of thousand other CRS's!)
>
> The OGC standards quite often reference EPSG 4326 for the CRS for 2d WGS
> 84 coordinate sets.
>
> As to the ubiquity of the use of WGS 84, this can be argued but from the
> OGC community perspective, WGS 84 is ubiquitous and should always be
> considered when modeling geographic information. The main issue is that
> programmers or systems ignore the CRS definition and create inconsistent
> representations that then inhibit interoperability and can actually
> cause life threatening situations.
>
> Alex - In dealing with the hydrology/water community and can state that
> the majority (all?) hydrology/water sensor systems actual generate raw
> data using WGS 84 lat/long coordinates. Subsequent processing transforms
> the raw data from lat/long to some other CRS, such as State Plane in the
> US. This is because many GIS system users work in UTM or State Plane or
> some other reference system.
>
> Cheers
>
> Carl
>