Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Smoothness overlay #5486

Open
5 tasks done
michalgwo opened this issue Feb 13, 2024 · 8 comments
Open
5 tasks done

Smoothness overlay #5486

michalgwo opened this issue Feb 13, 2024 · 8 comments
Assignees
Labels
new quest accepted new quest proposal (if marked as blocked, it may require upstream work first)

Comments

@michalgwo
Copy link
Contributor

General

Affected tag(s) to be modified/added: smoothness
Question asked: What’s the surface quality here?

We already have a quest asking for highway smoothness, so why not make it an overlay?

Checklist

Checklist for quest suggestions (see guidelines):

  • 🚧 To be added tag is established and has a useful purpose
  • 🤔 Any answer the user can give must have an equivalent tagging (Quest should not reappear to other users when solved by one)
  • 🐿️ Easily answerable by any pedestrian from the outside but a survey is necessary
  • 💤 Not an overwhelming percentage of quests have the same answer (No spam)
  • 🕓 Applies to a reasonable number of map data (Worth the effort)
@westnordost
Copy link
Member

That makes sense, actually, the quest should be replaced by an overlay.

@westnordost westnordost added new quest accepted new quest proposal (if marked as blocked, it may require upstream work first) and removed enhancement labels Feb 13, 2024
@rhhsm
Copy link

rhhsm commented Feb 14, 2024

That makes sense, actually, the quest should be replaced by an overlay.

This would enable comparison between highways to be tagged and ones already tagged, which might lead some mappers to be tempted to highlight differences ("this road is worse than that one") while both sections actually fall within the same category (this road is at the bad end of intermediate and that one is at the good end of intermediate). I have my doubts if that is a good thing.

Anyway, for an impression of what such an overlay may look like, see here http://www.roads-bg.eu/#13/42.6721/23.3336 (green=excellent or good, orange=intermediate, red=bad, dark red=very_bad, only motor traffic roads are shown). It also shows my main area of SC survey activity :)

@matkoniecz
Copy link
Member

This would enable comparison between highways to be tagged and ones already tagged, which might lead some mappers to be tempted to highlight differences ("this road is worse than that one") while both sections actually fall within the same category (this road is at the bad end of intermediate and that one is at the good end of intermediate). I have my doubts if that is a good thing.

It would also encourage greater consistency, at least at local scale and make easier to spot already present wrong data.

@rhhsm
Copy link

rhhsm commented Feb 14, 2024

It would also encourage greater consistency, at least at local scale and make easier to spot already present wrong data.

Yes, that's true: I already used ivanatora's website above to find wrong data. The advantages of a smoothness overlay are probably bigger than the disadvantage I sketched above.

@mnalis
Copy link
Member

mnalis commented Feb 17, 2024

That makes sense, actually, the quest should be replaced by an overlay.

While I'd like to have smoothness overlay and would use it sometimes, I must note that I quite dislike the trend of removing quests in favor or overlays. I even (mostly) agree that the quest should be auto-disabled when overlay is active, and understand that "less duplication of similar code, the better" as a general rule, but not when it comes at heavy price for usability. I'd certainly use smoothness overlay much less than smoothness quest.

I must say I personally (even as an quite advanced user! 1) in vast majority of cases much prefer simpler Quest-based StreetComplete instead of using Overlays.

While overlays are sometimes indeed very nice and useful, there are huge problems associated with them:

  • even with recent improvements for easier (two-click) changing of overlay, it is still extremely taxing if one needs to use more than one overlay. Even in SCEE (which offers one-click changing of overlays) using Overlays is enormously more cumbersome than using Quests (when more than one overlay is wanted - which is very often, if not always2)
  • number of overlays is growing, and will likely continue to do so. That would likely result in switching overlays even more complex in the future (i.e. certainly not much simpler)
  • I know the default answer "But you are only supposed to use one overlay, instead of switching them all the time, you are using them wrong", but I disagree.
    Even if one is fachidiot who only cares about single specific issue and nothing else (like I might be for bicycle-related infrastructure, for example), using one overlay simply does not cut it.
    For example, if I care about suitability of the driving bicycle on the road, but that includes (at the very least) surface overlay, smoothness overlay, track_type overlay, cycleway overlay and probably a few more (lit overlay, sidewalks overlay). It is very usable and enjoyable using quests to solve that. But if the quests are deleted and I have to switch through several overlays every few dozen meters, it would be a nightmare (for hopefully obvious reasons)
  • I find the idea that e.g. "there are many users who care about smoothness but not surface" very unconvincing.
    While merging several very related overlays (e.g. surface+smoothness+tracktype) into one gargantuan overlay would help with "constantly switching overlays" problem, it would significantly impact view-map usability (e.g. even if one could combine colors+line shapes+outlines to represent multiple aspects, it would be very hard to read -- I know, as I use such setup in OsmAnd to display surface+smoothness+lit+access all at the same time in some profiles)

TL;DR: Please don't remove smoothness quest. And generally, please let's not throw away Quest model (which made SC popular) in favor of (much less usable, IMHO) Overlay model.

Footnotes

  1. less-advanced / beginner people that I know who use StreetComplete don't touch overlays at all.

  2. In my experience, for way-based overlays, one basically always want more then one Overlay, even if mapping very specific things. (POI-based Overlays, on the other hands, might have use case for one-Overlay-only use; e.g. if one only care about addresses).

@rhhsm
Copy link

rhhsm commented Feb 21, 2024

I agree with @mnalis : I mostly rely on quests to contribute with SC, and use overlays mostly to add information to the map that I can't add with quests. This includes surface, lighting and sidewalks of service roads (I think users will be interested in these for parking aisles, service roads that may be used by pedestrians, etc.), missing shops, and occasionally for adding street parking and addresses for buildings that should have one but that are of unclear exact status (single or multi family residences).
A new smoothness overlay will be useful to get an overview of an area and to correct mistakes, but should not replace the smoothness quest, I think.

@qugebert
Copy link
Contributor

Am i allowed to this?

@mnalis
Copy link
Member

mnalis commented May 23, 2024

Am i allowed to this?

I don't think there was any opposition to writing the Smoothness overlay (to the contrary, it seems we'd all like that, just don't want Smothness Quest to go away as a result), and the issue is tagged as "new quest - accepted new quest proposal (if marked as blocked, it may require upstream work first)" and you have been assigned @qugebert and nobody complained, so I would say you're welcome!

(It might be good idea to open "Draft PR" mentioning it fixes this issue, so link is established and people can follow progress)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new quest accepted new quest proposal (if marked as blocked, it may require upstream work first)
Projects
None yet
Development

No branches or pull requests

6 participants