Sidewalk surface quest does not appear as expected

[rhhsm]

How to Reproduce

1. Select a road in sidewalk overlay, and reply that both sides have sidewalks
2. Walk until the end of the road, and notice that a small bit further on has sidewalk only on one side, with a different surface
3. Select road, and split
4. Select small bit, and reply that it has sidewalk only at one side
5. No sidewalk surface quest appears
6. I tried to work around this by undoing the sidewalk surface answer for the unsplit road (i.e it appears above the split road action in the undo list), however only the sidewalk surface quest for the long section appears.

Expected Behavior

5. I would expect that the sidewalk surface quest would appear at least for the small bit: that the surveyor needs to correct the answer means it's quite likely the sidewalk surface is also wrong
6. The sidewalk surface quest appears for both sections of the split road

Versions affected Android 10 and StreetComplete 52.0

[Helium314]

Can't reproduce. Sound a bit stupid, but is the step 2 actually important, i.e. things work properly without this step? I only did it from home and didn't really walk along any road.

[rhhsm]

Can't reproduce. Sound a bit stupid, but is the step 2 actually important, i.e. things work properly without this step? I only did it from home and didn't really walk along any road.

No, 2. is just to explain why this could happen in the field. I reproduced it at home, on 1 road. Will try if I can reproduce it on other roads...

[rhhsm]

Maybe it only happens for roads that are "clean" of other quests (no other quest icons hiding things). Will try more things tomorrow...

[matkoniecz]

Is it possible that this quest was blocked by other higher-priority quest on other object? Would it be still reproducible with all other quests disabled?

[rhhsm]

I've been experimenting (without uploading anything) on this way https://www.openstreetmap.org/way/259118617 It is an example of something strange with some ways including this way and the one just north-east of it: it appears without any quests in the general view (no overlay), and only in the sidewalk overlay it shows that no sidewalks have been set for it. I would expect that in the general view, the sidewalk quest would appear, but it doesn't. Maybe this is related to the issue here, maybe I should open a new issue for this?

I noticed there is an important omission in the "How to reproduce" above; it should be:

How to Reproduce

1. Select a road in sidewalk overlay, and reply that both sides have sidewalks

1a. Answer the sidewalk surface quest that appears (for instance that both sides are paving stones)

2. (optional) Walk until the end of the road, and notice that a small bit further on has sidewalk only on one side, with a different surface

3. Select road, and split (in unequal parts)

4. Select small bit, and reply that it has sidewalk only at one side

5. No sidewalk surface quest appears

6. I tried to work around this by undoing the sidewalk surface answer for the unsplit road (i.e it appears above the split road action in the undo list), however only the sidewalk surface quest for the long section appears.

Expected Behavior 5. I would expect that the sidewalk surface quest would appear at least for the small bit: that the surveyor needs to correct the answer means it's quite likely the sidewalk surface is also wrong 6. The sidewalk surface quest appears for both sections of the split road

