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

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 :)

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.

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.

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! ¹) 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 always²)
• 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.

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.

Am i allowed to this?

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)

Am i allowed to this?

So, @qugebert, are you still interested in working on Smoothness overlay (on which you've been assigned on your request some time ago)?

Argh sure, i just had some issue with a disappearing ok button on my last attempt and then somewhat lost sight about that.
I'll take another look at it next week and if I still can't get any further I'll at least get back to you with the current status, maybe someone has an idea what's wrong.

The OK button is not shown if the form is not complete, IIRC

Yeah i know, but i checked the isFormComplete etc functions, their returns etc. and it was fine.
I will have a look on it the next days.

Yeah i know, but i checked the isFormComplete etc functions, their returns etc. and it was fine.

@qugebert If you'd perhaps like to link a Draft PR, people might take a look and give you a hint?

I'm on it, currently I have at least a “simple” working version, which only handles smoothness without prefixes. I'll test a bit this afternoon. Do we want to treat it like the surface overlay, that both values are surveyed for segregated foot/bike? This would then be my next step.

Can we talk about the color scheme here? Unfortunately, I have little feeling for design considerations. Currently I have chosen rather random colors.

    /* TODO: Reconsider Colors */
    private val Smoothness.color get() = when (this) {
        Smoothness.EXCELLENT -> Color.BLUE
        Smoothness.GOOD -> Color.SKY
        Smoothness.INTERMEDIATE -> Color.CYAN
        Smoothness.BAD -> Color.AQUAMARINE
        Smoothness.VERY_BAD -> Color.TEAL
        Smoothness.HORRIBLE -> Color.ORANGE
        Smoothness.VERY_HORRIBLE -> Color.LIME
        Smoothness.IMPASSABLE -> Color.GRAY
        Smoothness.UNKNOWN -> Color.BLACK
    }

Suggestions from me

• excellent/good/intermediate -> green shades
• bad/very_bad -> organe shades
• horrible/very_horrible -> brown shades

Thanks for the link, @FloEdelmann

On the color palette, we have a sequence (good -> bad) here, so maybe we need a separate sequential color scheme, see

https://personal.sron.nl/~pault/#sec:sequential

But we have a few more constraints: Red must stand out, plus we cannot variate the brightness a lot, because the overlay colors must remain vibrant to distinguish them from the background map. So, in this regard, I think the current palette is pretty usable as a sequential palette.

I'd actually compress the palette even more and assign a few values the same color, because otherwise the whole coloring would just consist of blue-ish to cyan-ish colors, as just about 10% of tagged ways is worse than "bad"

Like this from top to bottom excellent, good, intermediate, bad, very bad, horrible + very horrible, impassable

By the way, since smoothness is a tag with well-defined values, any other values than the ones defined in the wiki can be treated as
INVALID (i.e., red color), no need to reserve black for that.

By the way, since smoothness is a tag with well-defined values, any other values than the ones defined in the wiki can be treated as INVALID

Maybe very_good could be treated shown like good or excellent? It's not in the wiki list, but I find it useful considering the strict description for excellent. I quite often tagged otherwise excellent ways as good, because the "As-new asphalt" wasn't fulfilled (it was nice and smooth, but clearly not as new).

Maybe very_good could be treated shown like good or excellent? It's not in the wiki list

it really should be first discussed (and accepted) outside SC issue tracker

To be on the safe side, I'll ask again here:
We treat smoothness like surface, so first of all we want a distinction in segregated footpaths and cycle paths here too, right? I.e. no “simple” survey of a common smoothness (as with lit etc.), right?
I wasn't sure whether the smoothness of segregated footpaths and cycle paths isn't usually identical (if they are being renovated, then both are being renovated at the same time), but on the other hand, it is particularly relevant for footpaths/cycle paths whether I can get through them easily with non-tired or poorly tired vehicles.
Then I would probably adopt part of the logic of the SurfaceOverlayForm in a new superclass and also use it for the SmoothnessOverlayForm.
Is this procedure okay?

Translated with DeepL.com (free version)

Yes, it would be nice to set smoothness of segregated paths separately: if the surface is not the same, then smoothness is quite likely to be different as well. Newly renovated asphalt is usually smoothness=excellent while new paving stones are usually smoothness=good and sett is hardly ever better than smoothness=intermediate.

As for the colours to be used, I think it's best to use colour similar to the surface overlay, with asphalt and excellent being the same shade of blue, paving_stones the same colour as good, and sett = intermediate. For the worst smoothness values some of the colours for unpaved surfaces could be used (gravel, ground, etc.). If we start using it and it turns out to be confusing that some colours are the same as in the surface overlay, I suppose it's not too difficult to change them?

Yes, it would be nice to set smoothness of segregated paths separately: if the surface is not the same, then smoothness is quite likely to be different as well.

How do you specify this in the OSM tags? If segregated=yes is set, the surface is specified separately with cycleway:surface and footway:surface. Both are currently used well over 100,000 times. In contrast, cycleway:smoothness is only used 2500 times and footway:smoothness only 260 times. I can't find any documentation on this in the wiki yet.

Do you know where that sharp increase since 2020 comes from? https://taginfo.openstreetmap.org/keys/footway:surface#chronology
Could it be because SC has strongly pushed usage since then?
According to https://github.com/streetcomplete/StreetComplete/commits/master/app/src/main/java/de/westnordost/streetcomplete/quests/surface/AddFootwayPartSurface.kt?after=09fdc4e728ddb5191d11ae8d7cb4c8ba05f12dce+34, SC started asking at the end of 2019.
Before that we were under 5k here too

In contrast, cycleway:smoothness is only used 2500 times and footway:smoothness only 260 times. I can't find any documentation on this in the wiki yet.

I don't think it needs to be documented. cycleway:smoothness is just a sub-category of smoothness where it is necessary to specify which part of a segregated path is described. So far, SC only asked for surface of segregated paths while asking for both surface and smoothness of non-segregated paths. That's why the numbers are like they are.

I guess that stub page at wiki is fine if anyone feels need to it.

(for example mentioning that StreetComplete contributed to much of its use is not self-evident even for people quite knowledgeable about OSM tagging)