An idea to avoid wrong tags after splitting ways following tracktype/surface quests

[cyclingcat]

Hi there,

the following idea is something I want to discuss first before I open an issue - maybe it's undesirable or complete bullshit...

Consider an agricultural track, tagged with highway=track, surface=*, but no tracktype tag. For a way like this SC will show the "tracktype" quest. Now assume that the user has to split this way in order to solve the quest because the tracktype changes along the track. Subsequently SC will create two tracktype quests which the user will now solve.

Afterwards the chance is very high that one of the split parts will contain a wrong surface tag! (Different tracktypes are highly correlated to different surfaces.)

One could argue: "If this case occurs, the tagging was wrong already before, so SC doesn't worsen anything. Fixing this is a case for QA tools like Osmose and out of scope for SC". On the other hand there is a SC user on-site with his smartphone in his hand who would be able to fix this immediately.

So my idea would be to delete the surface tag for both ways if a way was split because of a "tracktype" quest! Most certainly this deletes one wrong tag and possibly one correct tag, but SC would immediately show the "tracktype" quest afterwards, so the on-site user will be able to answer it correctly. And if he won't, other SC users will get these quests.

(Of course you could swap "surface" and "tracktype" here, the situation is symmetric.)

Does this sound sensible?

The cycling cat

[matkoniecz]

Main failure mode is: user answer surface, splits track, gets surface question AGAIN.

(for surface=gravel/ground/dirt it may be reasonable to have different tracktype values)

[mnalis]

perhaps surface quest on highway=track might be made dependent on first answering tracktype quest to avoid that issue? (But I'm not sure added complexity is worth it)

[cyclingcat]

Sure, changing surface tags will often lead to changing tracktype values, but the other way round the chance is even higher: If the tracktype changes, you can be 99% sure that the surface changes as well. My idea is to make the user correct the tagging immediately after his split while he is still on-site. (In particular for remote locations it could take a long while until the next mapper will correct this, with or without SC.)

Don't know about the implementation effort though, but deleting a tag doesn't sound too complicated to me (from my naive point of view, maybe there are side effects I'm currently not aware of).

The cycling cat

[mnalis]

I wouldn't agree on 99% figure, unless we are talking strictly of changing grade1 to grade5. For example, I quite often see grade5 become grade4, while still being surface=dirt.

The problematic issue as I see it is when we remove a tag we are effectively destroying information that someone put effort into entering, which is bad, especially as there is no guarantee that the mapper will answer the following quest.

Now if SC architecture allows marking data as stale instead of removing it (so ask the surface quest on new segment, and if the user answers it soon, then use new value, and if not, reuse old value), that might be passable. Maybe keep old value and use check_date or similar tag to indicate it needs to be resurveyed?

Even safer would be to forbid uploading of the split and answers for tracktype and surface unless both tags for both segments have been answered, but that sounds much more complex.