Talk:Key:cycle network

Looking at this page, it seems only the US is using the cycle_network tag. Could this be used for essentially grouping together some of london's (and perhaps more of the UK's) cycle networks, e.g. the Cycle Superhighways, and soon, the proposed Quietways network)

I have tagged the current handful of cycle superhighways as such to see if they may be useful and adopted elsewhere, but I'd be interested in other people's thoughts.

—Preceding unsigned comment added by L'le Tom (talk • contribs) 20:05, 18 March 2015‎ (UTC)

If these routes are specific to the UK, it would be best to prefix the tag values with "UK:" just to keep them separate from other countries' networks. Maybe something like "UK:Superhighway" and "UK:Quietways". – Minh Nguyễn (talk, contribs) 21:38, 22 March 2015 (UTC)

Pietervdvn, I do not understand what you mean to say in your recent edit to the Belgium section: "The most prominent usage of cycle_network in belgium is [Tag:cycle_network=cycle_highway cycle_highway], together with a few ad-hoc cycle routes." Do you mean to put double-brackets around that instead of single-brackets (that is, using [[ ]] instead of [ ] )? Also, even if you were to do that, what is "cycle_highway cycle_highway" as a value for cycle_network? That seems like a "non-standard" value for this tag, and I would appreciate your clarification of what you mean by that as you re-write / improve this section of this wiki, please. Thank you in advance. Stevea (talk) 21:52, 6 January 2020 (UTC)

Ah, thank you! That does help clear it up for me. Stevea (talk) 21:54, 6 January 2020 (UTC)

@Stevea: yes, indeed, I corrected that. See the new wikipage to see what the key is about. This was discussed on the Belgian list and this consensus arose. Pietervdvn (talk) 22:01, 6 January 2020 (UTC)

I appreciate your answer and pointer to the wiki-documentation on cycle_highway. I have always been impressed with how the BeNeLux countries (do people still say that?) have both established some of the world's best infrastructure for bicycling (including stitching these together into route networks and signing them understandably) as well as that these are well-accommodated in OSM! For example, Andy Allan's OpenCycleMap uses the "round circle" shields for cycle node networks / fietsknooppuntennetwerk and both tagging and rendering have worked well for these for many years. Great to see this continue with good growth around the world and in OSM, too. Cheers, Stevea (talk) 22:11, 6 January 2020 (UTC)

Haha, thx! Yes, we sometimes still use 'Benelux' as name ;p

And while we are indeed already quite good, there is still a tremendous lot to improve on cycling infrastructure and planning of buildings. Especially in Flanders it is really bad resulting in a lot of car congestions... But on the other hand, we've seen huge improvements on that the past decade, so...

What additional benefit does this tag provide?

This page's first sentence: "Values for this key often parallel network=* values" clearly implies it doesn't. How is the widely used network tag "ambiguous"? OSM is geospatially aware so the country codes are irrelevant. The rest of the tag appears to duplicate the name.--DaveF63 (talk) 22:51, 17 May 2021 (UTC)

I don't see the "clearly implies" that you do, perhaps you could better explain your "chain of logic" or derivation of why you say this. What is meant by this is that values of cycle_network=* often use ISO country codes (HU=Hungary, US=United States of America, UK=United Kingdom...) and when a network is at a "national level" (like "UK:National Cycle Network" or "US:US" for the United States Bicycle Route System), these will also be tagged network=ncn. Likewise for the "next level down" where in the USA, for example, states (as "sub-national," states are below the national level), these will get values like "US:OK" for the state of Oklahoma, or "US:NY" for the state of New York, and these are also tagged network=rcn (the next level down from national). This (often) continues with network=lcn, and so the statement "values for this key often parallel network=* values" is included (because it is both true and illustrative of this "paralleling" of the ncn/rcn/lcn hierarchy). At the international level, (where icn is "above" ncn), the value of cycle_network=* simply "stands alone."

The widely used network=* tag can be ambiguous at a regional level, for example, as "region" is itself rather fuzzily defined. In the USA, this is a state, and in Canada, a province, (there are many other examples) but elsewhere in the world (where it is less-defined or undefined), it remains ambiguous unless and until it is better defined. This wiki is a good place to document that.

