Add a warning if surface does not match the tracktype from highway=track

[mcliquid]

Description

Driven by this discussion from StreetComplete, I would like to introduce my idea to other OSM editors.

Short: I noticed that quite often a surface=* is mapped to a highway=track which does not match the existing tracktype=*. In these cases the editor should give a warning. The goal should be that both entries correspond to reality.

For example:

• Warn if user wants to add surface=asphalt but tracktype=grade4 is already given
• Warn if user wants to add surface=gravel but tracktype=grade1 is already given
• Warn if user wants to add tracktype=grade1 but surface=gravel is already given

The warning should appear in the upload window in iD if the user has changed a highway=track in any way and the surface and tracktype values do not match.

Quite similar to when access=public is used, and iD then notes that this item is deprecated.

Here is a rough list of cases where this error should be triggered: highway = track AND surface = unpaved|gravel|fine_gravel|compacted|pebblestone|dirt|earth|grass|grass_paver|mud|sand|woodchips|snow|ice|salt|rock|ground AND tracktype=grade1

highway = track AND surface = paved|asphalt|asphalt:lanes|chipseal|concrete|concrete:lanes|concrete:plates|paving_stones|sett|unhewn_cobblestone|cobblestone|cobblestone:flattened|metal|wood|stepping_stones AND tracktype = grade2|grade3|grade4|grade5

Screenshots

No response

[jjiglesiasg]

I do agree with that. Good proposal.

BsRgds

JJ @ Bolivia

From: mcliquid @. Sent: Tuesday, May 31, 2022 7:56 AM To: openstreetmap/iD @.> Cc: Subscribed @.***> Subject: [openstreetmap/iD] Add a warning if surface does not match the tracktype from highway=track (Issue #9138)

Description

Driven by this discussion https://github.com/streetcomplete/StreetComplete/discussions/4063 from StreetComplete, I would like to introduce my idea to other OSM editors.

Short: I noticed that quite often a surface= is mapped to a highway=track which does not match the existing tracktype=. In these cases the editor should give a warning. The goal should be that both entries correspond to reality.

For example:

• Warn if user wants to add surface=asphalt but tracktype=grade4 is already given
• Warn if user wants to add surface=gravel but tracktype=grade1 is already given
• Warn if user wants to add tracktype=grade1 but surface=gravel is already given

The warning should appear in the upload window in iD if the user has changed a highway=track in any way and the surface and tracktype values do not match.

Quite similar to when access=public is used, and iD then notes that this item is deprecated.

Here is a rough list of cases where this error should be triggered: highway = track AND surface = unpaved|gravel|fine_gravel|compacted|pebblestone|dirt|earth|grass|grass_paver|mud|sand|woodchips|snow|ice|salt|rock|ground AND tracktype=grade1

highway = track AND surface = paved|asphalt|asphalt:lanes|chipseal|concrete|concrete:lanes|concrete:plates|paving_stones|sett|unhewn_cobblestone|cobblestone|cobblestone:flattened|metal|wood|stepping_stones AND tracktype = grade2|grade3|grade4|grade5

Screenshots

No response

— Reply to this email directly, view it on GitHub https://github.com/openstreetmap/iD/issues/9138 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AFOKQKW5ZKTDICKOW7EGSCTVMX463ANCNFSM5XNJ2DQQ . You are receiving this because you are subscribed to this thread. https://github.com/notifications/beacon/AFOKQKWUGR337MQKJZ37ZJ3VMX463A5CNFSM5XNJ2DQ2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4SV22MOA.gif Message ID: @. @.> >

http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient

Virus-free. http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient www.avg.com

[tordans]

That sounds like a good idea but more like something for a QA Tool. iD has three of the integrated already:

But I see you know this already … https://github.com/osm-fr/osmose-backend/issues/1468.

[mcliquid]

@tordans Are the warnings / notices on the left column in the editor also handled by the external validators?

I imagine the behavior pretty much the same like this:

[tordans]

Are the warnings / notices on the left column in the editor also handled by the external validators?

No, they are part of iD. The way they work is (AFAIK), they compare a set of tags against a recommended set of tags from the name suggestion index https://nsi.guide/. So this only works for things that are part of NSI.

There is also some basic tagging cleanup for deprecated tags in ID and/or in id-tagging-schema.

AFAIK none of the code does a check like you are proposing, yet.

[tordans]

Thinking about this, a good first step would be, to show a box similar to the one you screenshotted whenever a selected item has also an issue in one of the validators. It could say something like

There are validation warnings for this <Shop> in <ValidatorName>. [Open validator view…] [Learn more…]

This way, the validators and issues like yours would receive more visibility without being "too loud".

[mcliquid]

First, I would like to link to the same ticket for JOSM here: https://josm.openstreetmap.de/ticket/22102

No, they are part of iD. The way they work is (AFAIK), they compare a set of tags against a recommended set of tags from the name suggestion index https://nsi.guide/. So this only works for things that are part of NSI.

In fact, this only works if any values are somewhat similar in the NSI and can be expanded.

There is also some basic tagging cleanup for deprecated tags in ID and/or in id-tagging-schema.

Same here. Only if a very specific case is found, it can be added. Here would be the link to my Aerialway Station screenshot from above.

How or at which point is the check integrated that checks whether a path crosses a waterway?

I could imagine that the same logic as in JOSM could be applied here.

[matkoniecz]

That sounds like a good idea but more like something for a QA Tool. iD has three of the integrated already:

This checks are highly hidden, and this issue deserved a clear warning

Nevertheless adding this warning to this QA tools is also a good idea.

[1ec5]

Are the warnings / notices on the left column in the editor also handled by the external validators?

No, they are part of iD. The way they work is (AFAIK), they compare a set of tags against a recommended set of tags from the name suggestion index https://nsi.guide/. So this only works for things that are part of NSI.

Those NSI checks are implemented as validator rules, but other validator rules are possible independently of NSI. They live in this folder.

As you can see from the existing validator rules, iD’s built-in rules are much more conservative than QA tools or even other editors’ validators. They should be well-designed with the mapper in mind. iD is used by a lot of mappers who don’t have much experience with QA, so there’s always a risk that they’ll satisfy the warning without understanding the underlying issue, creating more work for people who are experienced with QA. Mappers care about satisfying these warnings because the number of ignored and resolved warnings is tagged on the changeset and tied to their permanent record via the How Did You Contribute? tool.

In this case, if the surface and tracktype values are blatantly contradictory and practically always wrong, then that would be a good argument for adding a validator rule with fix buttons that discard either tag or change either tag to a value you’re sure is more correct. The existing not:name validator is a good precedent: #6411.

However, the wiki’s tracktype definitions include a lot of weasel words and room for interpretation. If local communities are strict about how these tags are applied, they may not appreciate it if iD users who don’t understand those nuances start updating tracktype based on surface or the other way around.

[mnalis]

I'm guessing non-experienced users would more naturally "just know" the right definition of surface tag than of tracktype tag. I.e. choosing whether surface is asphalt, gravel or dirt is more simple and intuitive (and less prone to interpretation differences) than determining which of the relatively vague tracktype definitions describes the situation best.

So my vote for iD check in such situation (when user notices the warning and chooses to fix it) would be to remove conflicting tracktype tag completely as a way of fixing the issue. If user is more knowledgeable, they can then add correct (non-conflicting) tracktype themselves, and if not, another user (in iD or StreetComplete on the ground or other tool) can add it later.