Finding and merging parallel ways that are part of the same street in OSM file

Question

I am using OSM data for a programming task I'm working on, and one thing I've noticed is that often, major streets that have a barrier or divider in the middle are represented as two separate, parallel ways - one way for each direction. This behavior is not desirable for the particular program I'm writing, so I want parallel ways to be merged into a single way running down the center of the street. It seems like a fairly simple problem, but I'm having a trouble getting the program to identify ways that need to be merged and then merge them properly.

Right now, the program looks for ways that need to be merged by looking at pairs of ways, using the first and last node of each way to figure out the angle at which it is oriented. If the ways are oriented at a similar angle and are close enough that small rectangles drawn around them would overlap, then the program will try to merge the two ways.

Unfortunately this technique doesn't work as well as I'd like it to in practice - it's pretty inefficient (as it would need to compare lots of pairs in a large map) and there are many edge cases in which it fails, like when one side consists of a single long way and the other side consists of multiple short ways.

Is there an easier way to accomplish this? Perhaps with an existing tool, or something obvious I haven't thought of?

Accepted Answer

major streets that have a barrier or divider in the middle are represented as two separate, parallel ways - one way for each direction

Yep this is intentional. The idea being that if you could physically (as opposed to legally) do a U-turn in a road, then you should map it as one OSM way, if you cannot (due to walls/barriers) then it should be 2 separate ways in OSM, with appropriate one way tags. This also makes much more sense for motorways, which will have complicated junctions which only merge into one "lane".

To solve your problem, I can give some hints: Many of these "split roads" will have oneway tags, they will have the same road classification (i.e. the highway tag), they will almost certainly have the same ref tag (e.g. ref=A8). They may have the same name tag. Perhaps this could help find candidate roads. It's also much less common the further down the road hierachy you go. 97.5% of highway=motorway are oneway=yes, whereas only 54% of highway=trunk are oneway=yes.

For example, this road and this road are one "split road". You'll notice they both are mapped oneway=yes, highway=motorway, ref=A 10, and both have the same name (L'Aquitaine).

As for the program, it tries to predict where sidewalks and crosswalks should be located, as part of a project to improve accessibility. ... It should be putting sidewalks on each side of a street, of course, but when there are two parallel ways it tries to put four sidewalks rather than two.

Perhaps, rather than trying to merge the 2 OSM ways, you could just use the approach I gave to detect "probably split roads", and then only add the sidewalk in one direction? i.e. the direction of the road itself?

Answer 2

I suspect that first merging ways that have been split along the length of the road would help a bit, naturally there is no guaranteee that the geometry of say a footway actually is parallel to the real road surface.

ASCII art of such a situation:

                F
                F
FFFFFFFFFFFFFFFFXfffffffffffffffff
                f
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR

F=footway 1 f=footway 2 R=Road

F and f woudn't be mergeable without splitting at X.

PS: in an answer becase markdown doesn't work in comments.

Answer 3

Your question/issue is just a trivial case of the problem what we inevitably meet in vector map-making. Namely, in a road class, road sections are often presented by two "parallel" poly-line segments, one per direction. More precisely, the distance between the two "parallel" poly-line segments is never larger than a critical (parameter) distance "d". For illustration assume the primary road class and d=10m. In the data preparation, when creating the vector scale-levels, when the scale factor is less than 1:20000 the distance will vary between 0 and 2 pixels on a 120dpi rendering display. This has a bad aesthetic consequence end data redundancy in transmission and client rendering. Therefore, in the data preparation we try to detect and eliminate the parallel cases (the phase/step just before the vector smoothing).
You have already got some suggestions how you can cope with the "parallel" issue. Here is one geometry/topology based option. Assume, for the mentioned illustration, we have two ways/poly-lines AC where B is an inner point and MP where N is an inner point. Assume that the distance d(B,M) and d(C,N) both are less than d. In an early version we have used a surface criterion for checking the parallel property between the BC and MN polylines. So, if the surface enclosed by the polygon BCNMB was less than the surface length(BC)*d, then we replaced the BC and MN poly-lines with only one keeping the proper connectivity. Occasionally this criterion was not enough strong and in the current version a corridor model is used. Assume that AC is longer than MP and a circular pen with radius d. Now, if you move this pen along the AC ply-line (as the skeleton) the contour of the thick line (in a vector format) is the border of an area we call for corridor. Now, if an edge vector of MN is inside the corridor of BC this is to be ignored/deleted from MN. The rest poly-lie(s) of MN and the NP poly-line with proper connections to AC create the new road segment.
Of course, there are many, many fine details missing. But note that the same model might be used for bulk upload of a road class (or other line-work data types). E.g. a government suddenly makes public a road class in a country. The local OSM community would like to upload this more accurate road data by eliminating "parallel" cases from the older manual uploads.

Finding and merging parallel ways that are part of the same street in OSM file

Follow this question

Related questions