Warning if road surface does not match the tracktype?

[mcliquid]

I keep observing in my region that StreetComplete users have added a surface=asphalt to a highway=track even though it was already attributed with a tracktype=grade3 or grade4.

Therefore I had the idea, if it would be possible to give a warning, if a user wants to select a surface, which does not match the existing tracktype.

For example:

• Warn if user selected surface=asphalt but is already tracktype=grade4 given
• Warn if user selected surface=gravel but is already tracktype=grade1 given

The warning could look like this:
Are you sure this is "%surface"?
Optional: "%tracktype" has already been defined here.

• Answer with yes: Delete the tracktype and then retrigger the tracktype quest.
• Answer with No: User can correct selection.

The effort for this is surely not trivial but maybe worth. An alternative would be to display only the surfaces that would fit the tracktype, but that would not be very user-friendly and also potentially fatal if the tracktype is already wrong.

I look forward to your feedback. Thank you for your work!

[matkoniecz]

Which part of data was wrong? Already present or what SC mapper added?

[mcliquid]

@matkoniecz Thank you for your quick reply, I appreciate. Short answer: The SC-mapper added wrong data.

Here's just one example: https://www.openstreetmap.org/way/135117589
It's a bit older, but the use case remains the same.

In reality (on the ground), here is a grade 3 farm track with two gravel lanes and grass in the middle. This can also be seen very well on the aerial photo (Bing uses SWISStopo from ~2019 here). The VoGIS aerial photo from late 2020 shows the same.

In this case, tracktype=grade3 was already present since 2011 and in 2017 surface=asphalt was tagged with SC, although this could not have been (even in 2017). I imply that the error message described above would have helped here.

[mcliquid]

I've marked the track (right one) and used the SWISStopo aerial image:

[matkoniecz]

The SC-mapper added wrong data.
Here's just one example: https://www.openstreetmap.org/way/135117589

In such case, why have you not removed this incorrect surface=asphalt tag, if you confirmed it to be invalid?

[mcliquid]

In such case, why have you not removed this incorrect surface=asphalt tag, if you confirmed it to be invalid?

@matkoniecz I could have done that and will probably continue to fix it manually. But why doesn't Streetcomplete warn in such a case, if the previous data obviously doesn't match the entered data?
Isn't it a very simple match check that should have triggered in this case and prevented the error?
Correct me if I'm wrong, but this would mean that SC doesn't care about the data their users create.

[matkoniecz]

this would mean that SC doesn't care about the data their users create

This is untrue. You can look through other reported issues and effort taken to avoid false data.

See for example #4056 #4021 #3639 #3718 #3734 #3833 #3978 #3813 for work on improving quality of data captured by SC after it turned out that it partially SC fault.

But no editor can prevent user from entering blatantly false data. If something is a gravel road and user answered that it is an asphalt road the neither iD nor JOSM nor Vespucci nor GoMap!! would be able to help.

And if someone managed to confuse gravel road with asphalt road then showing tracktype would not help.

If you had more recent example then I would definitely ask on changeset comment what went wrong here.