I don't believe that a tag which specifically defines a bicycle route as belonging to a network of other bicycle routes (in a single, defined network, which often parallels a "level of government"), along with a name and the syntax of the value actually denoting the "tree derivation" of the specific network, sub-network, sub-sub-network (or so on) is a bad idea, nor irrelevant, nor duplicates anything. If you think so, you'll need to bolster your assertions here with more than "country codes are irrelevant" and "appears to duplicate the name." Irrelevant, HOW? Duplicates the name WHERE? I appreciate your questions and wish to answer them as best I might (and of course the wider community is welcome to chime in, too), but merely making bold assertions about this tag and its values (possibly based on misunderstandings on what this tag denotes?) isn't enough to have a real discussion.

What this tag does is stated in the last sentence of the first paragraph (Ideally, all route relations in a single cycleway network should be tagged with the same cycle_network=* value.): it groups individual routes into a name- or symbol-identified network, establishing a specific hierarchy. This tag allows one to determine, for example, if a route is or isn't a member of a particular network, as well as whether two routes belong to the same network, different networks or whether one or both of them might not be associated with any particular network (rare, and perhaps shouldn't happen, but it does). For example, some local networks might simply be a group of routes in "the local network" (without a particular governmental or other oversight / management besides that), often these are not named, instead preferring to be identified as "San Francisco's established, signed, numbered, government-published bicycle network" (for example). Stevea (talk) 23:31, 17 May 2021 (UTC)

I don't know what the comment about, but I would agree if the intention is to fix network=*, instead of adding on cycle_network=* when currently it is further being affected by cycle_network=cycle_highway. ---- Kovposch (talk) 08:06, 18 May 2021 (UTC)

The intention is not "to fix network=*." The tag augments and clarifies the specific network itself (not just its level in a hierarchy). The intentions are as stated above and are implicit in the introductory paragraph of the Page. Stevea (talk) 16:14, 18 May 2021 (UTC)

I read "The cycle_network=* key was originally introduced to avoid the ambiguity of generic network=* values.", so it seems apparent that there's some limitations with using network=*cn in the first place. There's already network:type=* being used for network:type=node_network. In the wild, I see there are 2285 network:area=* and 504 network:name=* instances. Particularly for the latter, one example network:name=Rivierenland is used on a network=rwn + network:type=node_network in a group around 1599205 1599205. Similarly, network:name=Scheldeland is used on network=rcn + network:type=node_network (instead of cycle_network=Scheldeland) around 1697611 1697611. There appears to be a cross-modal need to tag this. Are there any counterparts to cycle_network=* for network=*wn?

---- Kovposch (talk) 06:46, 19 May 2021 (UTC)

@Kovposch: You have a point about cycle_network=* being unnecessarily limited to one mode of transportation, though I don't know of a better way to name a key that's supposed to carry the same semantics as network=* apart from the recreational route network format. network:for_real=*? Many cycle_network=* values carry more information than country plus name. The original U.S. values can get every bit as hierarchical as network=* values for road routes, for example cycle_network=US:CA:SF or cycle_network=US:NY:NYC. network:name=* would be more appropriate if all values were just names, as in how network=* is used on rail and public transit infrastructure. – Minh Nguyễn ^💬 18:14, 14 August 2021 (UTC)

Then do eg network:int_ref=* or something network:*=* else. *:guid=* (has nothing to do with the usual 128bit "GUID" in computing) is already used for a similar (hypenated, instead of colon) hierarchical format in network:guid=*, operator:guid=*, and gtfs:feed=* for GTFS imports/links. While these things "work", they aren't very pretty. You already get quite many funny combinations attempting to extend network=* by *_network=* and *_operator=*, treating them as a *_name=*. ----- Kovposch (talk) 20:03, 14 August 2021 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

@Kovposch: At a glance, none of those options looks well suited for the kind of values that were originally intended for cycle_network=*. Just to be clear, cycle_network=* and traffic_sign=* contain namespaced values with namespaces based on the hierarchical network format for road routes, which is based on the basic format for road routes. network:guid=* is too closely tied to GTFS for comfort, considering the existence of similar feed formats for managed lanes and intelligent traffic management systems. I would expect any proposal to transition to network:guid=* to cover both cycling and road routes for consistency, which would pretty much doom the proposal.

As for network:int_ref=*, it sounds like a way to allow a given network to have a different ID at an international level than it does at a national or local level, but even network:ref=* would be pretty confusing. It's confusing enough that ref=* indicates the network when tagged on a way but not when tagged on a relation.

