Knotenpunktnetzwerke

Vielleicht hilft dir das weiter:

http://wiki.openstreetmap.org/wiki/DE:B … etz-Routen

http://wiki.openstreetmap.org/wiki/Radwegenetze

Gruß
surveyor54

Möglicherweise kann man einige Ideen bzgl. des Taggings von den Niederländern übernehmen. Die sind ja mit den Knotenpunktnetzwerken weit vorne.
Als Beispiel sei hier eine (Sammel)Relation gegeben. Diese enthält die Knoten des Netzes, sowie die Verbindungswege (jeweils als einzelne Relationen).

Gruß Hubert

Guten Abend,

Danke für die Links.

Die Links im deutschen Wiki kannte ich schon, trotzdem war der Link von surveyor54 hilfreich: http://wiki.openstreetmap.org/wiki/Radwegenetze.
Vielen Dank auch an Hubert, der mich seinem Link auf den Hinweis gebracht hat, daß Relationen von Knotenpunktnetzwerken keine Sammelrelationen sind, sondern welche man (auf den Teil der Liniensegmente bezogen) als OGC-konformen Datentyp MultiLineString ansehen kann. Gesamt entspricht das wiederum dem Datentyp GeometryCollection (vergleiche http://portal.opengeospatial.org/files/ … t_id=25355 ). Damit tritt wiederum die nicht vorhandende OGC-Kondformität von OSM zu Tage... wann diese mal kommen wird???? api 0.7? 0.8???

Sven... der aber nur an der Oberfläche des Prignitzer Knotenpunktnetzes gekratzt hat.

Guten Abend,

durch Zufall stieß ich darauf, daß in Brandenburg neben dem Landkreis Prignitz auch der Landkreis Barnim ein Knotenpunktnetz hat:

http://www.barnimerland.de/de/radfahren … ystem.html

Sven

streckenkundler wrote:

Gibt es da Erfahrungen und/ oder Beispiele?

Weder noch - nur wenn du dich zufälligerweise ein wenig mit PostGIS auskennen solltest: Dort gibt es ein Schema für Topologien, das genau für so etwas gedacht ist. Hier mal ein Beispiel, was man damit anstellen kann: http://blog.mathieu-leplatre.info/use-p … works.html

Gruss
walter

Hallo Walter,

ja als jemanden mit ArcGis-Erfahrungen sagen mit Topologien was... Sowas mache ich gelegentlich dienstlich... Auch einfache SQL-Kenntnisse habe ich... Vorraussetzungen erst mal nicht schlecht... in meiner Vor-OSM-Zeit hatte ich auch mal PostgreSQL installiert... in der Hoffnung eine alternative zu meinem geliebten FoxPro zu haben... Aber...

Jetzt reizt mich das noch immer, allein die Zeit mich da einzuarbeiten fehlt...

Zur Datenlage... Auf das Knotenpunktnetz Barnim bin ich nur durch Zufall gestoßen, als ich einen Track einer Kollegin als Wanderwegrelation umgesetzt habe (*) und das dann abgefragt habe, weil ich ihn für eine interne Karte brauchte. (Overpass Turbo und BBox)... na und dann noch einige wenige Web-Suchen...

Im Moment habe ich bei den Prignitzern und den Barnimern Knotenpunkten zusätzlich zu tourism=information+ information=guidepost+bicycle=yes geschaut, daß ref='Knotenpunktnumer' sowie network=Knotenounktnetz=* und operator=Landkreis * gesetzt ist. Bei letzteren bin ich mir zwar nicht 100%ig sicher, dürfte aber das am ehesten naheliegende sein.

Ich muß mal sehen, wie ich das einigemaßen ordentlich im Wiki dokumentiert bekomme.

OSM spuckte aber erst mal nur 2 von midestens 99 existenten Knotenpunkten aus... Frustrierend...:( und in der Prignitz ist es ähnlich...:|

(*) Das war das erste mal... ich sollte mir dafür eventuell doch einen Dienst-Accout zulegen.

Sven

Neues Knotenpunktnetzwerk im Aufbau...

Hallo Zusammen,

durch den Tourismusverband Ruppiner Seenland wird seit letztes Jahr ein neues Knotenpunktnetzwerk aufgebaut. Ich stieß gestern auf einen entsprechenden Wegweiser und hatte bei meinen Kollegen im Naturpark Stechlin-Ruppiner Land nachgehakt...

https://www.openstreetmap.org/node/4038231014

Also mal bitte gelegentlich drauf achten...

Sven

-- delete --

Hallo,

ich hole meinen Beitrag mal wieder hoch...
Mittlerweile sind mir vier Knotenpunktnetze in Brandenburg bekannt:
1. Prignitz: Erfassungsstand weiterhin wie oben beschrieben
2. Havelland: 2 erfasste Teilabschnitte; http://www.busev-nauen.de/abschluss-pro … uf-kw.html
3. Barnim: eine Relation über alles, ohne Abschnittsnummern: https://www.openstreetmap.org/relation/3734957 http://www.barnimerland.de/de/radfahren … ystem.html
4. Ostprignitz: diverse Teilrouten erfasst

Gemäß http://www.tourismus-uckermark.de/filea … .03.15.pdf sind weitere in Planung: Landkreise Oberhavel und Uckermark.

Damit hat die nördliche Landeshälfte Brandenburgs Knotenpunktnetze (oder wird haben).

Leider gibt es das Tagging nicht hier, die einzelnen Netze zu unterscheiden.
Beispiel:

Ostprignitz-Ruppin:http://www.openstreetmap.org/relation/5391804
Havelland:http://www.openstreetmap.org/relation/5398296

Man könnte jetzt noch operator=* anfügen. Man weiß aber immer noch nicht, daß es sich um ein Knotenpunktnetzwerk handelt.

Die Holländer haben mit https://www.openstreetmap.org/relation/157868 eine Netzwerk-Relation verwendet.
Nun wird ja immer ins Feld geführt: Relationen sind keine Kategorien.

Solche Knotenpunktwegweisungen bilden aber genau solches Netzwerk mit seinen Teilrouten ab und ich halte derzeit solche Knotenpunktnetzwerke für eine der wenigen Anwendungsfälle dieses Relationstyps.

Im übrigen erstaunt es mich wie wenig bisher davon in OSM Einzug gehalten hat.

Hat jemand weitergehende Ideen?

Sven

Hallo Zusammen,

diesen Beitragfaden mal wieder aufgewärmt...

Sachstand: in Brandenburg haben wir mittlerweile Fahradknotenpunktnetze in folgenden Landkreisen:
1. Prignitz
2. Ostprignitz-Ruppin
3. Oberhavel
4. Barnim
5. Havelland
6. Uckermark (im Aufbau)
7. Elbe-Elster (im Aufbau)

Die Abfrage: http://overpass-turbo.eu/s/DA1 gibt grob die derzeitige Ausdehnung für Brandenburg wieder...

Anmerkungen:

Für die Uckermark konnte ich bisher keine erfassten Knotenpunkte finden, der eine Punkt https://www.openstreetmap.org/node/321828006 stammt von mir und war ein Zufallsfund über Mapilliary: https://www.mapillary.com/map/im/Rtji7oZ_CehoIqkLc1CwEw

Für Elbe-Elster hat User Christopher sehr gut vorgearbeitet, vielen Dank dafür... eigentlich wollte ich ihm ja nur zwei Punkte zuarbeiten. Beim Abarbeiten von anderen Notes und durchsehen von Mapilliary fand ich noch weitere, so daß das der Link hier: http://overpass-turbo.eu/s/DAi den Erfassungsstand wiedergibt.

Die Abfrage http://overpass-turbo.eu/s/DA1 zeigt aber auch, daß Routenabschnitte im Havelland und und im Barnim nicht dargestellt werden (auch wenn sie vorhanden sind). Hier steht diese Information, daß es ein Knotennetzwerk ist, ausschließlich in der Master-Relation: https://www.openstreetmap.org/relation/3734957.
In den drei Landkreisen Prignitz, Ostprignitz-Ruppin und Oberhavel ist dagegen diese Information auch an den Routenbschnitten stets geschrieben: "note:de=Knotenpunktnetz Landkreis Ostprignitz-Ruppin" Beispiel: https://www.openstreetmap.org/relation/7827243. Datentechnisch eigentlich nicht schön, aber immerhin abfragetechnisch kein Problem... Das fehlt aber im Barnim und im Havelland. Im Landkreis Elbe-Elster hab ich es gesetzt, da es noch nicht so sehr viele Relationen waren.

Problem:

Ein mögliches Abfrageszenario wäre:
'Alle Knotenpunkte und Routenabschnitte des Knotenpunktnetzes Landkreis xy ( Geo- und Sachdaten) für Online- und Offline-GIS-Anwendung zu extrahieren.'
Insgesamt halte ich das derzeitige Tagging für uneinheitlich und eine einfache Datennutzung für ein o.g. Anwendungsszenario nicht möglich.

Ich würde es für gut befinden, wenn:

1. Für Knotenpunkte entsprechend Wiki ausschließlich rcn_ref verwendet wird: https://wiki.openstreetmap.org/wiki/DE%3AKey%3Arcn_ref; auch die Holländer verwenden rcn_ref: https://www.openstreetmap.org/node/47138936
2. Für Routensegmente eines Fahradknotenpunktnetzwerkes ein einheitliches Tagging verwendet wird, um es indentifizierbar gegenüber anderen Routenrelationen zu machen. Relationen wie z.B. https://www.openstreetmap.org/relation/8901557 sind schwierig, nur als ausschließliches Knotennetzes darzustellen, da andere Radrouten auch darüber laufen https://www.openstreetmap.org/relation/29203.

Ob das nun weiterhin die note:de=* am Routensegment ist, oder ein separates eindeutiges Tag ist, ist hier eigentlich egal... Ziel muß es sein, diese Relationen der Routensegmente des Knotenpunktnetzes von Routen sonstiger im selben Wegeabschitt erfasster belibiger Radwegrelationen (=Themenradwege) zu unterscheiden... Das nur über eine Master-Relation zu machen halte ich für unglücklich.
3. Das Tagging im Wiki dokumentiert wird.

Schönen Abend,

Sven

Hallo Sven,

wie du schon festgestellt hast ist das Tagging der Knotenpunkte uneinheitlich. Das kommt auch aus dem Wiki heraus, hier gibt es für unterschiedliche Länder auch unterschiedliche Beschreibungen.
Zu dem ganzen Thema habe ich für die kommende FOSSGIS-Konferenz in Dresden einen Vortrag eingereicht.
Die Routen in Elbe-Elster habe ich abgefahren, da ich 3 Knoten auf meine Elberadweg-Tour gesehen habe und dann gelesen haben dass diese 2018 aufgebaut werden. In der Touristinfo vor Ort hatte ich mal nach eine Karte gefragt, dass man einen Überblick bekommt, was alles noch abzufahren ist. Die Dame in der Info wusste auch nicht wann da was kommt, sie ging aber davon aus zum Saisonstart 2019 könnte da was kommen.
Ich habe mal angefangen eine kleine Seite zu bauen, in der alle Knotennetzwerke entsprechend der derzeitigen Spezifikation im Wiki auflistet und Inhaltlich aufbereitet: https://cnn.lorenz.lu/

Christopher

Christopher wrote:

Ich habe mal angefangen eine kleine Seite zu bauen, in der alle Knotennetzwerke entsprechend der derzeitigen Spezifikation im Wiki auflistet und Inhaltlich aufbereitet: https://cnn.lorenz.lu/

Sehr schön 🙂 ist das eine automatische Auswertung?
Für Elbe-Elster muß ich noch die weitere Netzwerksegmente in die Masterrelation aufnehmen.
Mir war so, als wenn Landkeis Spree-Neiße auch an einem Knotenpounktnetz arbeitet... oder es will...

Sven

Hallo Sven, hallo Christopher,
ich beschäftige mich mit dem Tagging des Knotenpunktnetzes radrevier.ruhr.
https://wiki.openstreetmap.org/wiki/Kno … evier.ruhr
Mich stört, dass es verschiedene Taggings gibt. Eventuell führt ja die neue Diskussion zu einer Empfehlung.
Mir käme es sehr entgegen, wenn es für JOSM Vorlagen für das Tagging gäbe.
Gruß
Harald

streckenkundler wrote:

Die Abfrage http://overpass-turbo.eu/s/DA1 zeigt aber auch, daß Routenabschnitte im Havelland und und im Barnim nicht dargestellt werden (auch wenn sie vorhanden sind). Hier steht diese Information, daß es ein Knotennetzwerk ist, ausschließlich in der Master-Relation: https://www.openstreetmap.org/relation/3734957.
In den drei Landkreisen Prignitz, Ostprignitz-Ruppin und Oberhavel ist dagegen diese Information auch an den Routenbschnitten stets geschrieben: "note:de=Knotenpunktnetz Landkreis Ostprignitz-Ruppin" Beispiel: https://www.openstreetmap.org/relation/7827243. Datentechnisch eigentlich nicht schön, aber immerhin abfragetechnisch kein Problem... Das fehlt aber im Barnim und im Havelland. Im Landkreis Elbe-Elster hab ich es gesetzt, da es noch nicht so sehr viele Relationen waren.

Ich halte den note prinzipiell für überflüssig, ist sicherlich für solche overpass Abfragen hilfreich, aber nicht für jeden ist dieser Zweck ersichtlich und die Gefahr der Löschung besteht. Dass es anders geht zeigt Christophers tool
Ich habe aber auch kein Problem wenn jemand die Lust verspürt diese notes einzutragen 😉

Ich würde es für gut befinden, wenn:

1. Für Knotenpunkte entsprechend Wiki ausschließlich rcn_ref verwendet wird: https://wiki.openstreetmap.org/wiki/DE%3AKey%3Arcn_ref; auch die Holländer verwenden rcn_ref: https://www.openstreetmap.org/node/47138936

gibt aber auch https://wiki.openstreetmap.org/wiki/DE:Key:lcn_ref, was ich für die Knotennetzwerke zumindest in meiner Region für sinnvoller erachte da sie vom Landkreis betrieben werden und daher nach https://wiki.openstreetmap.org/wiki/DE: … sifikation als lokale Fahrradrouten zählen

Hallo Sven, Christopher, Harald,

Ich entschuldige mich für diesen Beitrag auf Englisch. Mein Deutsch reicht zum mitlesen, aber Schreiben nicht.

When exploring/mapping bicycle node networks, perhaps my hobbyproject at knooppuntnet.nl (or knooppuntnet.be) can help. This site is intended to assist in quality assurance of node networks in The Netherlands, Belgium and lately also Germany.

The site includes a list of German bicyle node networks.

Here are some example routes and networks mentioned in the forum messages above:
- Route 86-88 in network Landkreis Barnim.
- Network Oberhavel (the analysis does not like the lcn routes in this rcn network).
- Network radrevier.ruhr.
- Node 75 found in Mappilary, not belonging to any network.

The website is usually updated quite soon after changes are made to the OpenStreetMap database. Looking at details of the changes requires login via the OpenStreetMap website.

The intention of knooppuntnet is to apply the rules as described in the English wiki page. These rules mostly match the rules in the German wiki page (example differences: route name in "note" tag, network "name" tag not optional). Currently knooppuntnet only supports regional networks.

Most likely, some changes will be necessary to make knooppuntnet completely useable for Germany. I am open for suggestions.

Gruß aus Belgien,
Marc

bergaufsee wrote:

Ich halte den note prinzipiell für überflüssig, ist sicherlich für solche overpass Abfragen hilfreich, aber nicht für jeden ist dieser Zweck ersichtlich und die Gefahr der Löschung besteht.

Ja... deswegen schrieb ich ja auch:

streckenkundler wrote:

Für Routensegmente eines Fahradknotenpunktnetzwerkes ein einheitliches Tagging verwendet wird, um es indentifizierbar gegenüber anderen Routenrelationen zu machen.

Für das Netzwerk Radrevier Ruhr wird https://wiki.openstreetmap.org/wiki/Kno … evier.ruhr statt note:de cycle_network=* verwendet. Das gefällt mir sehr gut und würde es eben sauber ermöglichen, dieses von anderen Radrouten zu trennen... Das Tagging mit note:de wäre dann obsolet und eine recht leichte Datenabfrage gegeben.

In meinen Augen ist es für die Knotenpunkte Ansichtssache, ob rcn_ref und/oder lcn_ref verwendet wird... lcn_ref würde ich eher sehen, wenn es nur auf einer Teilfläche eines Landkreises angewendet wird. Wenn ich mit aber die Ausdehnung in Brandenburg anschaue, dann ist ein Gebiet defakto vom Havelland bis zur Uckermark komplett und durchgängig von Knotenpunktnetzen abgedeckt. Vielleicht sollte man sich aber auch bei Knotenpunktnetzen von den Einstufungen lcn und rcn lösen und diese separat betrachten. Der Gedanke gefällt mir sehr gut.

Im Ergebnis ist mir eine leichte Abfragbarkeit und Verwendbarkeit der Daten wichtig. Derzeit ist meiner Meinung nach ist diese leichte Abfragbarkeit nicht gegeben, wenn man erst die Master-Relation durchsuchen muß, um dann zu den Segmenten und Punkten zu kommen...

Sven

streckenkundler wrote:

In meinen Augen ist es für die Knotenpunkte Ansichtssache, ob rcn_ref und/oder lcn_ref verwendet wird... lcn_ref würde ich eher sehen, wenn es nur auf einer Teilfläche eines Landkreises angewendet wird. Wenn ich mit aber die Ausdehnung in Brandenburg anschaue, dann ist ein Gebiet defakto vom Havelland bis zur Uckermark komplett und durchgängig von Knotenpunktnetzen abgedeckt. Vielleicht sollte man sich aber auch bei Knotenpunktnetzen von den Einstufungen lcn und rcn lösen und diese separat betrachten. Der Gedanke gefällt mir sehr gut.

Eine separate Einstufung für die Knotenpunktnetze klingt auch nicht schlecht.
Aktuell sehe ich (für D) diese aber definitiv nicht in rcn, "Regionale Fahrradrouten sind in Deutschland die höchste Klassifikation für Routen, die nicht zu den D-Routen gehören." Vergleichbar mit Kreisstraßen, die gibt es auch deutschlandweit und doch bleiben es Kreisstraßen. Eine gewisse Abstufung sehe ich da schon als sinnvoll, wenn ich von Berlin nach Brandenburg (Stadt) oder noch weiter will suche ich vorrangig rcn Routen, will ich nur ins Nachbardorf begnüge ich mich auch mit lcn Routen, wofür ja auch das Knotennetzwerk hervorragend geeignet und möglcherweise auch gedacht ist.
Ich denke eine Unterstützung für lcn in dem tollen tool von Marc sollte auch machbar und keine Hürde sein. 😉

Bernd

bergaufsee wrote:

Eine separate Einstufung für die Knotenpunktnetze klingt auch nicht schlecht.
Aktuell sehe ich (für D) diese aber definitiv nicht in rcn, "Regionale Fahrradrouten sind in Deutschland die höchste Klassifikation für Routen, die nicht zu den D-Routen gehören."

Ich meinte das eher so: es gibt lcn-Routen, rcn-Routen, ncn-Routen, icn-Routen und es gibt als fünfte Klasse Knotennetze (diese nicht weiter differenziert)... In meinen Augen sind Knotennetze separate und nicht wirklich differenzierbare aber extra ausgeschilderte Basisradnetze. Letztendlich tritt dann ja auch der Effekt auf, daß ich immer Teile des Knotennetzes nutze, wenn ich zum Beispiel die Tour Brandenburg in der Prignitz beradele. Ich bin der Meinung, daß in Knotennetz-Bereichen andere ausgeschilderte Radweg-Routen, egal ob lcn, rcn, ncn oder icn stets über eben dieses Knotennetz geführt werden. Daher als separate Gruppe...

Sven

streckenkundler wrote:

Ich meinte das eher so: es gibt lcn-Routen, rcn-Routen, ncn-Routen, icn-Routen und es gibt als fünfte Klasse Knotennetze

hatte ich auch so verstanden und finde die Idee eine ernsthafte Überlegung wert 🙂
ich hätte nach meinem ersten Satz nicht nur einen Zeilenumbruch sondern neuen Absatz machen sollen, denn da habe ich nur meine Sicht auf die vorhandenen Klassifikationen erläutert.

Hallo,
das Auswertewerkzeug von Marc ist eine große Hilfe. Bedankt! Hier seine Auswertung für radrevier.ruhr:
https://knooppuntnet.nl/nl/network-facts/7592211
Das Netzwerk ist noch im Aufbau. Deshalb ist es wichtig, zu einem einheitlichen Taggingschema zu kommen. In einem ersten Schritt werde ich für die Routen network=rcn verwenden.

Bei der Beschäftigung mit dem Thema habe ich festgestellt, dass auch Routen/Knoten in Deutschland Bestandteil von niederländischen Knotennetzen sind:
https://www.openstreetmap.org/node/274312858
Mir gefällt das!
Z.B. kann mit dem Routenplaner auf route.nl über die Grenze hinweg eine Planung gemacht werden. Also: warum nicht die Erfahrung der Nachbarn nutzen. Bin gespannt, was der von radrevier.ruhr angekündigte Planer leistet.
Einen schönen Tag wünscht
Harald

Hallo,
ich habe ausgehend von den Facts in https://knooppuntnet.nl/en/network/7592211 für radrevier.ruhr (https://www.openstreetmap.org/relation/7592211) viele Dinge an die Gegebenheiten in NL und BE angepasst. Ein besonderer Dank gilt Marc. Hier die wesentlichen Änderungen.

1. network von lcn in rcn geändert
2. rcn_ref=xx-yy in note=xx-yy umgesetzt, rcn_ref gelöscht (Marc hat das gemacht)
3. note in allen Routen so geändert, dass die erste Knotennummer kleiner ist als die zweite
4. ways in den Routenrelationen sortiert

Das hat die Anzahl der Facts deutlich reduziert. Und hier das Resultat:

1. Eine Karte mit dem Netzwerk: https://knooppuntnet.nl/en/network-map/7592211
2. Schön finde ich auch die Visualisierung von Änderungen: https://knooppuntnet.nl/en/changeset/64729784/3244464 Um sie anzuschauen, muss man sich bei OSM anmelden.
3. Anzeige der fehlerhaften Routen, z.B.: https://knooppuntnet.nl/en/route/8883442

Eine Aufstellung aller Radroutennetze in D ist zu finden unter:

https://knooppuntnet.nl/en/networks/de/rcn

Lust die Knotenpunktwegweisung Oberhavel https://www.openstreetmap.org/relation/7832319 anzupassen?

Hier eine grobe Skizze, wie man das machen könnte.

1. In JOSM die Erweiterung Scripting installieren
2. Overhavel herunterladen:

[out:xml][timeout:125];
(
rel(id:7832319);
);
(
rel(r)[network!="rcn"];
node(r)[rcn_ref];
);
(._;>;);
out meta;

3. In Josm eine oder mehrere Routen im Relationenfenster auswählen.
4 Folgendes in die Scripting-Konsole kopieren:
var selectedObjects = josm.layers.activeLayer.data.getSelected().iterator();
while (selectedObjects.hasNext()) {
var obj = selectedObjects.next();
var objKeys = obj.getKeys();
var networkKey = 'network';
if (objKeys.get(networkKey) == 'lcn')
{
objKeys.put( networkKey, 'rcn');
obj.setKeys(objKeys);
obj.setModified(true);
}
}
und ausführen.

Der Code ohne Gewähr. Ich denke, dass es jemanden im Forum gibt, der das Script prüft und auch noch Plausibilitätsprüfungen einbaut.

Gruß
Harald

hfwri wrote:

Eine Aufstellung aller Radroutennetze in D ist zu finden unter:

https://knooppuntnet.nl/en/networks/de/rcn

Danke... gefällt mir. Ich habe mal Landkreis Elbe-Elster angepasst... Wenn ich das bei knooppuntnet richtig sehe, dürfte dann Elbe-Elster auch mit auftauchen?
Ich hab hier das den Inhalt von note:de nach cycle_network verschoben. cycle_network wird ja bei radrevier Ruhr auch verwendet und mit dem Tag kann man gut die Netzwerkrouten von sonstigen Radwegwouten unterscheiden.

Sven

Nun sind wir also hier auch so weit flächendeckend die Meinung verschiedener regionaler user zu ignorieren und z.B. mal eben sämtliche Routen auf rcn umzuschreiben, nur damit es im tool von Marc schick aussieht. Keine Frage, das tool ist toll, ist aber evtl. nicht für alle Belange ausgelegt und ließe sich sicherlich anpassen. Statt Argumente auszutauschen wird halt gehandelt, na ja.
Christopher z.B. hatte dargelegt dieses Thema auf der FOSSGIS anzusprechen, ich hätte es gut gefunden bis dahin zumindest solch gravierende überregionale Änderungen zu unterlassen und abzuwarten ob es dort neue Ideen gibt, stattdessen werden schon wieder vollendete Tatsachen geschaffen. Genau mit dieser Vorgehensweise habe ich so meine Probleme, nicht dass ich nicht kompromissbereit bin, aber nicht so ...
Bernd

Laut Wiki ist rcn aber richtig oder?

Regionale Fahrradrouten (network=rcn)

Regionale Fahrradrouten sind in Deutschland die höchste Klassifikation für Routen, die nicht zu den D-Routen gehören. Sie sollten in mehreren Tagesetappen zu befahren sein und mehrere Bundesländer oder Regionen durchqueren.

Lokale Fahrradrouten (network=lcn)

Lokale Fahrradrouten sind Fahrradrouten innerhalb eines Landkreises oder einer Gemeinde. Sie können in einer Tagesetappe befahren werden und werden von einer einzelnen Organisation betrieben.

Bei Fahrradknotenpunktnetzwerken ist nicht die Länge der einzelnen Relation für network=* ausschlaggebend, sondern die Größe des gesamten Netzwerkes. Umfasst ein solches Netzwerk z.B. mehrere Bundesländer oder Regionen, so sind alle Routen mit network=rcn zu taggen. Das betrifft dann auch sehr kurze Routen im Netz, wenn z.B. beide zugehörigen Knotenpunkte innerhalb eines Ortes liegen.

chris66 wrote:

Laut Wiki ist rcn aber richtig oder?

sehe ich nicht so,

Bei Fahrradknotenpunktnetzwerken ist nicht die Länge der einzelnen Relation für network=* ausschlaggebend, sondern die Größe des gesamten Netzwerkes. Umfasst ein solches Netzwerk z.B. mehrere Bundesländer oder Regionen, so sind alle Routen mit network=rcn zu taggen. Das betrifft dann auch sehr kurze Routen im Netz, wenn z.B. beide zugehörigen Knotenpunkte innerhalb eines Ortes liegen.

die Größe der jeweiligen Netzwerke welche sich aus den einzelnen Routen-Relationen zusammensetzen sind durch den operator definiert und die sind eben die jeweiligen Landkreise, nicht das gesamte deutsche Knotenpunktnetzwerk ist hier gemeint, denn es heißt ja nicht ohne Grund z.B. Knotenpunktwegweisung Havelland.
Ich weiß nicht wie es in den Niederlanden ist, daher kann es ja dort durchaus auch richtig sein.

bergaufsee wrote:

chris66 wrote:

Laut Wiki ist rcn aber richtig oder?

sehe ich nicht so,

Ich schon...

bergaufsee wrote:

Bei Fahrradknotenpunktnetzwerken ist nicht die Länge der einzelnen Relation für network=* ausschlaggebend, sondern die Größe des gesamten Netzwerkes. Umfasst ein solches Netzwerk z.B. mehrere Bundesländer oder Regionen, so sind alle Routen mit network=rcn zu taggen. Das betrifft dann auch sehr kurze Routen im Netz, wenn z.B. beide zugehörigen Knotenpunkte innerhalb eines Ortes liegen.

die Größe der jeweiligen Netzwerke welche sich aus den einzelnen Routen-Relationen zusammensetzen sind durch den operator definiert und die sind eben die jeweiligen Landkreise, nicht das gesamte deutsche Knotenpunktnetzwerk ist hier gemeint, denn es heißt ja nicht ohne Grund z.B. Knotenpunktwegweisung Havelland.
Ich weiß nicht wie es in den Niederlanden ist, daher kann es ja dort durchaus auch richtig sein.

Die Definitionen im Wiki, wann welche Klassifikation für Knotennetzwerke verwendet werden soll, sind aber so Wage, wie unbrauchbar. Gerade das (zusammengesetzte) Knotennetzwerk in Mittel- und Nordbrandenburg zeigt, daß man in dem entstandenen Knotennetzwerk geschlossen von der Havel über Elbe, Stepenitz, Dosse, wieder zur Havel, die Uckermark streifend und den Barnim querend zur Oder radeln kann... Solche zusammengesezten Knotennetze kan man nicht mehr nach lokal, regional oder was weiß ich differenzieren... Es ist allgemein ein Radknotennetzwerk unterschiedlicher Betreiber und fertig!

Übrigens, wie definiert man den im Wiki verwendeten Begriff " Region"? Um es nur auf den Landkreis Havelland zu begrenzen, würde ich schon den Havelbereich als solches und z.B. Nauener Platte oder Ländchen Glien jeweils als unterschiedliche Regionen definieren. Ähnlich ließe es sich auf die anderen Landkreise anwenden.

Darum bin ich der Meinung, ausgeschilderte Radknotennetze völlig von den Einstufungen lcn, rcn, ncn und icn abzukoppeln sind und als eine eigene, nicht weiter differenzierbare Einheit betrachtet werden müssen! Bei Radknotennetzen ergibt es sich von der Sache heraus, daß sich diese durch Verbindungsrouten auf Nachbarkreise und -regionen ausdehnen und es sich ein großes Netzwerk ergibt.

Sven

streckenkundler wrote:

bergaufsee wrote:

chris66 wrote:

Laut Wiki ist rcn aber richtig oder?

sehe ich nicht so,

Ich schon...

Die Definitionen im Wiki, wann welche Klassifikation für Knotennetzwerke verwendet werden soll, sind aber so Wage, wie unbrauchbar. Gerade das (zusammengesetzte) Knotennetzwerk in Mittel- und Nordbrandenburg zeigt, daß man in dem entstandenen Knotennetzwerk geschlossen von der Havel über Elbe, Stepenitz, Dosse, wieder zur Havel, die Uckermark streifend und den Barnim querend zur Oder radeln kann... Solche zusammengesezten Knotennetze kan man nicht mehr nach lokal, regional oder was weiß ich differenzieren... Es ist allgemein ein Radknotennetzwerk unterschiedlicher Betreiber und fertig!

Deine Meinung, nicht mehr und nicht weniger, das akzeptiere ich auch, bitte akzeptiere im Gegenzug auch die Meinung anderer user.

Übrigens, wie definiert man den im Wiki verwendeten Begriff " Region"? Um es nur auf den Landkreis Havelland zu begrenzen, würde ich schon den Havelbereich als solches und z.B. Nauener Platte oder Ländchen Glien jeweils als unterschiedliche Regionen definieren. Ähnlich ließe es sich auf die anderen Landkreise anwenden.

Die Definitionen im wiki sind bekanntermaßen an vielen Stellen ungenau, hat auch teilweise Sinn da es nicht immer nur schwarz/weiß gibt. Nehmen wir viele lokale Radrouten im Speckgürtel Berlins, die fahren oft sogar durch zwei Bundesländer, sollen wir die nun alle hart nach wiki zu rcn machen obwohl sie so kurz sind dass sie als Tagesetappe abzufahren sind. Oder z.B. die (noch nicht vollständig eingepflegte) Otto-Lilienthal-Route mit 259 km Länge, führt durch mehrere Landkreise, hatte ich daher ursprünglich als rcn eingebaut, wurde von einem anderen user als lcn herabgestuft. Eigentlich doch auch falsch. Da bleibt hier nicht mehr viel übrig für lcn.

Darum bin ich der Meinung, ausgeschilderte Radknotennetze völlig von den Einstufungen lcn, rcn, ncn und icn abzukoppeln sind und als eine eigene, nicht weiter differenzierbare Einheit betrachtet werden müssen! Bei Radknotennetzen ergibt es sich von der Sache heraus, daß sich diese durch Verbindungsrouten auf Nachbarkreise und -regionen ausdehnen und es sich ein großes Netzwerk ergibt.

Für eine separate Einstufung hatte ich dir bereits meine Zustimmung gegeben!

Ich fasse noch mal zusammen:
Im Gegensatz zu dir sage ich nicht, dass meine Meinung DIE Lösung bietet und setze diese über die Köpfe anderer user überregional um.

Mein Ansatz ist auch folgender: Vergleichbar mit den Straßenklassifizierungen ergibt sich wenn man auf einer Karte nacheinander Autobahnen - Bundesstraßen - Landstraßen - Kreisstraßen... einblendet ein immer dichter werdendes Netz. Ein ähnliches Bild sollte sich mit den Radrouten von icn bis lcn ergeben, wenn aber die Knotenpunktnetzwerke alle schon rcn sind ist hier Schluß, da soweit ich mich entsinne sämtlich lokale Routen auf den Wegen der Knotenpunktwegweisung liegen (sofern vorhanden).

Meine Meinung, nicht mehr und nicht weniger.
Bernd

bergaufsee wrote:

Deine Meinung, nicht mehr und nicht weniger, das akzeptiere ich auch, bitte akzeptiere im Gegenzug auch die Meinung anderer user.

ja...

bergaufsee wrote:

Die Definitionen im wiki sind bekanntermaßen an vielen Stellen ungenau, hat auch teilweise Sinn da es nicht immer nur schwarz/weiß gibt.

an irgendwas müssen wir uns aber entlang hangeln, um zu einem Ergebnis zu kommen...

bergaufsee wrote:

Nehmen wir viele lokale Radrouten im Speckgürtel Berlins, die fahren oft sogar durch zwei Bundesländer, sollen wir die nun alle hart nach wiki zu rcn machen obwohl sie so kurz sind dass sie als Tagesetappe abzufahren sind. Oder z.B. die (noch nicht vollständig eingepflegte) Otto-Lilienthal-Route mit 259 km Länge, führt durch mehrere Landkreise, hatte ich daher ursprünglich als rcn eingebaut, wurde von einem anderen user als lcn herabgestuft. Eigentlich doch auch falsch. Da bleibt hier nicht mehr viel übrig für lcn.

Sicher... aber... 🙂

Die Otto-Lilienthal-Route mit 259 km Länge hätte ich jetzt auch als rcn eingestuft... als lcn-Routen würde ich solche sehen, die in Gänze an einem Tag zu schaffen sind... unsere Gurke (=Gurkenradweg) hat in der erfassten Länge 267km, wenig mehr als die Otto-Lilienthal-Route und mir ist kein normaler Mensch bekannt, der die Tour an einem Tag in eine Ritt abradelt.. Diese Touren sind als 2-4-Tagestouren ausgelegt, z.B. mit 2-3 Übernachtungen, um die ganze Tour zu schaffen und so muß man sie auch betrachten (Kampfradler blenden wir hier mal aus). Meine Eltern haben an der Radoute ihren Garten und treffen oft Leute, die die Gurke beradeln und kundtun, wo sie ihre nächste Unterkunft haben.
Auf der anderen Seite: wenn wir die Knotennetzrouten nach lcn verschieben (wäre ein leichtes), ist lcn wiederum völlig überrepräsentiert und die recht wenigen echten lcn-Routen gehen dann völlig unter...
Ich befürchte ja auch, es gibt recht wenige echte lokale Radrouten, die als 1-Tages-Touren konzipiert sind, da es lukrativer ist einen Radtourist mit längeren Touren länger in Region zu halten.

Beispiele:
Rund um den Grimnitzsee: https://www.openstreetmap.org/relation/8196047 14km:nicht klassifiziert, würde ich als lcn ansehen.
Schwielochsee-Radweg: https://cycling.waymarkedtrails.org/#route?id=4082369 35km: den hab ich zwar mal als rcn erfasst, betrachte das aber mittlerweile als Fehler und sehe lcn als korrekt an.
Krämer Forst-Tour: https://cycling.waymarkedtrails.org/#route?id=4112715 57km

kurz um:

ich sehe als Lösung derzeit:

1. ein mitunter vorhandenes Radknotennetz als Basis für lokale, regionale (ect.) Radrouten eines/ mehrerer Landkreise mit Kreisübergreifenden Verbindungen
2. lokale Radrouten, die in der Regel als 1-Tages-Tour in Gänze zu schaffen sind (mein Gefühl sagt hier, daß die Grenze bei maximal 80-100km liegt)
2. regionale Routen, die als Mehr-Tages-Touren ausgelegt sind, um sie in Gänze zu schaffen. Diese können (nicht müssen) Bundeslandübergreifend sein (in meiner Region z.G. Gurkenradweg, Historische Stadrkerne 6, Spreeradweg)
3. nationale Routen: verbinden mindestens 2-3 Bundesländer... (ich sehe z.B. den Berlin-Usedom-Radweg durchaus als ein der Kandidaten (obwohl als rcn erfasst): https://cycling.waymarkedtrails.org/#route?id=27727. Der eben genanten Spreeradweg wäre auch eine Disskussion wert, ob der nicht eher ein ncn wäre, da bin ich mir unsicher.

Das hat sich für mich in der Gesamtbetrachtung der Knotennetze der Nordhälfte Brandenburgs herauskristallisiert...

Sven

chris66 wrote:

Lokale Fahrradrouten sind Fahrradrouten innerhalb eines Landkreises oder einer Gemeinde. Sie können in einer Tagesetappe befahren werden und werden von einer einzelnen Organisation betrieben.

Völlig einig! Alles, was da in NRW auf Kreisebene passiert, ist laut Wiki-Definition lcn. Leider hat sich eingebürgert, alles als rcn zu taggen. Damit verschwinden die landesweiten Fernwege im Gewusel lokaler Wege, die zu rcn hochgejazzt wurden.

Der Vergleich mit den Niederlanden verwirrt eher, weil es in dem kleinen Land diese Unterscheidung lcn/rcn nicht gibt, siehe auch Proposed_features/Node_Networks.

Wie sind die guidepost zu taggen?
Die Kollegen aus Ulm/Neuulm haben auf ihrer Seite
https://wiki.openstreetmap.org/wiki/Rad … lm/Neu-Ulm
das Beispiel:
„direction_east=Senden 9.3km;Ludwigsfeld 4.5km“
aufgeführt, hier also zwischen der Zahl der Entfernung und den „km“ sowie nach dem Strichpunkt kein Leerzeichen.
Auf der Seite
https://wiki.openstreetmap.org/wiki/DE: … Dguidepost
ist am Ende der Tabelle aufgeführt:
„Dient der Wiedergabe der auf dem Wegweiser zu findenden Angaben.
Mehrfachangaben pro Richtung ggf. durch Semikolon trennen.
Rechtschreibfehler sollten übernommen werden (ggf. mit note=* darauf hinweisen).
Beispiel: direction_east=Icksdorf 13 km; Zettstetten 5.9 km“
Hier also zwischen der Zahl der Entfernung und den „km“ sowie nach dem Strichpunkt jeweils ein Leerzeichen.
Auf keinem von mir bisher überprüften Wegweiser (guidepost) habe ich die Buchstaben „km“ gefunden. Ich habe deshalb vor, in meinem Mappingbereich das „km“ zu entfernen, wie ich es andernorts auch schon gesehen habe und bei mehreren Zielen einer Richtung nach dem Strichpunkt ein Leerzeichen einzufügen.
Spricht etwas dagegen?

GerdHH wrote:

Damit verschwinden die landesweiten Fernwege im Gewusel lokaler Wege, die zu rcn hochgejazzt wurden.

andererseits werden bei Verwendung von lcn diese völlig überrepresentiert und eigenliche lcn-Routen gehen unter. Mittlerweile plädiere ich für Knotennetzwerke für eine eigene Klasse: z.B. network=cnn (Cycle-Node-Network)

Sven

ghostrider44 wrote:

Wie sind die guidepost zu taggen?

in meinen Augen ist es ausreichend, daß es ein Wegweiser ist, ob es einer nur für Rad- oder auch für Wanderruten ist, und welche Knotenpunktnummer es ist und dann diesen mit in die Route aufgenommen... Weitere Angaben sind zwar nett, in meinen Augen aber nicht sinnvoll auswertbar.

Sven

Wegweiser: Meist wird man auf einen Pfahl verschiedene Schilder für Wanderer und Radfahrer schrauben. Wenn man es wirklich getrennt taggen will, gibt es ja noch foot=yes.

Nochmal zu der lcn/rcn-Debatte. Wenn in Berlin (oder Hamburg) die Stadt- und damit Landesgrenze überschritten wird, wäre es überformal, das als Argument für "rcn" zu nehmen -- oder noch extrener: in Grenzgebieten drei Kilometer lange Grenzpfade gleich als icn auszuweisen. Es geht doch, wie bei Kreis-, Landes und Bundesstraßen darum, Wege von örtlicher, regionaler und bundesweiter Bedeutung zu trennen. Auch wenn man sich von Flensburg bis Füssen theoretisch auf Kreisstraßen bewegen könnte, bleiben sie doch Wege von örtlicher Bedeutung. Wenn Radwege für Strecken von einem Tag gedacht sind, sind sie meiner Meinung nach lcn. Das gilt für alle mir bekannten Knotennetzwerke. Selbst wenn das Land NRW beschließen würde, alle Kreis-Knotennetzwerke zentral durchzunummerieren, würden daraus keine landesweiten Wege werden. Das wären für mich nur Fernradwege wie Hamburg-Rügen oder Berlin-Usedom, und es wäre gut, wenn diese auf Karten getrennt dargestellt würden.

Als eine weitere Ausnahme würde ich Radschellwege als rcn herausheben. Das ist sogar formal richtig, weil sie zentral vom Land finanziert und geplant werden (bei örtlicher Umsetzung, aber das ist bei Autostraßen auch so). Wenn wir jemals ein ganzes Netz von Radschnellwegen bekommen sollten, könnten die Knoten auch als rcn_ref getaggt werden. Und wie bei Autobahnen, würde sich das Netz deutlich von den örtlichen Wegen abheben.

Bei der Beschäftigung mit Knotenpunktnetzen, ist mir aufgefallen, dass es Netzwerke gibt, die sehr ähnlich sind:

z.B.: Relation: Knotenpunktnetz (SO) Kreis Soest (7708434)
https://www.openstreetmap.org/relation/7708434

und Relation: Knotenpunktnetzwerk Kreis Soest (5916006)
https://www.openstreetmap.org/relation/7708434

Der wesentliche Unterschied: in der 7708434 sind Hin- und Rückweg enthalten und in 5916006 nicht. Ist 5916006 das zuerst entstandene Netzwerk? Hier ein Vergleich der beiden Netze basierend auf den Wegen:

//␣Kreis␣Soest
relation(id:5916006);
rel(r)->.ka;
way(r.ka)->.k1;

//(SO)␣Kreis␣Soest
relation(id:7708434);
rel(r)->.kb;
way(r.kb)->.k2;

(
.k2;␣-␣.k1;
)->.d1;

(.d1;>;);
out␣skel␣qt;

{{style:
way␣{
color:␣red;
}

node
{
color:blue;
symbol-size:␣3;
}
}}

Kann eventuell eine gelöscht werden und wenn ja welche?

Das ist nur ein Beispiel. Es gibt noch weitere Netzwerke, die scheinbar doppelt sind:

https://knooppuntnet.nl/en/networks/de/rcn

Gruß
Harald

Hei,

Ich aktualisiere mal die Liste:

Der Landkreis Spree-Neiße hat nun auch ein umgesetztes Knotenpunktnetzwerk:

https://www.lr-online.de/lausitz/forst/ … d-37969399

Mir ist aber noch keine Erfassung vor Ort bekannt?

Sven

Moin!

Im LK Vechta gibt es nun auch ein Netzwerk, welches uber den Sommer eingetragen wird. Ich bin aber nicht sicher, über die Einstufung. Da es durch den LK Vechta betrieben wird habe ich es als "lcn" gekennzeichnet. Klar ist auch , das Netzwerke, die direkt als Verbund betitelt sind in die Kategorie "rcn" fallen.
[siehe https://www.openstreetmap.org/relation/9447784]
Wie ist den nun der aktuelle Konsens bezüglich der Einstufung von Fahrradknotenpunktsystemen?

MFG

Tyran

Tyran wrote:

Wie ist den nun der aktuelle Konsens bezüglich der Einstufung von Fahrradknotenpunktsystemen?

so richtig gibt es leider keinen...

Ich hab ja mit Knotennetz Landkreis Elbe-Elster und Spree-Neiße zwei in meiner Umgebung und hab hinreichend Übersicht über Themen-Radrouten, die zugleich über die Knotennetze geführt werden...
In meinen Augen kollidieren die Themen-Radrouten immer mit dem jeweiligen Knotenpunktnetz und deren Erfassung sowohl mit lcn oder auch mit rcn... Ich bin mittlerweile überzeugt, daß Fahrradknotennetze eine völlig eigene Klasse darstellen, die (eigentlich) nicht als rcn oder lcn zu erfassen sind... Das wird deutlich, wenn man sich Netzwerke anschaut, die in der weiteren Erfassung mehrere Kreise überspannen... und sich dann in dem Zusammenhang die Themenradrouten anschaut.

Mein Favorit ist noch immer network=cnn (cnn=cyclenodenetwork)
Aber eigentlich braucht man diese Netzwerkrelationen nicht unbedingt... ich hänge an die Knotenpunkte und vor allem an die Relationen zwischen den Knoten stets ein cycle_network=* Das reicht eigentlich schon, um alles abzufragen...

Sven

LS Sorry, I have to do this in English, mein Deutch reicht nicht!

In die Niederlände we are going to change course. We had taken network=rcn to mean bicycle node network, rwn for walking node network and so on.
We now recognise this causes several problems, zum Beispiel:
- We couldn't tag regular (chain-of-ways) routes any more, you just didn't see them any more because of the many node routes.
- They were still rendered as regional routes, i.e. at a much higher zoomlevel than we want
- Our country can get by with 3 ranges local, national and international for regular routes, but other countries really miss the regional level.
- It looks like node networks too are emerging a local, regional and national level.

It is now widely recognised that node networks need to be separated from other types of network.

Our solution is the following:

We will add a tag network:type=node_network to all the nodes, node2node routes and node netwerk relations. Nothing else needs to change.

Then rcn can really mean regional cycling route again. If the network:type=node_network tag is also present, the route is a node route.

In addition, lcn node_networks can be defined. I have already seen some in Germany.

We did some testing already. After the addition of the tag, nothing changes for current data users. But once the tagging is done, they will have the opportunity to separate node networks and regular routes for rendering, export, checking tools and planning/routing tools. Tagging presets for JOSM are being made.

This is a generic solution for node networks for all modes of transport and all geographical ranges. It leaves current tagging intact. I think it essentially does the same job as cycle_network=* but it is applicable to all node networks.

Note that this solution also leaves room for other types of network configurations/setups. E.g. we already spotted colour-choice networks, and maybe regular linear routes could be separated from the (super)routes containing loads of variants, shortcuts, extra loops etcetera. But that's for later.

We are in contact with waymarkedtrails and vmarc, they both have stated that this would help them and they will render/process it once it's documented.
We plan to do just that very soon.

I hope this helps?

Guten Abend,

ich hole das Thema mal wieder hoch. In Bezug auf meines issues https://github.com/waymarkedtrails/waym … issues/322 hat mich Peter Elderson über Github informiert:

Seitens der Niedländischen(und belgischen) Gemeinschaft ist die Entscheidung getroffen worden, den Tag
network:type=node_network

an Knotenpunkten
an den Relationen zwischen den Knotenpunkten
an das Knotenpunktketzwerk selbst

zu ergänzen.

siehe auch: https://forum.openstreetmap.org/viewtop … 88#p761988
und: https://forum.openstreetmap.org/viewtop … 15#p762015
und: https://github.com/waymarkedtrails/waym … issues/322

Ich persönlich bin überzeugt, daß das die aller beste Lösung ist. Es ist keine grundlegende Änderung am Tagging nötig, nur eine Ergänzung (!!!). Dieses Tagging ermöglicht bei Bedarf auch eine Nutzung für alle weiteren Freizeitrouten (Wandern, Reiten; lokal, regional, national... ect.).

Ich unterstütze das ausdrücklich und beteilige mich gerne an der Erweiterung und Ergänzung des Taggings und falls nötig auch an der Dokumentiation im Wiki.

Sven

Status report
All elements of all recreational node networks in the Netherlands now have the tag network:type=node_network. The maintenance site https://www.knooppuntnet.nl is being modified to check for the tag.
I think it is up to the German and Belgian communities to add the tag to ‘their’ node networks. Of course, we would be glad to help out, when asked.

Hi Peter.

Thanks for your status report. I do not think that this supplement should be a problem in Germany either.
Sven

Hallo Zusammen,

in Ergänzung zu Peter Eldersons Status-Report würde ich gerne die brandenburgischen Knotenpunktnetze analog zu den Niederländern ergänzen (keine Änderung bestehender Tags!).

Das betrifft in Brandenburg folgende Knotennetze:

Landkreis SPN: https://www.openstreetmap.org/relation/9681847
Landkreis EE: https://www.openstreetmap.org/relation/8801845
Landkreis PR: https://www.openstreetmap.org/relation/7787125
Landkreis HVL: https://www.openstreetmap.org/relation/6863562
Landkreis OPR: https://www.openstreetmap.org/relation/7801259
Landkreis OHV: https://www.openstreetmap.org/relation/7832319
Landkreis UM: https://www.openstreetmap.org/relation/9574712
Landkreis BAR: https://www.openstreetmap.org/relation/3734957

sowie alle, ausschließlich die in diesen Netzen erfassten Knotenpunkte und Knoten-zu-Knoten-Relationen.

Siehe auch https://github.com/waymarkedtrails/waym … issues/322

Da das in den Bereich eines Massenedits gehen würde: was wäre noch zu beachten: Mailing-Liste Deutschland, noch was?

Doku im Wiki... solche Knotennetze dürften nur im Bereich BeNeLux und Deutschland zu finden sein.

Sven

I know vmarc was waiting for this move to start handling of German cycling, walking and horse riding node networks. Up to now the problem was that he had to make lots of exceptions because the network types were mingled.
He is working on the site now, so I think a sort of planning would help things along!

I want to wait a few days before I start. I know that it is heading in the direction of mass editing.
That's why I announced it on the German mailing list.

Here in Brandenburg, I only know about cycle node networks.

I had looked at some of your networks on a random basis. Here in Brandenburg, they are likely to be as well as you are. I don't think there will be any great problems.

When I work through the network relations one at a time, I should catch all nodes and node-to-node relations.

Do you know this maintenance site? https://www.knooppuntnet.nl/en/networks/de/rcn

Peter Elderson wrote:

Do you know this maintenance site?

Yes, of course! But the site has also been quite supplemented...
By the way... another district (the ninth) in Brandenburg will also get a bicycle node network next year...

So...

Alle Knotenpunktnetze in Brandenburg sind entsprechend unser Niederländischen Kollegen ergänzt. In Folge dessen habe ich, soweit es mir möglich war, auch Verbesserungen und Ergänzungen gemacht. Die Seite https://www.knooppuntnet.nl/en/networks/de/rcn ist da wirklich genial. Danke ans Nachbarland!!

Da meiner Beobachtung nach die Netze nicht komplett erfasst sind, ist die Fehlerquote noch recht hoch. Hier in Südbrandenburg sind die beiden Netze eh man gerade erst mal errichtet. Ein weiteres soll ab September hinzukommen: Landkreis Oberspreewald- Lausitz.

Soweit ich es beobachtet habe, dürften Deutschlandweit etwa 30% der Netze ergänzt worden sein...

Sven

streckenkundler wrote:

Ich befürchte ja auch, es gibt recht wenige echte lokale Radrouten, die als 1-Tages-Touren konzipiert sind, da es lukrativer ist einen Radtourist mit längeren Touren länger in Region zu halten.

Hier bei uns gibts lokale Routen rund um Hannover (z.B. Julius-Tripp-Ring, 25km, https://cycling.waymarkedtrails.org/#route?id=32558, Grüner Ring mit 79km, https://cycling.waymarkedtrails.org/#ro … 757!9.7334 ).Haben ja nix mit Knotenpunktnetzen zu tun. Ignoriert das...

Für die Freizeitkarte-Android planen wir die Knotenpunkte demnächst anzuzeigen. Das Tagging der Punkte wurde ja vor Kurzem durch die niederländischen Kollegen noch etwas angepaßt und dort bereits entsprechend umgesetzt. Gibt es Aktivitäten die Ergänzung für Deutschland im Rahmen einer konzertierten Aktion ebenfalls zu übernehmen? Oder ist dies womöglich schon erledigt?

toc-rox wrote:

Gibt es Aktivitäten die Ergänzung für Deutschland im Rahmen einer konzertierten Aktion ebenfalls zu übernehmen? Oder ist dies womöglich schon erledigt?

ein Großteil dürfte erledigt sein. Es gab einige Mapper, die das erledigt haben.

Übersicht: https://www.knooppuntnet.nl/en/networks/de/rcn Der einzelne Smilie in der dritten Spalte zeigt an, wenn network:type=node_network ergänzt worden ist.

Sven

Mir erschließt sich aktuell zwar noch nicht ganz der Vorteil dieses neuen tags network:type=node_network, aber es macht ja auch nichts kaputt und wenn sich die Renderer und App-Programmierer auch danach richten mag das Ergebnis mir ja evtl. die Erleuchtung bringen 😉
Ich hätte da durchaus ein neues network=* Merkmal favorisiert, aber gut... So bleibt für mich immer noch die Frage nach der richtigen network=* Zuordnung. Ich halte in Deutschland immer noch nach https://wiki.openstreetmap.org/wiki/DE: … sifikation "lcn" als das passendere da die einzelnen Netzwerke sich auf die Landkreise beschränken (wie die Namen ja eindeutig zeigen) und ich mir über die einzelnen Knoten durchaus diverse Tagesetappen zusammenstellen kann. Auch wenn das Gesamtwerk größere überregionale Ausmaße annimmt ändert dies meiner Meinung nach nichts daran. Eine Landstraße bleibt auch eine Landstraße obwohl diese auch über die gesamte Republik ein bundesweites Netzwerk bilden.

Gruß Bernd

bergaufsee wrote:

Ich hätte da durchaus ein neues network=* Merkmal favorisiert, aber gut... So bleibt für mich immer noch die Frage nach der richtigen network=* Zuordnung.

Ich war eigentlich auch ursprünglich für ein eigenes network-Tag, das war aber von mir zu kurz gedacht! Im Ergebnis aber (und auch mit den Issues von Peter Elderson und mir) bin ich zur Überzeugung gelangt, daß die Niederländische Lösung mit network:type=node_network die einfachere und in der Gesamtbetrachtung die eindeutig bessere Lösung ist. Sie verändert kein bestehendes Tagging, sondern ergänzt es (im Gegensatz zu einem neuen network-Tag). Eine Änderung wäre viel aufwendiger und vor allem problematischer!

Gerade in den Niederlanden gibt es Netze, die als Knotenpunktnetze z.B. auch reine Wanderrouten, Reitwege oder Kanu-Routen beschreiben (lokal oder regional). Die Seite https://www.knooppuntnet.nl/en/overview gibt da einen exellenten Überblick. Man sollte sich wirklich mal in Ruhe alle Seiten der Auswertung der Seite anschauen... Da bekommt man z.B. auch einen Eindruck, wie lxn und rxn (x=w oder x=c) in dem Zusammenhang zu deuten sind...

Um es mal als Beispiel nur auf Radwegnetze zu beschränken: In Bezug auf die bereits bestehende Erfassung kann hier nun z.B. weiterhin lokale Knotenpunktnetze von regionalen unterschieden werden. Damit entfällt die leidige Disskussion ob es rcn oder lcn ist... In meinen Augen sind solche Knotenpunktnetze (bezogen auf Fahrrad) aber eh nicht nach Lokal oder Regional zu unterscheiden. Es ist ein Knotenpunktnetz mit Betreiber a, b oder c und fertig. Ich sehe bei solchen fast geschlossenen Netzen wie hier in Brandenburg auch keinen Sinn, diese nach lch oder rcn zu unterscheiden. In Nordbrandenburg existiert mittlerweile z.B. ein geschlossenes Netz von den Landkreisen Havelland, (tlw. Stadt Brandenburg), Prignitz, Ostprignitz-Ruppin, Oberhavel, Uckermark zum Barnim; unterschieden lediglich durch die unterschiedlichen Betreiber (=Landkreise). Hier im Süden Brandenburgs haben wir die Netze Elbe-Elster und das frisch entstandende Netz Spree-Neiße (mit Cottbus). Die Verbindung (Landkreis Oberspreewald-Lausitz) folgt ab dieses Jahr... Lokal mag ich sowas nun wirklich nicht mehr bezeichnen!

Im Ergebnis werden nun alle rein Knotenpunktbasierenden Netze von anderen Routengeschichten abgetrennt. Das ist in meinen Augen das wichtigste und bedeutendste Ergebnis. Erst jetzt erkennt man den konzeptionellen Unerschied zwischen Knotenpunktnetzen und Themenradrouten. Beides schließen sich ja nicht aus, sondern ergänzen sich. In meinen Augen für OSM ein großer Inhaltlicher Schritt nach vorn!

Sven

...der sich über das Gesamtergebnis sehr freut!

Tach, der Urheber meiner hier angesprochenen Relationensammlung hat sich im CS gemeldet. Es soll demnach ein Knotenpunktnetzwerk aus Alltagsrouten ergeben.

Könnte sich jemand Kundigeres als ich dessen annehmen?

--ks

Was sind Alltagsrouten? Gibt es eine Beschilderung?

Hei,

Neues Jahr, neues Knotenpunktnetzwerk... (das hatte ich auch schon erwartet)

Bei einer Entsorgungsfuhre Grünschnitt und Laub mit meiner Mutter zur geordneten Deponie (4€ der Hänger) habe ich die ersten Knotenpunkte im Stadtgebiet Lübben entdeckt. Die müssen ganz frisch aufgestellt worden sein...

Erste Punkte und Routen sind bereits nach dem bewährten Schema erfasst...
https://www.openstreetmap.org/relation/10953719

Im Zuge dessen werden auch einige Themenradrouten mindestens im Stadtgebiet Lübben umverlegt... Ich vermute, daß ist alles zur Zeit im Prozess... Nach Lust und Laune werde ich die Lübbener Punkte nach und nach abradeln und dokumentieren...

Sven

Spannend, irgendwann kann man mittels "Radeln nach Zahlen" von Dresden an die Ostsee radeln.

streckenkundler wrote:

Erste Punkte und Routen sind bereits nach dem bewährten Schema erfasst...
https://www.openstreetmap.org/relation/10953719

Wobei im Wiki empfohlen wird, in den Namen der Verbindungen immer ein Leerzeichen vor und nach dem Bindestrich zu lassen.

Wichtiger ist aber, es im Netzwerk einheitlich zu machen.

Grüße,
Jochen

JochenB wrote:

Wobei im Wiki empfohlen wird, in den Namen der Verbindungen immer ein Leerzeichen vor und nach dem Bindestrich zu lassen.

ja, ich habe bisher hier aber nur ref=xx-yy erfasst... name=xx - yy habe ich (bisher) weggelassen..

Ortsnamen mit in den name-Tag mit reinzunehmen, wie es z.B. in Ostprignitz-Ruppin gefällt mit irgendwie nicht...

Sven

Leider verstehe ich das System nicht. Mein Problem ist, dass ich nicht erkennen kann, wann ein Punkt ein Radknotenpunkt ist.
Es gibt network, information=guidepost, guidepost= , name, note, description, rcrn_ref, ref

Die Knotenpunkte hier in der Gegend (Bergisches Land) kombinieren diese Tags wild durcheinander. Die Knotenpunktnummer steht manchmal im Namen, manchmal in note, manchmal gar nicht alleine, sondern "kontoenpunkt 69" usw.

Ich habe mir verschiedene Karten angeschaut und jede rendert anders.

speichennippel wrote:

Leider verstehe ich das System nicht. Mein Problem ist, dass ich nicht erkennen kann, wann ein Punkt ein Radknotenpunkt ist.

eigentlich ist das recht einfach...
Ich machs mal am Beispiel einer Route, bei mir vor der Haustür: https://www.openstreetmap.org/relation/10953915

1. die Knotenpunkte: immer auf der Wegekreuzung: https://www.openstreetmap.org/node/2026273154 rcn_ref, network:type, expected_rcn_route_relations, cycle_network setze ich immer.
2. Radwege-Schilder: immer da, wo sie auch real stehen: https://www.openstreetmap.org/node/2867126401 (sind Optional)
3. Verbindungsrouten: https://www.openstreetmap.org/relation/10953915: diese enthalten Knotenpunkte (ohne Rolle), optional Radwegeschilder (Rolle guidepost) und die highway-Segmente zwischen den Knotenpunkten: Sortierung immer vom niedrigeren Punktnummer zur höheren Punktnummer.

4. Die Netzwerk-Relation:https://www.openstreetmap.org/relation/10953719: diese enthält die Verbindungsrouten und die Knotenpunkte... Wenn eine Route eine Verbindung zu einem anderen Netzt ist, sollte sie die Rolle connection bekommen.

Die Seite https://www.knooppuntnet.nl/en/networks/de/rcn wertet alle als Radknotennetz erfasste Netze aus und gibt auch Hinweise auf Fehler... Beispiel https://www.knooppuntnet.nl/en/network/6573287 der Punkt "Facts" listet etwaige Fehler und/oder Unvollständigkeiten auf... https://www.knooppuntnet.nl/en/network-facts/6573287.

Sven

speichennippel wrote:

Ich habe mir verschiedene Karten angeschaut und jede rendert anders.

Ach ja, das wichtigste war die Einführung von network:type=node_network. Diese ist an die Knotenpunkte, die Verbindungsrelationen und die Netzwerk-Relation zu setzen. Damit lassen sich diese Knotenpunktnetzwerke sauber separat abfragen und darstellen. WaymarkedTrails wertet nur nur Knotenpunkte (Darstellung als Zahl im Kreis) und die Verbindungsrouten (separate Farbe und separater Bereich un der Routenliste) aus. Das ist auch in dem Kontext ausreichend...

Sven

Danke!
Der Knoten an sich und das physische Schild werden also separat erfasst, das war mir nicht klar. Ich habe immer versucht, aus den Schildern Radknotenpunkte zu machen. Manchmal sieht man die Lösung vor lauter Schildern nicht 🙂

Wenn ich daraus eine Landkarte baue, sollte der Knoten als Nummer erscheinen und das Schild als Schild? Wäre das so korrekt?

speichennippel wrote:

Der Knoten an sich und das physische Schild werden also separat erfasst, das war mir nicht klar.

Das Schild selbst ist ja zunächst nichts weiter als ein ganz normaler Radwegweiser (gelegentlich auch für Wanderwege mitgenutzt)

speichennippel wrote:

Wenn ich daraus eine Landkarte baue, sollte der Knoten als Nummer erscheinen und das Schild als Schild? Wäre das so korrekt?

würde ich so sagen...

Sven

Danke nochmal, ich glaube, jetzt habe ich es verstanden. so sieht das demnächst in der Speichenkarte aus, hoffe, dass nun alles richtig dargestellt wird.
https://www.openstreetmap.org/node/293282320

PM zum Knotenpunktnetz Dahme-Spreewald: https://www.dahme-spreewald.info/de/seite/61161.html

ich meine...

Danke diverser Mapper ist das Netz bereits jetzt zu einem größeren Teil bereits in OSM verfügbar...https://overpass-turbo.eu/s/Uv1

Danke meinerseits vor allem an WegefanHB, avena701 und cehceh

An die Mapper: im Süd/Südwestteil des Landkreises Dahme-Spreewald (=Altkreis Luckau) gibt es noch Nachholebedarf.

Also auf: Radeln, Knotenpunkte erfassen und nicht die Richtung zum nächsten Punkt vergessen...

Pfingstliche Grüße,

Sven

PS: Landkreis Oberspreewald-Lausitz kann auch Knotenpunkterfassende Pfingstradler vertragen... Da fehlt auch einiges...

streckenkundler wrote:

1. die Knotenpunkte: immer auf der Wegekreuzung: https://www.openstreetmap.org/node/2026273154 rcn_ref, network:type, expected_rcn_route_relations, cycle_network setze ich immer.

Bielefeld wird gerade auch mit einem Knotennetzwerk gesegnet, dabei habe ich aber jetzt gerade das Problem , dass auch große Kreuzungen in der Innenstadt als Knotenpunkt ausersehen wurden, wie zB. hier die Knoten 21 und 44:

https://cycling.waymarkedtrails.org/#?m … 0182!8.526

zZ sind da tatsächlich noch die einzelnen Schilder/Guideposts mit der Knotenummer darauf als Knoten getaggt.

Bin mir da gerade mit mir selbst nicht einig wo genau ich da den jeweiligen Knoten besser plazieren sollte, insb. die 44 auf dem Adenauerplatz ....

Hartmut Holzgraefe wrote:

Bin mir da gerade mit mir selbst nicht einig wo genau ich da den jeweiligen Knoten besser plazieren sollte, insb. die 44 auf dem Adenauerplatz ....

Ähnlich ist es mit Knotenpunkten, die an Kreisverkehren starten und enden...
Ich hlaube, du wirst bei den Verbindungsrouten dann mit forward/backward arbeiten müssen und mit mehreren Knoten an der Kreuzung... Ansonsten mal bei bestehenden Knotennetzwerke schauen... https://www.knooppuntnet.nl/en/networks/de/rcn bietet da die Übersicht. Eventuell auch mal den User Peter Elderson fragen... Vielleicht hat er aus dem Stehgreif Beispiele. Ich müsste erst mal die Brandenburger Netze durchforsten.

Sven

streckenkundler wrote:

Hartmut Holzgraefe wrote:

Bin mir da gerade mit mir selbst nicht einig wo genau ich da den jeweiligen Knoten besser plazieren sollte, insb. die 44 auf dem Adenauerplatz ....

Ähnlich ist es mit Knotenpunkten, die an Kreisverkehren starten und enden...
Ich hlaube, du wirst bei den Verbindungsrouten dann mit forward/backward arbeiten müssen und mit mehreren Knoten an der Kreuzung... Ansonsten mal bei bestehenden Knotennetzwerke schauen... https://www.knooppuntnet.nl/en/networks/de/rcn bietet da die Übersicht. Eventuell auch mal den User Peter Elderson fragen... Vielleicht hat er aus dem Stehgreif Beispiele. Ich müsste erst mal die Brandenburger Netze durchforsten.

Sven

I am sorry to say I don't really know how to do this for cycling, where both directions are packed in one relation with forward and backward roles, combined with split cycle-network nodes. In Nederland, user https://www.openstreetmap.org/user/dvdhoven is the leading expert on that. I am sure he can provide good examples.

One other thing: The Dutch now use ref=mm-nn instead of note=mm-nn on the node2node relations. Knooppuntnet, OsmAnd and most of the renderers and routers support this, in fact using note=mm-nn was the exception. The reason is: the note key should contain mapper's notes about the object, not details for the end user.
There is a lot of retagging to be done, but in a few months we will have this behind us.

Waymarktrails then shows node2node routes like this: https://hiking.waymarkedtrails.org/#rou … 665!4.5571 instead of like this: https://hiking.waymarkedtrails.org/#rou … 459!4.7387

Peter Elderson wrote:

One other thing: The Dutch now use ref=mm-nn instead of note=mm-nn on the node2node relations. Knooppuntnet, OsmAnd and most of the renderers and routers support this, in fact using note=mm-nn was the exception. The reason is: the note key should contain mapper's notes about the object, not details for the end user.

Das finde ich auch Sinnvoll und habe es in der Region AC/DN/HS schon teilweise umgesetzt.

Peter Elderson wrote:

I am sorry to say I don't really know how to do this for cycling, where both directions are packed in one relation with forward and backward roles, combined with split cycle-network nodes. In Nederland, user https://www.openstreetmap.org/user/dvdhoven is the leading expert on that. I am sure he can provide good examples.

Thank you very much. I contacted him with a few examples and pointed to this thread.

Regards

Sven

Parzelle13 wrote:

Peter Elderson wrote:

One other thing: The Dutch now use ref=mm-nn instead of note=mm-nn on the node2node relations. Knooppuntnet, OsmAnd and most of the renderers and routers support this, in fact using note=mm-nn was the exception. The reason is: the note key should contain mapper's notes about the object, not details for the end user.

Das finde ich auch Sinnvoll und habe es in der Region AC/DN/HS schon teilweise umgesetzt.

In die Niederlände sind jetzt all Knotenpunknetzwerke umgesetzt von note=* zu ref=*. Dazu hab ich ein "Mechanical Edit"gemacht, sehe https://wiki.openstreetmap.org/wiki/Mec … r_Elderson .

Wenn Sie wollen kan ich das auch für Deutschland durchführen, wenn Sie sich einig und einverstanden sind.

Peter Elderson wrote:

... In die Niederlände sind jetzt all Knotenpunknetzwerke umgesetzt von note=* zu ref=*. Dazu hab ich ein "Mechanical Edit"gemacht, sehe https://wiki.openstreetmap.org/wiki/Mec … r_Elderson .

Wenn Sie wollen kan ich das auch für Deutschland durchführen, wenn Sie sich einig und einverstanden sind.

Ich würde dem zustimmen. I agree.

Parzelle13 wrote:

Peter Elderson wrote:

... In die Niederlände sind jetzt all Knotenpunknetzwerke umgesetzt von note=* zu ref=*. Dazu hab ich ein "Mechanical Edit"gemacht, sehe https://wiki.openstreetmap.org/wiki/Mec … r_Elderson .

Wenn Sie wollen kan ich das auch für Deutschland durchführen, wenn Sie sich einig und einverstanden sind.

Ich würde dem zustimmen. I agree.

Ja, ich auch...

Sven

Peter Elderson wrote:

Wenn Sie wollen kan ich das auch für Deutschland durchführen, wenn Sie sich einig und einverstanden sind.

Ja - es ist sinnvoll einheitlich zu mappen.

Peter Elderson schrieb:

Wenn Sie wollen kan ich das auch für Deutschland durchführen, wenn Sie sich einig und einverstanden sind.

Ja - es ist sinnvoll einheitlich zu mappen.

+1

Ich hab gesehen das viele Knotenpuntrouten mit ref=KNP getagd sind. Ist das wichtige Information? Kann es auch in einen andere Tag gespeicherd worden?

Peter Elderson wrote:

Ich hab gesehen das viele Knotenpuntrouten mit ref=KNP getagd sind. Ist das wichtige Information? Kann es auch in einen andere Tag gespeicherd worden?

Ich halte das KPN für vollkommen unwichtig, genauso wie RRR,NRW.

Vor allem gibt es in Kreisen wie Heinsberg, Aachen, Düren alle diese Tags als note="" gemeinsam in einem Netz.

I have added this to my mechanical edit page:

2020-06-11 I have asked on the OSM-forum Germany if they want to convert as well, and offered to help. So far 4 of 4 reactions were positive. If no objections arise, I will start this work on 2020-06-15.

https://wiki.openstreetmap.org/wiki/Mec … n#Progress

Any objections, please let me know! Also, if 2020-06-15 is too soon, let me know. If you prefer to perform this yourselves, please do!
Consensus in the German community about this is very important to me. I will only proceed if no objections are raised.

Parzelle13 wrote:

Peter Elderson wrote:

Ich hab gesehen das viele Knotenpuntrouten mit ref=KNP getagd sind. Ist das wichtige Information? Kann es auch in einen andere Tag gespeicherd worden?

Ich halte das KPN für vollkommen unwichtig, genauso wie RRR,NRW.

Vor allem gibt es in Kreisen wie Heinsberg, Aachen, Düren alle diese Tags als note="" gemeinsam in einem Netz.

Dann wird ich es allerdings sicherstellen.

Sind für ein Knotenpunktnetzwerk eigentlich zwingend Punktnummern an den Knoten notwendig? Im Moment bin ich dabei, das Wegenetzwerk des Schwarzwaldvereins in meiner Gegend zu mappen und bei Waymarked Trails gehen dadurch die Themenwanderwege immer mehr unter. Die etwas andere Darstellung der Knotenpunktnetzwerke könnte diese wieder etwas mehr hervorheben, aber ich weiß nicht genau, ob man das Schwarzwaldverein-Netz als Knotenpunktnetzwerk bezeichnen kann. Letztendlich ist das Prinzip genau das gleiche, nur dass die Knotenpunkte statt Nummern einzigartige Namen von irgendwelchen Objekten/Flurnamen in der Nähe haben.

Nummern sind m.W. nicht zwingend. Bei Haltern gibt es z.B. einen Knotenpunkt mit der Referenz 'Bf' für Bahnhof. Das scheint mir durchaus sinnvoll. Mehr als 2 oder 3 Buchstaben sollte so eine Referenz aber nicht lang sein.

doktorpixel14 wrote:

Sind für ein Knotenpunktnetzwerk eigentlich zwingend Punktnummern an den Knoten notwendig? Im Moment bin ich dabei, das Wegenetzwerk des Schwarzwaldvereins in meiner Gegend zu mappen und bei Waymarked Trails gehen dadurch die Themenwanderwege immer mehr unter. Die etwas andere Darstellung der Knotenpunktnetzwerke könnte diese wieder etwas mehr hervorheben, aber ich weiß nicht genau, ob man das Schwarzwaldverein-Netz als Knotenpunktnetzwerk bezeichnen kann. Letztendlich ist das Prinzip genau das gleiche, nur dass die Knotenpunkte statt Nummern einzigartige Namen von irgendwelchen Objekten/Flurnamen in der Nähe haben.

Hast du mal ein Beispiel? Am besten ein Foto eines Knotenpunktes... Meinst du z.B. diese Ecke: https://cycling.waymarkedtrails.org/#?m … 832!8.1179

Echte Knotenpunktnetze müssen in der Netzwerkrelation, den Verbindungsrouten und bei den Knotenpunten selbst auf jeden Fall ein "network:type=node_network" haben. Dann wird dieses als Knotenpunktnetz z.B. bei https://www.knooppuntnet.nl/en/networks/de/rcn gezeigt. Dann wird dieses Netz z.B. auch hier https://cycling.waymarkedtrails.org/#?m … 155!8.2049 farblich sepatat dargestellt, wird in Osmand extra als Knotennetz dargestellt... Vergleiche in meiner Heimatstadt: https://cycling.waymarkedtrails.org/#?m … 47!13.8618;

...Dann wird (nach der nächsten Aktualisierung) das z.B. hier: https://cycle.travel/map angezeigt und auch in der Testversion bei https://experimental.knooppuntnet.nl/de/map/cycling ausgewertet.

Diese Knotenpunktnetzwerke haben üblicherweise einen Wegweiserpfosten mit einer Zahl und an den Richtungsfahnen der Hinweis zum nächsten Knptenpunkt und ggf. die Richtung des Themenradweges. Die Seite https://www.radeln-nach-zahlen.de/de/Da … childerung zeigt das recht schön...

Viele Grüße,

Sven

...der die Knotenpunktnetzentwicklung und die Arbeit unserer Mapperkollegen aus der Heimat der Knotenpunktnetze echt Klasse findet...

Sorry to continue in English - my German is terrible.

I have looked at some of the cycle node networks. The action as described on my mechanical edit page is simply not possible, because the tagging is not consistent enough. The node numbers are in the name tag, the description tag, the note tag, and/or the ref tag, sometimes in three tags at the same time so very redundant; often mixed with other information and special punctuation.
Often there is also note:de and description. Sometimes the way this is done is consistent within a network, but sometimes it differs within the network.

All systems are acceptable to me, but it prevents me from using the automated edit. This can only be performed by the German community after reaching consensus about how to tag node network routes. Then you could setup a joint effort to adapt all networks according to this consensus.

I still could be of service if an agreed way of tagging has been established. Then I can do a lot of work reasonably fast.

My primary advice to get at that point would be: keep it simple. Tag less, avoid redundancy, and tag consistently.
E.g. there is no point in repeating the network information in all the separate routes, or to put information about the nodes in the routes. If an application needs that information, it can get it from the network and from the nodes.

streckenkundler wrote:

Hast du mal ein Beispiel? Am besten ein Foto eines Knotenpunktes... Meinst du z.B. diese Ecke: https://cycling.waymarkedtrails.org/#?m … 832!8.1179

Es ging mir eigentlich um die Wanderwege, siehe https://hiking.waymarkedtrails.org/#?ma … 321!8.1219 Die Fahradwege in der Gegend haben leider kein solches Netz.
Die Wegweiser sehen so aus: https://www.mapillary.com/map/im/J_QCKCQZIVipXucPUnQTWg

toc-rox wrote:

Nummern sind m.W. nicht zwingend. Bei Haltern gibt es z.B. einen Knotenpunkt mit der Referenz 'Bf' für Bahnhof. Das scheint mir durchaus sinnvoll. Mehr als 2 oder 3 Buchstaben sollte so eine Referenz aber nicht lang sein.

Okay, wenn es nicht mehr als 2 oder 3 Buchstaben/Ziffern sein sollten, fällt des Netzwerk wohl nicht ins Muster.

Gäbe es denn dann ein alternatives Value für network:type?

Peter Elderson wrote:

I have looked at some of the cycle node networks. ...

You are absolutely right.
Tagging is very inconsistent in Germany.
I hope we can achieve a uniform tagging scheme.
Thanks for your offer.

Hallo,

mir ist gestern bei Waymarked Trails aufgefallen, das im Dreiländereck NL/BE/DE das Wanderkontenpunktnetz in Belgien mit rwn eingetragen ist und somit auch entsprechend dort angezeigt wird.

https://hiking.waymarkedtrails.org/#sea … 464!6.0412

Relation dazu: https://www.openstreetmap.org/relation/9532813

Ich habe die die deutsche Seite allerdings mit lwn eingetragen, da ich es eher als ein lokales Wandernetzwerk gesehen habe.

Relation dazu: https://www.openstreetmap.org/relation/ … 422/6.0758

Da es aber auch Verbindungen zwischen beiden Seiten der Grenzen gibt (selbst einige Wegweiser wurden auf BE-Seite scheinbar von der Stadt AC aufgestellt), ergibt sich die Frage, alles einheitlich machen oder nicht.

Auch auf knooppuntnet.nl werden die Netzwerke scheinbar nur erfasst, wenn sie als rwn und nicht als lwn eingetragen wurden. Deshalb gibt es dort keine geprüften Wandernetzwerke in DE. In BE und NL allerdings schon.

Siehe https://www.knooppuntnet.nl/en/network/9532813

Hier im Bereich Aachen/Heinsberg sind einige Knotenpunktrelationen mehrfach eingetragen.

Diese hier sind keinem übergeordneten Netzwerk zugeordnet (auch keinem in NL):

https://www.openstreetmap.org/relation/174777
https://www.openstreetmap.org/relation/174772
https://www.openstreetmap.org/relation/175162
https://www.openstreetmap.org/relation/175163
https://www.openstreetmap.org/relation/175163

Sie entsprechen den Relationen im Knotenpunktnetzwerk Kreis Heinsberg (2073165)

Beispiel, beides Strecke zwischen den Knotenpunkten 62-63:
Knotenpunktnetzwerk Kreis Heinsberg https://www.openstreetmap.org/relation/2264003
Ohne Zuordnung https://www.openstreetmap.org/relation/175163

Ich würde diese nicht zugeordneten Relationen gerne löschen, wenn keine Bedenken bestehen.
Auch Mapper Kollegen aus den Niederlanden, welche hier mitlesen, sind natürlich gefragt.

Gruß

Parzelle13 wrote:

Auch auf knooppuntnet.nl werden die Netzwerke scheinbar nur erfasst, wenn sie als rwn und nicht als lwn eingetragen wurden.

This seems to be a bug in knooppuntnet. The intention is to support lwn also. I will look into it and fix.

Ich habe keine Bedenken!

In die Niederlände ist es jetzt ziemlich einfach geworden:

Knotenpunkt:
network:type=node_network
rXn_ref=... /* max 3 Zeichnen; normalerweise nur 2 Zahlen. X=w für walking; c für cycling u.s.w.

Node2node Route Relation:
network=rXn
network_type=node_network
type=route
route=bicycle /* or foot/hiking/horse
ref=mm-nn

Netwerkrelation:
type=network
network:type=node_network
network=rXn
name=*
operator=*

Wir tragen keinen Operator mehr ein in die Routen und Knotenpunkte, weil das zu oft wechselt und Benutzer das nicht mehr brauchen. (Es gibt ein nationales Routenmeldesystem, und die Netzwerke werden meistens von Regionalbüros im Auftrag verwaltet.)

Die Name des Netzes tragen wir nur noch im Networkrelation ein.

Obwohl man jetzt theoretisch auch lXn, nXn und iXn Knotenpuntnetzwerke eintragen kann, tun wir das noch nicht. Wir sehen die Knotenpunktnetzwerke noch immer wie regionaal.

Zukunft, sicher:
Es wird innerhalb weniger Monate einen universellen OSM-Knotenplaner geben. Es wird gerade getestet und sieht sehr gut aus. Es verwendet nur die Basisdaten.

Zukunft, vielleicht:
Weil ganz Nederland ein einziges Knotenpunktnetz is, erwegen wir die "network relation" abzuschaffen.
https://www.knooppuntnet.nl/ kommt mit einer neuen Version die mit geografischen Bereichen funktioniert.
Man braucht dann auch die "connection" Routen nicht mehr. Wie einfach kann es sein!

vmarc wrote:

This seems to be a bug in knooppuntnet. The intention is to support lwn also. I will look into it and fix.

Thank you for your efforts

Peter Elderson wrote:

Ich habe keine Bedenken! ...

Thanks to you too

I would like to answer in Dutch, but my Dutch is worse than my English. Reading usually works quite well.

Parzelle13 wrote:

my Dutch is worse than my English.

The same goes for many Dutch people...

Ich auch nicht.

Auch Sven hat eine klare Meinung zu dem Thema.

Peter macht deutlich, dass die vielen Redundanzen nicht nötig sind. Ich schlage vor, dass die entfernt werden. In radrevier.ruhr haben die meisten Knoten ein name-Tag. Das schadet nicht. Diesen Namen in den Routen zu wiederholen ist überflüssig.

Bleibt nur ein Problem: wie die Mapper ins Boot holen und von diesem einfachen und pragmatischen Vorschlag überzeugen? Ich habe in der Vergangenheit einige Knotenpunkt-Mapper kontaktiert. Einige haben das NL-Schema übernommen. Andere haben nicht geantwortet. Man merkt schon nach kurzer Zeit die Vorteile durch knooppuntnet.nl. Z.B. die Hinweise, wenn eine Einbahnstraße nicht in Gegenrichtung für Radler geöffnet ist. Dann stellt sich die Frage, ob nicht in den OSM-Daten ein Fehler ist. Damit trägt ein fehlerarmes Knotennetz zur Verbesserung der OSM-Daten und dem Routing bei. Und das ist doch der Wunsch der Community.
Gruß
hfwri

hfwri wrote:

Auch Sven hat eine klare Meinung zu dem Thema. Peter macht deutlich, dass die vielen Redundanzen nicht nötig sind. Ich schlage vor, dass die entfernt werden. In radrevier.ruhr haben die meisten Knoten ein name-Tag. Das schadet nicht. Diesen Namen in den Routen zu wiederholen ist überflüssig.

Ja, man kann einiges gut vereinfachen... Im Moment, wo hier in Südbrandenburg häppchenweise die vier Netze erfasst werden, sind diese recht gute Hilfsmittel für die Erfassung... Auch helfen mir betimmte Angaben, wenn ich Ausschilderungsfehler begegnen... Darum erfasse ich z.B. cycle_network=xyz (xyz als Platzhalter für den Namen des Netzes, wie ich ihn auf der Karte am Wegweiserpfosten vorfinde...
Um mir aber einen Überblick zu verschaffen, was in einem Landkreis los, ist, wie weit das Netz ist, arbeite ich in der Regel ohne die Netzwerkrelation. Ich frage mittels OverpassTurbo nur die Knotenpunkte und deren node2node-Routen ab...

Ich finde eigentlich die Angabe network=rXn an der Node2node Route Relation mittlerweile überflüssig... Sie sagt hier eigentlich nichts mehr aus.

Mit

network_type=node_network
type=route
route=bicycle /* or foot/hiking/horse
ref=mm-nn

an der Node2node Route Relation ist eigentlich alles gesagt, oder gehe ich da zu weit?

Sven

streckenkundler wrote:

Ich finde eigentlich die Angabe network=rXn an der Node2node Route Relation mittlerweile überflüssig... Sie sagt hier eigentlich nichts mehr aus.

Das kann ich mir vorstellen, aber in dem Zukunft kann das sich ändern. Ich hab bereits Lokalknotenpunktnetzwerke gesehen. Im Prinzip kunnen Knotenpunktnetzwerke aus lokale, regionale, nationale und internationale Routen aufgebaut werden.

In Nederland haben wir zB 17 nationale Wanderrouten (LAWen), mit um 75 Kreuzungen. Ich habe schon einmal vorgeschlagen die Kreuzungen nummern zu geben damit das ein nationales Knotennetzwerk wird, was man auch in einem Knotenpunktplanerapp kan verwenden. Die lange Routen bleiben dann bestehen, aber man kann auch eine eigene route planen via Strecken langer Wanderrouten.

Und international haben wir zB die Jakobsrouten. Die kan man einfacher wie ein internationales Netzwerk mit Knotenpunkte beschreiben als wie ein durchgehende Wanderweg mit unzählige Alternative. Den Knotenpunkten werden dann eher Namen als Zahlen gegeben, denk ich mich, aber das ändert das Prinzip nicht.

doktorpixel14 wrote:

aber ich weiß nicht genau, ob man das Schwarzwaldverein-Netz als Knotenpunktnetzwerk bezeichnen kann.

Das Wegenetz des Schwarzwaldvereins ist wie auch das des Schwäbischen Albvereins und vermutlich die von vielen anderen Wandervereinen von der Konzeption her kein Knotenpunktnetzwerk.

seichter wrote:

doktorpixel14 wrote:

aber ich weiß nicht genau, ob man das Schwarzwaldverein-Netz als Knotenpunktnetzwerk bezeichnen kann.

Das Wegenetz des Schwarzwaldvereins ist wie auch das des Schwäbischen Albvereins und vermutlich die von vielen anderen Wandervereinen von der Konzeption her kein Knotenpunktnetzwerk.

Mit der Einführung von "network:type=" ich meiner Ansicht nach ein gewaltiger Schritt gemacht worden. Es eröffnet die Möglichkeit, auch solche Netze besser zu strukturieren... Wie könnte man das bezeichnen? Letztendlich wäre es sowas wie ein Zielwegweisernetz...? Es wäre ein eigener network:type nötig...

doktorpixel14 wrote:

Die Wegweiser sehen so aus: https://www.mapillary.com/map/im/J_QCKCQZIVipXucPUnQTWg

Das würde ich z.B. einerseits als ein solches "Zielwegweisernetz" interpretieren, andererseits wäre für mich der "Friedenspilgerweg" eine separate Route...

Meinungen?

Sven

doktorpixel14 wrote:

Die Wegweiser sehen so aus: https://www.mapillary.com/map/im/J_QCKCQZIVipXucPUnQTWg

Ich denke, dies ist hauptsächlich ein attraktives Beschilderungssystem, das alle Routen und nahe gelegenen Ziele abdeckt.

hfwri wrote:

Bleibt nur ein Problem: wie die Mapper ins Boot holen und von diesem einfachen und pragmatischen Vorschlag überzeugen? Ich habe in der Vergangenheit einige Knotenpunkt-Mapper kontaktiert. Einige haben das NL-Schema übernommen. Andere haben nicht geantwortet. Man merkt schon nach kurzer Zeit die Vorteile durch knooppuntnet.nl. Z.B. die Hinweise, wenn eine Einbahnstraße nicht in Gegenrichtung für Radler geöffnet ist. Dann stellt sich die Frage, ob nicht in den OSM-Daten ein Fehler ist. Damit trägt ein fehlerarmes Knotennetz zur Verbesserung der OSM-Daten und dem Routing bei. Und das ist doch der Wunsch der Community.

Ich denke, jemand muss einen Wiki-Vorschlag mit dem Mindest-Tagging und den optionalen Extras für Deutschland machen. Es spielt keine Rolle, ob es Unterschiede gibt, solange dasselbe Tag für dieselben Daten verwendet wird und jeder sich an das absolute Minimum halt.

Dann kann man auf der "Talk"-Seite oder hier diskutieren und der Vorschlag kneten, bis Konsens besteht.

streckenkundler wrote:

Mit der Einführung von "network:type=" ich meiner Ansicht nach ein gewaltiger Schritt gemacht worden. Es eröffnet die Möglichkeit, auch solche Netze besser zu strukturieren... Wie könnte man das bezeichnen? Letztendlich wäre es sowas wie ein Zielwegweisernetz...? Es wäre ein eigener network:type nötig...

Ein network:type reicht mMn nicht.
Es müssten mindestens die Ziele hervorgehoben sein, die ihrerseits wieder an Verzweigungen stehen. Die Wegweiser stehen ja nicht nur an Verzweigungen von Wanderwegen, sondern auch da, wo andere Wege/Straßen abgehen oder an herausgehobenen Punkten zwischendrin. Die sind ja für das Netzwerk eigentlich irrelevant.
Am einfachsten ließe sich das durch eine ID (typisch Nummer) am Mast und eine jeweils angehängte Nummer in der Richtung zum nächsten Knoten erreichen (travelling by numbers).
Theoretisch könnte man das virtuell in OSM durchführen, der Wanderer draußen hätte aber herzlich wenig davon.

Aber vielleicht sickern ja Ideen dieser Art auch an Betreuer von Wegenetzen und regionale Verwaltungen durch?

seichter wrote:

Ein network:type reicht mMn nicht.

Wäre aber ein erster Schritt...

seichter wrote:

Es müssten mindestens die Ziele hervorgehoben sein, die ihrerseits wieder an Verzweigungen stehen. Die Wegweiser stehen ja nicht nur an Verzweigungen von Wanderwegen, sondern auch da, wo andere Wege/Straßen abgehen oder an herausgehobenen Punkten zwischendrin.

Da gab es mal...

Es gab mal eine Relationsgeschichte (als Wochenaufgabe) mit destination sign... oder so... Beitrag dürfte im Forum zu finden sein.... andererseits meine ich, daß waymarkedtrails auch Dinge wie direktion_east=* auswertet... Beispiel müsste ich suchen... habe ich aber Wochenende erst wieder gesehen...

seichter wrote:

Am einfachsten ließe sich das durch eine ID (typisch Nummer) am Mast ...

Das Problem hierbei ist, daß nicht sichergestellt ist, daß die Wegweiserpfosten nicht immer (eigentlich eher selten) eine eigene Nummer haben...

Hier in meiner Gegend... Wenn man das Rad in die Vorknotenpunktnetzzeit zurückdreht... "mein" LDS-Kreis hat immer Pfostennummern, egal ob Rad oder Wander... OSL-Kreis alle Pfosten stets ohne Nummern, angrenzender SPN-Kreis nur Wanderwegpfosten mit Nummer und das unregelmäßig... Aktuell ist es nicht anders. Also auch nicht Verlässlich...

Sven

streckenkundler wrote:

andererseits meine ich, daß waymarkedtrails auch Dinge wie direktion_east=* auswertet... Beispiel müsste ich suchen... habe ich aber Wochenende erst wieder gesehen...

das hab ich gefunden: https://cycling.waymarkedtrails.org/#gu … 63!14.5754

Das Problem ist hier wiederum... Wanderwegspfosten haben gerne mal eine "Multinutzung" Ich habe Beispiele mit regelkonformen Zielwegweiserfahnen, die Einschübe haben dann Hinweise auf den nächsten Radknotenpunkt, der Themenradroute, Wanderwegszeichen, sonstige Finge wie Zentrum eines Ortes oder Bahnhof... oder eben eine Separate Wanderwegsbeschilderung (andere Schildform und -farbe) am selben Pfosten... Ich glaube, wir sollten mal einen Wander- und Radwanderpfostenvarianten-Beitragsbaum der auch alle damit zusammenhängende Nebensächlichkeiten betrachtet, aufmachen und mal die unterschiedlichen lokalen Varianten zeigen... Wäre vielleicht sogar echt gut zur schärfung des eigenen Auges...

Sven

streckenkundler wrote:

Es gab mal eine Relationsgeschichte (als Wochenaufgabe) mit destination sign... oder so... Beitrag dürfte im Forum zu finden sein.... andererseits meine ich, daß waymarkedtrails auch Dinge wie direktion_east=* auswertet

Den Ansatz mit Relationen kenne ich, finde ich aber nur selten verwirklicht, ist mMn auch sehr aufwendig. Daher verwende ich nur die "kleine Lösung" mit direction_xy.
Referenz-IDs an Pfosten gibt es nur selten und wenn, dann nicht in dem Sinn, dass sie für ein Knotenpunktnetzwerk nutzbar wären.
Zum einen sind sie viel zu lang, um als Orientierungshilfe dienen zu können, zum anderen stehen sie dann gebietsweise an jedem Pfosten, egal ob Knoten oder nicht.

Ohne Aufwand eines lokalen Betreuers des Wegenetzes läuft da mMn nach nichts.
Premiumwege als Touristikanreiz werden hier in der Gegend stark propagiert, Knotenpunktnetzwerke sind da noch nicht so attraktiv.

seichter wrote:

Den Ansatz mit Relationen kenne ich, finde ich aber nur selten verwirklicht, ist mMn auch sehr aufwendig.

+1
Darum hat mir das auch damals schon nicht gefallen...

seichter wrote:

Daher verwende ich nur die "kleine Lösung" mit direction_xy.

Was schon aufwendig genug ist... Ich wusste übrigens bis zum Wochenende auch nicht, daß Lonvia direktion_xy direkt anzeigt... Die Entdeckung war für mich eher Zufall... Aber das wir auch gleich wieder zu einem Problem, und zwar wenn ich an einem Pfosten eine separate Beschilderung für Wanderwege und Radwanderwege mit unterschiedlichen Zielen und unterschiedlichen Wanderwegfarben und -symbolen habe...

seichter wrote:

Referenz-IDs an Pfosten gibt es nur selten und wenn, dann nicht in dem Sinn, dass sie für ein Knotenpunktnetzwerk nutzbar wären.
Zum einen sind sie viel zu lang, um als Orientierungshilfe dienen zu können, zum anderen stehen sie dann gebietsweise an jedem Pfosten, egal ob Knoten oder nicht.

...oder Pfosten haben mehrere Nummern... Beispiel: an einem Pfosten: Knotenpunkt (Nummer 1) eigentliche Pfostennummer (Nummer 2), Rettungspunkt (Nummer 3), Wanderwegspfostennummer (Nummer 4)...

😄 geil... Akutis Nummeritis...

Wenn wir hinreichend sauber die Routen erfassen und versuchen, diese zu pflegen und vielleicht noch die Position der Wegweiserpfosten haben, ist das Arbeit und Ergebnis genug... Ein bisschen soll der Wanderer/Radwanderer ja auch noch zu Denken bekommen...

Sven

seichter wrote:

Die Wegweiser stehen ja nicht nur an Verzweigungen von Wanderwegen, sondern auch da, wo andere Wege/Straßen abgehen oder an herausgehobenen Punkten zwischendrin. Die sind ja für das Netzwerk eigentlich irrelevant.
Am einfachsten ließe sich das durch eine ID (typisch Nummer) am Mast und eine jeweils angehängte Nummer in der Richtung zum nächsten Knoten erreichen (travelling by numbers).

Im Falle des Schwarzwaldverein-Netzes trifft das eigentlich nicht zu. Die Wegweiser stehen idR nur an Knotenpunkten des Netzwerks. Jeder Wegweiser hat auch eine ID, die irgendwo hinten drauf steht, aber eigentlich reicht ja schon, dass jeder einen einzigartigen Namen hat.

streckenkundler wrote:

Das würde ich z.B. einerseits als ein solches "Zielwegweisernetz" interpretieren, andererseits wäre für mich der "Friedenspilgerweg" eine separate Route...

So hab ich es auch erfasst. Das Wort "Zielwegweisernetz" finde ich eigentlich sehr passend, man bräuchte nur eine gute englische Übersetzung als value für network:type.

doktorpixel14 wrote:

Das Wort "Zielwegweisernetz" finde ich eigentlich sehr passend, man bräuchte nur eine gute englische Übersetzung als value für network:type.

Ich hatte network:type=destination_network im Kopf, passt das?

Sven

Hört sich meiner Meinung nach gut an. Das könnte man auf jeden Fall mal auf der Tagging-Liste vorschlagen.

doktorpixel14 wrote:

Im Falle des Schwarzwaldverein-Netzes trifft das eigentlich nicht zu. Die Wegweiser stehen idR nur an Knotenpunkten des Netzwerks.

Kann ich nicht bestätigen. Im Bereich Baiersbronn, den ich kenne, stehen die Wegweiser oft auch unterwegs mehrmals. Ich habe mal einen größeren Bereich im Nordschwarzwald mit route=hiking und information=guidepost heruntergeladen. Da sieht es nicht sehr viel anders aus.
Aber natürlich stehen an jedem Netzknoten Wegweiser (und in OSM sind fast alle drin).

Jeder Wegweiser hat auch eine ID, die irgendwo hinten drauf steht, aber eigentlich reicht ja schon, dass jeder einen einzigartigen Namen hat.

In den letzten Jahren wurde da viel ergänzt, da steht dann eine Landkreis-ID und eine UTM-Koordinate drauf. Wenn klar ist, wie das Tagging so eines Zielnetzwerkes aussehen könnte und wozu es gut sein kann, könnte ich mich beteiligen.
Bis dahin trage ich auch mal im Schwarzwald die destination_* nach, da dafür offensichtlich Auswertungen bestehen. Ich habe da eine Sammlung an Wegweiser-Bildern 😎.

Doppelte Knotenpunkte.

Hier https://www.openstreetmap.org/query?lat … 9&layers=C gibt es den Knotenpunkt 52 zweimal, an verschiedenen Stellen.

Der untere an der Kreuzung Alfons-Keever-Straße/Kompstraße war falsch eingezeichnet. Er befindet sich richtig an der Kreuzung L263/Kompstraße.
Das habe ich mir auf auf mapillary https://www.mapillary.com/app/?lat=50.8 … 306&zoom=0 angesehen und auf https://radservice.radroutenplaner.nrw.de noch mal kontrolliert. Anschließend in OSM korrigiert. Ist aktuell auf dem Layer Radfahrerkarte natürlich noch nicht gerendert.

Das Problem bei den dazugehörigen Routen aber ist, das es ja noch den zweiten Knotenpunkt 52 hier https://www.openstreetmap.org/node/945242930 gibt. Eine ähnliche Situation ist mir schon mal irgendwo anders aufgefallen.

Wie trägt man so etwas richtig ein?

Dummy-Route zwischen den beiden Knotenpunkte (52a-52b) oder ähnlich?

Hat jemand eine bessere Lösung?

Parzelle13 wrote:

Das Problem bei den dazugehörigen Routen aber ist, das es ja noch den zweiten Knotenpunkt 52 hier https://www.openstreetmap.org/node/945242930 gibt. Eine ähnliche Situation ist mir schon mal irgendwo anders aufgefallen.
Wie trägt man so etwas richtig ein?
Dummy-Route zwischen den beiden Knotenpunkte (52a-52b) oder ähnlich?

Wir (NL) haben das sehr oft. Heutzutage behandeln wir sie einfach als separate Knoten. Also kein a. und b., nur zwei Knotenpunkte 52 und ein kurze Verbindingsroute 52-52. Genau so wie es auf der Straße steht und wie mann tatsächlich fahrt. Das gibt auch kein Problem beim Planen und Rendern.

Peter Elderson wrote:

Wir (NL) haben das sehr oft. Heutzutage behandeln wir sie einfach als separate Knoten. Also kein a. und b., nur zwei Knotenpunkte 52 und ein kurze Verbindingsroute 52-52. Genau so wie es auf der Straße steht und wie mann tatsächlich fahrt. Das gibt auch kein Problem beim Planen und Rendern.

Dank je wel, Peter!

Habe es so gemacht.

Es gibt ja das Tag expected_rcn_route_relations.

So wie ich das verstehe, wird damit die Anzahl der Kontenpunktrouten angegeben die sich dort treffen. Auf den Wegweisern an den Knotenpunkten werden ja die Verweise auf andere Knotenpunkte mit der Zielknotenpunktnummer (bei uns hier, Weiße Taflel mit rotem Kreis und weißer Nummer ).

Beispiel: https://www.mapillary.com/app/?lat=50.9 … 522&zoom=0

Zusätzlich werden dort z.B. noch Verweise auf andere Ziele angebracht, im Beispiel die Richtung Elsdorf/Stetternich.

Manche Mapper tragen auch Routenverbindungen ein, welche definitive keine Knotenpunktrouten sind. Wahrscheinlich sind manche der Meinung, das es von einem Knotenpunkt zu allen seinen Nachbarknotenpunkten Verbindungsrouten geben muss. Das ist aber leider nicht so.

Im Beispiel:
Knotenpunktroute 1-6 https://www.openstreetmap.org/relation/1728635
Knotenpunktroute 1-9 https://www.openstreetmap.org/relation/5868270
Knotenpunktroute 1-99 https://www.openstreetmap.org/relation/1731306

keine Knotenpunktroute 1-8 https://www.openstreetmap.org/relation/7653844

Damit wird aber Anzahl von expected_rcn_route_relations überschritten, was z.B. in https://www.knooppuntnet.nl/en/network-facts/1504091 zum Fehler führt.

Meinungen?

Knooppuntnet zählt nur Knotenpunktrouten (network:type=node_network).

Im Zuge der Disskussion hier: https://forum.openstreetmap.org/viewtopic.php?id=69796 ist durch ein Beispiel von Galbinus
offensichtlich ein "verstecktes" Wanderknotenpunktnetz aufgetaucht... https://overpass-turbo.eu/s/VjG

Ich würde das gerne für https://www.knooppuntnet.nl/en/networks/de/rwn auswertbar machen... Meinungen?

Sven

streckenkundler wrote:

Im Zuge der Disskussion hier: https://forum.openstreetmap.org/viewtopic.php?id=69796 ist durch ein Beispiel von Galbinus
offensichtlich ein "verstecktes" Wanderknotenpunktnetz aufgetaucht... https://overpass-turbo.eu/s/VjG

Ich würde das gerne für https://www.knooppuntnet.nl/en/networks/de/rwn auswertbar machen... Meinungen?

Sven

...mal schauen... sicher nicht mehr versteckt: https://www.openstreetmap.org/changeset … 6&layers=N

Sven

streckenkundler wrote:

nicht mehr versteckt: https://www.openstreetmap.org/changeset … 6&layers=N

Sven

Da isses.. https://knooppuntnet.nl/en/network-facts/11224411

Sven

Ich war da vor zwei Jahren mal zwei Wochen im Urlaub und wurde vor Ort erstmalig mit einem solchen Knotenpunkt-Wanderwegenetz konfrontiert. Hatte mich dann versucht, in das Tagging einzulesen und so viel wie möglich in den zwei Wochen zu erfassen. Da kann sicherlich noch einiges ergänzt und korrigiert werden.

Galbinus wrote:

Da kann sicherlich noch einiges ergänzt und korrigiert werden.

bereits geschehen, für mich nach bestem Wissen und Gewissen...

Es hat sich in den letzten Jahren sich (auch zu meiner großen Freude) bei dem Thema sehr viel getan! Mit https://www.knooppuntnet.nl/ gibt es endlich ein echt gutes Tool zur Validitätsprüfung...

Sven

streckenkundler wrote:

streckenkundler wrote:

nicht mehr versteckt: https://www.openstreetmap.org/changeset … 6&layers=N

Sven

Da isses.. https://knooppuntnet.nl/en/network-facts/11224411

Sven

So einfach kann das sein!
".....note" tag with the route name." wird in der nächsten Version sein: ".... ref tag with the route name".
Eine deutsche Übersetzung ist ebenfalls geplant.

streckenkundler wrote:

Ich würde das gerne für https://www.knooppuntnet.nl/en/networks/de/rwn auswertbar machen... Meinungen?

Na, dann mach ich mal die Knnotenpunktnetzwerke:

Wandern im Aachener Wald https://www.openstreetmap.org/relation/11200022, liegt in Gebieten der Stadt Aachen und Belgien.

Barrierefreie Wegweisung im Wurm- und Broichbachtal https://www.openstreetmap.org/relation/11147490, liegt in Gebieten der Städte Aachen, Würselen, Herzogenrath und Alsdorf.

auch zu rwn Netzen.

Was macht man, wenn ein Knotenpunkt zu mehreren Kontenpunktnetzwerken gehört?

Beispiel: https://www.openstreetmap.org/node/146209805

Dieser Knotenpunkt gehört zu einem Radknotenpunktnetz und zu einem Wanderknotenpunktnetz. Es könnten ja mal noch mehr Netze werden.

Sollte dann das Tag network hier = rcn;rwn;.. lauten?

Knotenpunkte benötigen überhaupt kein Netzwerk-Tag!
rwn_ref und andere rXn_ref's beißen sich nicht.

Peter Elderson wrote:

Knotenpunkte benötigen überhaupt kein Netzwerk-Tag!
rwn_ref und andere rXn_ref's beißen sich nicht.

Danke Peter

Als Test habe ich ein kleines Netzwerk mit Knotenpunktnamen aufgebaut. Was denkt ihr darüber?

Diskussion mit Doktorpixel14: https://wiki.openstreetmap.org/wiki/Tal … twork:type

Link zu einer Route im neue Planer: https://experimental.knooppuntnet.nl/nl … g8b-6w1sqe

Ich habe gesehen, dass bereits mehr Netzwerke mit Knotennamen eingegeben werden. Das kommt mir etwas zu früh vor. Ich habe einen "Draft Proposal" https://wiki.openstreetmap.org/wiki/Pro … e_networks gemacht, um die Tagging-Probleme zu diskutieren. Da es jetzt in Deutschland passiert wäre es gut, es zuerst hier zu diskutieren, um das Problem richtig zu definieren und Optionen zu erkunden. Dann kann es in einem breiteren Kreis diskutiert werden.

Peter Elderson wrote:

Ich habe gesehen, dass bereits mehr Netzwerke mit Knotennamen eingegeben werden. Das kommt mir etwas zu früh vor. Ich habe einen "Draft Proposal" https://wiki.openstreetmap.org/wiki/Pro … e_networks gemacht, um die Tagging-Probleme zu diskutieren. Da es jetzt in Deutschland passiert wäre es gut, es zuerst hier zu diskutieren, um das Problem richtig zu definieren und Optionen zu erkunden. Dann kann es in einem breiteren Kreis diskutiert werden.

Mir sind hier in meiner Umgebung auf die Schnelle nur zwei Stellen mit je 2 Punkten bekannt, an der Buchstaben anstelle von Zahlen verwendet werden. Das betrachte ich aber als temporären Workaround, da an beiden Stellen eine Eisenbahnunterführungen gebaut werden. Das ist Eichwalde und das ist Zeuthen.

angezeigt werden alle Punkte mit network:type=* und Buchstaben im rcn_ref oder ohne rcn_ref für das Bundesland Brandenburg:
https://overpass-turbo.eu/s/X66

Die anderen beiden Punke sind offensichtlich "versteckte" noch nicht erkannte Knotenpunkte des Netzes Landkreis Spree-Neiße. Die verarbeite ich am Nachmittag.

Sven

Wenn ich mir das Beispiel von Peter mal auf waymarkedtrails anschaue, frage ich mich, wie so etwas auf Karten für kleinere Navi's sinnvoll angezeigt werden kann. Man sieht ja nur noch elliptische Knotenpunkte, alles andere, selbst Wanderwege ist nicht mehr sichtbar.

Parzelle13 wrote:

Wenn ich mir das Beispiel von Peter mal auf waymarkedtrails anschaue, frage ich mich, wie so etwas auf Karten für kleinere Navi's sinnvoll angezeigt werden kann. Man sieht ja nur noch elliptische Knotenpunkte, alles andere, selbst Wanderwege ist nicht mehr sichtbar.

Issue 1 ! I want to ask Waymarkedtrails to render differently, but they will need a consensus about the tags which does conform to general principles.

A ref is not a name, so WMT can expect refs not to be lengthy names.

My preference for now in the test cases would be to put the node name in a new tag: rwn_name=*, and to simply put a zero in rwn_ref. This would produce reasonable rendering of the nodes and it would be accepted by the Knooppuntnet validations. In Knooppuntnet Planner it will route and produce a gpx-output, but the node strip output will not be usable.

All the node routes would get the tag ref=0-0 (which incidentally mimics a node2node route...). No name, no note. If you want to, you could enter the from and to information in the description tag.

Once consensus tagging has been established I'm sure WMT and Knooppuntnet will accept and honour requests for rendering and data-use, then the zeroes can removed.

Above all, I am curious about your preferences, because it's a German thing. The Dutch do not (yet) have named nodes.

Ich habe einen kleinen Test zum Rendern in WMT durchgeführt. https://hiking.waymarkedtrails.org/#rou … 116!8.1609

Oben rechts habe ich für zwei Punkte rwn_ref = 0 gemacht, oben links habe ich einen Punkt verwendet. Sie können den Namen der Kreuzung sehen, da sich der Wegweiser in der Nähe befindet. Darunter befinden sich die andere Namen im Knoten in einer roten Ellipse. Welches ist das Beste?
Oder sollte der Knotenname noch separat auf der Karte stehen, wie z.B. an einer Bushaltestelle?

Vertrackte Knotenpunktgeschichte Stadt Cottbus (CB) und Landkreis Spree-Neiße (SPN).

Ich hab mich eben mal um die vertrackte Knotenpunktgeschichte Stadt Cottbus gekümmert... Die Geschichte ist so, daß auf den Knotenpunktkarten an den Knotenpunkten im Landkreis SPN vor Ort auch das Stadtgebiet Cottbus mit abgedeckt wird und Knotenpunkte vergeben sind. Vom Knotenpunkt im Landkreis SPN wird auch auf den Knotenpunkt Stadt CB verwiesen, wo aber eben nicht ausgeschildert ist. Diese Info habe ich unanhängig von zwei Mappern: silverlion und MaGIStokrat, Danke dafür. Ich habe erst mal alle Knotenpunkte im Stadtgebiet Cottbus auf "proposed:rcn_ref=*" gesetzt und eine für Cottbus eine extra Netzwerk-Relation angelegt...
CS: https://www.openstreetmap.org/changeset/90474266
Relation https://www.openstreetmap.org/relation/11587560

Ich bin mir noch nicht sicher, wie man mit solchem hybriden Zwischenstand umgeht... die Punkte zu löschen fände ich sehr schlecht, da sie zu mindestens auf dem Papier existieren und Ausschilderung auf diese verweisen...

Wie ich mit den connection-Routen vom Landkreis SPN nach Stadt CB umgehe, weiß ich nich nicht. eventuell lasse ich die einfach...

Sven

...der sich ägert, daß sich Cottbus mal sperrt...

streckenkundler wrote:

Ich habe erst mal alle Knotenpunkte im Stadtgebiet Cottbus auf "proposed:rcn_ref=*" gesetzt und eine für Cottbus eine extra Netzwerk-Relation angelegt... die Punkte zu löschen fände ich sehr schlecht, da sie zu mindestens auf dem Papier existieren und Ausschilderung auf diese verweisen

Find ich genau richtig.

Inzwischen tut sich auch in BW etwas. Es wurden neue Wegweiser aufgestellt oder bestehende verändert. Das Verkehrsministerium BW hat anscheinend Karten mit Knotenpunkten und dazu Katasterblätter erstellt. Die Knoten sind bezeichnet mit meist 3 Buchstaben (Kreisstadt Ludwigsburg nur 2 Buchstaben=LB) und einer Zahl, in meinem Heimatort z.B. von BIE 1 bis BIE 37 (einschließlich der Zwischenwegweiser). An den Pfosten der Wegweiser befindet sich eine Art Banderole, auf der z.B. steht: www.radnetz-bw.de, Standortnummer: LB-BIE.016.1. Befinden sich an einem Knoten aus verschiedenen Richtungen mehrere Wegweiser, wird die letzte Ziffer entsprechend geändert auf 2, 3 oder 4. Die Kennzeichnung ist recht klein und von größerer Entfernung nicht lesbar. Die Richtung zu einer benachbarten Nummer eines Knotenpunktes findet sich auch nicht am Wegweiser-Schild.
Mir ist jetzt nicht bekannt, ob es in BW bereits Knotenpunktnetze, insbesondere im Kreis Ludwigsburg, von RadNETZ gibt, wenn ja, könnte das ein Kollege hier mal erklären. Über waymarkedtrails habe ich im Kreis LB jedenfalls noch keine solche Relation gefunden. Ich stelle mir vor:
a) Knotenpunkt
cycle_network=Knotenpunktwegweisung Landkreis Ludwigsburg
network:type=node_network
expected_rcn_route_relations=nn (die Anzahl der Kontenpunktrouten, die sich dort treffen)
rcn_ref=BIE 16
oder ist hier nur die 16 anzugeben? Die 16 kann aber auch im Nachbarort vorhanden sein.

b) Wegweiser
Die bereits bestehenden Wegweiser würde ich z.B. mit folgenden Tags ergänzen:
name=BIE 16.1
network=rcn
ref=16.1 (oder nur 16? Dann könnte bei einem Knoten 4-mal die 16 auftreten)

Erfreulich ist, dass auch waymarkedtrails Sachen wie direction_north=* auswertet. Da frage ich mich aber, warum wir Dinge erfinden, die vor Ort nicht existieren. Ich habe schon Hunderte von Radwegweisern gesehen, aber hinter der Zahl der Entfernungsangabe noch nie die Buchstaben „km“ entdecken können. Erfinden wir das „km“ dann künftig z.B. auch für maxspeed?

c) Relation zwischen 2 Knotenpunkten
name=Bietigheim-Bissingen (15) – Bietigheim-Bissingen (16)
network=rcn
network_type=node_network
type=route
route=bicycle
ref=mm-nn (z.B. 15-16)
cycle_network=Knotenpunktwegweisung Landkreis Ludwigsburg
Den Sinn der Knotenpunktrelation kann ich allerdings nicht erkennen, wenn die Entfernung zwischen 2 Knoten sehr gering ist. So beträgt z.B. die Entfernung zwischen BIE 15 und BIE 16 ca. 70 m. Während sich längere Strecken über https://cycling.waymarkedtrails.org zum Download und Nachfahren eignen, ist eine Strecke von 70 m doch uninteressant. Oder gibt es eine Möglichkeit, mehrere solcher anschließenden Relationen auf einmal als gpx-Datei per Download zu erhalten?
Gibt es bei der Aufnahme der Mitglieder der Relation eine bestimmte Reihenfolge zu beachten?
Bei der Busrelation müssen zuerst alle Haltestellen und dann die Streckenabschnitte aufgenommen werden.
In #60 ist das Beispiel https://www.openstreetmap.org/relation/10953915 aufgeführt. Da ist die Reihenfolge:
guidepost, Knotenpunkt, einzelne Streckenabschnitte, Knotenpunkt, guidepost.

d) Netzwerkrelation
type=network
network:type=node_network
network=rcn
name=RadNETZ Baden-Württemberg
operator= Baden-Württemberg - Ministerium für Verkehr

Ist bei der Aufnahme der Relationen eine bestimmte Reihenfolge zu beachten?
Bei der Netzwerkrelation https://www.openstreetmap.org/relation/10953719 sind zunächst die Knotenpunkte und dann die Relationen aufgenommen, m.E. aber nicht in einer bestimmten Reihenfolge.

Kann jemand meine Fragen beantworten und hat zu meinen Vorstellungen Verbesserungsvorschläge?

Sorry to reply in English!

For answers, I look at two things:
1. rendering (in waymarkedtrails, osmand, the OSM cycle layer and the upcoming Knooppuntnet planner)
2. nodenetwork routing from node to node using only the node network. (Not regular A to B routing).
The test-version of the Knooppuntnet node network planner is available here: https://experimental.knooppuntnet.nl/de/map/cycling

ghostrider44 wrote:

Inzwischen tut sich auch in BW etwas. Es wurden neue Wegweiser aufgestellt oder bestehende verändert. Das Verkehrsministerium BW hat anscheinend Karten mit Knotenpunkten und dazu Katasterblätter erstellt. Die Knoten sind bezeichnet mit meist 3 Buchstaben (Kreisstadt Ludwigsburg nur 2 Buchstaben=LB) und einer Zahl, in meinem Heimatort z.B. von BIE 1 bis BIE 37 (einschließlich der Zwischenwegweiser). An den Pfosten der Wegweiser befindet sich eine Art Banderole, auf der z.B. steht: www.radnetz-bw.de, Standortnummer: LB-BIE.016.1. Befinden sich an einem Knoten aus verschiedenen Richtungen mehrere Wegweiser, wird die letzte Ziffer entsprechend geändert auf 2, 3 oder 4. Die Kennzeichnung ist recht klein und von größerer Entfernung nicht lesbar. Die Richtung zu einer benachbarten Nummer eines Knotenpunktes findet sich auch nicht am Wegweiser-Schild.
Mir ist jetzt nicht bekannt, ob es in BW bereits Knotenpunktnetze, insbesondere im Kreis Ludwigsburg, von RadNETZ gibt, wenn ja, könnte das ein Kollege hier mal erklären. Über waymarkedtrails habe ich im Kreis LB jedenfalls noch keine solche Relation gefunden. Ich stelle mir vor:

a) Knotenpunkt
cycle_network=Knotenpunktwegweisung Landkreis Ludwigsburg
network:type=node_network
expected_rcn_route_relations=nn (die Anzahl der Kontenpunktrouten, die sich dort treffen)
rcn_ref=BIE 16
oder ist hier nur die 16 anzugeben? Die 16 kann aber auch im Nachbarort vorhanden sein.

cycle_network tag is, as far as I know, not used for 1. and 2.

If BIE is not really part of the number but indicates the network or the area, better leave that out. 3 characters is the max for the refs.

Repeating node numbers is no problem, as long as they have at least two other nodes in between. (Otherwise the intermediate node would point to the same number in two different directions...). Most areas in Nederland use numbers 01 to 99 all the time.

b) Wegweiser
Die bereits bestehenden Wegweiser würde ich z.B. mit folgenden Tags ergänzen:
name=BIE 16.1
network=rcn
ref=16.1 (oder nur 16? Dann könnte bei einem Knoten 4-mal die 16 auftreten)

Erfreulich ist, dass auch waymarkedtrails Sachen wie direction_north=* auswertet. Da frage ich mich aber, warum wir Dinge erfinden, die vor Ort nicht existieren. Ich habe schon Hunderte von Radwegweisern gesehen, aber hinter der Zahl der Entfernungsangabe noch nie die Buchstaben „km“ entdecken können. Erfinden wir das „km“ dann künftig z.B. auch für maxspeed?

The Wegweiser are not used in the nodework planner. They are rendered by waymarkedtrails and many other maps as separate objects near the nodes (which are the intersections of the ways). For the planner it does not matter, but if there are multiple guideposts and multiple nodes you would see an awful lot of numbers 16 if you gave them all names and numbers.
In Nederland, we do not tag names and numbers on the guidepost nodes, just on the network nodes.

c) Relation zwischen 2 Knotenpunkten
name=Bietigheim-Bissingen (15) – Bietigheim-Bissingen (16)
network=rcn
network_type=node_network
type=route
route=bicycle
ref=mm-nn (z.B. 15-16)
cycle_network=Knotenpunktwegweisung Landkreis Ludwigsburg

The name tag does not apply here, unless the route actually has name signs along the road with texts like "Bietigheim-Bissingen (15) – Bietigheim-Bissingen (16). You could put the text in the description tag, but is it really useful to tag all the node routes with the same information?

The cycle_network tag, I don't know if that is used in applications.

In Nederland, we used to tag information like this in node networks, but it was seldom updated and never used. Now we keep it surprisingly simple.
Just the bicycle nodes with the rcn_refs, and the bicycle route relations with refs, all tagged as network:type=node_network, that's all you need to make it display and work. This would be my advice: start with the bare minimum to make it work, and only if you (users) really miss something worth while, then add it later. Resist temptation to add everything you know.

Den Sinn der Knotenpunktrelation kann ich allerdings nicht erkennen, wenn die Entfernung zwischen 2 Knoten sehr gering ist. So beträgt z.B. die Entfernung zwischen BIE 15 und BIE 16 ca. 70 m. Während sich längere Strecken über https://cycling.waymarkedtrails.org zum Download und Nachfahren eignen, ist eine Strecke von 70 m doch uninteressant. Oder gibt es eine Möglichkeit, mehrere solcher anschließenden Relationen auf einmal als gpx-Datei per Download zu erhalten?

It is not about length, but about connectivity.
The Knooppuntnet planner is currently the only application for OSM node network routing. You click or tap some nodes, the planner connects the nodes following the node2node routes, and the result can be exported to a gpx file.

Gibt es bei der Aufnahme der Mitglieder der Relation eine bestimmte Reihenfolge zu beachten?
Bei der Busrelation müssen zuerst alle Haltestellen und dann die Streckenabschnitte aufgenommen werden.
In #60 ist das Beispiel https://www.openstreetmap.org/relation/10953915 aufgeführt. Da ist die Reihenfolge:
guidepost, Knotenpunkt, einzelne Streckenabschnitte, Knotenpunkt, guidepost.

The node network route relation does not need to contain the nodes. For cycling routes with backward/forward roles they even get in the way of sorting and the JOSM continuity line. Just the ways in the correct order, matching the ref tag.
In fact, because the nodes are part of the ways (first node of the first way, last node of the last way), the information is already there. The guideposts nodes are not part of the node network. They are rendered as separate nodes near the network node, and the node network routing does not use them.

d) Netzwerkrelation
type=network
network:type=node_network
network=rcn
name=RadNETZ Baden-Württemberg
operator= Baden-Württemberg - Ministerium für Verkehr

Ist bei der Aufnahme der Relationen eine bestimmte Reihenfolge zu beachten?
Bei der Netzwerkrelation https://www.openstreetmap.org/relation/10953719 sind zunächst die Knotenpunkte und dann die Relationen aufgenommen, m.E. aber nicht in einer bestimmten Reihenfolge.

The network relation is just a bag of items, a collection. Order is not important. If you try to sort it in JOSM's relation editor it will group the nodes together and the relations, without any order.
The network relation has no real use for rendering or routing. It mainly served as an entry point for the Knooppuntnet Analysis, but the new version offers Analysis and maintenance by admin_level hierarchy.
https://experimental.knooppuntnet.nl/de … is/cycling

Knooppunt Maintenance/analysis by named Network will continue to be supported, though.

Hope this helps! Next time I will try some German again, with a little help of GT.

Fr Gr,
--
Peter Elderson

Hallo Peter,
vielen Dank für die Antwort. Mein Englisch ist leider nicht besonders gut, ich glaube aber, dass ich den Großteil verstanden habe. Ich werde mich jetzt mal, wie von dir empfohlen, mit den wichtigsten Tags an die Sache herantasten und dann sehen, was noch zu ergänzen ist.

ghostrider44

Inzwischen habe ich einige Knotenpunktrelationen und eine Netzwerkrelation angelegt:
https://www.openstreetmap.org/relation/11606677
Folgendes ist mir noch nicht klar:
Bei der Relation https://www.openstreetmap.org/relation/11607208 ist am Beginn beim tatsächlichen Knotenpunkt ein highway=crossing eingetragen, bei den Relationen https://www.openstreetmap.org/relation/11606793 und https://www.openstreetmap.org/relation/11606792 am Ende bzw. Beginn ein highway=mini_roundabout. Ist dies ein Problem?

Die Nummerierung der Knotenpunkte ist in dem von mir bisher festgestellten Bereich von Nord nach Süd bzw. Ost nach West vorgenommen worden. Innerhalb einer Gemeinde sind somit die Nummern aufsteigend. Beim Wechsel in die Nachbargemeinde ist dies aber z.B. von (BIE)32 nach (SAC)02 bzw. (BIE)29 nach (TAM)02. Bei den Relationen https://www.openstreetmap.org/relation/11606791 und https://www.openstreetmap.org/relation/11606794 habe ich beim Erfassen der Wegstücke deshalb diese Reihenfolge eingehalten, somit also von 32 nach 02 bzw. 29 nach 02. Muss dies gedreht werden, damit die kleinere Ziffer vorne steht?

So wie ich dies bisher aufgenommen habe, ist pro Landkreis nur eine Netzwerkrelation vorgesehen. Deshalb schlage ich vor, dass weitere Knotenpunktrelationen von RadNETZ im Bereich des Landkreises Ludwigsburg in die folgende Netzwerkrelation eingefügt werden: https://www.openstreetmap.org/relation/11606677

crossing oder mini_roundabout kann auch Knotenpunt sein. Kein problem.

Nummerierungssystemen sind nicht sehr wichtig. Die Zahlen sind nur Etiketten. Das Routieren funktioniert auch ohne Nummer, nur auf ein Knotenliste will man die unterwegs sehen!

Manche Mapper haben beim Mappen gerne die Nummer von klein zu gross, aber das ist nicht notwendig. Was logisch ist, oder wie man es mit einander verabredet.

Das gilt (m.m.) auch für die Eingabe von Knotenpunkte in die Relation.

Kleine Frage: Sind diese Knotenpunkte alle richtige Wechselpunkte (expected_rwn_route_relations > 2) , oder sind manche nur Punkte an denen man vorbeigeht (exp... = 2)?

Peter Elderson wrote:

crossing oder mini_roundabout kann auch Knotenpunt sein. Kein problem.

Prinzipiell richtig, aber es kompliziert die Auswertung enorm.

toc-rox wrote:

Prinzipiell richtig, aber es kompliziert die Auswertung enorm.

Wie meinst du?

Peter Elderson wrote:

Wie meinst du?

In der Freizeitkarte-Android unterstützen wir die Knotenpunktnetze für Radfahrer, Wanderer und Inline-Skater. Im Moment überlegen wir, auch die Netze für Reiter, Kanu- und Motorbootfahrer zu unterstützen. Als aufwändig/problematisch (aber nicht unlösbar) haben sich zwei Sachverhalte erwiesen:
- mehrere Netzknoten an einem Node (z.B. cycling + hiking)
- Netzknoten an anderen Objekten (z.B. turning_loop)
Für uns war das nur lösbar, indem wir für jeden Netzknoten einen eigenen Node abgeleitet haben. Oder anders ausgedrückt: Ideal ist genau ein Netzknoten an einem extra dafür erzeugten Node. Dies ist aber aufgrund der praktischen Erfassung wohl unrealistisch.

toc-rox wrote:

Als aufwändig/problematisch (aber nicht unlösbar) haben sich zwei Sachverhalte erwiesen:
- mehrere Netzknoten an einem Node (z.B. cycling + hiking)

Beispiel: https://www.openstreetmap.org/node/195588382

network:type=node_network zeigt ja, das es ein Element eines oder mehrerer Netzwerke ist.

Reicht hier die Verwendung von rcn_ref, rwn_ref und ähnlich nicht aus zu Unterscheidung, um welche Netzwerke es sich handelt?

Für cycle_network könnte man ja analoghiking_network und so weiter einführen.

Selbst expected_rcn_route_relations kann man ja entsprechend anpassen.

@toc-rox Ah so. Aber, mehrere Noden genau an der gleichen Stelle platzieren, das wäre keine gute Idee, oder?
Mehrere Netzknoten an einem Node (z.B. cycling + hiking): Sollten sie gleichzeitig gezeigt werden? Ich denke nicht?
Netzknoten an anderen Objekten (z.B. turning_loop): sollendie im gleichen Layer gezeigt werden? Die Netzen werden meistens als separate Layer gezeigt, denke ich?

Parzelle13 wrote:

Für cycle_network könnte man ja analog hiking_network und so weiter einführen.

cycle_network=* is a name thing, not a type, right?

In my opinion, while the name can indicate the type, it would not be right to construct a cycle_network name from type/region/operator/signing system. A network name is what 's shown on the sign as the network name.

The cycle_network wiki page says to put the tag on all the routes. Nederland currently has 333 node networks (all types) with nearly 60.000 nodes and nearly 80.000 routes. I think operator and network name information is better tagged in the network relations! Then, if something changes e.g. the network is renamed or networks are fused, or the operator changes, you only need to edit the network relation, not all the node2node route relations and network nodes.

With node networks, the maintenance burden is gigantic, because of the sheer numbers of items and the constant stream of changes. Keeping it as simple as possible in the beginning saves you heaps of maintenance work (and complicated mechanical edits) later.

Ich habe gesagt!

Peter Elderson wrote:

Kleine Frage: Sind diese Knotenpunkte alle richtige Wechselpunkte (expected_rwn_route_relations > 2) , oder sind manche nur Punkte an denen man vorbeigeht (exp... = 2)?

Bei den aufgeführten Knotenpunkten steht immer ein entsprechender Wegweiser mit Zielangaben (keine Zwischenwegweiser mit nur einem grünen Pfeil). Das expected_rwn_route_relations habe ich meist weggelassen, da hier meist eine beschilderte Wegweisung abgeht, die aber keine Nummerierung hat und ich noch nicht genau weiß, wie ich diese anlege und einfüge. Einige Punkte haben tatsächlich aber nur die beiden Richtungen. Die Frage ist dann, endet bzw. beginnt hier die Relation nicht, sondern erst an einem Knotenpunkt mit expected_rwn_route_relations > 2? Wird also bis zu diesem durchgezogen?

Parzelle13 wrote:

toc-rox wrote:

Als aufwändig/problematisch (aber nicht unlösbar) haben sich zwei Sachverhalte erwiesen:
- mehrere Netzknoten an einem Node (z.B. cycling + hiking)

Reicht hier die Verwendung von rcn_ref, rwn_ref und ähnlich nicht aus zu Unterscheidung, um welche Netzwerke es sich handelt?

Bei der Freizeikarte-Android wird die render library mapsforge verwendet. Diese erlaubt die Text Darstellung nur über das Name Tag.
D.h. für jeder Knotenpunkt Bedarf es einer Vorauswertung, um die rcn_ref, rwn_ref, etc. zu transformieren. Wenn man aber die verschiedenen Netze trennen will, muss man sich für eines entscheiden. Oder man muss eigene Punkte erzeugen. Dies dann im gleichen ID Range wie die Rohdaten. 🙁 Dies ist aufwendig und führt immer wieder mal zu Problemen.

Solche "mapsforge Probleme" haben wir bei allen Mulituse-Nodes. Darum ist jeder, welcher mapsforge verwendet, kein Fan davon.

ghostrider44 wrote:

Bei den aufgeführten Knotenpunkten steht immer ein entsprechender Wegweiser mit Zielangaben (keine Zwischenwegweiser mit nur einem grünen Pfeil). Das expected_rwn_route_relations habe ich meist weggelassen, da hier meist eine beschilderte Wegweisung abgeht, die aber keine Nummerierung hat und ich noch nicht genau weiß, wie ich diese anlege und einfüge. Einige Punkte haben tatsächlich aber nur die beiden Richtungen. Die Frage ist dann, endet bzw. beginnt hier die Relation nicht, sondern erst an einem Knotenpunkt mit expected_rwn_route_relations > 2? Wird also bis zu diesem durchgezogen?

Der Punkt ist, dass die Knoten mittels der Zahlen aufeinander verweisen. An den Knotenpunkten wählt man kein endgültiges Ziel, sondern eine nachfolgende Nummer wo man wieder wählt. Die Route zwischen zwei Punkte die nach einander verweisen ist ein Knotenpunktrelation. In ein richtiges Knotenpunktnetz sind die meiste Knotenpunkte exp... > 2.

Peter Elderson wrote:

Der Punkt ist, dass die Knoten mittels der Zahlen aufeinander verweisen. An den Knotenpunkten wählt man kein endgültiges Ziel, sondern eine nachfolgende Nummer wo man wieder wählt. Die Route zwischen zwei Punkte die nach einander verweisen ist ein Knotenpunktrelation. In ein richtiges Knotenpunktnetz sind die meiste Knotenpunkte exp... > 2.

Genau das ist hier das Problem. Wie ich bisher erkennen konnte, verläuft durch den Landkreis Ludwigsburg von Norden nach Süden ab Kirchheim am Neckar über Bietigheim-Bissingen und Ludwigsburg bis Kornwestheim nur eine Strecke mit Knotenpunkten und von Bietigheim-Bissingen nach Vaihingen an der Enz von Ost nach West eine weitere Strecke mit Knotenpunkten. Alle weiteren ausgeschilderten Strecken haben nach meinen Kenntnissen keine Nummer, somit auch keinen bekannten Knotenpunkt. Bis wann sich da noch was ändert, ist mir nicht bekannt.

Sorry to press this point. In node networks, the routes are not numbered, or if they are the route numers are not part of the node network.

The nodes have numbers and point to adjacent nodes by node number.

So node xx points to node yy using an arrow or pointer mentioning yy as the next node in a particular direction, and node number yy points back to xx and forward to zz [, aa, bbb, ...]. No similar numbers in between.

If that is not the case, it is not a node_network. A node is a point where you choose directions to other nodes.

So, not every numbered guidepost is a network node. If it does not direct you to another number it is not a network node.

From the description I get the impression the routes do bring you along numbered points, but these are not used to choose directions, they are more like numbered milestones on a fixed route.
Of course this could be the beginning of a real node network, but one long route cannot be a network, can it?

Peter Elderson wrote:

From the description I get the impression the routes do bring you along numbered points, but these are not used to choose directions, they are more like numbered milestones on a fixed route.
Of course this could be the beginning of a real node network, but one long route cannot be a network, can it?

Ich hoffe, dass dies der Beginn ist eines echten Knotennetzwerks. Im Bundesland Baden-Württemberg wurden jetzt vom Verkehrsministerium
BW zum ersten Mal Knotenpunkte festgelegt und bei diesen Wegweiser aufgestellt. Neben dem Land planen auch der Landkreis und die Gemeinde (zumindest an meinem Wohnort) ein Radnetz zu erstellen. Bis wann dies fertig ist, weiß momentan niemand. Ich wollte jetzt aber bereits die von anderen Mappern erstellten Relationen, bezeichnet mit "Radroutennetzwerk, Streckenrelation zwischen zwei Knotenpunkten" entlang den neuen Knotenpunkten, die zumindest eine feste Nummer haben, in ein Netzwerk aufnehmen, damit das Ganze auch übersichtlicher wird.

Wieder eines komplett...

Das Knotenpunktnetz meines heimischen Landkreises Dahme-Spreewald ist nun zu 100% fertig: https://knooppuntnet.nl/en/network/10953719 zumindestens soweit ich es vor Ort feststellen konnte. Mein Dank gilt auch den Usern WegefanHB, der mich mit Fotos unterstützt hat und besonders auch den Usern FA-KW und Osmegnos die den Nordteil des Kreises bearbeitet haben...
Damit ist das Netz wahrscheinlich eher in OSM, als das es eine Papierkarte gibt. Eine letzte Liste mit Anmerkungen und fehlenden Schildern geht noch an den Landkreis.

Mal sehen, wieweit ich mit den angrenzenden Netzen Landkreise Elbe-Elster, Oberspreewald-Lausitz und Spree-Neiße komme... Fotos mit Geokoordinaten von nicht erfassten Knotenpunkten sind immer Willkommen.

Sven

Sieht gut aus! Und der neue Planer funktioniert gut damit. https://experimental.knooppuntnet.nl/nl/map/cycling

Kudos!

Habe das gerade gesehen: "Datum letzte Inspektion" als farbliche Darstellung - sehr gut.
Dazu müsste aber ein check_date= in die Daten - meine Meinung - an die Relation und Knotenpunkte. Falls die Auswertung über "last updated" erfolgt genügt ein "verschieben eines nodes (Wegweiser)" zur angeblichen Prüfung.

geri-oc wrote:

Habe das gerade gesehen: "Datum letzte Inspektion" als farbliche Darstellung - sehr gut.
Dazu müsste aber ein check_date= in die Daten - meine Meinung - an die Relation und Knotenpunkte. Falls die Auswertung über "last updated" erfolgt genügt ein "verschieben eines nodes (Wegweiser)" zur angeblichen Prüfung.

Recht so. Das Wichtigste ist aber jetzt, die Knoten systematisch einzuführen. Wenn's nicht komplett in OSM steht, kann man überhaupt nicht zuverlassig planen.

Worauf ich ja auch geachtet habe, zusätzlich zu dei Knotenpunkten und Routen sind die Themenradrouten. Daher ist es essenziell, auch Fotos der Knoten zu haben. Gelegentlich wurden diese Themenradrouten in der Routenführung verändert, oder weichen (noch) vom Knotenpunktnetz ab. Das habe ich einmal, in Langengrassau...https://cycling.waymarkedtrails.org/#?m … 59!13.6343

Manchmal tauchen auch nicht erfasste Routen auf, so z.B. einige im Muskauer Faltenbogen...

Vor allem solche Routen anzupassen ist recht aufwendig...

Sven

streckenkundler wrote:

Worauf ich ja auch geachtet habe, zusätzlich zu dei Knotenpunkten und Routen sind die Themenradrouten. Daher ist es essenziell, auch Fotos der Knoten zu haben. Gelegentlich wurden diese Themenradrouten in der Routenführung verändert, oder weichen (noch) vom Knotenpunktnetz ab. Das habe ich einmal, in Langengrassau...https://cycling.waymarkedtrails.org/#?m … 59!13.6343

Manchmal tauchen auch nicht erfasste Routen auf, so z.B. einige im Muskauer Faltenbogen...

Vor allem solche Routen anzupassen ist recht aufwendig...

Sven

The torture never stops - Frank Zappa

streckenkundler wrote:

Daher ist es essenziell, auch Fotos der Knoten zu haben

und warum dann nicht mit image=* verlinken am "Wegweiser" (Knoten)? Dann kann auch einmal die andere Route kontrolliert/Korrigiert werden. Lieber später eventuell ein älteres Foto - sagt auch mehr als "Worte".

geri-oc wrote:

streckenkundler wrote:

Daher ist es essenziell, auch Fotos der Knoten zu haben

und warum dann nicht mit image=* verlinken am "Wegweiser" (Knoten)? Dann kann auch einmal die andere Route kontrolliert/Korrigiert werden. Lieber später eventuell ein älteres Foto - sagt auch mehr als "Worte".

Ja, das wäre schön, wenn so einfach ginge... 🙁

Ich habe immer mehrere Fotos pro Knotenpunkt... Nur wenn man äußerstes Glück hat reicht eines, in der Regel brauche ich für LDS immer mind. 3 Fotos... 2 für die Richtungsfahnen und eines für die Pfostennummer (+1 für die Karte am Pfosten). Ja und aus 3 eines zu machen ist auch nicht so leicht... und mir fehlt die Zeit... bei ca. 200 Knotenpunkten in LDS gehen vielleicht 2/3 aud mein Konto...

Sven

geri-oc wrote:

Habe das gerade gesehen: "Datum letzte Inspektion" als farbliche Darstellung - sehr gut.
Dazu müsste aber ein check_date= in die Daten - meine Meinung - an die Relation und Knotenpunkte. Falls die Auswertung über "last updated" erfolgt genügt ein "verschieben eines nodes (Wegweiser)" zur angeblichen Prüfung.

I am glad you like this function. Knooppuntnet currently looks at tag "survey:date=*", or the combination of "source=survey" and "source:date=*". It looks like it would be useful to add "check_date=*" to this?

Hallo,

seit einigen Tagen beschäftige ich mich relativ intensiv mit den Rad- und Wanderrouten im Rheinland (bisher in der Region zwischen Köln und Bonn). Die Knotenpunktnetzwerke sind hier bereits relativ gut erfasst, die übrigen Routen waren jedoch größtenteils in einem schlechten oder veralteten Zustand (bis 10 Jahre alt). Ich habe nun folgenden Gedanken:

Viele aktuelle Themenradrouten sind zum großen Teil auf das Knotenpunktnetzwerk gelegt und somit eine Aneinanderreihung von Knotenpunktrouten. Wäre es sinnvoll, die Themenrouten aus den Knotenpunktrouten-Relationen zusammenzusetzen, statt aus den einzelnen Linien der Wege? Dann wären die einzelnen Linien der Wege nur noch Bestandteil einer Relation (der Knotenpunktroute) statt zweien oder mehr. Das könnte den Wartungsaufwand verringern.

Testweise habe ich das mal bei der von mir neu angelegten RegioGrün Erlebnisroute Süd so gemacht. Zumindest auf waymarkedtrails wird das so aber nicht richtig gerendert.

Gibt es bereits Überlegungen zu dem Thema? Ich konnte bisher leider nichts dazu finden, auch kein anderes Beispiel. Müssen die Kind-Relationen eine bestimmte role erhalten?

Ich habe in den Niederlanden damit experimentiert. Es ist möglich, aber es ist sehr schwierig zu verwalten, wenn es mehr als etwa 10 Node2node Routen werden. Ich mache es also nicht mehr mit längeren Strecken, sondern nur mit kürzeren Rundwanderungen via 3-10 Knotenpunkte.

Ich verwende die Regel, dass der Operator sie selbst als Knotenpunktwanderung anbietet.

z.B.
https://hiking.waymarkedtrails.org/#routelist und https://hiking.waymarkedtrails.org/#rou … 839!5.1994

Peter Elderson wrote:

Es ist möglich, aber es ist sehr schwierig zu verwalten, wenn es mehr als etwa 10 Node2node Routen werden.

Warum ist das schwierig?

Peter Elderson wrote:

Ich verwende die Regel, dass der Operator sie selbst als Knotenpunktwanderung anbietet.

Ok, dann werde ich auch erstmal keine Knotenpunktrouten in Themenrouten aufnehmen und stattdessen ganz normal die Wege erfassen.

Bei meinem Beispiel funktioniert das Rendering auf waymarkedtrails mit den Themenrouten auch immer noch nicht richtig. Die gezeichnete Linie und die Schilder sind unvollständig, das Highlighting bei ausgewählter Route ist aber da. Ich werde die Route in den nächsten Tagen zur einfachen Route ohne Kind Relationen umbauen.

Duvodas wrote:

Warum ist das schwierig?

Die richtige Anordnung. Man kann das nicht einfach sehen und die Sortierfunktion macht das auch nicht.

Duvodas wrote:

Bei meinem Beispiel funktioniert das Rendering auf waymarkedtrails mit den Themenrouten auch immer noch nicht richtig.

Das ist das Anordnungsproblem. Man muss die Kind-Relationen selbst in die richtige Reihenfolge bringen. Erst dann kan WMT sie als eine Totalroute verwenden. Das Höhenprofil in WMT zeigt das Problem.

Ok, bisher habe ich die Sortierfunktion von JOSM nicht verwendet und immer alles von Hand sortiert. Ich habe das Gefühl, vor allem bei parallelen Teilstrecken mit Einbahnstraßen und den forward/backward Rollen geht das besser.

Die Kind Relationen habe ich auch in der richtigen Reihenfolge aufgenommen. Funktioniert es vielleicht nur, wenn innerhalb der Knotenpunktrouten die Linien in der richtigen Reihenfolge sind? Also muss es z.B. 4-8,8-15,15-3 sein und 4-8,15-8,15-3 funktioniert nicht?

Auffällig ist folgendes: Ich habe weder meine obige Beispielrelation noch die entsprechenden Knotenpunktrouten angefasst und seit gestern wird bei WMT plötzlich der nördliche Teil der Route richtig gerendert. Meine einzige Änderung in dem Gebiet war, dass ich das Radverkehrsnetz NRW in Köln von type=route auf type=network geändert habe. Aber das sollte mit der Themenroute ja nicht in Zusammenhang stehen.

LS
Ein französischer Mapper gebt jetzt Netzwerke in der Nähe von Toulouse ein. Das sind richtige Knotenpunktnetzwerke mit Namen, keine Zahlen.
Er möchte, dass es gut aussieht und funktioniert in waymarkedtrails, OsmAnd und Knooppuntnet Analyse un Knooppuntnet Planner.

Wir haben noch keinen Konsens über die endgültige Tagging, aber er möchte die Daten bereits eingeben. Vorläufige Lösung:
(auf English, entschuldige)

guidepost node on its exact position:
* tag name and ele and whatever you normally put on it (in this case they were already present)

network nodes (= intersections of the ways where the routes end/start)
network:type=node_network
rwn_name=<guidepost name>
rwn_ref=o (lowercase letter o)

network routes (mode2node route relations)
network:type=node_network
ref=o-o (lowercase letter o, hyphen, lowercase o)
name=<start node's rwn_name>-<end node's rwn_name)

network relation
network:type=node_network
name
operator
... whatever deemed necessary.

Note that network relations are not really necessary any more.
Also, the node2node routes do not really need the name tag. But it looks good in Waymarkedtrails!
The guideposts may be included in the route relations with the role guidepost, but this is not necessary.

This temporary scheme will give no "facts" in Knooppuntnet Analyse, Knooppuntnet Planner will work technically, and Waymarkedtrails and OsmAnd have a reasonable rendering and information popups/sidebar.
Knooppuntnet has been asked to display rwn_name instead of rwn_ref in the result list and in the pfd exports.

Peter Elderson wrote:

network nodes (= intersections of the ways where the routes end/start)
network:type=node_network
rwn_name=<guidepost name>
rwn_ref=o (lowercase letter o)
...
network routes (mode2node route relations)
network:type=node_network
ref=o-o  (lowercase letter o, hyphen, lowercase o)

Meines Erachtens ist die Einführung von 'rwn_name=*' unnötig und 'rwn_ref=o' eine sehr unglückliche Anwendung.

'rwn_ref=o' enthält nicht die Aussage, dass es keine Referenz gibt. Es sagt, dassdie Referenzbezeichnung "o" lautet. Wir haben dann hunderte unterschiedliche Knoten mit der gleichen Referenz, das ist nicht gut! Das gilt genauso für 'ref=o-o' an den Verbindungen.

Wenn in Frankreich der Name die Referenz darstellt, so kann dieser in der Form 'rwn_ref=<guidepost name>' angegeben sein. Es ist ja nirgends festgelegt, dass 'ref=*' eine Zahl sein muss. Analog dann auch das 'ref=<start node's rwn_ref>-<end node's rwn_ref>'

Somit kann des vorhandene Schema komplett verwendet werden, oder?

Auch ich habe angefangen das Wandernetzwerk in meiner Gegend als Knotenpunktnetzwerk zu taggen. Allerdings würde ich das etwas anders machen, als ihr es in Frankreich umgesetzt habt. Hier meine Verbesserungsvorschläge:

guidepost node on its exact position:

• tag name and ele and whatever you normally put on it (in this case they were already present)
  

network nodes (= intersections of the ways where the routes end/start)
network:type=node_network
rwn_name=<guidepost name> -> For more dense and local networks rather lwn_name=
rwn_ref=o (lowercase letter o) -> In my eyes tagging for the renderer

network routes (mode2node route relations)
network:type=node_network
ref=o-o (lowercase letter o, hyphen, lowercase o)
name=<start node's rwn_name> - <end node's rwn_name> -> I would add spaces before and after the "-" because in my area some names already contain it as a Bindestrich (e.g. "Sausteig-Lourdes-Grotte" -> "Sausteig - Lourdes-Grotte")
* The route relation also contains the guideposts at the end and the start of the route segment

network relation
network:type=node_network
name
operator
... whatever deemed necessary.

JochenB wrote:

Meines Erachtens ist die Einführung von 'rwn_name=*' unnötig und 'rwn_ref=o' eine sehr unglückliche Anwendung.

(Sorry to respond in English, mein Deutsch reicht nicht)

I agree withe the rwn_ref observation, and I understand the rwn_name observation. Explanation:

This is the temporary setup to make the current setup work with the universal node network planner Knooppuntnet Planner. See https://knooppuntnet.nl/nl/map/hiking and search/pan/zoom to south-east of Toulouse, give it a try!

The bigger picture is this:
I want to get rid of this trick as soon as possible. To do that, I need an approved tagging scheme, or else the data users will not make the necesasary changes. I have some experience in getting consensus in a relatively unknown field - it's impossible without a working model.
In the meantime, mappers want to move on.
This tempory scheme allows mappers to move on and enter the data, and start using the current applications. It does not break anything, and it allows data_entry in a way that can be easily reused /retagged.

Now to be more concrete:

The rwn_ref (r*n_ref) was designed for max 2 characters, numbers only. It was adapted to max 3: one letter two numbers, because operators started to use that. We have tried longer refs in the Schlossberg test, you can see the result in WMT here on the second picture: https://wiki.openstreetmap.org/wiki/Pro … e_networks
Knooppuntnet and OsmAnd also did not display this well. Other applications, I dont know, but it's clear this is not the solution.

As for the choice of o when there is no r*n_ref: it's a visual choice. o for naught. It's been used and documented: https://wiki.openstreetmap.org/wiki/Tag … 5#Examples

The o-o ref is then necessary to make Knooppuntnet Planner work. As it heappens, it resembles a node-node connection. In WMT it looks like this: https://hiking.waymarkedtrails.org/#rou … 088!1.4901 (hope this works...)
Notice how the guidposts near the network nodes show the name when zooming in. You can even click there and get the guidepost information.

While you are on the page, you might take a look at the issues and possible solutions...

This does not mean it should remain that way - but I think it is acceptable as a model and for data entry until the "dummy" rwn_ref and route ref can be eliminated. I have already asked Knooppuntnet if they will accommodate rwn_name instead of rwn_ref (what it would take to add this to their program).

Dummydaten sollte es nicht geben. Priorität sollte ref haben, name ist als Ergänzung zu betrachten.

Karthoo wrote:

Auch ich habe angefangen das Wandernetzwerk in meiner Gegend als Knotenpunktnetzwerk zu taggen. Allerdings würde ich das etwas anders machen, als ihr es in Frankreich umgesetzt habt. Hier meine Verbesserungsvorschläge:

rwn_ref=o (lowercase letter o) -> In my eyes tagging for the renderer

name=<start node's rwn_name> - <end node's rwn_name> -> I would add spaces before and after the "-" because in my area some names already contain it as a Bindestrich (e.g. "Sausteig-Lourdes-Grotte" -> "Sausteig - Lourdes-Grotte")

I agree, the o and o-o trick is tagging for ... well, not so much the renderer, it's for the checking utility Knooppuntnet Analysis and the Knooppuntnet Planner.
I find these are essential for systematic entry and use of node networks (please take a look at Belgium and the Netherlands, for walking and cycling to see the extent of node networks there). The Knooppuntnet Planner is the only utility that makes the OSM node network information directly available for planning and navigation, that's why I think it is important to have a temorary solution to make it work while an approved permanent scheme is discussed and passed.

toc-rox wrote:

Dummydaten sollte es nicht geben. Priorität sollte ref haben, name ist als Ergänzung zu betrachten.

Did you read https://wiki.openstreetmap.org/wiki/Pro … e_networks ?
Maybe you would like to add some comments there?

toc-rox wrote:

Dummydaten sollte es nicht geben

Thought about this some more. It's not really dummy data - it's a value saying there is no rwn_ref. Comparable to 'none', '0' (zero) and 'no' values of other keys.

KISS ... do not over-engineer the concept.

toc-rox wrote:

KISS ... do not over-engineer the concept.

Not really helpful... what exactly do you mean?

Karthoo wrote:

name=<start node's rwn_name> - <end node's rwn_name>  -> I would add spaces before and after the "-" because in my area some names already contain it as a Bindestrich (e.g. "Sausteig-Lourdes-Grotte" -> "Sausteig - Lourdes-Grotte")

• The route relation also contains the guideposts at the end and the start of the route segment
  

Names: In the proposal as well as and in the temporary setup, names and punctuation on the route relations are optional and free format.
Guideposts: Optional in all hiking routes.

I would like to know the rationale for adding guideposts to the route. I don't know of any application of that association, do you? The applications I know just ignore the guidepost members.

Ah, ich habe erst jetz gesehen, dass der Vorschlag 'rwn_name=*' hier schon länger diskutiert wird und im Wiki gelesen, dass 'ref=*' eher was mit Zahlen ist, mitunter sogar mit begrenzter Länge. Mein Post #163 ist damit hinfällig.

Grundsätzlich fände ich das Verwenden von 'name' am Knoten und 'from=*' und 'to=*' an der Relation der Wegeverbindung wunderbar einfach und völlig ausreichend. Ich verstehe den Mehrwert von 'rwn_name=*' nicht. Ich habe aber nicht die ganzen 171 Beiträge durchgelesen - krasser Thread! - und mein Englisch ist begrenzt.

Dafür muss der Knoten lediglich ohne Verwendung von 'rwn_ref=*' als als Netzwerknoten des jeweiligen Netzwerkes markiert werden. Daran erkennt der Renderer, dass er den Kreis zeichnen muss. Wenn mehrere Namen am Knoten notwendig werden, dann nutzt man Namensräume. Ein Knoten könnte dann so aussehen:

rwn:name=Katzensteinerhof
rwn:network:type=node_network

Da der Renderer kein 'rwn_ref=*' findet, schreibt er keine Zahl in den Kreis und setzt den Name daneben - fertig.

Das mit dem 'rwn_ref=o' und 'ref=o-o' widerstrebt mir zutiefst. Nicht nur weil es "Tagging für Renderer" ist, sondern auch, weil ein Merkmal für etwas "missbraucht" wird, wofür es nicht gedacht ist. Dann besser ein temporäres zusätzliches Merkmal erfinden wie 'rwn:has_ref=no', dann bleibt da alte Merkmal sauber.

Im Wiki steht dazu: "Wenn eine Straße oder ein Weg keine Nummer hat, benutze diesen Schlüssel nicht; damit ist sichergestellt, dass Navigationsprogramme nicht versuchen, die Straße mit einer Nummer zu benennen.".

Ich würde für Geduld plädieren, bis die Renderer mit einer neuen Lösung umgehen können und bis dahin 'rwn_ref=*' nicht füllen und/oder nur 'rwn:has_ref=no' taggen.

edit: statt 'node_network_node=yes' das etablierte 'network:type=node_network' verwendet

Grundsätzlich: Ist ein Netzwerk ein Knotenpunktnetzwerk, nur weil die Wegweiser einen Namen haben? Für mich absolut nicht.

Knotenpunktwegweisung wäre es m. E. erst, wenn

a) auf den Wegweisen ausschließlich die Namen der nächsten Knoten ausgeschildert würden,

oder

b) sich die Ausschilderung der nächsten Knoten optisch stark von der Ausschilderung entfernter liegender Ziele unterscheidet (bei Radwegnetzen in Deutschland durch Einschübe mit den Nummern unten am klassischen Wegweiser)

Das Beispielbild vom Wegweiser "Katzensteinerhof" im Proposal hat für mich keine Merkmale eines Knotenpunktnetzwerkes. Es ist nur ein Wegweiser einer klassischen Wegweisung mit einem Namen.

Womöglich gibt es gar keine Knotenpunktnetzwerke ohne Knotenpunktnummern und das ist eine Phantom-Diskussion durch ein Missverständnis, was ein Knotenpunktnetzwerk ausmacht.

Peter Elderson wrote:

I would like to know the rationale for adding guideposts to the route. I don't know of any application of that association, do you? The applications I know just ignore the guidepost members.

Ich finde mehrer Gründe, um Wegweiser in die Relationen aufzunehmen:

Wegweiser helfen bei der Orientierung. Womöglich ist es hilfreich, beim Verfolgen einer Route die zugehörigen Wegweiser mit anzukündigen und alle anderen Wegweiser auszublenden.

Mitunter gibt es mehrere Wegweiser an einer Kreuzung an verschiedenen Standorten. So weiß man, in welche Richtung man schauen muss.

Es gibt Routen, die sind nicht an jedem Wegweiser ausgeschildert. So weiß mann, dass man sich nicht verlaufen hat, nur weil ein Zwischenwegweiser nicht das Routensymbol hat.

Man kann statistisch auswerten, wieviele Wegweiser zu einer Route aufgestellt wurden. Routen mit vielen Wegweisern gelten als gut ausgeschildert, was ein Qualitätsmerkmal sein kann.

Peter Elderson wrote:

toc-rox wrote:

KISS ... do not over-engineer the concept.

Not really helpful... what exactly do you mean?

kiss = keep it simple and stupid

JochenB wrote:

Grundsätzlich: Ist ein Netzwerk ein Knotenpunktnetzwerk, nur weil die Wegweiser einen Namen haben? Für mich absolut nicht.

Knotenpunktwegweisung wäre es m. E. erst, wenn

a) auf den Wegweisen ausschließlich die Namen der nächsten Knoten ausgeschildert würden,

oder

b) sich die Ausschilderung der nächsten Knoten optisch stark von der Ausschilderung entfernter liegender Ziele unterscheidet (bei Radwegnetzen in Deutschland durch Einschübe mit den Nummern unten am klassischen Wegweiser)

Das Beispielbild vom Wegweiser "Katzensteinerhof" im Proposal hat für mich keine Merkmale eines Knotenpunktnetzwerkes. Es ist nur ein Wegweiser einer klassischen Wegweisung mit einem Namen.

Womöglich gibt es gar keine Knotenpunktnetzwerke ohne Knotenpunktnummern und das ist eine Phantom-Diskussion durch ein Missverständnis, was ein Knotenpunktnetzwerk ausmacht.

Zuerst habe ich genau das Gleiche gedacht, aber das zweite Beispielbild (Hilsenberg) hat mich überzeugt.
Für mich ist entscheidend, das es ein spezielles Netz von Kreuzungen gibt, die auf einander zeigen, und das unterwegs ein einziges Zeichen oder Symbol die Route zum nächsten Kreuzung in das Netz zeigt. Man folgt nicht ein Wanderung wie "die Rote Wanderung", aber man plant seine eigene Route durch das Netz, durch Aneinanderreihen kurzerer Strecken, die alle mit dem gelben Diamanten markiert sind.

Ich erinnere mich an einen Urlaub in Deutschland, in dem meine Frau und ich dachten, wir würden den Yellow Diamond Walk machen. Wir haben uns hoffnungslos verlaufen, und überall schienen gelbe Raute zu sein; wir haben es einfach nicht verstanden. Erst jetzt verstehe ich warum: Knotennetzwerk, nur mit Namen statt Nummern!

Der Katzensteinerhof Wegweiser zeigt: Operator und Symbol für dat ganze Netzwerk; Name; Namen und Richtungen benachbarte Auswahlpunkte (erste Name pro "Hand"). Klassische Wegweisung gibt an erster Stelle Endziele die man auf jedem Wegweiser seht. Direkt benachbarte Auswahlpunkte zeigen Katzensteinerhof am ersten Stelle. Die zweite un dritte Reihe sind "Service": sie Zeigen bereits die nächste Auswahl.

Also ja, das ist ein Knotenpunktnetzwerk, nur mit Namen statt Nummern.

toc-rox wrote:

Peter Elderson wrote:

toc-rox wrote:

KISS ... do not over-engineer the concept.

Not really helpful... what exactly do you mean?

kiss = keep it simple and stupid

I can add that solution to the proposal page, I'm just not sure to which issue...

Ich habe noch einen Gedanken zur Vergabe von rwn_ref. rwn_ref=o finde ich auch nicht gut. rwn_ref sollte ein kurzer (1-,2-,3- oder bis zu 5-stellig) Ausdruck sein, der auf ein Objekt verweist und an dessen Namen angelehnt ist.
Wenn das Objekt nun zwar einen Namen ("Katzensteiner Hof") aber keinen offiziellen ref hat, dann könnte der Mapper eine Abkürzung wählen, deren Länge eine vorgegebene maximale Länge (2-,3- oder bis zu 5-stellig) nicht überschreitet, aber eindeutig auf den vollständigen Namen verweist. Genau so sind doch bereits die meisten Rad- und Wanderrouten erfasst. Es gibt meistens einen Namen, aber keinen offiziellen ref, so dass der Mapper den ref frei vergibt.

Beispiele: PeerkePad -> PP, Ronde van Nederland -> RvN, Deutsche Fußball Route NRW -> DFR.

Für Katzensteiner Hof würde ich einfach rwn_ref=KH vergeben. Weiteres Beispiel für eine der Netzwerkrouten bei Toulouse:
Ancienne Vigne - La Garrigue

network node "Ancienne Vigne"
network:type=node_network
rwn_name=Ancienne Vigne
rwn_ref=AV

network node "La Garrigue"
network:type=node_network
rwn_name=La Garrigue
rwn_ref=LG

network route
network:type=node_network
ref=AV-LG
name=Ancienne Vigne - La Garrigue

Damit würden wir kein neues Schema einführen. Wir würden stattdessen einfach ein Schema fortführen, das in einem verwandten Bereich (den Routen) bereits so angewandt wird.

JochenB wrote:

Grundsätzlich fände ich das Verwenden von 'name' am Knoten und 'from=*' und 'to=*' an der Relation der Wegeverbindung wunderbar einfach und völlig ausreichend. Ich verstehe den Mehrwert von 'rwn_name=*' nicht..

1.
Analogie mit rwn_ref. Wir haben auch rcn_ref, rhn_ref, rpn_ref, rmn_ref und rin_ref, und im Zukunft möglist mehr. Ein einzelnes Node kann mehrere Nummern tragen, also ref ist nicht unterschiedend. Daher r*n_ref. Für Namen gilt das auch, sicher wenn meherere Operators Netzwerke verwalten.
2.
name= sollte der Namen eines sichtbaren Objekts sein (wiki). Knotenpunkte (intersections) sind keine sichtbare Objekten, die Wegweiser sind die Objekte und sie tragen den Namen schon. Der Knotenpunkt referiert an den Namen des Wegweisers für das r*n_ Netzwerk.

Dafür muss der Knoten lediglich ohne Verwendung von 'rwn_ref=*' als als Netzwerknoten des jeweiligen Netzwerkes markiert werden. Daran erkennt der Renderer, dass er den Kreis zeichnen muss. Wenn mehrere Namen am Knoten notwendig werden, dann nutzt man Namensräume. Ein Knoten könnte dann so aussehen:

rwn:name=Katzensteinerhof
rwn:network:type=node_network

Da der Renderer kein 'rwn_ref=*' findet, schreibt er keine Zahl in den Kreis und setzt den Name daneben - fertig.

Diese Vorschlag ist bereits im Proposal enthalten: rwn:name statt rwn_name.
Renderer, Router un Planer können rwn*name als erste benutzen; wenn es die nicht gibt, rwn_ref. Das ist generisch für alle r*n Knotenpunktnetzwerken

Das mit dem 'rwn_ref=o' und 'ref=o-o' widerstrebt mir zutiefst. Nicht nur weil es "Tagging für Renderer" ist, sondern auch, weil ein Merkmal für etwas "missbraucht" wird, wofür es nicht gedacht ist. Dann besser ein temporäres zusätzliches Merkmal erfinden wie 'rwn:has_ref=no', dann bleibt da alte Merkmal sauber.

Das hilft nicht als Zwischenlösung für Knooppuntnet Planner. Dann besser nichts machen, denk ich. Dann hat Deutschland keinen Pilotmodell. Auch kein Problem.

Ich würde für Geduld plädieren, bis die Renderer mit einer neuen Lösung umgehen können und bis dahin 'rwn_ref=*' nicht füllen und/oder nur 'rwn:has_ref=no' taggen.

Die Renderer sind kein Problem, dafür braucht man nichts extra zu taggen, was die Renderer überhaupt nicht verwenden werden!

JochenB wrote:

Peter Elderson wrote:

I would like to know the rationale for adding guideposts to the route. I don't know of any application of that association, do you? The applications I know just ignore the guidepost members.

Ich finde mehrer Gründe, um Wegweiser in die Relationen aufzunehmen:

Wegweiser helfen bei der Orientierung. Womöglich ist es hilfreich, beim Verfolgen einer Route die zugehörigen Wegweiser mit anzukündigen und alle anderen Wegweiser auszublenden.

Mitunter gibt es mehrere Wegweiser an einer Kreuzung an verschiedenen Standorten. So weiß man, in welche Richtung man schauen muss.

Es gibt Routen, die sind nicht an jedem Wegweiser ausgeschildert. So weiß mann, dass man sich nicht verlaufen hat, nur weil ein Zwischenwegweiser nicht das Routensymbol hat.

Man kann statistisch auswerten, wieviele Wegweiser zu einer Route aufgestellt wurden. Routen mit vielen Wegweisern gelten als gut ausgeschildert, was ein Qualitätsmerkmal sein kann.

Danke! Gibt es Apps die das so machen oder machen können? Vielleicht für Radknotenpunktrouten?

Duvodas wrote:

Ich habe noch einen Gedanken zur Vergabe von rwn_ref. rwn_ref=o finde ich auch nicht gut. rwn_ref sollte ein kurzer (1-,2-,3- oder bis zu 5-stellig) Ausdruck sein, der auf ein Objekt verweist und an dessen Namen angelehnt ist.
Wenn das Objekt nun zwar einen Namen ("Katzensteiner Hof") aber keinen offiziellen ref hat, dann könnte der Mapper eine Abkürzung wählen, deren Länge eine vorgegebene maximale Länge (2-,3- oder bis zu 5-stellig) nicht überschreitet, aber eindeutig auf den vollständigen Namen verweist. Genau so sind doch bereits die meisten Rad- und Wanderrouten erfasst. Es gibt meistens einen Namen, aber keinen offiziellen ref, so dass der Mapper den ref frei vergibt.

Beispiele: PeerkePad -> PP, Ronde van Nederland -> RvN, Deutsche Fußball Route NRW -> DFR.

Für Katzensteiner Hof würde ich einfach rwn_ref=KH vergeben. Weiteres Beispiel für eine der Netzwerkrouten bei Toulouse:
Ancienne Vigne - La Garrigue

network node "Ancienne Vigne"
network:type=node_network
rwn_name=Ancienne Vigne
rwn_ref=AV

network node "La Garrigue"
network:type=node_network
rwn_name=La Garrigue
rwn_ref=LG

network route
network:type=node_network
ref=AV-LG
name=Ancienne Vigne - La Garrigue

Damit würden wir kein neues Schema einführen. Wir würden stattdessen einfach ein Schema fortführen, das in einem verwandten Bereich (den Routen) bereits so angewandt wird.

Danke! Ich denke das würde sicherlich funktionieren, aber...

• Die Beispiele sind für lange Routen, nicht knotenpunkte, und die Abkürzunge sind nur für Display, im osmc:symbol-Tag. Also keine Refs.
  
• 5 Buchstaben ist zu viel. Wenn das einmal passiert, okee, aber mit ein ganzes Netzwerk, wie die Renderer das jetzt machen, ich denke das Bild ist nich akzeptabel.
  
• Genau dieses schlug ich den französischen Mappern vor. Die haben gesagt, das kann vielleicht für ein kleines Testnetzwerk, aber nicht wenn es grösser wird, man kann einfach die Abkürzungen nicht mehr verstehen; Die vollständigen Namen sollten auf der Karte und in der Output des Planners angezeigt werden.
  

Aber wenn ihr es so machen wollt, fine with me!

(Auf Englisch, entschuldige!)
I have adapted the named node proposal, after consideration of all comments. https://wiki.openstreetmap.org/wiki/Pro … e_networks

The old text is now on the Talk page under History, and I have explained the choices under Explanation of choices for proposal
https://wiki.openstreetmap.org/wiki/Tal … r_proposal

The proposal is down to two changes to the current node network tagging scheme:

1. tag rwn_name=<node name> instead of rwn_ref=<node ref> for the network nodes (i.e. the intersections linking the network node2node routes)
2. ref=* on the node2node routes is not required when node numbers are absent.

That's it!

Peter Elderson wrote:

Danke! Gibt es Apps die das so machen oder machen können? Vielleicht für Radknotenpunktrouten?

Ich kenn nur Overpass Turbo, wobei ich dort selten das rausbekomme, was ich rausbekommen möchte.

Meine Anwendungsfälle sind abstrakt, aber nicht weltfremd. Eine Routenplanungs- & Navigationsapp, die mir die für mich relevanten Wegweiser anzeigt, fände ich schon toll!

edit: typo

Peter Elderson wrote:

I have adapted the named node proposal, after consideration of all comments. wiki.openstreetmap.org/wiki/Pro … e_networks
...

The proposal is down to two changes to the current node network tagging scheme:

1. tag rwn_name=<node name> instead of rwn_ref=<node ref> for the network nodes (i.e. the intersections linking the network node2node routes)
2. ref=* on the node2node routes is not required when node numbers are absent.

Erlich gesagt, wäre ich dagegen, Tags für ein Knotenpunktnetzwerk mit Knotennamen einzuführen, solange es solche Netze nicht gibt. Hat jemand ein Beispiel für ein solches Netzwerk?

Der Wegweiser auf dem Bild hat einen Namen, aber es fehlt die Knotenpunktwegweisung. Pro Richtung kann das nur ein Ziel sein, nämlich der nächste Knotenpunkt. Im Beispiel gibt es drei oder vier Ziele, was darauf hinwiest, dass es eine ganz normale Wegweisung ist. Bei Fahrrad-Knotenpunktnetzwerken in Deutschland wird das üblicherweise mittels Steckschilder an den ganz normalen Wegweisern ausgeschildert.

Es ist ja gerade die Grundidee von Knotenpunktnetzwerken, dass man kurze Zahlen statt Knotenpunktnamen verwendet und diese überall ausweist, weil sich Zahlen leichter merken lassen. Womöglich kann man auch kurze Buchstabenkombinationen nehmen, aber das habe ich noch nirgendwo gesehen.

https://knooppuntnet.nl/nl/map/hiking#4 … m3f-5ibzjn (work in progress)
Shows the network layout and how the names serve as labels.

The guidepost shows the name, the operator, the general symbol for the network and the directions to adjacent nodes (the upper names). The adjacent nodes point back to this one in the same way. Intermediate crossings for all the connections between the named points are only marked with the Gelbe Raute.
Therefore it is a node network layout and a node network system for planning a route and navigating along it.

It's not the form of the label that defines the function of the network. It's next node based, not end goal based.

Peter Elderson wrote:

The guidepost shows the name, the operator, the general symbol for the network and the directions to adjacent nodes (the upper names). The adjacent nodes point back to this one in the same way. Intermediate crossings for all the connections between the named points are only marked with the Gelbe Raute.
Therefore it is a node network layout and a node network system for planning a route and navigating along it.

I'm not sure if this is really a network layout.
The first entry is not necessarily a network node, it might be a dominating point just on the way to the next real node where at least three marked ways meet.
From my experience with the (newer) guideposts of the SAV (Schwäbischer Albverein) which have a similar organization, the next guideposts in the opposite direction do not always point back identically. The intermediate posts are frequently route_markers but also often two-way guideposts with identical layout with name etc. but only showing two directions.

To my opinion the guidepost systems of the SAV and Schwarzwaldverein have many elements of a node network system but also substantial deviations.
This might be the case for many other hiking guidepost systems since they have a much longer history than those for bicycles and hikers usually have more time to read guideposts 😄.

https://hiking.waymarkedtrails.org/#?ma … 371!8.1211 shows it's a node network. A have received reports and photos of guideposts referencing each other. A test in the area has shown it can be used in a node network route planner to plan routes through the network. The planned result is a list of named nodes; the hiker chooses the next node, indicated on de guidepost. The guideposts are visible on the map. In between are yellow diamonds to show the way. I have no doubt this fits the node network concept.

But - it's not my area and it's not my decision. The development started in Germany, but if the development lacks general support here we will continue to develop the registration and handling of named nodes within the node network tools and planner, together with the French mappers around Toulouse. These node networks also live in Switzerland and Austria, so it's worth it!

We will get there. The world-wide OSM node network planner will support named and numbered node network planning for hiking, cycling, horse riding, inline skating, motorboat and canoe.

Let's talk again when the development work is done.

Ich möchte euch darauf hinweisen, dass ich einen Übersetzungsfehler im Wiki zu 'expected_rcn_route_relations=*' gefunden und korrigiert habe.

Es hat Auswirkungen auf Knoten und Verbindungen in Knotenpunktnetzwerken, wo es Verbindungen zu benachbarten Netzwerken oder Abstecher zu POIs gibt. Wenn ihr sowas getaggt habt, bitte schaut mal nach, ob das noch alles richtig ist.

Hier der Link zum zugehörigen Post: Übersetzungsfehler im Wiki zu Knotenpunktnetzwerken

Ich habe Quellen rausgesucht, die den deutschen Fachbegriff "Knotenpunktnetzwerk" bzw. "Knotenpunktwegweisung" beschreiben: Es ist ein Synonym für "Radeln nach Zahlen".

Eine andere deutsche Definition konnte ich nicht finden, womöglich ist das in anderen Ländern anders.

Die Quellen zeigen, dass das Wanderwegnetz im Schwarzwald exakt das Gegenteil von dem ist, was der deutsche Fachbegriff beschreibt.

Somit beschreibt auch ein 'network:type=node_network' genau das Gegenteil von dem Wanderwegnetz im Schwarzwald. Es trotzdem zu verwenden, weil der Render es ohne Anpassungen darstellen kann, ist damit reines Taggen für den Renderer.

Ich möchte daher dringend appelieren, für solche Netzwerke einen eigenen Wert zu definieren, z. B. 'node_name_network' oder Ähnliches. Das hilft auch den Renderern, sich an die Besonderheiten eines Knotennamen-Netzwerkes anzupassen.

In einer anderen aktuellen Diskusion habe ich 'network:type=basic_network' für Wander- und Radverkehrsnetze vorgeschlagen, unabhängig davon, ob die Knoten Namen haben.

Zusammenfassung der Quellen: Grundidee der Knotenpunktwegweisung ist, dass Menschen sich Zahlen leichter merken können als Ortsnamen. Merkmale einer Knotenpunktwegweisung sind nach der dortigen Definition:

• Knoten mit Nummern statt Ortsnamen
• Ausschilderung (nur) der nächsten Knotennummer
• Karte des Netzes mit den Knotennummern an jedem Knotenpunkt
• Ausweisung der Nummern-Wegweisung zusätzlich zur Ziel-Wegweisung des Grundnetzes

In Deutschland wurde die Knotenpunktwegweisung meines Wissens nur für Radverkehrsnetze angewendet. Die Zahlensymbole werden als Einschub unten an die Ziel-Wegweiser angebracht.

In dem Netzwerk im Schwarzwald sind alle (!) Punkte dieser Definition nicht erfüllt:

• statt Nummern werden Orts-/Knotennamen verwendet
• es werden mehrere folgende Knoten ausgewiesen, nicht nur der nächste
• es gibt in meist keine Karten an den Knotenpunkten, wo die umliegenden Knoten dargestellt werden
• die Ziel-Wegweisung und die Knoten-Wegweisung sind vermischt

Damit ist dieses Netz genau das Gegenteil von dem, was 'network:type=node_network' nach deutschem Fachbegriff beschreibt. Sowas sollten wir vermeiden!

Quellen z. B.

• Beschilderungsstandards im Radverkehr in Baden-Württemberg pdf, Seite 37
• Hinweise zur wegweisenden Beschilderung für den Radverkehr in Nordrhein-Westfalen, pdf Seite 33
• Handbuch zur Radwegweisung in Hessen, pdf Seite 22

Ich verstehe nicht so recht worauf du hinaus willst? Ein neues Tagging-Schema?

JochenB wrote:

Grundidee der Knotenpunktwegweisung ist, dass Menschen sich Zahlen leichter merken können als Ortsnamen.

Hmm, woher hast du das? Bei einer Route ist der Nutzer (unflexibel) auf die Route festgelegt. Bei einem Knotenpuntnetzwerk nur auf die Strecke bis zum nächsten Knoten. Das heißt, ein Knotenpunktnetzwerk ist wesentlich flexibler.

toc-rox wrote:

Ich verstehe nicht so recht worauf du hinaus willst?

Ich beziehe mich auf die Posts ab Nr. 162. Dort wird berichtet, dass das Taggingschema für Knotenpunktnetze auf Netze ausgeweitet wird, wo Wegweiser Namen statt Nummern haben. Das wird als vereinbar mit der Definition von "Knotenpunktnetzwerk" gesehen. Ich hatte dem widersprochen, hatte aber keine Quellen. Das hole ich nun nach.

Es wird auch an einem Proposal Proposed features/Named nodes in node networks dazu gearbeitet. Mein Englisch ist nur zu schlecht, um da mitzudiskutieren.

toc-rox wrote:

Ein neues Tagging-Schema?

Nein, nur ein anderen Wert als 'node_network' für 'network:type' Ursprünglich war mal 'destination_network' im Gespräch. Das würde ich dann aber auch für Ziel-Wegweisung ohne Knotenpunktnamen verwenden, siehe Diskussion "Proposal: Wander-/Radwege ggü. anderen Wegen mit Wegweisern hervorheben?"

toc-rox wrote:

JochenB wrote:

Grundidee der Knotenpunktwegweisung ist, dass Menschen sich Zahlen leichter merken können als Ortsnamen.

Hmm, woher hast du das?

Das ist aus allen Quellen die ich betreffs Definition des Knotenpunktnetzwerks habe, drei davon habe ich ja auch verlinkt.

toc-rox wrote:

Bei einer Route ist der Nutzer (unflexibel) auf die Route festgelegt. Bei einem Knotenpuntnetzwerk nur auf die Strecke bis zum nächsten Knoten. Das heißt, ein Knotenpunktnetzwerk ist wesentlich flexibler.

Ob man die Knoten mit Namen oder Nummern versieht, die Flexibilität ist exakt die gleiche. Nur kann man sich Nummern einfacher merken.

Daher hat man das Knotenpunktsystem erfunden, wo Knoten Nummern haben und immer nur die nächste Knotennummer ausgeschildert wird. Um eine Planung zu machen, über welche Knotennummern man fahren möchte, braucht es an jedem Knotenpunkt eine Karte. All das ist im Schwarzwald nicht vorhanden, weswegen ich für ein anderes 'network:type' plädiere als 'node_network, um das sauber zu trennen.

Nicht missverstehen, ich finde das Schwarzwälder Schildersystem gut, bin letztes Jahr selber dort gewandert und habe mich darüber gefreut!

Robhubi wrote:

JochenB wrote:

Karthoo wrote:

Für die Wanderwege des Schwarzwaldvereins habe ich (in Absprache mit Anderen) das bereits etablierte Tag network:type=node_network verwendet. Dazu hat ein niederländischer Kollege auch ein Proposal angelegt, das auch Knoten mit Namen statt nur ref-Nummern in node_networks möglich machen soll.

Das ist meines Erachtens eine sehr unglückliche Entwicklung, denn hier wird ein vorhandener Wert für etwas verwendet, dass das Gegenteil von dem beschreibt, wofür der Wert stand. Warum nicht einen neuen Wert einführen?

Ich kann diese strenge Sicht nicht teilen. Das wesentliche:
• Die Knoten sind benannt
• Die Wegweisung zeigt zu den Nachbarknoten
ist doch erfüllt. Ob die Benennung mit Namen oder Nummern erfolgt halte ich für unwesentlich.

Die Diskussion ist in einer anderen Diskussion entstanden, ich antworte aber lieber in diesem Thread, weil hier besser passt.

Robhubi wrote:

• Die Knoten sind benannt ... Ob die Benennung mit Namen oder Nummern erfolgt halte ich für unwesentlich.

Mir ist es wichtig, dass wir feststehende Fachbegriffe nicht umdefinieren, nur damit man am Renderer nichts ändern muss. Der Fachbegriff "Knotenpunktnetzwerk" ist unglücklich, weil der Begriff selber nichtssagend ist, schließlich ist jedes Netz ein Netzwerk mit Knoten. Um den Begriff richtig zu verwenden braucht man dessen Definition.

Aus welcher Quelle hast du, dass eine Benennung von Knoten ein wesentliche Merkmal eines Knotenpunktnetzwerkes ist?

Ich habe intensiv danach gesucht, eine solche Definition habe ich nicht gefunden. In allen Quellen ist es sehr deutlich: Es sind die Nummern, die ein Knotenpunktnetzwerk definieren und wodurch es sich von anderen Wegweisungstypen abhebt.

Zitate:

Handbuch zur Radwegweisung in Hessen:
Die Knotenpunktwegweisung ist ein an Nummern geknüpftes System. … Die Kombination von Infotafel und Nummer ermöglicht es Radfahrenden, Touren entsprechend einer Nummernfolge (z.B. über 50 – 45 – 57 – 54 – 47 – 33 und zurück zum Startpunkt 50)

Wandern in Ostbelgien:
"Das Knotenpunktsystem ... besteht aus entweder Fahrrad- oder Wanderrouten, die an den Kreuzungspunkten (Knoten) anhand einer Nummer miteinander verbunden sind".

Hinweise zur wegweisenden Beschilderung für den Radverkehr in Nordrhein-Westfalen:
Jeder Netzknoten ist mit einer individuellen Nummer gekennzeichnet. An diesen Netzknoten werden Übersichtskarten installiert, welche den Standort in Bezug zum Umgebungsnetz abbilden, so dass dem Nutzer auch vor Ort eine individuelle Routenwahl ermöglicht wird.

Wandern in Aachen:
Nummerierte ‚Knotenpunkte‘ erleichtern Ihnen die Orientierung. Die systematische Verbindung dieser Punkte macht es einfach, die eigenen Spaziergänge und Wanderungen zu planen: Sie brauchen sich nur noch die Nummern der ausgewählten Knoten in der richtigen Reihenfolge zu merken!

Standard für Radverkehrswegweisung Baden Württemberg:
"Dabei erhält ein Teil der Netzknoten Nummern, die als Zielbezeichnung dienen. Diese Nummern werden in die Wegweisung einbezogen, so dass es möglich ist von Netzknoten zu Netzknoten zu navigieren. Auf diese Weise lassen sich über eine Nummernfolge einfach individuelle Touren zusammenstellen."

Wandern nach Knotenpunkten im Bargerveen:
Die nummerierten Streckenschilder führen Sie von Knotenpunkt zu Knotenpunkt.

Definition of node network (routeyou.com):
A node network is a specific selection of roads and paths forming a closed network (graph) used for recreational purposes such as cycling, hiking, horseback riding, ... The nodes ( intersections) get a number. This makes it possible to display a track with a set of numbers. In the field, you have signs indicating how to go frmo one node to the connected node (see figure above).

Neben der Nummer werden als Merkmale von Knotennetzwerken genannt: Karten am Knotenpunkt, dass nur der nächste Knotenpunkt ausgeschildert wird und wie die Schilder und Karten auszusehen haben. Das alles würde ich nicht als die wichtigsten Unterscheidungskriterien sehen. Andere Definitionskriterien habe ich nicht gefunden.

Robhubi wrote:

Die Wegweisung zeigt zu den Nachbarknoten

Idee der Knotenpunktnetzwerke ist, es dem Nutzer so einfach und übersichtlich wie möglich zu machen. Dazu gehört, dass an einem Knotenpunkt nur so wenig Nummern wie möglich stehen, also nur die der jeweilig nächsten Knoten. Das ist sicherlich nicht das wichtigste Merkmal, aber eines, was immerhin in den Beschilderungsstandards genannt ist und wo es sich von einer Zielwegweisung oder der im Schwarzwald unterscheidet. Nachteil: Der Nutzer muss sich für jeden zwischen-Knotenpunkt die Nummer merken.

Im Schwarzwald versucht man mehrere Ziele auszuweisen, so dass man sich möglichst wenige Unterwegspunkte merken muss. Das ist genau die umgekehrte Herangehensweise.

JochenB wrote:

Ich möchte euch darauf hinweisen, dass ich einen Übersetzungsfehler im Wiki zu 'expected_rcn_route_relations=*' gefunden und korrigiert habe.

Es hat Auswirkungen auf Knoten und Verbindungen in Knotenpunktnetzwerken, wo es Verbindungen zu benachbarten Netzwerken oder Abstecher zu POIs gibt. Wenn ihr sowas getaggt habt, bitte schaut mal nach, ob das noch alles richtig ist.

Hier der Link zum zugehörigen Post: Übersetzungsfehler im Wiki zu Knotenpunktnetzwerken

Bitte beachten Sie, dass Knooppuntnet das Status-Tag nicht mehr betrachtet, wenn die Anzahl der Verbindungen gezählt wird.

Edit: Also, Nederland no longer uses note for the connection routes. All node2node connections have been retagged to use ref. Reason: note is for mapping-related notes, not for attributes of the object. We now use the note tag as intended.

JochenB wrote:

Es wird auch an einem Proposal Proposed features/Named nodes in node networks dazu gearbeitet. Mein Englisch ist nur zu schlecht, um da mitzudiskutieren.

Ich war so frei und habe mal eine entscheidende Frage gestellt.

JochenB wrote:

toc-rox wrote:

Ein neues Tagging-Schema?

Nein, nur ein anderen Wert als 'node_network' für 'network:type' Ursprünglich war mal 'destination_network' im Gespräch. Das würde ich dann aber auch für Ziel-Wegweisung ohne Knotenpunktnamen verwenden, siehe Diskussion "Proposal: Wander-/Radwege ggü. anderen Wegen mit Wegweisern hervorheben?"

Dann lass uns doch das richtig stellen und für die ohne Knotennamen einen neuen Wert erfinden.

JochenB wrote:

toc-rox wrote:

JochenB wrote:

Grundidee der Knotenpunktwegweisung ist, dass Menschen sich Zahlen leichter merken können als Ortsnamen.

Hmm, woher hast du das?

Das ist aus allen Quellen die ich betreffs Definition des Knotenpunktnetzwerks habe, drei davon habe ich ja auch verlinkt.

Bitte nicht alles glauben. Wo ist denn die wissenschaftliche Publikation?
Wenn das der Fall wäre würde OSM nur so von name=^[0-9]*$ wimmeln. Ich sehe aber überall Namen für Ortschaften, Straßen, Stadtteile, Brunnen, Haltestellen, ....

JochenB wrote:

Daher hat man das Knotenpunktsystem erfunden, wo Knoten Nummern haben und immer nur die nächste Knotennummer ausgeschildert wird. Um eine Planung zu machen, über welche Knotennummern man fahren möchte, braucht es an jedem Knotenpunkt eine Karte. All das ist im Schwarzwald nicht vorhanden, weswegen ich für ein anderes 'network:type' plädiere als 'node_network, um das sauber zu trennen.

Nicht missverstehen, ich finde das Schwarzwälder Schildersystem gut, bin letztes Jahr selber dort gewandert und habe mich darüber gefreut!

+1 es braucht nur einen eigenen Wert für die Relationen und hat zum Teil auch Verbindungen ohne Schildernamen, die ich weiterhin dann als lwn=yes eintrage, so wie ich es auch schon mache, wenn ich keinen Überblick über den Verlauf der Route habe, da ich nur auf einem Teilstück unterwegs war.

skyper wrote:

Bitte nicht alles glauben. Wo ist denn die wissenschaftliche Publikation?

Ich habe mich viele Jahre im Landes-ADFC engagiert u. a. für Fahrradtourismus. Meine Frau arbeitet sein 2006 im touristischen Bereich. Dort ist der Begriff "Knotenpunktnetzwerk" der Fachbegriff für "Radeln/Wandern nach Zahlen". Kreiert wurde er angeblich in Belgien, wo man die Idee mit den Zahlen auf touristische Netzwerke übertrug.

Wenn sämtliche Suchergebnisse nach diesem Begriff im Netz auf Netze mit Zahlen verweisen und keins auf Netze mit Namen, wenn das auch in den offiziellen Handlungsleitfäden und Standards so definiert wird, sollte das ein starker Hinwies sein, dass wir nicht in einer Filterblase leben.

Ich vermute, dass in Niederlanden, Belgien und Frankreich, wo diese Ausschilderungsform populär ist, ebenso solche Quellen geben wird.

Ich will ja kein riesiges Problem daraus machen, aber die Lösung des Widerspruchs ist einfach und tut nicht weh. Was spricht denn dagegen, einen entsprechenden Wert "Knotennamenwegweisung" für 'network:type' einzuführen? Dann Verwenden wir 'node_network' in OSM für das, für das es außerhalb OSM auch steht.

Nach Abschluss der Diskussion ums Taggen von Wegen mit Wegweisung ohne Name und Symbol werden die Rendererprogrammierer vermutlich eh' die Darstellung von Radverkehrs- und Wandernetzen anpassen.

Da bist Du dann näher an der Praxis aber ob alles überdacht und wissenschaftlich begründet ist darf ich wohl weiter anzweifeln. Ich bin da eher bei Hirn und Lernprozessen und der Verarbeitung plus der Veränderungen durch unsere elektronischen Alleskönner, dem Internet und unserem Verständnis des Lernens.

Es mag ja auf den ersten Blick schneller erkennbar sein und passt auch auf weniger Platz, aber Text auswendiglernen macht Sinn und wenn ich heute erzähle wo ich mich zwei Jahren bewegt habe kann ich immer noch die Namen der Ortschaften aufzählen, die Nummern hätte ich längst vergessen und was wollten andere auch mit den Nummern? (Auf OSM die Wegweiser suchen?)

Bei Themen- und Stationsrouten macht eine Nummerierung ja auch Sinn aber allen Wegweisern eine Nummer zuzuordnen keinen. Da ist die Praxis im Schwarzwald mit eindeutigen Namen der Wegweiser an den Kreuzungen mMn die schlauere Lösung.

skyper wrote:

ob alles überdacht und wissenschaftlich begründet ist darf ich wohl weiter anzweifeln

Achso meinst du das, ich dachte du meinst die Definition. Nö, das ist auch ein Marketinggeschichte und Mode. Schlecht ist es nicht aber auch überbewertet.

JochenB wrote:

Achso meinst du das, ich dachte du meinst die Definition. Nö, das ist auch ein Marketinggeschichte und Mode. Schlecht ist es nicht aber auch überbewertet.

<offtopic>

Wobei, einen unheimlichen Vorteil hat es: die Kommunen/Kreise/Tourismusverbände zwingen sich damit, in Netzen zu denken und nicht nur in einzelnen rein touristischen Routen. Somit erhalten wir ein komplettes Netz mit Wegweisung, wo (hoffentlich) sichergestellt ist, dass man einigermaßen gut Rad fahren kann.

Das macht sicher auch den Baulasträgern bewusst, dass man hier mit Fahrradfahrern rechnen muss, z. B. bei der Frage, welche Straße als nächstes eine neue Asphaltdecke erhält.

Jeder Wegweiser ist auch Werbung fürs Radfahren, jeder Weg mit dem Fahrrad ist ein Gewinn für Gesundheit und Umwelt, egal ob Alltagsverkehr oder touristisch.

</offtopic>

Wenn ich mir das mit den Nummern noch einmal überlege ist es mir zu kleinteilig gedacht. Stelle mir gerade ein längere Route durch mehrere Landkreise vor und da können mehrfach die gleichen Nummern vorkommen. Bei vier oder noch mehr Stellen sind die Zahlen den Buchstaben schon unterlegen. Gibt es eigentlich auch Systeme mit Buchstaben (A, B, C ...) anstatt Zahlen? letter_node_network ?

Buchstaben und Zahlen kombiniert, sicher. Z.B. wie hier: https://knooppuntnet.nl/de/map/hiking#sxb5p0-g48ah
kombiniert mit Farbrouten.

Einzelne Buchstaben hab ich noch nicht in OSM gesehen, aber auf dem Weg in einem kleinen Naturschutzgebiet, schon.

Für den Planner spielt es keine Rolle, welche Art von Beschriftungen an den Knotenpunkte angebracht sind. Es könnten auch Bilder oder Statuetten sein. Alle diese routen und Knotenpunkte können mit einander verbunden werden in ein einzige Planung.

Mehrfach die gleichen Nummern oder Codes oder Namen, das ist auch kein problem, es sei denn, von einem bestimmten Knoten aus geben zwei Richtungen dieselbe Nummer an. Die Planung verläuft dann reibungslos, der Reisende kann aber am Auswahlpunkt keine Wahl treffen. Also es mussen am mindesten zwei weitere Knoten dazwischen liegen. Aber wenn es auf der Straße falsch ist, werden wir es so mappen, wie wir es finden.

skyper wrote:

Stelle mir gerade ein längere Route durch mehrere Landkreise vor und da können mehrfach die gleichen Nummern vorkommen.

Irgenwo hatte ich gelesen, dass gleiche Nummern mindestens 40km auseinanderliegen sollen, also mind. 2h reine Fahrtzeit. Da, sollte es nicht so schlimm sein, wenn die Nummer zweimal vorkommt. Um es eindeutig zu halten reicht es, wenn zwischen zwei gleichen Nummern mindestens zwei andere Nummern liegen, sonst hat man einen Wegweiser, der die gleiche Nummer in zwei Richtungen ausweist 🙂 .

Mir ist es noch nicht untergekommen, dass in Nachbarschaft zwei gleiche Nummern liegen. Wäre mal eine anspruchsvolle overpass-turbo-Abfrage, wenn das überhaupt geht.

https://knooppuntnet.nl/nl/map/cycling#1rzj320-15i82az

Peter Elderson wrote:

https://knooppuntnet.nl/nl/map/cycling#1rzj320-15i82az

Stimmt, aber die vielen 18-Nummern sollen zusammen ein Knotenpunkt sein.

Gemeint war eher so etwas: Nr 99 - Nr 99 mit nur 13 km Abstand https://knooppuntnet.nl/nl/map/cycling#qb0qy-q9fut

JochenB wrote:

Irgenwo hatte ich gelesen, dass gleiche Nummern mindestens 40km auseinanderliegen sollen, also mind. 2h reine Fahrtzeit. Da, sollte es nicht so schlimm sein, wenn die Nummer zweimal vorkommt. Um es eindeutig zu halten reicht es, wenn zwischen zwei gleichen Nummern mindestens zwei andere Nummern liegen, sonst hat man einen Wegweiser, der die gleiche Nummer in zwei Richtungen ausweist smile .

Mir ist es noch nicht untergekommen, dass in Nachbarschaft zwei gleiche Nummern liegen. Wäre mal eine anspruchsvolle overpass-turbo-Abfrage, wenn das überhaupt geht.

Auch wenn es die Stadt, in der ich lebe, vielleicht nicht wirklich gibt. In Bielefeld haben sie es geschafft, das doch recht kleine Gelände mit einem engen Knotenpunktnetzwerk zu überziehen, da wimmelt es von Doubletten (alles Luftlinie): 6-6 mit 5,1 km Abstand, 2-2 mit 6,0 km, 77-77 mit 5,5 km, 78-78 mit 7,0 km, 80-80 mit 6,7 km, 27-27 mit 8,9 km usw.
Fast, als ob jeder Stadtbezirk sein eigenes Netzwerk hätte, oder die früher unabhängigen Städte und Gemeinden Heepen, Brackwede usw. sich nach fast 50 Jahren immer noch als autonom betrachten... Man könnte ordnungsgemäß die Route 77-78-80-81-77 fahren und ist dann nicht wieder am Ausgangspunkt. (Allerdings endet in diesem Beispiel ein Abschnitt im Moment blind an einer Autobahn, die Brücke ist gerade eine Baustelle 🙁 ).

Es unterstreicht meiner Meinung nach noch einmal, dass man beim Mappen auf keinen Fall zu viele Grundannahmen über Netzwerke im Allgemeinen machen kann, sondern tatsächlich schauen muß, wie die Gegebenheiten vor Ort sind, und wie man sie beschreiben kann.

Duvodas wrote:

Hallo,
...
Viele aktuelle Themenradrouten sind zum großen Teil auf das Knotenpunktnetzwerk gelegt und somit eine Aneinanderreihung von Knotenpunktrouten. Wäre es sinnvoll, die Themenrouten aus den Knotenpunktrouten-Relationen zusammenzusetzen, statt aus den einzelnen Linien der Wege? Dann wären die einzelnen Linien der Wege nur noch Bestandteil einer Relation (der Knotenpunktroute) statt zweien oder mehr. Das könnte den Wartungsaufwand verringern.

Testweise habe ich das mal bei der von mir neu angelegten RegioGrün Erlebnisroute Süd so gemacht. Zumindest auf waymarkedtrails wird das so aber nicht richtig gerendert.

Gibt es bereits Überlegungen zu dem Thema? Ich konnte bisher leider nichts dazu finden, auch kein anderes Beispiel. Müssen die Kind-Relationen eine bestimmte role erhalten?

Davon wurde zwar bereits abgeraten - das kann ich aber bezogen auf die hiesigen Routen nur unterstreichen. Weitgehend liegen die Themenrouten entlang Knotenpunkten, aber eben nur weitgehend. Und die ganze Geschichte ist dynamisch. Es ist nicht gesagt, dass eine Route geändert wird, und dann mittendrin plötzlich doch die Knotenpunktroute wieder verläßt. Das wäre dann äußerst mühsam, die Knotenroutenetappen wieder aufzulösen.

Auch das über knooppuntnet vorgeschlagene Verfahren kommt hier in Bielefeld an seine Grenzen, da die Ausschilderung aus welchen Gründen auch immer Merkwürdigkeiten bereithält:

So gibt es z.B. einen Knoten 55, der den Nachbarknoten 51 in zwei Richtungen ausweist, rückwärts gibt es aber nur eine Routenführung... (habe ich versucht abzubilden in den Routen 51-55 und 55-51).

JochenB wrote:

sonst hat man einen Wegweiser, der die gleiche Nummer in zwei Richtungen ausweist smile .

Ja, ja, sowas gibt's.

Die Knotenpunktnetzwerke befinden sich inzwischen in einer übergeordneten Relation Fahrradknotenpunktnetzwerk NRW, die wiederum in die Relation Radverkehrsnetz NRW aufgenommen ist.

Da es gar kein Fahrradknotenpunktnetzwerk NRW gibt, würde ich hier vorschlagen, den Namen zu ändern in die Mehrzahl Fahrradknotenpunktnetzwerke. Es kann zwar sein, dass in der Zukunft die vereinzelten Netze zu einem großen Netz zusammenwachsen, das beschreibt aber nicht den aktuellen Zustand, und in den offiziellen Bezeichnungen taucht das auch nicht auf. Mir kommt es noch etwas besser vor, die Knotenpunktnetzwerke der Kreise jeweils in die Unter-Relationen des Radverkehrsnetzes aufzunehmen statt noch eine Superrelation neben den jeweiligen Kreisnetzwerken auf der höchsten Ebene zu haben.

Das hätte den Vorteil, dass man für jeden Kreis eine vollständigere Fahrradinfrastruktur in einer Relation verfügbar hätte. Lediglich die Themenrouten bleiben noch unklar, die könnte man eventuell auch noch in den Kreisen unterbringen.

Grüße, Sebastian

JochenB wrote:

Peter Elderson wrote:

https://knooppuntnet.nl/nl/map/cycling#1rzj320-15i82az

Gemeint war eher so etwas: Nr 99 - Nr 99 mit nur 13 km Abstand https://knooppuntnet.nl/nl/map/cycling#qb0qy-q9fut

Ist das ein Problem? Es gibt keine Knotenpunkte, die in zwei verschiedene Richtungen auf 99 zeigen.

segubi wrote:

Bielefeld

Das ist eine laufende Arbeit, denke ich? https://knooppuntnet.nl/de/analysis/net … 7857/facts

Peter Elderson wrote:

JochenB wrote:

Peter Elderson wrote:

https://knooppuntnet.nl/nl/map/cycling#1rzj320-15i82az

Gemeint war eher so etwas: Nr 99 - Nr 99 mit nur 13 km Abstand https://knooppuntnet.nl/nl/map/cycling#qb0qy-q9fut

Ist das ein Problem? Es gibt keine Knotenpunkte, die in zwei verschiedene Richtungen auf 99 zeigen.

Nein, es ist kein größeres Problem. Allerdings sollte der Netzbetreiber die Nummern so vergeben, dass gleiche Nummern möglichst weit auseinanderliegen.

Wenn du z. B. Punkt 99 als Ziel hast und siehst wenige Kilometer vorher einen Wegweiser zum 99, dann denkst du vielleicht dass das eine Abkürzung ist oder du vorab nicht richtig geplant hast. Wenn du dich dann spontan entscheidest, die Route zu ändern, dann hast du dich verfahren.

JochenB wrote:

Allerdings sollte der Netzbetreiber die Nummern so vergeben, dass gleiche Nummern möglichst weit auseinanderliegen.

Na ja, sie tun was sie tun, ohne uns zu befragen!

JochenB wrote:

skyper wrote:

Stelle mir gerade ein längere Route durch mehrere Landkreise vor und da können mehrfach die gleichen Nummern vorkommen.

Irgenwo hatte ich gelesen, dass gleiche Nummern mindestens 40km auseinanderliegen sollen, also mind. 2h reine Fahrtzeit

Wohl eher 1-3h reine Fahrzeit, je nach Geländeform, Untersatz und Windverhältnissen.

Peter Elderson wrote:

segubi wrote:

Bielefeld

Das ist eine laufende Arbeit, denke ich? https://knooppuntnet.nl/de/analysis/net … 7857/facts

... kann man wohl sagen... Der Anteil der korrekten Abschnitte war auch schon einmal größer, als ich erst die Hälfte der Routen eingegeben habe. Da ich aber die Strecken abfahre, auch um zu schauen, ob sie wirklich befahrbar beschildert sind (es ist auch vor Ort noch ziemlich neu und hat viele Fehler), dauert es. Und soweit ich das überblicke, habe ich im Moment nicht viele Mitstreiter. Einige Probleme bestehen aber tatsächlich: es gibt viele Baustellen, Strecken sind hierdurch nicht befahrbar, und manche Tentakel sind wirklich unlogisch oder zumindest kompliziert ausgeschildert mit mehreren Split nodes und überkreuzten Tentakeln, da kommt knooppuntnet nicht immer ganz hinterher, auch wenn es auf der Straße wirklich so ist, wie ich es gemappt habe.

Es wartet aber tatsächlich noch viel Korrekturarbeit. Ich stelle im Moment weiter die Routen zusammen, an die Anpassung an die Anforderungen von knooppuntnet mache ich mich erst in einem weiteren Arbeitsgang, das ist viel Arbeit...

Besonders mühsam ist es, die Durchgängigkeit für das Fahrrad zu überprüfen, also ob die Tags bicycle yes/no oder use sideway usw. vernünftig gesetzt sind. Wenn nicht, wird es nämlich schnell sehr aufwändifg, wenn man die Fahrradwege links und rechts der Fahrbahn jeweils mappen muß und dann noch mit den entsprechenden Rollen versehen - und dann sind diese Wege halt primär oft nicht komplett gemappt, so dass es nicht reicht, die Relationen zusammenzustellen. Und manche Sachen sind nicht ohne eine neue Besichtigung vor Ort nicht zu klären.

Sie haben es tatsächlich fertig gebracht, kurze Abschnitte in das Fahrradknotenpunktnetzwerk einzubauen, in denen man gar nicht Fahrradfahren darf (eine enge Brücke z.B.). Ich habe mich jetzt entschieden, hier noch bicycle=dismount einzufügen, um zu signalisieren, dass es trotzdem eine Fahrradroute sein soll...

segubi wrote:

... das ist viel Arbeit

Danke dafür!!!

Und ich habe noch eine Ergänzung. Ich weiß nicht, ob irgend ein Renderer das verwendet, aber ich werde mal die Routen, soweit ich die Beschilderung zur Verfügung habe, mit den Tags "incline=up" und "incline=down" ergänzen. Das ist leider nirgendwo explizit empfohlen, und auch vielleicht nicht verallgemeinerbar.
Aber in NRW haben sämtliche Streckenabschnitte den Charakter von Knotenabschnitten. Schilder stehen nur an bestimmten Punkte, dazwischen gibt es nur kleine Pfeile ohne jede Zusatzinformation. Die Routen werden also durch die Beschilderung zwischen je zwei Wegweisern definiert. Unter den vorgegebenen Routentypen ist für NRW vorgesehen, dass Steigungen und Gefälle > 4% pauschal angegeben werden. Das bezieht sich dann immer auf den kompletten Abschnitt zwischen zwei Punkten (vielleicht gibt es auch Stellen mit beiden Symbolen? muß ich mal drauf achten). Einige der Routen sind auch als "Freizeitroute" mit einem Baum-Symbol charakterisiert. Das bedeutet hier in Bielefeld effektiv, dass der Weg durch Wald geht, ungepflastert ist, ggf. nicht für Rennräder geeignet sein dürfte, oder vielleicht auch nur größere Umwege in Kauf nimmt. Da weiß ich noch nicht genau, wie ich das tagge.
Wenn jemand bessere Vorschläge hat, wie man diese Information von den Wegweisern den Routen zuordnen kann, gerne...
Und hier fällt mir gerade auf: Das könnte tatsächlich ein Grund sein, die NRW-Einzelwege von Wegweiser zu Wegweiser als je eine Relation zu mappen, und die Knotenpunktrelationen zusätzlich zu mappen, auch wenn dann die Wegabschnitte doppelt vertreten sind. Eine Knotenpunktroute geht nämlich oft über mehrere Wegweiser mit Abzweigen, die Steigungen sind dann natürlich nur auf den unmittelbar auf den Wegweiser folgenden Unter-Abschnitt bezogen.

Im Moment hatte ich leider gerade begonnen, alle doppelt gemappten Abschnitte aus der Relation "Radverkehrsnetz NRW Stadt Bielefeld" zu beseitigen. Es wird wohl noch ein bißchen dauern, bis das alles einigermaßen konsistent ist. (Nebst so Kleinkram, dass Richtungen von Radwegen verkehrt herum sind, so dass beim Tag oneway=yes plötzlich für den Router Linksverkehr angesagt ist und eine Strecke nicht mehr durchgängig ist - das ist eine der Hauptfehlerquellen dafür, dass knooppuntnet so viele issues hat...)

segubi wrote:

Und ich habe noch eine Ergänzung. Ich weiß nicht, ob irgend ein Renderer das verwendet, aber ich werde mal die Routen, soweit ich die Beschilderung zur Verfügung habe, mit den Tags "incline=up" und "incline=down" ergänzen. Das ist leider nirgendwo explizit empfohlen, und auch vielleicht nicht verallgemeinerbar.

Good idea! I think it is much requested information about a route, so if it's visible on the ground it's worth tagging.
The relations are ordered, so you can use incline with yes, no, or even positive ande negative values, with respect to the order of the ways within the route. This would then (I think) represent the average incline of the route. The individual ways within can of course have very different inclines of their own.

If more detailed incline/decline patterns witthin a route are given on the signs, e.g. [#Km] incline + [#Km] decline, max incline / max decline, I think a special value syntax would be required. But I guess that could be a later addition.

If this community decides to do it this way, I would be glad to pass it on and document it as "in use".

Why wouldn't it be verallgemeinbar?

segubi wrote:

Und ich habe noch eine Ergänzung. Ich weiß nicht, ob irgend ein Renderer das verwendet, aber ich werde mal die Routen, soweit ich die Beschilderung zur Verfügung habe, mit den Tags "incline=up" und "incline=down" ergänzen. Das ist leider nirgendwo explizit empfohlen, und auch vielleicht nicht verallgemeinerbar.

Ich sehe incline eher am way als an der Route. Bei so manchem Abschnitt zwischen 2 (Ziel-)Wegweisern im Bergland müsstest Du sonst auswürfeln, ob Du die lange mäßige Steigung von der einen Seite oder die kurze knackige von der anderen Seite aus unterschlägst.

segubi wrote:

in NRW haben sämtliche Streckenabschnitte den Charakter von Knotenabschnitten. Schilder stehen nur an bestimmten Punkte, dazwischen gibt es nur kleine Pfeile ohne jede Zusatzinformation.

Das ist überall in Deutschland so, wo die Verbindungen mit Wegweisung ein Netz bilden. Um das von Themenrouten zu unterscheiden, habe ich ja die andere Diskussion gestartet.

segubi wrote:

Die Routen werden also durch die Beschilderung zwischen je zwei Wegweisern definiert.

Ich habe in meinem Vorschlag als Endpukte für die Routen folgendes geschrieben: "Knoten, an denen sich diese Wege kreuzen, verzweigen oder enden". Wobei man - im Gegensatz zum Knotenpunktnetzerk - die Relation auch auch über mehrere solcher Knoten hinweg führen kann, Hauptsache sie bildet eine durchgängige Wegekette und verzweigt sich nicht. Das verringert die Zahl der zu pflegenden Relationen. zudem kann man so z. B. Minirelationen von einer Kante vermeiden.

Die Kreuzungs-, Abzweig und Endpunkte sind üblicherweise auch die Punkte, an denen Vollwegweiser stehen (Tabellen oder Pfeilwegweiser). Dazwischen gibt es meist nur Zwischenwegweiser mit kleinen Pfeilen und ohne Ortsangaben.

Allerdings wird an Kreuzungen mit größeren Straßen oft ebenso ein Vollwegweiser gesetzt, ohne dass andere Wege des Fahrradnetzes kreuzen oder abzweigen. Hier die Relation enden zu lassen und eine neue zu starten bringt m. E. eine Schwemme an Relationen mit sich, die sich schwerer überschauen lassen.

segubi wrote:

Und hier fällt mir gerade auf: Das könnte tatsächlich ein Grund sein, die NRW-Einzelwege von Wegweiser zu Wegweiser als je eine Relation zu mappen, und die Knotenpunktrelationen zusätzlich zu mappen, auch wenn dann die Wegabschnitte doppelt vertreten sind. Eine Knotenpunktroute geht nämlich oft über mehrere Wegweiser mit Abzweigen, die Steigungen sind dann natürlich nur auf den unmittelbar auf den Wegweiser folgenden Unter-Abschnitt bezogen.

Das wirkt auf mich eher komliziert und ich vermute, für andere wird es schwer nachvollziehbar, warum du die Verbindung auf mehrer Relationen aufteilst udn poppelt erfasst. Da ist die Gefahr groß, dass das jemand das zusammenfasst und Dupletten löscht.

Die Neigungssymbole am Wegweiser sind draußen hilfreich, weil man dafür nicht auf die Karte schauen und diese interpretieren muss.

Die Neigungsangaben in OSM an die Relation zu schreiben halte ich für nicht notwendig und ungenau. Wenn, dann sollte das direkt an die Kanten, die in der Neignung liegen.

Aber selbst das ist nicht notwendig, denn gute Navis / Kartendarstellungen bekommen das anhand der Höhenlinien selber und genauer raus.

keep it simple 🙂

Peter Elderson wrote:

segubi wrote:

Und ich habe noch eine Ergänzung. Ich weiß nicht, ob irgend ein Renderer das verwendet, aber ich werde mal die Routen, soweit ich die Beschilderung zur Verfügung habe, mit den Tags "incline=up" und "incline=down" ergänzen. Das ist leider nirgendwo explizit empfohlen, und auch vielleicht nicht verallgemeinerbar.

Good idea! I think it is much requested information about a route, so if it's visible on the ground it's worth tagging.
The relations are ordered, so you can use incline with yes, no, or even positive ande negative values, with respect to the order of the ways within the route. This would then (I think) represent the average incline of the route. The individual ways within can of course have very different inclines of their own.

If more detailed incline/decline patterns witthin a route are given on the signs, e.g. [#Km] incline + [#Km] decline, max incline / max decline, I think a special value syntax would be required. But I guess that could be a later addition.

If this community decides to do it this way, I would be glad to pass it on and document it as "in use".

Why wouldn't it be verallgemeinbar?

Thank you for your encouragement. The precipitating idea was just trying to map the visible situation and its logic seen in the guideposts.

In fact: secure would be only to describe the guideposts. The transfer of the information of the guideposts to the routes implies an interpretation and depends on the correct place and content of the guideposts - which is not completely given, as we are confronted with reality. It is possible to place any posts with any information at any place without relation to anything real (they did so last year 😉)

So I really think, we really should wait before such a method would be stated as "in use". If the state keeps this system: dividing the net into single routes between nodes that have clear properties - "Freizeitroute" "Schnellweg" "Incline" ... then it would be appropriate to apply it to the network. But I'm not quite sure whether they'll really stick to this structure.
An advantage of my tagging scheme is that it can be changed very quickly. I think it could be a good idea to later involve also marc (vmarc) from knooppuntnet.nl. An application of the tags could obviously be to create schematic maps with symbols between the nodes. But this would imply that the routes between the nodes can be subdivided. The "incline" information applies to a route between two nodes of the "Radverkehrsnetz NRW" and not two nodes of a "Knotenpunktnetzwerk" which are less dense.

With "nicht verallgemeinerbar" I want to say that these tags only fit to a whole route if the operator uses the same sign on both ends of the route. In Bielefeld it seems to be the case. The operator (Straßen.NRW, that's Land Nordrhein-Westfalen) claims to show stronger inclines on the guideposts. But they don't suggest exact values, only >4% and >10%. So the tagging scheme had to include expressions with inequations as well as maximum values. And I'm not sure, whether it could happen that on a guidepost also could occur an incline AND a decline. This could be the reason for the operator to put nodes on the passes, even if there is no branch there. (eg. node 76 - btw. the route tagged bicycle uphill there is a bit nonsense. There are no signs for bicycles there and it leads over stairs. I didn't delete it for the Stadt Bielefeld shows it in their description of one bicycle route and it looked like they made the entry by themselves. Just added notes and a fixme.)

bus-mt wrote:

Ich sehe incline eher am way als an der Route. Bei so manchem Abschnitt zwischen 2 (Ziel-)Wegweisern im Bergland müsstest Du sonst auswürfeln, ob Du die lange mäßige Steigung von der einen Seite oder die kurze knackige von der anderen Seite aus unterschlägst.

Das schöne ist: Ich muß es nicht auswürfeln, es ist bereits ausgewürfelt und auf die Wegweiser gedruckt. Das wäre in diesem Fall nicht das Problem. Damit kann man sogar abbilden, dass die Wegweiser auf einen Anstieg verweisen (über die Route), und dass in Wirklichkeit auch Gefälle dabei sind (über die Wege). (Or in other words: The dice have already been used - by the operator. I don't see a real problem. One uses the tags in the route to show the description of the guideposts that is intended by the operator - this is the logic of the route, just a virtual thing that is the logical representation of the content of guideposts. And one can use tags in the ways to describe the characteristics of the street in real life, there we also have the description of the surface and so on).

JochenB wrote:

Ich habe in meinem Vorschlag als Endpukte für die Routen folgendes geschrieben: "Knoten, an denen sich diese Wege kreuzen, verzweigen oder enden". Wobei man - im Gegensatz zum Knotenpunktnetzerk - die Relation auch auch über mehrere solcher Knoten hinweg führen kann, Hauptsache sie bildet eine durchgängige Wegekette und verzweigt sich nicht. Das verringert die Zahl der zu pflegenden Relationen. zudem kann man so z. B. Minirelationen von einer Kante vermeiden.

... ja, sorry, Deinen Vorschlag muß ich wirklich mal durcharbeiten. Hatte den Link versust. Danke für den Hinweis. Das ist übrigens genau die Frage, ob man es nicht doch so wie im Knotenpunktnetzwerk machen sollte. Du hast natürlich recht mit dem keep it simple. Ich werde sicher als nächsten Schritt erst einmal die zahlreichen Inkonsistenzen im Knotenpunktnetzwerk Bielefeld reduzieren, bevor ich neue Baustellen aufmache...

segubi wrote:

With "nicht verallgemeinerbar" I want to say that these tags only fit to a whole route if the operator uses the same sign on both ends of the route.

Agreed. If the signs consistently give attributes of the node2node routes, they can be tagged on the routes. By the way, this is is no different from any other recreational route, but on longer routes I think it is only useful on shorter routes/sections. Nederland had motorboat networks where minimal passage height/width (to be compared with vessel heigth and width) and minimal water depth (compared with vessel depth) and even max allowed boat length (for turns) are given, and we recorded those values on the node2node routes.

Planners could show this on the network map, similar to current display options for quality, unpaved or last surveyed. For incline display, an arrow or a double pointy bracket could show light/heavy incline or decline. Planner output could show this information in the node strip.

It all depends on what the operator puts on the signs, it should be verifiable by survey.

Die Idee, starke Neigungen in die Karten zu bringen, finde ich verlockend. Gute Radkarten haben dort einen Pfeil in Richtung der Steigung oder Ähnliches. Das vermisse ich bei den OSM-Radkarten.

Das an die Relationen zu schreiben birgt die Gefahr, dass dieser Pfeil an die falsche Stelle gezeichnet wird. Häufig wird die Neigung ja nicht den gesamten Abschnitt betreffen und nicht überall gleich stark sein. Das ist dann ärgerlich, wenn ich einen Umweg fahre um diesen Pfeil zu umgehen, um dann doch vor dem Berg zu stehen.

Um das zu vermeiden, müsste die Relationen auch noch zwischen den Wegweisern zerstückelt werden (und man sollte den anderen Mappern im 'note=*' erklären, warum das zerstückelt wird).

Die Pfeile sollten nur an Steigungen dargestellt werden, wo eine Radroute oder Netzverbindung langgeht. Will man alle Steigungen darstellen, ergäbe das unübersichtlich viele Pfeile. Es sollten je nach Länge und Schwere der Steigung auch nur ein oder wenige Pfeilssymbole sein.

Ich denke völlig unkritisch ist es, den Inhalt des Wegweisers am Knoten des Wegweisers zu taggen. Nur muss man dabei die Richtung angeben. Wäre das so korrekt?:

incline:northwest=down

Das ist für eine Kartendarstellung aber kaum brauchbar.

Dafür wäre das Vorhandensein einer route-Relation mit 'route=bicycle' der Auslöser, eine solche Darstellung zu prüfen. Der Renderer müsste dann entweder incline-Angaben an den Kanten auswerten. Wenn es die nicht gibt dann die kreuzenden Höhenlinien.

Wenn eine Mindestdifferenz und Mindestneigung erreicht wird, sollte der Pfeil gezeichnet werden. Bei steileren Neigungen ein Doppelpfeil. Wenn die Neigungen länger gehen sollten nach einem Mindestabstand weitere Pfeile gezeichnet werden, ansonsten sollte der Pfeil mittig zwischen Beginn und Ende der Neigung sein.

Anders kann ich mir es schwer vorstellen.

Die Steigung betrifft nicht nur Radfahrer sondern ist eine Eigenschaft des Weges, sollte also auch nur genau dort gemappt werden. Das hat in einer Route bzw. in einer Relation nix zu suchen. incline muss nur gemappt werden und Router und Renderer müssen das gescheit auswerten.

Mammi71 wrote:

Die Steigung betrifft nicht nur Radfahrer sondern ist eine Eigenschaft des Weges, sollte also auch nur genau dort gemappt werden. Das hat in einer Route bzw. in einer Relation nix zu suchen. incline muss nur gemappt werden und Router und Renderer müssen das gescheit auswerten.

Vielleicht ist es auch mißverständlich. Mir geht es darum, den systematisch angewendeten Inhalt der Wegweisung zu mappen. Das ist auch auf dem Boden ("on the earth") noch einigermaßen in Entwicklung, die Nachbarkreise sind nur teilweise so konsequent darin, aber es ist letztlich das gesamte Netz hier als Knotenpunktnetzwerk aufgebaut, auch wenn die Knoten nicht alle benannt sind. Das heißt, die Wegweisung zeigt nicht nur in diffuser Form in eine Richtung, sondern verbindet streng zwei Punkte miteinander und zusätzliche Eigenschaften zwischen diesen Punkten werden auf beiden Seiten der Wegweisung markiert. Das betrifft auch noch ein Symbol mit einem Bäumchen für "Freizeitroute", was heißt, die ist nicht zum schnellen Fahren geeignet, sondern geht über Waldwege, benötigt wegen ggf. ebenfalls vermehrt anzutreffenden Fußgängern auch ein langsameres Tempo (also das genaue Gegenteil von z.B. einer MTB-Route).

Diese Marker beziehen sich, sofern keine Fehler in der Beschilderung gemacht werden, auf den gesamten Routenabschnitt. Es stimmt schon, ein Routenplaner muss das wissen. Und das ist gewährleistet, wenn das Tag in der Route steht. Es eignet sich für schematische Karten, die z.B. voraussetzen, dass ein Fahrer auf dem NRW Wegenetz bleiben möchte, das zwischen zwei Knoten nur immer durch die roten Zwischenwegweiser ohne jegliche Zusatzinformation zusammengehalten wird. Da könnten dann die Logos oder Äquivalente mit verwendet werden. Wenn die Informationen in dem Fall aus den Wegen rekonstruiert werden müßten, würde es komplexe Algorithmen erfordern, und die Situation der Wegweiser würde auch nicht abgebildet werden können.

Das über die Wegweiser regeln zu wollen, wäre zwar inhaltlich sauberer (weil man dann nicht mit den z.T. auftretenden logischen Fehlern in der Beschilderung in der Realität kämpfen müßte, und wirklich nur 1:1 abbildet, was da ist), würde aber erfordern, diese Information noch in die direction_xyz=... unterzubringen, womit diese Tags nicht mehr ohne parsing vernünftig lesbar wären oder sehr umständlich und wahrscheinlich uneinheitlich würden. Die aktuelle Syntax ist noch menschenlesbar.

Ich will mich auch gar nicht darum schlagen, so ein Tagging einzuführen. Für mich als Freizeitmapper ist es schon so aufwändig genug, das bisherige Tagging anzuwenden. Ich finde es nur ein bißchen schade, diese Informationen, die so offen auf der Straße liegen, einfach zu ignorieren.

Ich empfehle auch durchaus, die HBR NRW - Hinweise zur wegweisenden Beschilderung für den Radverkehr zu lesen. Ich weiß nicht, ob es für die anderen Bundesländer ähnliche Publikationen gibt, aber es ist m.E. eine große Hilfe in den Entscheidungen, wie man das Netz abbilden könnte. In den Gebieten, in denen das in NRW noch nicht so sehr umgesetzt ist, kann man sich dann auch schon darauf einstellen, was kommt, statt nachher alles neu strukturieren zu müssen.

Peter Elderson wrote:

JochenB wrote:

Peter Elderson wrote:

https://knooppuntnet.nl/nl/map/cycling#1rzj320-15i82az

Gemeint war eher so etwas: Nr 99 - Nr 99 mit nur 13 km Abstand https://knooppuntnet.nl/nl/map/cycling#qb0qy-q9fut

Ist das ein Problem? Es gibt keine Knotenpunkte, die in zwei verschiedene Richtungen auf 99 zeigen.

Es gibt hier übrigens einen Punkt, der auf EINEN anderen (51) in zwei verschiedene Richtungen zeigt (alternative Routen). Weiß auch nicht genau, was planner damit anfangen sollen... Rückwärts ist übrigens nur eine Richtung angegeben.

segubi wrote:

Es gibt hier übrigens einen Punkt, der auf EINEN anderen (51) in zwei verschiedene Richtungen zeigt (alternative Routen). Weiß auch nicht genau, was planner damit anfangen sollen...

Ja, das sehen wir auch in Nederland. Eigentlich sollte es einen Zwischenpunkt geben, aber Operatoren vergessen das manchmal. Die Kreuzung hat oft ein Schild "Alternative mit Hochwasser" oder ähnliches, damit der Reisende wählen kann. Mit Knooppuntnet und anderen Planern kann man einfach die richtige Route auswählen.
Die Aufgabe besteht darin, das zu markieren, was wir sehen. Wir können nicht alle Mängel lösen.

segubi wrote:

Mir geht es darum, den systematisch angewendeten Inhalt der Wegweisung zu mappen.

Ich finde es sehr gut, dass du dir Gedanken machtst und die hier zur Diskussion stellst. Irgendwann wird jemand sowas mappen und dann hat er das vielleicht nicht so durchdacht und dessen ungünstige Lösung setzt sich womöglich durch. Dann lieber gemeinsam dagegentreten und schauen ob es stehenbleibt oder auch gemeinsam verwerfen (und das dann ggf. im Wiki dokumenmtieren).

Die Zusatzinfos auf den Schildern haben den Vorteil, dass sich jemand intensiv damit beschäftigt hat. Es ist sehr viel wahrscheinlicher, dass die Angaben richtig und relevant sind.

Sie haben den Nachteil, dass sie bereits eine Verallgemeinerung sind und Informationen fehlen, z. B. wo genau die Steigung ist.

Wenn die Informationen sich auf den gesamten Abschnitt der Route beziehen, dann ist die route-Relation schon ein möglicher Platz dafür (neben den Wegweisern), insbesondere wenn es Dinge sind, die sich nicht leicht aus den Wegen ableiten lassen, wie z. B. das Bäumchensymbol.

Selbst die Steigungsangaben wären nicht falsch an der Relation. Die Datenverwerter können ja entscheiden, ob sie diese abstrahierte Information verarbeiten oder sich die Infos detailliert aus den Wegen herleiten. Detailierte Angaben an den Wegen sollten globale Angaben in den Relationen überschreiben. Die Frage ist nur, ob es einen Mehrwert gibt und wie groß die Wahrscheinlichkeit der Missinterpretation ist. Und das sehe ich bei den Neigungsangaben kritisch.

Wenn, dann sollte das m. E. nicht einfach mit 'incline=down' gemappt werden sondern vielleicht mit 'incline_symbol=down'. Somit wäre die Quelle der Angabe gleich mit dokumentiert. Bei 'incline=down' könnte man denken, jemand hat das händisch aus den Wegekanten abgeleitet. Das wäre löschenswerter Quatsch.

Wenn sich die Infos nur auf einen Teil der Route beziehen, so müsste man die Route splitten. Das ist es oft bei den Neigungsangaben so. In einem anderen aktuellen Diskussionfaden wurde sich darüber aufgeregt, dass man Wege viel zu viel splittet. Wenn wir jetzt auch noch Relationen in viele Teilrelationen splitten, dann wird das echt unübersichtlich. Da sollten wir uns genau überlegen, ob es das wert ist oder ob wir die Angaben nicht liebr nur an die Wegekanten schreiben.

segubi wrote:

Ich finde es nur ein bißchen schade, diese Informationen, die so offen auf der Straße liegen, einfach zu ignorieren.

Ja finde ich auch. Für die Informationen, die sich aus den Wegekante besser ableiten lassen, ist der Mehrwert aber begrenzt. Für alle anderen finde ich es sinnvoll, solange man die Routen nicht splitten muss.

segubi wrote:

Das über die Wegweiser regeln zu wollen, wäre zwar inhaltlich sauberer (weil man dann nicht mit den z.T. auftretenden logischen Fehlern in der Beschilderung in der Realität kämpfen müßte, und wirklich nur 1:1 abbildet, was da ist), würde aber erfordern, diese Information noch in die direction_xyz=... unterzubringen, womit diese Tags nicht mehr ohne parsing vernünftig lesbar wären oder sehr umständlich und wahrscheinlich uneinheitlich würden. Die aktuelle Syntax ist noch menschenlesbar.

Nur als Idee: Wenn Du die Beschilderung der Wegweiser nicht mit direction_xyz=... einträgst, sondern mithilfe von "destination_sign"-Relationen, könnte man das Steigungs-Symbol unter destination:symbol=... eintragen.

klnkengi wrote:

Nur als Idee: Wenn Du die Beschilderung der Wegweiser nicht mit direction_xyz=... einträgst, sondern mithilfe von "destination_sign"-Relationen, könnte man das Steigungs-Symbol unter destination:symbol=... eintragen.

Hab' ich mir nun mal angeschaut. Stimmt im Prinzip, aber das ist gigantisch aufwändig, ich nehme mal einen aufgeteilten Knotenpunkt zufällig heraus (noch nicht einmal ein besonders umfangreiches Beispiel) Knoten 70 Süd, Bielefeld, es gibt immerhin nur 2 Wegweiser (es gibt auch Knoten mit 3 oder 4 Wegweisern). Auf dem beiden habe ich je Verweise auf 7 Ziele und 4 Knoten. Im Standardfall bekommt jedes Ziel eine Relation, man scheint die Ziele auch zusammenfassen zu können, so dass es immerhin je 3 Richtungen werden (es gehen auch 4-5 wenn man Pech hat). Also muß dieser Knoten mindestens 6 destination_sign Relationen bekommen (statt 2 nodes als guidepost). Das schaffe ich nicht ohne Plugin, das ich nicht selbst programmieren kann. Die Knotendichte ist hier so dicht, dass ich für das Abfahren einer Strecke mit dem Fahrrad weniger Zeit brauche als für das mappen nachher (selbst wenn ich die Hälfte der Strecke durch bereits bekanntes Gebiet fahre), also 4 Stunden Fahrradfahren sind locker 5-6 Stunden Zeit am Computer, wenn ich es halbwegs vollständig machen will.

Aber die Datenstruktur wäre natürlich deutlich besser. Für auswertende Software hübscher zu parsen als die Umkreissuche nach irgendwelchen hoffentlich passenden guideposts... Also wer schreibt's Plugin? Oder gibt's das schon? Ein Fenster, schnell die Richtungen angeben, er findet selbst heraus, welche Wege gemeint sein müssen (Fahrradbefahrbare auswählen, nichts über den Fußweg schicken, oder anbieten, den Fußweg schnell noch mit bicycle=yes zu taggen, vielleicht doch auf die Straße, wenn sie ein cycleway:left:oneway=no hat...) 😉

Oder eine Software, die aus umstehenden Guideposts Wegweiserrelationen bastelt und vorschlägt? Das wäre durchaus denkbar, wenn das zugrundeliegende Netzwerk bereits gut vorstrukturiert ist. Damit wäre ich bei meinem nächsten post: ...

JochenB wrote:

Wenn sich die Infos nur auf einen Teil der Route beziehen, so müsste man die Route splitten. Das ist es oft bei den Neigungsangaben so. In einem anderen aktuellen Diskussionfaden wurde sich darüber aufgeregt, dass man Wege viel zu viel splittet. Wenn wir jetzt auch noch Relationen in viele Teilrelationen splitten, dann wird das echt unübersichtlich. Da sollten wir uns genau überlegen, ob es das wert ist oder ob wir die Angaben nicht lieber nur an die Wegekanten schreiben.

Das betrifft hier übrigens nur eine knappe Handvoll Routen. Es läuft aber da auf eine andere grundsätzlichere Frage hinaus: Man müßte sich Gedanken machen, ob man Routen lieber splitten will, oder Abschnitte mehrfach abbilden möchte. Ich bin da nicht 100% entschieden. Das Radverkehrsnetz NRW ist strukturell erst einmal EIN Netzwerk, das, wenn es nicht fehlerhaft ausgeschildert und aufgebaut ist, ziemlich eindeutig ein Knotenbezogenes Netzwerk ist, an jedem Knoten stehen Wegweiser mit Zielen. Zwischen den Knoten stehen nur Zwischenwegweiser ohne Ziele, ohne spezifische Routenmarkierungen (außer dem reservierten Logo, dem roten Pfeil für eben das NRW-Radverkehrsnetz, mit der Landesgrenze nach Norden wechselt z.B. die Farbe, das ist dann klar ein anderes Netz). Zwischen den Knoten liegen Wege, die gut Routen im osm-Sinn entsprechen. Sie haben Attribute, die durch die Wegweiser an den Enden definiert werden, dazwischen sind keine weiteren Informationen ausgeschildert. Die Knoten können Nummern haben, dann ist es ein "node_network".

Auf diese Minimalrouten setzen auf der nächsten Ebene längere Routen auf:

• Das sind die Routen zwischen nummerierten Knoten,
  
• die durch die Landkreise unterhaltenen Themenrouten
  
• die durch das Land unterhaltenen/organisierten Themenrouten
  
• manche Bundesländerübergreifenden Routen, die sich auch hier aufsetzen. (Z.B. BahnRadRoute WeserLippe)
  

Von der Logik der Daten wäre es so, dass das kleinste Teilchen die oben genannten Routen ohne eigenen Namen sind. Jede andere Art Route setzt sich aus diesen Unterrouten zusammen.

Das erzeugt aber Probleme. Es ist nicht üblich, eine benannte Route sehr vielen Unterrouten zusammenzusetzen, obwohl Langstreckenrouten durchaus aus mehreren Unterrelationen bestehen.

Besonders die Struktur der aktuellen Knotenpunktnetzwerke ist inzwischen zwischen den Niederlanden, Belgien und Deutschland recht großflächig vereinheitlicht, in Frankreich, Österreich und Spanien gibt es auch einzelne Knotenpunktnetzwerke, die diesem Schema folgen. Eine gewisse Abstimmung wäre hilfreich, und/oder Mitarbeit z.B. an dem knooppuntnet Projekt. Man sollte sich da nicht aus der Struktur rauskicken.

Vorteile wären allerdings: Änderungen der Routenführung vor Ort würden unmittelbar in alle betroffenen Routen (Themenrouten, Nummernrouten, Überregionale Fahrradwege) übernommen, die Kartendaten wären leichter aktuell zu halten. Im Moment bin ich dabei mit jeder Strecke, die ich fahre und korrigiere, locker mal 5 weitere Relationen von verschiedensten Fahrradrouten mit korrigieren zu müssen. Auch temporäre Umleitungen könnten markiert werden (gelbe Verkehrsschilder). Auch die Aktualität einzelner Abschnitte ist besser sichtbar. (survey:date=xyz)

Die Eigenschaften der Unterabschnitte könnten auf Karten schnell sichtbar gemacht werden: z.B. Grüne Abschnitte für die "Bäumchen"-Logos, andere Farben für die starken Steigungen.

Ich benutze im Moment zunächst in Bielefeld eine Mischform: Ich bearbeite das Knotenpunktnetzwerk nach den üblichen Regeln, eine Relation für eine Route zwischen zwei Nummern. Die benannten Routen haben eine komplette Relation (wenn sie sich nicht verzweigen), die unabhängig von den anderen ist. Was dann noch übrig bleibt, bekommt Routenrelationen zwischen zwei Wegweisern, die in das Netzwerk ("Radverkehrsnetz NRW Stadt Bielefeld") aufgenommen werden.

Im Moment lösche ich aus der Relation "Radverkehrsnetz NRW Stadt Bielefeld" nach und nach alle Einzelwege, die entweder durch das Knotenpunktnetzwerk oder durch Routen in dieser Relation bereits dargestellt sind. Wenn ich das so mache, müßte ich eigentlich auch die Themenrouten in die Relation mit aufnehmen, um dann nur noch ganz wenige unbenannte Routen übrig zu haben. Was aber würde ich mit den überregionalen Resten machen, sowohl in Bielefeld aufnehmen als auch z.B. im Kreis Gütersloh? Die Route nach Kreisen teilen? Das ist alles nicht so elegant. Insbesondere würde das wieder zu nur bedingt sinnvollen Sammelrelationen führen, z.B. wenn man die NRW-Themenrouten auch anfangen würde zu sammeln...

Ich stelle mir vor, dass ich, wenn ich mir die Relation "Radverkehrsnetz NRW" mit allen Unterrelationen anschaue, dann auch das komplette Radverkehrsnetz NRW habe. Da im Moment eine Relation "Knotenpunktnetzwerk NRW" alle Knotenpunktnetzwerke in NRW enthält und diese im "Radverkehrsnetz NRW" enthalten ist, benötige ich für dieses Ziel keine doppelte Anführung von den Routen.

Irgendwie empfinde ich es als ungünstig, wenn "ways" doppelt enthalten sind. Bei Routen fällt mir das nicht so schwer. Im Moment kommt es oft vor, dass ein identischer Streckenabschnitt je nach Route unterschiedlich gewählt wird. Wenn ich von A nach B auf der Themenroute fahre, werde ich vielleicht über den Pfad an der Seite geführt, muß zwischendurch absteigen, weil plötzlich der Radweg nur noch in eine Richtung befahren werden darf etc.. Fahre ich den gleichen Abschnitt auf dem Knotenpunktnetzwerk, wird der Weg über die Autostraße geführt, die mit use_sideway markiert ist. Dabei können unterschiedliche errechnete Zeiten und Entfernungen herauskommen, oder ein Weg auch mal gar nicht durchgängig sein. Oder man bekommt Alternativen beim Routing angeboten, die gar keine sind.

Aus diesem Grund bin ich dagegen, Informationen, die sich auf eine Route beziehen (also auf dem WegWEISER und nicht auf dem WEG sind), an Wegen zu taggen.

Ein wichtiges Kriterium fürs Taggen ist mir auch, dass man eine Struktur schafft, die man automatisiert möglichst einfach in eine andere überführen kann. Das reduziert letztlich die Gefahr, dass Änderungen massiv arbeitsaufwändig und dann ggf. unmöglich würden. Da darf es ruhig auch etwas kleinteilig in manchen Dingen sein. Zusammenführen geht automatisiert einfacher als umgekehrt.

(zu viel Text, ich weiß... ich schaff heute Abend kein Kürzen mehr. Sorry)

Grüße, Sebastian

segubi wrote:

Aus diesem Grund bin ich dagegen, Informationen, die sich auf eine Route beziehen (also auf dem WegWEISER und nicht auf dem WEG sind), an Wegen zu taggen.

Das sehe ich auch so. Ausnahme: Wenn es noch keine route-Relation gibt, der Mapper nicht den gesamten Verlauf kennt oder mit Relationen nicht gut umgehen kann, wäre z. B. ein lcn=* an die Kanten eine Alternative, bis sich jemand findet, der die Relation anlegt.

segubi wrote:

Von der Logik der Daten wäre es so, dass das kleinste Teilchen die oben genannten Routen ohne eigenen Namen sind. Jede andere Art Route setzt sich aus diesen Unterrouten zusammen.

Das wurde hier kürzlich auch irgendwo diskutiert, finde es aber nicht mehr. Dort fand das nicht so Anklang. Ein Argument war glaub ich, dass die Themenrouten nicht immer deckungsgleich sind mit den Netzverbindungen.

Ich finde es problematisch, dass man diese Routen beim Bearbeiten der Wege bzw Verbinungs-Relationen nicht sieht. Das die Themenroute dort lang geht erfährt man erst durch einen Blick in die Elternrelationen der Netzverbindung. Das birgt Gefahren und erschwert die Pflege.

segubi wrote:

Was aber würde ich mit den überregionalen Resten machen, sowohl in Bielefeld aufnehmen als auch z.B. im Kreis Gütersloh? Die Route nach Kreisen teilen? Das ist alles nicht so elegant. Insbesondere würde das wieder zu nur bedingt sinnvollen Sammelrelationen führen, z.B. wenn man die NRW-Themenrouten auch anfangen würde zu sammeln...

Im Prinzip sind die Master-Relationen reine Sammelrelationen. Die Kreisrelationen helfen aber, beim Mappen des Netzes den Überblick über alle Verbindungen zu halten, Verbindungen zu Nachbarkreisen mit Rolle 'connection'. Insofern sind für mich solche Kreisrelationen für das Netz OK, egal es ein Knotenpunktnetzwerk ist oder ein Grundnetz ohne Routen-Symbole.

Die Themenrouten würde ich nicht in kreis- oder länderspezifische Masterrelationen aufnehmen. Das macht die nur unübersichtlicher.

Eine master-network-relation für Themenrouten würde ich nur machen, wenn es ein spezielles Netz eines besonderen Betreibers ist und es nicht durch administrative Grenzen definiert ist. Ein solchens Beispiel wären die Routen des "Rad- und WanderParadies Schwarzwald und Alb". Dann hat man das problem des Teilens an Grenzen auch nicht.

segubi wrote:

Ich benutze im Moment zunächst in Bielefeld eine Mischform: Ich bearbeite das Knotenpunktnetzwerk nach den üblichen Regeln, eine Relation für eine Route zwischen zwei Nummern. Die benannten Routen haben eine komplette Relation (wenn sie sich nicht verzweigen), die unabhängig von den anderen ist. Was dann noch übrig bleibt, bekommt Routenrelationen zwischen zwei Wegweisern, die in das Netzwerk ("Radverkehrsnetz NRW Stadt Bielefeld") aufgenommen werden.

Das ist doch gut so. Nur dass es zwei Master-Relationen für das Netz gibt, finde ich verwirrend, insbesondere, wenn das Netz des Kreises in großen Teilen in ein Knotenpunktnetzerk aufgegangen ist.

Das Tagging-Schema der Knotenpunktnetze sieht ja auch route-Relationen mit 'state=alternate' vor. Damit könnte man die Verbindungen ohne Knotenpunktwegweisung versehen. Wenn sich mein Vorschlag mit dem 'network:type=basic_network' durchsetzt, wäre das eine wesentliche Anwendung dafür.

Diese Verbidnungen könnten alle in eine Master-network-Relation. Die unterschiedliche Wegweisung würde anhand des 'network:type' an der Relation erkannt, so dass Renderer die unterschiedlich darstellen können. Fänd ich übersichtlicher.

JochenB wrote:

segubi schrieb:

Von der Logik der Daten wäre es so, dass das kleinste Teilchen die oben genannten Routen ohne eigenen Namen sind. Jede andere Art Route setzt sich aus diesen Unterrouten zusammen.

Das wurde hier kürzlich auch irgendwo diskutiert, finde es aber nicht mehr. Dort fand das nicht so Anklang. Ein Argument war glaub ich, dass die Themenrouten nicht immer deckungsgleich sind mit den Netzverbindungen.

(The Belgian forum has just discussed this again). Here is (slightly edited) what I posted:

1. I have tested building 2 longer routes out of existing node2node routes, because the operator claimed they were absolutely following the node network. Turn out they didn't, but that was not a problem: I just added some extra ways and sections. The problem was: you can't sort the parts, and you can't see the order of the parts in the superrelation. It turns unmaintainable very quickly.

2. The other test was with roundtrip local walks (colour loops). That particular walking network was built by combining all the existing local 'colour loops'. Everywhere the loops cross or touch each other, a Network Node was placed. All the node2node routes are part of one or more loops and every loop can be made from a limited number of node2node routes. I created the loop relations by collecting a few (2-6) node2node relations into a loop relation. The node2node relations were rwn and the loops were lwn, but that posed no problem.

So the first use case (long theme route) failed: unmanageable for long routes with many node2node sections.
Example (look at the sections in the information panel): https://hiking.waymarkedtrails.org/#route?id=9576945

The second use case (local loops) turned out to be beneficial. The node network actually benefits from the colours, and the loops benefit from the node planner. You can see the colours (colour=* on the node2node relations) in the output of the Knooppuntnet Planner.
Compare:
https://hiking.waymarkedtrails.org/#sea … 936!7.0487
https://knooppuntnet.nl/nl/map/hiking#6 … 8on-5777a2

Peter Elderson wrote:

1. I have tested building 2 longer routes out of existing node2node routes, because the operator claimed they were absolutely following the node network. Turn out they didn't, but that was not a problem: I just added some extra ways and sections. The problem was: you can't sort the parts, and you can't see the order of the parts in the superrelation. It turns unmaintainable very quickly.
[...]
So the first use case (long theme route) failed: unmanageable for long routes with many node2node sections.
Example (look at the sections in the information panel): https://hiking.waymarkedtrails.org/#route?id=9576945

I agree, one has to be careful not to create difficulties in doing that. But I don't exactly know what you mean by "can't sort" and "can't see the order". In the mentioned relation 9576945 the members seem to be ordered correctly and I see it in JOSM. It isn't indicated next to the relations, but the order is sorted and visible. And even waymarkedtrails shows the elevation profile in the proper order and has no difficulties. The sections there are ordered alphanumerically, if waymarkedtrails left them unsorted they had the proper order I assume.
Hm. I see an issue: there are no roles forward an backwards set for the relations. That would be necessary I think. My comment on the elevation profile is incomplete. It looks fine because there are so many fragments that I don't see, whether these are sometimes reversed...
So its a matter of the editing or rendering software and not of the data. I agree that sorting relations would be more difficult than sorting ways and more error prone, and a connection between routes is difficult to define if there are split nodes not just a binary value connected/not connected! Maybe it's some project for the future if the structure of the networks still would suggest that way.

segubi wrote:

The sections there are ordered alphanumerically, if waymarkedtrails left them unsorted they had the proper order I assume.

True. I have asked for that, but got no response. Maybe you could try? The same goes for other sectioned routes, that's why they get names with a section number in it.
The elevation profile (and the export gpx) actually solve most ordering problems, unless there are too many errors: gaps, crossing ways, or unsolvable puzzles such as closed way roundabouts, pedestrian areas, or if roles are involved, then it fails.
The same is true for sorting in JOSM (yes, if you know the order you can see it's allright, but the continuity line is not correct and if the order is messed up, you need external sources and individual placement of the members to get it right again).

segubi wrote:

So its a matter of the editing or rendering software and not of the data. I agree that sorting relations would be more difficult than sorting ways and more error prone, and a connection between routes is difficult to define if there are split nodes not just a binary value connected/not connected! Maybe it's some project for the future if the structure of the networks still would suggest that way.

True, better tools could do a lot, but I can't build them and I don't see much enthousiasm of programmers for this niche... so until the brighter future arrives, we'll have to manage without. And, if I look at other challenges in OSM, I have to admit this is not the highest priority.

Hallo allerseits,

ich erfasse das neue Radwegeknotennetz Altmark. Dabei stoße ich auf ein Problem: Laut zuständiger Behörde enden Routen auch an Punkten ohne Knotenpunkt. Ist diese Fallgestaltung bereits aufgetreten und wie kann man dies lösen?

Hallo Ainadilion,

Das Netz sieht sehr gut aus. Ich konnte es aber noch nicht bis in Detail prüfen. Ein Fehler ist mir aber bereits aufgefallen, den Natura evtl. schon korrigiert hat.

Kamern-Mahlitz: Die Strecke geht vom KP 35 nach Kamern und führt auf der Straße zum See und endet zwischen den KP 20 und 43. Nicht am KP 20.

Mit freundlichen Grüßen

Im Auftrag

Jeanett Czinzoll Tourismusmanagerin

Verbandsgemeinde Elbe-Havel-Land Bismarckstr. 12 39524 Schönhausen (Elbe)

https://cycling.waymarkedtrails.org/#?m … 25!12.1056
https://knooppuntnet.nl/en/analysis/cha … 74/4786928

Gruß
Ainadilion

Hallo Ainadilion,

einige Frage zur Verständnis, bevor ich das beantworten kann:

Eine Knotenpunktroute ist es ja nur dann, wenn sie mit den entsprechenden Knotenpunktnummern ausgeschildert ist. Ich nehme an in die eine Richtung ist KP35 ausgeschildert. Welche Nummer ist in die andere Richtung ausgeschildert? Und welche Nummern sind an diesem Wegweiser vorhanden? https://cycling.waymarkedtrails.org/#gu … =516386981

Möglicherweise handelt es sich um einen split node (siehe https://wiki.openstreetmap.org/wiki/Cyc … k_Tagging). Die sind etwas komplizierter, technisch aber leider notwendig, wenn ausgewiesene Knotenpunkte mit einer Nummer geometrisch und der OSM ways her nicht an ein und dem selben Punkt liegen.

Ainadilion wrote:

... Im Auftrag

Jeanett Czinzoll Tourismusmanagerin

Verbandsgemeinde Elbe-Havel-Land Bismarckstr. 12 39524 Schönhausen (Elbe)

Ich würde einfach darauf verweisen einen "Endpunkt" zu benennen, da "Radeln nach Zahlen" schließlich an einer Zahl enden sollte. Als Tourismusverband sollte man auch an dem "ordentlichen" Aufbau der Routen interessiert sein. Wie komm ich denn von "endet zwischen den KP 20 und 43" weiter, wenn dort nichts ausgeschildert ist?

Guten Abend zusammen,

Ich hatte ja Ainadilion per PN geraten, sein Problem in diesem Beitragsfaden darzulegen. @Ainadilion Danke! 🙂

Ich stecke zwar recht gut in dieser Materie drin, bin mir hier aber auch unsicher...
Auf solche Situationen stößt man aber immer wieder mal...

Ich habe hier bei mir vielleicht eine ähnliche Situation...

Knotenpunkt 14 verweist unter anderem auf Knotenpunkt 18 (zunächst) Richtung Südwest...

Hier die Karte dazu (bitte merken)...

Der Wegweiser mit dem Knotenpunkt 18 hingegen ist hier: https://www.openstreetmap.org/node/85778579

und verweist in fragliche Richtung nur zum Knotenpunkt 17 (dieser wiederum dann nur zur 18..)

Dann, am Abzweig zurück zum Knotenpunkt 14 gibt es nur dieses Schild:
Bild 1:

Bild 2:

Sowohl vom Knotenpunkt 17, als auch 18 gibt es direkt keinen Hinweis auf den eingangs genannten Knotenpunkt 14.

So... kommen wir zum "bitte merken"...
betrachtet man sich nochmal die oben gezeigte Karte, ist der Knotenpunkt 18 an eine Stelle gesetzt...

Ich selbst interpretiere das für mich so, als daß ich beide hier dargestellten Punkte https://cycling.waymarkedtrails.org/#?m … 66!13.7598 als ein Knotenpunkt "18" betrachte (Entfernung: ca. 50m).... entsprechend ist es erfasst...

Zurück zur Ausgangsfrage von Ainadilion...

Mich würden Fotos der beteiligten Wegweiser der Knotenpunkte dringend interessieren...

Das ist ja immer eine Abwägung zwischen einem theoretischen Netz und dessen praktischer Umsetzung. Im Moment würde ich hier aber zu einer ähnlichen Lösung wie von mit dargelegt, tendieren...

...erst mal eine Zwischenmeinung...

Viele Grüße,

Sven

PS: Ach ja: alle Fotos in diesem Beitrag haben Geokoordinaten sowie Fotografierrichtung!!

Moin streckenkundler,

ich habe mir deine Situation mal mit deinen Fotos und mapillary angesehen. Das ist eindeutig eine split node Situation. Für die Fehleranalyse und das Routing von knooppuntnet.nl sind hier sogenannte tentacle in den Routen nötig. Das ist wie schon erwähnt auf dem ersten Blick etwas komplizierter, kommt bei mir in Köln und Umgebung aber häufig vor.
Bei dir hast du aber das perfekte, einfachste Beispiel dafür. Wenn du nichts dagegen hast, würde ich die Stelle bei dir einfach mal entsprechend umbauen. Das hilft dir vielleicht als Anschauung direkt weiter?

Hallo,

ein Foto des Knotenpunktes findet sich hier:
https://photos.google.com/share/AF1QipO … VRYmN5WEJR

Hier der Zwischenwegweiser:
https://photos.google.com/share/AF1QipO … VRYmN5WEJR

und hier schließlich der Punkt 43
https://photos.google.com/share/AF1QipO … VRYmN5WEJR

Gruß
Ainadilion

Die Auszeichnung vor Ort ist allerdings unvollständig... Optimalerweise müssten an beiden Wegweisern bei Knotenpunkt 18 jeweils die Nummern 14, 16, 17, 27 ausgewiesen sein. Was mindestens fehlt ist die 14 an dem Wegweiser mit der großen 18 oben drauf, den Rest kann man auch so machen wie es ist.

Duvodas wrote:

Bei dir hast du aber das perfekte, einfachste Beispiel dafür. Wenn du nichts dagegen hast, würde ich die Stelle bei dir einfach mal entsprechend umbauen. Das hilft dir vielleicht als Anschauung direkt weiter?

Wenn du willst, leg los. Dann hab ich eine Referenz...

Duvodas wrote:

Die Auszeichnung vor Ort ist allerdings unvollständig... Optimalerweise müssten an beiden Wegweisern bei Knotenpunkt 18 jeweils die Nummern 14, 16, 17, 27 ausgewiesen sein. Was mindestens fehlt ist die 14 an dem Wegweiser mit der großen 18 oben drauf, den Rest kann man auch so machen wie es ist.

Ja, deswegen die Zwischenlösung mit der Route https://www.openstreetmap.org/relation/11256109 da bei gut 50m Entfernung beides zueinander sichtbar ist...

Sven

Ok, ich habe es gerade umgebaut.
Ich kann mal Versuchen das Prinzip der split nodes kurz zusammenzufassen:
Es gibt technisch mehrere Knotenpunkte, die im Netz mit der gleichen Nummer ausgezeichnet sind. Das ist häufig an großen Kreuzungen und Brücken der Fall, aber auch an Straßensituationen wie dieser.
Man schaut sich nun jede Knotenpunktroute einzeln an, die mit dem Knotenpunkt verbunden ist, und zwar in dieser Beschreibung gedanklich in Richtung des Knotenpunkts. Die Route wird nun ganz normal für beide Fahrrichtungen bis zum ersten Knoten des split nodes geführt. Zusätzlich müssen von allen anderen Knoten des split nodes aus Verbindungen nur für die Gegenrichtung (die sogenannten tentacles) angelegt werden, die bis zur ersten erreichbaren Stelle einer der folgenden Möglichkeiten geführt werden:
1. dem ersten Knoten
2. einem anderen tentacle
3. einem Punkt der Hauptroute

Anders formuliert: In Richtung des split nodes wird die Route nur bis zum ersten Knoten des split nodes angelegt, in Gegenrichtung aber von allen Knoten des split nodes.

Ausführliche Anleitung und komplexe Beispiele gibts hier:

https://wiki.openstreetmap.org/wiki/Cyc … rk_Tagging

Anschließend kann man bei knooppuntnet.nl gut sehen, dass das Routing jeweils über die kürzeste Verbindung geführt wird ohne dass doppelte Knoten oder Routen wie 18-18 nötig sind.

Betreffs der Altmark:

Aus den Fotos ist nicht ersichtlich, was in Mahlitz am Knotenpunkt (KP) 35 ausgeschildert ist.

Wenn dort tatsächlich sowohl der KP 20 als auch der KP 43 mit einzelnen Einschüben ausgeschildert ist, dann sind es auch zwei route-Relationen: eine zum KP 20, eine zum KP 43. Das wäre dann die saubere Lösung.

Wenn am KP 35 nur die 20 ausgeschildert ist, dann ist der Wegweiser am Abzweig Teil des KP 20 und es gibt eine Route 35 <>20 mit einem Split-Node am KP 20.

Der Abstand zwischen KP 20 und KP 43 beträgt 380m. Der Abstand zwischen Abzweig und KP 20 nur 125m. Das spräche dafür den Abzweig tatsächlich als Teil des KP 20 zu verstehen.

Auch die Karte des Knotenpunktnetzwerkes verbindet den KP 35 nur mit dem KP 20. Spricht auch für den Split-Node am KP 20.

Normalerweise heißt Knotenpunktnetzwerk "keep it simpel". Es wird immer nur der nächste Knoten ausgeschildert, pro Richtung also eine Nummer. Im Bild wird am Abzweig nicht nur der nächste KP 20 sondern gleich noch der übernächste KP 19 ausgeschildert. Man könnte das als weiteren dezenten Hinweis verstehen, dass dieser Wegweiser Teil des KP 20 ist.

Wenn vom KP 35 aus auch der KP 43 ausgeschildert ist, sollte diese Relation trotzdem erstellt werden, sie ist draußen ja auch ausgewiesen, unabhängig von der Sicht der netten Mitarbeiterin der Gemeinde und unabhängig davon, ob der KP 20 gesplittet wird oder nicht.

Noch ein paar Hinweise zum Tagging:

Am Knotenpunkt 20 und 43 wurde der Wegweiser direkt auf den Kreuzungspunkt der Wege getaggt. Das ist nicht im Sinne des Erfinders. Den Wegweiser möglichst dort taggen, wo er steht, den Knotenpunkt dagegen auf den Kreuzungspunkt der Wege (KP 20: node/516386987 und KP 43: node/1808230300).

Im Wiki dazu:

• Knotenpunkt: DE:Key:rcn_ref
• Wegweiser im Knotenpunktnetzwerk: wiki/DE:Tag:information=guidepost

Die Master-network-Relation des Knotenpunktnetzes sollte kein 'route=bicycle' haben, denn sie stellt keine Route dar sondern eine Art Sammelkategorie(relation/12331231).

Im Wiki dazu:

• wiki/DE:Relation:network

Ainadilion wrote:

Hier der Zwischenwegweiser

<klugscheißermodus an>

Zwischenwegweiser sind nur die kleinen Pfeil-Schilder auf der Strecke zwischen zwei Hauptwegweisern. Dort gibt es keine Ortsangaben sondern maximal Aufkleber der Routen und einen (!) Pfeil.

<klugscheißermodus aus>

Ainadilion wrote:

Hallo,

ein Foto des Knotenpunktes findet sich hier:
https://photos.google.com/share/AF1QipO … VRYmN5WEJR

Hier der Zwischenwegweiser:
https://photos.google.com/share/AF1QipO … VRYmN5WEJR

und hier schließlich der Punkt 43
https://photos.google.com/share/AF1QipO … VRYmN5WEJR

Gruß
Ainadilion

Sorry, ich hatte Deine Fotos letztens übersehen.

Die Ausschilderung an KP 35 wäre interessant.

1. nur 20 ausgeschildert

KP20 müsste ein split node sein. Ohne split node würde man bei der Route 35->43, streng der Beschilderung folgend, das letzte Stück zum KP20 hin und zurück, also doppelt fahren. Allerdings ist für eine korrekte Beschilderung mit einem split node die 35 am Schild bei KP43 zuviel und an Deinem "Zwischenwegweiser" (der dann auch ein KP20 wäre) müsste die 20 durch die 02 ersetzt werden.

2. 20 und 43 ausgeschildert

Kein split node, die Rrouten 35->20 und 35->43 wären größtenteils identisch (unschön). In diesem Fall wäre die 19 an Deinem "Zwischenwegweiser" zu viel.

Mir scheint es hier so zu sein, dass die Planer selbst nicht ganz genau wussten, wie sie diese Situation ausschildern sollen 😉

Duvodas wrote:

Mir scheint es hier so zu sein, dass die Planer selbst nicht ganz genau wussten, wie sie diese Situation ausschildern sollen

In den Niederlanden ist das genau so!
Wir haben sogar Operatoren, die keine Zahlenreferenzen auf die Knotenpunkte schildern! Woher weiss man dann, wie man zum nächsten Punkt gelangt?

Knotenpunkte mit Namen statt Nummern: Knooppuntnet hat das jetzt eingebaut, für Analyse und für Map (Planer).

Ich habe gesehen, dass Deutsche Mapper im Schwarzwald bereits viel Arbeit geleistet haben, Kudo's!

Waymarkedtrails unterstützt Knotenpunkte mit Namen (noch) nicht, aber da WMT die Wegweiser anzeigt, sieht es immer noch vernünftig aus.

Die Methode ist für alle Typen von Knotenpunktnetzwerke gleich. Aber, zB, lwn und rwn zu mischen das funktioniert noch nicht. Also alle Elemente lwn, oder alle Elemente rwn.

Die ersten Pilotversuche zu diesem Ergebnis wurden in Deutschland durchgeführt. Vielen Dank dafür!

Das geht mit Wanderwegen im Schwarzwald aber leider nicht mit Fahrradwegen. Der Grund ist simple. Die Wanderwege haben am Ziel einen Wegweiser mit Namen. Die Fahrradweg haben aber nur Richtungsangaben ohne Angaben eines Namens am Wegweiser und häufig fehlt am Ziel auch ein Wegweiser. Der Anfang und das Ende bleiben dadurch immer unscharf.

Ich habe auch schon Beispiele gefunden, wo jetzt die einzeln Segment-Relationen in die übergeordneten Relationen eingebaut wurden. Vom Prinzip, ja richtig, allerdings Frage ich mich in wie viele Ebenen von Superroutes wird dann einen europäischen Radwanderweg eintragen wollen. Beim ÖPV gibt es starke Bedenken bei Segment-Relationen aufgrund der zusätzlichen Ebenen, aber vielleicht ist dann `bicycle` und `hiking` ein Türöffner.

Insgesamt fände ich es auf jeden Fall gut, wenn wir einen Tag für die Unterscheidung von Fahren nach Zahlen bzw Fahren nach "Namen" haben.

Ich denke, Peter redet nur von Knotenpunktnetzwerken mit Namen, nicht den von skyper angesprochenen "Radverkehrsnetzen" in Deutschland.

Es gibt:

1) Knotenpunktnetzwerke mit fester Bezeichnung für die Knoten:
-- Nummern
-- Namen

2) Radverkehrsnetze / Zielwegweisung

Hier gehts um 1), über 2) wird u.a. hier diskutiert: https://forum.openstreetmap.org/viewtopic.php?id=72458

skyper wrote:

Insgesamt fände ich es auf jeden Fall gut, wenn wir einen Tag für die Unterscheidung von Fahren nach Zahlen bzw Fahren nach "Namen" haben.

++1

Der Begriff "Knotenpunktnetzwerk" ist bereits belegt für das "Radeln/Wandern nach Zahlen", wo i.d.R. nur die nächste Knotenpunktnummer ausgeschildert wird. Idee war ja, dass sich der Tourist nur eine Reihe von Nummern merken/aufschreiben muss, keine langen Namen.

Ein Netzwerk, in dem die Wegweiser Namen statt Zahlen haben und i. d. R. mehrere Ziele ausgewiesen werden, fällt nicht unter diese Definition. Das hatte ich ja an anderer Stelle bereits mit Quellen belegt.

Auch sollte dem Renderer die Chance gegeben werden, beides anhand eines Taggs zu unterscheiden. So kann er damit anders umgehen.

Duvodas wrote:

…Man schaut sich nun jede Knotenpunktroute einzeln an, die mit dem Knotenpunkt verbunden ist, und zwar in dieser Beschreibung gedanklich in Richtung des Knotenpunkts. Die Route wird nun ganz normal für beide Fahrrichtungen bis zum ersten Knoten des split nodes geführt. Zusätzlich müssen von allen anderen Knoten des split nodes aus Verbindungen nur für die Gegenrichtung (die sogenannten tentacles) angelegt werden, die bis zur ersten erreichbaren Stelle einer der folgenden Möglichkeiten geführt werden:
1. dem ersten Knoten
2. einem anderen tentacle
3. einem Punkt der Hauptroute

Ich hatte Probleme, das zu verstehen. Mir war nicht klar was nun genau der "Split-Node" ist. Der Knotenpunkt als Ganzes oder die einzelnen OSM-Knoten? Schwierig war für mich auch das "in der Gegenrichtung", da mir nicht klar war, von welcher Richtung es die Gegenrichtung war. Nächster Stolperpunkt: Was ist eine "Hauptroute". Zudem: Wenn das Tentakel nicht an einem Split-Node sondern auch an einem anderen Tentakel enden kann, so muss man ggf. bei der Fahrt durch den Knoten 2 mal die Relation wechseln. Das ist m. E. nicht im Sinne des Erfinders. Erschwerend kommt dazu, "Knoten" in diesem Kontext dreifach belegt ist:

• Knoten des Knotenpunktnetzwerkes
• OSM-Knoten, die diesen Knoten darstellen
• Knoten im OSM-Graph allgemein

Auch den englischen Text in wiki/Cycle_Node_Network_Tagging habe ich erst verstanden, nachdem ich das Beispiel intensiv studiert habe. Das kann aber auch an meinem Englisch liegen.

Ich habe es selber versucht. Es ist echt schwer, das textlich so zu beschreiben, dass es eindeutig ist und man es trotzdem versteht. Auf jeden Fall wird es länger. Hier der Link zu meinem Vorschlag für das Wiki mit zwei abstrakten Beispielen:

wiki/User:JochenB/split_nodes

Stimmt das Vorgehen so? Ist der Text verständlich?

Das Beispiel 2 entspricht dem Beispiel auf wiki/Cycle_Node_Network_Tagging

Unschön ist, dass sich in den Relationen durch die Tentakel keine durchgehende Wegekette mehr ergeben. Diese Durchgängigkeit ist normalerweise ein einfacher Qualitätscheck. Leider kann man die Tentakel nicht über eine Rolle wie z. B. 'link' markieren, da die Rollenfelder schon mit 'forward' bzw 'backward' belegt sind.

Der Text ohne Beispiele nochmal hier:

Mitunter können nicht alle Relationen des Knotenpunktnetzwerkes an dem gleichen Knoten im OSM-Graph beginnen und enden. Das kommt vor allem an größeren Kreuzungen vor. Die Aufgabe ist, die Relationen trotzdem in allen möglichen Richtungen lückenlos zu verbinden. Dabei sollen Relationen vermieden werden, die Start und Ziel im gleichen Knoten haben (z. B. Relation "18-18" innerhalb des Knotenpunkts 18).

Folgend eine Anleitung dafür. Dabei ist wichtig, folgende Begriffe zu unterscheiden:

• OSM-Node - der Knoten im OSM-Graph
• Knotenpunkt - der nummerierte Knotenpunkt im Knotenpunktnetzwerk ("Radeln nach Zahlen")
• Split-Nodes - OSM-Nodes, auf die sich ein Knotenpunkt aufteilt
• Relation - route-Relation der Verbindung zweier Knotenpunkte. Die Relationen enthalten Wege beider Fahrrichtungen. Die Fahrrichtungen werden hier in getrennten Schritten betrachtet:

• zulaufend - Richtung von einem benachbarten Knotenpunkt
• abgehend - Richtung zu einem benachbarten Knotenpunkt
• Fahrweg - Wege einer Fahrrichtung

Der Knotenpunkt wird auf mehrere OSM-Nodes aufgeteilt, den "Split-Nodes". Die Split Nodes werden an jede Relation angebunden. Dazu wird nacheinander jede am Knotenpunkt endende Relation betrachtet und folgende drei Schritte durchgeführt:

1. Schritt: Split-Node anlegen

Es wird der zulaufende Fahrweg betrachtet. Der Split-Node ist der erste OSM-Node, an dem der Fahrweg auf einen Fahrweg von/zu einem anderen Knotenpunkt trifft.

Der Split-Node erhält die Nummer des Knotenpunkts im Tag 'rcn_ref=*'.

2. Schritt: Zulaufenden Fahrweg in der Relation abbilden:

Der zulaufende Fahrweg endet am ersten Split-Node des Knotenpunkts.

3. Schritt: Abgehenden Fahrweg in der Relation abbilden:

Der abgehende Fahrweg soll die durchgehende Verbindung zu den anderen Relationen herstellen. Er beginnt dazu an einem Split-Node, wo ein zulaufender Fahrweg aus Schritt 2 endet.

Idealerweise wird der Start des abgehenden Fahrwegs so gewählt, dass in seinem Verlauf durch den Knotenpunkt alle anderen zulaufenden Fahrwege angebunden werden.

Ist dies nicht möglich, so werden weitere Fahrwege in die Relation aufgenommen, mit denen die anderen Split-Nodes angebunden werden. Es gibt dadurch am Beginn der Relation mehrere "Tentakel", die die Radfahrer/Wanderer von allen zuführenden Relationen abholen.

Dabei wird in Kauf genommen, dass die Wege in der Relation keine durchgehende Wegekette mehr ergeben.

Qualitätschecks:

• Es gibt es maximal so viele OSM-Node mit 'rcn_ref=*', wie es Relationen zu Nachbarknoten gibt.
• In jeder Fahrrichtung durch den Knoten gibt es nur einen Wechsel der Relationen.
• In jeder Fahrrichtung durch den Knoten gibt es nur mindestens einen OSM-Node mit 'rcn_ref=*'.
• An jedem OSM-Node mit 'rcn_ref=*' endet mindestens ein zulaufender Fahrweg einer Relation.
• An jedem OSM-Node mit 'rcn_ref=*' beginnt mindestens ein abgehender Fahrweg einer Relation.
• An jedem endenden zulaufenden Fahrweg befindet sich ein OSM-Node mit 'rcn_ref=*'
• An jedem endenden zulaufenden Fahrweg schließen sich die abgehenden Fahrwegen aller anderen Relationen an
• ... (weitere?)

JochenB wrote:

Auch sollte dem Renderer die Chance gegeben werden, beides anhand eines Taggs zu unterscheiden. So kann er damit anders umgehen.

lwn Knotenpunkte mit Namen sind getaggt mit lwn_name=<Name>
lwn Knotenpunkte met Zahlen oder kurze Coden sind getaggt mit lwn_ref=<Zahl oder Code>
Ich denke das genügt, oder?

Die von den Belgiern und Niederländern entworfene und in Zusammenarbeit mit anderen Ländern weiter ausgebaute Definition des Knotenpunknetzes in OSM ist nicht auf Zahlen beschränkt. Es ist eine funktionale Definition: Knoten haben eine Marke als Referenz für den Benutzer, und benachbarte Knoten verweisen zu zweit aufeinander. An Zwischenkreuzungen müssen nur Pfeile vorwärts und Pfeile zurück vorhanden sein, die Knoten dazwischen müssen nicht erwähnt werden, obwohl dies oft der Fall ist. Wenn die Knoten keine Namen oder Nummern, sondern Bilder oder Symbole oder (warum nicht) Pieptöne hätten, könntest du die Route genau so planen und so erhältst du eine Liste von Bildern usw., denen der Reisende folgen kann.

Das System ist so konzipiert, dass es in all diesen Fällen gleich funktioniert. Deshalb finde ich es gut, den gleichen network:type zu verwenden. node_network zeigt an, dass die Segmente an diesen Punkten miteinander verknotet sind, wie die Schnüre in einem Fischernetz.

Beispiel: extreme Split-Node-Situation mit alternativer Lösung, der „Cluster-Methode“.
https://knooppuntnet.nl/nl/analysis/route/11512870/map

Peter Elderson wrote:

lwn Knotenpunkte mit Namen sind getaggt mit lwn_name=<Name>
lwn Knotenpunkte mit Zahlen oder kurze Coden sind getaggt mit lwn_ref=<Zahl oder Code>
Ich denke das genügt, oder?

Ja, damit wären wenigstens die Knotenpunkte unterscheidbar.

Peter Elderson wrote:

JochenB wrote:

Auch sollte dem Renderer die Chance gegeben werden, beides anhand eines Taggs zu unterscheiden. So kann er damit anders umgehen.

lwn Knotenpunkte mit Namen sind getaggt mit lwn_name=<Name>
lwn Knotenpunkte met Zahlen oder kurze Coden sind getaggt mit lwn_ref=<Zahl oder Code>
Ich denke das genügt, oder?

Die von den Belgiern und Niederländern entworfene und in Zusammenarbeit mit anderen Ländern weiter ausgebaute Definition des Knotenpunknetzes in OSM ist nicht auf Zahlen beschränkt. Es ist eine funktionale Definition: ...

Ich finde es nicht gut, wenn wir Dinge in OSM anders definieren als draußen. Vermutlich ist das jetz so etabliert, dass man es nicht mehr geändert bekommt.

Wie kann ich anhand der Daten unterscheiden zwischen Relationen eines klassischen "Knotenpunktnetes" mit Zahlen bzw. kurze Codes und den Relationen eines Wanderwegenetzes mit benannten Wegweisern? Die Knotenpunktnetze sollten ja genau die Nachteile der Namen beseitigen, in OSM sind sie nun wieder gleich.

JochenB wrote:

Ich finde es nicht gut, wenn wir Dinge in OSM anders definieren als draußen.

Es gibt keine universelle Definition von "Knotenpunktnetzwerk". Es gibt Beschreibungen, die die gängigste Form als Beispiel angeben. Da es viele andere Varianten gibt, die sich in vielen kleinen Punkten unterscheiden, aber im Wesentlichen das gleiche Funktionssystem verwenden, würde OSM meiner Meinung nach gut daran tun, sich nicht auf eine Implementierung festzulegen.

Knotennetzwerk sagt genau, was es ist: ins Netz verknoten. Jeder, dem die Verwendung von Zahlen wichtig ist, kann diese Implementierung Number Network nennen. In den Niederlanden betonen einige Betreiber, was der Wanderer tun muss: Sie nennen es Auswahlpunkte.

Aufgrund des generischen Tagging-Systems spielt dies für OSM keine Rolle. Diese Implementierungen sind funktionell ähnlich und entsprechen dem Bild eines geknoteten Fischernetzes.
Sie können daher grundsätzlich gleichzeitig und gekoppelt verwendet werden; man kann ein Trip über nummerierte Knoten, Wahlpunkte mit Farben oder Knoten mit Namen planen; wenn sie verbunden sind, funktioniert es und der Unterschied liegt hauptsächlich in der Routenliste für den Benutzer.

JochenB wrote:

Wie kann ich anhand der Daten unterscheiden zwischen Relationen eines klassischen "Knotenpunktnetes" mit Zahlen bzw. kurze Codes und den Relationen eines Wanderwegenetzes mit benannten Wegweisern?

Die Knoten sind Teil der Relationen, nämlich der erste Knoten des ersten Weges und der letzte Knoten des letzten Weges. Damit sind die Informationen verfügbar. Man könnte es auch redundant für alle Relationen separat, oder für die Network Relation taggen, aber warum sollte man das tun, wenn es keinen funktionalen Unterschied macht?

Das Argument die Mitglieder der Relation ranzuziehen finde ich zu einfach. Damit bräuchte ich ja nicht einmal die Fallunterscheidung zwischen altbackener Route und Knotennetzwerk.
Mir ist es herzlich egal wo und wie unterschieden wird, aber es sollte aus den Tags der Relation ersichtlich sein, um welche Art von Knotenbezeichnung es geht. Zahlen, Farben, Namen und Symbole wurden jetzt schon genannt, gibt es noch mehr?

Duvodas wrote:

skyper wrote:

Das geht mit Wanderwegen im Schwarzwald aber leider nicht mit Fahrradwegen. Der Grund ist simple. Die Wanderwege haben am Ziel einen Wegweiser mit Namen. Die Fahrradweg haben aber nur Richtungsangaben ohne Angaben eines Namens am Wegweiser und häufig fehlt am Ziel auch ein Wegweiser. Der Anfang und das Ende bleiben dadurch immer unscharf.

Ich habe auch schon Beispiele gefunden, wo jetzt die einzeln Segment-Relationen in die übergeordneten Relationen eingebaut wurden. Vom Prinzip, ja richtig, allerdings Frage ich mich in wie viele Ebenen von Superroutes wird dann einen europäischen Radwanderweg eintragen wollen. Beim ÖPV gibt es starke Bedenken bei Segment-Relationen aufgrund der zusätzlichen Ebenen, aber vielleicht ist dann `bicycle` und `hiking` ein Türöffner.

Insgesamt fände ich es auf jeden Fall gut, wenn wir einen Tag für die Unterscheidung von Fahren nach Zahlen bzw Fahren nach "Namen" haben.

Ich denke, Peter redet nur von Knotenpunktnetzwerken mit Namen, nicht den von skyper angesprochenen "Radverkehrsnetzen" in Deutschland.

Es gibt:

1) Knotenpunktnetzwerke mit fester Bezeichnung für die Knoten:
-- Nummern
-- Namen

2) Radverkehrsnetze / Zielwegweisung

Hier gehts um 1), über 2) wird u.a. hier diskutiert: https://forum.openstreetmap.org/viewtopic.php?id=72458

Ja, der Unterschied war ja nur gedacht um den Fall zwischen "zu Fuß" und "Rad" in BaWü besser einzuordnen.

Die restlichen Anmerkungen gelten aber für bei Threads, wenn ich den europäischen Radwanderweg durch Schwarzwaldquerweg oder Fernwanderweg Freiburg-Bodensee ersetze. Ich habe jetzt zig destination_sign Relationen für jeden einzelnen Wegweiser, jeweils ein Segment von benannten Wegweiser zu benanntem Wegweiser, dazu dann Superroutes für die einzelnen übergeordneten Ziele (eventuell auch schon in mehreren Relationen verschachtelt, weil das Fernziel die gleiche Strecke wie das nähere Ziel hat) und dann erst kommen die übergeordneten "normalen" Routen á la Fernwanderweg, diese auch schon in einzelne Etappen unterteilt. Habe jetzt vergessen zu zählen, aber vier bis fünf Ebenen von Relationen könnte ich locker erreichen.

skyper wrote:

Ich habe jetzt zig destination_sign Relationen für jeden einzelnen Wegweiser, [...] dazu dann Superroutes für die einzelnen übergeordneten Ziele (eventuell auch schon in mehreren Relationen verschachtelt, weil das Fernziel die gleiche Strecke wie das nähere Ziel hat)

Ich bin nicht sicher, ob ich dich hier richtig verstehen. Wo sind denn solche Relationen angelegt? Kannst du jeweils ein Beispiel zeigen?

In den Niederlanden laufen oft genug 20 Relationen über 1 Straßenabschnitt. ÖPNV-Routen, lange/kurze/Knoten/bevorzugte Fahrradrouten, lange/kurze/Knoten/bevorzugte Fußrouten. Nicht selten folgen 6 Fern- oder Nahwanderwege dem gleichen Weg.

Es gibt keine klare allgemeingültige Hierarchie für cycleways, cyclable paths etc. Ja, das glauben nationale, regionale und lokale Gremien, aber jeder hat seine eigene Idee und, wie soll ich sagen, sie passen nicht immer gut zusammen.

skyper wrote:

Ich habe jetzt zig destination_sign Relationen für jeden einzelnen Wegweiser, jeweils ein Segment von benannten Wegweiser zu benanntem Wegweiser, dazu dann Superroutes für die einzelnen übergeordneten Ziele (eventuell auch schon in mehreren Relationen verschachtelt, weil das Fernziel die gleiche Strecke wie das nähere Ziel hat)

Ich persönlich halte von Relationen vom type=destination_sign nichts... Es ist in der Erfassung zu aufwendig und in der Masse der vorhandenen Wegweiser (z.B. Rad~, Wander~) nicht leistbar das selbst ansatzweise vernünftig zu erfassen...

Ich selbst werde die Finger davon lassen... Das ist aber eine eigene Disskussion...

Sven

Duvodas wrote:

skyper wrote:

Ich habe jetzt zig destination_sign Relationen für jeden einzelnen Wegweiser, [...] dazu dann Superroutes für die einzelnen übergeordneten Ziele (eventuell auch schon in mehreren Relationen verschachtelt, weil das Fernziel die gleiche Strecke wie das nähere Ziel hat)

Ich bin nicht sicher, ob ich dich hier richtig verstehen. Wo sind denn solche Relationen angelegt? Kannst du jeweils ein Beispiel zeigen?

So schnell finde ich leider die konkreten Beispiele nicht (mehr?), Sorry. Eine kurzzeitige Sperre und ein JOSM Ticket später, kann ich nur sagen, dass ich in diesem CS solche kurzen Abschnitte zwischen zwei Wegweisern aus der Etappe des Rheinradweges geschmissen habe, finde sie aber nicht mehr und meine damaligen Änderungen haben gefruchtet, was die Struktur angeht. Sieht jetzt schon viel sauberer aus, wurde aber auch einiges geändert.
Bei den Wanderwegen ist es leider nicht groß anderes.
Daher hier nur ein paar Beispiele für Routen, die von solchen Zerlegungen betroffen sein könnten:

• Der Rheinradweg ist jetzt schon in drei Ebenen. Die Etappen könnten aber durch aus noch in Teile von Stadt zu Stadt unterteilt werden und in Köln dann wohl zusätzlich noch die einzelnen Abschnitts-Relationen von Wegweiser bis Wegweiser als unterste Ebene verwenden. Da bin ich dann bei fünf Ebenen.
  
• Der E1 hat selbst schon drei Ebenen. Eine unterste Ebenen hat aber deckungsgleiche Teilabschnitte mit den "einfachen" Ausschilderungen ([1], [2]). Diese könnten nun aber auch noch in Teile von Wegweiser zu Wegweiser geteilt werden, da wie gesagt, die Wegweiser eigene Namen und Höhenangaben haben. Dachte, das hatte ich auch schon mal entdeckt.
  

Hoffe, das hilft ein bisschen weiter.

Hallo Peter,

ich sehe hier Analogie zu einem klassischen Nichtverstehen zwischen Techniker und Produktmanager. Du

Aber erstmal zur Definition:

Peter Elderson wrote:

JochenB wrote:

Ich finde es nicht gut, wenn wir Dinge in OSM anders definieren als draußen.

Es gibt keine universelle Definition von "Knotenpunktnetzwerk". Es gibt Beschreibungen, die die gängigste Form als Beispiel angeben. ...

Wo genau hast du gefunden, dass dies nur ein Beispiel unter vielen ist?

Ich habe nur die an mehreren Stellen dokumentierte Definition gefunden, nach der Knotenpunktnetzwerke sich auszeichnen durch ein a) Netz mit nummerierte Knoten, an denen b) die Nummern der Nachbarknoten ausgewiesen sind.

Bislang habe ich nach stundenlangen Suchen garnichts gefunden, das einen Hinweis gibt, dass das nur eine unter mehreren möglichen Definitionen des Fachbegriffs ist.

Peter Elderson wrote:

... aber im Wesentlichen das gleiche Funktionssystem verwenden ...

Ich glaube hier liegt der Kern, warum wir nicht zusammen kommen.

Du schaust aus technischer Sicht drauf. Der Technik ist es egal ob kurze Nummern oder lange Zahlen, ob wenige oder viele Ziele. Programmiert ist das nahezu gleich. Das sehe ich auch so.

Die mir einzig bekannte Definition von "Knotenpunktnetzwerk" schaut aber eben nicht aus technischer Sicht drauf. Sie beschreibt die Nutzersicht auf die Wegweisung. Die Grund-Idee ist eben, die Vereinfachung durch kurze Nummern und (in der Regel) nur eine Ziel-Nummer je Richtung. Das ist ein Begriff aus dem Tourismus Marketing, kein technischer.

Die Kern-Funktion eines "Knotenpunktnetzwerks" ist diese Vereinfachung. Nicht der technsiche Aufbau.

Der Begriff kann gar nicht technisch definiert sein. Aus technischer Sicht ist "Knotenpunktnetzwerk" absolut nichtssagend. Ein Netz hat immer Knoten(punkte), sonst wäre es keines. Technisch gesehen könnte man ja alles oder nichts darunter verstehen.

Peter Elderson wrote:

... Da es viele andere Varianten gibt, die sich in vielen kleinen Punkten unterscheiden ... aber warum sollte man das tun, wenn es keinen funktionalen Unterschied macht?

Hier sind wir wieder bei der technischen Sicht versus Nutzersicht.

Aus Nutzersicht empfinde ich es nicht als "kleinere Abweichungen", wenn die beiden Kern-Funktionen eines Knotenpunktnetzwerks ins Gegenteil verkehrt werden. (lange Namen statt kurze Nummern, mehrere lange Zielbezeichnung je Richtung statt eine Ziel-Nummer)

Für die Nutzer der Karten ist ein wesentlicher funktionaler Unterschied, ob er ein Wegweisungssystem nach der außerhalb von OSM bekannten Definition eines Knotenpunktnetzwerks vorfindet, oder eben eine klassische Wegweisung, bei der Wegweiser teils lange Namen tragen.

Wir bauen OSM letzen Endes dafür, dass am Ende Nutzer die Daten nutzen, nicht für - noch so gute - technische Werkzeuge, die die Datenqualität checken.

Peter Elderson wrote:

Knotennetzwerk sagt genau, was es ist: ins Netz verknoten. ...

Nun gut, dass diese hier verwendete Definition von der draußen verwendeten Defintion abweicht ist ja genau das, was ich kritisiere.

Peter Elderson wrote:

... würde OSM meiner Meinung nach gut daran tun, sich nicht auf eine Implementierung festzulegen

Und hier ist halt der dritte wesentliche Dissens. Ich finde es tut OSM gar nicht gut, zwei aus Nutzersicht völlig gegensätzliche Ansätze unter dem selben Namen festzulegen.

Peter Elderson wrote:

JochenB wrote:

Wie kann ich anhand der Daten unterscheiden zwischen Relationen eines klassischen "Knotenpunktnetes" mit Zahlen bzw. kurze Codes und den Relationen eines Wanderwegenetzes mit benannten Wegweisern?

Die Knoten sind Teil der Relationen, nämlich der erste Knoten des ersten Weges und der letzte Knoten des letzten Weges. Damit sind die Informationen verfügbar. Man könnte es auch redundant für alle Relationen separat, oder für die Network Relation taggen, ...

Nun, mit diesem Argument braucht man das 'network:type=node_network' garnicht, denn es lässt sich ermitteln, ob an beiden Enden nummerierte Knoten liegen.

JochenB wrote:

Du schaust aus technischer Sicht drauf. Der Technik ist es egal ob kurze Nummern oder lange Zahlen, ob wenige oder viele Ziele.

Nein, das stimmt nicht. Technisch ist es anders, aber für den Planer und Benutzer ist es das gleiche System. Nur mit Buchstaben statt Zahlen. Man plant eine Trip, und endet mit eine Liste von Knotenpunktlabels. Unterwegs seht man den nächsten Knoten auf die Liste und die Pfeile zeigen die Richtung.

Ich mag auch kurze Zahlen mehr als Namen, aber in manche gebieten sind Namen informativer für den Wanderer.

JochenB wrote:

Nun, mit diesem Argument braucht man das 'network:type=node_network' garnicht, denn es lässt sich ermitteln, ob an beiden Enden nummerierte Knoten liegen.

Dieses Tag wurde eingeführt, weil Datennutzer gebeten haben, Knotenpunktrouten mittels eines Tags eindeutig von anderen Freizeitrouten zu unterscheiden.
Es gibt auch andere nummerierte Knoten, und wenn ein Knotenpunkt fehlt, möchtet man nicht, dass die Route aus der Ansicht und aus und aus den Validierungen verschwindet.

Über die Definition: Dieses System stammt nicht aus Deutschland, sondern aus Belgien, wo eine Mischung aus (vielen) Nummern und (weniger) Namen verwendet wurde. Eine deutsche Organisation ist daher nicht die Quelle einer allgemeingültigen Definition, egal wie wichtig diese Organisation in Deutschland ist.
Unterwegs und im Planer kann das gleiche Netzwerksystem genutzt werden, mit Namen, Codes, Nummern, Farben oder einer Mischung daraus. Dies ist für die Benutzer wichtiger als eine Definitionsfrage.

Ich beende jetzt meine Teilnahme an dieser Diskussion, weil alles oft genug gesagt ist! Ich wünsche Ihnen viel Erfolg beim Ausbau der verschiedenen Netzwerke.

JochenB wrote:

Peter Elderson wrote:

... würde OSM meiner Meinung nach gut daran tun, sich nicht auf eine Implementierung festzulegen

Und hier ist halt der dritte wesentliche Dissens. Ich finde es tut OSM gar nicht gut, zwei aus Nutzersicht völlig gegensätzliche Ansätze unter dem selben Namen festzulegen.

Peter Elderson wrote:

JochenB wrote:

Wie kann ich anhand der Daten unterscheiden zwischen Relationen eines klassischen "Knotenpunktnetes" mit Zahlen bzw. kurze Codes und den Relationen eines Wanderwegenetzes mit benannten Wegweisern?

Die Knoten sind Teil der Relationen, nämlich der erste Knoten des ersten Weges und der letzte Knoten des letzten Weges. Damit sind die Informationen verfügbar. Man könnte es auch redundant für alle Relationen separat, oder für die Network Relation taggen, ...

Nun, mit diesem Argument braucht man das 'network:type=node_network' garnicht, denn es lässt sich ermitteln, ob an beiden Enden nummerierte Knoten liegen.

+1, ja, bitte, eine Unterscheidungsmöglichkeit und klare Definition der Relationen.
Sonst kann ich auch gleich noch auf `network=*` verzichten, denn mit Hilfe der Mitglieder und Eltern ist ja die Länge und auch das Gebiet ermittelbar. 🙄

skyper wrote:

Sonst kann ich auch gleich noch auf `network=*` verzichten, denn mit Hilfe der Mitglieder und Eltern ist ja die Länge und auch das Gebiet ermittelbar.

Ich kann eine so gute Idee nicht ignorieren... wie lang sollte eine Route für l, r, n und i sein?

Und welches Tag wäre nützlich um eine mit ref=nn-mm getaggte Knotenpunktroute von einer ohne ref-Tag unterscheiden?

Fragen, Fragen...

--
(Jetzt zurück in den Winterschlaf)

Peter Elderson wrote:

Ich beende jetzt meine Teilnahme an dieser Diskussion, weil alles oft genug gesagt ist! Ich wünsche Ihnen viel Erfolg beim Ausbau der verschiedenen Netzwerke.

Ist Ok, da es scheinbar nur uns beide interessiert bringt die Diskussion auch wenig.

Es kommen ja auch keine neuen Quellen oder ähnliches, ich hatte darauf gehofft. Ich hatte auch auf belgischen Seiten gesucht und nur etwas gefunden, was meine Aufassung stärkt. Aber da gibt es eine Sprachbarriere.

Man muss sich nicht in allem einig sein. 🙂

...Hintergrundinformationen zu Knotenpunktnetzen in Brandenburg...

Liebe Knotenpunktfreunde...

durch Zufall bin ich bei der TMB (=Tourismus-Marketing Brandenburg GmbH) auf folgende Seite gestoßen: https://www.tourismusnetzwerk-brandenbu … andenburg/

Besonders positiv beeindruckt hat mich dieses pdf: https://www.tourismusnetzwerk-brandenbu … enburg.pdf
Wir als OSM-Gemeinschaft werden da aktiv genannt unsere Daten (hier Netzwerkrelationen) aktiv verlinkt. Das bestärkt mich auch im meiner Meinung, daß nur über OpenData wie wir es umsetzen, solche Dinge verarbeitbar sind. Auch unsere Holländischen Nachbarn haben mit ihrer Seite https://www.knooppuntnet.nl/en/analysis … e/networks einen ganz gewichtigen Beitrag mit dazu geleistet...

Da sieht man, wo die Reise hingeht... Es scheint auch so zu sein, als daß für den Landkreis Potsdam-Mittelmark sich Knotenpunkte materialisieren könnten. Also: Augen auf und bitte drauf achten...

Viele Grüße,

Sven

Streckenkundler
... Hintergrundinformationen zu Knotenpunktnetzen in Brandenburg...

+ 1 🙂

Michael!

streckenkundler wrote:

Auch unsere Holländischen Nachbarn haben mit ihrer Seite https://www.knooppuntnet.nl/en/analysis … e/networks einen ganz gewichtigen Beitrag mit dazu geleistet...

🙂
Diese Ehre geht an vmarc in Belgien und sicherlich auch für seine fantastische Planer-Anwendung. Betreiber können jetzt einfach verlinken und müssen keinen Knotenpunktplaner selbst programmieren.

Hallo Zusammen,

User dx125 hat mir Fotos vom Knotenpunkt 26 in Radewege geschickt. Vielen Dank dafür. Dieser Punkt und eine Handvoll andere Punkte liegen im Landkreis Potdam-Mittelmark, im Amt Beetzses, der bisher kein eigenen Netz hat. Dieses bisher kleines Netz wird sicher im Zusammenhang mit dem Netz Landkreis Havelland entstanden sein.

Ich tendiere dazu, daß man diesen Bereich als eigenes Netz abspalten sollte, auch die bisher in der Stadt Brandenburg liegenden Punkte in Routen würde ich dann in ein eigenenes Netz verschieben. Es scheinen auch hier neue Punkte hinzuzukommen: z.B.: https://www.mapillary.com/app/?pKey=887048998832892

Das würde dann auch mit den Angaben passen, die im pdf dargestellt sind (vg. Beitrag https://forum.openstreetmap.org/viewtop … 84#p847984)

Meinungen?

Sven

streckenkundler wrote:

Hallo Zusammen,

User dx125 hat mir Fotos vom Knotenpunkt 26 in Radewege geschickt. Vielen Dank dafür. Dieser Punkt und eine Handvoll andere Punkte liegen im Landkreis Potdam-Mittelmark, im Amt Beetzses, der bisher kein eigenen Netz hat. Dieses bisher kleines Netz wird sicher im Zusammenhang mit dem Netz Landkreis Havelland entstanden sein.

Ich tendiere dazu, daß man diesen Bereich als eigenes Netz abspalten sollte, auch die bisher in der Stadt Brandenburg liegenden Punkte in Routen würde ich dann in ein eigenenes Netz verschieben. Es scheinen auch hier neue Punkte hinzuzukommen: z.B.: https://www.mapillary.com/app/?pKey=887048998832892

Das würde dann auch mit den Angaben passen, die im pdf dargestellt sind (vg. Beitrag https://forum.openstreetmap.org/viewtop … 84#p847984)

Meinungen?

Sven

Es sind ja doch schon einige Knotenpunkte im Landkreis Potsdam-Mittelmark erfasst. Im Sommer gab es die zumindest im Raum Werder noch nicht, wurden die tatsächlich alle in den letzten Monaten beschildert? Dann sollten die auf jeden Fall ein eigenes Netz bekommen.

klnkengi wrote:

Es sind ja doch schon einige Knotenpunkte im Landkreis Potsdam-Mittelmark erfasst. Im Sommer gab es die zumindest im Raum Werder noch nicht, wurden die tatsächlich alle in den letzten Monaten beschildert? Dann sollten die auf jeden Fall ein eigenes Netz bekommen.

Ich bin mir noch nicht 100%ig sicher... aber... recht aktuelle Mapillary-Bilder z.B. potentielle Nr. 40 https://www.mapillary.com/app/?pKey=2170429203106613 oder Nr. 41 https://www.mapillary.com/app/?pKey=909901273228058 zeigen noch keine Beschilderung...
Im Landkreis PM habe ich außerhalb des Amtes Beetsee noch keine Beschilderung auf Mapillary gesehen. Ich tendiere dazu, erst mal eines für Amt Beetzsee zu erstellen, die restlichen von LK PM mit reinschmeißen und ein proposed:~ davor zu setzen, so wie es in Cottbus ist... Dort gibt es die Knotenpunkte auf dem "Papier" und auf den Karten angrenzender Knotenpunkte, im Stadtgebiet Cottbus ist aber wohl nichts ausgeschildert. Diese Relation kann dann für den gesamten Kreis nachgenutzt werden, in der Annahme, daß das Netz wirklich einsprechend erweitert wird, der Beetzsee-Teil also in den Kreisteil aufgeht...

Dieses proposed:~ wird bei https://www.knooppuntnet.nl/en/analysis … e/networks ausgewertet, auch auf den Karten.
Das wäre für mich derzeit die saubere Lösung.

Sven

streckenkundler wrote:

Ich tendiere dazu, erst mal eines für Amt Beetzsee zu erstellen, die restlichen von LK PM mit reinschmeißen und ein proposed:~ davor zu setzen, so wie es in Cottbus ist... Dort gibt es die Knotenpunkte auf dem "Papier" und auf den Karten angrenzender Knotenpunkte, im Stadtgebiet Cottbus ist aber wohl nichts ausgeschildert. Diese Relation kann dann für den gesamten Kreis nachgenutzt werden, in der Annahme, daß das Netz wirklich einsprechend erweitert wird, der Beetzsee-Teil also in den Kreisteil aufgeht...
Sven

Das klingt doch gut so.

Spätestens im Frühling (... sind ja nur noch ein paar Monate 😄) werde ich bestimmt auch mal ne Runde um den Schwielowsee drehen, so dass ich dann vor Ort schauen kann, ob die Knotenpunkte dort beschildert sind.

klnkengi wrote:

streckenkundler wrote:

Hallo Zusammen,

User dx125 hat mir Fotos vom Knotenpunkt 26 in Radewege geschickt. Vielen Dank dafür. Dieser Punkt und eine Handvoll andere Punkte liegen im Landkreis Potdam-Mittelmark, im Amt Beetzses, der bisher kein eigenen Netz hat. Dieses bisher kleines Netz wird sicher im Zusammenhang mit dem Netz Landkreis Havelland entstanden sein.

Ich tendiere dazu, daß man diesen Bereich als eigenes Netz abspalten sollte, auch die bisher in der Stadt Brandenburg liegenden Punkte in Routen würde ich dann in ein eigenenes Netz verschieben. Es scheinen auch hier neue Punkte hinzuzukommen: z.B.: https://www.mapillary.com/app/?pKey=887048998832892

Das würde dann auch mit den Angaben passen, die im pdf dargestellt sind (vg. Beitrag https://forum.openstreetmap.org/viewtop … 84#p847984)

Meinungen?

Sven

Es sind ja doch schon einige Knotenpunkte im Landkreis Potsdam-Mittelmark erfasst. Im Sommer gab es die zumindest im Raum Werder noch nicht, wurden die tatsächlich alle in den letzten Monaten beschildert? Dann sollten die auf jeden Fall ein eigenes Netz bekommen.

Hallo, ich wollte mich mal kurz melden und etwas zu diesem Thema sagen.

Ich bearbeite gerade im Auftrag der TMB (und des Reiselandes Havelland) einige Radrouten und Knotenpunkte in dessen Gebiet.

Kernpunkt der Arbeit/Auftrages ist die Überprüfung, Korrektur und Optimierung der bestehenden Routen und das Erstellen einiger zusätzlicher fehlender Routen (Rad und Wandern), zusammen mit der Überprüfung der Knotenpunkte. Ich habe dafür eine Liste von der TMB bekommen. Es mag sicherlich noch mehr Routen geben, aber diese sind aktuell jetzt nicht Teil meines Auftrages.

Ich habe ebenso eine Liste der aktuellen Knotenpunkte bekommen, die ich in OSM einpflege, und nach Abschluss (und Freigabe) dann gerne auch an die Holländer weitergebe.
Für mich ist diese Liste ausschlaggebend (und nicht der holländische Datenbestand), da sie direkt vom Urheber kommt, der auch für die Beschilderung vor Ort zuständig ist.
Und ja, es gibt auch ein Knotenpunkt-Netz vom Landkreis PM, da wäre dann tatsächlich zu überlegen on man ein eigenes Netz für diesen Landkreis bildet.
Meine Meinung dazu: ja! Aber ich werde erst mal nichts ändern an der momentanen Zuweisung zum Netz Havelland, solange ich da noch dran arbeite. Wenn es nicht weiter stört, würde ich erst gerne meine Arbeit vollenden und dann hier ein Go! für die Änderung geben.

Ich habe eine ganze Reihe von Knotenpunkten aus PM vorliegen, ich werde aber nur einige wenige projekt-relevante davon bearbeiten (weil halt nur dies Teil des Auftrages ist), werde dann aber auch diese Liste gerne zur Verfügung stellen, wenn der Auftrag abgeschlossen ist.
Wie weit das Knotenpunktnetz vom PM generell fortgeschritten ist, und ob es womöglich vollständig ist weiss ich nicht.

Ich habe bereits zu einigen meiner Änderungssätzen Kommentare bekommen, danke dafür, ich werde mich um alles kümmern, aber ich werde mich wegen alles, was ich hier mache und ändere, an offizielle örtlichen Stellen/Behörden wenden und offizielle Aussagen einholen müssen.
Habt Geduld mit mir :-)

Hei,

Es ist sehr gut, daß gerade was Radrouten und so anbelangt, Dinge auf dem laufenden gehalten werden...

Du musst dir lediglich im Klaren sein, daß auch andere Mapper daran arbeiten können... Du arbeitest ja die Daten direkt in die Hauptdatenbank ein...

Seiten wie 1. https://www.knooppuntnet.nl/en/analysis … e/networks oder 2. https://cycling.waymarkedtrails.org/#?m … 49!12.9109 werten dann diese eingegebenen Daten immer aktuell und ständig aus...

Beispiel... Es dürfte z.B. hier: https://cycling.waymarkedtrails.org/#?m … 99!12.6181die Route zwischen den Knotenpunkten 71 und 72 fehlen... wird diese eingetragen, erscheint diese nach wenigen Minuten bei https://cycling.waymarkedtrails.org/#?m … 99!12.6181 und mit https://www.knooppuntnet.nl/en/analysis/network/6863562
kann man schauen, ob alles in Ordnung ist, ob Wegesegmente fehlen, zuviel sind oder ob z.B. ein bicyle=no ein Routing verhindert.
Bei anderen weiteren Auswertungen und Kartenerstellungen werden diese Informationen im Rahmen ihrer Aktualisierungszyklen auch gleich verwendet. Darum finde ich es gut, und angemessen, sich so schnell und so gut es geht, auch um die Datenpflege zu kümmern.

Eigentlich kann man für die Stadt Brandenburg und für den Landkreis PM jetzt schon die Netze abtrennen... dann hat man fehlende oder Fehlerhafte Dinge besser im Blick...

Wenn du magst, kann ich das am Wochende mal machen... Ich stecke recht Tief in der Knotenpunkt-Materie drin... Das Netz LDS bin ich geschätzt zu 2/3 abgefahren (Auto und Rad) und hab es erfasst. bei den Netzen Elbe-Elster, OSL, und SPN war ich in der Erfassung auch sehr stark beteiligt...

GeoDressingRS wrote:

Habt Geduld mit mir :-)

...Das haben wir. Wir konnten hier bisher jeden helfen... 🙂

OSM-Mantra: "Hier wird dir geholfen, ob du willst oder nicht!" 😄

Viele Grüße,

Sven...

PS: bitte beachten: die ersten drei Beiträge im Forum werden von einem Moderator freigegeben...

Hallo Zusammen,

streckenkundler wrote:

Eigentlich kann man für die Stadt Brandenburg und für den Landkreis PM jetzt schon die Netze abtrennen... dann hat man fehlende oder Fehlerhafte Dinge besser im Blick...

...So... Ich habe zwar etwas länger gewartet, habe die Netze für Stadt Brandenburg an der Havel und Landkreis PM nun als separate Netze abgetrennt.

https://www.openstreetmap.org/changeset … 1&layers=N und https://www.openstreetmap.org/changeset … 7&layers=N

Mal sehen was https://www.knooppuntnet.nl/en/analysis … e/networks nun dazu sagt.

Sven

Im November hatten wir hier darüber gesprochen, wie man an komplizierteren Knotenpunkten die Tentakel anlegt, damit alle Verbindungen am Knotenpunkt sauber miteinender verknüpft sind. Die Diskussion ist dann aber eingeschlafen (Post #248).

Ich habe versucht, das Vorgehen an zwei abstrakten, möglichst einfachen Beispielen ausführlich zu beschreiben. Das könnten wir ins Wiki für Knotenpunktnetzwerke aufnehmen.

Ich bin mir aber nicht sicher: Stimmt das Vorgehen so? Ist der Text verständlich? Kann man es besser formulieren?

Im Prinzip sind es für jede Verbindung am Knoten nur drei Schritte:

• Split-Node taggen
• Fahrweg in Richtung des Knotens in die Relation aufnehmen
• Vom Knoten abgehenden Fahrweg in die Relation aufnehmen (ggf. mehrere Tentakel)

Schaut bitte mal drüber: wiki/User:JochenB/split_nodes

Duvodas hatte es schön kompakt wie folgt beschrieben:

Duvodas wrote:

Es gibt technisch mehrere Knotenpunkte, die im Netz mit der gleichen Nummer ausgezeichnet sind. Das ist häufig an großen Kreuzungen und Brücken der Fall, aber auch an Straßensituationen wie dieser.
Man schaut sich nun jede Knotenpunktroute einzeln an, die mit dem Knotenpunkt verbunden ist, und zwar in dieser Beschreibung gedanklich in Richtung des Knotenpunkts. Die Route wird nun ganz normal für beide Fahrrichtungen bis zum ersten Knoten des split nodes geführt. Zusätzlich müssen von allen anderen Knoten des split nodes aus Verbindungen nur für die Gegenrichtung (die sogenannten tentacles) angelegt werden, die bis zur ersten erreichbaren Stelle einer der folgenden Möglichkeiten geführt werden:
1. dem ersten Knoten
2. einem anderen tentacle
3. einem Punkt der Hauptroute

Anders formuliert: In Richtung des split nodes wird die Route nur bis zum ersten Knoten des split nodes angelegt, in Gegenrichtung aber von allen Knoten des split nodes.

Ich habe das aber bis heute nicht verstanden, vermutlich, weil mir die Begrife nicht klar sind. Ich vermute, dass es auch nicht in allen Fällen funktioniert.

Das komplexe Beispiel aus dem Englischem Wiki entspricht meinem Beispiel 2. Alles nicht Relevante habe ich weggelassen.

Danke!

Hi! (Sorry to use English - no time to translate properly.)
In https://wiki.openstreetmap.org/wiki/Nod … _Nodes_.2A and the following sections, the "CLuster method" is explained. It is substantially more simple than the "tentacle method" in the English wiki. Intermediate solution is the "Closed loop" solution.

Hallo zusammen,

Frage: löscht iD network:type=node_network an Objekten in bestimmten Situationen?

Mir kommt die Frage deshalb, weil ich heute einen Knotenpunkt repariert habe bei dem "network:type=node_network" entfernt wurde, was natürlich ziemliche Folgefehler verursacht hatte. Nach einem Kommentar im betreffenden CS schrieb der Ersteller, daß er bewusst nichts entfernt hat. https://www.openstreetmap.org/changeset/116934878.

Aufgrund der immer wieder auftretenden iD-Probleme und meiner äußersten Reserviertheit dem Editor gegenüber, glaube ich dem User Langlaeufer sofort!!

Ich hoffe, es wird/wurde nicht schon wieder ein systemischer Fehler in iD gerissen, der ewig offen bleibt...

Sven

Ich habe die Id-Preset getestet, sie ist in Ordnung.

Peter Elderson wrote:

Ich habe die Id-Preset getestet, sie ist in Ordnung.

...kann es ein anderes sein? Der User hat an dem Knotenpunkt eine Ampel ergänzt. Wäre es möglich, daß dadurch das passiert ist?

Sven

streckenkundler wrote:

Peter Elderson wrote:

Ich habe die Id-Preset getestet, sie ist in Ordnung.

...kann es ein anderes sein? Der User hat an dem Knotenpunkt eine Ampel ergänzt. Wäre es möglich, daß dadurch das passiert ist?

Sven

Stimmt! Durch Anwenden der Voreinstellung für Ampeln in Id wird das Tag network:type=node_network entfernt.

Peter Elderson wrote:

streckenkundler wrote:

Peter Elderson wrote:

Ich habe die Id-Preset getestet, sie ist in Ordnung.

...kann es ein anderes sein? Der User hat an dem Knotenpunkt eine Ampel ergänzt. Wäre es möglich, daß dadurch das passiert ist?

Sven

Stimmt! Durch Anwenden der Voreinstellung für Ampeln in Id wird das Tag network:type=node_network entfernt.

Danke für die Prüfung...

Ich sag ja...iD hat sein Eigenleben... das nicht gut ist... ein Ticket ist hier zwingend erforderlich...

Grüße,

Sven

Peter Elderson wrote:

Stimmt! Durch Anwenden der Voreinstellung für Ampeln in Id wird das Tag network:type=node_network entfernt

streckenkundler wrote:

Ich sag ja...iD hat sein Eigenleben... das nicht gut ist... ein Ticket ist hier zwingend erforderlich...

Die Frage ist doch, ob Knotenpunkte an Ampel gehören.

Mammi71 wrote:

Peter Elderson wrote:

Stimmt! Durch Anwenden der Voreinstellung für Ampeln in Id wird das Tag network:type=node_network entfernt

streckenkundler wrote:

Ich sag ja...iD hat sein Eigenleben... das nicht gut ist... ein Ticket ist hier zwingend erforderlich...

Die Frage ist doch, ob Knotenpunkte an Ampel gehören.

Kann schon mal vorkommen. Knotenpunkte sind typischerweise an Kreuzungen. Ampeln können auf verschiedene Arten erfasst werden. Die einfachste ist es, den Kreuzungspunkt zu taggen. Wenn da schon ein Knotenpunkt liegt, dann ist das eben so.

streckenkundler wrote:

Peter Elderson wrote:

streckenkundler wrote:

...kann es ein anderes sein? Der User hat an dem Knotenpunkt eine Ampel ergänzt. Wäre es möglich, daß dadurch das passiert ist?

Sven

Stimmt! Durch Anwenden der Voreinstellung für Ampeln in Id wird das Tag network:type=node_network entfernt.

Danke für die Prüfung...

Ich sag ja...iD hat sein Eigenleben... das nicht gut ist... ein Ticket ist hier zwingend erforderlich...

Grüße,

Sven

Naja, ich halte das eher für einen Fehler der Anwendung von ID als von ID selbst. Wenn ich in ID einen Knotenpunkt auswähle, steht oben unter "Objekttyp" "Knotenpunkt des Freizeitnetzes". Wenn ich jetzt unter "Objekttyp" die Voreinstellungen für "Ampel" auswähle, ist ja eigentlich klar, dass der gesamte Objekttyp ersetzt wird und nicht nur zusätzliche Tags hinzugefügt werden. Wenn ich nur zusätzliche Tags für eine Ampel hinzufügen möchte, muss ich das halt unter "Eigenschaften" machen.

klnkengi wrote:

Naja, ich halte das eher für einen Fehler der Anwendung von ID als von ID selbst. Wenn ich in ID einen Knotenpunkt auswähle, steht oben unter "Objekttyp" "Knotenpunkt des Freizeitnetzes". Wenn ich jetzt unter "Objekttyp" die Voreinstellungen für "Ampel" auswähle, ist ja eigentlich klar, dass der gesamte Objekttyp ersetzt wird und nicht nur zusätzliche Tags hinzugefügt werden. Wenn ich nur zusätzliche Tags für eine Ampel hinzufügen möchte, muss ich das halt unter "Eigenschaften" machen.

Ich bin mir da nicht sicher...
Es war nur "network:type=node_network" weg, nicht aber cycle_network, expected_rcn_route_relations und rcn_ref

Sven

streckenkundler wrote:

Ich bin mir da nicht sicher...
Es war nur "network:type=node_network" weg, nicht aber cycle_network, expected_rcn_route_relations und rcn_ref

Sven

Das stimmt, das ist nicht ganz konsequent. Eigentlich müssten diese anderen Tags auch gelöscht werden. Es liegt wohl daran, dass "network:type=node_network" der entscheidende Tag dafür ist, dass ID den Punkt als Objekttyp "Knotenpunkt des Freizeitnetzes" erkennt.

klnkengi wrote:

Das stimmt, das ist nicht ganz konsequent. Eigentlich müssten diese anderen Tags auch gelöscht werden. Es liegt wohl daran, dass "network:type=node_network" der entscheidende Tag dafür ist, dass ID den Punkt als Objekttyp "Knotenpunkt des Freizeitnetzes" erkennt.

Es gib auch hier mehrere Wenn-Dann-Geschichten...
-man könnte sich entscheiden, den straßenbegleitenden Weg separat zu mappen... Dann würde der Knotenpunkt an einen Kreuzungspunkt mit diesem wandern. Ändert hier aber nichts, da die begleitenden Wege für Radfahrer offensichtlich nicht benutzungspflichtig sind.
-man kann die Ampel detaillierter erfassen und bei dieser mit traffic_signals:direction arbeiten. Dann wandert die Ampel-Information weg von dem Kreuzungspunkt hin an die Stellen, wo diese jeweils real steht.

Sven

Hallo zusammen,

ich wollte gerade eine OverpassTurbo-Frage als neuen Beitrag schreiben, da ist mir bei der Vollendung des Beitrages die Lösung eingefallen (nichts geht über trial and error!) ... Die Frage wäre gewesen: "Wie tagabhängige Textbeschriftung?"

Ich oder man stößt ja immer wieder auf Fehler in der Ausschilderung. Zur Erläuterung eignet sich das fixme-Tag ja sehr gut. Ich dachte mir: das mußt du für dich endlich mal visualisieren, denn gerne wird es im Zuge der Bearbeitung ein gelöstes fixme vergessen zu entfernen. Ging mir schon so, denn mir dieser Abfrage hab ich einige Kandidaten ermittelt!
Mit der Abfrage https://overpass-turbo.eu/s/1g6I ermittle ich für mich nun alle Fahrradknotenpunkte und Knotenpunkt-Routen, die ein fixme haben. Nichts geht über eine ordentliche Visualisierung!! Bei Knotenpunkten steht dann nun "Knotenpunkt xy:(fixme-Text)", bei Routen "Route ab-xy:(fixme-Text)". Da es hier im Abfragebereich für mich auf die Darstellung und Beschriftung aller Knotenpunkte ankommt, wollte ich auch diejenigen Knotenpunkte beschriftet wissen, die kein fixme haben... Das leistet erstmal diese Abfrage. Darauf aufbauend kann ich morgen Abend im Zug weiter herumfeilen...

Knotenpunktige Grüße,

Sven

klnkengi wrote:

streckenkundler wrote:

Ich tendiere dazu, erst mal eines für Amt Beetzsee zu erstellen, die restlichen von LK PM mit reinschmeißen und ein proposed:~ davor zu setzen, so wie es in Cottbus ist... Dort gibt es die Knotenpunkte auf dem "Papier" und auf den Karten angrenzender Knotenpunkte, im Stadtgebiet Cottbus ist aber wohl nichts ausgeschildert. Diese Relation kann dann für den gesamten Kreis nachgenutzt werden, in der Annahme, daß das Netz wirklich einsprechend erweitert wird, der Beetzsee-Teil also in den Kreisteil aufgeht...
Sven

Das klingt doch gut so.

Spätestens im Frühling (... sind ja nur noch ein paar Monate 😄) werde ich bestimmt auch mal ne Runde um den Schwielowsee drehen, so dass ich dann vor Ort schauen kann, ob die Knotenpunkte dort beschildert sind.

So, am Sonntag habe ich mal eine Tour nach Werder gemacht, und festgestellt, dass die Knotenpunkte entlang meiner Route alle (noch) nicht ausgeschildert waren. Ich habe sie daher auf "proposed:" gesetzt. Ich habe ja die starke Vermutung, dass das für die anderen Knotenpunkte, die vom gleichen Benutzer im Auftrag der TMB hinzugefügt wurden, ähnlich ist. Sollte man die vorsorglich auch ohne Kontrolle vor Ort erstmal auf "proposed:" setzen?

klnkengi wrote:

Ich habe ja die starke Vermutung, dass das für die anderen Knotenpunkte, die vom gleichen Benutzer im Auftrag der TMB hinzugefügt wurden, ähnlich ist. Sollte man die vorsorglich auch ohne Kontrolle vor Ort erstmal auf "proposed:" setzen?

Ich vermute, daß man da das punktweise abarbeiten müsste... Im Landkreis PM gab es zunächst nur im Amt Beetzsee und dann südlich angrenzend in der Stadt Brandenburg Knotenpunkte. Bei Mapillary hab ich mittlerweile außerhalb dieses Bereiches Knotenpunkte gesehen. proposed:* ist sehr gut. Morgen mehr. Mir fallen die Augen zu... Sven

streckenkundler wrote:

Mit der Abfrage https://overpass-turbo.eu/s/1g6I ermittle ich für mich nun alle Fahrradknotenpunkte und Knotenpunkt-Routen, die ein fixme haben. Nichts geht über eine ordentliche Visualisierung!! Bei Knotenpunkten steht dann nun "Knotenpunkt xy:(fixme-Text)", bei Routen "Route ab-xy:(fixme-Text)". Da es hier im Abfragebereich für mich auf die Darstellung und Beschriftung aller Knotenpunkte ankommt, wollte ich auch diejenigen Knotenpunkte beschriftet wissen, die kein fixme haben... Das leistet erstmal diese Abfrage. Darauf aufbauend kann ich morgen Abend im Zug weiter herumfeilen...

So.. ich habe für mich in Ergänzung zu https://www.knooppuntnet.nl/en/analysis … e/networks erst mal meine ergänzende Prüfung gefunden: https://overpass-turbo.eu/s/1g8v

In meinem Bereich werden alle Knotenpunkte mit Nummer gezeigt, und deren vorhandenen Routen. Gibt es ein fixme, ist es rot, mit entsprechendem Text, ansonsten grün. Ein roter Kreis sagt, daß "expected_rcn_route_relations=*" fehlt.

Sven

streckenkundler wrote:

klnkengi wrote:

Ich habe ja die starke Vermutung, dass das für die anderen Knotenpunkte, die vom gleichen Benutzer im Auftrag der TMB hinzugefügt wurden, ähnlich ist. Sollte man die vorsorglich auch ohne Kontrolle vor Ort erstmal auf "proposed:" setzen?

Ich vermute, daß man da das punktweise abarbeiten müsste... Im Landkreis PM gab es zunächst nur im Amt Beetzsee und dann südlich angrenzend in der Stadt Brandenburg Knotenpunkte. Bei Mapillary hab ich mittlerweile außerhalb dieses Bereiches Knotenpunkte gesehen. proposed:* ist sehr gut. Morgen mehr. Mir fallen die Augen zu... Sven

Was sagt denn die Person, welche das eingetragen hat dazu?
Ich hoffe die verwendete Quelle war auch mit OSM kompatible, ansonsten ist das ja eher ein Fall für "redacted". 🙄

skyper wrote:

Was sagt denn die Person, welche das eingetragen hat dazu?
Ich hoffe die verwendete Quelle war auch mit OSM kompatible, ansonsten ist das ja eher ein Fall für "redacted". 🙄

Hier hat er sich dazu geäußert.
https://www.openstreetmap.org/changeset … 67/12.9508
Da hätte er wohl teilweise eher irgendwas mit "proposed" machen sollen, denn jetzt sind die Knotenpunkte alle in der Karte drin, obwohl er nicht weiß, was davon tatsächlich ausgeschildert ist bzw. wann die Ausschilderung erfolgt. Der Radfahrer erwartet aber eine Ausschilderung, wenn der Knotenpunkt in der Karte verzeichnet ist. Findet er keine Ausschilderung vor, wirft das ein schlechtes Licht auf OSM. (OTG - Regel)
@skyper
du hattest ja schon mal Kontakt 😉
https://www.openstreetmap.org/changeset/116828435
Auftragsmapper, der sein Geschäftsmodell auf OSM aufbaut, aber allergisch reagiert bei Hinweis auf die Regeln von OSM.

dx125 wrote:

Der Radfahrer erwartet aber eine Ausschilderung, wenn der Knotenpunkt in der Karte verzeichnet ist. Findet er keine Ausschilderung vor, wirft das ein schlechtes Licht auf OSM. (OTG - Regel)

Sowas ist sicher ein arges Dilemma. Haben wir in und um Cottbus auch. Im Landkreises Spree-Neiße wird auf Knotenpunkten in der Stadt Cottbus verwiesen, auf den Karten am Wegweiser sind sie für das Stadtgebiet Cottbus auch ausgewiesen, aber OTG nicht. Hier existeren sie erstmal teilweise als proposed. Das wird auch so von knoppuntnet.nl ausgewertet. Das empfehle ich auch für den Landkreises Potsdam-Mittelmark! Ich hab ja Mailkontakt zur TMB, ich werde das Thema mal vorsichtig angehen.

Sven

dx125 wrote:

https://www.openstreetmap.org/changeset … 67/12.9508
Da hätte er wohl teilweise eher irgendwas mit "proposed" machen sollen, denn jetzt sind die Knotenpunkte alle in der Karte drin, obwohl er nicht weiß, was davon tatsächlich ausgeschildert ist bzw. wann die Ausschilderung erfolgt. Der Radfahrer erwartet aber eine Ausschilderung, wenn der Knotenpunkt in der Karte verzeichnet ist. Findet er keine Ausschilderung vor, wirft das ein schlechtes Licht auf OSM. (OTG - Regel)

+1,
Mal wieder ein Beispiel wie "Mappen im Auftrag" nicht funktioniert.

dx125 wrote:

@skyper
du hattest ja schon mal Kontakt 😉
https://www.openstreetmap.org/changeset/116828435
Auftragsmapper, der sein Geschäftsmodell auf OSM aufbaut, aber allergisch reagiert bei Hinweis auf die Regeln von OSM.

Ich habe versprochen mich in diesem Fall ruhig zu verhalten. Gibt wohl einige Baustellen, sowohl was das Verhalten als auch die Umsetzung angeht, aber ich warte jetzt einfach mal ab und hoffe, dass das andere Personen klären. 🙂

Stadt Brandenburg an der Havel...

User itchybellybutton hat hier: https://www.openstreetmap.org/note/3085480 dankenswerterweise zwei Bilderlinks zu Wegweisern in der Stadt Brandenburg gesendet, wo ich mir das mal in Ruhe und im Detail mir anschauen konnte... Dort sind die Verweise zu den Knotenpunkten anscheinend überwiegend in ein eigendes städtisches Wegweisersystem eingebettet (auf Havelradweg o.ä. basierend?)
Das macht es hingehen wiederum schwierig, saubere Routen von A nach B zu erfassen...

Aber nun weiß ich aber endlich, worauf man da achten muß... Auf dem Richtungswegweiser ist in gleicher Größe wie das Icon zum Themenradweg auch das zum nächsten Knotenpunkt: https://www.mapillary.com/app/?pKey=1184588098712759

Leider ist dann mapillary von der Bildqualität wiederum oft zu Schlecht, als daß man immer die nötigen Details erkennen kann...

Uhi... das wird schwierig...

Sven

Hi Sven,

hier ein Bild zum Wegweiser vor dem Pauli Kloster: https://ibb.co/sFHKyqb
Genauer Ort des Wegweisers: https://www.openstreetmap.org/node/9641214830

Da die Quali eher Mau ist, kurz beschrieben welche Symbole darauf sind.
Gen Kirchmöser -> Telegrafenradweg; Tour Brandenburg; Havelradweg; Historische Stadtkernroute 4; Fontane Rad; Storchenradweg; Knotenpunkt 20
Gen Potsdam -> Historische Stadtkernroute 4; Havelradweg; Tour Brandenburg; Fontane Rad; Knotenpunkt 19; Telegrafenradweg

Ich bin etwas verwirrt, warum der Storchenradweg dort ausgeschildert ist. Laut der Stadt führt dieser dort nicht entlang. Zudem ist er nur in eine Richtung ausgeschildert. Heißt es, in dieser Richtung geht es zum Storchenradweg? Allerdings laut HBR Brandenburg:

Wenn, beispielsweise an einem Bahnhof oder Parkplatz, der Weg zu einer Radroute ausgewie-
sen werden soll, wird das Routenpiktogramm mit einer gestrichelten Linie eingerahmt. Somit
werden dem Radfahrer der Weg zur Radroute und die Information, dass er sich noch nicht auf
der Radroute befindet, vermittelt. Hintergrund ist, dass die Routenlogos nur für Beschilderungen
auf der tatsächlichen touristischen Radroute genutzt werden dürfen.

Ich erkenne jetzt keine gestrichelte Linie auf dem Bild und wüsste auch nicht, dass dort eine war.

Wenn das Wetter wieder besser wird, suche ich gerne weitere Schilder und schick sie dir privat bei OSM, wenn du das möchstest.

@itchybellybutton

Danke... !

Schicke alles was irgendwie helfen kann... Ich wurschltele mich da dann durch...

Wenn du da hinkommst, achte auch mal auf südlich angenzendes Potsdam-Mittelmark... Da stehen mittlerweile auch einige Knotenpunktwegweiser, ist anscheinend gerade im Aufbau.
Bei Karten wie https://www.dein-havelland.de/fileadmin … n_2021.pdf sind die Knotenpuntemit "*" mit vorsicht zu genießen, da kann es Abweichungen geben.

Dankende Grüße,

Sven

Hallo Knotenpunktfreunde,

Es gibt Neuigkeiten. Ab Juni startet der Aufbau des Netzes in der Stadt Cottbus:
https://www.cottbus.de/mitteilungen/202 … eiser.html

Vielen Dank @MaGIStokrat für die Information.

Ich glaube, das wird ein ziemlicher Kanten an Arbeit. Dann wird aber auch das Netz Spree-Neiße westentlich fehlerfreier.

Zum Glück gibt es im Cottbuser Raum einige Mapper, die eingebunden werden können.

Sven

Im Kreis Minden-Lübbecke (NRW) wird auch seit ungefähr Jahresbeginn auf ein Knotenpunktnetz umbeschildert.

bus-mt wrote:

Im Kreis Minden-Lübbecke (NRW) wird auch seit ungefähr Jahresbeginn auf ein Knotenpunktnetz umbeschildert.

...Dann kennst du ja deine nächste Aufgabe.. 😄

Gute Tips aus eigener Erfahrung: alle neuen Knotenpunkt-Wegweiser mit Geo-Koordinaten fotografieren und wenn es die Technik hergibt, auch mit Kompass-Richtung. Auch Mapper in der Umgebung mit einbeziehen und um Fotos bitten. Das hilft im Nachhinein sehr, die Daten nachzuvollziehen. Das hilft auch die Routen der oft gleichzeitig beschilderten Themenradrouten nachzuvollziehen. Es kann sein, daß im Zuge der Knotenpunktnetzbeschilderung solche Themenradrouten hin und wieder mal umverlegt werden.

Ach noch eines: rechne mit Ausschilderungsfehler. Sowas bleibt nicht aus. Bitte gut dokumentieren und an den entsprechenden Verantwortlichen des Landkreises weiterleiten. In meinem Landkreis Dahme-Spreewald habe ich dahingehend bei der Erfassung sehr gute Erfahungen gemacht...

Sven

Ich hab mich mal dran versucht: Netzwerk-Relation, erste Route. Und natürlich gleich einen Sonderfall erwischt, der Start-Knoten ist ein Kreisverkehr. Muss ich den aufteilen oder kann der einfach als erster Way in die Route rein?

bus-mt wrote:

Muss ich den aufteilen oder kann der einfach als erster Way in die Route rein?

als erster way reicht...

Maß der Dinge ist für mich https://www.knooppuntnet.nl/en/analysis … k/14195076 Wenn die Route da fehlerfrei angezeigt wird, ist es in Ordnung.
Ich selbst nehme die Knotenpunkte auch mit in die Routen-Relation auf. JOSM nörgelt da zwar rum, das ignoriere ich aber. Vor allem bei der Erfassung eines Netzes und auch später bei einer Fehlerbearbeitung erleichtet es das Editieren. (Als Gimmick könnte auch der Wegweiser mit rein, das mache ich aber nicht konsequent.)

Mein einigermaßen Referenz-Kreisverkehr mit Knotenpunkt ist in meiner Nachbarstadt: https://www.openstreetmap.org/#map=19/5 … 2&layers=N

Vielleicht äußert sich auch noch Peter Elderson dazu.

Viele Grüße,

Sven