Remove `bicycle=designated` from "Cycle & Foot Path" Preset

[tordans]

Is there a reason, why we have bicycle=designated on the highway=cycleway-"Cycle & Foot Path" preset?

Or, to ask it differently: Is there a country, where highway=cycleway does not clearly imply bicycle=designated?

I understand why it has to be on the highway=path-"Cycle & Foot Path" preset.

Looking at the wiki https://wiki.openstreetmap.org/wiki/Tag:highway%3Dcycleway#Foot_access_on_cycleways it is not clear that we actually need it. This linked section just references what the preset does (in an incomplete way excluding the regional presets filter…). But the example actually omit the bicycle=designated.

---

My proposal is to remove this line https://github.com/openstreetmap/id-tagging-schema/blob/main/data/presets/highway/cycleway/bicycle_foot.json#L39

It was copied over from the iD Presets 4 years ago.

---

This would IMO resolve the issue behind #1193

[balchen]

Would that include the Cycle & Foot crossing preset as well?

[balchen]

Is there a country, where highway=cycleway does not clearly imply bicycle=designated?

The discussion usually revolves around the consequences of adding foot=designated, not if highway=cycleway in itself implies bicycle=designated.

The argument usually goes that adding foot=designated changes the implied access.

[tordans]

I now find the discussion at #1225 which precedes this one. Will keep this open for now to give it visibility, but also happy to close to only have one ticket…

[andrewharvey]

Sorry I don't agree with this. I always add bicycle=designated and foot=designated regardless of highway=cycleway, highway=footway or highway=path assuming both Bicycles and Pedestrians are signposted as shared users of the way. To me this makes it abundantly clear from my mapping that both modes are equally designated to share the space per the "Cycle & Foot Path" preset.

[quincylvania]

Hi all, I originally added this preset here: openstreetmap/iD@103c533

The idea is that explicit tags are better than implied tags, since "implied tags" create extra work for data consumers and are not always interpreted the same way globally. Since the name of this preset is meant to convey equal access to both pedestrians and cyclists, adding bicycle=designated in the preset allows mappers to be precise without requiring an additional step to set the cycling access.

I would actually be more strict about this and add "bicycle": "designated" to tags and remove addTags. Currently a feature with highway=cycleway + foot=designated + bicycle=no matches "Cycle & Foot Path", which seems like a bug.

[balchen]

The idea is that explicit tags are better than implied tags, since "implied tags" create extra work for data consumers and are not always interpreted the same way globally.

I assume that you wouldn't want a preset highway=residential + motor_vehicle=yes + foot=yes + bicycle=yes, even if this follows the same logic that you now presented?

[quincylvania]

I assume that you wouldn't want a preset highway=residential + motor_vehicle=yes + foot=yes + bicycle=yes, even if this follows the same logic that you now presented?

I would be fine with this preset if it and it was named something clear like "Residential Road for Motor Vehicles, Bicycles, and Pedestrians" and if people actually wanted to use it, but I doubt very many people would actually want to use it. By contrast, people very much want to add Cycle & Foot Paths and they want the editor to add enough tags so that every app will know what they meant.

To your larger point, I really don't put much stock in "implied tags". So many of the issues people encounter with OSM-based apps is that the app is making broad assumptions based on limited information—things like routing cars down service roads not tagged private. It's much better to overtag than undertag.

[balchen]

To your larger point, I really don't put much stock in "implied tags".

OSM really wouldn't work without implied tags. Neither would anything else in the world if we had to name them like you just did to be able to infer anything from the name. Good luck with that, btw.

Seems like a case of agreeing to disagree.

The trouble is, the iD preset is directly in conflict with the Norwegian OSM community agreement on tagging, which means every time someone in NO edits a cycleway, there is a false warning from iD generating noise and confusing new mappers.

I've requested to have an exemption added to iD for NO (like there is for other countries), but that's been slowly rejected by @tordans on the grounds that this approach here is better.

So I will unfortunately need to continue to push for some change here, even if you think explicitly tagging everything is much better.

[quincylvania]

OSM really wouldn't work without implied tags.

Yes, of course this is true. I'm not saying they're not useful, I'm just saying it's better to be explicit.

The trouble is, the iD preset is directly in conflict with the Norwegian OSM community agreement on tagging

I've requested to have an exemption added to iD for NO

This is exactly why explicit tagging is better. When iD adds an exception that certain tags are implied in certain places, then every app that consumes OSM has to add the same exception logic to be compliant, making the data more difficult to use. Granted this issue is a pretty minor example.

[balchen]

When iD adds an exception that certain tags are implied in certain places, then every app that consumes OSM has to add the same exception logic to be compliant, making the data more difficult to use. Granted this issue is a pretty minor example.

Again, we have to agree to disagree, but if you really believe that data consumers need to add an exception to support that cyclists are designated on a cycleway, I would argue that those apps are faulty in the first place. It's not "certain places" -- it's literally in the definition of the road class and in the wiki.