I find network:area=* tantalizing. If not for Waymarked Trails and OpenCycleMap relying on three-letter network=* values, I'd be very strongly in favor of using network=* the same way for both road and recreational routes and network:area=* to clarify the scope of a network. Lonvia has expressed some reservations about the three-letter values, so maybe a solution along those lines wouldn't be out of the question. [1]

 – Minh Nguyễn ^💬 00:59, 15 August 2021 (UTC)

I forgot to clarify by network:name=*, I was suggesting why not use network:name=London Cycleways, instead of the cycle_network=GB:London Cycleways (or *=GB:London:Cycleways; hell, or even network:bicycle=GB:London Cycleways as I'm reminded of hgv:national_network=*) format. (there's also a network=EuroVelo not using network=EU:EuroVelo) Seems it can already be difficult to parse the format when there are so many varieties for what is promoted as a hierarchy. This is worsened with increasing numbers of organizations, where the abbreviation/code in *=US:ACA needs to be understood as a Adventure Cycling Association.

In adopting this format, there's a secondary difference with the ISO 3166-2 standard. Established subdivision codes should be hyphenated, rather than colon-ed into the next level.

For the network:int_ref=* example, I just have question over the origin of the hierarchical format on how far do we need to qualify it. Like in Key:network#Public_transit_routes, network=FR:STAR is a less common example, and further it could be uniquely identified with network:wikidata=*.

---- Kovposch (talk) 04:44, 15 August 2021 (UTC)

Some notes:

Interestingly, cycle_network=BE-VLG:cycle_highway correctly uses hyphenation.

There are names and different formats from cycle_network=radrevier.ruhr to as long as cycle_network=Knotenpunktwegweisung Spree-Neiße

---- Kovposch (talk) 06:15, 15 August 2021 (UTC)

@Kovposch: OK, so the idea is to align to the rail and public transport network format rather than the road network format. The advantage is that this freeform, non-namespaced format, in combination with network:wikidata=*, can accommodate an arbitrarily complex collection of networks. That would be desirable in the U.S., where the number of recreational route–designating authorities is essentially unbounded. When relying on namespacing, we end up needing deeply nested values like network=US:OH:SAN:Fremont to avoid name collisions. It would be great to get out of the business of defining our own hierarchy of networks and rely on Wikidata QIDs to ensure uniqueness.

On the other hand, most recreational route networks in the U.S. have obscure or unimportant names, unlike in public transport. (There is an official system of "State Bicycle Routes" in Ohio, but that system has no official name.) These same exact considerations apply to road route networks, except that those network values are already being used in routers, making it more difficult to justify a similar overhaul for that kind of route. [2] Incidentally, OsmAnd's verbose but incomplete implementation rather proves the need for network:area=*. I think that key would become even more important with non-namespaced values, since not every data consumer will be able to join to Wikidata just to know the scope of a network. But without the existing namespacing format, I don't know how else a data consumer would be able to generalize, say, county route networks in West Virginia (white circle shield) versus county route networks in Florida (blue pentagon). network:is_in:state=*?

You're right that the subdivision codes should've been hyphenated when the hierarchical road network format was first developed in 2009. For road routes, this format has become problematic because it's impossible to tell at a glance whether a colon introduces a subdivision, an individual network name like network=US:TX:FM or network=US:US, or an auxiliary banner like network=US:US:Business (which can alternatively be specified in modifier=*). I don't think there's a strict expectation that all subdivisions adhere to ISO 3166-2: for example, that standard has no codes for counties, so in Ohio we've been using the transportation department's official three-letter county codes, which appear on signs.

 – Minh Nguyễn ^💬 16:23, 15 August 2021 (UTC)

hgv:national_network=* is unrelated to the concept of a network of routes. It's a system of multiple designations. Congress called it the National Network without thinking about a potential conflict with OSM terminology. ;^) – Minh Nguyễn ^💬 21:47, 15 August 2021 (UTC)

Holy, that's a long list on OSMAnd... I like network:is_in:*=* too since it's already used on some type=route . Concern would be whether it works well if multiple value is to be expected.

Yes, I'm mostly thinking about whether the hyphen standard would be useful had it been adopted.

---- Kovposch (talk) 11:28, 16 August 2021 (UTC)

@Kovposch: I would hope that multiple values wouldn't often be necessary for network=* on a route relation. Differing networks would be as good a reason as any for sub/superrelations. – Minh Nguyễn ^💬 22:06, 16 August 2021 (UTC)