Resurveing: Add double check when values change

[tordans]

I really like the re-surveing feature that SC introduced and spearheads. But I wonder if things can be done to reduce miss-tagging in some use cases.

Use case

I notice a few times that the bicycle stands capacity resurveing quest introduces wrong data.

An example is
https://osmcha.org/changesets/156286947/?aoi=3ee95214-1a8e-4a7e-8546-5c9c0ac2b006

• https://www.openstreetmap.org/node/6198207558/history
• https://www.mapillary.com/app/?z=18&lat=52.4981084&lng=13.4430488&panos=true&pKey=1162841444920351&focus=photo&x=0.6399965238078373&y=0.6882350835595245&zoom=0.664645508768157

But I noticed other times before that.

In my experience this quest is more likely to be miss-tagged during resurvey than others, but I cannot pinpoint this or think that it is relevant.

Proposed Solution

Last time I checked SC does not show the current data anywhere during the re-surveing.

My thinking is, that this should change in order to trigger a "who is wrong, me or the prev. mapper?" though in the current user, which will certainly improve the accuracy of the data.

I think this can be added in multiple ways which all have the dis/advantags. They are all OK IMO.

• pre fill the quest with the current answer
• make it a "is this value still right yes/change" answer
• show a confirmation after the new answer "this will change the value from A to B, does that look right? USE MINE | KEEP OLD | …(back)"

Personally I like the last case the most, because it does not change the current flow.

[RubenKelevra]

I didn't know SC had even a resurvey for capacity of bicycle stands.

Last time I checked SC does not show the current data anywhere during the re-surveing.

Ususally it does: It shows the current mapped details and asks if it's still correct. If you say no, you unlock that you map something new, otherwise a check_date is added, to map that it was reverified.

Here's an example for bicycle lanes:

Since I've never seen a quest to resurvey capacity of bicycle parking, so I can't be sure. But if it doesn't display what's mapped there, this should be changed and be like above.

[matkoniecz]

It does not display currently tagged info

[RubenKelevra]

I agree, it should do this beforehand.

[mnalis]

I can't find original post now, but AFAIR it was explained that it is intentional behaviour that bicycle parking count is not shown beforehand.

Reasoning was along the lines that for the resurvey to make any sense, the user must count the parking spots again. If the number was shown beforehand, that is very high likelyhood that many users (out of laziness & trusting the static universe model) would just confirm what was already there instead of counting, thus rendering resurvey quest worthless at best (or even more, actively problematic, as it would update old number with new check_date claims).

Thus, the first two suggestions should not be implemented, but something along the lines of a third one might:

show a confirmation after the new answer "this will change the value from A to B, does that look right? USE MINE | KEEP OLD | …(back)"

As suggested, it might still be problematic (users could just enter 0 and then choose KEEP OLD), even is somewhat less so (it would be more trying to actively game the system instead of just plain laziness/trustfulness).

But a variation that verifies old value to new one, and if they differ asks (without mentioning the old number) "It seems that the number of parking spaces here has changed, please double check your count. I DOUBLECHECKED, CONFIRM NEW COUNT | OOPS, I MISCOUNTED, LET ME REVISE THE NUMBER"

[RubenKelevra]

I think the default assumption that our users are lazy is odd. I mean how long does it count to 4 or to 20? That's a not a task where I think someone would skip this step.

This however may very well be a concern on parking lots for cars, where the number is say 254 or something like that.

In this case it's fine IMHO to show the number and ask for confirmation.

[matkoniecz]

From what I remember it was on pile of "big implementation effort given benefits, write PR if you want".

[mnalis]

TL;DR: see double-blind scientific methodology for reasoning why showing data first is bad idea for accuracy, and for counting task it does not gain us any convenience (as opposed to say opening_hours quest where it gives us a lot). Asking for confirmation after counting if results differ is fine, though (and probably a good idea).

---

I think the default assumption that our users are lazy is odd

I was trying to be short and simple (given my tendency to get overly long), but the whole known psychological issue is much more complex, and (beside "plain laziness", which is in itself probably quite complex) is resulting from observer bias, confirmation bias, and other factors; which is why in science such blinding is considered essential in order not to get biased/skewed/wrong data (recent standards requiring at least double blinding, and sometimes triple blinding)

Anyway, long story short, it is known and proven psychological deficiency of human brain. (it is probably intentional evolutionary tendency though: over-optimizing in order to save time and energy)

• In StreetComplete, we sometimes accept that risk for tasks with complex UI, when doing otherwise would be prohibitively expensive; e.g. for opening_hours resurvey, we accept just confirming it, because it is several orders of magnitude easier to verify two timetables (one on a door and other on a mobile phone) then to use SC UI to re-enter all opening hours values from scratch. So there, we give up a little accuracy to gain a lot of convenience, which is considered a good trade.

