RadNETZ Baden-Württemberg

Hallo zusammen,

das könnte evt. in Richtung dieses Themas gehen: https://forum.openstreetmap.org/viewtopic.php?id=72458

Sven

Hallo Rainer,

Ich mappe vor allem im Westen von BW das gesamte beschilderte Radwegenetz und damit auch das RadNETZ. Ich erstelle dabei jeweils eine Relation zwischen den Knotenpunkten des Netzwerkes, also zwischen jedem Wegweiser mit 3 oder mehr Richtungsangaben. Dabei unterscheide ich über das Tag cycle_network an den Relationen zwischen Wegabschnitten, die zum RadNETZ gehören (cycle_network=DE:BW:RadNETZ) und Abschnitten, die zum Kreisnetz gehören (z.B. cycle_network=DE:BW:OG). Siehe zum Beispiel diese Overpass-Abfrage: https://overpass-turbo.eu/s/1fFN (rot RadNETZ, grün Kreis-Netz)

Da ich die RadNETZ-Verbindungen zwischen den größeren Orten nicht zusätzlich als Route hinzufügen wollte, habe ich zwischen den Knotenpunkten des RadNETZes Superrouten erstellt, denen dann die Routen-Abschnitte zwischen den Wegweisern untergeordnet sind. Vielleicht keine elegante Lösung, aber ich habe das vor allem gemacht, damit nicht noch mehr Relationen an den Wegen hängen, aber auch weil ich finde, dass die RadNETZ-Abschnitte keine Routen im klassischen Sinne sind. Man erkennt sie wie du schon geschrieben hast eigentlich nur durch die Aufkleber an den Wegweiserpfosten und ab und zu mal einer Bodenmarkierung, aber man weiß jetzt nicht in welche Richtung das RadNETZ weitergeht.

So eine Superroute wäre z.B. die hier: https://cycling.waymarkedtrails.org/#ro … 168/8.2204

Es sind übrigens deutlich mehr Abschnitte gemappt, als die, die du aufgelistet hast. Es gibt da so eine Sammelrelation: https://www.openstreetmap.org/relation/9481353
Bin ich eigentlich auch kein Fan von, aber ich habe die Wege, die ich erfasst habe, bisher immer dort eingepflegt.

Grüße,
Leon/Karthoo

Hallo Leon,

Karthoo wrote:

Ich erstelle dabei jeweils eine Relation zwischen den Knotenpunkten des Netzwerkes, also zwischen jedem Wegweiser mit 3 oder mehr Richtungsangaben.

Mir ist das, wie schon geschrieben, zu aufwändig. Aber vielleicht überschätze ich den Pflegeaufwand ja.

Karthoo wrote:

Es sind übrigens deutlich mehr Abschnitte gemappt, als die, die du aufgelistet hast.

Mein Fehler, ich hatte nur nach type=route gesucht, da sind die Superrouten natürlich durchs Raster gefallen.

Mir geht es unter anderem darum, dass die RadNETZ-Strecken in meiner Gegend in OSM als solche erfasst sind, sich in ein landesweites Konzept einfügen und insbesondere bei Abfragen vom Typ "alle Wege des RadNETZ BW" mit berücksichtigt werden. Ich sehe, dass das wohl nur über Abschnittsrelationen geht. Ein gangbarer Ansatz wäre für mich, zunächst die betroffenen Strecken als Relation zu erfassen, d.h. erst mal nicht die Teile der Landkreisnetze, die nicht zum RadNETZ gehören.

Gruß
Rainer

rainerU wrote:

Ein gangbarer Ansatz wäre für mich, zunächst die betroffenen Strecken als Relation zu erfassen, d.h. erst mal nicht die Teile der Landkreisnetze, die nicht zum RadNETZ gehören.

Wäre doch schon mal ein Anfang und besser, als dass das RadNETZ gar nicht erfasst ist. Das kann man dann nach und nach erweitern. So habe ich das auch gemacht.

rainerU wrote:

Mir geht es unter anderem darum, dass die RadNETZ-Strecken in meiner Gegend in OSM als solche erfasst sind, sich in ein landesweites Konzept einfügen und insbesondere bei Abfragen vom Typ "alle Wege des RadNETZ BW" mit berücksichtigt werden. Ich sehe, dass das wohl nur über Abschnittsrelationen geht.

