
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>

<p>On 2020-02-12 23:34, Martin Koppenhoefer wrote:</p>

<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"><br /><br /> sent from a phone<br /><br />Il giorno 12 feb 2020, alle ore 14:06, Colin Smale <<a href="mailto:colin.smale@xs4all.nl">colin.smale@xs4all.nl</a>> ha scritto:<br /><br /> Exactly this. A hobbyist or volunteer CAN verify an admin boundary (where it is available as open data) - it is independently verifiable. It is objectively of better quality than an OTG observation with a phone.<br /><br /> this will obviously depend on the individual case, but in some instances in Europe I have seen the published open data boundaries were simplified geometries. Just because the original datum was precisely acquired doesn't necessarily imply that the published open data (often derivative data) is super accurate as well (our own errors in the transformation of the data during the import aside).<br /><br /></div>

</blockquote>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Good point about the simplification. If they do that by Douglas Peuker then no points will be moved, but some points can be deleted. So any points that make it through to the simplified data are accurate and actually appear in the input. If the boundary, road or whatever is actually curved, then we can subjectively improve on the published data by inserting additional points, but we should use the accurate points as a frame of reference and *leave them alone*. They are most likely to be the very best data we can get our hands on, even if they are not 100%.</div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Concerning data quality and its definition:</div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Locations are stored in OSM as pairs of {lat,lon} and I assume these are both 64-bit floats in the database. Any processing that we do on any location should be done so as to minimise the error, so the transformation parameters should be as accurate as possible and all operations should be done at maximum precision - 64-bit floats ("double precision" for the old guard) or, even better, 128-bit. When processing this kind of data you need to be aware of these things, and principles like these should also be considered "best practices". Results from higher-precision inputs using higher-precision operations can be considered to be *of a higher quality* than when a lower precision is used. And when we "export" the data by translating the binary representation to text (including XML), that should also be at a sufficiently high precision, such that re-importing the data would lead to the same binary representation. Every time data is loaded into an editor, it is translated to a string, and when it is stored, it translated back. This process must not lead to a loss of data precision!</div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

</body></html>