In NL no roads are imported. Many years ago the Dutch road network was imported from the AND database. In this database a road consisted of many segments (just like the Dutch National Road database (NWB)). One for each connection with an other road. All segments had an own AND id which was also imported in OSM at the time. Later on we realised these AND idās were of no use at all and thusā¦ were deleted from OSM. We also realised that we would never have roads split in so many segments if they were manually mapped. All these segments also have consequences for some data consumers. Nominatim returns all these segments if you search for a street in a city. (try Marianlaan Zwanenburg e.g.) and Carto shows a lot more street name labels when there are many segments.
It is also good to realise that not all segments were created by AND import. A lot were created for reasons unknown to me. Maybe an error in an editor. Or maybe a way was cut because only a part was surveyed and a mapper wanted to add a tag (e.g. surface=asphalt). When someone else later also adds this tag to the other part we end up with a split way for no reason at all. During the 90.000 combinations weāve already made weāve also seen many very small segments (often no more then 1 or 2 meters) that were very easy to miss when working on route relations.
As far as I know consensus in OSM is that highways are not split unless tags differ or when (route) relations requires us to do so. Also for consistency reasons in OSM it would be a good idea to combine ways. Also see this response in the Dutch forum regarding route relations.
For further information please also see this thread on the (old) Dutch forum.
Oh, opinions must have changed then (not your opinion).
I remember Marc Zoutendijk writing that combining roads was a strange habit of sick people. Here is the old thread.
I also fail to see the benefit of this. Whatās the actual reason people would do this? Did anyone complain that the total number of ways is too high? Are we trying to solve an actual problem, or what?
I definitely see a benefit because in lots of places streetnames are not shown at all because there is not enough space to show a name ten times in ten centimeter. I brought this up in the rendering section of Carto and it was picked up by someone but it stranded there also.
I canāt find that thread.
As an example: on this long stretch of road the name is not shown because it doesnāt fit four times:
Yes I guess so. I think the issues with cutting highways (with relations) in JOSM has disappeared so that there no more reason not to combine highways. As stated by Dick who maintains a lot of the route relations in OSM it would even be beneficial to now have these ways combined.
I can understand this question because the current situations has not lead to major problems (AFAIK). Ok ā¦rendering streetlabels in Carto could be better but it has never been a major issue. The question one might ask is ā¦ how should we map a long street with many connections to other streets? (not considering differences in tags/route relations). Should we map one long way, or all segments between connecting ways, or something else? As far as I know most people would map just one way. This will not prevents us from eventually ending up with segments that could be joined (again) because mapping continues. Then the question is ā¦. should we join these again or leave em alone? Answers will differ depending on who you ask.
The same goes for ways that are split without any other connection ways on the node where ways are split.
I personally see split ways as a kind of database redundancy. The DB of the current situation in OSM could be smaller if ways are joined.
Furthermore creating/maintaining route relations is more transparent.
And as said before ā¦ streetlabeling in Carto will improve
Again one might argue that this is not worth the trouble. In that case ā¦ donāt do it and save your energy for other OSM related work that you find more important.
I have (manually) merged some cases where for some reason road was split into about 100 elements, each about 1m long. This was making editing it a pain.
Iāve seen many crazy split ways and often wondered why they were split in the first place. One common situations is where ways were split because there was a bridge=yes. Later on some saw it was not a bridge but a crossing tunnel=culvert and removed the bridge=yes. And forgot to combine ways again. Iāve also seen many ways that are split of which one part was 1 meter long but Iāve never seen something as crazy as a way split into 100 segments of 1 meter each.
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?
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.
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.