Ich finde, dafür ist das Tag cycle_network= perfekt geeignet. Ob man jetzt die Variante mit den Teil-Relationen zwischen den Wegweisern verwendet, darüber kann man sich noch streiten, jedenfalls haben der Benutzer @Peilscheibe und ich damit schon einen recht großen Teil des RadNETZes in der Mitte und im Westen von BW erfasst.

Grüße,
Leon/Karthoo

Karthoo wrote:

Ich finde, dafür ist das Tag cycle_network= perfekt geeignet. Ob man jetzt die Variante mit den Teil-Relationen zwischen den Wegweisern verwendet, darüber kann man sich noch streiten, jedenfalls haben der Benutzer @Peilscheibe und ich damit schon einen recht großen Teil des RadNETZes in der Mitte und im Westen von BW erfasst.

Die Verbindungen, welche du mit den Teil-Relationen zwischen den Wegweisern abdeckst, gehören nach meinem Verständnis sowohl zum Kreisnetz als auch zum RadNETZ BW, zumindest aus Sicht des Nutzers. Man müsste daher bei diesen Relationen
cycle_network=DE:BW:RadNETZ;DE:BW:<landkreis> setzen oder eine zweite Relation anlegen mit cycle_network=DE:BW:<landkreis>. Andernfalls werden diese Verbindungen bei Abfragen und Auswertungen, die sich auf das Kreisnetz beziehen, nicht berücksichtigt. Da Mehrfachwerte mit Semikolon nicht von allen Datennutzern ausgewertet werden und Doppelung von Relationen nicht besonders elegant ist, würde ich für meinen Teil diese Verbindungen als Teil des Kreisnetzes erfassen und die RadNETZ-Verbindungen zwischen den größeren Orten als einfache Routenrelationen mit cycle_network=DE:BW:RadNETZ.

Auf jeden Fall, bitte keine weiteren network-Sammelrelationen mit Wegen als Mitglieder. Auch auf die Sammlung aller (Super)Routen in einer network Relation kann auch verzichtet werden, da das mMn durch Tags der Routen ausgedrückt werden kann, aber damit kann ich noch leben. Die Sammlung aller Straßenbahnlinien in Freiburg i.Br habe ich auf jeden Fall vor einiger Zeit gelöscht.

Was das RadNETZ an sich angeht, finde ich es sehr schwierig, dass "on the ground" nachzuvollziehen. Ja, sehr vereinzelt finde ich Markierungen auf dem Asphalt. Aufkleber an den Stangen der Wegweiser finde ich selten und sie sind leicht überklebt. Hat es hier nicht für ein neues Schild am Wegweiser gereicht? So wie es für mich aussieht, ist das ein Versuch auf dem lokalen Netz ein paar Hauptverbindungen hervorzuheben, ohne sich die Mühe zu machen, dass auch so zu beschildern.
Der Start und das Ende der Abschnitt ist dann auch willkürlich, was mich ja auch schon beim lokalen Netz von Relationen abhält.

Ja, wir können weiterhin Sammelrelationen erstellen oder auch die Wander- und Radwege in jeweils Relationen zwischen einzelnen Wegweisern zerlegen und dann zig Level von Superrouten darüber bauen, aber macht das Sinn? Ist es mit ein bis zwei Tags an den Wegen nicht auch getan, wie es mit `lcn=yes` vor langer Zeit vor den Sammelrelationen auch funktioniert hat?

Nebenbei, woher habt ihr die Informationen? Habt Ihr die Wege alle abgefahren oder gibt es frei Daten?

Zum Schluss stelle ich mir noch die Frage, wie viel Nutzen diese Information mir gerade bringt. Da es fast nicht ausgeschildert ist, kann ich vor Ort mich daran auch nicht orientieren und es bleibt wohl nur das Abfahren der Spur (gpx). Das was in Freiburg in Bruchstücken erkennbar ist, bietet mir auch nicht mehr Anreiz, sondern im Gegenteil, ist weder eine schöne, ruhige, schnell oder sichere Strecke. Wenn dann ist es eventuell noch eine direkte Verbindungen zwischen denn einzelnen Städten, aber sobald eine Überspringen will, habe ich vielleicht keine Lust den Umweg durch die Innenstadt dazwischen, mit all den Ampeln, zu machen.

