Solving some track related quests can leave inconsistent data behind

[cyclingcat]

Hi there,

some weeks ago I came across a situation where solving some simple quests turn consistent tagging into an inconsistent tag combination.

Consider the following situation: An unpaved agricultural track, tagged consistently with

highway=track
surface=compacted
tracktype=grade2

The smoothness quest popped up. However, this track has obviously been asphalted recently, so I answered with "Other surface" from the Äh... menu.

Now the surface quest popped up, which I answered with "Asphalt".

Now the smoothness popped up again, which I answered with "Excellent".

No further quests popped up, leaving the tagging as

highway=track
surface=asphalt
smoothness=excellent
tracktype=grade2

Which is a contradiction - I cannot imagine any case where this combination could be valid - tracks with "excellent" asphalt will always be "grade1" (see the wiki).

Is there anything that could be improved here?

Ideas:

IF (highway="track" // or "path" or similar
    AND surface was changed from anything to "asphalt" // or "concrete" or "paving stones" or similar
    AND tracktype != "grade1") {
        delete tracktype
}

(SC users with activated "tracktype" quest would be able to correct this immediately, otherwise at least the now wrong "tracktype" tag would be deleted.)

Or maybe even better:

IF (highway="track"
    AND surface="asphalt"
    AND smoothness was changed from anything to "excellent"
    AND tracktype exists) {
        set tracktype to "grade1"
}

(which changes the tracktype to the only correct value but does not silently create this tag; if the latter is no problem then the last AND clause can be of course omitted.)

Observed with SC v58.

The cycling cat

[matkoniecz]

See #5236 #5650 #5133 #1909 #662

[cyclingcat]

Yes, there are some similar issues (one of them I opened myself 7 years ago 😆)

This issue, however, is not about some kind of "maintenance quest" or contradicting inputs of a user or an endless loop or correcting former mistagging. It's about turning 100% valid (but outdated) tagging into 100% contradicting tagging just by answering some SC quests. (The SC user won't have a clue that his correct answers will leave contradicting tags behind!)

To be fair, I have missed #5236, but that issue also doesn't mention the smoothness tag which is the essential point here because it ensures that tracktype=grade1 will be the correct value, without any doubts or edge cases.

The cycling cat

[westnordost]

Regarding idea 1, as far as I remember, it was determined that some asphalted tracks could be grade2 and hence it should not be seen as an unconditional conflict.

smoothness on the other hand is not considered or changed at all currently.

Rather than building even more logic into this tracktype-surface-conflict-detection (and then it would need to be tracktype-surface-smoothness-conflict-detection), I think the easy solution would be to remove smoothness whenever surface is removed, as the former is somewhat dependent on the latter (at least in StreetComplete interface). Would this solve the issue?

[cyclingcat]

Regarding idea 1, as far as I remember, it was determined that some asphalted tracks could be grade2 and hence it should not be seen as an unconditional conflict.

Generally spoken yes, but here we have the additional information "'smoothness' has just been set to 'excellent'" which contradicts tracktype=grade2 in 100% of all cases. This is the substantial difference to the former discussions.

I think the easy solution would be to remove smoothness whenever surface is removed, as the former is somewhat dependent on the latter (at least in StreetComplete interface). Would this solve the issue?

It wouldn't, because tracktype would still be untouched. The smoothness quest would pop up again (if the user had activated it), the user will answer it with "excellent", leaving still the (now definitely wrong) tag tracktype=grade2 behind. So I'd still suggest to either remove "tracktype" in this special case [*] or even set it to "grade1".

(Nevertheless also removing smoothness whenever surface is IMHO also a good idea because of the dependency you mentioned.)

[*] This case may sound special, but it's not that uncommon. Many unpaved agricultural tracks are being paved at some time, e. g. while preparing it for a (touristic or other) cycleway. In these cases the chances are very high that the freshly paved surface will be of "excellent" smoothness, but because the chance is not 100% I don't propose setting smoothness=excellent here but just removing/setting "tracktype" if and only if smoothness=excellent will be set on a paved track (via the smoothness quest).

The cycling cat

[westnordost]

Hmm, right. So what smoothness values would you say definitely conflict with which tracktype values?

[mnalis]

Many unpaved agricultural tracks are being paved at some time, e. g. while preparing it for a (touristic or other) cycleway

I agree such changes happen relatively often, but I wonder if we shouldn't just unconditionally remove tracktype (along with smoothness) when user indicates that surface has changed, so the users would be re-asked both of them.

After all, when surface changes, it is highly likely that tracktype and smoothness have also changed (yes, they could've remained the same, but that is by accident, not by design, so should be re-verified anyway even if happened to remain the same on the ground).

[cyclingcat]

Hmm, right. So what smoothness values would you say definitely conflict with which tracktype values?

I'd say:

• smoothness=excellent (in SC only applicable to surface=asphalt/concrete/paving stones/paved!) conflicts with any tracktype other than grade1 with no exceptions. This is the main topic of this issue. The tracktype could even be set safely to grade1 if smoothness is "upgraded" to excellent via the corresponding SC quest.

• For smoothness=good it's similar but not identical: Any track with surface=asphalt/concrete/paving stones/paved and smoothness=good can get tracktype=grade1 automatically as well. However, smoothness=good is offered as an answer also to e. g. surface=compacted, which is a candidate for tracktype=grade2, so any automatism that sets tracktype=grade1 when smoothness is "upgraded" to good should only work for the above mentioned surfaces.

For other combinations the correlation between smoothness ("softness") and tracktype is too weak for implementing some automagical decisions IMHO.

The often mentioned edge case of deteriorated paved tracks which should not get tracktype=grade1 doesn't apply here. (The wiki article mentions "heavily degraded and crumbled roads which was paved in past" as possible candidates for tracktype=grade2, but exactly this case will be excluded thanks to the freshly surveyed smoothness=excellent/good).

If you feel uncomfortable with setting tracktype=grade1 although it hasn't been explicitly asked, simply delete tracktype in these cases and let the user decide what to do with an asphalted track with excellent smoothness. (This would be 100% spammy though...)

Or follow @mnalis' suggestion above with its much broader scope than mine.

Or even combine both approaches (= set tracktype=grade1 in the cases mentioned above, delete tracktype and smoothness in all other cases if surface changes).

The cycling cat

[westnordost]

(Nevertheless also removing smoothness whenever surface is IMHO also a good idea because of the dependency you mentioned.)

Oh, actually, this is already done. See SurfaceCreator.kt line 28.

So, I like @mnalis suggestion because otherwise to conditionally remove it, checks would need to be added both in any quest / overlay that changes the surface and also any quest / overlay that modifies the smoothness.