Proposal talk:Cycleway hierarchy

Fuzzy concept

The proposed values do not have clear definitions. I would have no idea how to determine the correct value in my own community (Norway). If implemented, I think we would get endless discussions about tagging.

I think the physical characteristics of the cycleway, tagged with other keys such as cycleway=*, surface=*, segregated=*, lanes=* etc, are more important for the biker. We already have the network=* tag which takes care of important national and regional routes and which display nicely on a map. Also, you have a separate proposal for cycleway=expressway. --NKA (talk) 08:10, 11 August 2022 (UTC)

The point was explicitly to NOT capture physical traits, but only importance/function/role. Hence the example of the two physically/"taggingly" indistinguishable cycleways, where one is long, continuous, and well-connected, and the other one is short, discontinuous and disconnected. Their importance/functions, i.e. their place in the hierarchy, are very different. This is the same concept as primary/secondary/tertiary for highway, which also does not capture the physical state.

The proposition that network=* can handle this, is valid, but to me somewhat misplaced. The documented role of network seems to be to capture a specific network, not importance/function. A road can be classified with a hierarchy per this proposal even if it is not a part of a specific network. --Balchen (talk) 10:11, 11 August 2022 (UTC)

If it helps, any mention of typical physical traits can be removed. Typical physical traits are discussed for highway=primary etc, but I see no problem with removing them from this proposal. --Balchen (talk) 11:06, 11 August 2022 (UTC)

AFAICS this proposal relies on essentially subjective criteria. I very much doubt that major consumers for bicycle routing will consume this tag even if implemented. You should try & seek feedback from CycleStreets, cycle.travel, OpenCycleMap etc. SK53 (talk) 11:10, 11 August 2022 (UTC)

In NO, municipalities and counties with a formalised cycle network (as opposed to just random cycleways) will have these formally divided into a hierachy. Those without a cycle network will not, so there will be cycleways with no hierarchical classification. This is part of the proposal. NL and BE also have a hierarchy that is reflected in their route numbering system (e.g. the Dutch F-routes). TfL cycle superhighways are also a formal classification of hierarchy. I don't see that this is essentially subjective.

I can't speak to what software will do in the future, but using the hierarchial classification of a roadway as an option to generate alternative driving routes is ubiquitous for car routing. Would that be different for bike routing? --Balchen (talk) 11:43, 11 August 2022 (UTC)

The overlap with routes and networks

I don't agree physical standards should be represented in here. Functionality is the point of highway=*. There was in fact network:type=basic_network suggested, but that's not really good, as it is simply classified in a network without being a uniquely identified route. You could easily make them a network=* or *cn=yes without creating a type=route, if there are some characteristic that categorizes it. This applies especially since you have signage here. To solve the problem of network=* and cycle_network=*, there is network:area=* and network:name=* to allow more general separate tagging. Do we need a footway:hierarchy=* as well? --- Kovposch (talk) 09:17, 11 August 2022 (UTC)

I agree that physical standard will not be represented here. Hence the exhaustive comparison of examples where the physical standard may be indistinguishable, yet the proposed hierarchy tag could be different.

The purpose is to capture the importance/function/role that the road serves, not its physical standard. --Balchen (talk) 10:11, 11 August 2022 (UTC)