https://www.openstreetmap.org/relation/11917818
https://www.openstreetmap.org/relation/11719968

rainerU wrote:

das RadNETZ Baden-Württemberg ist ein landesweites Netz alltagstauglicher Fahrradverbindungen.

rainerU wrote:

Dass ein Weg zum RadNETZ gehört, ist vor Ort nur an auf der Fahrbahn angebrachten RadNETZ-Logos zu erkennen Beispiel (Mapillary).

Scheint wirklich sehr alltagstauglich zu sein, dieses RadNETZ, wenige Meter weiter (Beidrichtungsradweg!):
https://www.mapillary.com/app/?pKey=135 … ocus=photo
Deshalb wurde dort wahrscheinlich inzwischen ein Fußwegschild aufgestellt, rechts neben dem Ampelmast, die Radfahrerin macht auch einen etwas unschlüssigen Eindruck:
https://www.mapillary.com/app/?pKey=919 … ocus=photo
Das "RadNETZ Alltag" (rote Linie in der offiziellen Karte) und die Bodenmarkierung verweisen aber weiterhin auf diesen Weg...

skyper wrote:

Nebenbei, woher habt ihr die Informationen? Habt Ihr die Wege alle abgefahren oder gibt es frei Daten?

Ich gehe mal davon aus, du willst mit dieser Frage nicht andeuten, da würden Daten aus nicht ODbL-kompatiblen Quellen übernommen. Was mich betrifft, so kartiere ich nur Wegweiser und Verbindungen, die ich abgefahren habe oder von denen es aktuelle Mapillary-Fotos gibt. Die Wegweiser des RadNETZes und damit die sich daraus ergebenden Verbindungen im Stadtkreis Ulm und im Alb-Donau-Kreis identifiziere ich neben dem Aufkleber anhand dem Zeitpunkt, zu dem sie aufgestellt wurden. Die Wegweisung des ADK wurde vor zwei Jahren komplett erneuert, mit Ausnahme der Wegweiser entlang der RadNETZ-Verbindungen. Diese wurden erst in den letzten Monaten hinzugefügt und sind somit leicht identifizierbar. Ähnlich ist es in der Stadt Ulm. Dort gibt es eine ziemlich alte Radwegweisung und auch dort wurden die RadNETZ-Wegweiser erst kürzlich montiert.

rainerU wrote:

skyper wrote:

Nebenbei, woher habt ihr die Informationen? Habt Ihr die Wege alle abgefahren oder gibt es frei Daten?

Ich gehe mal davon aus, du willst mit dieser Frage nicht andeuten, da würden Daten aus nicht ODbL-kompatiblen Quellen übernommen.

Das wäre leider zumindest im Regierungsbezirk Freiburg nichts neues, wenn es um Fahrradrouten geht.

rainerU wrote:

Was mich betrifft, so kartiere ich nur Wegweiser und Verbindungen, die ich abgefahren habe oder von denen es aktuelle Mapillary-Fotos gibt. Die Wegweiser des RadNETZes und damit die sich daraus ergebenden Verbindungen im Stadtkreis Ulm und im Alb-Donau-Kreis identifiziere ich neben dem Aufkleber anhand dem Zeitpunkt, zu dem sie aufgestellt wurden. Die Wegweisung des ADK wurde vor zwei Jahren komplett erneuert, mit Ausnahme der Wegweiser entlang der RadNETZ-Verbindungen. Diese wurden erst in den letzten Monaten hinzugefügt und sind somit leicht identifizierbar. Ähnlich ist es in der Stadt Ulm. Dort gibt es eine ziemlich alte Radwegweisung und auch dort wurden die RadNETZ-Wegweiser erst kürzlich montiert.

Ja, so ähnlich mache ich das auch. Zuerst die Wegweiser inklusive destination_sign-Relationen erfassen und dann diese den vorhandenen Relationen zuordnen. Bei mir sind das in erster Linie die zusätzlichen Routen, da ich mir wie gesagt beim Anfang und Ende der Teile des lokalen Netzes zu unsicher bin und mir genügt eigentlich auch das `lcn=yes` bzw. `lwn=yes` an den einzelnen Wegen.
In Freiburg, werden gerade alle Wegweiser erneuert und aufs RadNETZ gibt es kaum Hinweise. Werde nachher mir einnige Wegweiser noch mal genauer anschauen. Insgesamt fehlen noch sehr viele Wegweiser in den OSM Daten und was mich stutzig macht, noch mehr fehlen in den Relationen, allenvoran in denen des RadNETZ.

