Add some smoothing to the roads

[kocio-pl]

On lower zoom levels there can be artifacts on some roads (especially in mountains), we could use line smoothing.

Example of bad rendering:

https://www.openstreetmap.org/#map=12/33.5872/75.4889

[kocio-pl]

Would anybody like to try a bit? This should be similar to #3103 - very simple code, mostly testing different settings.

[polarbearing]

And the effects of overdoing it can be studied here #3499 ;-)

[Adamant36]

Id imagine it wouldn't be as much of an issue at that zoom level. Since exact geometry isn't as important at that point. Plus, I don't think its exact without smoothing anyway.

[matthijsmelissen]

@kocio-pl Which artefacts (in the image) are you referring to exactly?

[kocio-pl]

I mean they look like strange areas, while there are no areas there, just lines.

[vholten]

These areas are caused by overlapping hairpin turns. Smoothing is not going to help here, because smoothing adds nodes to change straight lines into curves, so the hairpin turns will still overlap.

I have tried the setting line-smooth: 1 anyway and at zoom level 12, the effect of smoothing is indeed not visible. At high zoom, it looks like this:

Before:

With line-smooth: 1

The only thing I can think of that would help is line simplification, but low simplification settings don't remove the areas of overlap, and high simplification settings would change road shapes too much from reality.

Example with
line-simplify: 5; line-simplify-algorithm: visvalingam-whyatt;

line-simplify: 50; line-simplify-algorithm: visvalingam-whyatt;

[kocio-pl]

It does not look good, indeed. Thanks for testing, however!

[matthijsmelissen]

What about line simplification followed by smoothing? :)

[mboeringa]

@vholten , what is actually happening in the "line-simplify: 50" example image? Is the Visvalingam-Whyatt algorithm causing self intersections of the lines? I refer to the "triangles" visible in what is only a single line element, not a dual carriage highway.

I am just trying to wrap my head around what causes these particular artifacts...

[matthijsmelissen]

The highway is part of a type=route relation. Could it be that osm2pgsql imports the type=route as a road somehow? That would explain the double rendering. @pnorman ?

[pnorman]

Route relations are imported, but should have no tags that cause them to render.

https://www.openstreetmap.org/relation/3239209 had a tagging error because it had a relation with a highway tag (see #302, #1980)

I do not believe there is a combination of smoothing and simplification that will get acceptable results that are worth the tradeoff of the geometry no longer being identical to the one in OSM data, particularly on examples like the one here. I believe this is true on low-zoom too. I believe the affect will either be unnoticeable or too distorting. If someone can show otherwise, I'd welcome it, since I could use it for my own styles.

This is different than with boundaries which had a dashed line, so very subtle smoothing can have a big improvement on dash pattern placement.

[kocio-pl]

Thanks for checking, I will therefore close it. If anybody will have a better idea to try and discuss, it can be easily reopened.

[matthijsmelissen]

https://www.openstreetmap.org/relation/3239209 had a tagging error

Thanks for catching. So that's what causing the triangles.

If someone can show otherwise, I'd welcome it, since I could use it for my own styles.

@pnorman I agree with your analysis. The problem is that all line-simplify algorithms that are built into Mapnik operate on the nodes that exist in OSM data, and these nodes can be unevenly spaced. This means that the effects of line simplification are much stronger on roads where the points are far apart, than on roads (such as the road above) where the nodes are close together. This makes the existing line simplification in Mapnik basically useless when applied to OSM data. A line simplification in Mapnik that works independently of the node density would be great improvement.

[matthijsmelissen]

@vholten Just out of curiosity, could you regenerate the images with the data fixed? And perhaps with smoothening applied after simplification?

[matthijsmelissen]

I have created an upstream issue: mapnik/mapnik#4019

I think this is an important issue, not also for roads but also for low zoom borders, rivers etc. If anybody reading along here would be willing to contribute in the Mapnik topic, that would be very helpful.

[jeisenbe]

True, it could be especially helpful for intermittent rivers, since they use a dashed line.

…

