onthegomap / planetiler

Flexible tool to build planet-scale vector tilesets from OpenStreetMap data fast
Apache License 2.0
1.44k stars 115 forks source link

[BUG] --simplify-tolerance-at-max-zoom=0 still does some simplification #1092

Closed davecraig closed 1 week ago

davecraig commented 1 week ago

We use the --simplify-tolerance-at-max-zoom=0 option with the aim of preserving intersections at the maximum zoom level. However, we have noticed that it doesn't always work. The node I'm focussed on is https://www.openstreetmap.org/node/8869599302#map=19/55.941903/-4.316366 and when we run planetiler it's being dropped from Station Road.

I'm building a map for Scotland (obviously if I was a little more expert I could narrow this down!):

java -Xmx20g -jar planetiler-dist-0.8.3-SNAPSHOT-with-deps.jar --force --download --area=scotland --fetch-wikidata --output=scotland.pmtiles --nodemap-type=array --storage=mmap --maxzoom=15 --render_maxzoom=15 --simplify-tolerance-at-max-zoom=0

At zoom level 15 for tile 15991,10213 I would expect there to be 7 nodes remaining in the line representing Station Road, but instead there are only 6. The one that has been dropped is the intersection. Running tileserver-gl-light to inspect the results and zooming right in the gap is almost imperceptible, but there definitely is one.

If I alter DouglasPeuckerSimplifier so that it skips processing if the distanceTolerance is 0 or less:

  public static Geometry simplify(Geometry geom, double distanceTolerance) {
    if (geom.isEmpty() || (distanceTolerance <= 0.0)) {
      return geom.copy();
    }

    return (new DPTransformer(distanceTolerance)).transform(geom);
  }

then the output file changes, growing from 519230972 to 519316026 bytes. This suggests that there are a lot of other simplifications going on elsewhere in the map despite the expectation that simplification is turned off. On the upside this change also means that a value of --simplify-tolerance-at-max-zoom=-1 also now works - previously the value was being squared before being used which negated its effect.

I'll make a PR with this change. However, it obviously doesn't address the underlying issue which I presume is precision related in some way. (Apologies for not delving further, but I haven't yet figured out the best way to run a debugger on the code to look more closely as I'm really a C++ embedded linux developer and Maven is still a bit mysterious to me).

Many Thanks.

davecraig commented 1 week ago

There was a mis-understanding by me of what a simplify-tolerance-at-max-zoom of 0.0 meant. That still allows simplification of a line if a node is exactly on the line with 0.0 error. What I really want is to be able to specify a negative tolerance, which currently doesn't work. I'll just submit a PR for that instrea,