<div dir="ltr"><div>You would also have to know how many ways there are, just looking for 2 is not sufficient, because there could be 3, 4, 5, 6 or even more. Around here I've a situation with 6 parallel carriageways:</div><div><a href="https://www.openstreetmap.org/#map=19/41.86472/12.49702">https://www.openstreetmap.org/#map=19/41.86472/12.49702</a></div><div>some meters north of this spot, they are even 7 for a short length (or 8, if you count the cycleway and 9 if you also count the parking aisle).</div><div><br></div><div>And you would have to decide when not to do it, for example Via Palos runs for some time parallely but then makes a turn and passes under the bridge: <br></div><div><a href="https://www.openstreetmap.org/way/257174994#map=17/41.86821/12.49583">https://www.openstreetmap.org/way/257174994#map=17/41.86821/12.49583</a></div><div><br></div><div>And if there are ways that run along the "principal" highway for some time at only one side, but then vanish, and you calculate the center for the "synthesis", it will put corners or curves in your main way which actually runs straight.<br></div><div><br></div><div>You will surely have to define a maximum distance threshold for this unification, and you always will have edge cases around this threshold which can cause inconsistency.</div><div><br></div><div>Depending on your purpose, you also may want to not unify parallel ways when they run on different levels, e.g. one on a bridge or embankment (e.g. along a retaining wall), or in a cutting.<br></div><div><br></div><div>As you probably know, the typical OSM solution for this is raster rendering, because then the ways merge visually and "automatically" (as their width is usually exagerated and layer ordering renders first the casing then the fill).<br></div><div><br></div><div><br></div><div>Cheers</div><div>Martin<br></div></div>