Bike route networks classification (ICN, NCN, RCN and LCN)

ramthelinefeed · 2024-11-25T10:17:26.211Z

SomeoneElse:

Perhaps in addition to “i”, “n”, “r” and “l” we need something that says “who it’s for” - hyperlocal or further-afield commuters, Strava-fans or out-and-out tourists .

A ‘who it’s for’ tag would be practically very useful for actual cyclists and routing apps, but also rather difficult to objectively decide on a value for, I guess. I think we’d be getting into what wikipedia calls ‘editorialising’ rather than just mapping ‘what’s on the ground’. (Although I frankly I don’t think that’s a bad thing! Maps are meant to be useful…)
For a lot of cycling infrastructure in Britain, the a ‘who it’s for’ tag would probably have to say ‘box-ticking bureaucrats desperate to spend their budgets’ In Northern Ireland, for instance, the Dept for Infrastructure Roads Service is very fond of added painted cycle lanes in the hard shoulders of 70mph dual carriageway trunk roads. Whilst this may harmonise well this the new Assisted Dying Bill going through parliament as I type, to date they have not proved popular with human cyclists.

Richard · 2024-11-25T10:46:04.018Z

Minh_Nguyen:

Would this redefinition network=icn align with your recommended approach?

network=icn is the set of routes that should appear at all zoom levels on a rendered map of cycling routes.

network=ncn is the set of routes that should begin appearing together at somewhat low zoom levels.

Oh come on, you know the OSM tagging<->rendering relationship doesn’t work like that

What cycle.travel displays at all zoom levels is my business, and people shouldn’t make tagging decisions expecting to influence that. I might want to show a curated set of good quality US long/medium-distance cycle routes - the Katy Trail, for example - at low zoom levels, and only start introducing the USBRS or even international routes at higher levels. If people start second-guessing “what will renderers show at zoom level n?” then carnage will result.

(When I say “I might want” I mean “I do want”, I just haven’t had time to curate that list yet…)

ramthelinefeed · 2024-11-25T11:05:32.462Z

Inevitably there is always going to be some aspirational tagging by editors, and some feature requests to the curators and developers of renderers as to what editors would like to see in maps.
This only becomes carnage if that dialogue breaks down We don’t tag for the renderers, but OSM is only ever as good as its best renderers - without them we just have a database, not a map.

Peter_Elderson · 2024-11-25T12:31:14.708Z

As explained before, I think this route tagging is mainly for the rendering (we’re building a map, aren’t we?). It is important to add information for the renderer, without prescribing what renderers should do with the information.

The renderer decides which objects and which details to show, in which style and at what zoom levels, and we mappers have to provide the information to base the decisions on, and the details to show.

We should not map for a particular renderer, i.e. map the information based on previous decisions of a particular renderer.

Peter_Elderson · 2024-11-25T21:42:30.060Z

Peter_Elderson:

Commuter routes / cycle trunks are a growing phenomenon, and worth mapping, I totally agree. We are actually getting local commuter cycling routes, intercity commuter routes

Here is one example:

image1082×608 117 KB

They used “bicycle:type=utility” and also “cycle_highway=yes” which may not be the best tags to convey the idea in OSM. In an earlier version, cycle_network=cycle_highway was used instead of cycle_highway=yes.

I don’t think the mappers were thinking about world wide uniform tagging, only about how to tag for the Dutch situation. If an OSM standard tagging pops up and wins the war, retagging is no problem.

stevea · 2024-11-26T00:46:20.772Z

Peter_Elderson:

If an OSM standard tagging pops up and wins the war, retagging is no problem.

I think what we’ve been doing (at peace with ourselves, certainly) for a couple of decades (of bicycle route network tagging) is to “exist within” the bursts of taggings in particular directions. All over the world (in our database), with a plethora of tagging flavors. There are many dialects of tagging cycle networks. We seem to be (here) in stages of identifying many (most? not all) of them and their (diverse) syntax (taggings). Such identification is doable, it’s something we haven’t yet done systematically (to my knowledge).