I could reproduce this both with "all" quests enabled, and with only sidewalk and sidewalk surface quests enabled. However, it is an issue for ways that have no other quests (because they have all been answered as for the example way, or because they are not activated). If another quest is unanswered for a way (this one for instance https://www.openstreetmap.org/way/862062530, it has an unsolved smoothness quest), the behaviour depends on the priority of that quest vs. the priority of the sidewalk and sidewalk surface quests. If that quest is higher priority and is answered first for the unsplit way, the issue occurs. If it is answered after splitting the way, the sidewalk surface quests appear as expected (no issue). If the other quest has lower priority than sidewalk+sidewalk surface, the issue always occurs.

[Helium314]

I would expect that in the general view, the sidewalk quest would appear, but it doesn't

There seems to be a separately mapped sidewalk nearby. In such situations the sidewalk quest is not applicable because it seems like a waste of users' time.

Answer the sidewalk surface quest that appears (for instance that both sides are paving stones)

That's indeed a very important omission, and makes the solution rather straightforward: Adjust (delete?) existing sidewalk surface when sidewalk tags are changed in overlay.

[rhhsm]

I would expect that in the general view, the sidewalk quest would appear, but it doesn't

There seems to be a separately mapped sidewalk nearby. In such situations the sidewalk quest is not applicable because it seems like a waste of users' time.

There a separate sidewalk only on one side, the sidewalk status in the other side is still unknown. Besides, way 862062530 doesn't have any separately mapped sidewalks, but the sidewalk quest doesn't appear in general view for that way either.

Answer the sidewalk surface quest that appears (for instance that both sides are paving stones)

That's indeed a very important omission, and makes the solution rather straightforward: Adjust (delete?) existing sidewalk surface when sidewalk tags are changed in overlay.

Sorry for that... Yes, sidewalk surface should be deleted for the 2 sections of the split way so sidewalk surface quest is asked again for both sections.

[Helium314]

Besides, way 862062530 doesn't have any separately mapped sidewalks, but the sidewalk quest doesn't appear in general view for that way either.

https://www.openstreetmap.org/way/1056791202 is aligned and parallel, thus it's not asked.

[rhhsm]

Besides, way 862062530 doesn't have any separately mapped sidewalks, but the sidewalk quest doesn't appear in general view for that way either.

https://www.openstreetmap.org/way/1056791202 is aligned and parallel, thus it's not asked.

That's quite a tough filter! :) It's such a tiny piece of path, but it results in a much longer road not being quested. Maybe a length comparison check could be done? I think a road should be excluded from the sidewalk quest only if there are parallel paths along it on both sides and of comparable length to the road. Or even ignore parallel paths unless they are tagged with footway=sidewalk.

[rhhsm]

Wondering why this way is not quested for sidewalks? https://www.openstreetmap.org/way/23147663

[Helium314]

If you're interested in details of such things I recommend you to build a debug version and add some logging into the relevant function. Then answer some quest for the element (or change it using an overlay) and check logs.

[Helium314]

Maybe a length comparison check could be done?

Should be possible, but there would need to be some additional processing as the sidewalk may be split into small segments, or go around a whole block. And with the sidewalk overlay being able to catch such situations, I doubt anyone would be willing to do the necessary work.

[rhhsm]

If you're interested in details of such things I recommend you to build a debug version

I would if I could, but it's been 20+ years ago since I last did anything like that (in Visual Basic...). I'm afraid all I can contribute here is my user experience ;)

[rhhsm]

If you're interested in details of such things I recommend you to build a debug version and add some logging into the relevant function. Then answer some quest for the element (or change it using an overlay) and check logs.

If I were capable of doing this, I would first try if ignoring nearby footways completely would result in an unacceptable number of roads that are quested that shouldn't be. If the number is indeed too high, then I would try if including only footways that are tagged as sidewalks (footway=sidewalk) in the filter would result in a too high number of falsely quested roads. Of course the number of falsely quested roads should be compared with the number of falsely not quested roads. Maybe some else with some time available could do this?

Wondering why this way is not quested for sidewalks? https://www.openstreetmap.org/way/23147663

I tried splitting the road in several sections and see for which section the sidewalk quest doesn't appear in the general view: it's the bit at the Eastern end. Apparently the footway at the end https://www.openstreetmap.org/way/499159632 triggers the filter, resulting in a perfectly ordinary residential road not being quested in general view.

[rhhsm]

Answer the sidewalk surface quest that appears (for instance that both sides are paving stones)

That's indeed a very important omission, and makes the solution rather straightforward: Adjust (delete?) existing sidewalk surface when sidewalk tags are changed in overlay.

This discussion went off topic (will probably post a separate issue for the too strict filter for sidewalk quest), so I'd like to repeat that

• for ways that have a sidewalk surface tag and that are changed through the sidewalk overlay (from sidewalk=both to sidewalk=left/right as well as from sidewalk=left/right to sidewalk=both), the sidewalk surface tag should be deleted so it's asked again for the new situation.

