Unclear about orientation in roundabout

[hmartink]

I 'm asked about e.g. pavement presence in a round about. I could guess that it is the outer part which is eligible, but this is not clear from the UI (which presents it as straight line).

How to Reproduce
Go to 50.76335, 6.99709. Then you get the question.

Versions affected
I think I saw this in older versions as well, but it's clearly present today with StreetComplete v36.0

[matkoniecz]

What about the explanation text? Is it still not clear after reading it?

[smichel17]

For reference, it looks like this

(I am purposely not commenting further yet)

[westnordost]

See @matkoniecz . The reason such roads exist was the very reason why this description was added. There is nothing else really that could be done in this UI without radically changing it I don't know how.

[smichel17]

Would it be possible to color code the sides of the street? Something like this:

Alternatively, maybe we could just make the description text more eye-catching: either black, or bold the important section

The road in the illustration is rotated the same as on the map at the location of the pin.

[westnordost]

Hm yes, that would be possible with tangram-es. Though of course, it would need some change in implementation. Currently, on selecting a quest, the main fragment just tells the map fragment to highlight the geometry of the element and tells the bottom sheet fragment to display the quest form UI. I.e. the two things are separate and don't know anything about each other.

So to do something like this, ... I guess, the quest form fragment would need to essentially control how the map fragment renders the highlighted geometry, i.e. in effect the quest form would need to request the main fragment to render it differently than normal. Thus, the main fragment would probably need to wait for the quest form fragment to appear until it displays the highlighted geometry.
But it is possible.
It would also probably make it possible to have the whole building be highlighted (i.e. not only the outline but also the height) on selecting a building-related quest.

[FloEdelmann]

have the whole building be highlighted (i.e. not only the outline but also the height)

For reference, a similar suggestion was made in #3397.

[peternewman]

For the moment, am I right in thinking @smichel17 's illustration is correct and it's based on the orientation at the quest pin? Or is it the reverse and there's one marker half way along the way and therefore the two-colour proposal is actually wrong?

[westnordost]

Reviewing this, I think it is not worth the effort to break up the whole "highlighted geometry" rendering to give yet another hint to the user. As seen by Peter Newman's confusion in his last comment, this is also not the silver bullet.

[smichel17]

As seen by Peter Newman's confusion in his last comment, this is also not the silver bullet.

@westnordost I think you've misread @peternewman's comment. I interpreted his comment to mean,

@smichel17's mockup is clear, but I'm not sure if it is correct, because the current behavior is unclear.

[peternewman]

Yes exactly, I could accurately answer the question posed by @smichel17 's mockup, although my suspicion is the mock-up is actually the wrong way round.

If we do nothing, someone at least needs to clarify for power users what is the correct interpretation for the current one:

Is the inside the left, as I suspect, or the right? i.e. is the quest pin being rendered in the middle or at end of the way?

FWIW this also impacts staircase direction and the same fix would work for that too. Alternatively (and possibly simpler), rendering a directional marker along the selected way (arrows, or even the question marks we currently see on either side) and showing that on the zoomed-in rotating puzzle bit would allow you to identify it (although requiring a little more brainpower for the sidewalk), but with no real difference on the staircase questions.

[westnordost]

Why would it matter if the quest pin is rendered in the middle or at the end of the way? Whatever should "the end of a way" mean when we speak of a circle?

[peternewman]

Why would it matter if the quest pin is rendered in the middle or at the end of the way?

Take a piece of paper (ideally printed on one side), hold it as a tube (with the printing inwards), if the pin is at the join of the two ends, the left (from that point) is the inside (with the printing) and right is unprinted. Now imagine the same thing but the pin is on the middle of the sheet, left is outside (unprinted) and right is inside (printed).

So in the case of a sidewalk, whether the pavement is on the "left" or the right" makes a big difference to routing/walking on foot.

Whatever should "the end of a way" mean when we speak of a circle?

Fair point, although we all know it's drawn as a line with two ends, not a native circle with centre and diameter.

[westnordost]

I don't get it.

[peternewman]

If you ask the question at point A, the answer is entirely different to if you ask it at point B (hence the colours swap places).

[westnordost]

I see. So if it is asked at point A, the user would select e.g. sidewalk on the left (red), no sidewalk on the right. If it is asked for point B, the user would select sidewalk on the right (red) and no sidewalk on the left.

But anyway, that's what the hint is for:
#3399 (comment)

[smichel17]

I swapped the wontfix label to needs PR since, with that confusion cleared up, the coloring suggestion does seem like it would solve the issue completely (but may not be worth @westnordost's time to implement, since the current situation is not that bad).

[matkoniecz]

@smichel17 I am not sure from reading this exchange that @westnordost would accept PR

[westnordost]

Probably not. Unless you can think of a solution that would involve less code and complexity than I do.

[smichel17]

Hm, ok. Perhaps I'll look into it after it is decided whether we're moving to MapLibre (#3123).