[OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

Colin Smale colin.smale at xs4all.nl
Wed Feb 12 23:05:10 UTC 2020


On 2020-02-12 23:34, Martin Koppenhoefer wrote:

> sent from a phone
> 
> Il giorno 12 feb 2020, alle ore 14:06, Colin Smale <colin.smale at xs4all.nl> ha scritto:
> 
> 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.
> 
> 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).

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

Concerning data quality and its definition: 
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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20200213/272d3f00/attachment.htm>


More information about the talk mailing list