• However, for counting tasks, UI is already extremely simple (i.e. entering a single number) so basically nothing would be gained, while counting part (which must always be done) is the "hard part", and is very susceptible to biases mentioned above. Thus, we would be giving up significantly more accuracy for practically no gain at all (maybe a click or two saved). Thus, in that case it would not be a good trade.

Similar issues have been discussed previously (i.e. ideas for applying same "building type" to answer to multiple buildings is problematic not only for UI and implementation standpoint, but it also would invite not checking each building type but answering "surely all of them must be detached too" after one sees a dozens of them in a row. Or maxspeed quest being disabled by default, because checking it (especially whole areas for slow zones) is very demanding and thus likely to produce incorrect answers as most people would use "default" reasoning)

---

Thus, verifying the data matching only after it has already been counted (thus, without bias!) and entered is significantly better idea which produces more quality data for same amount of work.

e.g. "It seems that the number of parking spaces here has changed, please double check your count. I DOUBLECHECKED, CONFIRM NEW COUNT | OOPS, I MISCOUNTED, LET ME REVISE THE NUMBER"

[tordans]

Thanks for the context.

I was thinking about why some users make this mistake. When we assume the users know what they are doing (AKA how to count capacity ec) and are careful with their mapping, which I think we can, that leaves mistakes due to not understanding which object they are mapping or how the objects relate.

In Berlin, we have a very high level of details on the sidewalks and roads which means I needs to orient myself very well to match the digital map with what I see in the real word. SC map style is not ideal for this kind of situation (for good or at least understandable reasons).

There are a few factors that make the bicycle parking quest different from others…

• lanes are easier to "find"
• other objects are not clustered as much as bike parking nodes/areas

There are a few open tickets that would help here, like #56 and more details on the map which might be possible once the map design becomes easier to modify with maplibre.

For now, the easiest way to make it easier for users to understand which objects they are changing to see the data that is already there. Be it before or after they did their re-survey…

[matkoniecz]

see double-blind scientific methodology for reasoning why showing data first is bad idea for accuracy,

I expect it depends on ratio of wrong answers when capacity is not shown and how often people are incorrectly swayed by shown value.

I expect that it differs in various cases.

Do you have links to this research? Has it been replicated? (Any not replicated psychology research should be considered as not worth much if anything, see replication crisis)

and for counting task it does not gain us any convenience

Maybe a tiny bit as often you will not need keyboard

[matkoniecz]

I was thinking about why some users make this mistake

Do you have example mistakes? I seen one user who counted U-shaped stands interest of counting 2 capacity for each (and there was space on both sides), despite the hint

[tordans]

I was thinking about why some users make this mistake

Do you have example mistakes? I seen one user who counted U-shaped stands interest of counting 2 capacity for each (and there was space on both sides), despite the hint

I linked the most recent example in my initial post which is the area I linked in the comment you quoted. Other similar cases are already solved and I will not have the time to dig them up again.

[fxedel]

Another example of resurveying mistakes (it was my fault in case): https://osmcha.org/changesets/157167301?aoi=69f2fba4-6afb-4c5f-a89a-2a6538c9432a

In this case, I was resurveying (without knowing that it was a resurvey, I assumed I was surveying it the first time) a recycling container. We have large containers for "packaging waste" ("Verpackungsmüll"), which includes plastic packing and metal cans. However, since I always think of these containers as "plastic waste containers", I forgot to add metal cans. As a result, my changeset actually only removed cans. If SC had asked me "Are you sure that you removed metal cans?", I would have said "Oh no, my mistake, I forgot about them, thanks for double-checking".

I don't know if that's a common case, just wanted to add some user feedback :)

[RubenKelevra]

@fxedel yeah, I think we should at least show that the user is changing something, vs adding new data. And what the user is changing exactly, to catch those mistakes.

However in your case you also wouldn't have this mistake if that data would have been presented and you've asked to confirm it, this by the way is the default case in OSM: The editing user is presented with the existing data, and he/she can choose to make changes.

Not sure why we should differ from this in SC, still.

[westnordost]

Actually, I think we should review for which quests the question is asked again. What changed since their implementation?

1. There is now (since a long time) also the CheckExistence and CheckShopExistence quests, which do a better job at checking whether something is still there in its current form
2. There is now (since a long time) a label below the question, denoting the type of feature. E.g. "bicycle stands", "bicycle locker" etc.
3. There is now the things overlay

For the case of bicycle parking capacity, I do think that the bicycle parking capacity should probably not be asked again, because realistically, the parking capacity doesn't change for a bicycle parking.

I've never seen a bicycle parking being just extended (or reduced). Rather, instead, if the bicycle parking is redesigned, it may end up being at a (slightly) different position, have a different type (e.g. racks -> double-decker racks), etc., or be gone (at that location) altogether.
So, at least for bicycle parking, I think it is better to ask just for the existence, the label below the question will tell users what type of bicycle parking it is.

Other quests should be reviewed, too. But for most, nothing should change. E.g. roads usually can have their surface renewed (i.e. -> surface, smoothness quests) without the whole road vanishing and reappearing in a slightly different form or location :-)

