Cycleways can reverse direction when applying same selection to different ways

[frankie2784]

Add cycleways to a way such as the below:

Then click a different way with a different orientation and SC offers the below suggested option:

Applying this option adds a lane to the left side of the road travelling in the opposite direction to traffic flow (in Australia):

In fact, it tags the way with cycleway:left:oneway=-1

This is counterintuitive, and I notice this seems to only occur with the auto-complete.

Without carefully looking at the direction of the arrows could mean roads are being tagged with strangely aligned cycleways.

[westnordost]

I don't understand, what exactly is the issue?

[matkoniecz]

is it about lane being on left when filling it and then on the right when applying remembered selection?

[frankie2784]

Given the rarity of contra-flow lanes on regular roads, I propose that SC check the direction of suggested lanes so that they travel with traffic by default (left is always up, right is always down in Australia - opposite for Europe). i.e. SC should not auto-complete lanes in the contra-flow direction (unless previously requested by the user).

SC already provides a warning when trying to manually change the direction of the lanes (but it doesn't appear when auto-complete sometimes puts in a contra-flow lane):

In fact, you can see this warning pops up even when trying to change the lane to travel in the correct direction (the arrows in this case should be pointing up for standard left-side travel), which is also unnecessary.

[frankie2784]

is it about lane being on left when filling it and then on the right when applying remembered selection?

No, it is that SC assumes the new lane is in the contra-flow direction (arrows on the left-side are down instead of up), when the previous one wasn't.

[frankie2784]

Here's another example:

SC suggests the "left" side as "up" in the above (correct). But when applied, actually puts the lane as "down" when viewed from the same orientation:

If I instead enter the cycleways manually, it now puts the lane arrow in the correct direction:

I don't have an issue with the side of the road per se (there are obvious difficulties with showing which side is "left" and "right" with a more-or-less horizontally-aligned way). The main point is that if the lane is going to be applied to the north-side of the road, like the above, then it should assume that it is travelling east rather than west (again, this is for left-hand countries like Australia, Europe will be the opposite).

[westnordost]

I'd like to keep that button as dumb as possible. It fills in what it displays.

Any smartness that tries to guess the user's intention or guess how the road is supposed to look like with certain parameters is bound to be wrong some times and only contributes to its behavior regarded as inconsistent.

So, do you have any suggestion on how to improve the behavior but stay consistent?

[westnordost]

In fact, you can see this warning pops up even when trying to change the lane to travel in the correct direction

Well, that's a bug

[frankie2784]

I'd like to keep that button as dumb as possible. It fills in what it displays.

Any smartness that tries to guess the user's intention or guess how the road is supposed to look like with certain parameters is bound to be wrong some times and only contributes to its behavior regarded as inconsistent.

So, do you have any suggestion on how to improve the behavior but stay consistent?

I would propose for simplicity that auto-complete should always assume that, for Australia, "left" is "up" and "right" is "down". That is, the bike lane should always follow the standard direction of traffic on each side of the road - it already does this when manually selecting lanes. The user can then choose to reverse any particular lane for rare exceptions to that rule.

[frankie2784]

I'd like to keep that button as dumb as possible. It fills in what it displays.

In the case of the last example, it actually fills in the reverse direction of what it displays.

Clicking on this:

Adds this:

[westnordost]

So you say that the button should ignore any previously selected reverse direction and instead always display+apply the default direction?

If yes, why?

[frankie2784]

So you say that the button should ignore any previously selected reverse direction and instead always display+apply the default direction?

If yes, why?

If it can also remember the previously chosen directionality then I guess that's fine too. However, reverse direction is exceedingly rare in real life, so it probably isn't a big deal to apply defaults every time. On top of that, applying defaults every time would safeguard against an accidental flip that goes unnoticed for multiple subsequent quests.

[westnordost]

If it can also remember the previously chosen directionality then I guess that's fine too.

What do you mean? Does it currently not remember that?

[frankie2784]

If it can also remember the previously chosen directionality then I guess that's fine too.

What do you mean? Does it currently not remember that?

No it doesn't. That's the main issue I've been trying to get across (although it seems a couple of other related issues have emerged in this thread also).

See my first example. I tagged a cycleway manually, which added it in the regular direction of traffic flow (correct).

Then when I applied the "remembered" selection to the next way, for some reason it decided it was a contra-flow lane (incorrect).

The arrows in the second image should be pointing up to be in the direction of traffic flow.

[westnordost]

Oh, now I get it. This is actually quite the nasty bug. Will fix it asap.

[westnordost]

This is actually pretty tricky to fix... the solution is a little bit dirty but at least does not result in a refactor that (just) makes everything more complicated.

the direction of the cycleway for the last answer button is now always rotated to what would be the default direction for any country.

[frankie2784]

Thanks for attending to this so quickly @westnordost. That's great.

There appears to be another tiny issue lurking here. I won't open another bug report, as this seems to be related?

Due to the previous issue, this way has been tagged as having two contra-flow lanes (instead of both flowing with traffic):

This shows correctly in SC:

When I reverse these in SC:

It does flip their direction in OSM, but it leaves these unnecessary "oneway" tags (it is a two-way street, so these tags represent just the regular flow on this road):

Not the biggest concern, but thought it was worth flagging this slightly untidy behaviour.

[westnordost]

StreetComplete deliberately does not remove explicitly set direction tags but just updates them if they are there. The consideration is that if the mapper previously cared enough to explicitly set the direction, he will have had a good reason to do this. In any case, the app should not remove any tags as long as they are not wrong. People get upset if an app automatically deletes (explicit) data, rightly so.

Now, of course, in this case it was StreetComplete which set the previous tags explicitly. But StreetComplete doesn't know who or why the tags have been set explicitly previously. And StreetComplete had a good reason to set them explicitly before: Both sides were specified by the user to go each into the opposite direction of what would be considered the default.

[frankie2784]

That makes sense. Thanks for clarifying.

…

On Mon, 9 Jan 2023, 12:47 Tobias Zwick, ***@***.***> wrote: StreetComplete deliberately does not remove explicitly set direction tags but just updates them if they are there. The consideration is that if the mapper previously cared enough to explicitly set the direction, he will have had a good reason to do this. In any case, the app should not remove any tags as long as they are not wrong. People get upset if an app automatically deletes (explicit) data, rightly so. — Reply to this email directly, view it on GitHub <#4722 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AETVUIUI2NKO5F22VIUTJPTWRNU3PANCNFSM6AAAAAATQM2LGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>