Proposal talk:Basic network (2021)

rcn, lcn ?

Hallo, ist es gedacht, dass eine Relation nach diesem Proposal als icn, ncn, rcn, lcn eingestuft werden kann? Das lese ich aus dem Proposal nicht heraus. In Sachsen gibt es ein sehr grobmaschiges touristisches Radnetz (SachsenNetz Rad, zwischen Netzknoten sind es auch mal 20-50km) und ich denke, dass das Netz als rcn eingestuft werden soll. Ich habe an dieser Relation 2262874 2262874 mit dem Proposal experimentiert. Es ist so, dass OpenCycleMap gar nichts rendert (https://www.openstreetmap.org/#map=14/51.0233/13.8732&layers=C). Sowohl Waymarked Trails als auch CyclOSM (https://www.cyclosm.org/#map=15/51.0166/13.8847/cyclosm_live) rendern als local (https://cycling.waymarkedtrails.org/#?map=15!51.018!13.8885). Wie sollen die Render auch wissen, dass es sich um ein "regionales 'Premium'-Netz" handelt? Avena701 (talk) 07:20, 20 August 2021 (UTC)

Im Proposal wollte ich diese Frage nicht klären sondern mich auf das Einführen der Tags beschränken. Freilich habe ich mich das auch schon gefragt und bin mir da nicht ganz sicher. Das muss dann im Wiki beschrieben werden.

Einerseits sind die Konzeptionierer und Finanzierer dieser Wegweiser oft die Bundesländer, was für 'rcn' spricht. Andererseits sind die Verbindungen zwischen den Knoten selber meist recht kurz, was für ein 'lcn' spricht. Auch auf den Fahrrad-Wegweisern steht meist der nächste Ort, was eindeutig 'lcn' wäre, sowie das nächste größere Ziel, was durchaus schon mal im Nachbarkreis liegen kann, m. E. aber auch meistens noch kein 'rcn' rechtfertigt. Auch wenn die Hauptziele in Sachsen gerne 50 km auseinanderliegen, die Landkreise (alles darunter ist ja 'lcn') sind hier auch recht groß.

Zudem kommt, dass die Wegweisung bundesweit entsprechend der FSGV-Vorschläge erfolgt, Ausnahmen wie Sachsen-Anhalt mal ausgenommen. Thüringen, Bayern, Sachsen und Hessen z. B. verwenden nahezu die gleichen Wegweiser. Insofern ist das Netz für den Nutzer draußen schon fast ein 'ncn'.

Der Betreiber der Wegweiser ist im Idealfall für den Nutzer draußen egal und auch nicht oder schwer ersichtlich. Die Ortsnamen auf den Wegweiser sind dem Nutzer (und Mapper) dagegen wichtig und gut erkennbar. Daher habe ich mich für das Propsal entschieden, ein 'lcn' als Standard vorzuschlagen. Bei Wanderwegweisern wird es meist ähnlich sein, nur gibt es da keinen bundesweiten Standard.

Spannend wird es für die Nutzern erst dann, wenn es Landes-Netz und kommunale Netze nebeneinander gibt und die sich für den Nutzer (und Mapper) draußen tatsächlich unterscheiden, z. B. in den Standards für Mindestbreite und Fahrbahnbelag oder in der Art der Wegweisung. Dann sollte unbedingt auch zwischen 'rcn' und 'lcn' unterschieden werden. Sonst halt 'lcn' als Standardwert. Ich denke so kann man es dann auch im Wiki beschreiben, oder?

Das SachsenNetz Rad ist für mich als Radfahrer bislang leider kein "Premium-Netz", das sich von kommunalen oder Kreis-Netzen abhebt. Es wurden nur Wegweiser aufgestellt, die Wege selber wurden meist nicht verbessert. Es gibt meines Wissens auch keine erweiterten Standards für das SachsenNetz. Wenn doch etwas an den Wegen getan wird, dann passiert das auf Initiative der Gemeinden. Leider zeigt der Freistaat nur wenig Interesse am Radverkehr. In meiner Heimat Leipzig und Umland gibt es keine erkennbaren Unterschiede zwischen kommunalen Verbindungen und Verbindungen des SachsenNetzes Rad, in Dresden ist es meines Wissens auch so.

Meiner Erinnerung nach liegen in Sachsen auf den meisten SachsenNetz-Verbindungen auch rcn-Radrouten. Da diese Routen in der Darstellung Priorität vor dem Grundnetz haben, wären sie als rcn erkennbar. Der Rest wäre dann Grundnetz.

Zu den Beispiel: ich hab da auch experimentiert, bei mir wurden die Relationen dargestellt, als hätten sie das zusätzliche Tag nicht. Nur musste ich mitunter einen Monat warten, bis es neu gerendert wurde.

Soweit meine Gedanken dazu, passt das?

--Jo (talk) 16:25, 20 August 2021 (UTC)

Danke für die Antwort ( = meine Frage soll mit dem Proposal nicht geklärt werden). Ich bin der Meinung, dass es im Allgemeinen Radnetze unterschiedlicher Ränge geben kann, so wie es Radroute unterschiedlicher Ränge geben kann. Jemand hat sich mal dafür entschieden, dass wir icn, ncn, rcn, lcn in OSM verwenden und die geografische Ausdehnung spielt vielleicht auch ganz gut den Rang.

Ja, ich denke auch, dass verschiedene Ränge geben kann, aber nur, wenn die für den Nutzer und Mapper erkennbar (und relevant) sind. In NRW gibt es diese Trennung z. B. im Online-Kataster. Das ist aber keine gültige Quelle. Draußen ist diese Trennung i.d.R nicht wahrnehmbar.

Die gleichzeitige Definition von 'rcn/lcn' als eine Klassifizierung und die Definition über die geografische Ausdehnung der Verbindungen oder des Netzes sind ansich schon ein Widerspruch. Die Klassifizierung ist ein Verwaltungsakt, die Ausdehnung lässt sich messen. Mitunter passt beides nicht zusammen. Insofern macht das eine saubere Definition nicht einfach.

Zurück zum SachsenNetz Rad: Wir sind uns 100% enig, dass es ein unambitioniertes Projekt ist und dass das einzige sichtbare Ergebnis nur die Wegweisung ist. Die Wege im SachsenNetz Rad wechseln lustig zwischen grüner Wiese, Waldweg und Bundesstraße ohne Radweg, aber es gibt auch viele wirklich nette und fahrbare Strecken. Es gibt bzw. wird derzeit landesweit eine konsistente und durchgängige Wegweisung installiert und das Sachsenwappen weißt auf jedem Schild darauf hin, dass man im SachsenNetz Rad fährt. Ich bin der Meinung, dass "landesweit einheitlich", "besondert markiert (mit Sachsenwappen)" und "grobe Maschen" zusammen eine rcn-Einstufung erfordert.

Durch die Wappen ist es draußen erkennbar, wenn auch wenig relevant für den Nutzer. Insofern könnte man das machen. Das mit dem Wappen ist aber auch ein sächsischer Sonderweg, der womöglich aus Kostengründen (zusätzliche Farben) irgendwann wieder einschläft.

In Bezug auf SachsenNetz Rad müssten wir das (lcn/rcn) wahrscheinlich woanders diskutieren, aber wie müsste dein Proposal für rcn-Netze verwendet werden? Wäre es nicht sinnvoll, das zu konkretisieren?

Eigentlich genauso, nur das statt 'lcn' dann 'rcn' verwendet wird. Ich würde das dannn lieber im Wiki beschreiben als im Proposal, denn das ist schon sehr lang. Im Wiki könnte es dann in etwa so stehen: "Die Wegweiser weisen i.d.R. auf nahe Orte im Sinne 'lcn'. Daher wird in der Regel "lcn" verwendet, unabhängig vom Betreiber der Wegweisung oder der Ausdehnung des Netzes. Unterscheiden sich jedoch Wegweiser oder Gestaltungsmerkmale der Verbindungen lokaler Netze ggü. einem regionalen Netz, so können die regionalen Verbindungen durch 'network=rcn' bzw. 'rcn=basic_network' abgegrenzt werden."

Avena701 (talk) 19:54, 20 August 2021 (UTC)

Viele Grüße,--Jo (talk) 23:16, 20 August 2021 (UTC)

Basisnetzwerk

Mir fehlt hier noch eine Definition von dem, was ein "Basisnetzwerk" ausmacht, momentan sind da nur Bilder die zeigen, wie die Wegweiser aussehen.

Hierzulande ist mir der Ausdruck in amtlichen Schriften zu Verkehrsplanung begegnet. Ein Beispielsatz wäre: "Basisnetzwerk, über das Themenradrouten geführt werden können." Da fallen dann aber auch Wege ganz ohne Zielwegweisung darunter, die nur durch StVO Kennzeichen oder Bodenmarkierungen ausgeschildert sind.

Das bringt mich auf einen, wie ich meine, überlegenswerten Ansatz zur Definition: Im Basisnetzwerk liegen die Wege, die von den Wegerhaltern selber oder denen sehr nahe stehenden Organisationen ausgeschildert werden. Das sind Gemeinden, Alpen- und Tourismusvereine zB.

Die Erhaltung der Wege ist ja ein Schwachpunkt vieler Themenrouten. Es ist schon Thema bei den Themenrouten: Die Wegerhalter ins Boot zu bekommen. Das Basisnetzwerk ist der Trick, mit dem das gelingen soll. --Hungerburg (talk) 11:17, 14 November 2021 (UTC)

Hm, wäre solch eine Definition nicht zu allgemein und würde dann in vielen Gegenden einfach alle ausgeschilderten Routen beinhalten? Eigentlich geht es ja nicht darum, wer die Schilder aufgestellt hat, sondern um die Art der Beschilderung: Im Basisnetzwerk gibt es keine durchgängig gleich bleibende Beschilderung (Name oder Symbol), der man folgen kann. Das sind häufig Zielwegweiser, deren Ziele sich aber an jeder Kreuzung ändern können. Im Bereich der Alpenvereine wären es die Standardmarkierungen (Tirol z.B. rot-weiß-rot), die an jedem Weg vorhanden sind. Auch hier gibt es an den Kreuzungen eine Zielwegweisung, die sich an jeder Kreuzung ändern kann. Im Gegensatz dazu gibt es zumindest im Rheinland Radrouten, die nicht auf dem Basisnetzwerk liegen und durch ein gleichbleibendes Symbol ausgeschildert sind. Hier gibt es an den Kreuzungen extra für die Route aufgestellte Wegweiser, die nur das (gleich bleibende) Symbol zeigen.--Duvodas (talk) 09:32, 15 November 2021 (UTC)

Die Dikussion in der Mailing-List scheint ja auch in die Richtung zu gehen, es nicht auf die fehlenden Namen zu beziehen sondern auf den Grundcharachter des Netzes.

Gut, die Frage ist, woran man das fest macht. Im Deutschen Radverkehrsnetz hätte ich die Zielwegweisung als das wesentliche Merkmal gesehen. Drum hätte ich das so beschrieben.

Ich weiß nicht, ob es in anderen Ländern nicht einfach Symbole ohne Zielwegweisung gibt, die Wege als offiziell für Radfahrer empfohlen markieren. Da müsste man aber eine Grenze einführen, denn sonst würde jedes blaue Radwegschild dazu gehören.

--Jo (talk) 22:54, 15 November 2021 (UTC)

Siehe auch in der Mailingliste United_States/Bicycle_Networks#Local, wie wir solche "informellen Fahrradrouten" in den USA markieren. Wenn das Rendern Ihr Ziel ist, könnten Sie lcn=yes entweder auf der Infrastruktur oder auf einer mit network=lcn (oder rcn oder ncn) markierten Route erreichen. Stevea (talk) 23:01, 15 November 2021 (UTC)

Danke, allerdings ist nicht das Rendern das Ziel sondern die Unterscheidbarkeit zu Routen / Wegen mit lcn=yes bzw. network=lcn. Daher der Vorschlag des neuen Wertes. --Jo (talk) 23:06, 15 November 2021 (UTC)

Sofern ich die Absicht dieses Vorschlags nicht zutiefst missverstehe, bleibe ich zu 100 % davon überzeugt, dass dies mit cycle_network=* möglich ist. Stevea (talk) 23:28, 15 November 2021 (UTC)

Unterscheidbarkeit

Das im Proposal geschilderte Problem, dass sich lwn oder lcn Basisrouten nicht von Themenrouten unterscheiden lassen soll mit dem network:type=basic_network abgeholfen werden. Das in Analogie zu den Knotenpunktnetzwerken. Ich würde weiter gehen, und die Basisrouten in ein eigenes Netzwerk bwn oder bcn stellen. Damit sind die auf einen Schlag aus den Karten heraus, und man muss die anderen, die man in den Karten haben will nicht hervorheben. Wenn das dann durchstartet können sich Auswerter/Renderer etwas überlegen, wie sie die auf Karten bringen, so dass nichts wichtigeres verdrängt wird dabei. --Hungerburg (talk) 11:17, 14 November 2021 (UTC)

Teilweise teile ich deine Meinung, was die Einstufung in ein neues Netzwerk bwn oder bcn angeht. Für mich macht es keinen Sinn, das Netzwerk aufgrund seiner gesamten Ausdehnung z.B. einem rcn zuzuordnen. Meiner Meinung nach kann es eigentlich nur aufgrund der einzelnen Länge der Verbindungen, also der "Engmaschigkeit" eingeordnet werden. Ich könnte aber auch auf solche Einordnung verzichten und für die Kennzeichnung der Basisnetzwerke einen neuen eigenen Tag einführen. Ich denke aber, dass es hier keinen Konsens gibt, anderen ist die Einstufung in lcn/rcn/... wichtig. Da für die Knotennetzwerke hier auch kein neuer Wert eingeführt wurde, halte ich deutlich mehr davon, die Basisnetzwerke analog zu den Knotennetzwerken wie im Proposal beschrieben zu kennzeichnen. --Duvodas (talk) 09:38, 15 November 2021 (UTC)

Hier möchteich auf den ersten Beitrag oben verweisen: "rcn, lcn ?"

Es kann durchaus sinnvoll sein, auch Klassifizierungen nach lokal/regional vorzunehmen. Bei Geyer im Erzgebirge habe ich eine Wanderkarte mit zwei Symbolen gesehen, eines für "örtliches Wandernetz" und eines für "regionales Wandernetz". In sich sind beide klassische basic-networks, aber getrennte Layer.

Ein bisschen sollten wir auch den Migrationspfad beachten. Eine Änderung, die die Karten ersmal unverändert lässt ist da hilfreicher als eine, die ganze Netze von der Karte verschwinden lässt. Der erste Versuch des Umtaggen einer route-Relation in Network-Relationen führte zu heftigen Diskussionen am Changeset. Das mit den network-relationen war ja der erste Ansatz.

--Jo (talk) 23:04, 15 November 2021 (UTC)

cycle_network=*, ein etabliertes Tag und möglicherweise hiking_network=* (existiert derzeit nicht)

Siehe auch [1]. Stevea (talk) 21:07, 15 November 2021 (UTC)

Danke, Ich habe mich intensiv mit diesem Tag befasst und finde ihn gut, siehe https://forum.openstreetmap.org/viewtopic.php?pid=827683#p827683

Aber nicht für alles auf einmal, sondern nur für eine Anwendung.

Bisher wurden im deutschen Radverkehrsnetz die regionale Zuordnung über 'ref=*' getaggt mit Werten, die draußen nicht vorkommen, z. B. 'ref=NRW'. Ich würde das gerne durch dieses Schama ersetzen: 'cycle_network=<Land>:<Bundesstaat>:<Region>:<Kommune>', Wobei das auch schon beim Bundesstaat enden kann, z. B. 'cycle_network=DE:NRW'

Damit könnten wir dieses Tagging in Deutschland etablieren, mich würde das sehr freuen.

Zu dem Netz 'cycle_network=DE:NRW' gehören aber sowohl touristische Themen-Routen als auch die Alltags-Verbindungen mit Wegweisung. Ich denke, diese Trennung hier auch noch aufzunehmen überfrachtet das Schema.

In diesem Proposal habe ich mich auf das begrenzt, was neu ist. Neu ist die Unterscheidung der Wege mit offizieler Wegweisung von den Themen-Routen. 'cycle_network' habe ich nicht erwähnt. Das hätte ich tun sollen. Dazu ist die Diskussion ja da, damit ich das noch machen kann.

Bei Knotenpunktnetzwerken wird 'network:type=*' bereits erfolgreich verwendet. Dort beschreibt 'network:type=noede_network' die Art der Wegweisung. Auch hier geht es um die Art der Wegweisung. Es wird also kein Rad neu erfunden sondern ein bewährtes Tagging-Schema auf weietere Anwendungsfälle erweitert.

Viele Grüße,

--Jo (talk) 00:39, 16 November 2021 (UTC)

Kannst du einen Vorschlag machen? Ich kann mir es nicht so richtig vorstellen!

Wir brauchen einen fixen Begriff, anhand dessen erkennbar ist, dass es sich um eine Verbindung im offiziellen Radverkehrsnetz handelt und nicht um eine Routenempfehlung.

cycle_network=* zeichnet sich dadurch aus, dass es eine sehr große Anzahl verschiedene Werte gibt. Jedes Netzwerk hat sienen eigenen Wert. Dort einen fixen Begriff mit einzubauen, nach dem die Datenkonsumenten suchen müssen, finde ich einen Bruch im Konzept von cycle_network.

Zudem kombiniert cycle_network=* Aussagen zur Verwaktungs-Hierarchie mit Netzwerknamen. Mit diesem Proposal käme noch eine dritte Aussage hinzu. Ich fände es besser, die Aussagen in getrennten Tags zu beschreiben:

• Hierarchie: cycle_network=*
• Räumliche Ausdehnung: network=* (nur bei routenempfehlungen wirklich sinnvoll)
• Art der Wegweisung: network:type=* oder etwas Passenderes.

---

Can you make a suggestion, I can't really imagine it.

We need a fixed term that shows that it is a connection in the official cycle network and not a route recommendation.

cycle_network=* is characterized by the fact that very different values are used. There is a break in the concept of cycle_network to include a fixed term that the data consumers have to search for.

In addition, cycle_network=* combines statements on the administrative hierarchy with network names in one value. This proposal would add a third statement. I think it would be better to describe the statements in separate tags:

• Hierarchy: cycle_network=*
• Spatial expansion: network=* (only for route recommendations)
• Type of signposting: network:type=* or something more suitable.

--Jo (talk) 22:02, 19 November 2021 (UTC)

warum Relation und nicht direkt am Weg? | Why not as a tag on the way?

English below

Ist es nicht unnötig kompliziert, das in Relationen zu packen? Hiermit schafft man sich Probleme mit der Frage der Größe und Abgrenzung, die man mit dem Tagging direkt an den Wegen nicht hat.

Ich sehe so ein Radnetz ähnlich wie die verschiedenen highway-Klassen für Autos. Wichtige Verbindungen haben Wegweiser und bekommen highway=primary/secondary etc. Diese highway-Werte sind nicht in Relationen, sondern direkt am Weg. Für den Radverkehr könnten die einzelnen Wegabschnitte lcn=yes oder lcn=basic_network bekommen.

Ein mögliches Gegenargument möchte ich gleich entkräften und zwar die Behauptung "Das lcn=* kann nicht an jedem Wegabschnitt vor Ort (on the ground) erkannt werden." Meine Antwort: Das ist genau das gleiche bei highways. Zum korrekten Tagging muss ich die Straße weiter verfolgen und erkennen, welche Orte diese Straßen verbindet und wie das ausgeschildert ist.

---

Isn't it unnecessarily complicated to put this into relations? This creates problems with the question of size and demarcation, which you do not have with tagging directly on the paths.

I see such a bike network similar to the different highway classes for cars. Important connections have signposts and get highway=primary/secondary etc.. These highway values are not in relations, but directly on the way. For bike traffic, the individual path segments could get lcn=yes or lcn=basic_network.

I would like to debunk one possible counter-argument right away, and that is the claim "The lcn=* cannot be detected on the ground at each way segment." My response: it's exactly the same for highways. For correct tagging I have to follow the road further and recognize which places these roads connect and how that is signposted.

Translated with www.DeepL.com/Translator (free version)

Beides hat Vor- und Nachteile und ist oft Geschmackssache.

Solange nur die Zugehörigkeit zu einer Netzebene abgebildet wird, ist es mir gleich ob Relation oder Tag am Weg.

Deswegen schlage ich beides vor. Allerdings sollte man auch klar machen, dass es nicht OK ist, Relationen zu löschen um die Werte wieder an die Wege zu taggen. Ich werde das Wort "temporär" rausnehmen.

Relations-Tagging ist allerdings zu bevorzugen, wenn zur Route weitere Angaben gemacht werden. Dann muss man die Angabe nur einmal machen.

---

Both have advantages and disadvantages and are often a matter of taste.

As long as only the affiliation to one network level is shown, it doesn't matter to me whether it is a relation or a tag on the ways.

So I suggest both. However, you should also make it clear that it is not OK to delete relations in order to tag the values back to the ways. I'll take the word "temporary" out.

Relations tagging is to be preferred, however, if further information is given about the route. Then you only have to enter this information once.

--Jo (talk) 21:20, 19 November 2021 (UTC)

---

Ich finde, es sollte eine klare Empfehlung geben, ob Relation oder Way genutzt werden sollen.

Meine klare Präferenz ist, es am Way zu belassen, weil das viel leichter zu erstellen und bearbeiten geht. Aber ich habe dein Argument Pro-Relation nicht verstanden und lasse mich gerne überzeugen. Du nennst als Vorteil einer Relation, dass man weitere Angaben nur einmalig eintragen muss. Bitte nenne mir Beispiele, um welche zusätzlichen Angaben es hier geht.

---

I think there should be a clear recommendation whether to use Relation or Way.

My clear preference is to leave it at Way because that is much easier to create and edit. But I didn't understand your pro-Relation argument, and I'm happy to be persuaded. You mention as an advantage of a Relation that you have to enter further details only once. Please give me examples of what additional details are involved here.

Translated with www.DeepL.com/Translator (free version)

--Nielkrokodil (talk) 09:26, 20 November 2021 (UTC)

Die Diskussion ob Relation oder Tag am Weg gab es bereits bei 'lcn/lwn=yes'. Es war immer so, dass es verschiednene Präferenzen dazu gab und dass eine alleinige Beschränkung auf den Tag am Weg keine Mehrheit finden würde.

In Deutschland ist ein Großteil des Radverkehrsnetz bereits mittels Relationen gemappt. Somit stellt sich die grundsätzliche Frage eigentlich nicht mehr. Es braucht die Unterscheidbarkeit von Routenempfehlungen und Netzverbindung auf jeden Fall (auch) bei Relationen. Wenn es nur eine Empfehlung geben sollte, so wären das deswegen die Relationen.

Bereits heute stehen an den Relationen zusätzliche Atrtribute bzw. in deren Eltern-Relationen z.B. operator=*. Über Hierarchie von Eltern und Kinder-Relationen wird die administrative Hierarchie des Netzes abgebildet, z.B. in Nordrheit-Wesphalen (Relation 33216). Ohne Relations-Hierarchien wäre der Tag cycle_network=<country>:<state>:<destrict>:<municipal> an jede Wegkante zu schreiben.

Auf den Wegweisern stehen mitunter zusätzliche Informationen zu den Wegabschnitten in Form von Symbolen, z.B. ob sie landschaftlich reizvoll sind. Das wäre eine weitere Information, die in der Relation gut aufgehoben wäre.

Für die Grundidee, die Wege als Teil des offiziellen Radverkehrs - /Wandernetzes auszuweisen, wäre m. E. aber ein Tag am Weg vollkommen ausreichend, da stimme ich mit dir völlig überein.

---

The discussion about relation or tag on the ways already existed with 'lcn/lwn=yes'. It was always the case that there were different preferences and that a sole restriction to the tag on the ways would not find a majority.

In Germany, a large part of the basic cycling network is already mapped using relations. Thus, the fundamental question no longer arises, it is necessary to be able to distinguish between route recommendations and network connections in any case (also) for relations. If there was only one recommendation, it would be the relations.

Already today there are additional attributes on the relations or in their parent relations e.g. operator. The administrative hierarchy of the network is mapped via the hierarchy of parent and child relationships, e.g. in North Rhine-Westphalia (Relation 33216). Without relation hierarchies, the tag cycle_network=<country>:<state>:<destrict>:<municipal> would have to be written at each path edge.

The signposts often contain additional information about the route sections in the form of symbols, e.g. whether they are scenic. That would be another piece of information that would be in good hands in this relation.

For the basic idea of identifying the paths as part of the designated cycling / hiking network, in my opinion a tag on the ways would be completely sufficient, I totally agree with you.

--Jo (talk) 13:47, 20 November 2021 (UTC)

Use of abbreviations

Sorry if this particular topic has already been discussed, as a non German speaking it's hard to understand what is the actual matter upside.
As mentioned on Talk:Tag:network=ncn, pedestrian/cycling networks use too much of abbreviated key/values names and :type suffixes.
lcn, rcn, and so on mix several concepts: Hierarchy, transportation medium and network. I hope this proposal would have make them a little clearer and get rid of network:type=* (to use another suffix than type).
It should be said that Any_tags_you_like recommends Syntactic conventions for naming and they would improve readability and accessibility to new mappers as well here. Fanfouer (talk) 20:54, 17 November 2021 (UTC)

Yes, network=*, cycle_network=* and network:type=* do not directly describe what they are trying to say. It will be difficult to turn that back. network:type=* may not be nice, but the tag is established in connection with node_network (used 172,669 times).

Node networks are characterized by a special form of guidance for cyclists / hikers (cycling / walking by numbers) combined with a structure of the network (network of nodes and connections, which usually forms several meshes).

This proposal is also about a structure combined with a uniform signposting, so it makes sense for me to use a new value for the existing tag.

The point is to show that these paths are part of the officially recommended cycling / hiking network through standardized signposting. In doing so, it must be ensured that they can be distinguished from the (mostly) tourist route recommendations that run via this network.

In principle, it is the purpose of the routes that makes the difference

• The ways are part of a network of nodes and connections that is official recommended for cycling / hiking and is provided with uniform signposting
• The ways are part of a route recommendation with a start and end or as a circular route

What kind of key name do you use there? What do you mean?

route:purpose=basic_network/route_recommendation?

Maybe just simply tag basic_network=yes?

--Jo (talk) 21:08, 19 November 2021 (UTC)

Hi @JochenB:, indeed that will be difficult to change this naming fashion, however that would be useful to provide a more meaningful standard. We should achieve such improvements before it became impossible.

It appears to me that in OSM, many things (not to mention everything) are networks of nodes, the first thing to do is to better qualify what a node really means in hiking, cycling, transportation of any kind. node_network just sounds obvious currently. A railway network is nothing much than a node network just like a hiking one.

Hi, @Fanfouer: The term "node network" is a fixed term from tourism marketing for "cycling / hiking by numbers", at least in Germany. I think they just took it over. Ok from a marketing point of view, but technically the term is at most meaningless, all networks consist of nodes and edges. You can understand everything by it and everything is also understood by it. My attempt in the German forum to limit the meaning of 'node_network' in terms of content resulted in one stubborn backlash, otherwise no interest whatsoever. I hardly think that changes will find acceptance in this regard.

My proposal does not apply to network:type=node_network, so we have deviated from the topic. :).