Developing that OSM “standard” is harmony among our many taggings. There are also specific tagging intentions (inclinations, more desire than reality…) which seem to be problematic for some, as some routing may be merely aspirational.

Change here can easily upset apple-carts aplenty. There have been bad crayon-scribbles into our data aplenty, we clean those up because “we know what we mean by removing nasty-wrong data and curating real, correct data.”

There continues to be some hammering out of things, for sure. Feels like early days, with some progress. We don’t have a clearly-stated destination / goal, here, though should we agree to re-tag (longer-term, for sure), let’s keep it clean and elegant. If we DO end up “pulling things together into a newer (bicycle routing, network) syntax,” that is. It’s doable, it takes some work, we’ve begun, this dialog is excellent. We have been cordially discussing this topic for decades.

The task might benefit from a systematic cataloging of our many methodologies of tagging these, a large-ish task, it seems to me. (Partly why it’s great to see a plethora of cataloging, of tagging-flavors, additional dimensions like “well-marketed” and other things…we’re doing this now). I see yet more harmony ahead, slow and steady ahead. Good for us.

Minh_Nguyen · 2024-11-26T02:27:32.882Z

Richard:

Oh come on, you know the OSM tagging<->rendering relationship doesn’t work like that

Indeed, but we see that it’s the remaining rationale behind the three-letter acronyms. I now turn to my closing arguments:

From the get-go, the use of these three-letter acronyms outside the UK was literally tagging based on the specifications of a particular renderer.
To some, this was the right decision. Therefore, anywhere the tags prove unsuitable, they suppose we could divorce them from any real-world meaning, explicitly reducing them to zoom level hints. For a global renderer, this lowest common denominator would be the answer to the original question that started this thread.
These days, there is a desire to provide data consumers with more specific network information, so they can make appropriate rendering and other decisions for themselves. Because this information has been preempted by hard-coded rendering hints, data consumers will have to work around the tagging scheme in postprocessing.

Peter_Elderson · 2024-11-26T07:13:34.781Z

Minh_Nguyen:

preempted by hard-coded rendering hints

Hm… All information in the OSM database is hard-coded, and can be seen as rendering hint. If I enter information that I find important to an object, probably (hopefully) a map or app aimed at people who care about this sort of information will render it.

Now my understanding is that tiles are created with some, but not all, information included, so tile users can use the basic tiles, modify them, or even have the client side modify the style. Information in the tile differs from the OSM database. So I can understand that at the tile level one could make a difference between information that is used to pre-format the tiles, and information that is transformed and included in the tiles for later processing.

From the mapper’s point of view, this is a renderer’s decision. THe mapper just puts information in the database (probably dreaming a lot about the end result on a map, but the dreams are not captured, the information is).

Even osmc:symbol is nothing more than information. It’s not the symbol itself, but only a description, which is fortunate because our national hiking/foot/walking route operator wanted to sue us for illegal use of the route symbol (white-over-red, in license from the French, they told me). By the way, that is also why we can’t use pictures for the route symbols: that would be illegal copying and distribution of a licensed trade mark).

dieterdreist · 2024-11-26T08:13:24.000Z

By the way, that is also why we can’t use pictures for the route symbols: that would be illegal copying and distribution of a licensed trade mark).

are you sure? After all you would use the trademark to describe what they are registered for…

StC · 2024-11-26T08:19:25.814Z

dieterdreist:

are you sure? After all you would use the trademark to describe what they are registered for…

I suggest that we create a dedicated thread for this if we want to dig deeper.

There is also the tricky question of representing the actual signs on the ground vs the symbols used in communication supports

Peter_Elderson · 2024-11-26T08:38:49.823Z

dieterdreist:

By the way, that is also why we can’t use pictures for the route symbols: that would be illegal copying and distribution of a licensed trade mark).

are you sure?

No, it’s what they told me after seeing the symbols and routes on a map.