Hallo Leute,
Ich wollte ich auch kurz mal zu der Sache melden. Ich finde es gibt ein paar wesentliche Punkte, auf die wir uns einigen sollten.
- Werden die einzelnen Relationen nach fiktiven Streckenverläufen oder nach Stadt- oder Landkreisen geordnet
- Ob oder wie werden die Wegweiser in die Relationen aufgenommen
- allgemeine Regeln für die Farben, Namen, Aufbau der Tags
- network oder route für die Überrelationen
Ich bin zwar nicht mehr so aktiv beim Mappen dabei, jedoch helfe wo ich kann, falls die Relationen irgendwie umstrukturiert werden müssen.

Gruß Pfefferdose

Die Diskussion auf mein Proposal wurde ja schon verlinkt. Mit 'network:type=basic_network' kann man diese Routen von den Themenrouten unterscheiden.

Das alleinige Verwenden von 'cycle_network=DE:BW:RadNETZ' reicht noch nicht, da diese Grundnetze in jedem Bundesland anders heißen. Allerdings ist das eine gute Methode, um Hierarchien darzustellen. 'ref=*' sollte dagegen nicht verwendet werden, weil die Verbindungen zwischen den Knoten ja nummern- und namenslos sind.

Ich habe gerade andere Prioritäten, drum ruht das Proposal zur Zeit. Ich muss es mit anderer Beschreibung nochmal versuchen, der Text war unglücklich für Leute, die nicht in der Materie stecken. Allerdings scheint der Bedarf der Anwendung groß zu sein, es wird bereits reichlich angewendet.

Sollte im Proposal-Diskussion ergeben, dass man ein neuen Key erfinden soll, so kann man das später leicht ändern.

Pfefferdose wrote:

Hallo Leute,
Ich wollte ich auch kurz mal zu der Sache melden. Ich finde es gibt ein paar wesentliche Punkte, auf die wir uns einigen sollten.

+1

Pfefferdose wrote:

- Werden die einzelnen Relationen nach fiktiven Streckenverläufen oder nach Stadt- oder Landkreisen geordnet
- Ob oder wie werden die Wegweiser in die Relationen aufgenommen
- allgemeine Regeln für die Farben, Namen, Aufbau der Tags
- network oder route für die Überrelationen

Da sprichst Du wichtige Punkt an, wobei Du ja schon genau das Problem beschreibst, dass es eben keine exakten Start- und Endpunkte gibt, was für mich gegen Relationen spricht.
Bitte keine route-Relationen als Mitglieder von route-Relationen, das ist nicht definiert. Entweder `superroute` oder `network`.

Ich habe inzwischen einige RadNETZ-Verbindungen als route-Relationen erfasst:

https://www.openstreetmap.org/relation/13759156
https://www.openstreetmap.org/relation/13759980
https://www.openstreetmap.org/relation/13761984

Ich werde es erst mal dabei belassen und nur noch die im Rahmen des RadNETZ-Ausbaus hinzukommenden Wegweiser erfassen. Diese Wegweiser kennzeichne ich mit cycle_network=DE:BW:RadNetz, sofern sie durch einen Aufkleber erkennbar als zum RadNETZ gehörend markiert sind.

Das RadNETZ BW ist aus meiner Sicht, abgesehen von kleinen Aufklebern an den Pfosten der Wegweiser und spärlichen Logos auf der Fahrbahn, kein OTG erkennbares Netz. Sieht man von verwaltungsinternen Dingen ab, wie der Zuständigkeit für die Planung und Montage der Wegweiser, der mutmaßlichen Kostenbeteiligung des Lands an Ausbau und Unterhalt der betroffenen Wege, sehe ich in diesem Netz keinen praktischen Nutzen für die Radfahrer. Alle Wege, über die das Netz führt, sind auch Teil des jeweiligen lokalen Radverkehrsnetzes, zumindest dort wo ich das beurteilen kann. Diese Wege können somit auf Karten gekennzeichnet und von Routern bevorzugt verwendet werden, auch wenn sie in OSM nicht als Teil des RadNETZ BW erfasst sind.