With more precise naming, comments that are currently raised in different channels would find natural answers. Are those nodes signposts, crossroads, cairns, places?

This is actually not relevant to the proposal. I am only concerned with the difference between the network with signposting and the marked route suggestions. Both are already mapped to a large extent, at least in my area, you just can't tell them apart on the basis of the data. This differentiation is the motivation for the proposal.

But in order not to leave your question behind: Nodes arise where connections of the basic network begin, end, branch or cross.

If you don't mean my proposal but nodes of a 'node_network': There it is the nodes (intersection of the streets) with node numbers, recognizable by special signs with the node number. (example image).

The tagging of node networks is well described in the wiki under Cycle Node Network Tagging, there are excellent tools for analysing it and it is implemented precisely. It's a lot of fun to watch and participate.

To me again, network:type=* actually refers to a kind of level or administrative level (among other things that should be in different keys),

"type" is not self-speaking. It just says that there are distinguishing features between different - otherwise identically tagged - networks. In this respect it can be anything, including an administrative level. So far it has been used to assign a certain type of signage and network structure ('node_network').

My proposal also aims at a network structure with uniform signposting. In this respect, the tag offered itself.

But I think I will change the proposal and propose a completely more self-explanatory tag. Or I will suggest using network relations instead of route relations.

network:level=* (national, regional, local) wouldn't be better?