On Tue, Jan 8, 2019 at 8:03 PM Matthijs Melissen ***@***.***> wrote: I have created an upstream issue: mapnik/mapnik#4019 <mapnik/mapnik#4019> I think this is an important issue, not also for roads but also for low zoom borders, rivers etc. If anybody reading along here would be willing to contribute in the Mapnik topic, that would be very helpful. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3551 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AoxshCd2eci92K0VQIPUyvycrEcg9lI7ks5vBHsSgaJpZM4ZHHhZ> .

[vholten]

I am following this interesting discussion, but I don't have time right now to run further tests.

[mboeringa]

What about line simplification followed by smoothing? :)

One big warning to applying smoothing to lines in a road network:

While this may seem harmless, there is a major issue with how PostGIS implements it: every line element / database record is treated on its own, without regard for possible connectivity between line elements in a road network. While this yields extremely fast and performant results, it can lead to visual and unwanted break-ups in the road network. See the attached images that used a combination of generalization using the PostGIS ST_SimplifyVW SQL function followed by smoothing using the PostGIS ST_ChaikinSmoothing.

The left image is without any generalization and smoothing, the right with. Notice the loss of road network connectivity in the red circle due to the smoothing "cutting corners". This issue is likely mainly caused by road line elements not split up at junctions, hence the junction not being an end node of all road line elements entering the junction. In OpenStreetMap, there is nothing from preventing you to create such a junction, there are probably many of them.

I think this issue may also, although less likely, happen with simplification alone, when the crucial junction node is dropped during simplification. This is less likely to happen with generalization though, as the line element, if it continues beyond the junction, is likely to make a sharp turn (or go straight ahead), meaning the node will be a vital "shape" node, not easily dropped in generalization.

I think there is no real solution to this issue, unless defining a PostGIS Topology, which is likely a very costly operation on a database the size of OpenStreetMap...

[mboeringa]

@pnorman ,

My last observation in the previous post raises an interesting theoretical question:

Could osm2pgsql theoretically be enhanced with a command line option to automatically cut a line element in two and create two separate database records with the same tags, if the (junction) node is not an end node of a specific road or railway way element, but the node is shared with another highway/railway element and thus a true junction?

The modified, cut up way elements in separate database records, could then likely safely be generalized / smoothed, as now all end nodes would be at junctions?... So no break-ups of the network would occur??

I have no real idea, but I could see this as a potentially much simpler, and maybe with more performance, alternative option to building something like a PostGIS Topology. After all, during processing in something like osm2pgsql, the memberships of nodes in ways is already known, instead of derived afterwards by building a topology.

[mboeringa]

Besides highways/railways, ways tagged with waterway=x could benefit from this to. Potentially also barrier=x, although I think this is less of a concern as being an element mostly rendered at high zoom and thus not really needing generalization or smoothing.

[mboeringa]

To help explain the issue I suspect is happening with smoothing, this is what I think happens:

This is why I also made the possible suggestion about osm2pgsql. If osm2pgsql could cut the red line in two at the black junction node, and store the result in two separate database records, this issue would likely not happen.

[matthijsmelissen]

Real life example of that:

https://www.openstreetmap.org/?mlat=49.60155&mlon=6.12065#map=19/49.60155/6.12065&layers=CN

[kocio-pl]

This might be important also for rivers, barriers and other objects, since they all can have junctions too.

[mboeringa]

This might be important also for rivers, barriers and other objects, since they all can have junctions too.

Yes, but only if they are being generalized. As I also wrote here #3551 (comment), barriers are likely not an issue, since they are generally only rendered at high zoom, and thus don't need generalization. Waterways is a suitable candidate though, since they are also rendered across a large scale range.

[pnorman]

This is why I also made the possible suggestion about osm2pgsql. If osm2pgsql could cut the red line in two at the black junction node, and store the result in two separate database records, this issue would likely not happen.

That isn't really possible without a post-processing topology inspection. Say the red line comes first in the planet file, it would be impossible to insert it into the tables until everything was processed.

It would also substantially worsen label placement because ways would be much shorter on average.

I'd stick this idea in the class that of ideas that is interesting, but inherently extremely difficult to implement.

[kocio-pl]

In case anyone is interested - there is a PR implementing adaptive smooth algorithm in Mapnik:

mapnik/mapnik#4031