Ich sehe hier keinen Unterschied. Auch mit dem Rad sind die Wegweiser eine Hilfe zum Abbiegen. Auch auch bei destination sehe ich, welches Ziel in der jeweiligen Richtung ist. Sowohl bei destination als auch bei guidepost ist immer ein bestimmter Weg gemeint, den man folgen muss um zum Ziel zu kommen. Bei beiden Varianten kann später ein erneutes Abbiegen nötig sein (mit neuem Wegweiser / Destination sign).
Hallo,
der Unterschied liegt darin, dass Radnetze im einfachsten Fall auf die Wegweiser und ihre Nachbarschaftsbeziehungen reduziert werden können ohne irgend welche Wege zuzuordnen.
Destination soll es erleichtern, zu einem Weg an einer Kreuzung denjenigen Wegweiser auszulesen um als Teil des Routings einen Hinweis an den Nutzenden zu geben, welchem Ziel zu folgen ist. Es ersetzt z.B. einen Straßennamen (Hauptstraße) durch eine Zielangabe (Köln) in der Annahme, dass der Name des Wegs vor Ort schwieriger zu lesen ist als die Bezeichnung auf dem Wegweiser. So mein Verständnis bisher.
Grüße
Jens-Uwe
Je mehr ich darüber nachdenke, desto mehr bin ich davon überzeugt, dass das offizielle Radverkehrsnetz direkt am highway dran und nicht in einer Relation sein sollte. Das mit den Relationen ist alles mühsam und kompliziert. Der Wert lcn=yes oder rcn=yes deckt das wichtigste ab:
- Router können solche Wege bevorzugen
- Renderer können solche Wege hervorheben (cyclosm macht das schon)
- Datenauswerter können sich die Daten per overpass (oder wie immer sie wollen) herunterladen und (zB auf Lücken) analysieren, jedoch brauchts es hier womöglich andere Methoden als wenn man Relationen analysiert.
Die großen Nachteile der Relationen, dass sie irgendwann zu viel oder zu groß werden, fallen alle weg. Und auch der Nachteil von Relation an sich, dass sie für zahlreiche Mitwirkende per se abschreckend sind, ist nicht zu unterschätzen.
Vielleicht braucht es für Spezialfälle noch ein paar Zusatztags, aber die Mehrzahl aller Netzelemente wird mit dem einen Tag auskommen.
Wie @segubi geschrieben hat, ist diese Diskussion mehrmals gestartet worden und immer wieder frustriert aufgegeben worden. Ich glaube, es braucht ein kleines Team (ca. 5 Personen), welches ohne ständige Zwischenrufe ein in sich schlüssiges Proposal ausarbeitet, dieses dann gesammelt zur Diskussion stellt und hoffentlich zu einer positiven Abstimmung bringt. Ich wäre bereit, in so einer Kleingruppe mitzuarbeiten, aber möchte das nicht federführend bearbeiten.
Liebe Grüße
1 Like
So wurde das auch lange gemacht und wird es auch teilweise noch, bis es Mapper gab, die diese Wege in Relationen gepackt haben. Relationen halte ich eigentlich nur für notwendig, wenn es um konkrete (oft touristische) Routenvorschläge (zu einem Ziel oder bei Rundwegen) geht, nicht jedoch bei lokalen/reginalen Netzen.
1 Like
Ich will mich nicht querstellen, aber ich glaube, ob das mühsam oder kompliziert ist, ist wirklich Geschmackssache. Ich finde das mit den Wegen persönlich total unübersichtlich. Ich kann nie auf den ersten Blick sehen, wer da etwas eingepflegt hat und wann, ohne mich durch unendliche Changesets durchzuwühlen. Die hohe Popularität der Relationen spricht schon ein Stück für sich, ich stehe auch nicht alleine mit meinem Empfinden da. Vielleicht ist die Herangehensweise eine andere?
Natürlich ist es einfacher, die Wege zu markieren, wenn man von einer Karte etwas überträgt. Es ist aber, wenn man on the ground sich die Situation anschaut, viel einfacher, den gefahrenen Weg nachzugehen und die Relation mit dem Datum zu versehen als die ganzen Wege. Ich kann, was Nordrhein-Westfalen angeht, ziemlich klar sagen, dass nur ein Survey zu korrekten Daten führt, da es kein suffizientes Kartenmaterial gibt. Die offizielle website zeigt Daten, die z.T. über 10 Jahre veraltet sind, und dort neue Wege fehlen und abgebaute noch enthalten sind. (Mal ganz unabhängig davon, dass ich nicht weiß, ob die Quelle überhaupt zugelassen ist für OSM).
Man kann mit lcn/rcn nicht erkennen, ob es sich um Routen mit Zielwegweisung handelt oder nur einfach in irgendeiner Form ausgeschilderte Radrouten handelt.
In den Tags lcn/rcn sehe ich keine Aussage für das Grundnetz. Die unbenannten Netzabschnitte, bzw. das gesamte Grundnetz könnte mit gleichem Recht als ncn (Größe des Gesamtnetzwerkes) wie lcn (Länge zwischen zwei Knoten) betrachtet werden. In einigen Regionen werden (wurden? in HF habe ich es nach Diskussion geändert) diese Routen als rcn betrachtet.
Wenn man sich darauf einigen würde, z.B. am Weg NUR das reguläre Netzwerk zu taggen, und hierfür entweder dafür nur lcn oder nur rcn nehmen würde, oder wie @JochenB auch mal erwogen hatte, bcn einzuführen, DANN könnte ein Renderer diese Wege identifizieren. Im Moment sind auch zahlreiche Fragmente so getaggt, die irgendwann mal vielleicht Radnetzwerk im engeren Sinne waren.
Im Moment finde ich, gibt es die Definition von rcn/lcn nicht her, dass nur Wege mit Zielwegweisung erfasst werden. Ich fürchte, es kann mühsam werden, hierfür einen Konsens zu erhalten und ohne den wären die Daten wertlos.
Mich hält auch ab, dass die Routenrelationen mehr Informationen enthalten. Man könnte ohne weiteres automatisiert die Relationen in ein Tagging am Weg überführen, umgekehrt wäre es schon ziemlich schwierig, wenn man Besonderheiten drin haben will, wie signed_direction=yes oder spezielle Routenführungen in unterschiedliche Richtungen. Wie soll man das im Tagging unterbringen?
Ich stehe gerade in Kommunikation mit dem Tourismusverband der Niederlausitz betreffs Mängel an den ausgeschilderten Verbindungen zwischen den Knotenpunkten. Diese Verbindungen sind in einem Objekt zusammengefasst. Ich brauchte nur einen Link zu diesem Objekt zu senden, um darzustellen, worum es geht - extrem praktisch:
https://www.openstreetmap.org/relation/12311325#layers=Y
Ich denke, die Verwendung von Relationen wurde bereits vor Jahren durch die Praxis entschieden, fast überall hat man das so gemacht. Bei Knotenpunktnetzwerken sehr strukturiert, beim Rest in teils riesigen Sammelrelationen. Seit meinem Proposal-Entwurf wird auch das Grundnetz vermehrt ähnlich der Knotenpunktnetzwerke getaggt, die Sammelrelationen nehmen ab.
Zumindest mit JOSM ist das Taggen von Relationen komfortabel gelöst, ich erkenne daran nicht Kompliziertes. Aber ja, man muss erstmal überhaupt lernen, was Relationen sind. Das sollte einerseits Grundwissen für jeden Mapper sein, andererseits biete ich im Proposal ja auch eine “Einstiegshilfe” ohne Relationen an.
Bitte nicht lcn/rcn=yes verwenden, denn daraus wird nicht klar, ob es sich um eine klassische Route oder eine Verbindung im Netzwerk handelt. Damit wären wir wieder am Anfang beim ursprünglichen Problem. Wenn dann lcn/rcn=basic_network, das ist auch Teil des Proposals.
Wir sollten den Unterschied zwischen Netzwerk-Verbindung ohne Knotennummer und mit Knotennummern nicht dadurch abbilden, ob wir das mittels Relation an die Linie schreiben oder direkt an die Linie.
Inhaltliche Unterschiede sollten durch unterschiedliche Tag-Inhalte beschrieben werden und nicht durch unterschiedliche Verwendung von OSM-Konstrukten.
Also genau dort liegt einer der größte Vorteile der Relation: ein Blick in die Mitgliederliste und man erkennt Lücken auf einem Blick. Hier per Overpass zu gehen halte ich für mega-kompliziert, das ist dann wirklich nichts mehr für den Durchschnitts-Mapper.
Dieser Nachteil existiert in meinen Augen nicht, die Relationen sind meist recht kompakt. Ein paar durchgehende zusammenhängende Linien und ggf. am Ende noch die zugehörigen Wegweiserknoten.
Es ist eher umgekehrt, dass bei dichten Netzen sehr kleine Relationen entstehen können mit ein / zwei Linien. Aber dafür gibts ja auch die simple Lösung, mehrere hintereinander liegende Verbindungen in einer Relation zusammenzulegen.
Nun, dafür habe ich lcn/rcn=basic_network vorgeschlagen, das kann ja später jemand in Relationen mit network:type=basic_network überführen, der mit Relationen nicht fremdelt.
1 Like
Ich habe das nicht als frustrierend erlebt, sondern als sehr konstruktiv. Dass ich am Proposal nicht weitergemacht habe, hat einerseits private Gründe, anderseits habe ich meine Ziele bereits weitgehend erreicht.
Das Proposal wurde sehr umfangreich in der internationalen Mailingliste diskutiert. Gefühlt 70% war fehlendes Verständnis für den Bedarf bzw. für den Unterschied zu bekannten Tags, die nach meiner Einschätzung bereits etwas anderes beschreiben. 15% waren Abschweifungen und vielleicht 15% Verbesserungshinweise.
Diese 15% waren die Diskussion wert. Für mich war die Frage wichtig, ob es relevante Bedenken gibt und wir mit dem Vorschlag auf dem Holzweg sind. Von denen, die es verstanden haben, kam so etwas nicht. Damit ist für mich das Wichtigste erledigt.
Es gab vor allem die Bitte, einen selbst-beschreiberenden Tag-Namen zu finden als network:type. Zudem zahlreiche Hinweise für eine verständlichere, allgemeinere Beschreibung des Problems und der Lösung. Es gab auch Kritik an dem Vorschlag, ein Tagging ohne Relationen als “Einstiegshilfe” anzubieten.
Da sich network:type bereits durchgesetzt hat und mir auch nichts Besseres einfällt würde ich das Proposal mit denselben Tags weiterführen. Die Beschreibung, was ein “Grundnetz” ist, würde ich jedoch genereller durchführen, so dass es unabhängig vom Anwendungsfall “Wandern” oder “Radfahren” ist. Ich würde zudem begründen, warum ich die Vorschläge der Anwendung bestehender Tags nicht übernehme.
Macht viel Aufwand, aber wofür?
Ich habe ehrlich gesagt nur beschränkt Spaß daran, nochmal den Rest der Welt zu erklären wie die Situation in Mitteleuropa ist mit dem Risiko, dass es nicht verstanden und daher abgelehnt wird.
Das wäre der Worst Case. Dann haben wir ein abgelehntes Proposal für eine Praxis, die sich längst verbreitet hat. Wer hat Lust das nochmal mit einem erneuten Vorschlag anzugehen oder wer wird das bereits Getaggte alles nochmal abändern?
Also lieber die Kraft in das Wiki stecken. So sollten Knotenpunknetze und Grundnetz zusammen beschrieben werden, die Unterschiede sind ja gering.
Zudem gibt es viele redundante Beschreibung in den Seiten der einzelnen Keys. Das wäre besser zentral auf die Seiten Bicycle/Radverkehrsnetze kartieren und das Bicycle/Fahrradrouten_kartieren aufgehoben, von den Key-Seiten dann einfach darauf verweisen.
2 Likes
Ich ergänze noch einmal an diesem Ort einen Vorschlag von Jens-Uwe etwas expliziter, den ich gut finde, und den ich allmählich hier in der Gegend einpflegen werde, weil er offensichtlich unschädlich für bestehende Applikationen und hilfreich für neue Anwendungen ist:
In die Relationen können am Start- und Endpunkt die zugehörigen Wegweiser aufgenommen werden. Das hat den großen Vorteil, dass die Relationen deutlicher definiert sind, und die Verbindung zwischen Route und Wegweiser einfach herstellbar ist, ohne z.B. eine Umkreissuche um die Wege der Routen durchführen zu müssen.
Ich würde vorschlagen, Zielwegweiser, die unterwegs stehen, auch an der Stelle in die Relation einzusetzen, wo sie sich befinden. (Ich bin der Meinung, dass auch bei getrenntem Hin- und Rückweg EIN guidepost-node nur EINMAL aufgenommen werden sollte. Begründung unten…) Bei linearen Relationen, die auch über Abzweigungen laufen kann sich hieraus (wenn mehr als 2 Richtungen vorliegen) auch ein Hinweis ergeben, dass an dieser Stelle ein Abzweig liegt.
(@Jens-Uwe_Hagenah: Du hast von “deiner” Routing-Applikation gesprochen, die die Relationen entsprechend auswertet. Gibt es sie irgendwo? Man könnte sie ja gut zum Testen der Relationen verwenden…)
Viele Grüße und ein gutes neues Jahr hier…
Sebastian
Anhang: guidepost nur je einmal aufnehmen?
Pro:
- Insgesamt nicht zu viele Elemente in eine Relation aufnehmen
- Ungeschriebenes Gesetz: Elemente sowieso nicht doppelt in eine Relation aufnehmen (hier gibt es aber auch gut begründbare Ausnahmen)
- Da die Daten, wenn man die Relation bereits zur Auswertung herunter geladen hat, ist die Zuordnung zu bestimmten Lokalisationen ohne erneute Datenabfrage lokal ohne Aufwand möglich. (Also die Zuordnung zum entprechenden Routenabschnitt/Routenpunkt der Gegenrichtung: Algorithmus: erstelle Route für Hinweg, erstelle Route für Rückweg, wähle jeweils den nächstliegenden Punkt der Route zum Wegweiser als Wegweisungspunkt)
Contra:
- Woher soll der Router dann wissen, wo genau ein Abzweig ist?
Pro:
- Das muss der Router aufgrund der Wege selbst herausfinden, da 1. erfahrungsgemäß die Relationen ohnehin ständigen Veränderungen unterliegen und die Ordnung sich je nach Editor, der damit hantiert, auch mal wieder ändern kann. 2. im Falle von Abzweigungen unter Umständen sowieso variable Routen auftreten können, bei denen es mehrere faktische Knoten (je nach eingeschlagenem Weg und Richtung) geben kann.
Contra:
- Ich könnte mir Fälle vorstellen, wo ein Wegweiser nur von einer Routenrichtung aus sichtbar ist. Das könnte dann damit signalisiert werden. Im Falle von Verzweigungen würde ich dann allerdings ohnehin hoffen, dass dann ein zweiter Wegweiser für die andere Richtung vorhanden wäre - leider gibt es on the ground Ausnahmen, dass nämlich Aufzweigungen nur für eine Wegrichtung vorhanden sind und die Gegenrichtung keine Wahlmöglichkeit gezeigt bekommt. (halte ich prinzipiell für eine Ausschilderungsinkonsistenz, befürchte aber, das ist an manchen Stellen beabsichtigt - leider erinnere ich mich nicht mehr genau an die Beispiele. War irgendwo im Kreis Herford.)
Pro:
- Warum bei so komplizierten Fällen nicht doch überhaupt die Relation an der Aufzweigung splitten und zwei Relationen machen??? Dann muß die arme Routinganwendung (bzw. deren Programmierer) sich nicht mit der Analyse dieser Spezialfälle beschäftigen… Sondern Knoten ist halt am Ende der Relation. Die Relation, die keinen Abzweig angeboten bekommt, bekommt halt auch keinen Guidepost node, wenn sich daraus eine Relation ergibt, in die nur von einer Seite aus eingebogen werden würde wegen der Ausschilderung, kann ein signed_direction=yes bekommen (Achtung: Es gibt auch Wegabschnitte, die zwar von der Zielwegweisung nur von einer Seite erfaßt werden, aber eine beidseitige Zwischenwegweisung haben. Da handelt es sich am wahrscheinlichsten um Vandalismus oder einen Ausschilderungsfehler. Ich würde dann kein signed_direction setzen, sondern bescheiden auf eine genauere Spezifizierung verzichten, und wenn ich viel Zeit übrig habe, mit der zuständigen Stelle des Landkreises/der Gemeinde Kontakt aufnehmen und fragen, ob das Absicht ist…)
Meine Idee besteht darin, Radwegweisernetze wie Knotenpunktnetze zu behandeln. Das bedeutet dass, dass jeweils eine Verbindung zwischen zwei entfernt voneinander liegenden Wegweisern erfasst wird aber nicht über diese Wegweiser hinausgeht.
Im Falle von Armwegweisern sind dann genau zwei Wegweiser beteiligt (Beispiel Relation 15089617).
Die Wege zwischen den beiden Wegweisern werden ohne Rolle erfasst wenn Hin- und Rückweg identisch sind. Was dabei der Hin- bzw. Rückweg ist, wird durch die Erfassenden willkürlich festgelegt. Die Strecken sollten vollständig sein, um die Gesamtlänge zu ziemlich genau zu erfassen. Eine Abweichung von dieser Regel wird weiter unten beschrieben.
Fallen Hin- und Rückweg streckenweise auseinander, so bekommen die Strecken, die nur auf dem Hinweg befahren werden, die Rolle forward (unabhängig von der Richtung des Way). Entsprechendes gilt für den Rückweg mit der Rolle backward (Beispiel Relation 14956019).
Gibt es nur einen Hinweg (ohne Rückweg) so bekommen alle Stecken die Rolle forward um sie von einer in beide Richtung befahrbaren Strecke zu unterscheiden.
Stehen an einem oder beiden Enden (mehrere) Tabellenwegweiser, so werden diejenigen aufgenommen, die zu dieser Relation gehören, d.h. auf das Ziel hinweisen (Es gibt leider krude Situationen, wo nicht alle Wegweiser die Ziele zumindest paarweise teilen. Das ist aber nur selten der Fall) . Den Normalfall zeigt das schon bekannten Beispiel Relation 14956019 am Anfang. Oder mit mehreren Wegweisern an beiden Enden (Beispiel Relation 14884215).
Für die Auswertung per Programm ist es wichtig, dass die Relation am Anfang und Ende jeweils Strecken so aufnimmt, dass die zugehörige Himmelsrichtung des Wegweisers mit der des ersten bzw. letzten Steckeinabschnitts übereinstimmt. Sonst versagt die Zuordnung dieses Abschnittes zu der Himmelrichtungen des Wegweisers und die zur Relation passende Zielangabe kann nicht gefunden werden. Siehe hierzu den Anfang in der Schillerstraße von Relation 15089790. Wird auch der kurze Way (das Teilstück Dorfstraße hinzugenommen, um den Anschluss zur angrenzenden Relation lückenlos zu machen (Relation 15089791), so würde dieses in Ost-West- statt in Nord-Süd-Richtung weisen. Und die Wegweisung (des Wegweisers 1593914894) in Richtung Ost (Bad Schwartau) statt Nordwest (Ahrensbök) zuordnen.
Ich hoffe hiermit einen brauchbaren Vorschlag zum Mapping von lokalen Radnetzen (network:type: basic_network) mit Wegweisern zu unterbreiten. Ich betrachte ihn als RFC.
Das ganze Beispiel mehrere Relation findet sich bei Turbopass.eu unter dem angegebenen Link.
@segubi: Vielen Dank für dein Interesse an meiner App (für Android-Smartphones). Ich stelle ich gerade auf dieses Schema im Mapping um. Aber ich werde wohl noch etwas brauchen 
. Sobald ich etwas Vorführbares habe, werde ich dies hier auf Community.Open mitteilen 
.
Kleiner Hinweis zu diesem Absatz: Die Rollen “forward” und “backward” bei Radrouten-Relationen beziehen sich nicht darauf, ob es der “Hinweg” oder “Rückweg” der Route ist, sondern ob der jeweilige Straßen-/Wegabschnitt in Richtung oder in Gegenrichtung des OSM-Ways befahren wird. Sieht man auch, wenn man deine Beispiel-Relation in der “Radfahrerkarte” anschaut. Dort wird durch gelbe Pfeile markiert, in welche Richtung die Radroute führt - das sieht im Moment etwas durcheinander aus (z.B. auf dem Sonnenweg Richtung Nordosten, aber auf der Straße Heisterbusch Richtung Südwesten).
Ich würde schon fordern, dass die Wege der einen Relation mit einer Anschließenden Relation eine Kontinuität bilden, und keine Lücken entstehen dürfen, also dass in einer der Relationen der Weg Way: Dorfstraße (1043530092) | OpenStreetMap auftauchen müßte.
Das ist nicht ganz unproblematisch, da das erheblich von der Richtung des Wegweisers abweichen kann, z.B. bei Kombinationen mit Unterführungen. Die Mappingpraxis ist da etwas variabel. Da Mapping immer orientiert an der Gegebenheit vor Ort sein soll, wird für eine allgemein verbindliche Vorgabe wohl eher die tatsächliche Richtung des Wegweisers zu nehmen sein.
Ich persönlich habe zumeist die ungefähre Wegrichtung der ersten ca. 100 Wegmeter genommen. (Z.B. wenn man nach Süden eine Straße überquert, auf der nach Osten der Radweg weitergeht, wird der Wegweiser zumeist auch Osten weisen, auch wenn der erste Weg nach Süden weist.
Dann gibt es so krude Situationen wie folgende: Node: 8870479267 | OpenStreetMap Node: 8870479268 | OpenStreetMap, wodurch die Radfahrer mit dem Holzhammer dazu bewegt werden sollen, die Straße in jedem Fall zu überqueren und den beidseitigen Radweg auf der Südseite der Dornberger Straße zu verwenden. Auf der Nordseite weist der Wegweiser “Bethel” nach Süden, auf der Südseite nach Osten.
Die Guidepost Nodes werden sich im Zweifel an der Situation “on the ground” orientieren müssen. Wahrscheinlich braucht es schon noch einen etwas komplexeren Algorithmus, oder man verwendet die Destination-Sign-Relationen (https://wiki.openstreetmap.org/wiki/DE:Relation:destination_sign) und erweitert die Verwendung der Rolle “to” auf Relationen.
Hat mal jemand eigentlich sich den praktischen Aspekt dieser Methoden überlegt?
Hier in der Gegend wird teilweise das Radwegnetz neu beschildert und auch umgestaltet. Früher habe ich ein i/n/r/lcn drangehängt und gut war es. Jetzt fahre ich vorbei und denke mir: “Oh Gott, das kann jemand anders machen. Ist mir zu kompliziert.” Jetzt als ich mal ausprobieren wollte, habe ich schlussendlich doch wieder nur lcn=yes drangepappt.
2 Likes
Vielleicht sollte ich noch einmal meine Idee des Routings auf dem Netz der Radwegweiser erwähnen und den Unterschied zum “klassischen” Routing über eine Abfolge von einzelnen Wegen. Ich möchte es ermöglichen, Radfahrenden am Wegweiser den Hinweis “Nord: BI-Großdornberg (Fzs) ,8 km; …” anzeigen. Dazu muss die Zuordnung vom abgehenden Weg zur Himmelsrichtung des Wegweisers der App bekannt sein. Dazu müssen die erforderlichen Informationen in OSM so vorhanden sein, dass die Zuordnung verlässlich möglich wird. Dafür sind (leider) zusätzliche Informationen erforderlich.
Beim klassischen Routing brauche ich öfter den Blick auf die Karte (z.B in OSMAnd) um den weiterführenden Weg zu entdecken. Da ich aber während der Fahrt diese nicht lesen kann, muss ich an der Kreuzung anhalten. Das möchte ich vermeiden.
1 Like
Das kann man mit destination:bicycle erledigen, ganz ohne Relation, so wie es auch beim allgemeinen Straßennetz gemacht wird.
Wieso kannst Du die Karte nicht während der Fahrt lesen? So wie der FGSV Standard die Wegweiser definiert, kannst Du sowieso nur die Wegweiser quer zu deiner Fahrtrichtung schnell genug lesen, wenn es wenig Wegweiser sind. (Hier feiert man momentan Orgien mit bis zu 14 Zielen an einem Wegweiser.) Weiter müsstest Du deinen Vorstellungen zur Folge die Himmelsrichtung in dem Moment wissen, um auf den richtigen Wegweiser zu schauen.
Nach meinen Erfahrungen mit diesen Wegweisern als solches, ich fahre lieber ohne sie und nach Routinganweisung, weil die
- Wegweiser schlecht lesbar aufgestellt sind.
- verdreht werden oder sogar verdreht aufgestellt werden.
Und ein Routing, was sich auf die Wegweiser bezieht, löst das Problem der schlechten Aufstellung der Wegweiser nicht.
ich bin letztlich NUR über einen praktischen Aspekt daran geraten, über Relationen zu mappen. Als ich 2020 angefangen habe OSM für Radtouren zu nutzen, habe ich festgestellt, dass hier in der Region das Mapping seit Jahren veraltet war und viele Routen geändert, gestrichen und neu hinzugefügt wurden. Ohne Zusammenfassung der überprüften Abschnitte in Einzelrelationen mit Datum hätte ich niemals den Überblick behalten, was nun aktuell und was veraltet ist, und nur so ist ein gemeinschaftliches Mappen möglich.
Es ist aufwändig. Aber durch Löschung der lcn/rcn/ncn-Tags an Wegeabschnitten wäre ich auch nicht wirklich klargekommen. Vor allem wäre bei Fehlern meinerseits (z.B. wenn ich einen Weg einfach nicht gefunden hätte, weil Wegweiser unkenntlich waren) kaum noch nachvollziehbar gewesen, was ich da im Datenbestand treibe.
Mist, eigentlich hatte ich mir geschworen auf solche grundsätzlichen Infragestellungen nicht mehr zu antworten, weil ich das schon zu oft getan habe. Sorry. Siehe intialen Post.
Viele Grüße, Sebastian
Zur einen Anmerkung (Und vielen Dank an Dich, @klnkengi und @GUFSZ für die Anmerkungen) :Die geschilderte Situation ließe sich aus meiner Sicht dadurch auflösen, dass für den Weg über die Straße eine eigene Relation angelegt wird.
Das möchte ich damit begründen, dass sich die Angaben auf dem Wegweisern deutlich unterscheiden, sowohl in den Himmelsrichtungen für z.B BI-Bethel als auch in den Kombination der Ziele: 8870479267 auf der Nordseite der L778, der BI-Bethel zusammen mit BI-Uerentrup und Tierpark Olderdissen nach Süden anzeigt bzw. 8870479268 auf der Südseite, der Bethel zusammen mit (Bf) BI-Zentrum und KP 50 nach Osten anzeigt.
Zu der anderen Anmerkung. Um die Kontinuität zu wahren und dafür den kurzen Way auf der Dorfstraße einzufügen, wäre möglich. Da aber die Zuordnung der Himmelsrichtung des Weges zu Angabe auf dem Wegweiser nicht mehr klappt, wäre der Preis, diese Angabe in die Relation aufzunehmen. Mein Vorschlag dazu wäre in der Relation die Rolle guidepost um die Himmelsrichtungen zu ergänzen: guidepost:direction_north bzw am anderen Ende guidepost:direction_south_east. Das ist zwar eine Anforderung an Mappende, daran zu denken. Auf der anderen Seite könnte damit aber auch diese Information für die Validierung genutzt werden. Stehen an einem Ende mehrere Wegweiser (typisch Tabellenwegweiser), so wäre die Himmelsrichtung bei allen guideposts anzugeben. Dieser Mehraufwand (und die Redundanz) schein mir akzeptabel). Und meine App täte sich viel leichter 
. An der Stelle sähe es dann so aus: Richtung Osten: 15089791 bzw. Norden: 15089790.
Also weil Du eine Technik für ein persönliches Großprojekt entwickelt
hast, soll man für Kleinkram sich diese Technik aneignen? Habe ich das
richtig übersetzt?
Ja, ich stand vor der Herausforderung eine neue Rolle einzuführen oder eine vorhandene im neuen Kontext anders zu belegen. Wobei die eingeführte Variante (mit Bezug zur Reihenfolge der nodes des way) nach meinem Verständnis keine Aussage dazu mach, ob es sich im Sinne der Route um den Hin- oder Rückweg handelt also keinen Bezug zu dem Anfangs- und dem Endpunkt der Route hat. Die Aussagekraft bezieht sich darauf, ob ich z.B. eine Einbahnstraße gegen die Fahrtrichtung nutze.
Hast du einen Vorschlag, wie die von mir festgelegte Information besser in OSM abgebildet werden kann?
@GUFSZ Ja, Vandalismus kann ein Problem sein, Verschmutzung und schlechte Lesbarkeit ebenso. Und ich möchte auch niemanden zur Nutzung zwingen. Dass ich während der Fahrt die Karte auf Smartphone nicht lesen kann, liegt an meiner Kurzsichtigkeit und meinem Alter.
Die Himmelsrichtung möchte ich dazu nutzen, nur diejenigen Angaben der passenden Himmelsrichtung anzuzeigen und eben nicht alle der vor dir angeführten 14 Ziele. Das würde mir auch nur wenig helfen, da ich ja wissen möchte, welchem der Ziele ich folgen soll. Die Himmelsrichtung dient hierbei nur der Zuordnung der Angaben auf dem Wegweiser zu dem nächsten Weg der Relation.
Im krassesten Fall, ja. Ich sehe dass allerdings weniger als ein persönliches Großprojekt sondern meinen Beitrag zu OSM und als Alternative für das Routing für Radfahrende und eine Möglichkeit Wegweiser in das Routing einzubinden. Damit ist auch ein Routing ausschließlich über die Wege des Netzes möglich. Außer man nutzt BRouter so, dass alle nicht im Radnetz als Relation gemappten Wege so hohe Kostenfaktoren bekommen, dass sie nicht genutzt werden. Diese Anwendung wird ja nicht ausgeschlossen, sondern eine weitere kommt hinzu.
Wobei dies nicht notwendigerweise auf das Radfahren beschränkt ist.