"level" is better than "type", but there are different levels, not just administrative levels. It can also be the degree of expansion or something similar. Network_administration_level=* would be self-explanatory.

That would be a replacement for network=*cn/*wn and not for network:type=node_network, right?

After several reading of the proposal, I still fail to understand why basic is used in place of unnamed to deal with routes with no name in opposite to named routes. Fanfouer (talk) 15:37, 20 November 2021 (UTC)

For two reasons:

Reason 1: The aim of the proposal is to clearly delimit the signposted basic network with to the suggested routes. This goal cannot be reached with noname=yes, since the route suggestions often do not have a name either.

Reason 2: Because it doesn't get to the heart of the matter. The core of the basic network is

• that the ways are officially recommended for walking / cycling
• that there are uniform hiking / cycling guideposts
• that the ways forms a network of nodes and connections
• that it is differentiated from signposted route recommendations that can run over the basic network. These route recommendations have different types of signposting, often also different target groups, are mostly marketed, have a defined start and end point or form a circular route.

None of this is evident from noname=yes. It's a bit like tagging sign_color=blue instead of highway=motorway.

It was my mistake to put the missing names in the foreground. I have to rewrite the description of the basic network and reduce it to this core. I made an attempt down at Country-specific? Caution!

--Jo (talk) 00:23, 21 November 2021 (UTC)

network:range=* (national, regional, local) would be probably better than network:level=*, surely better than network:range=*

basic is another "non information". You know only nodes, you don't have ways? Just put nodes in the relation. This is the kind of relation? Put signpost= as roles. KISS

--Nospam2005 (talk) 21:34, 22 November 2021 (UTC)

I think that the term "basic" is not devoid of information. But I am open to better suggestions that describe the network better. Unfortunately, I can't think of anything better. "base:networks" contains

1. The route is part of a network, therefore '…_network'
2. This network is the lowest layer in the hierarchy of networks, therefore 'basic_...' in the sense of "basic layer"
3. The purpose of the network is the basic function, which is to officially mark cycle-friendly or hiker-friendly ways with standardized signposts.

The focus of the proposal is on the third aspect, because a tag for this is currently missing. This tag is necessary in order to distinguish it from recommended routes that are provided with route-based signposting. If it were only the first two aspects, there would be no need for a proposal, because there are already possibilities for this.

--Jo (talk) 21:12, 28 November 2021 (UTC)

Neither the concepts of "network hierarchy" nor of "function" are present in the proposal...

--Nospam2005 (talk) 11:52, 29 November 2021 (UTC)

network:type=* is using *:type=* for a data "type", or at least typology. This is closer to type=* in , more acceptable than being a meaningless suffix elsewhere. ---- Kovposch (talk) 07:57, 29 November 2021 (UTC)

Sorry can't follow the entire thread yet: Let me mention there's network:area=* used by a few. ---- Kovposch (talk) 07:57, 29 November 2021 (UTC)

Complexity of the proposal

I think this proposal is far too complex. Basically, you want to emphasize roads and connections if they are chosen for the destination-based signposting. Why not stick to that, and leave all the complexities out. Regular routes, Node Network routes and route-based signposting are not affected, it's just attached to the same poles.

Problem: Marking the ways didn't result in nice rendering and routing on all platforms. So mappers started to put the selected ways in route relations, but they became unmanageable: too many members, certainly not scalable to the whole country.

Solution: Now you want to break this down into a mass of smaller routes, which can be maintained more easily. You define such a route as a connection from one destination-based guidepost to the next. For this to work, you need all the connections between all the official guideposts as routes in the OSM database. Many of those routes will contain only one way; if the connection has turns, on the road this is indicated by a generic cycle sign, and the route relation will contain a chain of ways, as routes usually do.

Comments: I think the guideposts are not essential and can be left out of the routes. Renderers can render them as separate features, and routers just need the preference so they can increase the routing weight. It does not hurt to include the guidepost nodes, but it is a lot of maintenance work and the nodes are generally ignored by data users. The routes have no name and that's fine. No need to indicate that the name is missing when the name is obviously missing. The general network=*cn tag applies. This will enable renderers and routers to emphasize the preferred cycle-connections. So far, nothing is outside the documented mapping schemes.

It will not enable data users to differentiate between these official connections and the other (prescribed, touristic, recreational) route types. If you really really want that, another value for network:type will make that possible. However, when there is also a fully developed Node network in the same area, you will end up with a massive duplication of short routes, differing only in one or two tags. Nodes of the Node_networks will coïncide with the official guideposts, but not all guidpeposts will be Node_Network Nodes. Using a separate tag allows data users to make the distinction and process both aspects as they see fit, within one route relation. If the Node2node route is not exactly the same as the official cycle route, you obviously still need to use 2 different relations.

The hierarchy of networks above the "ground level" of routes is not really necessary, I think, but it can help control and maintenance. It also can hold the names and operators and other important stuff which the end users (cyclists on the road) don't really care about!

Temporary tagging of ways: I would not advertise that, if you want mappers to move to Guidepost2Guidepost route tagging. : Pelderson 19. November 2021, 11:34 Uhr --Pelderson (talk) 11:34, 19 Nov 2021

Thank you for that suggestion. The discussion on the mailing list also shows that the description is too complicated. Your suggestion sounds a lot simpler.

However, I did not want to suggest breaking down large relations. You can do that without a proposal. I just wanted to suggest the tags to distinguish it from. Which again shows that the core of the matter is not sufficiently clear.

It doesn't matter to me whether it is tagged as a relation or directly on the way. I will probably remove the "temporarily" and instead write that you can convert them into relations but not have to.

--Jo (talk) 20:05, 19 November 2021 (UTC)

Country-specific? Caution!

Remark of a more general nature. I often see text emphasizing a special and unique situation in a country. Most of the time the uniqueness is based on country-specific rules "how we do it here", restricting the options. It feels logical to adapt mapping to that. However, in the rest of the world these rules are different; rules may not be country-wide; there may be many exceptions; and rules may change or allow alternatives in parts or in the whole of the country. In my experience, rules like "in our country ALL recreational signposting is ALWAYS done in THIS WAY" should raise all the red flags. Or "The <authoritative body> has issued specifications that all states and localities are supposed to honour". I have read many guidepost and signing specifications that look comprehensive and great, and can indeed be found on the ground... combined with most of the old systems and newer local or regional systems which better suit the local or regional "recreational vision". And I have been around enough to know that this happens in many countries, in Europe at least.

My plea is to NOT base tagging on this kind of country-specific "business rules"and implementations. In this case, Germany appears to want all bicycle signposting to use one integrated system. If you tag the actual guideposts, you can devise a mapping for all the information found on this guidepost feature. But the route tagging should not assume that all routes are found on, and based on, these integrated guideposts; routes use guideposts but also other methods of waymarking. The restriction is not universal, so don't base mapping on it. Do not assume in mapping that other types of recreational routes use the same kind of integrated guideposting.

I plea for global and generic mapping. Routes are everywhere, signposting by destination and by theme is everywhere, paths and roads are everywhere. Many transport methods are not that different when mapping routes: you have the actual ways (including waterways) usually with some kind of signposting, there are routes using a selection of these ways for one ore more kinds of transport, and the routes are split in the categories functional (to get from A to B fast/comfortable) and recreational (doing the route is the goal). So I would be happy if the mapping scheme is NOt specific to Germany, NOT specific to cycling, but globally applicable to all current recreational routing, with room to incorporate other transport methods if and when they arrive. Recreational airway routes? Why not.

Ok, none of this is very concrete, but maybe it helps the proposal if country-specifics are left out, and the texts are reviewed with applicability to other countries and to other transport methods in mind.

I have said.

Pelderson (talk) 08:36, 20 Nov. 2021

(deutsche Version unten drunter)

Thanks. I'll take it up for the revision.

I'll try to describe it generically. However, my examples will come from Germany and Switzerland. It is not possible for me to research the situation worldwide. That's why we're putting it up for discussion here and on the mailing list.

For me, describing generically means not tying it down to a certain type of signpost. In the German cycling network and in the sample images of the hiking networks, the basic network is defined by the destination signposts, the route recommendations by the individual route symbols. That then belongs in the section "Situation of the cycling network in Germany".

It could be different in other countries. For example, a uniform symbol could simply mark the basic network. The route recommendations through signs with the name of the route and perhaps the next place.

I think the following design is generic enough, right ?:

The basic network summarizes ways that are officially recommended for cycling / hiking by means of standardized signposting.

Users can expect that there are better conditions for cycling / hiking here than on ways that are not part of the network. Users should be able to rely on being guided within the network using standardized signposts.

The network can be recognized by the uniform signposting. It connects several destinations and has nodes at which connections of the network branch or cross.

This network is to be differentiated from route recommendations that can run over the network, e.g. B. Themed routes such as "Martin Luther Cycle Path". These route recommendations usually have a symbol and / or a name that can be found on signposts or route markings.

Example German cycle network:

The Basic Network is defined by green or red bicycle signs. At branches in the network or at large intersections, signposts contain destination information, usually to the next place and to the next larger destination (main signpost). At smaller intersections, cyclists are guided by small signs with arrows (intermediate signposts). All signs contain a bicycle pictogram.

The signposted route recommendations in the German cycling network can be recognized by the small symbols that are screwed onto the main signposts of the basic network. Sometimes the symbols can also be found on intermediate signposts.

---

Danke. Das nehme ich auf für die Überarbeitung.

Ich werde versuchen, es generisch zu beschreiben. Allerdings werden meine Beispiele aus Deutschland und der Schweiz kommen. Es ist mir nicht möglich, die Situation weltweit zu recherchieren. Daher stellen wir es ja hier und in der Mailing-List zur Diskussion.

Generisch beschreiben heißt für mich, es nicht an einer bestimmten Art der Wegweiser fest zu machen. Im Deutschen Radverkehrsnetz und in den Beispielbildern der Wandernetze wird das Grundnetz durch die Ziel-Wegweiser definiert, die Routenempfehlungen durch die individuellen Symbole. Das gehört dann in den Abschnitt "Situation des Radverkehrsnetz in Deutschland".

In anderen Ländern könnte es anders sein. So könnte z.B. einfach ein einheitliches Symbol das Grundnetz markieren. Die Routenempfehlungen durch Schilder, auf denen der Name der Route steht und vielleicht der nächste Ort.

Ich denke so ist es generisch, oder?:

Das Grundnetz fasst Wege zusammen, die mittels einheitlicher Wegweisung offiziell für das Radfahren / Wandern empfohlen werden.

Die Nutzer dürfen erwarten, dass es hier bessere Bedingungen zum Radfahren / Wandern gibt als auf Wegen, die nicht Teil des Netzes sind. Nutzer sollten sich darauf verlassen können, innerhalb des Netzes mittels einheitlicher Wegweiser geführt zu werden.

Das Netz ist erkennbar anhand der einheitlichen Wegweisung. Es verbindet mehrere Ziele und hat Knotenpunkte, an denen sich Wege des Netzes verzweigen oder kreuzen.

Dieses Netz ist abzugrenzen von ausgeschilderten Routenempfehlungen, die über das Netz verlaufen können, z. B. Themenrouten wie "Martin-Luther-Radweg". Diese Routenempfehlungen haben i.d.R. ein Symbol und/oder ein Name, die sich an Wegweisern oder Routenmarkierungen wiederfinden.

Beispiel deutsches Radverkehrsnetz:

Das Grundnetz wird durch grüne oder rote Fahrradwegweiser definiert. An Verzweigungen des Netzes oder großen Kreuzungen enthalten Wegweiser Zielangaben, meist zum nächsten Ort und zum nächsten größeren Ziel (Hauptwegweiser). An kleineren Kreuzungen werden Radfahrer mittels kleiner Schilder mit Pfeilen geführt (Zwischenwegweiser). Alle Schilder enthalten ein Fahrradpiktogramm.

Die ausgeschilderten Routenempfehlungen im deutschen Radverkehrsnetz sind an Symbolschildchen zu erkennen, die unten an die Hauptwegweisern des Grundnetzes angeschraubt werden. Mitunter finden sich die Symbole auch an Zwischenwegweisern wieder.

--Jo (talk) 20:27, 20 November 2021 (UTC)

What is really the difference between a node and a basic network ?

For me (hiker in France and Switzerland), I can't distinguish both.

In France we have :

• "Modern" networks
  • Guideposts are named and usually in mountains have an elevation.
  • All intersections with 3 or more routes have a named guidepost.
  • Routes are the "ground" level for other recreational routes.
  • Routes are unamed (or the name is "start - end")
• "Old" networks
  • Guideposts aren't named
  • Some (a lot) intersections don't have any guidepost.
  • Routes are usually named and/or coloured
  • They tend to be modernized

All routes between "Nodes" are official.

A lot of modern networks don't have yet opened data. So, a lot of guidepost are (temporarily) unamed in OSM.

The issue with the actual behaviour of knooppuntnet is that we must "tag for the rendering":

• add a lwn_name=? to "Nodes"
• add a note=? - ? to routes starting from and ending to unamed "Nodes".
• (also adding note=A - A for roundtrip routes)

Another major issue is to use the complicated (and not standard) **xxn_** prefix.
I suggest to use the simple tags ref=* or name=* as possible (and keep using i.e. lcn_ref=* and lwn_ref=* for special cases).

--Pyrog (talk) 09:17, 3 December 2021 (UTC)

A network:type=node_network has labeled Nodes (labeled with numbers, codes, names) which refer to each other, pair by pair, by the Node labels. In between, you follow the Node2Node route markers of the Node network, which may be just an arrow (or e.g. a Gelbe Raute).

The only requirement is that the ways have sufficient access for the transport mode; they do not have to be designated or preferred ways in the OSM sense.

The routes often differ significantly from what a regular router would give, simply because the Node2Node routes are created for a different purpose, often choosing beauty over distance, surface quality or travel time.

The Node network does not signpost end destinations such as a city name, or route numbers/codes/names; it just points to adjacent Nodes.

--Peter Elderson (talk) 11:16, 19 May 2024 (UTC)

What is really the difference between a node and a basic network in 2024 ?

It seem that a basic network is a node network without node ?
The relations seem nearly identical (continuous chain of odered ways).

In France basic network are a collection of connections and/or loops.
They could form a "mesh" but this isn't mandatory. --Pyrog (talk) 09:58, 19 May 2024 (UTC)

In Nederland, as in many other countries in Europe, we have systems of preferred ways for cars, cycling, and walking, usually with their own destination based (unlabeled) signposting styles. For cars, subdivision exist, which for OSM are translated to trunk, motorway, primary etc. For cycling, we have three legal kinds of designated cycleways, we translate that for OSM to highway=cycleway + the generally accepted access values (designated, yes and no, for bicycle, mofa and moped). The recreational Node network uses many paths and roads outside this system of cycleways. The regular destination based signposting system (shortest/fastest/easiest route to ...) uses only a part of all the cycleways, and also other roads and paths. A general router will usually route over the same ways as the regular signposting system, but not over the Node Network. Long distance recreational routes will usually be different from both. Similar systems exist for foot transport.

We do not feel the need or see the benefits of yet another collection of routes to indicate preferential or designated ways.

--Peter Elderson (talk) 21:19, 19 May 2024 (UTC)

The fact is that there is different types of hiking routes in the field (at least in France, Germany…) .

• Nodes network (in practice "routes" network except "few" exceptions)
• Network of routes, with or without guideposts, with or without names, elevation or visible reference for thoses guideposts.

How to map them in OSM ?

• Basic network seem a good tagging scheme, simpler than actual node networks scheme.

--Pyrog (talk) 11:00, 21 May 2024 (UTC)

I think the "basic_network" does not enable Node-based navigation. If on the road Node-based navigation has been implemented for walking/cycling/horse riding, you don't capture that in a "basic_network".

Which means a trip planner application can't output a list of Node labels to navigate along your itinerary, which is the primary function of the Node network.

If a Node network has been rolled out, even if is in that particular region for that particular transport mode, almost the same as a "basic network" would be, I would opt to map the Node network. If you stick to the minimal requirements it's not that complicated. E.g. the network relation is not required. The Node2Node route relations only need the network:type tag and the ref OR name tag (besides the tags required for all route relations). The Nodes also require the network:type tag (eliminating the need for a network relation); the network tag is replaced by the xxn_ref tag OR the xxn_name tag.

I think (not sure if I remember correctly) that for a network with named Nodes you can omit the name and ref tags of the Node2Node routes, correct?

I have just mapped a horse riding Node network in the Veluwe, Nederland, because the operator has placed Node poles, each one pointing to the 'adjacent' network nodes. If I had mapped it as a "basic network" I would have created almost the same number of relations and junction nodes, but we wouldn't have the network planning and navigating function for which the system has been placed in the field.

It's not about getting the objects into OSM, it's about fully capturing the on the ground navigation truth. And we have the universal Node network planner to support that.

--Peter Elderson (talk) 12:37, 21 May 2024 (UTC)

Applications?

Are there applications that show or use the thousands of bicycle route relations tagged as basic_network in Germany?--Peter Elderson (talk) 12:20, 19 May 2024 (UTC)

Tagging without relations

I understand this proposition for beginers but I think that it must be discouraged and used temporarly.
My experienced with this type of tagging for i.e. nordic pistes is that it's a big mess.
--Pyrog (talk) 09:44, 19 May 2024 (UTC)

Separate network / route systems!

The proposal seems to rely on the uniform signposting system in Germany, where signposting for different purposes is combined into one system. Clever, and neat, I do admire the concept!

The signposts integrate:

• A. regular destination based signage, using direction "hands" with printed destinations;
• B. long distance routes (with a name, a code, a number and/or a symbol), using clip-on shields with the code/number/symbol on the direction hands;
• C. Node network signage (with Node labels and next-node pointers) using Node label shields and clip-on shields with next-node pointers on the direction hands.

However, that does not mean that the network systems and routes are necessarily tied each other, or depend on each other. In Germany, they may coincide because, by choice, they all use the same guideposts, but in general the network systems and routes can just as easily use different signposts for all or part of the routes and networks.

Long distance routes can run over the "basic network" and/or the "Node network" and/or other ways.
Node network routes can coincide with or use the basic-network and/or use other ways.

--Peter Elderson (talk) 10:19, 20 May 2024 (UTC)

Distinguishing connections of the basic network from thematic routes

The proposal states: "Without this proposal, it is not possible to distinguish connections of the basic network from thematic routes."

On the road, you follow a thematic route by following its symbol and/or/name and/or ref. You follow a designated section of road or path using the destination-oriented official signs, usually hands on a standardized guidepost. If you do not map sections between "basic network" guideposts as relations, you do not need to distinguish, because only one of them uses relations. So in essence this statement says, the proposal makes itself necessary. Furthermore, if you do map relations, they will be short and without name/ref/symbol, or with different name/ref/symbol.
I think the need to map this 'basic network' as a system of nodes and relations should be expressed in terms of data use and benefit to end users of applications. Then we can weigh the effort against the benefits, and see if the perceived benefits could be effectuated in a simpler or less time consuming way. Think of just using an appropriate network=value and leaving out the nodes. --Peter Elderson (talk) 12:11, 22 May 2024 (UTC)