Siehe auch Hilfe gesucht für Landesfernradwege in Ba-Wü - #14 by GerdP und die folgende Diskussion um mögliche neue Rollen wie “disused”, “planned” etc.
Ich habe dort einige Argumente für die Erfassung der Symboltafeln an den Wegweisern im Zusammenhang erwähnt, ohne explizit auf die verwendeten direction_* Tags einzugehen. Für bessere Vorschläge des Taggings oder die “Absegnung” durch die Community wäre ich dankbar. Die Infos in neue Tags zu packen sollte mir leicht gelingen, sofern sich das hier als besser rausstellt.
Angefangen habe ich im Naturpark Wildeshauser Geest Way: Naturpark Wildeshauser Geest (1028919997) | OpenStreetMap, innerhalbs dieses Gebiets dürften fast alle Wegweiser entsprechend gemappt sein.
Gerade für unvollständige Routen, oder teilweise gut und an manchen stellen schlecht ausgeschilderte etc. wo es schwer operationalisierbar ist, sollte man unbedingt großzügig vom tag “note=*” Gebrauch machen, damit andere Mapper eine Orientierung haben, worum es sich bei dem Objekt handelt.
disused usw. ist ja als Lifecycle prefix - OpenStreetMap Wiki bereits etabliert.
Eine Route, die es nicht mehr gibt, aber mal früher vorhanden war, kann gut als abandoned:route=* getaggt werden. Damit kann man auch Routen markieren, wo einzelne Schilder noch stehen. Hier in meiner Region gibt es z.B. noch https://www.openstreetmap.org/relation/286726 Wege der Weserrenaissance, wo alle 10-20 km nochmal ein Schild hängen geblieben ist, und manchmal auch eher versehentlich in ähnlichen Abständen als Routeneinschub mit an einen Wegweiser frisch wieder eingehängt wurde.
Ich habe gerade mal nach der bisherigen Verwendung von Anführungszeichen in den direction_= Tags geschaut. Die Verwendung ist doch sehr häufig (besonders bei Wanderwegweisern), so dass eine automatische Differenzierung zwischen Zielen und Routen auf die Weise nicht möglich wäre. Das heißt, man muß es anders machen.
In Frage kommen auch die guidepost-Relationen, die ich aber sehr unhandlich finde.
Meine Motivation die Routeneinschübe unter Nutzung des tags “direction_=” zu erfassen war, dass diese wie die meist darüber stehenden Zielangaben zu benachbarten Orten unmittelbar an eine Richtung gebunden sind. Das gewählte Schema habe ich durch Austausch mit GerdP entwickelt und bisher keinen Widerspruch erfahren.
Hauptnutzen der Erfassung war und ist der Fall, dass Routenrelation noch nicht in OSM existieren oder unvollständig erfasst sind. So konnte nach und nach das Routennetz ergänzt werden - ohne gezwungen zu sein, Routen am Stück abzufahren. Ebenso ist einfach überprüfbar, ob der in OSM gewählte Routenverlauf zu der Beschilderung passt.
Die Schwierigkeit der eindeutigen Auswertbarkeit, konnte ich bei den erfassten Schildern bisher nicht beobachten - siehe z.B. hier Node: CLP.048.1 (8241781657) | OpenStreetMap.
Vorschläge für ein passenderes Tag-Schema unterstütze ich. Der Vorschlag von Segubi für direction_northwest:route= finde ich gut.
Sobald ein Schema festgelegt ist, sollte ein “Bereinigen” der zuvor genutzten direction_ tags einfach möglich sein.
Ich hatte Beispiele wie 3671384964 mit direction_northwest=‘Freizeitanlage “Haus Rott” 0.8 km’, 3694744999 mit direction_southwest=‘Schulzentrum “Edith-Stein-Straße” 0.2 km’, 4124133461 direction_west=‘Freilichtmuseum “Zeitsprung” 400 m; Cottbus Chósebuz 15 km; Klinge 0,4 km’ usw. im Blick.
Ok, das ist noch machbar: man müßte dann alle als Routeneinschübe interpretieren, bei denen die Richtungsangabe unmittelbar mit den Anführungszeichen losgeht.
Aber dann gibt es z.B. diesen hier: 6726253464 mit direction_south=‘Seedorf 5,8 km; Route “Am Rand des Schwarzwalds”’. Die Information, dass keine Entfernungsangabe dransteht, ist auch nicht zuverlässig verwertbar, da manchmal einfach keine Entfernungsangaben an den Wegweisern dranstehen, besonders bei sehr kurzen Strecken und Einzelzielwegweisungen.
Ich glaube, ich würde das ein paar Tage abwarten, und mich dann daran machen, die Sachen umzutaggen, sowie im Wiki eine Ergänzung zu den Routeneinschüben zu machen.
Absolut einverstanden! Deswegen finde ich es auch wichtig, dass keine Information verloren geht.
Das ist wirklich eine schwierige Aufgabe, für die ich auch kaum eine gute Lösung habe. Leider sind halt die Routeneinschübe - hier zumindest - Kraut und Rüben. Oft melde ich ersteinmal den Kommunen über die Meldeplattform zurück, dass Fehler vorliegen, die brauchen dann manchmal über ein Jahr, bis sie reagieren und etwas ändern (falls überhaupt). Selbst neue Routen starten erst einmal mit Fehlanlagen. Und meine Lust, offensichtlich falsche Routeneinschübe zu mappen ist sehr begrenzt, daher habei ich mich bislang vor dem Mapping der Einschübe gedrückt, und daher kommt meine Verwendung von fix_guidepost als Tag. Die Routen erschließen sich dann oft erst bei rückwärtigem Befahren oder Interpolieren von Lücken…
Fehler bei den Routeneinschüben habe ich bisher in meiner Gegend nur selten entdeckt, aber ein paar Stellen kenne ich auch, wo offensichtlich die Tafeln von zwei Routen verwechselt wurden: Eine fehlt, eine falsche ist zuviel. Habe die entsprechenden Stellen auch gemeldet, aber es ist noch kein Jahr vergangen und daher noch keine Änderung zu sehen gewesen 
Gut möglich, dass ich es übermäßig wahrnehme… wenn es passiert, hält es ziemlich lange auf. Habe nochmal overpass befragt, etwas über 1500 Guideposts sind von mir zuletzt bearbeitet worden, Fehler habe ich bei etwa 1% eingetragen, nur bei 49 habe ich etwas zu den Routeneinschüben moniert (da habe ich aber noch einen Überhang, den ich noch nicht eingearbeitet habe). Also… eher selten Fehler ;-)…
Nach einigem Nachdenken neige ich eher zu direction_:symbol als zu direction_:route. Keine Ahnung, wie verbreitet diese Einschubtafeln in anderen Ländern sind, ich kenne die vor allem aus D, aber ich glaube, in Österreich ist es ähnlich, müsste mal meine alen Fotos sichten. Als Bezeichnung für die Dinger kennen ich auch noch “Fähnchen” oder Dein “Routeneinschub”.
Bevor man es offiziell im wiki dokumentiert: Hier ein paar mögliche Problemfälle für Mapper:
- In vielen (den meisten?) Gegenden werden die Nummern der Nachbarknoten von Knotenpunktnetzwerken auch bei den Themenrouten “eingeschoben”. Hier solte man klären, ob man die mit erfasst und wenn ja:
- nur die Nummer (mein Favorit) oder
- die dadurch ausgedrückte Knotenroute. Bei einem Zwischenwegweiser der KP-Route 5-28 hätte man dann etweder “5” und “28” oder zweimal “5-28” (oder nur 5 und 28 bzw. 5-28)
- Wie man mit Symbolen umgeht, für die es noch keine Relation gibt und für die man (noch) keinen Namen hat. Siehe z.B. Name der Route? Schwarze Karnevalsmaske auf weißem Grund
Ich habe noch so einen ähnlichen Fall, wo auf dem Schild kein Name steht, Symbol ist ein alter Mann mit Hut, ich glaube, so habe ich es auch erfasst und eine entsprechend note drangehängt. - Im Südwesten Niedersachsens findet man oft Routen, die (im Internet) einen langen Namen haben, aber nur mit z.B. mit “BR 3” oder anderen Kürzeln (also der ref=*) ausgeschildert sind. Ich habe dann dieses Kürzel gemappt. In Bremen findet man eine Mischung aus beidem: Name der Route und Kürzel. Zum Beispiel die Route “H5 - Grün und Grenzenlos” hat eine Tafel, auf der "Grün und Grenzenlos steht und darunter in anderer Schrift “Grüner Ring H5”. Mit war da noch nicht klar, ob die ref zum Namen gehört oder nicht. Den Namen der Route werde ich wohl noch ändern und dann evtl. auch die Texte zu allen Wegweisern. (Hier ist diese Redundanz nachtürlich echt anstrengend, vor allem, weil man nicht so einfach ersetzen kann. Ich mache das daher mit JOSM in 4 Schritten: a) Alle zu änderden Knoten mit einem temporären Tag versehen, so dass sie als geändert markiert sind. Dann die Objekte als *.osm speichern. b) Mit Notepad die Änderungen an der *.osm durchführen und danach c) die Datei wieder in JOSM laden und das tempöräre tag löschen. d) Nochmal prüfen, ob Texte mit Umlauten richtig sind und dann hochladen.
- Im Raum Osnabrück findet man fast an jedem Wegweiser und oft (immer?) in alle Richtungen eine Tafel, die zuerst wie ein Themenroute aussieht, aber doch nur das Radwegenetz in Osnabrück beschreibt. Hier zum Bespiel in der Nähe des Bahnhofs Bramsche:
Ich habe diese Tafeln bisher nicht erfasst, aber einen guten Grund habe ich dafür auch nicht. Vermutlich wird an den Grenzen des Osnabrücker Gebiets manchmal nicht in jede Richtung so ein Schild dran gehängt?
In NRW scheint es gleich mehrere solcher Netze zu geben, die dann an fast allen Wegweisern auftauchen, z.B. die “NiederRheinroute” Relation: NiederRheinroute (5406832) | OpenStreetMap.
Die Symbole unterscheiden sich vielleicht geringfügig durch Farben und manchmal zusätzlich Nummern, wenn ich das richtig verstanden habe, aber diese “Netze” sind eigentlich keine Routen. Habe das aber nur auf Radreisen kennengelernt, da sollte man die Experten vor Ort noch mal fragen.
5. Haben die Symbole eine Reihenfolge? Die meisten dieser Tafeln kann man ja von vorne und hinten lesen, daher ist es nicht offensichtlich, in welcher Reihenfolge man die mappt. Ich dachte zunächst, immer vom Pfosten aus zu starten und dann nach aussen weiter, aber es gibt ja auch Schilder, die in der Mitte am Pfosten befestigt sind. @jmsbert hat vorgeschlagen, sie immer alphabetisch zu ordnen. Das habe ich dann so gemacht, aber notwendig finde ich es nicht.
6. Bei information=route_marker gibt es auch unterschiedliche Varianten, wie mit Themenrouten umgegangen wird. Ich kenne da bisher
- Tafeln mit Pfeil (grün auf weiß oder rot auf weiß)
- Tafeln für eine bestimmte Route, also Pfeil und Namen einer Route, z.B. für Hunteweg oder Brückenradweg. Scheint aber veraltet.
- Tafeln mit Pfeil und mehr oder weniger vielen Routen-Symbolen, die denen an den Wegweisern entsprechen.
Ich habe die Liste der Symbole bisher nur in eine note=* gepackt. Interessant in diesem Zusammenhang sind Routen, die nur in einer Richtung ausgeschildert sind. Da sind dann entsprechend unterschiedliche Listen auf Markern an der der gleichen Kreuzung.
- Welchen Text erfasst man? Nimmt man genau das, was auf dem Schild steht (falls überhaupt), oder, wenn schon eine Relation vorhanden ist, den Text, der dort als name=* angegeben ist? Ich habe da noch keine klare Präferenz.
Beispiel: Auf den Symboltafeln zur Relation https://www.osm.org/relation/151754 https://www.osm.org/relation/151754 finde ich “Hunteweg” und darunter “Fernradweg”.
Wie umgehen mit Routen, die mehrsprachig “benamst” sind, aber keinen Text auf der Symboltafel haben? Beispiel: Diese Route https://www.osm.org/relation/2073135 wird durch eine Symboltafel ausgewiesen, auf der ein Leuchtturm zu sehen ist, aber kein Text. Ich war da erstmal mit meinem Latein am Ende. Würde man dann in D “Fietsallee am Nordkanal” mappen und in NL “Fietsallee langs de Noordervaart”?
Ich werde zunächst mal mit dem bisher verwendeten Verfahren weiter machen. Zumindest im Raum Niedersachsen habe ich noch sehr viele Fotos nicht verdatet, möchte das aber noch tun. Den Rest von D habe ich eher als Forschungsreise betrachtet, um mal über den Tellerrand zu schauen. Wie immer bei OSM: Je mehr Fälle man kennt, desto weniger sicher ist man sich 
(Zentrale Messages zuerst:
- Bitte nicht zuviel Aufwand in die Routeneinschübe stecken!
- Zielsetzung des Projektes im Auge behalten: Die Wartung und Überprüfbarkeit der Routen zu verbessern
- Grundlegende Ziele: Auswertbare Daten zu behalten. Taggingaufwand soweit im Rahmen zu halten, dass man mit den stetigen Änderungen on the ground halbwegs Schritt halten kann
- Das Tagging der nummerierten Knotenpunkte hierbei außen vor zu lassen).
Zu Details:
… ich sehe die ganzen Punkte und Schwierigkeiten und stimme zu, Du nennst damit viele Gründe, warum ich bisher die Finger davon gelassen hatte. Ich habe in der Konsequenz mich aber eben auch vorwiegend um lokale und halbwegs zu bewältigende regionale Routen kümmern können, wie schon erwähnt. Das Mappen der Routeneinschübe (dann ist es übrigens sinnvoll, ein survey:date=* mit einzufügen, so weiß man schon im Node, wie alt die Info ist, und muß nicht die Changesets und Metadaten mit beurteilen), ist ja offenbar aus der Problematik heraus entstanden.
“Routeneinschub” ist die offizielle Bezeichnung in den “Hinweise zur wegweisenden Beschilderung für den Radverkehr” in NRW, die als Verwaltungserlass rechtsverbindlichen Status haben, daher nutze ich recht konsequent die entsprechenden Begriffe. In den anderen Bundesländern sehen die Schilder ähnlich bis identisch aus, der Rechtsstatus ist mir allerdings nicht so klar geworden, das System ist im Grunde ja dasselbe: Zielwegweisung (weitgehend, NRW: gefordert, aber auch nicht 100% umgesetzt) konsequent für jede Richtung an jeder Aufzweigung angegeben, Routenwegweisung zusätzlich als Einschübe. Zwischen Aufzweigungen Wegweisung durch kleinere Zwischenwegweiser (auch technisch definierter Begriff). Ich habe versucht, die HBR und de facto Situation soweit sie mir begegnet ist, auf meiner Userseite zusammenzufassen.
Knotenpunktnetzwerke
Hier gibt es schon viele Wegweiser, es gibt in Deutschland leicht konkurrierende Taggingschemata, die ich nicht anrühren wollte. Mir geht es aktuell darum, ein neu auftretendes Phänomen (Mappen der Routeneinschübe) frühzeitig zu ordnen. Da Knotenpunktnetzwerke ein internationales Phänomen sind, ist die Angelegenheit komplexer. (s. Wiki). Eins von mehreren etablierten Schemata ist, die Knotenpunkte in die direction=* tags mit aufzunehmen als “KP xy”. Das hat seinen Sinn bei der Auswertung der Wegweiser, dass die Knotenpunkte auch als “Ziel” erfasst werden.
In NRW ist vorgegeben, das die Zwischenwegweiser keine Routenangaben enthalten, insofern auch nicht die KP-Routen, und sollten auch nicht getaggt werden.
Bezeichnungen für Routen/Routeneinschübe
Auch das ist einer der Gründe, warum ich die Routeneinschübe ungern mappe. Es gibt viele verschiedene Möglichkeiten, textkodiert einen Routeneinschub zu bezeichnen. Bei einer Route habe ich es mal so gemacht, dass ich verifiziert habe, ob in den regionalen Routenrelationen schon ein Anfang gemacht worden ist, nachdem ich nichts finden konnte, habe ich die Routenrelation angelegt, das Logo dort unter symbol beschrieben und in der note angemerkt, was ich wußte.
An einer anderen Stelle habe ich einfach am guidepost die Routeneinschübe mit note=“Hier finden sich noch Routeneinschübe R3 und R14”, wobei es keinerlei Routenrelation gab, auf die es sich hätte beziehen können.
Gut ist es hierbei, sich mit dem “Erfinder” von Namen und Ref ins Einvernehmen zu setzen, um keinen Editwar zu provozieren. Da gibt es schon manchmal ziemlichen Streit drum, ob die “ref” objektiv verifizierbar sein muß. In der Regel haben die Routen vom Betreiber einen Namen bekommen, den man nicht unbedingt an den Wegweisern erschließen kann. Wenn diese Route mit z.B. “H5” ausgeschildert ist, ist das wenigstens klar die Referenz.
Jap, der Kreis Osnabrück hat das überall drangehängt… Das würde ich auf keinen Fall mappen. Im Moment wird die Information auch dadurch abgebildet, dass zumindest die unbenannten Routen in einer Relation zusammengefaßt sind. Wer es unbedingt mappen will, könnte das über das Tag cycle_network machen. Das allerdings völlig unsystematisch verwendet wird. Inhaltlich wäre das passend.
Zwischenwegweiser
Für NRW gibt es immerhin inzwischen behördliche Vorgaben. Es sind nur reine Routenmarkierungen ohne Routensymbole zugelassen, “Routenabzweiger” - roter Pfeil mit Routensymbol dürfen nur als Bestandssicherung für alte Routen benutzt werden. Und: natürlich gibt es Fahrradrouten OHNE offiziellen Charakter! Das ist der Ausgangspunkt für diesen Thread: “Wie Taggen wir die OFFIZIELLEN Routen?”
Es gibt dennoch unglaublich viele alte Routen, die noch anderen Regeln folgen, aber man sollte im Blick haben, dass diese sozusagen “deprecated” sind.
Die “NiederRheinroute” ist als Ganzes keine Route im OSM-Sinn, sondern ein Netzwerk und entsprechend type=network und nicht type=route getaggt.
Der Rest scheint tatsächlich eine fortlaufende Route über die ganze Fläche zu sein. Dazu gibt es Querverbindungen, die anscheinend Nummern haben (soweit die Daten in OSM).
Kein Wunder, dass man überall auf die Route stößt… Das ist aber nicht NRW-typisch, denke ich, sondern die Konzeptidee am Niederrhein. So wie es mal das “Waben-Konzept” im Münsterland gab, das wieder abgebaut worden ist, oder ein Ringe-System in Bünde, wovon die Ringe noch erhalten sind (und nicht 100% HBR-Konform ausgeschildert sind).
Schluss:
Das Ringsystem in Bünde nehme ich für einen Abschluss des überlangen Posts: Die Ringe habe ich an den Wegweisern nicht gemappt, sondern nur die Relationen erstellt, und halte das auch für überflüssig, obwohl da überall die Nummern der Ringe hinter den Zielen stehen:
Meine Praxis ist, Informationen zu markieren, die nützlich sind (für mich im Prozess interessantere Dinge zu mappen; oder direkt schon für andere nützlich). Die Routeneinschübe halte ich für flächendeckendes Tagging für zu aufwändig. Hier werden jedes Jahr Wege umgebaut, das hätte die Konsequenz, dass die Routeneinschübe schnell veralten und der Datenbestand wertlos wird. Das heißt, man sollte sich bewußt sein, dass diese Daten z.T. nur einen Interimscharakter haben. Die Fehleranfälligkeit ist hoch, weil die grafische Information nicht zuverlässig durch einen Text abgebildet werden kann. (Name der Relation? Ref. der Relation? Beschreibung des Logos).
Die Information über den Routenverlauf für den Endanwender gehört in die Routenrelation. Insofern sind die Routeneinschübe selbst redundant, wenn sie zusätzlich an den Wegweisern gemappt werden.
Daher halte ich es für sinnvoll, sie unabhängig von den Zielangaben in eigene Tags unterzubringen, damit sie nicht die anderen, stabileren Informationen überlagern. (Die Routeneinschübe haben ja den Zweck der leichten Austauschbarkeit, um Routen schnell um- und neu gestalten zu können, ohne das Grundnetzwerk ändern zu müssen). Meine persönliche Praxis war, in unabhängigen Tags auf Diskrepanzen hinzuweisen. (note, fix_guidepost)
Wie das Tag genau heißt, ist letztlich egal, und wenn der nächste User einfach eins verwendet, sollte er durchaus im Wiki (DE:Bicycle/Fahrradrouten kartieren - OpenStreetMap Wiki und Key:direction_north - OpenStreetMap Wiki https://wiki.openstreetmap.org/wiki/Key:direction_north:myextension) darauf hinweisen, damit die übernächste Userin nicht ein anderes für den gleichen Zweck erfindet. Eine Erläuterung hierzu und Verweis auf den thread hier, sollte in der Diskussion gegeben werden. (+ Erwähnung hier ist natürlich sicher sinnvoll. Das wiki ist groß, Einträge werden schnell übersehen).
Liebe Grüße, und sorry für die Länge…
Oder führe adhoc das neue Tag ein (Der Umbau in die andere Richtung und die Umbenennung des Tags ist einfacher als das Parsen der Routeneinschübe aus den direction-Einträgen!)
Ich kenne das, dass die Radtour weniger Zeit braucht als die Datenverarbeitung danach. So sollte es eigentlich nicht sein…
Wollte gerade mit direction_northeast:symbol loslegen, aber so recht gefallen tut mir das auch nicht. Man beschreibt ja nicht die Symbole, sondern die Bedeutung derselben. Also wohl doch eher so was wie
direction_northeast:route
Ich würde da aber eher die Mehrzahl verwenden, also direction_northeast:routes. Diese Variante wird bisher anscheinend auch noch nicht verwendet.
Sollen die doppelten Hochkomma dann bleiben oder nicht? Also
- direction_northeast:routes=“Alfsee-Tour”; “Artland-Rad-Tour”; “Bauernhof Tour”; “Hügeltour”; “Land-Schaft-Kultur”; “NordWestBahn-Tour”
oder einfacher (und mein Favorit) - direction_northeast:routes=Alfsee-Tour; Artland-Rad-Tour; Bauernhof Tour; Hügeltour; Land-Schaft-Kultur; NordWestBahn-Tour
Zumindest bisher ist mir nie ein Semikolon in den Namen untergekommen, die doppelten Hochkomma sind also wohl eher nicht nötig.
direction_*:route oder routes finde ich beides auch ok. Ob es da eine übliche Regel für Singular oder Plural gibt, weiß ich nicht.
Ich würde auf jeden Fall möglichst bald eine (zunächst englische, da direkt für jeden zu finden) Wiki-Seite anlegen und die Seite direction_north, die es als Sammelseite gibt, entsprechend ergänzen.
Ich würde auf die Seite eine Beschreibung dessen packen, was Du tust, damit andere, die das Verfahren übernehmen, es genauso machen. Wichtig finde ich, dass grundsätzlich für die Guidepost-nodes gilt: Es wird nur das getaggt, was tatsächlich sichtbar ist. Das ist der Grund, warum ich symbol zunächst naheliegender als route(s) finde, man beschreibt ja eben doch die Symbole, in dem man die Namen der Route referenziert.
Es sollte kein Routentag gesetzt werden, wenn es am Wegweiser fehlt. (Das ist bei Wegweisern mit nur 2 Richtungen recht häufig). Genauso wie man ja auch Schreibfehler auf dem Schild in der Regel übernehmen soll. Von der Regel kann man abweichen, wenn man das in note=* genauer erklärt. Ich würde hier es aber eher so machen, dass ich in Note hineinschreiben würde: Routenverlauf xy-Route nach NW, entsprechender Einschub fehlt. (Wenn man sowieso nur daran vorbeifährt, kann man es ja oft auch nicht wissen.)
Ich halte es für sinnvoll, dann auf die Anführungszeichen zu verzichten und entsprechend dem Gebrauch in anderen Tags mit Semikolon trennen, so wie dein zweiter Vorschlag. Ich glaube, es ist zwar relativ viel Text, aber gut nachvollziehbar, wenn man das name=* Tag aus der entsprechenden Routenrelation als Bezeichner im Tag direction_:routes= benutzt. (Auch das würde ich im Wiki so beschreiben.) Alternativ ginge ref, aber ref ist nicht immer gesetzt und z.T. umstritten, wenn es ein willkürlich gewählter Wert ist, und auch nicht immer ganz eindeutig. (Hier z.B. gibt es doubletten der Referenzen Rxy: Altes “R-Netz-NRW” und “Rxy” Rundwege).
Würde ich dann genau so empfehlen.
Der Plural würde zumindest gleich klarer machen, dass man es mit Werte-Listen zu tun hat.
Da kenn ich mich nun wieder gar nicht aus. Ich habe bisher nur einzelne Texte in Wiki-Seiten bearbeitet.
Den ganzen Formalismus möchte ich mir bei diesem Nice-To-Have eher nicht antun.
Erstmal Hallo zusammen, habe bisher nur mitgelesen.
Ich habe mal auf meiner Benutzerseite einen ersten Entwurf erstellt, den könnte man diskutieren und verschieben, wenn wir uns über den Namen des Keys einig sind.
Ich wäre auch dafür den name=* der Routen zu erfassen, aber dann müsste man diese Namen am besten nochmal überprüfen, beispielsweise ist bei D8 Rhein-Route die ref=* mit drin.
Ich habe gestern meine ersten Wegweiser nach dem neuen Verfahren erfasst und ein paar vorhandene geändert. Die langen Schlüssel sind ziemlich unpraktisch, wenn man viel mit der Tastatur arbeitet, weil die Auto-Vervollständigung meist was falsches vorschlägt, aber das ist wohl eher mein Problem. Für Brillenträger wie mich sind die zwei Keys
direction_northwest:routes
direction_northeast:routes
sehr leicht zu verwechseln, auch in Auswahllisten. Praktischer für die Eingabe wäre es, z.B. nur dnwr oder dnwe einzugeben und JOSM machte dann daraus die langen Schlüssel. Kenne aber keine solche Funktion in JOSM.
Zum Konvertieren der alten Tags: Es dürfte allein bei mir um knapp 2000 Knoten gehen. Kennt jemand ein gutes Tool für so was? Mit osmconvert scheint es nicht zu gehen, mit einem Text-Editor ist es auch nicht trivial.
Sollen die Nummern für Knotenpunkte jetzt rein in die Liste oder nicht? Im Wiki-Entwurf sind sie drin. Bin hin-und hergerissen…
Der übliche Weg sind Keys in der Einzahl, daran sollte man sich auch hier halten. Es heißt ja auch nicht destinations oder directions_north.
Ich würde das zunächst einfach nur auf der Seite von direction_north erwähnen und entsprechende redirects anlegen. Wir sollten dann gleich einen Abschnitt “Further Details” anlegen für direction_*:ref, direction_*:route und direction_*:symbol.
1 Like
Man muss aufpassen, dass man “symbol” nicht doppelt benutzt - meistens ist es wohl das Symbol neben den Zielen.
Die Symbole der Routen sehe ich eher an den Routen-Relationen selbst und nicht an jedem der potentiell hundert Wegweiser der Route. Wenn man den Wegweiser mit in die Relation aufnimmt, dann ist der Zusammenhang auch in der Auswertung problemlos zu finden.
Das kann man machen, wenn es eine Relation gibt. Ist aber sehr oft nicht der Fall. Ich bin dann immer unsicher, ob ich für einen Abbschnitt von vielleicht 1 km gleich eine Relation mit fixme=incomplete anlegen soll, die dann vielleicht niemals vervollständigt wird. Abgesehen davon geht es aber ja gerade darum, den Verlauf der Route redundant zu dokumentieren.
Die meisten Keys sind wohl in der Einzahl, weil wir ja in OSM meist ein reales Objekt mit einem OSM Objekt beschreiben. Ich hatte da turn:lanes im Kopf, ist aber ein schlechtes Beispiel, weil dort | als Trenner verwendet wird. Dein Argument mit destination versus destinations überzeugt mich.