Das spricht natürlich alles nicht dagegen, dieses Netz trotzdem in OSM zu erfassen, irgendwie existiert es ja doch. Da es für solche Netze derzeit kein akzeptiertes Tagging-Schema gibt, werde ich das aber nicht machen. Das Proposal von JochenB enthält zwar ein paar gute Ansätze, z.B. das Tag cycle_network=*, seine Umsetzung scheitert aber daran, dass es auf route-Relationen für Verbindungen aufbaut, die es OTG nicht gibt. In der Praxis führt das zu einer Vielzahl von Klein- und Kleinst-Relationen zwischen benachbarten Wegweisern, von denen viele nur aus zwei Wegweisern und einem oder zwei Wegen bestehen. Der damit verbundene Pflegeaufwand erscheint mir in Relation zum Nutzen viel zu hoch.

Mmh, dann brauchen wir aber mehrere Werte für `cycle_network=*` an einem Wegweiser und ich weiß nicht ob es dadurch besser wird. Reicht es nicht, die Information in der Relation zu haben und die Wegweiser in die Relation mitaufzunehmen? Ein `cycle_network=DE:BW:RadNetz` am Wegweiser ist m.E. zu wenig, wenn Du schon schreibst, dass sich das RadNETZ auf das lokale Grundnetz aufbaut.
Von den einzelnen Kleinstsegmenten als Relationen und darüber superroute halte ich auch nicht viel und würde eine Unterteilung nur da verwenden, wo es Sinn macht, aber bestimmt nicht an jedem Wegweiser. Beim ÖPV befindet sich ähnliches bissher auch nur in den Kinderschuhen und ein wirklich überzeugendes Konzept habe ich auch noch nicht gefunden.

Eine viel zwingendere Frage ist die nach den Quellen und nach OTG. Da ich in meiner Gegend leider keine Quellenangaben in den CS finde habe ich mal direkt nachgefragt. Solange halte ich hier mal die Räder still.

rainerU wrote:

seine Umsetzung scheitert aber daran, dass es auf route-Relationen für Verbindungen aufbaut, die es OTG nicht gibt

Das verstehe ich nicht. Im deutschen Wiki steht zu Relation:route:

Eine Route ist eine vorgegebene und oft öffentlich ausgeschilderte Strecke, die über verschiedene Abschnitte führt und regelmäßig von Fahrzeugen oder Personen genutzt wird.

Die Fahrradwegweiser schildern OTG öffentlich eine Strecke zum Radfahren aus. Damit sind m. E. die wesentlichen Kriterien für eine Route erfüllt.

Im Wiki steht nichts davon, dass Beginn und Ende OTG als solche ausgeschildert sein müssen, warum auch? Bei einer Rundtour gibt es z. B. systembedingt kein Beginn und Ende.

Das soll uns aber nicht davon abhalten, Vorschläge zu machen, wo wir Routen sinnvollerweise beginnen und enden lassen. In meinem Proposal habe ich das bewusst offengelassen, weil es im Kern nur um die Unterscheidung zwischen Themenroute und Verbindung im ausgeschilderten Netzwerk geht. Insofern kann das Proposal nicht daran scheitern, weil das garnicht Teil des Proposals ist 😉 .

Ein möglicher Vorschlag ist, die Routen i.d.R. dort enden zu lassen, wo sich Strecken verzweigen. OTG ist das zu erkennen an den Wegweisern, die in mehr als 2 Richtungen zeigen. Aber das muss man auch nicht so machen. Gerade um superkurze Relationen zu vermeiden kann man diese auch eine andere längere mit dranhängen. Ich sehe keine gravierenden Nachteile. Damit könnte man auch deiner Sorge entgegenwirken:

rainerU wrote:

In der Praxis führt das zu einer Vielzahl von Klein- und Kleinst-Relationen zwischen benachbarten Wegweisern, von denen viele nur aus zwei Wegweisern und einem oder zwei Wegen bestehen.

Oder?

rainerU wrote:

Der damit verbundene Pflegeaufwand erscheint mir in Relation zum Nutzen viel zu hoch.

Find ich nicht. Bei Knotenpunktnetzwerken gehen wir ähnlich vor und es ist wunderbar strukturiert und gut pflegbar.

Unpflegbar sind für mich die entstandenen Riesenrelationen, wo alle Verbindungen eines Kreises gesammelt wurden, teils mit 3.000 Mitgliedern und mehr. Und wie gesagt, mit der Möglichkeit des "Dranhängens" kann man die Anzahl kurzer Relationen auch überschaubar halten.