I hope someone will find some time to implement this (sorry I don't have the skills to do this myself).

[westnordost]

For reasons I do not remember clearly now, I once decided that when editing solely the cycleway:* tagged on the road, the app should not try to be smart and delete/update any "sub"-tags such as cycleway:left:surface etc.

For consistency, this decision should be valid for sidewalks, too.

It is also not trivial to remove these tags:

• The :surface or something else could have been tagged as :both before, so it would need to be expanded to both sides and then deleted from the side that now has no sidewalk
• When the tags are re-shuffled like above, it looks like in the change history that the user actually checked the surface on the other side, which he did not. Removing both sides for good measure on the other hand could be considered vandalism.
• especially for cycleway:*, the answer is not always clear whether it is correct to remove the current :surface, :color, :ref or what other subtags there may be. For sidewalk:* it may be clearer, but then again there is sidewalk=separate - which subtags should stay and which be deleted? I'd rather not get into that
• there may be other tags that should (sometimes) be removed when the sidewalk or cycleway tag changes in one way or another. I feel to start supporting some smart logic here is going to open a can of worms

In general, I recommend mapping sidewalks and cycle paths as separate ways if you want to record more than their mere existence because everything else will become increasingly complex and difficult, to maintain too.

[rhhsm]

I agree that it's risky to try to let the app make "smart" decisions about deleting information, and not trivial either (although @Helium314 stated that "the solution rather straightforward: Adjust (delete?) existing sidewalk surface when sidewalk tags are changed in overlay."). But I find it unsatisfactory that in this way, some information will be incomplete and never quested. Take this way, for instance https://www.openstreetmap.org/way/1122687307 where I changed sidewalk=right to sidewalk=both using the sidewalk overlay, but the sidewalk surface quest was not asked so only info on the right sidewalk surface is there. Would it be an option to change the sidewalk surface quest in such a way that not only roads without a sidewalk surface tag are quested, but also roads where there is a mismatch between sidewalk:x:surface= and sidewalk=y (y≠x)?

[mnalis]

I do agree with you @rhhsm that leaving behind known invalid data is not ideal solution. But I also understand @westnordost reluctance to determine how to detect and handle all corner cases.

I still think it would be good idea to try to handle at least most common cases (e.g. especially the ones that SC adds itself!):

• if overlay changed tag to sidewalk=left:
  • remove sidewalk:right:surface=* (if it exist)
  • change sidewalk:both:surface=* (if it exists) to sidewalk:left:surface=*
• if overlay changed tag to sidewalk=right
  • remove sidewalk:left:surface=* (if it exist)
  • change sidewalk:both:surface=* (if it exists) to sidewalk:right:surface=*
• if overlay changed tag to sidewalk=no
  • remove sidewalk:left:surface=* (if it exist)
  • remove sidewalk:right:surface=* (if it exist)
  • remove sidewalk:both:surface=* (if it exist)

I understand that it would not cure 100% of the possible situations, but it would handle most common of them in reasonable way. I could try to make PR for that if @westnordost thinks it would be acceptable?

Would it be an option to change the sidewalk surface quest in such a way that not only roads without a sidewalk surface tag are quested, but also roads where there is a mismatch between sidewalk:x:surface= and sidewalk=y (y≠x)?

That also might be a workable idea, which would not be considered "vandalism". It's however more complicated than just that (as it could be e.g. sidewalk=both + sidewalk:left:surface=asphalt + sidewalk:right:surface=paving_stones for example), so it might end up being more complex then removing only affected tags on update - I'd prefer method outlined above.

[westnordost]

Would it be an option to change the sidewalk surface quest in such a way that not only roads without a sidewalk surface tag are quested, but also roads where there is a mismatch between sidewalk:x:surface= and sidewalk=y (y≠x)?

Yes

[rhhsm]

Thanks! @mnalis the case that a sidewalk is added (sidewalk=right or sidewalk=left to sidewalk=both) should also be considered. I started this issue with an example where a sidewalk was removed, but the example yesterday is about a case where one sidewalk existed and another sidewalk was added. Adding one or two sidewalks where there was none does trigger the sidewalk surface quest, so it is not an issue.