[OSM-dev] ogr2osm coordinate precision

[Paul Norman]

On 2014-06-29 2:24 PM, Sebastiaan Couwenberg wrote:
> Currently ogr2osm outputs OSM node element using 9 decimal places for
> lat/lon coordinates, shouldn't it use 7 decimal places instead to match
> the documentation?
>
> http://wiki.openstreetmap.org/wiki/Node#Structure

OSM nodes in general have no limit on precision. Nodes stored in the API 
do. Editors will generally need higher precision to avoid accumulated 
errors with geometry manipulation operations.

> ogr2osm uses the --sigificant-digits and --rounding-digits options to
> set the precision, and uses the default values of 9 and 7 respectively.
>
> https://github.com/pnorman/ogr2osm/blob/master/ogr2osm.py#L113
>
> ogr2osm uses the --sigificant-digits value for the precision in the
> output. Should it use the --rounding-digits value or even a separate
> variable specifically for the output?
The significant digits is essentially only used for the output. The 
internal storage uses an integer multipled by 10**significant, but that 
actually cancels out with 
https://github.com/pnorman/ogr2osm/blob/master/ogr2osm.py#L499-L500

Rounding digits is used for deduplicating nodes, and should always be <= 
significant digits. The reason for this is that many data sources come 
with errors where coordinates are *supposed* to be the same in two 
linestrings, but aren't, so they don't always get correctly merged. NHD 
is one source where this is particularly bad. Decreasing 
--rounding-digits to 5 or so may help with NHD (see the Hoover Dam for a 
good test).

As the deduplication takes place deep in the internals in a tight loop 
and is one of the longest parts of converting file, it running fast is 
important, so complicated radius calculations are out.

With most data sources, the default values are fine.