In Deutschland wird Radwegweisung i.d.R. entsprechend der Hinweise der FGSV ausgeführt. Dort verlaufen Themenradrouten (Symboleinschübe) immer über das ausgeschilderte Radverkehrsnetz (Zielwegweiser). Genauso bei Verbindungen von Knotenpunktnetzwerken.

Insofern können wir auch in OSM annehmen, dass Radrouten und Knotenpunktnetzwerkverbindungen standardmäßig Teil des Radverkehrsnetzes sind. Dort müssen wir das Radverkehrsnetz nicht nochmal als Route mappen.

Es sollten dann nur noch die Ausnahmen als solche gekennzeichnet werden, also die Themenrouten, die das Radverkehrsnetz verlassen, z. B. mit 'basic_network=no'. Das wäre z. B. der Fall wenn eine Themenroute nur mit Aufklebern an Bäumen markiert wurde und nicht dem mit Zielwegweisern ausgewiesenem Radverkehrsnetz folgt.

edit: typo

JochenB wrote:

ich nicht. Im deutschen Wiki steht zu Relation:route:

Eine Route ist eine vorgegebene und oft öffentlich ausgeschilderte Strecke, die über verschiedene Abschnitte führt und regelmäßig von Fahrzeugen oder Personen genutzt wird.

Die Fahrradwegweiser schildern OTG öffentlich eine Strecke zum Radfahren aus. Damit sind m. E. die wesentlichen Kriterien für eine Route erfüllt.

Das bestreite ich nicht. Es ging mir darum, dass das durchaus Wiki-konforme Verwenden von Routen in diesem Fall zu Problemen führen kann.

So wollte ich die RadNETZ-Verbindung Ehingen - Ulm-Donautal erfassen. Im Stadtgebiet Ehingen gibt es bereits für einen Teil des Radwegenetzes lcn-Relationen. Das Tagging entspricht zwar nicht dem Proposal, aber die Struktur ist mit diesem konform. Im weiteren Verlauf gibt es keine Relationen, dort sind nur die Wege mit lcn=yes versehen. Die Proposal-konforme Lösung wäre, für alle noch nicht als Relation erfassten Verbindungen des Grundnetzes eine Relation anzulegen und diese in eine Superroute für die RadNETZ-Verbindung aufzunehmen, so wie es @Karthoo oben beschrieben hat. Das ist mir aber zu aufwändig und pflegeintensiv. Die Verbindung bleibt also erst mal ungemappt.

JochenB wrote:

rainerU wrote:

In der Praxis führt das zu einer Vielzahl von Klein- und Kleinst-Relationen zwischen benachbarten Wegweisern, von denen viele nur aus zwei Wegweisern und einem oder zwei Wegen bestehen.

rainerU wrote:

Der damit verbundene Pflegeaufwand erscheint mir in Relation zum Nutzen viel zu hoch.

Find ich nicht. Bei Knotenpunktnetzwerken gehen wir ähnlich vor und es ist wunderbar strukturiert und gut pflegbar.

Eine kurze Anmerkung dazu. Ich stimme zu, dass die erstmalige Einrichtung dieser kleinen Relationen zwischen (aufspaltenden) Wegweisern sehr viel Arbeit ist. Analog zu den Knotenpunktnetzwerken kann man damit jedoch den Zustand algorithmisch überprüfen, was den Pflegeaufwand nicht erhöht, sondern erheblich reduziert. Dazu kann man analog zu expected_rcn_route_relations die Anzahl der Richtungen des Wegweisers angeben und diese mit der Anzahl der Routen abgleichen, die am Wegweiser enden.

Duvodas wrote:

Analog zu den Knotenpunktnetzwerken kann man damit jedoch den Zustand algorithmisch überprüfen, was den Pflegeaufwand nicht erhöht, sondern erheblich reduziert.