The routes: after we explained that the routes were hand-recorde in the field (even if they did not allow us to use the digital info), which -under our law- does not break copyright, they gave permission to use their info, but they asked us to make sure that our OSM-route lines were not more up-to-date than theirs… we don’t control their updates, so that’s a mute request. I did set up a process to compare their route lines with OSM routes, resulting in hundreds of differences, mostly at their side, and they used it to fix their digital routes. Sadly, they didn’t pick this up as a regular QA process.

The symbols: I explained that we mappers just give a text description of the symbol, and that renderers decide what to make of that. And that I would support a legal check to see if that violates copyrights or licenses, because I would really like to see if we are not allowed to describe a symbol, or if renderers are not allowed to use the description like that.
And it is a fact that this particular logo is not that complicated, and if a renderer uses the text description to depict something like it, it is bound to look reasonably like the licensed picture.
I haven’t heard any objections since, and I am sure they know how to find me!

It has to be said: their digital info of all routes has improved substantially. They used to keep the digital route lines equal to the printed versions, but their has been a paradigma shift: they now see and publicise (as “interactive maps”) the current route including all the modifications as The Route.

Idrizza · 2024-11-26T08:50:42.264Z

Hello!

I’m sorry but I didn’t read the whole thread, only a few dozens messages. I’m the GIS specialist of Vélo & Territoires, the French association monitoring the “Schéma national des véloroutes” (national bikeroutes network/planning schema) or SNV. I’m also the french representative for the EuroVelo network, on GIS and data subjects.

Let’s begin by defining “Véloroutes” (or bikeroutes), as per the Vélo & Territoires / French government definition:

continuous routes designed to facilitate cycling over medium and long distances. They are supported in particular by roads belonging to the public or private domain of the State, its public establishments and the local authorities and their groupings responsible for roads. They use any type of road suitable for cyclists and are continuously signposted. They may be of local, departmental, regional, national or European interest. Cycle routes link different areas of France and enable people to cycle through towns and cities in good conditions.

The association I work for especially cares about so called “Véloroutes”, and less about bike routes primarily on shared roads, intended for road cyclists, or one-day cycle loops.

We have 4 schemas level, as in network values: european, national, regional, and departmental. All véloroutes we know of and their schema level are available on our GIS portal Velodatamap. For french véloroutes, I think our official classification should help OSM contributors decide which value of network to attribute. European network is not defined by us, but by EuroVelo. National network is defined by us, and a national véloroute should meet the criteria defined in the SNV rules.

As per this document, a national véloroute should:

cross two French regions ;
be at least 100 km long ;
have a 60% already cyclable ratio.

For regional and departmental levels, we don’t enforce anything as it is the local authorities’ responsibility. Some local authorities define precise criteria for departmental and regional véloroutes, as Normandy departments did: Route numbering guide for Normandy. And here is their Normandy véloroutes schema.
However, it begins to be a bit complicated when the Normandy region has its own definition: Soutien financier au développement des véloroutes de Normandie | DREAL Normandie. Some regional véloroutes in the region’s eyes are only departmental in the departments’ eyes, and vice versa. Good luck for tagging that!

With the help of those documents and our GIS portal, you should be able to define more easily the best network value for most of French véloroutes.

As for cycle_network, all véloroutes registered in the national schema can be tagged cycle_network=Schéma national des véloroutes. All EuroVelo routes in french territory are by default included in the SNV, even if they should be tagged cycle_network=EuroVelo

StC · 2024-11-26T09:26:47.050Z

Idrizza:

All EuroVelo routes are by default included in the SNV, evend if they should be tagged cycle_network=EuroVelo

Is there any part of a EuroVelo route that does not belong to a French Veloroute with its own relation in OSM?

Vinzenz_Mai · 2024-11-26T09:39:02.812Z

Hi @Idrizza,

I know it’s offtopic here, but could you have a look at the segment with the ID 218355, ID local=cg57_17112, part of V52 and EuroVelo 5 between Gondrexange and the junction of the Canal du Marne au Rhin and the Canal des Houillères de la Sarre please.

