(Semi) automatic combining highway pairs. Any suggestions?

Mateusz_Konieczny · 2023-02-19T09:51:50.996Z

PeeWee32:

A hundred pairs (or so) of highways will be loaded into JOSM using an overpass query containing these highway id-s. JOSM would loop through these and combine these ways. If anything is wrong with combining JOSM will give an error (but I am very confident this wil not happen ) After looping through these pairs the changeset can be uploaded to OSM.

that is an automated edit

Kogacarlo · 2023-02-19T13:54:12.431Z

I can understand why you would like to combine pairs. But I don’t understand why you are looking at only pairs and not triplets or more.
It’s not logical to look at pairs only.

Secondly, I remember one of the Dutch mappers that imports roads telling he or she allways imports roads in seperate pieces because with those pieces it would be easier to create route relations. This should be adressed. It would be stupid to import thousands of pieces in the database and afterwards have a script combining them.

Kogacarlo · 2023-02-19T14:31:58.892Z

But then, if you let the script rerun until no more pairs are found eventually all roads will be combined

But what to do when there are multiple combinations possible? How to distinguish between main road and branches?

780×320 117 KB

PeeWee32 · 2023-02-19T14:40:27.530Z

Kogacarlo:

But what to do when there are multiple combinations possible? How to distinguish between main road and branches?

The script distinguishes in situations of possible combinations. This situation is definitely not one that will ever be solved (semi) automaticity. A local mapper might know best if a combination (and which one) is best.

PeeWee32 · 2023-02-19T17:48:41.612Z

Kogacarlo:

Secondly, I remember one of the Dutch mappers that imports roads telling he or she allways imports roads in seperate pieces because with those pieces it would be easier to create route relations. This should be adressed. It would be stupid to import thousands of pieces in the database and afterwards have a script combining them.

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.

Kogacarlo · 2023-02-20T02:19:07.597Z

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.

Nadjita · 2023-02-20T11:02:21.233Z

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?

Kogacarlo · 2023-02-20T15:32:40.743Z

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:

PeeWee32 · 2023-02-20T18:12:04.622Z

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.

PeeWee32 · 2023-02-20T18:14:35.740Z

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.

Mateusz_Konieczny · 2023-02-20T18:36:20.472Z

PeeWee32:

I can understand this question because the current situations has not lead to major problems (AFAIK).

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.

PeeWee32 · 2023-02-21T05:33:18.058Z

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.

Kogacarlo · 2023-02-21T14:05:15.256Z

Mateusz_Konieczny:

100 elements, each about 1m long

There is a handy key right to the left of the [End]-key that can take care of that.
And then draw something new in seconds.

Anyways, we’re still looking for a software solution to the combining task.

@PeeWee32, do you have a changeset number I can have a look at of some of the 85000 roads you combined?

Mateusz_Konieczny · 2023-02-21T14:52:11.939Z

PeeWee32:

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).

PeeWee32 · 2023-02-21T17:51:33.565Z

Kogacarlo:

@PeeWee32, do you have a changeset number I can have a look at of some of the 85000 roads you combined?

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).

Kogacarlo · 2023-02-22T14:08:49.001Z

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?

scai · 2023-02-22T14:36:34.221Z

I’m not really convinced that this is a good idea in all cases.

Consider this (somewhat artificial) example:

foo1751×558 197 KB

Two roads connected, same tags, not being part of any relation.

Should they really be merged? I don’t think so.

dieterdreist · 2023-02-22T17:33:34.000Z

they cannot be merged because they are part of a turn restriction, at least they should be (divider line prevents vehicles from turning there)

PeeWee32 · 2023-02-22T17:46:54.743Z

scai:

Should they really be merged? I don’t think so.

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.

PeeWee32 · 2023-02-22T18:59:55.313Z

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.

defrag_wezep1081×538 125 KB

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.