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.
Dann fehlt mir aber der Bezug zu dem Netz, das sich aus den Radwegweisern ergibt. Eben das von @segubi vorgeschlagene basic_network, das nur Wegen enthält/enthalten sollte, die für Radfahrende besonders geeignet sind.
Auch wenn es Off-Topic wird. Ich habe hier vor Ort, die neuen Radwegschilder genutzt. Jede Kreuzung eines. Was ich da anhalten musste, war grausam. Soll heißen, ich glaube Du wirst bei deinem System nur anders/mehr behindert.
Wie dem es nun auch sei, Osmand und/oder Locus haben eine Funktion, dass sich der Zoom dem Tempo anpasst.
Weiter kann man bei beiden Apps die Zoomstufen vergrößern und verkleinern. Osmand: Langes Tippen auf das + Zeichen rechts unten.
Vielleicht wäre eine App mit aufgeteiltem Bildschirm besser. Ein Teil zeigt den Bereich der in x Metern erst kommt, deutlich vergrößert an.
… achso. Naja, ich habe ja schon ausgeführt, dass ich es nicht als Großprojekt empfinde.
Im Grunde geht es mir genau um die Frage, um die sich gerade der Austausch im Changeset: 127533538 | OpenStreetMap dreht: Wie geht man mit der Differenzierung zwischen alten Netzwerkresten (wie es anscheinend das Südhessennetz mit Nummern) ist, und dem aktuellen Ausschilderungsschema, das bundesweit eingesetzt wird (was ich in der Überschrift als “offiziell” bezeichnet habe) um.
Das ist für mich wirklich eine offene Frage, aber es ist deutlich, dass ein rcn/lcn=yes an den Einzelwegen überhaupt nicht in der Lage ist, im Datenbestand zu definieren, um was für ein Netz es sich eigentlich handelt.
Und da die Netze (zumindest hier in der Region) munter weiter umgestaltet werden, erlebe ich es als einfacher, bei einer geänderten Routenführung zwischen zwei Punkten die Relationen zu korrigieren. Ob dabei Fehler oder Lücken entstanden sind, ist z.B. mit JOSM schon beim Editieren sichtbar. Für das Taggen an Wegen gibt es keine Möglichkeit einer Plausibilitätskontrolle.
An der Stelle, auf die sich o.g. Changeset-Diskussion bezieht, bin ich tatsächlich unentschlossen, was man mit der Überlappung von alten und neuen Netzen macht.
Ich persönlich gehe pragmatisch so vor, dass ich in den Fällen, wo alte Netze und Routen vollständig nach dem neuen System ausgeschildert sind, und insofern in dem neuen Netz aufgehen, ich nur die benannten und nummerierten Routen in Relationen fasse, und die unbenannten basic_network-Relationen für unbenannte Abschnitte verwende. In den Fällen, wo diese Übernahme nur unvollständig ist, habe ich im Moment keine bessere Idee, als die Abschnitte, die nach dem neuen Ausschilderungsschema ausgeführt sind, in basic_network-Relationen zu erfassen, auch wenn sich hierbei Überlappungen mit anderen Routen ergeben.
Wer eine bessere Idee hat, die ermöglicht, diese Information aus den OSM-Daten später wieder zu extrahieren, soll sie gerne mitteilen.
Und dazu muss ich etwas sagen. Ich finde es etwas unglücklich, dass Du aus der Aussage eines Ortskundigen, der ich bin, als Ortsfremder solch weitgreifende Schlüsse ziehst.
Denn das ganze Netz zieht sich über mehrere Landkreise und gestern konnte ich sehen, dass es in einer anderen Gegend, wo ich extrem selten aufschlage, ziemlich gut gepflegt ist.
Dann kommen wir zum Frankfurter Netz, irgendein eifriger Mensch aus Kassel hat eine Monsterradnetzrelation erstellt. Jemand anderes, in NRW lebend, hat sie gelöscht, dabei dürften nicht unerhebliche Daten verloren gegangen sein.
Und jetzt als einfacher Wald und Wiesenmapper, frage ich mich, soll ich jetzt Daten, noch einmal erfassen, weil irgendwelche Leute die Daten als ihre Spielwiese betrachten.
Ich habe die Fehler, die in meiner näheren Umgebung waren, korrigiert. Durch die Löschaktion sind diese Infos perdu.
Okay, durch diese Korrektur kam raus, dass diese Monsterelation existiert. Aber hier in der Gegend gibt es so manch eigenartige Relation. Aber ich fasse die Sachen überhaupt nicht an, weil ich mittlerweile überprüfen muss, ist die Relation korrekt erstellt oder löscht, dass jemand, weil irgendetwas OSM-politisches los ist.
Bei dem Weg in dem Changeset hätte ich schon längst ein lcn=yes drangepappt, und jeder wüsste, okay, soll nett für das Radfahren sein.
Genauso würde ich in Frankfurt, so manches so simpel klären, wenn es da nicht notes und fixme eines nicht ortsansässigen Mappers gäbe, der es ganz genau haben will.
Andererseits klagt just dieser Mapper, dass die Netze so schlecht gepflegt sind. Aber genau der betreibt die Verkomplizierung der Sache, sodass man das halt nicht mehr im nebenbei betreiben kann.
Könnte es nicht sein, dass Du das Problem erzeugst, was Du beklagst und lösen willst?
Ich fahre selbst gerne in der Freizeit Fahrrad und nutze das Fahrrad auch für relativ lange Strecken, um von A nach B zu kommen. Hierfür habe ich die aktuelle Wegweisung grundsätzlich sehr schätzen gelernt, mit der ich mich einigermaßen darauf verlassen kann, dass ich auf dem Weg von A nach B nicht mal 20 km an einer Bundesstraße mit Abgas- und Lärmbelästigung radeln muß (was passiert, wenn ich einen Routenvorschlag über die Routing-Apps annehme), sondern wo möglich auch etwas verkehrsferner geführt werde, ohne dass ich mir einen Weg mühsam aus Themenroutenabschnitten und unzuverlässig getaggten “highway=track” Wegen zusammenklauben muß, um dann doch über Privatgelände mit freilaufenden Hunden zu geraten, weil ein access=private Tag gefehlt hat.
Wenn man aber eine Route planen will und nicht auf gut Glück auf eine längere Strecke losfahren will, ist es schön, eine Karte zu haben, in der man sehen kann, ob es in der gewünschten Region solche Strecken überhaupt gibt, und ob man auf große Umwege geschickt wird.
Dein Problem ist kein Problem der Erfassung, sondern des Renderings. An der von dir angeführten Stelle, ist es für deine Fragestellung vollkommen egal, ob das jetzt die Südhessenroute xyz ist, sondern es ist ein Teil irgendeines Radwegnetzes.
Der Witz ist, das Frankfurter Netz wurde früher ohne Relationen gerendert. Damit es jetzt gerendert wird, muss man es für manche Renderer in Relationen packen.
Edit: Ich hätte kein Problem, den östlichen Teil der Frankfurter Innenstadt aus dem Kopf zu mappen. Aber die ganzen Zusatzinfos, die es nach deinem System braucht, die müsste ich erfassen. Die Zeit habe ich nicht.
In diesem persönlichen Zusammentreffen wird klar, wenn die technische Eingangsschwelle der Erfassung so hoch angesetzt wird, bekommt man nicht die Daten, die man pflegen will.
1 Like
Welche Schlüsse meinst Du?
Die Daten sind verloren gegangen, als sie durch die Monsterrelation ersetzt wurden, nicht durch die Löschung der Monsterrelation, die schon längere Zeit vorher . Das war aber vermutlich nicht einmal der Ersteller der Monsterrelation. Siehe bitte hierzu auf der Userseite von celsius11 | OpenStreetMap . (Sehe gerade auf der Seite, dass Du offenbar ohnehin im letzten September irgendwie involviert warst, also zumindest doch die ganze Angelegenheit schon seither kennst).
lcn=yes heißt NICHT “nett für das Radfahren”, sondern Zugehörigkeit zum “Lokalen Fahradnetzwerk” (was immer das heißt… ist keine für das gegenwärtige Radnetz in Deutschland erfundene Kategorie). Aber kann man so machen…
Dein Ärger ist in den Posts unübersehbar. Ich kann es nachvollziehen, wenn Du Dich unter Druck gesetzt fühlst, ein komplizierteres Taggingschema zu übernehmen. Das mußt Du ja aber doch überhaupt nicht.
Ich mache keine Vorgaben. Gemappt werden muß überhaupt nicht so komplex, wie ich es tue, und das Schöne ist, dass die verschiedenen Vorgehensweisen ohne Probleme parallel existieren können und auch von Routern sowie Renderern ohne Probleme parallel verstanden werden. Ein allmählicher Übergang wäre problemlos möglich, ich kann mir auch vorstellen, dass zur Vereinfachung plugins für die Editoren programmiert werden können, sobald ein ausreichendes Interesse bestünde.
Nur: Die bisherigen Mappingpraktiken ermöglichen nicht die Identifikation des aktuellen Radnetzes im Kontrast zu alten Daten und anderen Routen ohne eine sehr komplexe lokal individuelle Auswertung der OSM-Daten zu machen (z.T. nur über color-Tags, die die Farben der Schilder wiedergeben usw., oder name-Tags, die komplex geparst werden müßten) . Ebenso ist die Beurteilung, wie alt der jeweilige Datenbestand ist, nur sehr schwierig. Es handelt sich im Gegensatz zum Ausbauzustand der Autostraßen tatsächlich um sehr mühsame Beobachtungen. Daher ist der Datenbestand teilweise sehr alt, und eine automatisierte Qualitätskontrolle (mit Informationen wie z.B. “wo sind Routenabschnitte länger als 5 Jahre nicht überprüft worden?”) sehr hilfreich.
Mein Anliegen ist nur, dass wir irgendwie eine Methode finden, wie man es einheitlich machen könnte. Am besten im Konsens und auf der Basis möglichst geringer Änderungen der jeweiligen lokalen Praktiken, so dass möglichst wenig Änderungen im Gesamtdatenbestand nötig sind.
Zu Celsius11. In einer Mail am 14.10 an mich, schreibst Du, dass er der Ersteller der Relation war.
Da ich die History der Relation auf meinem Rechner habe, er hat die Relation erstellt. 92 Prozent der Edits in der Relation stammen vom ihm. Und das Thema, dass durch das einfache Löschen der Relation, dann die von Celsius11 gelöschten Daten noch gänzlicher verschwinden, war zwischen uns beiden in einem Mailwechsel ein Thema.
Auch wusstest Du schon ohne mich, dass Celsius11 diese Edits in sehr kurzer Zeit durchgezogen hat.
Ich greife mal heraus:
die schon längere Zeit vorher
Der letzte Edit von Celsius11 war am 25.9. Die letzten Relevanten am 28.7. Du hast am 17.10 gelöscht.
Es gab in diesem Mailwechsel zwischen uns beiden auch von dir Überlegungen, wie man diesen Datenverlust verhindern könnte.
Von dem stufenweisen Vorgehen ist in der Relationshistory nichts zu merken. Du hast 2022-10-14T22:24:10Z gelöscht. Das war deine einzige Maßnahme zu der Relation.
Auf den Löschbutton hätte ich genauso drücken können, aber ich habe es nicht getan, weil ich eine Rettung oder Wiederherstellung der Daten auf die Celsius11 zurückgegriffen hat, für wichtig erachtet habe.
Ich habe nicht den Eindruck, dass dir die Rettung dieser Daten sehr wichtig war. Das Verstecken hinter Celsius11 musst Du mit dir selber ausmachen.
Ich fühle mich nicht unter Druck gesetzt. Ich beobachte nur, dass ich immer wieder auf Dinge stoße, bei denen ich mich in so einer dicht besiedelten Gegend wie im Rhein-Main-Gebiet wundere, warum sie, solange nicht korrigiert worden sind.
Warum sind in den drei Monaten nach Löschen der Monsterrelation in Frankfurt so wenige neue Relationen entstanden, obwohl das Wegenetz visuell von prominenten Karten verschwunden ist und Frankfurt quasi blaufrei ist. Findet da eine Abstimmung mit den Füßen statt?
Weil ich habe mal versucht rauszufinden, wie die neueren Konzepte funktionieren könnten. Alle finden es furchtbar wichtig, aber eine simple Schritt-für-Schritt-Anleitung, mit der man nach 10 Minuten loslegen könnte, scheint eine Fehlanzeige zu sein.
Und vielleicht ist diese zwei Zitate ein Ausdruck der Situation.
Ich übersetze: Ich finde es wichtig und toll, aber es könnte mir zu viel Arbeit sein.
Gibt es jemanden der validiert? Ist das nicht der Radler, der feststellt, Wegführung verändert, das trage ich mal ein? Oder hoffst Du auf Menschen, die sich mit JOSM die Relationen anschauen, und dann im Zweifelsfall denn fragwürdigen Abschnitt vor Ort begutachten?
Wie sieht dieser Prozess der Validierung und Wartung des Netzwerkes überhaupt aus? Warum ist er so sinnvoll und wichtig?
Aktuell führen wir gerade eine Diskussion über die Routeneinschübe an Wegweisern, guidepost-nodes, für die ich gerne Anregungen mitnehme: Es geht um die Ergänzung der direction_= Tags um Routeneinschübe, die an einigen Stellen gemacht wurden. (Changeset: 139261262 | OpenStreetMap)
z.B.: direction_northwest=‘Osnabrück 21.0 km; Bifurkation 1.2 km; Wellingholzhausen 7.1 km;; “Else-Werre-Radweg”; “Niedersächsische Mühlen-Tour”’ in Node: 4986/5 (11079042147) | OpenStreetMap
Meine Empfehlung: Eher ein unabhängiges Tag zu verwenden, um die verschiedenartigen Informationen nicht zu vermischen, z.B.:
direction_northwest:route=Niedersächsische Mühlen-Tour; Else-Werre-Radweg
Interessant ist es, tatsächlich die Routeneinschübe vor Ort zu dokumentieren - nicht zuletzt, weil sie oft inkonsistent und fehlerhaft sind. Meine Praxis bisher war, nur die Routenrelationen zu verwenden und ausschließlich Ausschilderungsfehler zu dokumentieren in fix_guidepost=. Wenn ich es dem Betreiber gemeldet habe, auch ein Hinweis zum Ticket und das Datum der Meldung: fix_guidepost:ticket:date= zu hinterlassen.
=================
Inhalt der Changeset-Diskussion:
Segubi:
Ich würde davon abraten, die Routeneinschübe in die Direction-Angaben mit hineinzunehmen. Die Routen werden über Routenrelationen abgebildet. Das Problem ist, dass die “direction” Angaben tatsächlich Ziele beschreiben, also die Routeneinschübe nicht ausgewertet werden. Darüberhinaus ist die Wahl der Namen recht willkürlich und haben ein hohes Risiko, dass sie von Wegweiser zu Wegweiser Varianten aufweisen.
Ich finde aber die Frage tatsächlich ungeklärt, ob und wie man die Routeneinschübe in die Tags aufnehmen sollte, und denke, sie kann gerne weiter diskutiert werden. (Repräsentation des aktuellen offiziellen deutschen Radverkehrsnetzes (nach den Vorgaben der FGSV) in OSM DE:Tag:information=guidepost - OpenStreetMap Wiki DE talk:Tag:information=guidepost - OpenStreetMap Wiki… ). Ich tendiere dazu, diese Zusatzinformationen wegen Redundanz und Unübersichtlichkeit eher wieder rauszunehmen.
… Es muß halt einen zuverlässigen Algorithmus geben, mit dem das Tag so geparst werden kann, dass ein Routeneinschub von einem Ziel unterschieden werden kann. So wie Du es gemacht hast, würde es über die Anführungszeichen funktionieren. Das setzt aber voraus, dass es nie Wegweiser gibt, in denen Anführungszeichen verwendet werden. Das ist schwer garantierbar, auch wenn es sicher nur äußerst selten vorkommen dürfte, wenn überhaupt.
Z.B.: Klappe mal hier die Ziele auf: waymarkedtrails versteht das so nicht. Waymarked Trails - Cycling
Kommentar von GerdP vor 30 Minuten
Die Redundanz ist eher der Grund für das Mapping am Wegweiser. Ich stoße ja andauernd auf alte Relationen, bei denen nicht klar ist, ob die jemals ausgeschildert waren. Ein besseres Verfahren als bei den direction_* Angaben wäre mir auch recht, aber ich habe erst mal so begonnen, um Erfahrungen zu sammeln, wie gut das funktioniert. Die Darstellung in waymarkedtrails ist da für mich erstmal nachrangig. Ich habe aber tatsächlich wieder aufgehört, die Schilder von meiner Radreise zu mappen, da ich wohl sowieso nie wieder in der Gegend neue Routen erfassen werde. Die Idee stammt übrigens nicht von mir, sondern von einem Mapper-Kollegen aus Cloppenburg.
Kommentar von segubi vor weniger als einer Minute
Die Routen, die nicht ausgeschildert sind, gehören sowieso nicht in Openstreetmap und sollten auch gelöscht werden. Das ist soweit auch Konsens. Ich spreche i.d.R. die Ersteller an und frage nach, wie es sich verhält, und dann werden sie meist einvernehmlich gelöscht, wenn es nur ein “Routenvorschlag” ist.
Vielleicht müssen wir uns noch einen Ort für den Austausch mit etwas breiterer Öffentlichkeit suchen. Ich hätte kein Problem, zusätzliche Tags direction_south:route= xyz zu verwenden, das würde das Parsing leichter machen und die Tags direction_south=* blieben abwärtskompatibel.
Es spricht prinzipiell wenig gegen neue Tags, wenn sie funktionieren, und man damit bestehende Taggings schont.
Die Routenrelationen haben einen Key symbol=*, mit dem recht klar deutlich wird, dass es sich um eine ausgeschilderte Route handelt.
Ich finde es aber insgesamt durchaus sinnvoll, die Routeneinschübe zu mappen, und sie befinden sich am Guidepost, also gehören sie auch irgendwie an den entsprechenden node.
Ich kopiere mal gleich die Changesetdiskussion in den genannten Thread im Forum.
2 Likes