Damit kann zwar die formale Korrektheit und Vollständigkeit geprüft werden, ob die Relationen noch der Realität vor Ort entsprechen, müssen Mapper vor Ort überprüfen. Und da gilt: je einfacher ein Taggingschema ist, um so mehr Mapper beteiligen sich an der Wartung. Wenn in einer Region genügend Mappingkapazität verfügbar ist, dann sind diese Relationen vollkommen ok. Das ist aber bei weitem nicht flächendeckend der Fall. Dort, wo jetzt noch weiße Flecken bei der Erfassung der Radverkehrsnetze sind - ich kenne da einige - hätte ich gerne ein niedrigschwelliges Angebot, das ohne diese vielen Relationen auskommt.

Bei all dem gehe ich natürlich davon aus, dass die Daten OTG erfasst bzw. verifiziert werden. Für die Netze in meiner Ecke gibt es zwar frei zugängliche Planungsunterlagen. Diese sind aber aus Lizenzgründen nicht für OSM nutzbar. Aber selbst wenn sie es wären könnte man sie nicht unbesehen übernehmen, da es vor Ort immer wieder Abweichungen und undokumentierte Änderungen gibt.

Die Sammelrelationen der Netzwerke mit Wegen als Mitglieder sind Bockmist, keine Frage.
So wie das aber hier beschrieben wird, klingt es als ob das Knotenpunktnetzwerk-Tagging jetzt komplett für andere Netzwerke übernommen werden soll und das halte ich schon für problematisch, vor allem aufgrund der Komplexität.
Weiterhin können wir uns eventuell auf den Startpunkt einigen, wo das Ziel zum ersten mal auf den Wegweisern auftaucht aber der letzte Knoten am Ende existiert bei mir nicht und es ist auch nicht der erste Wegweiser, wo das Ziel nicht mehr auftaucht. Bei Städten hätte ich jetzt das Zentrum als Start- bzw. Endpunkt angenommen, aber die Beschilderungen für das nächste Ziel beginnen schon vorher.

Kann mir bitte eine Person mal an einem Beispiel erklären wie das aussehen soll. Auf diesem Abschnitt sollten z.B. fast alle Wegweiser mittlerweile erfasst sein:
- https://www.openstreetmap.org/way/1002830385
- https://www.openstreetmap.org/way/616625780

Bitte die separierte Gegenrichtung nicht vergessen. Gespannt bin ich auch auf die Aussage zur Kronenbrücke und was für ein Knoten die darstellen soll.

rainerU wrote:

hätte ich gerne ein niedrigschwelliges Angebot, das ohne diese vielen Relationen auskommt.

In meinem Proposal hatte ich zwei Taggingmöglichkeiten vorgeschlagen. Einmal niederschwellig als 'lcn=basic_network' an den Wegelinien und einmal aufwendiger über route-Relationen.

So gibt es die Chance, das Netz (erstmal) unkompliziert zu erfassen. Solange die einzige Aufgabe der Relation ist, die Mitglieder als Teil des Netzwerkes zu markieren ist das ebenbürtig mit einer Relation. Wenn weitere Eingeschaften des Netzwerkes erfassen werden sollen, so ist es m. E. besser, das einmal in der Relation zu erfassen und nicht an jeder einzelnen Wegelinie.

Wenn sich jemand findet, der Wege mit 'lcn=basic_network' in Relationen überführt und mit weiteren Informaionen anreichert, so kann er es im Anschluss gerne tun. Wichtig ist erstmal, dass es überhaupt erfasst wird und man es von anderen Routen unterscheiden kann.

JochenB wrote:

In meinem Proposal hatte ich zwei Taggingmöglichkeiten vorgeschlagen. Einmal niederschwellig als 'lcn=basic_network' an den Wegelinien und einmal aufwendiger über route-Relationen.

Das habe ich gesehen.

Wenn weitere Eingeschaften des Netzwerkes erfassen werden sollen, so ist es m. E. besser, das einmal in der Relation zu erfassen und nicht an jeder einzelnen Wegelinie.

Wenn sich jemand findet, der Wege mit 'lcn=basic_network' in Relationen überführt und mit weiteren Informaionen anreichert, so kann er es im Anschluss gerne tun. Wichtig ist erstmal, dass es überhaupt erfasst wird und man es von anderen Routen unterscheiden kann.

Wenn die Relationen erst mal angelegt sind, muss sie auch jemand pflegen. Ich stoße aber immer wieder auf lcn-Relationen, die einmal vor fünf oder mehr Jahren angelegt und seitdem nicht mehr bearbeitet wurden. Ich würde diese Relationen ja pflegen, wenn ich deren Nutzen erkennen würde, genauer gesagt ihren Mehrwert gegenüber dem einfachen lcn=yes am Weg.

