IETF Logo Mail Archive

Re: [Geopriv] Progressing the draft draft-thomson-geopriv-confidence-03

Henning Schulzrinne <hgs@cs.columbia.edu> Wed, 31 July 2013 13:32 UTC

Return-Path: <hgs@cs.columbia.edu>
X-Original-To: geopriv@ietfa.amsl.com
Delivered-To: geopriv@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9032421F9E99 for <geopriv@ietfa.amsl.com>; Wed, 31 Jul 2013 06:32:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aN9DKNnwpWf7 for <geopriv@ietfa.amsl.com>; Wed, 31 Jul 2013 06:32:39 -0700 (PDT)
Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id B44B121F979E for <geopriv@ietf.org>; Wed, 31 Jul 2013 06:32:39 -0700 (PDT)
Received: from dhcp-431d.meeting.ietf.org (dhcp-431d.meeting.ietf.org [130.129.67.29]) (user=hgs10 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r6VDWa0g015913 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 31 Jul 2013 09:32:37 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Henning Schulzrinne <hgs@cs.columbia.edu>
In-Reply-To: <CABkgnnUC57BuOGYesnkxxpMwsYjFAoFfMQ8xe=uYTpSsS1UESA@mail.gmail.com>
Date: Wed, 31 Jul 2013 09:32:40 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <7273FCC2-82ED-48DD-8FBF-E8D8A8085244@cs.columbia.edu>
References: <CACWXZj3kKwXTx85NLWMcum-21foHcESNKaiYSUELNfwM8UP5Vg@mail.gmail.com> <CABkgnnXGT5jaGrMaA_6+DEJW2Nq3VVFALFH3HC6aoQFhJWrX9Q@mail.gmail.com> <CAOPrzE2dFNocXg_1OY1_rq0ZRznsMBzLKpviLphUOmfgtXBCNQ@mail.gmail.com> <CABkgnnWs-XzzX6gh5J3NUfFBYvAVbr-F7+UmM_az3tZipy0qhw@mail.gmail.com> <CAOPrzE24CXRAfJtNtekLcbR7RiGqDjqAMvt7ftYR9=r8mBvomg@mail.gmail.com> <CABkgnnU+jcVx6=+i=OuA8=8U32HYpr92tJDXNPjXDhYBua1CDw@mail.gmail.com> <F58BBB12-65FC-44B8-AB8B-DB5FCB7B2F7B@cs.columbia.edu> <CABkgnnVu4mB0956+QRcgJCRCMWsFCYUq2zwR-Xu2BpRDnfZeUA@mail.gmail.com> <CABkgnnUC57BuOGYesnkxxpMwsYjFAoFfMQ8xe=uYTpSsS1UESA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.1508)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5
Cc: GEOPRIV WG <geopriv@ietf.org>
Subject: Re: [Geopriv] Progressing the draft draft-thomson-geopriv-confidence-03
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/geopriv>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jul 2013 13:32:48 -0000

But can you capture these provisioning problems in any kind of confidence indication? If an error occurs that places a Berlin base station in Orlando (e.g., due to a typo in the long/lat data), the notion of a confidence ring doesn't make a whole lot of sense. (Yes, the example is based on what somebody mentioned regarding where his iPhone thought he was.)

On Jul 31, 2013, at 9:25 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

>> On 31 July 2013 15:06, Henning Schulzrinne <hgs@cs.columbia.edu> wrote:
>>> I'm assuming that's because errors do not have an approximately normal (Gaussian) distribution for some or all location determination methods?
>> 
>> In part.  Gaussian distributions are actually becoming the exception
>> rather than the rule.
>> 
>> Also, it's possible that provisioning errors contribute a greater than
>> 5% reduction in confidence.  Getting good databases is a really hard
>> operational problem.
> 
> I should expand on that.  A lot of location determination relies on
> having good databases of reference locations, for example cell sites.
> Network operators spend a lot of time and effort on maintaining these
> databases, but errors do inevitably occur.
>

v2.23.0 | Report a Bug | By Email