From nobody Fri Aug 1 07:55:05 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D18F1B27B3 for ; Fri, 1 Aug 2014 07:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNw5BbR4E73P for ; Fri, 1 Aug 2014 07:55:01 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E105A1B27B1 for ; Fri, 1 Aug 2014 07:55:00 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s71Esfaf005113; Fri, 1 Aug 2014 16:54:41 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2AB132074E9; Fri, 1 Aug 2014 16:57:33 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 122CF203FDD; Fri, 1 Aug 2014 16:57:33 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s71Esa9A022804; Fri, 1 Aug 2014 16:54:41 +0200 Message-ID: <53DBAA2C.6090503@gmail.com> Date: Fri, 01 Aug 2014 16:54:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dino Farinacci References: <7C75B9AA7E16464496CBA2BFCB5C8786@SRA4> <53DA3DD3.8080501@gmail.com> <53DA5468.2090405@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/Ajjz4wpHckFBhxayxkXmGJyRDBE Cc: "" , "" , "" , "" , Victor Moreno , dickroy@alum.mit.edu Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 14:55:03 -0000 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 nobody Fri Aug 1 07:57:42 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E166B1B27B6 for ; Fri, 1 Aug 2014 07:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56yUsqNCotuN for ; Fri, 1 Aug 2014 07:57:38 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B2A71A0040 for ; Fri, 1 Aug 2014 07:57:37 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s71EvHVA016832; Fri, 1 Aug 2014 16:57:17 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 83541203C78; Fri, 1 Aug 2014 17:00:09 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6CBA0203A9A; Fri, 1 Aug 2014 17:00:09 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s71EvHX2024124; Fri, 1 Aug 2014 16:57:17 +0200 Message-ID: <53DBAACD.2070101@gmail.com> Date: Fri, 01 Aug 2014 16:57:17 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Carl Reed , Dino Farinacci References: <7C75B9AA7E16464496CBA2BFCB5C8786@SRA4> <53DA3DD3.8080501@gmail.com> <53DA5468.2090405@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/2_96cDe0GQ2EypzeyItWQzRxDQk Cc: dickroy@alum.mit.edu, melinda.shore@gmail.com, karagian@cs.utwente.nl, lear@cisco.com, its@ietf.org Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 14:57:41 -0000 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: dickroy@alum.mit.edu ; ; lear@cisco.com ; > ; > 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 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 > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From nobody Fri Aug 1 08:51:31 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96B11A0B0C for ; Fri, 1 Aug 2014 08:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g74sgSEMdqA5 for ; Fri, 1 Aug 2014 08:51:28 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 984D71B27C3 for ; Fri, 1 Aug 2014 08:51:28 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id y13so5782263pdi.11 for ; Fri, 01 Aug 2014 08:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5HgzyMEgEWZc4rk7uQCXD81I1yxV9wHSkwHy1EoHsvo=; b=Sk3B5pQpUcqK+g9e75knX7/QHpqdFeEPZe3tcAu3+Vr1o1TMPYdAysPFjb7Y5E6PCE H5/L93tlVlsKDbBGMLGitwEjrCtTvL7vQDBTka930PpuyGJWtkf+a+aHerFZxvQWiU+u +MJOA5vd8xbaiojf+MHbRs5d1tqlw27Ju3nWLt/+2UEMEQq3G+R8epKzHjX/au+9IJG4 KmmxZ9WmGKG3OpiVrovjNFnumjgTfqLChDePOZpNjgXFZC0mDK0RCf1kqlUNtCeCSVja tNsFSMMXFWJd+bQB0x201HpqlGiwWa0VNuKy46BsgeMO2uex0tdBDqQlHOslm7UzQSjS 58Nw== X-Received: by 10.66.150.37 with SMTP id uf5mr7259701pab.36.1406908288284; Fri, 01 Aug 2014 08:51:28 -0700 (PDT) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id et1sm9075556pbc.39.2014.08.01.08.51.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Aug 2014 08:51:26 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dino Farinacci In-Reply-To: <53DBAA2C.6090503@gmail.com> Date: Fri, 1 Aug 2014 08:51:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C75B9AA7E16464496CBA2BFCB5C8786@SRA4> <53DA3DD3.8080501@gmail.com> <53DA5468.2090405@gmail.com> <53DBAA2C.6090503@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/its/tolYVvctaDBkxkNdV1UuOeFkXB0 Cc: "" , "" , "" , "" , Victor Moreno , dickroy@alum.mit.edu Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 15:51:30 -0000 > 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 nobody Thu Aug 7 07:23:31 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3DF1B2B28 for ; Thu, 7 Aug 2014 07:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4fKcu4sZgCr for ; Thu, 7 Aug 2014 07:23:25 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 245DC1B2B5B for ; Thu, 7 Aug 2014 07:23:24 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s77ENFNJ013058; Thu, 7 Aug 2014 16:23:15 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 02CF2202C4F; Thu, 7 Aug 2014 16:26:16 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DFC2C2044C8; Thu, 7 Aug 2014 16:26:15 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s77ENA6k006328; Thu, 7 Aug 2014 16:23:15 +0200 Message-ID: <53E38BCE.9050704@gmail.com> Date: Thu, 07 Aug 2014 16:23:10 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dickroy@alum.mit.edu, "'Carl Reed'" , "'Dino Farinacci'" References: <7C75B9AA7E16464496CBA2BFCB5C8786@SRA4> <53DA3DD3.8080501@gmail.com> <53DA5468.2090405@gmail.com> <53DBAACD.2070101@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/hjrTsVk9IZsDw7NTzUjJARvEuWE Cc: karagian@cs.utwente.nl, melinda.shore@gmail.com, its@ietf.org, lear@cisco.com Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 14:23:28 -0000 Le 01/08/2014 18:47, Richard Roy a écrit : > All, > > See comments below ... > > Cheers, > > RR >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Friday, August 01, 2014 7:57 AM >> To: Carl Reed; Dino Farinacci >> Cc: dickroy@alum.mit.edu; melinda.shore@gmail.com; lear@cisco.com; >> karagian@cs.utwente.nl; its@ietf.org >> 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: dickroy@alum.mit.edu ; ; lear@cisco.com ; >>> ; >>> 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 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 >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>> >>> > > > From nobody Thu Aug 7 09:58:45 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCF41B2E8F for ; Thu, 7 Aug 2014 09:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUkPnkzJqRtl for ; Thu, 7 Aug 2014 09:58:39 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A6E1B2E86 for ; Thu, 7 Aug 2014 09:58:39 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id bj1so5737759pad.11 for ; Thu, 07 Aug 2014 09:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=JGITKhN58REbR4aSaxfrz7sH/UUNCMrc3i2Iy+gJbXg=; b=EPr1KUa0OJgL1sfjHWI10NNvgXD3+w9uXNjZGIWoMTryKoDr1uV+vkxqHWJsQYmMaz ejd+VDlCoXzGu8gUWaPXfYqYLMnHxKlOPhvKJ/D2HeQI+UeIJ+U0S3Mk/35z9Hy/IqtT C/bN9sH3D9tnrb2Ng5C5FK7V1wno6iK2mjJOlJG0N7mXyOVwCVw3gn+bxA3mBBLIi7hm xuKCXJhz/4j+KOf4qGwUDyQ75gyFWk2ewdNMmQcAr+qB/qZiKZ6gwpqIPf9ZNlRfkb3E WChUQvaY/LY/wIH9B0j+pSxCxQuCmqE0My6PS9Wz/Q+ldnAm3aTfkjljc0+wXAUKVW/S CxjA== X-Received: by 10.70.103.175 with SMTP id fx15mr19090326pdb.94.1407430718875; Thu, 07 Aug 2014 09:58:38 -0700 (PDT) Received: from [192.168.1.103] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id xz7sm16357374pac.3.2014.08.07.09.58.37 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 Aug 2014 09:58:38 -0700 (PDT) Message-ID: <1407430716.3050.28.camel@localhost> From: Rex Buddenberg To: Alexandru Petrescu Date: Thu, 07 Aug 2014 09:58:36 -0700 In-Reply-To: <53E38BCE.9050704@gmail.com> References: <7C75B9AA7E16464496CBA2BFCB5C8786@SRA4> <53DA3DD3.8080501@gmail.com> <53DA5468.2090405@gmail.com> <53DBAACD.2070101@gmail.com> <53E38BCE.9050704@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-2.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/odcw-VV1EI74MkmYKUPADrZkgs0 Cc: lear@cisco.com, its@ietf.org, melinda.shore@gmail.com, karagian@cs.utwente.nl, 'Dino Farinacci' , dickroy@alum.mit.edu Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 16:58:42 -0000 > 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:alexandru.petrescu@gmail.com] > >> Sent: Friday, August 01, 2014 7:57 AM > >> To: Carl Reed; Dino Farinacci > >> Cc: dickroy@alum.mit.edu; melinda.shore@gmail.com; lear@cisco.com; > >> karagian@cs.utwente.nl; its@ietf.org > >> 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: dickroy@alum.mit.edu ; ; lear@cisco.com ; > >>> ; > >>> 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 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 > >>> its@ietf.org > >>> https://www.ietf.org/mailman/listinfo/its > >>> > >>> > > > > > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Sat Aug 9 23:41:45 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CC01A0669 for ; Sat, 9 Aug 2014 23:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5p8dj1megmdf for ; Sat, 9 Aug 2014 23:41:41 -0700 (PDT) Received: from out62-ams.mf.surf.net (out62-ams.mf.surf.net [145.0.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149621A0319 for ; Sat, 9 Aug 2014 23:41:40 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id s7A6iJgk008295; Sun, 10 Aug 2014 08:44:19 +0200 Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 10 Aug 2014 08:41:37 +0200 Received: from EXMBX24.ad.utwente.nl ([169.254.4.146]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.03.0181.006; Sun, 10 Aug 2014 08:41:30 +0200 From: To: , , Thread-Topic: [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk Thread-Index: AQHPnZB4AVfSUsfRF06Y2IP/wtf3UZu3gpqAgAKfbYCAABlvgIAAAX0AgAAG44CAAZFHgIAAHr6AgAlFtwCAACttAIAD42OAgABGe98= Date: Sun, 10 Aug 2014 06:41:28 +0000 Message-ID: References: <7C75B9AA7E16464496CBA2BFCB5C8786@SRA4> <53DA3DD3.8080501@gmail.com> <53DA5468.2090405@gmail.com> <53DBAACD.2070101@gmail.com> <53E38BCE.9050704@gmail.com> <1407430716.3050.28.camel@localhost>,<520DD834BE0E4DFF94AFE61EC46A484B@SRA4> In-Reply-To: <520DD834BE0E4DFF94AFE61EC46A484B@SRA4> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.9.237] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Bayes-Prob: 0.5 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.48; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0bMASIjxV - 6e95de3d1bc0 - 20140810 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/its/3fiKqJYlXQdXhYWYg31FA7LYzrM Cc: lear@cisco.com, melinda.shore@gmail.com, its@ietf.org, farinacci@gmail.com Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 06:41:44 -0000 Hi Richard, I agree with you on the issue that in several cases PDFs and CDFs are neede= d 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 averag= e value is applied, usually it gives the region of support in which it is e= xpected that=20 500 from the 10000 experiments might lie. Best regards, Georgios ________________________________________ Van: Richard Roy [dickroy@alum.mit.edu] Verzonden: zondag 10 augustus 2014 6:21 Aan: 'Rex Buddenberg'; 'Alexandru Petrescu' CC: 'Carl Reed'; 'Dino Farinacci'; Karagiannis, G. (EWI); melinda.shore@gma= il.com; its@ietf.org; lear@cisco.com 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 i= n 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 a= s 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:buddenbergr@gmail.com] > Sent: Thursday, August 07, 2014 9:59 AM > To: Alexandru Petrescu > Cc: dickroy@alum.mit.edu; 'Carl Reed'; 'Dino Farinacci'; > karagian@cs.utwente.nl; melinda.shore@gmail.com; its@ietf.org; > lear@cisco.com > 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 =E9crit : > > > All, > > > > > > See comments below ... > > > > > > Cheers, > > > > > > RR > > >> -----Original Message----- > > >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > >> Sent: Friday, August 01, 2014 7:57 AM > > >> To: Carl Reed; Dino Farinacci > > >> Cc: dickroy@alum.mit.edu; melinda.shore@gmail.com; lear@cisco.com; > > >> karagian@cs.utwente.nl; its@ietf.org > > >> 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 =E9crit : > > >>> 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 GeoSM= S > > >>> (https://portal.opengeospatial.org/files/?artifact_id=3D44146) or h= ow > 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 Gaussia= n > 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' valu= e > > 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 an= d > > believes it to be 2, 49, 100, it must tell other vehicles that it just > > _thinks_ to be there (i.e. HDOP=3D=3D1, really there with a 10centimete= r > > precision, or HDOP=3D=3D5 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: dickroy@alum.mit.edu ; ; > lear@cisco.com ; > > >>> ; > > >>> 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 =E9crit : > > >>>> > > >>>>> 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] i= s > 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 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 > > >>> its@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/its > > >>> > > >>> > > > > > > > > > > > > > > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its= From nobody Mon Aug 11 10:57:27 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28D31A04AB for ; Mon, 11 Aug 2014 10:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSp7i5hkfr0Q for ; Mon, 11 Aug 2014 10:57:23 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 593EB1A048D for ; Mon, 11 Aug 2014 10:57:23 -0700 (PDT) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s7BHvBpp019299; Mon, 11 Aug 2014 19:57:11 +0200 Received: from nephilia.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 530DF1C0D36; Mon, 11 Aug 2014 19:56:51 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (Postfix) with ESMTP id 3A9791C0CDD; Mon, 11 Aug 2014 19:56:51 +0200 (CEST) Received: from [127.0.0.1] ([132.166.86.4]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s7BHuXgS010246; Mon, 11 Aug 2014 19:56:40 +0200 Message-ID: <53E903D1.5000808@gmail.com> Date: Mon, 11 Aug 2014 19:56:33 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Rex Buddenberg References: <7C75B9AA7E16464496CBA2BFCB5C8786@SRA4> <53DA3DD3.8080501@gmail.com> <53DA5468.2090405@gmail.com> <53DBAACD.2070101@gmail.com> <53E38BCE.9050704@gmail.com> <1407430716.3050.28.camel@localhost> In-Reply-To: <1407430716.3050.28.camel@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/jYeRIcvIdnpXQHRP3OTsNURwUX4 Cc: lear@cisco.com, its@ietf.org, melinda.shore@gmail.com, karagian@cs.utwente.nl, 'Dino Farinacci' , dickroy@alum.mit.edu Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 17:57:26 -0000 Le 07/08/2014 18:58, Rex Buddenberg a écrit : > >> 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, 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. > > 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. 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 > > > 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:alexandru.petrescu@gmail.com] Sent: Friday, August 01, >>>> 2014 7:57 AM To: Carl Reed; Dino Farinacci Cc: >>>> dickroy@alum.mit.edu; melinda.shore@gmail.com; lear@cisco.com; >>>> karagian@cs.utwente.nl; its@ietf.org 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: >>>>> dickroy@alum.mit.edu ; ; >>>>> lear@cisco.com ; ; >>>>> 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 >>>>>> 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 its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>> >>> >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > > > From nobody Mon Aug 11 11:00:48 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA701A04AF for ; Mon, 11 Aug 2014 11:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ng1nHTXDXUH3 for ; Mon, 11 Aug 2014 11:00:41 -0700 (PDT) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id AF5961A0478 for ; Mon, 11 Aug 2014 11:00:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id CDCE094582; Mon, 11 Aug 2014 14:00:40 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (scale.ogcinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVup1rHkQsmQ; Mon, 11 Aug 2014 14:00:39 -0400 (EDT) Received: from mail2.standardsmail.org (mail2.standardsmail.org [66.244.86.41]) by mail.opengeospatial.org (Postfix) with ESMTP id C4CE094581; Mon, 11 Aug 2014 14:00:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail2.standardsmail.org (Postfix) with ESMTP id BB637E674D4; Mon, 11 Aug 2014 14:00:39 -0400 (EDT) Received: from mail2.standardsmail.org ([127.0.0.1]) by localhost (mail2.standardsmail.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id gfJrLwCUqWIR; Mon, 11 Aug 2014 14:00:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail2.standardsmail.org (Postfix) with ESMTP id 890BAE66FB2; Mon, 11 Aug 2014 14:00:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.standardsmail.org Received: from mail2.standardsmail.org ([127.0.0.1]) by localhost (mail2.standardsmail.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lm78AXDRsFlG; Mon, 11 Aug 2014 14:00:38 -0400 (EDT) Received: from OfficeHP (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail2.standardsmail.org (Postfix) with ESMTPSA id A6364E64F60; Mon, 11 Aug 2014 14:00:37 -0400 (EDT) Message-ID: <3FD19BB517994A4780FD222AD237352A@OfficeHP> From: "Carl Reed" To: , "'Rex Buddenberg'" , "'Alexandru Petrescu'" References: <7C75B9AA7E16464496CBA2BFCB5C8786@SRA4> <53DA3DD3.8080501@gmail.com> <53DA5468.2090405@gmail.com> <53DBAACD.2070101@gmail.com> <53E38BCE.9050704@gmail.com> <1407430716.3050.28.camel@localhost> <520DD834BE0E4DFF94AFE61EC46A484B@SRA4> In-Reply-To: <520DD834BE0E4DFF94AFE61EC46A484B@SRA4> Date: Mon, 11 Aug 2014 11:42:58 -0600 Organization: OGC MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/its/nJEaRWzJcQ3PFvVrrmUQX1tctCQ Cc: karagian@cs.utwente.nl, melinda.shore@gmail.com, lear@cisco.com, its@ietf.org, 'Dino Farinacci' Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 18:00:44 -0000 Sidebar - In terms of a standard approach to encoding such confidence info/probabil= ity=20 functions, check out UnCertML. http://www.uncertml.org/ Cheers Carl -----Original Message-----=20 From: Richard Roy Sent: Saturday, August 09, 2014 10:21 PM To: 'Rex Buddenberg' ; 'Alexandru Petrescu' Cc: 'Carl Reed' ; 'Dino Farinacci' ; karagian@cs.utwente.nl ;=20 melinda.shore@gmail.com ; its@ietf.org ; lear@cisco.com Subject: RE: [geonet/its] Agenda for the GeoNet informal meeting on 23rd=20 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 a= re 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 'go= od' rather than 'bad'", this in not statistical "confidence". In fact, it's useless information to any receiver that thinks rationally, not emotional= ly. RR > -----Original Message----- > From: Rex Buddenberg [mailto:buddenbergr@gmail.com] > Sent: Thursday, August 07, 2014 9:59 AM > To: Alexandru Petrescu > Cc: dickroy@alum.mit.edu; 'Carl Reed'; 'Dino Farinacci'; > karagian@cs.utwente.nl; melinda.shore@gmail.com; its@ietf.org; > lear@cisco.com > Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23r= d > 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) i= n > 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 =E9crit : > > > All, > > > > > > See comments below ... > > > > > > Cheers, > > > > > > RR > > >> -----Original Message----- > > >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > >> Sent: Friday, August 01, 2014 7:57 AM > > >> To: Carl Reed; Dino Farinacci > > >> Cc: dickroy@alum.mit.edu; melinda.shore@gmail.com; lear@cisco.com; > > >> karagian@cs.utwente.nl; its@ietf.org > > >> Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting o= n > 23rd > > >> July at 20:30; IETF registration desk > > >> > > >> Le 31/07/2014 17:01, Carl Reed a =E9crit : > > >>> 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 coordinate= s > is > > >>> done in decimal degrees. While the format you show is perhaps nic= e > 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 Geo= SMS > > >>> (https://portal.opengeospatial.org/files/?artifact_id=3D44146) 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 th= e > > >> 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 estimate= d > > > 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 limi= t > > > theorem, this distribution can be assumed to be multi-variate Gauss= ian > 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) estimate= s. > > > That's what you want! > > > > In addition to that estimate error covariance communicated by the GNS= S > > system to the terminal computer, there is a need of a 'confidence' va= lue > > 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 jus= t > > _thinks_ to be there (i.e. HDOP=3D=3D1, really there with a 10centime= ter > > precision, or HDOP=3D=3D5 meaning a sphere of radius of 100meter). > > Otherwise other vehicles may send messages to that vehicle in the wro= ng > > 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: dickroy@alum.mit.edu ; ; > lear@cisco.com ; > > >>> ; > > >>> 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 =E9crit : > > >>>> > > >>>>> 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 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 > > >>> its@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/its > > >>> > > >>> > > > > > > > > > > > > > > > _______________________________________________ > > its mailing list > > its@ietf.org > > https://www.ietf.org/mailman/listinfo/its From nobody Mon Aug 11 11:17:37 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28C61A0711 for ; Mon, 11 Aug 2014 11:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5ghmNQNfGN5 for ; Mon, 11 Aug 2014 11:17:30 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D141A072C for ; Mon, 11 Aug 2014 11:17:28 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so8768166wgh.3 for ; Mon, 11 Aug 2014 11:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=tJml25KB4/YDbaXORRAn4WCa3Z1CIv+l9mhD0SNjP2E=; b=Xc7wFIOBuO+eVEYvCCaBdOJSp1NQ1zaCuTs8nHlevIvs2AJpvVR+hKQcw+ydDyCL/x iU41ubVXbPzvEDUlm8uszC6erugQxv6INBg5U2q/aITpWAE2c4n8ncD+MQl6tFcGPwZu pt0Q1jk8jyhpd/SMVh8r4loTOm1wIvKWvI5m53G7w6MLJNSE9LTaZwAnfskHdhzE1dfw 5Ox3vKWmxJiTCPo/ew7uT2wxmPz3SJepsJ3wlPMMAzLDxUcyc5YJrjSyRP9pnzlc8u4g +LzRu9Dq3J9+tm7RE7UH0ry3hsMDo2ToDQn+zAvwTaVtuHOAiSENp8f88E/IxFoEJRlF uLaw== X-Received: by 10.194.236.35 with SMTP id ur3mr12809287wjc.127.1407781047680; Mon, 11 Aug 2014 11:17:27 -0700 (PDT) Received: from [192.168.0.18] (mry91-1-82-229-156-225.fbx.proxad.net. [82.229.156.225]) by mx.google.com with ESMTPSA id ja13sm46582515wic.8.2014.08.11.11.17.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Aug 2014 11:17:27 -0700 (PDT) Message-ID: <53E908B5.8050301@gmail.com> Date: Mon, 11 Aug 2014 20:17:25 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dickroy@alum.mit.edu, 'Carl Reed' , 'Dino Farinacci' References: <7C75B9AA7E16464496CBA2BFCB5C8786@SRA4> <53DA3DD3.8080501@gmail.com> <53DA5468.2090405@gmail.com> <53DBAACD.2070101@gmail.com> <53E38BCE.9050704@gmail.com> <26FE3B6E9AD84928B0A91402371F93B6@SRA4> In-Reply-To: <26FE3B6E9AD84928B0A91402371F93B6@SRA4> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/hgB7a2Kb8hD2ODSR4hgGPjevI8c Cc: karagian@cs.utwente.nl, melinda.shore@gmail.com, its@ietf.org, lear@cisco.com Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 18:17:32 -0000 Le 10/08/2014 01:38, Richard Roy a écrit : [...] >> 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. > > [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). >> 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. > > [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 >>>>> >>>>> Carl Reed, PhD CTO Open Geospatial Consortium >>>>> >>>>> -----Original Message----- From: Alexandru Petrescu Sent: >>>>> Thursday, July 31, 2014 8:36 AM To: Dino Farinacci Cc: >>>>> dickroy@alum.mit.edu ; ; >> lear@cisco.com ; >>>>> ; 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 >>>>>> 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 its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>> >>> >>> > > > From nobody Mon Aug 11 11:21:29 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9B71A072E for ; Mon, 11 Aug 2014 11:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxZ8RjbRJMoT for ; Mon, 11 Aug 2014 11:21:23 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD97E1A0747 for ; Mon, 11 Aug 2014 11:21:21 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id m15so8890798wgh.29 for ; Mon, 11 Aug 2014 11:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=C+eIWnwZhzxjs15LC5Unj6pozLWMKbMD8w1e9OB779M=; b=CGx0gNf32TaAISPrrsyk9qltrs/Nzs192V+CzXxUepwEm/5jiK8qHxW+PCYABeBx7W X7pxf9HJNGyODLbynxFz9nAqczdHyyYx3vBYHnu2C7lvQ2mVcWIzsVM5wHHE48W59UfY lwa7vMQ73R4ZqQmaffpOH4EBpqUXm/L3lvTuRoEhdAIKaJCstMu3wHwx3PxC3Yu4lstp sAjftyc1Y35Kak6sbFZD5fhFzycCmAa3lBbgG0Tf8Dc4LI8XS7IxnjywucxMQrWOuRSR K5KdUmQfI1vp0kqYTvYI8OifbL071/yic3pt//uq7KT7yovXexJSPWRd0jvuBnl74VTd C+QA== X-Received: by 10.194.22.166 with SMTP id e6mr57437049wjf.88.1407781280126; Mon, 11 Aug 2014 11:21:20 -0700 (PDT) Received: from [192.168.0.18] (mry91-1-82-229-156-225.fbx.proxad.net. [82.229.156.225]) by mx.google.com with ESMTPSA id gb5sm46625211wib.8.2014.08.11.11.21.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Aug 2014 11:21:19 -0700 (PDT) Message-ID: <53E9099E.4090101@gmail.com> Date: Mon, 11 Aug 2014 20:21:18 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dickroy@alum.mit.edu, 'Rex Buddenberg' References: <7C75B9AA7E16464496CBA2BFCB5C8786@SRA4> <53DA3DD3.8080501@gmail.com> <53DA5468.2090405@gmail.com> <53DBAACD.2070101@gmail.com> <53E38BCE.9050704@gmail.com> <1407430716.3050.28.camel@localhost> <520DD834BE0E4DFF94AFE61EC46A484B@SRA4> In-Reply-To: <520DD834BE0E4DFF94AFE61EC46A484B@SRA4> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/SU-K5juQm94npVSK5GoH8gBZPJk Cc: lear@cisco.com, its@ietf.org, melinda.shore@gmail.com, karagian@cs.utwente.nl, 'Dino Farinacci' Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 18:21:26 -0000 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 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:buddenbergr@gmail.com] >> Sent: Thursday, August 07, 2014 9:59 AM >> To: Alexandru Petrescu >> Cc: dickroy@alum.mit.edu; 'Carl Reed'; 'Dino Farinacci'; >> karagian@cs.utwente.nl; melinda.shore@gmail.com; its@ietf.org; >> lear@cisco.com >> 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:alexandru.petrescu@gmail.com] >>>>> Sent: Friday, August 01, 2014 7:57 AM >>>>> To: Carl Reed; Dino Farinacci >>>>> Cc: dickroy@alum.mit.edu; melinda.shore@gmail.com; lear@cisco.com; >>>>> karagian@cs.utwente.nl; its@ietf.org >>>>> 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: dickroy@alum.mit.edu ; ; >> lear@cisco.com ; >>>>>> ; >>>>>> 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 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 >>>>>> its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its > > > From nobody Mon Aug 11 11:38:11 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062BB1A0761 for ; Mon, 11 Aug 2014 11:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_zz3W6nTH37 for ; Mon, 11 Aug 2014 11:38:01 -0700 (PDT) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id 949541A0755 for ; Mon, 11 Aug 2014 11:38:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 235F994393; Mon, 11 Aug 2014 14:38:01 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (scale.ogcinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBaSbdJOmX_l; Mon, 11 Aug 2014 14:38:00 -0400 (EDT) Received: from mail2.standardsmail.org (mail2.standardsmail.org [66.244.86.41]) by mail.opengeospatial.org (Postfix) with ESMTP id 25BD09438D; Mon, 11 Aug 2014 14:38:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail2.standardsmail.org (Postfix) with ESMTP id 1B99FE52338; Mon, 11 Aug 2014 14:38:00 -0400 (EDT) Received: from mail2.standardsmail.org ([127.0.0.1]) by localhost (mail2.standardsmail.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id eBy5GX5zFiWV; Mon, 11 Aug 2014 14:37:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail2.standardsmail.org (Postfix) with ESMTP id 0CC8EE523B9; Mon, 11 Aug 2014 14:37:59 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.standardsmail.org Received: from mail2.standardsmail.org ([127.0.0.1]) by localhost (mail2.standardsmail.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gfZ-4qF5VSR3; Mon, 11 Aug 2014 14:37:58 -0400 (EDT) Received: from OfficeHP (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail2.standardsmail.org (Postfix) with ESMTPSA id 3886FE52338; Mon, 11 Aug 2014 14:37:58 -0400 (EDT) Message-ID: <6872947722F0496DB83E8DE3E35F568C@OfficeHP> From: "Carl Reed" To: "Alexandru Petrescu" , , "'Rex Buddenberg'" References: <7C75B9AA7E16464496CBA2BFCB5C8786@SRA4> <53DA3DD3.8080501@gmail.com> <53DA5468.2090405@gmail.com> <53DBAACD.2070101@gmail.com> <53E38BCE.9050704@gmail.com> <1407430716.3050.28.camel@localhost> <520DD834BE0E4DFF94AFE61EC46A484B@SRA4> <53E9099E.4090101@gmail.com> In-Reply-To: <53E9099E.4090101@gmail.com> Date: Mon, 11 Aug 2014 12:32:29 -0600 Organization: OGC MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/its/bN7UnEuG-zJ_mqU8CiFZWGG5C7I Cc: karagian@cs.utwente.nl, melinda.shore@gmail.com, lear@cisco.com, its@ietf.org, 'Dino Farinacci' Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 18:38:07 -0000 Alex - I would suggest checking out Dynamic Host Configuration Protocol Options for Coordinate-Based Location= =20 Configuration Information http://tools.ietf.org/html/rfc6225 May be very close to what this group is looking for in terms of a go forw= ard=20 "template" Cheers Carl -----Original Message-----=20 From: Alexandru Petrescu Sent: Monday, August 11, 2014 12:21 PM To: dickroy@alum.mit.edu ; 'Rex Buddenberg' Cc: 'Carl Reed' ; 'Dino Farinacci' ; karagian@cs.utwente.nl ;=20 melinda.shore@gmail.com ; its@ietf.org ; lear@cisco.com Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23rd=20 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. Alex Le 10/08/2014 06:21, Richard Roy a =E9crit : > All, > > Statistical confidence values are of limitd use in ITS applications. T= he > 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= =20 > are > parameterized by means and second central moments (and other higher ord= er > moments if the PDF is not Gaussian). Confidence values relate to how ma= ny > times one can expect the outcome of a realization of a particular rando= m > process/experiment to lie between a set of values (aka in a given regio= n=20 > of > support). That is, a 95% confidence interval gives the region of suppo= rt=20 > in > which it is expected that 9500 outcomes out of 10000 experiments will l= ie. > ITS apps only get one shot in general, and the info they need is the PD= F=20 > of > the estimated multivariate quantity. > > If, on the other hand, you are thinking of confidence anthropomorphical= ly=20 > as > in ... "well, I'm pretty confident that the values I'm giving you are=20 > 'good' > rather than 'bad'", this in not statistical "confidence". In fact, it'= s > useless information to any receiver that thinks rationally, not=20 > emotionally. > > > RR > >> -----Original Message----- >> From: Rex Buddenberg [mailto:buddenbergr@gmail.com] >> Sent: Thursday, August 07, 2014 9:59 AM >> To: Alexandru Petrescu >> Cc: dickroy@alum.mit.edu; 'Carl Reed'; 'Dino Farinacci'; >> karagian@cs.utwente.nl; melinda.shore@gmail.com; its@ietf.org; >> lear@cisco.com >> Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23= rd >> 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 =E9crit : >>>> All, >>>> >>>> See comments below ... >>>> >>>> Cheers, >>>> >>>> RR >>>>> -----Original Message----- >>>>> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >>>>> Sent: Friday, August 01, 2014 7:57 AM >>>>> To: Carl Reed; Dino Farinacci >>>>> Cc: dickroy@alum.mit.edu; melinda.shore@gmail.com; lear@cisco.com; >>>>> karagian@cs.utwente.nl; its@ietf.org >>>>> 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 =E9crit : >>>>>> 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 GeoS= MS >>>>>> (https://portal.opengeospatial.org/files/?artifact_id=3D44146) 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 Gaussi= an >> 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 GNS= S >>> system to the terminal computer, there is a need of a 'confidence' va= lue >>> 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 jus= t >>> _thinks_ to be there (i.e. HDOP=3D=3D1, really there with a 10centime= ter >>> precision, or HDOP=3D=3D5 meaning a sphere of radius of 100meter). >>> Otherwise other vehicles may send messages to that vehicle in the wro= ng >>> 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: dickroy@alum.mit.edu ; ; >> lear@cisco.com ; >>>>>> ; >>>>>> Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting o= n >> 23rd >>>>>> July at 20:30; IETF registration desk >>>>>> >>>>>> Le 31/07/2014 16:31, Dino Farinacci a =E9crit : >>>>>>> >>>>>>>> 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 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 >>>>>> its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its > > > From nobody Mon Aug 11 12:48:20 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454EA1A070D for ; Mon, 11 Aug 2014 12:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bex1dDMorP1r for ; Mon, 11 Aug 2014 12:48:17 -0700 (PDT) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id DFC6A1A071B for ; Mon, 11 Aug 2014 12:48:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 6F32694517; Mon, 11 Aug 2014 15:48:16 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (scale.ogcinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zE31IYg572tH; Mon, 11 Aug 2014 15:48:15 -0400 (EDT) Received: from mail2.standardsmail.org (mail2.standardsmail.org [66.244.86.41]) by mail.opengeospatial.org (Postfix) with ESMTP id 5991F94518; Mon, 11 Aug 2014 15:48:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail2.standardsmail.org (Postfix) with ESMTP id 4E73AE23F93; Mon, 11 Aug 2014 15:48:15 -0400 (EDT) Received: from mail2.standardsmail.org ([127.0.0.1]) by localhost (mail2.standardsmail.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id KEnGNA_Uqgf3; Mon, 11 Aug 2014 15:48:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail2.standardsmail.org (Postfix) with ESMTP id 43155E6A026; Mon, 11 Aug 2014 15:48:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.standardsmail.org Received: from mail2.standardsmail.org ([127.0.0.1]) by localhost (mail2.standardsmail.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FdamwXO0Jj6F; Mon, 11 Aug 2014 15:48:13 -0400 (EDT) Received: from OfficeHP (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail2.standardsmail.org (Postfix) with ESMTPSA id 70281E23F93; Mon, 11 Aug 2014 15:48:12 -0400 (EDT) Message-ID: <60332213CDF7472CB5FC385D91E9F473@OfficeHP> From: "Carl Reed" To: "Alexandru Petrescu" , "Rex Buddenberg" References: <7C75B9AA7E16464496CBA2BFCB5C8786@SRA4> <53DA3DD3.8080501@gmail.com> <53DA5468.2090405@gmail.com> <53DBAACD.2070101@gmail.com> <53E38BCE.9050704@gmail.com> <1407430716.3050.28.camel@localhost> <53E903D1.5000808@gmail.com> In-Reply-To: <53E903D1.5000808@gmail.com> Date: Mon, 11 Aug 2014 13:47:16 -0600 Organization: OGC MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/its/5dfB8HRBlfG7pHvVU1hPmwnc4Rg Cc: its@ietf.org, lear@cisco.com, melinda.shore@gmail.com, karagian@cs.utwente.nl, 'Dino Farinacci' , dickroy@alum.mit.edu Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 19:48:19 -0000 Alex et. al. WGS 84 is not a projection. WGS 84 is an Earth-centered, Earth-fixed=20 terrestrial reference system and geodetic datum (NGA). The expression and= =20 use of WGS 84 as a reference system is proscribed in how the coordinates = are=20 specified by the defining parameters. There are "flavors" for the definin= g=20 parameters, typically whether the WGS 84 coordinate is 2d or 3d. This is why the OGC and many other organizations use the EPSG CRS definit= ion=20 database as a normative reference for the defining parameter set for a WG= S=20 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=20 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=3Dselection&entity=3Durn:ogc= :def:crs:EPSG::4326&reportDetail=3Dlong&title=3DWGS%2084&style=3Durn:uuid= :report-style:default-with-code&style_name=3DOGP%20Default%20With%20Code As to the ubiquity of the use of WGS 84, this can be argued but from the = OGC=20 community perspective, WGS 84 is ubiquitous and should always be consider= ed=20 when modeling geographic information. The main issue is that programmers = or=20 systems ignore the CRS definition and create inconsistent representations= =20 that then inhibit interoperability and can actually cause life threatenin= g=20 situations. Alex - In dealing with the hydrology/water community and can state that t= he=20 majority (all?) hydrology/water sensor systems actual generate raw data=20 using WGS 84 lat/long coordinates. Subsequent processing transforms the r= aw=20 data from lat/long to some other CRS, such as State Plane in the US. This= is=20 because many GIS system users work in UTM or State Plane or some other=20 reference system. Cheers Carl -----Original Message-----=20 From: Alexandru Petrescu Sent: Monday, August 11, 2014 11:56 AM To: Rex Buddenberg Cc: dickroy@alum.mit.edu ; 'Carl Reed' ; 'Dino Farinacci' ;=20 karagian@cs.utwente.nl ; melinda.shore@gmail.com ; its@ietf.org ;=20 lear@cisco.com Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23rd=20 July at 20:30; IETF registration desk Le 07/08/2014 18:58, Rex Buddenberg a =C3=A9crit : > >> 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, 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. > > 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. 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 > > > On Thu, 2014-08-07 at 16:23 +0200, Alexandru Petrescu wrote: >> Le 01/08/2014 18:47, Richard Roy a =C3=A9crit : >>> All, >>> >>> See comments below ... >>> >>> Cheers, >>> >>> RR >>>> -----Original Message----- From: Alexandru Petrescu >>>> [mailto:alexandru.petrescu@gmail.com] Sent: Friday, August 01, >>>> 2014 7:57 AM To: Carl Reed; Dino Farinacci Cc: >>>> dickroy@alum.mit.edu; melinda.shore@gmail.com; lear@cisco.com; >>>> karagian@cs.utwente.nl; its@ietf.org 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 =C3=A9crit : >>>>> 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=3D44146) >>>>> 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=3D=3D1, really >> there with a 10centimeter precision, or HDOP=3D=3D5 meaning a sphere o= f >> 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: >>>>> dickroy@alum.mit.edu ; ; >>>>> lear@cisco.com ; ; >>>>> 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 =C3=A9crit : >>>>>> >>>>>>> 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 >>>>>> 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 its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>> >>> >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > > > From nobody Tue Aug 12 09:57:47 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8AA91A0360 for ; Tue, 12 Aug 2014 09:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34FaTX0EHkIp for ; Tue, 12 Aug 2014 09:57:31 -0700 (PDT) Received: from out68-ams.mf.surf.net (out68-ams.mf.surf.net [145.0.1.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F047A1A035C for ; Tue, 12 Aug 2014 09:57:30 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id s7CH0KLJ023368; Tue, 12 Aug 2014 19:00:20 +0200 Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 12 Aug 2014 18:57:23 +0200 Received: from EXMBX24.ad.utwente.nl ([169.254.4.146]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Tue, 12 Aug 2014 18:57:19 +0200 From: To: , , Thread-Topic: [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk Thread-Index: AQHPnZB4AVfSUsfRF06Y2IP/wtf3UZu3gpqAgAKfbYCAABlvgIAAAX0AgAAG44CAAZFHgIAAHr6AgAlFtwCAACttAIAD42OAgABGe9+AANdJ8IAC+bmX Date: Tue, 12 Aug 2014 16:57:17 +0000 Message-ID: References: <7C75B9AA7E16464496CBA2BFCB5C8786@SRA4> <53DA3DD3.8080501@gmail.com> <53DA5468.2090405@gmail.com> <53DBAACD.2070101@gmail.com> <53E38BCE.9050704@gmail.com> <1407430716.3050.28.camel@localhost>,<520DD834BE0E4DFF94AFE61EC46A484B@SRA4> , <41430947B62D449BA713C2B8021B5C57@SRA4> In-Reply-To: <41430947B62D449BA713C2B8021B5C57@SRA4> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.9.237] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Bayes-Prob: 0.5 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.49; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0bMBR0kFm - f810f0315499 - 20140812 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/its/7-YEdL8h2iRKV-VA2lopoNAXDkg Cc: lear@cisco.com, melinda.shore@gmail.com, its@ietf.org, farinacci@gmail.com Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 16:57:40 -0000 Hi Richard, Thanks for the explanation! Regarding the confidence interval definition, yes I agree with you.=20 95% of the experiments run will result in an estimate within the 95% confid= ence 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 [dickroy@alum.mit.edu] Verzonden: zondag 10 augustus 2014 21:28 Aan: Karagiannis, G. (EWI); buddenbergr@gmail.com; alexandru.petrescu@gmail= .com CC: creed@opengeospatial.org; farinacci@gmail.com; melinda.shore@gmail.com;= its@ietf.org; lear@cisco.com Onderwerp: RE: [geonet/its] Agenda for the GeoNet informal meeting on 23rd = July at 20:30; IETF registration desk > -----Original Message----- > From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] > Sent: Saturday, August 09, 2014 11:41 PM > To: dickroy@alum.mit.edu; buddenbergr@gmail.com; > alexandru.petrescu@gmail.com > Cc: creed@opengeospatial.org; farinacci@gmail.com; > melinda.shore@gmail.com; its@ietf.org; lear@cisco.com > Subject: RE: [geonet/its] Agenda for the GeoNet informal meeting on 23rd > July at 20:30; IETF registration desk > > 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 arr= e > 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 > 500 from the 10000 experiments might lie. [RR>] Actually it's 9500. That is, 95% of the experiments run will result in an estimate within the 95% confidence interval. RR > > Best regards, > Georgios > > > > > > ________________________________________ > Van: Richard Roy [dickroy@alum.mit.edu] > Verzonden: zondag 10 augustus 2014 6:21 > Aan: 'Rex Buddenberg'; 'Alexandru Petrescu' > CC: 'Carl Reed'; 'Dino Farinacci'; Karagiannis, G. (EWI); > melinda.shore@gmail.com; its@ietf.org; lear@cisco.com > Onderwerp: RE: [geonet/its] Agenda for the GeoNet informal meeting on 23r= d > 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 > > > -----Original Message----- > > From: Rex Buddenberg [mailto:buddenbergr@gmail.com] > > Sent: Thursday, August 07, 2014 9:59 AM > > To: Alexandru Petrescu > > Cc: dickroy@alum.mit.edu; 'Carl Reed'; 'Dino Farinacci'; > > karagian@cs.utwente.nl; melinda.shore@gmail.com; its@ietf.org; > > lear@cisco.com > > Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23r= d > > 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) i= n > > 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 =E9crit : > > > > All, > > > > > > > > See comments below ... > > > > > > > > Cheers, > > > > > > > > RR > > > >> -----Original Message----- > > > >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > > >> Sent: Friday, August 01, 2014 7:57 AM > > > >> To: Carl Reed; Dino Farinacci > > > >> Cc: dickroy@alum.mit.edu; melinda.shore@gmail.com; lear@cisco.com; > > > >> karagian@cs.utwente.nl; its@ietf.org > > > >> Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting o= n > > 23rd > > > >> July at 20:30; IETF registration desk > > > >> > > > >> Le 31/07/2014 17:01, Carl Reed a =E9crit : > > > >>> 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 coordinate= s > > is > > > >>> done in decimal degrees. While the format you show is perhaps nic= e > > 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=3D44146) 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 th= e > > > >> 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 estimate= d > > > > 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 limi= t > > > > 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 GNS= S > > > 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 jus= t > > > _thinks_ to be there (i.e. HDOP=3D=3D1, really there with a 10centime= ter > > > precision, or HDOP=3D=3D5 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: dickroy@alum.mit.edu ; ; > > lear@cisco.com ; > > > >>> ; > > > >>> 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 =E9crit : > > > >>>> > > > >>>>> 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 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 > > > >>> its@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/its > > > >>> > > > >>> > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > its mailing list > > > its@ietf.org > > > https://www.ietf.org/mailman/listinfo/its=3D= From nobody Mon Aug 25 06:41:55 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF681A8940 for ; Mon, 25 Aug 2014 06:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deUQfR4zuFqm for ; Mon, 25 Aug 2014 06:41:49 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A800A1A8947 for ; Mon, 25 Aug 2014 06:41:48 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s7PDfdTP026802; Mon, 25 Aug 2014 15:41:39 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C017C2087E4; Mon, 25 Aug 2014 15:41:39 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A7DA6208637; Mon, 25 Aug 2014 15:41:39 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s7PDfL8a029774; Mon, 25 Aug 2014 15:41:39 +0200 Message-ID: <53FB3D01.10902@gmail.com> Date: Mon, 25 Aug 2014 15:41:21 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Carl Reed , dickroy@alum.mit.edu, "'Rex Buddenberg'" References: <7C75B9AA7E16464496CBA2BFCB5C8786@SRA4> <53DA3DD3.8080501@gmail.com> <53DA5468.2090405@gmail.com> <53DBAACD.2070101@gmail.com> <53E38BCE.9050704@gmail.com> <1407430716.3050.28.camel@localhost> <520DD834BE0E4DFF94AFE61EC46A484B@SRA4> <53E9099E.4090101@gmail.com> <6872947722F0496DB83E8DE3E35F568C@OfficeHP> In-Reply-To: <6872947722F0496DB83E8DE3E35F568C@OfficeHP> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/8oLE5F8pLePWDqzbHCmDoqwZtTs Cc: karagian@cs.utwente.nl, melinda.shore@gmail.com, lear@cisco.com, its@ietf.org, 'Dino Farinacci' Subject: Re: [geonet/its] RFC6225 'DHCP options for Coordinate-based Location Configuration' (was: Agenda...) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 13:41:53 -0000 Le 11/08/2014 20:32, Carl Reed a écrit : > 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" 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: dickroy@alum.mit.edu ; 'Rex Buddenberg' > Cc: 'Carl Reed' ; 'Dino Farinacci' ; karagian@cs.utwente.nl ; > melinda.shore@gmail.com ; its@ietf.org ; lear@cisco.com 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. > > 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:buddenbergr@gmail.com] Sent: Thursday, August 07, 2014 >>> 9:59 AM To: Alexandru Petrescu Cc: dickroy@alum.mit.edu; 'Carl >>> Reed'; 'Dino Farinacci'; karagian@cs.utwente.nl; >>> melinda.shore@gmail.com; its@ietf.org; lear@cisco.com 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:alexandru.petrescu@gmail.com] Sent: Friday, August >>>>>> 01, 2014 7:57 AM To: Carl Reed; Dino Farinacci Cc: >>>>>> dickroy@alum.mit.edu; melinda.shore@gmail.com; >>>>>> lear@cisco.com; karagian@cs.utwente.nl; its@ietf.org >>>>>> 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: >>>>>>> dickroy@alum.mit.edu ; ; >>> lear@cisco.com ; >>>>>>> ; 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 >>>>>>>> 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 its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> >> > > From nobody Mon Aug 25 06:58:45 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7551A896A for ; Mon, 25 Aug 2014 06:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78zsxATB88Ln for ; Mon, 25 Aug 2014 06:58:34 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3A2F1A896C for ; Mon, 25 Aug 2014 06:58:33 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s7PDwN85007965; Mon, 25 Aug 2014 15:58:23 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6773820889E; Mon, 25 Aug 2014 15:58:23 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4EBC9208897; Mon, 25 Aug 2014 15:58:23 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s7PDw6gp018113; Mon, 25 Aug 2014 15:58:22 +0200 Message-ID: <53FB40EE.2000007@gmail.com> Date: Mon, 25 Aug 2014 15:58:06 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: dickroy@alum.mit.edu, "'Rex Buddenberg'" References: <7C75B9AA7E16464496CBA2BFCB5C8786@SRA4> <53DA3DD3.8080501@gmail.com> <53DA5468.2090405@gmail.com> <53DBAACD.2070101@gmail.com> <53E38BCE.9050704@gmail.com> <1407430716.3050.28.camel@localhost> <520DD834BE0E4DFF94AFE61EC46A484B@SRA4> <53E9099E.4090101@gmail.com> <5AD83A86E74B45CDBAB9F01C2978A49E@SRA4> In-Reply-To: <5AD83A86E74B45CDBAB9F01C2978A49E@SRA4> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/utl1IROWlfRcLAY34FUdKIR5zo0 Cc: lear@cisco.com, its@ietf.org, melinda.shore@gmail.com, karagian@cs.utwente.nl, 'Dino Farinacci' Subject: Re: [geonet/its] ways of representing 'confidence'(was: Agenda ...) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 13:58:42 -0000 Le 11/08/2014 21:15, Richard Roy a écrit : > > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Monday, August 11, 2014 >> 11:21 AM To: dickroy@alum.mit.edu; 'Rex Buddenberg' Cc: 'Carl >> Reed'; 'Dino Farinacci'; karagian@cs.utwente.nl; >> melinda.shore@gmail.com; its@ietf.org; lear@cisco.com 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:buddenbergr@gmail.com] Sent: Thursday, August 07, 2014 >>>> 9:59 AM To: Alexandru Petrescu Cc: dickroy@alum.mit.edu; 'Carl >>>> Reed'; 'Dino Farinacci'; karagian@cs.utwente.nl; >>>> melinda.shore@gmail.com; its@ietf.org; lear@cisco.com 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:alexandru.petrescu@gmail.com] Sent: Friday, >>>>>>> August 01, 2014 7:57 AM To: Carl Reed; Dino Farinacci Cc: >>>>>>> dickroy@alum.mit.edu; melinda.shore@gmail.com; >>>>>>> lear@cisco.com; karagian@cs.utwente.nl; its@ietf.org >>>>>>> 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: dickroy@alum.mit.edu ; >>>>>>>> ; >>>> lear@cisco.com ; >>>>>>>> ; 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 >>>>>>>>> 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 its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >>> >>> > > From nobody Wed Aug 27 04:05:35 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3071A0643 for ; Wed, 27 Aug 2014 04:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.226 X-Spam-Level: ** X-Spam-Status: No, score=2.226 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DecyaOhBiBXf for ; Wed, 27 Aug 2014 04:05:32 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id B5A681A0642 for ; Wed, 27 Aug 2014 04:05:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,409,1406584800"; d="scan'208";a="30056633" Received: from exc-cashub01.tsn.tno.nl (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 27 Aug 2014 13:05:30 +0200 Received: from EXC-MBX02.tsn.tno.nl ([fe80::5836:4645:c512:f964]) by EXC-CASHUB01.tsn.tno.nl ([fe80::b855:be6:1aa8:4d0f%13]) with mapi id 14.03.0195.001; Wed, 27 Aug 2014 13:05:29 +0200 From: "Wissingh, B.F. (Bastiaan)" To: "its@ietf.org" Thread-Topic: [geonet/its] Minutes Geonet side meeting IETF 90 Toronto Thread-Index: AQHPwebPQg7iKuqy9kqBO/NkOTODzw== Date: Wed, 27 Aug 2014 11:05:29 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [134.221.225.191] Content-ID: <01360F8BCCA0764B95D575B10B4F3652@tno.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/its/BK_FprrIzR3uAmuQWnQarXtPG00 Cc: "alexandru.petrescu@gmail.com" , "karagian@cs.utwente.nl" Subject: [geonet/its] Minutes Geonet side meeting IETF 90 Toronto X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 11:05:34 -0000 Hi all, As Georgios already mentioned in an earlier e-mail from 25th of July, we where in the process of gathering the minutes of the side meeting of the IETF 90 Toronto. Please find them below: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Minutes of the Geonet informal meeting on Wednesday 23 July at 20:30 Location: IETF registration desk; 5 people were present. Dino, Bastiaan, Ray Bellis, Victor Moreno and Georgios Karagiannis =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The discussion focused on the main issues seen by the people that were attending the meeting and on the next steps. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The following items have been discussed: Work in Geopriv done related to, =B3given this is my IP address, where am I?=B2 Just like a directory lookup. But such a deployment of a location server in each access network seems very far from happening today. There seems currently no demand for such a server within each access network except for emergency services use case. >From geolocation back to ip address is even more difficult. You should not make assumptions on the network connection that is being used (wired, wireless, etc.), it should be acrostic of the layer 2 connectivity. It seems like not all the use cases have the same paradime, can be solved with the same solution. What we are asking for needs to seem like it is somewhat solvable. Produce some diagrams explaining what theoretically might be possible to solve, to get insight in the steps that are missing. Flows of how information is flowing. Emergency broadcast example, let terminals in a certain area contact a broadcast emergency server an keep a connection open to receive data. Not the other way around that a broadcast emergency server needs to setup a connection with all nodes in a certain area. Use a multicast address to disseminate traffic. In GeoNet we would like to make a mapping between gateways that are responsible for a certain area and the IP address on which that gateway is reachable from the service provider. Such a mapping can be done with DNS, but it is far far from scalable. How do you trigger the joining to such dissemination channels, from the gateways. Protocols exist for, given my location, what is the right channel to join. Mapping from a geographical location back to lisp gateways seems like a problem. LISP example; mapping database distributed in a DNS like hierarchy for mapping location info to an IPv4, IPv6 or MAC address. These can be used as lookup keys. Why not a 2-tupel with geo-coordinates and radius to define physical location, use that as lookup key? How do they get into the database? These devices come up, know what there coordinates are, should all register with the same thing. How do we know that we have the same name or id. Is this expandable? Not sure how the lookup on the other side works=8A Lisp can be deployed in phases, no need to deploy all at once. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Way forward basically two options: There are two options on moving forward with the Geonet activity: =3D=3D Option 1: Try to create an IETF BOF/WG, by first modifying the following: =3D=3D 1) The scope is too large: Adjust the use-cases, align them more and make sure they all =B3require=B2 = the same solution, or have the same problem statement. E.g, the precise goods tracking use case seems very different from the other use cases. Narrow further the scope 2) show in detail how Geonet can be applied to one or more use cases, using message sequence diagrams, etc. 3) dissemination of packets within a geographical area should be layer 2 technology agnostic 4) show how geographical areas, including overlapping areas, can be possible mapped to IP addresses Ray Bellis mentioned that this is a very hard problem to solve and therefore it might be required to bring Geonet to IRTF and not IETF. =3D=3D Option 2: Try to go for a Researching Group instead of a Working Gro= up. =3D=3D Advantage is that the problem statement, use cases, etc. can be more vague as it is a research topic. Take it to Lars? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please provide your opinion on the proposed options on the way forward. Best regards, = B.F. (Bastiaan) Wissingh MSc TNO Netherlands Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de = wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verban= d houdt met risico's verbonden aan het elektronisch verzenden van berichten. = This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. From nobody Thu Aug 28 06:03:36 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C671A041D for ; Thu, 28 Aug 2014 06:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxUcrWjh2Vte for ; Thu, 28 Aug 2014 06:03:26 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE5F1A0421 for ; Thu, 28 Aug 2014 06:03:24 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s7SD3JYg021950; Thu, 28 Aug 2014 15:03:19 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DF59F20A8A9; Thu, 28 Aug 2014 15:03:23 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D0D2220A894; Thu, 28 Aug 2014 15:03:23 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s7SD32ql029482; Thu, 28 Aug 2014 15:03:19 +0200 Message-ID: <53FF2886.7030606@gmail.com> Date: Thu, 28 Aug 2014 15:03:02 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Wissingh, B.F. (Bastiaan)" , "its@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/vorOYkP33smO-O7pPL5f5qNpkE8 Cc: "karagian@cs.utwente.nl" Subject: Re: [geonet/its] Way forward (was: Minutes Geonet side meeting IETF 90 Toronto) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 13:03:34 -0000 Hi Bastiaan, Thank you for compiling the minutes, they are valuable reading for those who could not attend, including myself. In the message you are asking for feedback. Here is some feedback. Please comment. Le 27/08/2014 13:05, Wissingh, B.F. (Bastiaan) a écrit : [...] > Way forward basically two options: > There are two options on moving forward with the Geonet activity: > > == Option 1: Try to create an IETF BOF/WG, I agree with this option 1. > > by first modifying the > following: == > 1) The scope is too large: > Adjust the use-cases, align them more and make sure they all ³require² the > same solution, or have the same problem statement. E.g, the precise goods > tracking use case seems very different from the other use cases. > Narrow further the scope I agree about adjusting the use-cases. Currently there are 4 use-cases documented in draft-karagiannis-geonet-problem-statement-00: 1. Dissemination of IP packets to geographical areas 2. Precise tracking of package positions during a shipping process 3. Dissemination of ITS (Intelligent Transportation System) information to fixed and mobile RSUs via Internet 4. Tracking and communicating with people or objects located in certain geographical areas There are some immediately clear similarities but also discrepancies. For example, (1), (3) and (4) may use the same mechanism, although the mobile RSU part of (3) may be a bit different because the RSU is mobile. The (2) use-case - precise tracking - seems a bit more different from the others, although the use-case may read similar. The difference lies in the fact that it is the IP address of the end-node that is associated with the coordinates of the assumed-to-be-RSU, whereas in use-cases (1), (3) and (4) it is the IP address of the RSU itself which is associated with the coordinates. Given these aspects, I also think we need to refine the use-cases such as to stress the similarities and reduce the discrepancies. > 2) show in detail how Geonet can be applied to one or more use cases, > using message sequence diagrams, etc. I agree. A first message sequence diagram would be useful. Could you please draw a message exchange geonet/its? It should be something like this: RSU Vehicle's MR Client Server at lat/long/alt close to RSU | | | | | | | | |-------------->| | | | IP address of | | | | RSU at lat/lon| | | | /alt/prec? | | | |<--------------| | | | RSU-IP | | | | | | | |---------------------------------->| | | Message-to-RSU-IP | / | | | |-------/ | | | \"broadcast"all in area | | | \ > 3) dissemination of packets within a geographical area should be layer 2 > technology agnostic I agree. We should be careful with the words: - dissemination - broadcast - multicast because they could easily clash. Multicast can be "IP multicast", some-link-layer multicast (e.g. WiFi multicast). But can not be "radio multicast". Broadcast can be "IP broadcast, 255.255.255.255", sone-link-layer broadcast (e.g. ff:ff:ff:ff:ff:ff in WiFi) and can be "radio broadcast", or even "TV broadcast". Dissemination is ambiguous with respect to all. There is no such term as "IP dissemination", nor "some-link-layer dissemination". HEnce, we could be free to define it. We could say that geonet dissemination is a sequence of IP multicast packets which are radop-broadcasted in area no larger than 50 square kilometers. What do you think? > 4) show how geographical areas, including overlapping areas, can be > possible mapped to IP addresses > Ray Bellis mentioned that this is a very hard problem to solve and > therefore it might be required to bring Geonet to IRTF and not IETF. I fully agree. It is hard in the computational sense in that decisions of member appartenance to sets is NP-complete. > == Option 2: Try to go for a Researching Group instead of a Working Group. > == > Advantage is that the problem statement, use cases, etc. can be more vague > as it is a research topic. Take it to Lars? This option could be explored as well. What do you think? Alex [...] From nobody Thu Aug 28 06:17:49 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFD41A03F5 for ; Thu, 28 Aug 2014 06:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QS0b5mNlQOPT for ; Thu, 28 Aug 2014 06:17:44 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4BB61A03FA for ; Thu, 28 Aug 2014 06:17:43 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s7SDHSXx030799; Thu, 28 Aug 2014 15:17:28 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1FA8120A81C; Thu, 28 Aug 2014 15:17:33 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0714320A7FF; Thu, 28 Aug 2014 15:17:33 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s7SDHN8L007146; Thu, 28 Aug 2014 15:17:28 +0200 Message-ID: <53FF2BE3.3030609@gmail.com> Date: Thu, 28 Aug 2014 15:17:23 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Carl Reed , Rex Buddenberg References: <7C75B9AA7E16464496CBA2BFCB5C8786@SRA4> <53DA3DD3.8080501@gmail.com> <53DA5468.2090405@gmail.com> <53DBAACD.2070101@gmail.com> <53E38BCE.9050704@gmail.com> <1407430716.3050.28.camel@localhost> <53E903D1.5000808@gmail.com> <60332213CDF7472CB5FC385D91E9F473@OfficeHP> In-Reply-To: <60332213CDF7472CB5FC385D91E9F473@OfficeHP> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/ZEWzohpU17p3VbP2VC0bDA3QJ7w Cc: its@ietf.org, lear@cisco.com, melinda.shore@gmail.com, karagian@cs.utwente.nl, 'Dino Farinacci' , dickroy@alum.mit.edu Subject: Re: [geonet/its] WGS84 et alia (was: Agenda for the GeoNet informal meeting on 23rd July at 20:30; IETF registration desk) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 13:17:48 -0000 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 : > 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: dickroy@alum.mit.edu ; 'Carl Reed' ; 'Dino Farinacci' ; > karagian@cs.utwente.nl ; melinda.shore@gmail.com ; its@ietf.org ; > lear@cisco.com > Subject: Re: [geonet/its] Agenda for the GeoNet informal meeting on 23rd > July at 20:30; IETF registration desk > > Le 07/08/2014 18:58, Rex Buddenberg a écrit : >> >>> 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, > > 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. >> >> 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. > > 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 > >> >> >> 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:alexandru.petrescu@gmail.com] Sent: Friday, August 01, >>>>> 2014 7:57 AM To: Carl Reed; Dino Farinacci Cc: >>>>> dickroy@alum.mit.edu; melinda.shore@gmail.com; lear@cisco.com; >>>>> karagian@cs.utwente.nl; its@ietf.org 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: >>>>>> dickroy@alum.mit.edu ; ; >>>>>> lear@cisco.com ; ; >>>>>> 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 >>>>>>> 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 its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>> >>>> >>>> >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> >> >> > > >