Ich nehme nur mal das Thema Routinganweisungen als Beispiel. Ein nützliches und hilfreiches Feature von Fahrradnavis wäre eine Richtungsansage, wie man sie von Autonavis gewohnt ist. Eine solche Ansage lässt sich aber mit den basic_network-Relationenen trotz des hohen Aufwands, den man rein steckt, nicht realisieren, da die Richtungsangaben der Wegweiser in keiner Weise mit der zugehörigen Verbindung verknüpft sind.

rainerU wrote:

Wenn die Relationen erst mal angelegt sind, muss sie auch jemand pflegen. Ich stoße aber immer wieder auf lcn-Relationen, die einmal vor fünf oder mehr Jahren angelegt und seitdem nicht mehr bearbeitet wurden. Ich würde diese Relationen ja pflegen, wenn ich deren Nutzen erkennen würde, genauer gesagt ihren Mehrwert gegenüber dem einfachen lcn=yes am Weg.

Mir geht's da tatsächlich ähnlich, allerdings mit lcn=yes an den Wegen. Ich stoße immer wieder auf einzelne Wege mit lcn=yes, die oft nicht einmal (mehr) Teil eines lcn-Netzwerks sind. Ich habe das Gefühl, lcn=yes ist viel unübersichtlicher als die Relationen-Lösung.

rainerU wrote:

Ich nehme nur mal das Thema Routinganweisungen als Beispiel. Ein nützliches und hilfreiches Feature von Fahrradnavis wäre eine Richtungsansage, wie man sie von Autonavis gewohnt ist. Eine solche Ansage lässt sich aber mit den basic_network-Relationenen trotz des hohen Aufwands, den man rein steckt, nicht realisieren, da die Richtungsangaben der Wegweiser in keiner Weise mit der zugehörigen Verbindung verknüpft sind.

Deshalb füge ich an die Relationen meistens auch die Richtungsangaben via destination:forward/backward an, wie z.B. hier.

Karthoo wrote:

rainerU wrote:

Wenn die Relationen erst mal angelegt sind, muss sie auch jemand pflegen. Ich stoße aber immer wieder auf lcn-Relationen, die einmal vor fünf oder mehr Jahren angelegt und seitdem nicht mehr bearbeitet wurden. Ich würde diese Relationen ja pflegen, wenn ich deren Nutzen erkennen würde, genauer gesagt ihren Mehrwert gegenüber dem einfachen lcn=yes am Weg.

Mir geht's da tatsächlich ähnlich, allerdings mit lcn=yes an den Wegen. Ich stoße immer wieder auf einzelne Wege mit lcn=yes, die oft nicht einmal (mehr) Teil eines lcn-Netzwerks sind. Ich habe das Gefühl, lcn=yes ist viel unübersichtlicher als die Relationen-Lösung.

Liegt das nicht eher daran, dass die Relationen in QA unterstützt werden, während `l*n=*` an Linien komplett ignoriert wird?

Karthoo wrote:

rainerU wrote:

Ich nehme nur mal das Thema Routinganweisungen als Beispiel. Ein nützliches und hilfreiches Feature von Fahrradnavis wäre eine Richtungsansage, wie man sie von Autonavis gewohnt ist. Eine solche Ansage lässt sich aber mit den basic_network-Relationenen trotz des hohen Aufwands, den man rein steckt, nicht realisieren, da die Richtungsangaben der Wegweiser in keiner Weise mit der zugehörigen Verbindung verknüpft sind.

Deshalb füge ich an die Relationen meistens auch die Richtungsangaben via destination:forward/backward an, wie z.B. hier.

Die Richtungen sollten ja aus den superroute Relationen erkennbar sein, aber auch laute hier die Frage wohl, welche Software wertet das korrekt aus.

Karthoo wrote:

Deshalb füge ich an die Relationen meistens auch die Richtungsangaben via destination:forward/backward an, wie z.B. hier.

Auch das kann man am Weg machen, Beispiel.

Also ich nutze für sowas auch Relationen wegen der guten Wartbarkeit. Auf einen Blick sieht man Lücken oder kann auf die gesamte Verbindung zoomen. Womöglich liegt das am verwendeten Editor. In JOSM ist das sehr komfortabel gelöst.