Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT)
Christian Hopps <chopps@chopps.org> Sat, 17 July 2021 23:17 UTC
Return-Path: <chopps@chopps.org>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881A53A265D; Sat, 17 Jul 2021 16:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 zC2cOG4z_g0g; Sat, 17 Jul 2021 16:17:12 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id B6B803A265C; Sat, 17 Jul 2021 16:17:11 -0700 (PDT)
Received: from smtpclient.apple (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 8AFCE803DF; Sat, 17 Jul 2021 23:17:10 +0000 (UTC)
From: Christian Hopps <chopps@chopps.org>
Message-Id: <C86851A1-66E3-44CA-A7BB-1ECD7E5AD59D@chopps.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CF5B26B2-E070-40A3-863C-C212257F49D1"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Sat, 17 Jul 2021 19:17:09 -0400
In-Reply-To: <20210717221418.GF74365@kduck.mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-netmod-geo-location@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, kent+ietf@watsen.net
To: Benjamin Kaduk <kaduk@mit.edu>
References: <162146723152.27764.1299479086437558158@ietfa.amsl.com> <m2fsy9cdhl.fsf@ja.int.chopps.org> <20210717173321.GE74365@kduck.mit.edu> <m2h7gssrqq.fsf@ja.int.chopps.org> <20210717221418.GF74365@kduck.mit.edu>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/TXAHwKPj6Mui3F9CaUWjihLSHnw>
Subject: Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Jul 2021 23:17:17 -0000
> On Jul 17, 2021, at 6:14 PM, Benjamin Kaduk <kaduk@mit.edu> wrote: > > On Sat, Jul 17, 2021 at 02:38:55PM -0400, Christian Hopps wrote: >> >> Benjamin Kaduk <kaduk@mit.edu> writes: >> >>> Hi Christian, >>> >>> Sorry for the very delayed reply (and thanks to Rob for the nudge). >>> >>> On Wed, May 26, 2021 at 06:04:58PM -0400, Christian Hopps wrote: >>>> >>>> Benjamin Kaduk via Datatracker <noreply@ietf.org> writes: >>>> >>>>> Benjamin Kaduk has entered the following ballot position for >>>>> draft-ietf-netmod-geo-location-08: Discuss >>>>> >>>>> When responding, please keep the subject line intact and reply to all >>>>> email addresses included in the To and CC lines. (Feel free to cut this >>>>> introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/ >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> I think we lack sufficient precision (forgive the pun) in how we talk >>>>> about "accuracy" and "precision". Are the leafs that claim to specify >>>>> "accuracy" specifying a precision? If so, the precision of a specific >>>>> measurement, the precision of the measurements that led to the creation >>>>> of the coordinate frame, or something else? Are they doing so in >>>>> relative terms (e.g., percentage) or absolute terms (e.g., degrees and >>>>> meters)? (There are "units" directives only for "height-accuracy" and >>>>> not the others.) How can we we say that we'll have 16 fraction-digits of >>>>> precision for lat/long when the maximum accuracy we can say that a >>>>> geodetic-system has only gives us 6 fraction-digits for coord-accuracy? >>>>> When we say that the "precision of this measurement is indicated by the >>>>> reference-frame" is that the same thing as the relevant "-accuracy" >>>>> nodes, or something else? >>>> >>>> Yes, the geodesic-datum is what defines the values and their accuracy. For the >>>> precision in the value we choose the fractional digits based on what might be >>>> needed, but not to prescribe anything. For decimal degrees e.g., we only need >>>> 100s values the rest can be left to the fractional portion. >>> >>> Unfortunately, even your description here still doesn't help me understand >>> what the intended semantics of these values are. >>> >>> To help illustrate my confusion, here are a few possible things that could >>> be what is intended to be conveyed: >>> >>> - the geodetic-datum description of the object has been measured to be >>> within a known delta of the actual object being described, at all points >>> on the object that the coordinate system can describe >>> >>> - the geodetic-datum description of the object is capable of determining >>> relative differences between points on the object to within a particular >>> delta of precision, but those individual coordinate values may be farther >>> than that delta from the actual point on the object that was referred to >>> >>> - the values that are reported in this YANG module reflect measurements >>> that were made and are known to be within some delta of the coordinate >>> system's value that they are reported as >>> >>> - the values that are reported in this YANG module reflect measurements >>> thare are known to be distinguishable from other measurements to within >>> some delta of other measurements relative to that coordinate system, even >>> though the actual position being indicated may diverge from the reported >>> value by more than that delta >>> >>> - the values that are reported in this YANG module reflect measurements >>> that were made and are known to be within some delta of the actual point >>> on the object that the coordinates refer to >>> >>> - the values that are reported in this YANG module reflect measurements >>> that were and are known to be distinguishable from other measurements of >>> points on that object within some delta, but the actual distance from the >>> measured point to the point on the object indicated by the reported >>> coordinates may be larger than that delta >>> >>> In short, there are at least three classes of things at play here: the >>> actual object itself, the coordinate system used to model the object, and >>> values reported in the YANG module (which are assumed to ultimately derive >>> from some form of measurement). To talk about accuracy or precision >>> implies a relationship between elements of two of those classes, and I >>> don't even know which of those classes you're trying to talk about. >> >> Let's start with a simple baseline, if you want to dig any deeper than the well understood Lat+Long; do you know what a geodetic datum is? This is required knowledge if you want to get into anything more than the obvious Lat+Long use of this grouping. It defines the coordinates and also the accuracy of measurements. > > Well, I thought I did, but the fact that you are asking me makes me less > sure that I actually do. > > Limiting just to the Earth for simplicity of discussion, it is "well known" > that the earth is not a perfect sphere; it's not even a regular ellipsoid. > Even discounting local topography on the surface, "mean sea level" varies > due to the differing internal density, angular momentum, and myriad other > factors. So if we want to talk about coordinates of a point on the earth, > we have to build a model of the earth in which we define what our > coordinates mean. We'll have to anchor our coordinate system to actual > points on the earth in some way, whether by defining an arbitrary origin at > a physical object, using the center of mass (which can at least in theory > be measured to very high precision), or some combination thereof. But the > coordinate system remains a model of the actual earth, and there will be > some skew between them for points that in an ideal coordinate system would > match up exactly with the physical object. > > The coordinate system will have inherent accuracy limits based on how much > skew there is between the idealized points in the coordinate system and the > actual points on earth they're supposed to represent. When one makes a > measurement with respect to a given coordinate system there may also be > inherent limits to the precision of measurement that can be made with > respect to the coordinate system, e.g., if the coordinate system is defined > with respect to GPS points, the limits of GPS resolution are a bound on how > precisely one can make a measurement. > > That's all well and good, but what I describe above is a property of the > coordinate system itself, not a property of individual measurements made > with reference to that coordinate system. The YANG grouping we define here > allows overriding the coord-accuracy and height-accuracy on a > per-grouping-instantiation basis, i.e., for a single list of coordinates. > But those coordinates in the instantiation are certainly sometimes going to > be derived from measurements, and I expect that measurements will be the > overwhelming majority of usage. Measurements, however, *also* have > accuracy and precision, but this time with respect to the coordinate system > they are being measured in. Instrumental error and other factors can > introduce a systemtic bias in the measured values, leading to bad accuracy, > even if the precision of the group of measurements remains quite good, so > that relative comparisons within the dataset are reliable even if the > absolute numers are not reliable with respect to the coordinate system. > > So, when we refine the coord-accuracy and height-accuracy for an > instantiation of the grouping, what does that mean? It’s supposed to mean the accuracy of the measurement that is recorded in the grouping. So if the coord-accuracy is .1 and the measurement is lat/long then the accuracy is within 1/10 of a decimal degree. if the measurement is in cart coordinates the accuracy would be 100cm. I don’t think we need to make this anymore complex than that. Is there some text you would like to see to make that clearer? Thanks, Chris. > > >> It is out way out of scope for this YANG grouping to try and explain the huge field of geographic locations and geodetic datum and systems. > > Of course. But we should have enough of a reference so that people can > have a way to read up and understand what the fields we are defining > actually mean. > > -Ben
- [netmod] Benjamin Kaduk's Discuss on draft-ietf-n… Benjamin Kaduk via Datatracker
- Re: [netmod] Benjamin Kaduk's Discuss on draft-ie… Christian Hopps
- Re: [netmod] Benjamin Kaduk's Discuss on draft-ie… Christian Hopps
- Re: [netmod] Benjamin Kaduk's Discuss on draft-ie… Rob Wilton (rwilton)
- Re: [netmod] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [netmod] Benjamin Kaduk's Discuss on draft-ie… Christian Hopps
- Re: [netmod] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [netmod] Benjamin Kaduk's Discuss on draft-ie… Christian Hopps
- Re: [netmod] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [netmod] Benjamin Kaduk's Discuss on draft-ie… Christian Hopps
- Re: [netmod] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk