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)

Refinements to proposed tagging

I strongly support this concept.

I would suggest merging the cycleway=expressway proposal into this, as an analogy to highway=motorway. The main criteria I feel have to do with right of way, visibility and ability to maintain speed, but I don’t mind giving any other typical properties as examples.

I think the physical criteria should be completely removed from at least primary/regional, and the criteria derived purely from the directly observable function the way serves, i.e. what you already have in the meaning column. A cycleway connecting two rural villages may well be just a dirt path, but it’s still the primary (only) connection.

To quote from highway=trunk’s entry ”Note that highway=trunk is classified by its importance in road network, not by its quality (though in given area these two will correlate extremely strongly).” For primary/regional cycleways, this importance should be obvious and verifiable just by looking at a map (connection between two distinct settlements).

For secondary and tertiary, while I think function should still be the main deciding factor, in practice it may be very hard to justify the verifiability of using these hierarchy values if there are no external clues, like you provided as examples. (I can think of very few places in Finland where these might be justified, due to rarity of signage.)

I think the main benefits of this proposal compared to cycle routes are that (at least parts of) this model can work without any explicit signs or official route designations, and that it has an obvious built-in hierarchy, making things easy for maps. And unlike cycle routes, this model guarantees actual bicycle infrastructure on the ground. --Aktiivimallikansalainen (talk) 17:24, 11 March 2025 (UTC)