That was added by someone who loved importing stuff, but had much lower enthusiasm toward data quality, discussing their imports or even automating imports properly.
Other extreme was a regular house mapped with polygon that had 1500 nodes (in this case it was relatively obvious that it was result of automated tracing of raster map).
This was not just me that did this. It was/is a joined effort of some mappers from the Dutch community (and feel free to join us 
). All my changesets in which I combine ways have a reference to that topic in the Dutch forum. My last changeset(s) were based on pairs of which I think might be combined in a (semi) automatic way.
Progress and categories of potential combinations can be seen in map I linked in my first post. In the top right corner you can expand so you see layers you can select.
The pairs I had in mind for (semi) automatic are not shown there because these are a subset of Category1 (Cat1). (=the least controversial combinations).
So your map is an indication of where roads could be combined? With a maximum of two roads? Thatās a real good effort!
But look here. Why have the other three pieces of āBoslaanā not been added?
Wat code do you use there anyways? Can it be upgraded to show more than two roads that can be combined?
Iām not really convinced that this is a good idea in all cases.
Consider this (somewhat artificial) example:
Two roads connected, same tags, not being part of any relation.
Should they really be merged? I donāt think so.
they cannot be merged because they are part of a turn restriction, at least they should be (divider line prevents vehicles from turning there)
Neither do I. And weāve seen many examples that technically could be merged but that are not a good idea. Weāve been through that over the last 7 months or so in this thread on the NL forum. That was one reason we have made categories on the map of (technical) options. All Iāve said so far about which way we could (semi) automatic merge is that it is a subset of category1 on the map. I do not think your example in that catergory and even it is was it would not be one that I would suggest for a semi automatic merge.
At this point I see no use in a discussion on which (not) to merge because that will have to happen once there is a way to merge (semi) automatically. At that point we have to comply to āAutomated Edits code of conduct ā and then this topic should be addressed.
Depending on which boxes you check the map shows all or a subset of all ways that could technicaly be merged. If you check cat1,2 and 3 then you see all. But not all are a good idea to merge and that is why I made categories. Cat1 the most likely to be merged and cat3 least likely. So for your example all nodes where ways can be merged are shown. This map can be used as WMS as well soā¦loaded in JOSM merging is relatively easy.
Cat1 still is not 100% idiot proof so that is why I made an extra sql script to select a subset of cat1 (not on the map) that are āidiot proofā to merge. So far Iāve tested this manually and results look promising. This extra sql script selects pairs. But if pairs connect to other pairs (or pairs overlap) like in the āBoslaanā then I just pick one pair for a merge and open these in JOSM. After a rerun of the script the next day it will select the next pair so after 3 reruns all is merged. Maybe a JOSM merge script/plugin can be made to do this all in one go but I assume this is more complex so thatās why I started with this example.
while it is not a problem to occasionally merge ways with identical properties, I would not think it is something we should (semi) automatically do on the planet scale, as it creates a lot of unnecessary history noise and disruption (it becomes harder to see the history of the ways that get deleted in the merge).
It is clearly beneficial in extreme situations where ways are chopped into tiny segments for no reason, like Mateusz example, I have also seen something like this (rarely).
Roadways are split anyway for many reasons and for displaying street names this means you have to deal with it anyway (e.g. create a merged way for the name display).
I agree but this cut-up problem is a Dutch problem.
OK I understand.
The problem with merging 10 pieces in multiple combining actions is not the actions itself but that all history in OSM is saved. So multiple actions increase the data drastically - thatās how I think it works.
So it would be better to create the longest possible strings in one go.
Were do I find the WMS?
I agree with what you say. The WMS can be found in the linked thread but that is a long one so I can imagine you ask
And it can also found in this thread with more maps / WMS-es I made.
I understand what you are saying but the Dutch situation is different from most (or all?) other countries due to importing segments instead of complete roads. In this posting I describe a comparison Netherlands/ Germany. The number of (techically) potental ways that could be merged was about the same in both countries. The number of OSM-ways in Germany however is 6x higher. That gives you an indication of how cut up things are in The Netherlands. And maybe also good to know that I have no intention of merging ways in other countries.