I suspect that it is an actually asphalt and aerial is outdated or user knowingly entered false data or user misused StreetComplete and mapped without surveying (I guess that is argument for #4017).

But why doesn't Streetcomplete warn in such a case, if the previous data obviously doesn't match the entered data?

It is actually on my list of ideas to have quest triggered in case of such mismatch. But if SC user enters false data then it would just result in removal of valid tracktype

Isn't it a very simple match check that should have triggered in this case and prevented the error?

check is easy - setting up interface to display it well, testing code, review of code would take few hours in total.

For example 77b9fda with trivial (once you know where to place it) code and no new interface elements took me 70 minutes to implement.

I have a really enormous list of possible improvements to StreetComplete, and it is repeated case of deciding on what to work.

Do you have some more recent examples where asking user is more likely to help? I am really confused why someone managed to tag gravel as asphalt.

[mcliquid]

But no editor can prevent user from entering blatantly false data. If something is a gravel road and user answered that it is an asphalt road the neither iD nor JOSM nor Vespucci nor GoMap!! would be able to help.

And if someone managed to confuse gravel road with asphalt road then showing tracktype would not help.

In this case, it would be an intentional entry of misinformation and not an accident. No one can prevent an abusive entry, an oversight could be prevented by a warning.

If you had more recent example then I would definitely ask on changeset comment what went wrong here.

I have actually already done it with this one person, because it seems to be a pattern here. But there are other such cases worldwide, which can be found with an overpass query and some research. For very many of the tracks in the linked overpass, the last CS comment is "Add road surface". Unfortunately Overpass cannot filter on "created_by", then it would be even easier to provide a basic number of false records.

I suspect that it is an actually asphalt and aerial is outdated or user knowingly entered false data or user misused StreetComplete and mapped without surveying (I guess that is argument for #4017).

Yes that would be obvious, but it is actually a grade3. On my attached photo you are the track left below and you can clearly see the surface of gravel and a green strip in the middle. The photo is two weeks old and still matches the aerial photo. (It's not the best photo to show, but it was also recorded with another reason.)

It is actually on my list of ideas to have quest triggered in case of such mismatch. But if SC user enters false data then it would just result in removal of valid tracktype

That is definitely true. But if a user were to get a warning at this point, it would be negligent vandalism of the data. None of us can prevent that.

I have a really enormous list of possible improvements to StreetComplete, and it is repeated case of deciding on what to work.

I totally understand and I am really very grateful for your work here. The time investment that you and the other contributors volunteer is not to be underestimated and I always try to elaborate how grateful I am for that. I just want to offer my contribution here to optimize the app, but I always have the feeling that this is not wanted. At least in the tone that prevails here.

Do you have some more recent examples where asking user is more likely to help? I am really confused why someone managed to tag gravel as asphalt.

It can always happen that you clicked on something too quickly and then don't change it back. Exactly then a warning would be useful. If the tracktype is really outdated and the interface has changed in the meantime, then a warning and deletion of tracktype would lead to the correction of the data. But if someone really intends to place a Wrong value simply nothing more helps.

Another approach would still be to give only the appropriate surfaces to choose from and then urge the user to comment with a picture rather than delete existing data.

[10992-osm]

Here, it seems possible the the user could have confused one way with another, since the photo is taken from the vantage point of an asphalt way.

[mcliquid]

Here, it seems possible the the user could have confused one way with another, since the photo is taken from the vantage point of an asphalt way.

(Just to clarify: The photo is from myself. And we are only talking about this one single case. There are numerous others. )
Of course, this could be possible, but for one the GPS of the user would have been very bad, because the two paths have a distance of 20 meters to each other. And the selected path is also very clearly marked in red in SC.
Nevertheless, a check and warning as described at the beginning would have helped in this case of confusion from my point of view.

[mnalis]

I basically see three possible reasons:

• one-time mistake by user (e.g. "fat fingers", momentarily distraction / wrong orientation / GPS error, etc).
• consistent honest mistake by same user (might indicate bigger problems, like not using SC while Surveying but instead using aerial imagery)
• consistent intentional errors (e.g. gamification taken too far, deliberate vandalism, etc.)

Warning the user (and forcing answer) would help with first case, and probably some (but not all) instances of second. It would not of course help against third case. Modifying list of answers depending on tracktype is another option with perhaps better results.

However another alternative is not changing anything in StreetComplete, but implementing such check (if not existing already? Would you be interested to check, @mcliquid ?) in some of the Validators / QA Tools. It that way, all three instances can be detected, much more context seen (e.g. other error in that area by same user or others), user contacted via changelog discussion / email, and appropriate action taken depending on the result.

Also, second class of problem would benefit greatly is user is mistakenly orienting map wrong or something, and is contacted about that -- if they are repeatedly answering that quest wrong, they might be answering other quests (where we don't have extra tags to verify against) wrong too!

[mcliquid]

Thanks i've found it! See https://josm.openstreetmap.de/browser/josm/trunk/resources/data/validator/combinations.mapcss#L328

But will it only trigger if grade1 exists with unpaved or grade2 with sand or mud? I can't find anything with grade3 to grade5 and sealed surfaces. Can this be?

[mcliquid]

They get checked when you press upload.

I have all enabled and created a highway=track with surface=asphalt and tracktype=grade4. JOSM would let me upload that without any problems. Not even with highway=track, surface=asphalt and tracktype=grade5 an error appears. Only with highway=track, surface=sand and tracktype=grade1 an error occurs.

[matkoniecz]

But will it only trigger if grade1 exists with unpaved or grade2 with sand or mud?

yes

I can't find anything with grade3 to grade5 and sealed surfaces. Can this be?

this may be worth proposing to JOSM authors to warn on also this (via Help -> Report bug on latest JOSM version) if this is always wrong

[matkoniecz]

I've added these two issues to iD-Editor and Osmose-Analyzer:
openstreetmap/iD#9138
osm-fr/osmose-backend#1468

https://josm.openstreetmap.de/ticket/22102 now also exists

Discussion around this rules will be also useful to tweak selection of targets in SC

[matkoniecz]

https://josm.openstreetmap.de/ticket/22102 was merged as r18527

https://josm.openstreetmap.de/ticket/22102#comment:13

[mcliquid]

I have thought about this again and made a few investigations, since I consider the topic as important especially in relation to bicycle navigation. (At least for me as a road cyclist)

@mnalis I agree completely with your list above. A warning in StreetComplete would resolve your first two cases. Deliberately entering the incorrect information can't affect any assistance in the world.

At this point I would like to split the topic, as we should distinguish into what we could do about preventing future errors and what we could do about existing "errors".

Part 1: (Try to) prevent wrong entries in future
This would be done by a warning if the surface given by the user does not match the tracktype or the other way around. Depending on what was already there.
Maybe a reduction of choices is best as well as then offering the option like in the smoothness quest "Is other surface" or "Is other tracktype" as another option.

Example:
A dirt road is already tagged with surface=asphalt but has no tracktype yet. Then show in the tracktype quest selection only "paved" (grade1) and . Under "Other answers" then "Other surface" appears. I have built this very quickly as a mockup: warning_mockup.png

After all, it may be that the condition of the path has changed over time. That seems to be the case with this path here: https://www.openstreetmap.org/way/35816420/history
It used to be a gravel path with grade2 in 2014. Today (since 2021) it is asphalted. But the grade2 has remained.
Maybe it would already help to show the already existing value again explicitly in the quest. As seen in my mockup. Then the user should only have the possibility to change the existing value again in the app.

Part 2: Clean up already existing errors in OSM by SC through Resurvey.
Since the topic kept bothering me, I made an overpass query that outputs all cases where the tracktype does not match the surface (according to wiki rules). (highway=track only)
In my research I found out that in Baden-Württemberg 6864 agricultural roads are not correctly attributed. In Bavaria there are 7875. So about 15,000 cases only in southernmost Germany.
This includes all tracks that are tagged like these:

• highway = track, surface = asphalt, tracktype = grade3
• highway = track, surface = pebblestone, tracktype = grade1
• highway = track, surface = wood, tracktype = grade2

Of course, this could be made into a MapRoulette challenge, but the difference between grade1 and grade2 is rarely seen in aerial photos. Also a warning in Osmose or JOSM or KeepRight would help only conditionally, if the differences are extreme like for example surface=grass + tracktype=grade1.
Therefore, from my point of view, it would be a good idea to do a resurvey using StreetComplete.
Both quests (Tracktype + Surface) would have to be triggered again for the recognized tracks.

I look forward to hearing your opinions on this.

[mcliquid]

Good point. I looked at the proposal at the time as well as the discussion page for tracktype and learned from that that the tracktype or more specifically the "grade" stands for the physical, structural condition of the track.
As far as I understand it, a grade1 is always a sealed, concreted and paved surface. I don't know if the translation fits, but in german we would say "water closed surface" or something like that. In my understanding, an asphalt surface which is so destroyed that one would assume grade3 would be neither surface=asphalt anymore nor "tracktype=grade1". So rather something like tracktype=grade3 and surface=mixed.
I mean also the blog entry of Chris shows some problems in this regard. But from my point of view, there will always be edge cases that we can't all take into account, but which are rare.

[matkoniecz]

The problem with such quest (that I actually have on my to-do list) that it should be allowed to trigger only in cases which are always wrong, in every single case.

[mcliquid]

Yes I understand. I'm very glad it's on your list, because I think it would be a big improvement for data quality for routing software.

Maybe it would be a first step to take only combinations that make 100% no sense.
From my point of view that would be primarily everything with surface=gravel and tracktype=grade2-grade5.
I just can't imagine that there can be a grade1 with gravel, therefore I assume it's in every single case not correct.

Combinations with surface=sett are also clear according to the wiki, but maybe not clear enough for users. These could be added later, according to the motto iterative work.

[mnalis]

I like part1 with only showing eligible surfaces for that tracktype (and option to mark tracktype wrong).

Regarding already mapped elements (part2), I agree it is most reliable to verify that on the ground. Note that we also have smoothness=* (surface quality) quest in SC, which might make (when solved) some of those elements clearly wrong and thus eligible for resurvey. (e.g. surface=asphalt + tracktype=grade3 + smoothness=excellent). It would need the users that manually enabled surface quality quests, but if they're mapping for cycling (like I do too) I guess that they would want to solve that quest anyway.

[mcliquid]

To further verify the problem for myself I tried a few bike routers (brouter, ORS, Komoot and Graphhopper). All of them avoid a highway=track, surface=asphalt, tracktype=grade2, although in reality this is a grade1. So the correctness of the data would be a great added value and the fix by StreetComplete a greater one :)

[mcliquid]

I have a suggestion on this topic, which could possibly be implemented with a little less effort.

Here's the scenario: There is a way with highway=track, tracktype=grade1 and surface=gravel entered in OSM:
In reality we assume it is highway=track, tracktype=grade2 and surface=gravel.

Already now the tracktype-quest is displayed in StreetComplete as a re-survey.
If now the same value is set again, a check_date:tracktype is set by SC. If something other than the existing tagging is selected, only the tracktype will be adjusted.
Suggestion 1: Always set the check_date:tracktype when a quest is re-surveyed no matter which values are set.
Suggestion 2: Show the already set surface in the quest description. See attachment 1.
Suggestion 3: The resurvey should additionally be expanded to include more cases. With the combination surface = dirt and tracktype = grade2 this is not executed yet for example.

If now surface does not match tracktype, then show the surface quest again (too), but only with the surfaces that match the tracktype selected just before. This is not happening at the moment.
In addition, show the tracktype in the surface quest (as well as the surface in the tracktype quest) and set a check_date:surface.
See attachment 2.

Last but not least, show the current surface also in the smoothness quest description to make it more clear. See attachment 3.

[mcliquid]

One more addition that is not yet fully thought out: Maybe SC could trigger a quest if the combination of tracktype, surface and smoothness does not match. This would be the case if tracktype=grade2, surface=asphalt and smoothness=excellent|good occurs on a highway=track.

[matkoniecz]

#4105

[mcliquid]

I know that your implementation will be a great added value in the face of the technical possibilities. I'm super happy with it!

In fact, I have already thought about learning programming to contribute to SC, but until I can do it as well as you, it will take a long time - if ever :)

[Helium314]

In fact, I have already thought about learning programming to contribute to SC, but until I can do it as well as you, it will take a long time - if ever :)

Just give it a try!
SC also was my start into Java / Kotlin / Android programming in general a few years ago, and you can put it to good use in other places / apps as well.

[matkoniecz]

SC also was my start into Java / Kotlin / Android programming in general a few years ago

But you had some programming experience already, right? SC or Android app may not be an optimal very first project due to noticeable complexity of setting up everything. (though that is not a reason to not try at all! Just mentioning this so you will not be discouraged if SC will be overwhelming if you try it too early)

BTW, https://github.com/streetcomplete/StreetComplete/blob/master/CONTRIBUTING_A_NEW_QUEST.md may be useful

[Helium314]

But you had some programming experience already, right?

Some very basic C/C++ course a long ago, and some more experience with Matlab scripts. Definitely nothing nearly as complex as even a simple Android app.
Initially it took a very long time to find where the things I wanted to change are actually located in the code.

BTW, https://github.com/streetcomplete/StreetComplete/blob/master/CONTRIBUTING_A_NEW_QUEST.md may be useful

Definitely, starting with the hints for looking around would have saved me a lot of time.

[matkoniecz]

Oh, and for

Yes, I initially tried showing current tracktype and surface and ask user to select correct one, but it turned out to be both not easily done due to technical reasons (no access to tags while building form) and too confusing, so switched to what is seen in #4105

I found mockup (this has not actually worked, as form has no access to tags while being constructed - though this likely can be changed). But this form of quest was too confusing anyway.