Talk:Variable-access lanes
Scheme bad for software support point of view
I want to point out that this scheme, i.e. including the shoulder in the lane count is a bad idea when looking at it from the point of view of software support.
If lanes=* (can) include also shoulders, i.e. lanes one can not drive upon, it means that any software that wants to do anything with the lanes=* tag must also support the tagging described here to yield correct results. Including, of course, software that existed already before this tagging scheme was invented (or, before this tagging schema will see widespread use, whenever that may be).
Good tagging schemas don't retroactively make existing software yield wrong results but drill down on the level of detail by using additional tag, not change the meaning of existing tags. By defining that lanes=* is the number of lanes including lanes you may not drive upon (shoulders), you kind of change the meaning of lanes=* and this causes, amongst others, the issue described above. --Westnordost (talk) 13:42, 15 September 2022 (UTC)
- This tagging scheme only includes the shoulder in the lane count when it is in fact a lane one can drive upon. This is also important, because it enables including the lane in turn:lanes=*, destination:lanes=*, maxwidth:lanes=*, placement=*, connectivity=*, etc. A "running hard shoulder" is essentially no longer a shoulder, as it has been modified to become a traffic lane (that can be opened and closed). Commonly, newly constructed emergency bays are added to the road to replace the emergency lane function of the former shoulder.
- Using access:lanes=* to specify usage restrictions on lanes is well established. Software that doesn't understand the variable value will interpret it as a lane with unknown access conditions, just like any other value for access=* it doesn't understand. This is expected and intended. --JeroenvanderGun (talk) 20:07, 15 September 2022 (UTC)
- access=variable is not standard in the first place. This is required by the *:lanes=* syntax, The usual or default restriction is needed, from the perspective of *:conditional=*. access=variable is not meaningful for this purpose. Editing Key:access#List_of_possible_values together without further explanation doesn't help your argument. https://wiki.openstreetmap.org/w/index.php?title=Key:access&type=revision&diff=2392933&oldid=2377698
You should try access:variable:lanes=* similar to maxspeed:variable=*. This avoids any mixing and conflict with actual determinable restrictions in forming the conditions. The variability can further be tagged together.
Anything wrong with shoulder:left:*=*? When it is not open for travel, it functions as a inner shoulder too.
Cf active_traffic_management=* to augment *:varaible=* in how dynamic the variability is. --- Kovposch (talk) 06:37, 16 September 2022 (UTC) - Another problem is *:conditional=* @ (flashing_lights) or similar is already possible. This overlaps with access=variable. --- Kovposch (talk) 06:42, 16 September 2022 (UTC)
- access=variable is not standard in the first place. This is required by the *:lanes=* syntax, The usual or default restriction is needed, from the perspective of *:conditional=*. access=variable is not meaningful for this purpose. Editing Key:access#List_of_possible_values together without further explanation doesn't help your argument. https://wiki.openstreetmap.org/w/index.php?title=Key:access&type=revision&diff=2392933&oldid=2377698
- Thanks for the feedback. The current tagging is not necessarily the best, but at least this is now consistently used in the Netherlands and consistently documented. W.r.t. your suggested alternatives:
- One possible variant could indeed be to drop variable and instead use e.g. access:lanes=no|yes|yes + access:lanes:conditional=yes|yes|yes @ extra_lane_open. But it seems unnecessarily verbose. Nevertheless, it is probably good to define some condition for use in conditionals, so that you can add things like maxspeed:conditional=100 @ extra_lane_open.
- With something similar to maxspeed:variable=*, I guess you would end up with access:lanes=no|yes|yes + access:lanes:variable=peak_traffic|obstruction|obstruction? I suppose this could work. Or access:variable:lanes=*? variable:lanes=*?
- Using shoulder:*=* instead of considering it a lane seems undesirable for reasons mentioned above, and also appears inconsistent for cases where the variable-access lane briefly turns into a permanently-open lane (see new example).
- I added a lot more examples to the page, hopefully that should help compare different possible tagging schemes. Feel free to copy-paste the examples table to this talk page with the tags modified.
- (Note that the brief mentioning in Key:access#List_of_possible_values is merely intended to redirect people to the explanation on this wiki page.)
- --JeroenvanderGun (talk) 12:49, 16 September 2022 (UTC)
- Thanks for the feedback. The current tagging is not necessarily the best, but at least this is now consistently used in the Netherlands and consistently documented. W.r.t. your suggested alternatives:
Scheme variations spotted in other countries
For reference, here are some undocumented tagging schemes spotted in the wild (found via TagInfo):
- lanes:conditional=*. Seems very impractical because everything else that depends on the number of lanes now also needs to use conditional tags. Also arguably the lane still physically exists when it is closed. access:lanes:conditional=* seems preferable to lanes:conditional=*.
- access=peak_traffic instead of access=variable. Seems worse than current scheme on wiki page because then we need to define a new access=* value every time the reasons for opening/closing the lane are different.
- shoulder:right:access=signals. See comments above on lane vs shoulder.
- drive_on_shoulder=possible.
--JeroenvanderGun (talk) 16:56, 16 September 2022 (UTC)