[matkoniecz]

In my city it is normal for bicycle parkings to be expanded or run over, but maybe it is not true more generally

[westnordost]

What do you mean, "run over"?

[matkoniecz]

that part of bicycle parking was destroyed by a car that run over it

some also got lost after road was renovated

[RubenKelevra]

In my city it is normal for bicycle parkings to be expanded or run over, but maybe it is not true more generally

Same here, a hardware store just doubled the parking spots for bikes while also adding two outlets for charging. 3 years ago there were zero parking spots for bikes.

[westnordost]

Hm okay, I see. Well, I will review the other re-check quests anyway.

As per the original feature request, I would close this as will not fix.

Whatever was tagged before should not matter when the user decides what value he specifies, after all, he is there right now and sees with his own eyes the current situation. If any quest is worded in a way that it is confusing or answer options are not clear so that it leads to systematic incorrect answers, then the quest should be enhanced to not be confusing or ambiguous instead of burdening the user to doubt and/or compare his answer with a previous answer.

Such confirmation dialogs are usually mostly just annoying for users rather than helpful to achieve a better data quality. Also, both either implementing such a confirmation dialog or in some way or another showing the previously tagged value would need to be implemented for each form individually which would make this also quite time consuming to do and maintain, never mind the possible inconsistency when such a confirmation dialog is shown for one quest, but not another.

[matkoniecz]

Though for example for recycling quest I have faint plan to implement ability to show what is tagged with option to quickly confirm it.

No promises that I will implement it soon, I will first finish some of already started projects.

[westnordost]

Reviewed re-check quests. Just two remain where I am considering to remove the re-check:

• bicycle shop offers repairs: it's really whether it is that kind of shop. I doubt that a bike shop with repairs would stop offering it at one point or the other way round. Same with second hand bike availability ( by @matkoniecz )

• camp power, showers, drinking water: I'd also argue that it is rather defined by the kind of camping ground, (backcountry or not) i.e. unlikely to change (by @mnalis )

[RubenKelevra]

Reviewed re-check quests. Just two remain where I am considering to remove the re-check:

• bicycle shop offers repairs: it's really whether it is that kind of shop. I doubt that a bike shop with repairs would stop offering it at one point or the other way round. Same with second hand bike availability ( by @matkoniecz )
• camp power, showers, drinking water: I'd also argue that it is rather defined by the kind of camping ground, (backcountry or not) i.e. unlikely to change (by @mnalis )

Well, on the flipside it still improves accuracy of the data, if we check it every 6 years or so. So if people rely on them, it's good to make sure that they are accurate from time to time.

I would vote for rechecking them, much stuff can be change in 6 years.

[mnalis]

camp power, showers, drinking water: I'd also argue that it is rather defined by the kind of camping ground, (backcountry or not) i.e. unlikely to change (by @mnalis )

I would vote for rechecking them, much stuff can be change in 6 years.

Yeah, I see not much problem with leaving rechecking them, especially considering that they are rare enough not to present noticeable spam; and there are some uses for them.

While I agree that is somewhat unlikely that they degrade (e.g. camp offering drinking water suddenly stopping to do so), situation might occasionally improve (e.g. alpine hut that didn't have power might get solar panels installed, especially with all "renewable and energy independent" trends in EU and elsewhere. Or a smaller camp without showers might grow if there is enough business at the location and get showers outbuilding)

Additionally, those quests work as alternate "existence check" quest, so if recheck for (some of) those quests were to be removed, at least check for camp / alpine hut should be added to existence quest. (especially camps IME are known to close from time to time - more often than I'd like, in fact)

[westnordost]

Additionally, those quests work as alternate "existence check" quest, so if recheck for (some of) those quests were to be removed

This is a mute argument, my point is, that because we have the existence check, we don't need other quests to confirm their existence.

[mnalis]

my point is, that because we have the existence check, we don't need other quests to confirm

I know, that is why it was prefixed with "Additionally". The main argument for retaining status quo was above it:

• it does provide some benefit on its own, as situation may (admittedly rarely) improve (as given in examples)
• it does not make extra burden for the mapper by remaining where it is

That being said, if you think it would be noticeably better if recheck in those quests was replaced by moving it to existence quest, I won't throw a tantrum 😃, even if I do think currently solution might be slightly better

[westnordost]

Oh, you are right, camps are actually not checked in the check existence quest. Nevermind then.

Anyway, closing this as will not fix.

[HolgerJeromin]

Not followed the discussion in detail but

I doubt that a bike shop with repairs would stop [...]. Same with second hand bike availability

I know a shop which dropped selling second hand bikes.

[RubenKelevra]

Now as you're saying this indeed, I know a car dealer which also offered bicycle repairs and the service that you can give them your old bike if you buy a new one and if they sell it you'll get this as a discount later on.

But they stopped doing both of that, only offering new bike sales nowadays.