[Tile-serving] [openstreetmap/osm2pgsql] WIP: Add code to generalize polygons using two different strategies (PR #1830)

[Jochen Topf]

You are raising some valid points, @mboeringa. In fact the first version of the code in this PR would generate polygons that were all invalid! (The rings were not closed, which is fixed now.) I also added an optional  `ST_MakeValid()` step to the `raster-union` strategy which seems to work well in my experiments (use `-p make_valid` to enable) and seems to not take too much time. But overall I am not too worried about validity. The generalized data is not that accurate anyway, that's the whole point of generalization, and small rendering errors will probably not matter. Still, it is better to have things valid. We'll need some more real-world experience with this to see how important that is and whether it is worth the extra effort.

Unfortunately the potrace library will sometimes generate invalid polygons. I have seen two cases: Sometimes it snips off corners of the tiles it renders, this can be mitigated by having larger margins around tiles, but that's certainly something to look out for. The other happens when rendering polygons touching in single points (think of the figure "8") which must be modelled as two polygons, not one. There is another problem with the potrace library which I couldn't figure out yet: The left side of all polygons is slightly to the left of where it should be, the right side is okay. Maybe some kind of rounding error. You can't usually see it in the results though, because the effect is small, but still somewhat annoying.

You also mentioned the `num_seg_quarter_circle` setting and the need for simplification. I have played around with this in a different context, but didn't do that in this project. Using fewer segments for the buffer makes processing noticably faster, so that is an important optimization, but I am focusing on the new raster-based approach which is even faster and it generates far smaller polygons (with less vertexes) to begin with, so I believe there is no need for the extra simplification step. But it would be interesting to try this out. There is a huge experimental space here and I fully expect that we'll tweak code and parameters for a long time to come to better results. Anybody who wants to play around with this, please go ahead and report your findings here.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/osm2pgsql/pull/1830#issuecomment-1336935012
You are receiving this because you are subscribed to this thread.

Message ID: <openstreetmap/osm2pgsql/pull/1830/c1336935012 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tile-serving/attachments/20221205/678e02ed/attachment.htm>