The cycle path is on the south side of the Canal du Marne au Rhin as mapped in OpenStreetMap (Relation: ‪Véloroute 52 - Gondrexange‬ (‪8387471‬) | OpenStreetMap) not on the north, see my pictures in Proposal: creation of a working group for a more coherent integration of EuroVelo routes on OSM - #50 by Vinzenz_Mai

Best regards
Vinzenz

Idrizza · 2024-11-26T09:42:27.046Z

Sorry, I don’t understand your question! Only the french parts of EuroVelo are also part of the SNV.

Idrizza · 2024-11-26T10:05:26.763Z

Corrected, but next time please write me privately, either at my professional email, or with a private message here, instead of going off-topic in a thread. Even better would be to also warn the local authority, as they are the people that send us the tracks =) Surely they have this error in their database too.

Thanks for the info though!

StC · 2024-11-26T10:38:41.482Z

Idrizza:

Sorry, I don’t understand your question! Only the french parts of EuroVelo are also part of the SNV.

In your original post you said that all EV routes in France were part of the French national scheme. Which brings us to a potential problem with routes that belong to two networks (EV and national)

My question “are there any parts of EVs in France that do not belong to a national route” aims at discarding the above issue: if there is both an icn relation and a nwn relation in OSM, then each of these belong to exactly one network (EV or national)

Vinzenz_Mai · 2024-11-26T10:54:07.639Z

Idrizza:

Corrected, but next time please write me privately, either at my professional email, or with a private message here, instead of going off-topic in a thread.

I should have thought of that myself

Idrizza:

Even better would be to also warn the local authority, as they are the people that send us the tracks =)

I’m sorry, but my French is much too bad for such a thing

Idrizza · 2024-11-27T10:18:48.679Z

Yes there are parts of EuroVelo routes in France that are only part of an EuroVelo route, and not part of another véloroute registered to the SNV. See EV8 between Draguignan and Peyrolles-en-Provence, for instance. That said, even those parts are de facto part of SNV, just because they are part of an EuroVelo. SNV is in fact the combination of strictly national véloroutes and french parts of european véloroutes. This is a rule SNV has.

About regional and departmental schema levels, each one of them includes véloroutes from above levels, as you can see in the Normandy véloroutes schema, which includes EuroVelo and national routes. Departmental schemes are a combination of EuroVelo, national, regional and departmental routes. This is not as much a rule as a custom, as nothing would forbid a department to only include its own departmental véloroutes in its own schema. I don’t think it would have much sense from a local authority point of view, but it’s not forbidden.

To wrap up, and independently from the redefinition of this tag you all talked about, surely each véloroute network tag in France should be set to the highest level of schema it is part of. Then, reusers have to choose between :

display only the véloroutes strictly part of a precise schema level
display all véloroutes part of a schema level and all the schema levels above

However, in France and several other countries, EuroVelo routes have a national name, only applied to the national part. For instance, EuroVelo 4 in France is named “La Vélomaritime”.

Speaking of OSM relations, currently we have a route for each stage (Roscoff - Morlaix, etc.), a superroute for each national part (EuroVelo 4 - La route de l’Europe centrale - tronçon France : La Vélomaritime, etc.) and a superroute for the whole EuroVelo route (EuroVelo 4 - La route de l’Europe centrale). Each one of them is tagged network=icn. Would it make more sense that stages relations have a rcn or ncn value? And the national superroutes have a ncn value?

For now, if I count all the type=route and network=icn relations, I’ll end up with hundreds of results for Europe…whis seems a bit odd to me, don’t you think?

stevea · 2024-11-27T23:28:59.444Z

Idrizza:

For now, if I count all the type=route and network=icn relations, I’ll end up with hundreds of results for Europe…whis seems a bit odd to me, don’t you think?

Not really odd at all. More like “factual.” How else might we “get our heads around them?” (The topic does have “networks classification” in its name).

It’s so great to experience this dialog!