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.
_______________________________________________
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
