Talk:Relation:connectivity

When it says "One or more via node or ways, which represent the junction." for the via role, is that one via node or one or more via ways? (i.e., can there be two or more nodes with the via role in the relation). -Vorpalblade77-kaart (talk) 18:17, 17 December 2019 (UTC)

No. There can be one via node, which works for most simple junctions, or any number of via ways, which can be useful for intersections involving dual carriageways or other uncommon situations. The current wording for this is a bit unclear though, so I'll try to find something better. --LeifRasmussen (talk) 19:00, 17 December 2019 (UTC)

via nodes or ways

I think the sentence "Via members should be nodes when possible, but in some cases, a way is needed." conflicts with the sentence "One via node or one or more via ways, which represent the junction."

Sort of. I really just wanted to make clear that it's better to use nodes than ways, because they are more maintainable, but that it's ok to use ways if nodes won't suffice. Basically, both are ok to use, but if you come across a situation that could be modeled with either, use a node. --LeifRasmussen (talk) 14:20, 19 January 2020 (UTC)

Maybe replace "Via members should be nodes when possible, but in some cases, a way is needed." by "If the from way and the to way are connected, use the shared node as via member, else use one or more via ways which connect them." There is no example that shows a via way, so it's really difficult to understand when this is needed.

I've improved the wording. Thanks for bringing up this unclarity! --LeifRasmussen (talk) 15:25, 20 January 2020 (UTC)

Clarity of first example

I was struggling to understand why the first example needed a connectivity relation. Having looked at the ways on OSM I now realise the To way has three backward lanes, but didn't spot that from the picture. I think it would be much clearer if the lane numbers were painted on the image. Also, I'm still not sure why it couldn't be understood from a placement tag. Perhaps the hatched area? Can that be explained? Or is it okay to use connectivity relations even when it could be worked out but is a bit complicated, because it's explicit and saves routers from guessing? Thanks! --TrekClimbing (talk) 23:15, 15 February 2021 (UTC)

When creating the proposal, I made the rules for how to assume connectivity as simple as I could to ensure each data consumer understands everything the same. Part of that simplification is that placement tags shouldn't be used for assuming connectivity when there are more than 2 ways connecting. I personally think it's fine to add connectivity relations if your not sure if the connections can be assumed.

I'm currently working on a plugin for JOSM which will allow all aspects of lane tagging to be done in a graphical, mostly text free UI, but it doesn't yet support connectivity relations. See the plug-in "Lanes" for the current beta version. LeifRasmussen (talk) 17:58, 20 February 2021 (UTC)

Thanks, I see that rule now. I have tried adding lane numbers to the first example which I think would be helpful: https://commons.wikimedia.org/wiki/File:ConnectivityExample1-lanes.png if you want to swap the image. I've added that plugin (I was using Lane and road attributes for visualising), looking forward to connectivity relations being added to that. Any chance it will highlight points that can't be guessed using your rules? Thanks --TrekClimbing (talk) 21:54, 20 February 2021 (UTC)