Nodes connecting ways in complex road intersections

I have encountered many road intersections where nodes that I believe serve no useful purpose and are actually detrimental have been placed joining ways. My understanding is that a node connecting two ways should, in general, be placed only when it is possible and permissible to turn from one way onto the other. However, there may be some merit, which I don’t see, in such nodes in terms of router behavior.
Example:
https://www.openstreetmap.org/#map=19/51.14261/-114.12362&layers=N
In this example, nodes have been placed connecting each left turn lane within the core “square” of the intersection with each way that is crossed by the lane. Unless turn restrictions are placed on each of these nodes, a router is at liberty to do things like route from [Shaganappi Trail left turn to Country Hills Boulevard east-bound] to [Country Hills Bv west-bound] or to [Shaganappi Tr north-bound]. These things can be prevented with turn restrictions, but can, with less map data, be prevented by eliminating the connecting nodes.
Do the nodes connecting the turn lanes to the other turn lanes have any value?
Do the nodes connecting the turn lanes to the through-lanes which they cross have any value?

Looks OK to me. The test is “possible”, not “permissible”.

The only time you wouldn’t join them is if one bridged over, or tunnelled under the other, and then you would need bridge or tunnel tags and layer tags.

It does look as though there are too many ways, i.e. the crossovers could be intermediate nodes, but that isn’t an actual error.

You can use relations to exclude turns that are possible within the one way system but forbidden by signage on the ground.

@abDoug, you are not the first to notice this. There was a proposal https://wiki.openstreetmap.org/wiki/Proposed_features/highway%3Djunction to simplify complex junctions back in 2012. However, it was never approved, nor did it became popular.

So for now, we still put a not on all level crossings of two highway-ways, as hadw mentioned.

Thanks.
The “possible” vs “permissible” test at least makes for consistency. Unfortunately, most of the intersections in Calgary have been done without specification of turn restrictions, so a huge amount of work will be required to fix things and the database will grow substantially.

This work of adding turn restrictions is done all over the world. Many other things are added to the database as well (from benches to forests), so the size of the database will grown anyway.

Sure, lots of things contribute to the size of the database. If they contribute useful information, fine. If they don’t, they are worthless or worse than worthless junk.

A single tree at the edge of a parking lot is arguably useless junk, unless it is a “significant” tree because of species, age, having a name, etc. It might be useful as a reference point for drug dealers. But it doesn’t need much beyond the point coordinates.
I spent a great deal of time trying to edit (by moving existing nodes) then ultimately completely replacing a stream in a local very popular park because it had changed substantially due to a floods. Many pathways, including bridges, were permanently destroyed by the floods. The original mapper had used about 4-5 times as many nodes as could ever be justified for a stream running in a natural bed (as opposed to a concrete channel). But they were still only nodes requiring coordinates - a huge burden for editing but not so much for the database.

When a useless node connecting two link ways is added, it becomes “necessary” to tag it to restrict turns. This results in automatic splitting of each way at that node. Each resulting piece now must carry a name, possibly in multiple languages, and tags for surface, number of lanes, one-way status, et cetera. What is gained by this? As far as I can tell, absolutely nothing. No one has made a case for why that node was of any value in the first place, other than allowing mappers to suspend thought while adding it. If that node is omitted, there is no useless junk added to the database and subsequent editing when more accurate aerial images become available is less tedious.