Is it possible to customize the validators in iD to what the individual country community consider best practices?
E.g., in Norway you are spammed with adding bicycle=designated on cycleways that have foot=designated, which makes it hard to discover the real issues that should be fixed. There’s no plan to remove it on global level
The validator warning occurs because the combination of highway=cycleway foot=designated looks similar to the tags for the Cycle & Foot Path preset, which has those two tags plus bicycle=designated.
A few years ago, the French community had this preset suppressed within France, with the idea that mappers there should apply highway=path instead of highway=cycleway. This caused some user confusion because a path-based preset was never added as a replacement in France. If the local community is sure that highway=cycleway normally should not have bicycle=designated, then one solution would be to define a Norway-specific preset that takes precedence over the global one, omitting bicycle=designated.
The iD discussion you linked points out that foot=designated without bicycle=designated might be ambiguous from a routing perspective. That would be something for the local community to consider and possibly find a different solution for.
Out of curiosity, what are these real issues? Is it anything that iD could surface to users via a validation rule?
A real issue could be “Cycle path crosses stream”, but it is hidden among 20 warnings saying “Cycle and Foot path has incomplete tags”.
If my experience if iD is anything to go by, probably the reverse - iD bleats about things that are not issues locally - as a separate example, it complains that bus stops are not converted to “platforms” and other validators complain that these “platforms” do not have wheelchair tags. This global approach simply does not match the local infrastructure (here bus stops don’t themselves determine whether there is wheelchair access but buses do; whereas for rail platforms it’s the opposite).
Edit: And I guess it’s only fair to clarify that the schema that iD is imposing here (with bus stops) is not of iD’s making - it’s utterly bonkers to apply globally, but I guess does make sense in the urban regions of central Europe where it was devised.
Thank you for the clarification. It wasn’t clear to me at first that you were referring to issues in the sense of existing iD validator issues, versus something that would be flagged outside of iD by the community.
In any case, id-tagging-schema would be the place to request a regional change to the presets.
True. highway=cycleway implies bicycle=designated. If it’s not designated, it simply is not a cycleway.
So bicycle=designated can be tagged explicitly, but world-wide validators should not warn if it’s missing. If a country/community has agreed on a different tagging, they should use a country/community-specific validator.
highway=path does not imply any designation. I think foot=yes and bicycle=yes are international defaults for highway=path. Segregation is not implied and is not the default, so world-wide validators should not warn about missing segregated tags there.
If there is a segregated tag, then I personally would expect the main tag to be either cycleway with foot=yes|designated, or a footway with bicycle=yes|designated. Because, if there are no signs or markings, how else would you know that it’s a segregated foot/bicycle path?
Since I am not sure that this expectation will hold across the globe, I would not warn about it in a general OSM validator. E.g. communities could decide that if segregated=yes is present, foot=yes and bicycle=yes are implied. I wouldn’t let a secondary tag imply other secondary tags, but hey, that’s my personal preference.
Indeed - and at least where I live sometimes it’s important to record the actual access tags for bicycles, which may not be “yes”.
Nice, in Germany highway=cycleway foot=designated is simply wrong. Adding only bicycle=designated is not fixing the problem but either foot=designated is wrong or it should be highway=path bicycle=designated foot=designated. 
Sure - we also have some permissive cycleways. Designated, but subject to closure by the owner. Then highway=cycleway implies bicycle=designated AND bicycle=permissive says that the owner can close it at any time. Usually it’s a nature reserve or park which closes at night, during storms, during uncontrolled pandemics and for maintenance or re-design. (Yes, designed nature: real nature is hard to find in Nederland).
We run into problems with e.g. tracks and unclassified ways which are also bicycle=designated (traffic sign) and at the same time bicycle=permissive. Some are mapped as cycleways with vehicle=permissive, despite looking like regular roads/tracks.
Anyway, it’s hard enough without validators firing away at the solutions.
The validator rule only warns about a missing bicycle=designated if foot=designated and bicycle=* is unset. Setting bicycle=* to anything resolves the warning.
Does that mean that I get no warning about highway=cycleway bicycle=no foot=designated?
I’m away from the computer right now, but that would be my expectation. Some otherwise unlikely combinations can occur when, say, a path or street is closed for repairs or for some other situation, or in order to get overridden by a conditional restriction (which iD doesn’t expose in its fields yet).
The validator doesn’t try to catch every possible error, just a limited set of them. This particular rule isn’t even an access restriction checker; it’s just flagging a combination that almost matches a preset but doesn’t. Sometimes such near-matches are actually bugs or gaps in id-tagging-schema or name-suggestion-index.
Is that because it is the custom in Germany is not to use highway=cycleway for things that might also have foot access?
I’ve made a PR for the changes to exclude Norway from the presets.
Almost, in Germany a highway=cycleway is signed with 
traffic_sign=DE:237 which translates to access=no bicycle=designated. In theory, pedestrian could be allowed but there is no sign for foot=yes. For foot=designated we need 
traffic_sign=DE:240, 
traffic_sign=DE:241-30 or 
traffic_sign=DE:241-31, all highway=path bicycle=designated foot=designated (access=no), or 
traffic_sign=DE:239, highway=footway, or no sign at all for sidewalks.
In the end it is more likely a problem with presets.
If you bother with access tags for repairs or for some other situation it is, in my eyes, better to adjust the highway value, too, and conditional restrictions should follow the rule that either the majority of the time bicycles are allowed and the no part should be under bicycle:conditional or if the majority of the time bicycles are disallowed the highway value should be adjusted.
Still, I do not understand why a possible missing default access tag is flagged but the obvious tagging errors are not. Once again, I understand why I do not get warm with iD and better stick with JOSM, though I would expect more from the prominently presented editor for beginners.
Normally this is true, but the combination of highway classification and access tagging is flexible enough to accommodate unusual situations. Some regions have stricter norms than others. Some regions have traffic signs that conveniently support these norms without requiring mappers to make a judgment call, but not all regions are so lucky.
iD’s support for access tagging is still incomplete. The scheme is much more complex than the existing field lets on, and there isn’t very much validation about it yet. It’s a known issue: one of this year’s suggested Summer of Code proposals is specifically about building out this feature, though it’s too early to say whether we can expect anything to come out of it this year.
Is there a distinction between a preset and the validation rules that generate the warnings? Or do the same definition file control both?
As an example, there’s currently a discussion whether crossing:markings is useful or not.
Is it possible to keep the preset, but silence the warnings about missing crossing:markings tags? If you can’t silence them, you get spammed with thousands of warnings when zooming over a city. E.g., this is not useful
If they are tied together, it could be a mass edit is appropriate.
Some validation rules are based on preset data; others are not.
In the Issues sidebar you’ve opened, “Everything” and “Everywhere” are currently selected – these options are for when you want to get spammed. You can likely cut down dramatically on the warnings just by toggling these settings. Moreover, if you don’t want to see this particular warning for any reason, you can uncheck the “Incomplete Tags” category in the list beneath the list of warnings.
In this particular case, the Incomplete Tags warning is coming from the preset data. iD notices that the node almost matches the Unmarked Crossing preset’s tags, but not quite:
The broader context is that id-tagging-schema seems to be heading towards a future in which the various crossing presets are oriented towards the crossing:* subkeys (not just crossing:markings), similar to how the level crossing presets are organized. The fate of the traditional crossing key may ultimately vary by region, depending on how well that older scheme accommodates real-world conditions in each country, but the subkeys are designed to be more global in nature, being less open to interpretation.
