1

I have my geodata layers processed in GRASS GIS. Its internal tools report that the topology has no problems, such as self- and mutual intersections.

Then I export the data to a GML file which then is converted to an OSM XML format, the last step preserving all coordinates intact. This OSM file is then opened in JOSM and validated, at which point quite a lot of self-intersections, duplicate nodes etc are found.

It was very confusing for me to understand where these problems come from until I noticed that they happen mostly on vertical (north-south) or horizontal segments of polygons.

Upon closer inspection I noticed that GRASS operates with floating point coordinates having 11 digits after the dot, and the GML and OSM files have 11 digits. The JOSM editor then shows only 7 digits after the dot in UI. Data exports from the existing OSM database has 7 digits. However if I re-save my own OSM file opened in JOSM as a new OSM file it retains 11 digits.

Can this reduction of precision lead to the types of topology problems I observe? If so, what is the best approach to avoid/fix them?

I can use GRASS to discover/fix topology problems, but native OSM tools/editors cannot do that, so my best bet is to somehow tell GRASS to use reduced precision.

1
  • Could you post a screenshot of what you see in the JOSM validator? Or better yet, share a sample of the data? I often run into a similar problem with JOSM, and seems to have more to do with the file conversion being imperfect than any precision issues.
    – JoshC
    May 14 '19 at 11:30
1

So far the only solution I could think of is to do the following sequence:

  1. v.out.ogr to export data from GRASS with 11 digits resolution to an GML file
  2. Process that GML file with a simple custom script that rounds all coordinates to 7 digits after the dot
  3. v.in.ogr to get the new rounded data into GRASS
  4. v.clean to snap, break, remove duplicate nodes, small areas, angles.
  5. v.out.ogr to export data out to a new GML
  6. Convert the final GML into OSM

After this long sequence JOSM validation tools find considerably fewer errors/varnings caused by intersections. So far I only tested it on smaller layers from my data set, but it looks promising to me.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.