Knotenpunktnetzwerke

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…)

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?

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 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.

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.

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 :slight_smile:

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 :wink:)

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.)

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).

… 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…

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.

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.

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.

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.

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.

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.

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…) :wink:

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: …

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

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.

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.

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.

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.

(The Belgian forum has just discussed this again). Here is (slightly edited) what I posted:

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/#search?query=enschede&map=14!52.2936!7.0487
https://knooppuntnet.nl/nl/map/hiking#6cid37-1sxwo4a-1af08on-5777a2

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.

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).

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?

https://cycling.waymarkedtrails.org/#?map=16!52.7525!12.1056
https://knooppuntnet.nl/en/analysis/changeset/113364774/4786928

Gruß
Ainadilion