An editor is frantically running around Calgary chopping ways into tiny little pieces.
Consider an intersection of four one-way ways crossing (like an octothorpe #), which is very common here for divided roads.
As originally drawn by most editors, this would consist of four ways with the appropriate connecting nodes (four) where they cross. After this editor has be at it and split each way at each node, there will be twelve distinct ways - four entering, four exiting and four short pieces “inside” the four nodes. (In a case were two of the ways have left turn lanes that pass through the “square”, instead of 6 ways there are now 18! https://www.openstreetmap.org/query?lat=51.03690&lon=-114.17857#map=19/51.03671/-114.17808))
Except in special circumstances, such as where splitting is necessary for making a bus route relation, I can see no merit in doing this. On the contrary, each of those ways must now carry full details - road class, name, one-way, surface, lane count, turn prohibitions, etc. This will clearly be burdensome to the database. It also means that a router must examine each node to determine if the road has the same name on both sides OR give instructions like go west on A street, continue west on A street, continue west on A street.
He does the same thing for ways with right turn connectors, splitting the way where the connector diverges. Again, this is necessary for some ways at some intersections for creating routes or where the number of lanes changes, but seems useless and damaging except in such cases.
I seek guidance on this from knowledgeable editors.
Generally the first advice is to add a comment to the changeset in question, as, if it is decided that this needs stopping, the escalation process is to do that, and try to enter into a dialogue, but if there is no dialogue, the editor will be blocked until they have read the comment.
From the aerial imagery there seems to be a kerb, so the detail with the turning ways seems to be right, and if you are worried about navigators, these detail is needed for a navigator to give a good route and guidance, just it needs more work in the details, traffic lights and restrictions. Also more detail and careful edition is needed in “lanes” and “turn:lanes” to improve the guidance.
In reply to hadw
I would have added comments to the changesets, but I generally approach this stuff by asking myself if I really know better than the other guy, and in this case the very best I can claim is “well … maybe” - hence the request for input from others.
I did some experiments and realized that splitting a way is a consequence of adding a turn restriction, and therefore unlikely to be something he is doing explicitly. Some of those he is putting in are required by the practice of putting in the connecting nodes that I questioned in the previous thread, so the splitting makes the burden to the database much greater than presence of “useless” connecting nodes. He is putting in a lot of turn restrictions that, as far as I can determine, are not supported by law, so I’ll query his authority for adding them. He also seems to be splitting at each node where a turn connector diverges from the through-way. As far as I can see, this is required only if there is a change in lane count for the through-way or for creation of a route, but at least the pieces are more than a few metres long.
I actually don’t care all that much about roads, but I’ve fixed an awful lot of errors and named many many roads that have been in the map for nearly 9 years without names. However, I view the addition of things that don’t contribute information useful to as least some users as generally bad.
In reply to muralito
I hadn’t noticed, but I actually picked an error-filled intersection as an example. The only turn connectors that should be there are from 17 Ave east-bound to and from Simcoe Bv. The other three are simply turn lanes, not connectors. Calgary is forever changing roads, and many in the map are from the original work of one editor nearly 9 years ago. Using the source which must not be named, I can confirm that those connectors used to exist but no longer do. The LRT tracks north of 17th were added just a few years ago, pretty much right on what used to be the west-bound lane of 17th.
Checking all that stuff is incredibly time consuming and the poor quality of the Bing sat images for most of this area don’t help. It can be really difficult to distinguish a painted line from a narrow curb that dividing through-lanes from connector lanes. If I didn’t have resources based on open data from the City of Calgary, I’d have a very hard time doing many of my edits.
I shall have to put a yet another red X teardrop on the map!
The Bow Tr - Strathcona Bv intersection to which you linked is a good example of how having a node connecting the connector way to the cross through-way (WB connector way to SB Bow Tr connecting to NB Bow Tr) makes is necessary to apply a turn restriction. The same is true where two connector ways cross, and those nodes I really regard as useless junk that burdens the database. If the nodes were added, there would be no need for applying the turn restrictions.
muralito, thanks for mentioning turn:lanes. I hadn’t looked at that before and have never seen it applied to any road in Calgary.
I’ve avoided editing roads except for alignment (again, many roads here were placed 9 years ago and never reworked since) and naming. Even at that, since the time I signed up as an OSM editor, I’ve spent much more time editing roads that I have driving on them. It’s probably true for pathways, too, but I like walking & cycling. I don’t even like being in car, much less driving one.
If OSM supported setting of traffic rules by area such as city, county, country, etc, a huge amount of this could be made to go away with a very few lines of rules.
For example, if a rule such as
U-turn at traffic light = no
applicable distance from light = 35 [metres]
could be applied to the province of Alberta, it would relieve the need for tens of thousands of individual tags and probably hundreds of thousands of the tiny fragments of ways and megabyte of burden to the database that result from applying the turn restrictions at individual connecting nodes. Omit the completely useless nodes connecting crossing links, and even more worthless junk doesn’t have to be added to the database. The exceptions not covered by this U-turn rule would be extremely few. In this example, the “applicable distance” is not something codified in law, but a necessity arising from the variant placement of traffic lights on ways - sometimes at node where ways cross, sometimes on ways “before” crosswalks & intersecting nodes, etc. It would have to be added by someone willing to actually think carefully about the issue (though the number of cases of prohibiting U-turns where actually legal by making the distance somewhat too large would be minuscule).
I note that the only occasion on which I used OSM (OsmAnd+) for a driving route, the ways connecting to two small roundabouts had reversed one-way tags, after two people from the Mapbox Data Team had done something to them but failed to correct the error.
He is putting in a lot of turn restrictions that, as far as I can determine, are not supported by law, so I’ll query his authority for adding them. He also seems to be splitting at each node where a turn connector diverges from the through-way. As far as I can see, this is required only if there is a change in lane count for the through-way or for creation of a route, but at least the pieces are more than a few metres long.