On 06/30/2014 01:35 AM, Paul Norman wrote: > > 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? > > 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. > 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. Thanks for the clarifications. I agree that the default values are fine, especially regarding their use in deduplication. Because the API returns nodes with only 7 decimal places, would you recommend the use of --sigificant-digits=7 when the resulting OSM data is intended for updating existing data in OSM (using Replace Geometry in JOSM)? This way the coordinates downloaded from the API would match those from ogr2osm, and needlessly modifying the node coordinates with a higher precision could be prevented. Kind Regards, Bas _______________________________________________ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
