DE talk:Tag:information=guidepost

From OpenStreetMap Wiki
Jump to navigation Jump to search

Wegweiser in einem Knotenpunktnetzwerk (rxn_ref)

Ich bin der Meinung, dass man durchaus die Nummer oben auf dem Wegweiser taggen sollte, nach der Regel, dass das in die Karte aufgenommen werden soll, was sichtbar auf dem Boden ist. Der Knoten selbst trägt die Nummer jedenfalls nicht. Es ist Problem der Renderer, sich zu entscheiden, den mit der Rolle "node" versehenen Knoten und dem Tag xyn_ref=13 in der Karte darzustellen und nicht den zugehörigen Wegweiser oder die nach den HBR auch vorgesehene Karte. Da eigentlich die Nummer eine Bezeichnung (oder ein "Name") für den Knoten ist, und keine eindeutige Referenz, hatte ich im Forum auch einmal vorgeschlagen, stattdessen "name=13" zu taggen, letztlich würde das aber im Zweifel zu Redundanzen führen und ein uneinheitliches Tagging derselben Information erzeugen. Siehe auch Diskussion im Forum.

Ich bemühe mich hier mal um eine diplomatische Änderung des Textes...

--Segubi (talk) 21:46, 5 June 2021 (UTC)

Wenn man die Knotenpunktnummer am Wegweiser taggen möchte, dann ist r*n_ref die beste Lösung, weil es konsistent zum Tagging des eigentlichen Knotenpunkts ist und ref=* schon für die Katasternummer verwendet wird.
Dann aber bitte auch die Programmierer der Renderer darauf hinweisen, dass man Wegweiser mit r*n_ref nicht als FKN-Knotenpunkt darstellt. Das ist m. E. der Grund, warum man die Nummer am Wegweiser weglässt. --Jo (talk) 22:54, 5 June 2021 (UTC)
--Jo (talk) 22:54, 5 June 2021 (UTC)
Ist mein Plan. Bzw. einer meiner zu vielen Pläne... ;-), hat nicht die höchste Priorität. Ich hoffe auch ein wenig, dass das hässliche Rendering dazu führt, dass vielleicht auch jemand anders den Hinweis gibt... Ich steig durch die Struktur bei waymarkedtrails noch nicht so ganz durch. --Segubi (talk) 00:45, 6 June 2021 (UTC)

Tabelle, Verwendung von network=*

Die Empfehlung der Verwendung von network=Netzwerkname hat sich gerade auch für snr anscheinend überholt, auch in Leipzig wird inzwischen vorwiegend network=rcn getaggt. Auch im Wiki zu network, Abschnitt Radverkehrsnetze wird ausdrücklich das Gegenteil empfohlen. Im Sinne eines einheitlichen Taggings ändere ich die hiesige Tabelle.

--Segubi (talk) 22:39, 5 June 2021 (UTC)

Guidepost als Routenmarkierung? Eher nicht...

Hallo, User:MalgiK, ich würde nicht sagen, dass information=guidepost verwendet werden sollte für Wegweiser, die nur Themenrouten, aber keine Ziele ausschildern. Die englische Definition im Wiki läßt dies auch gezielt aus. Reine Routenmarkierungen sollten mit information=route_marker dargestellt werden (selten wird auch information=trail_blaze hierfür benutzt. Natürlich werden Themenrouten auch mit aufgeführt. Ich sehe, dass die einleitende Zeile den Verweis auf die Themenrouten schon lange beinhaltet. Ich finde das mißverständlich und würde den einleitenden Satz gerne wie folgt ändern: "Ein touristischer Wegweiser zur Ausweisung bestimmter Zielorte, ggf. auch mit Markierungen von thematischen Routen. Der Vermerk von Wegweisern auf Karten hilft Wanderern, Rad- und Skifahrern bei der Orientierung, z. B. wenn kein GPS-Gerät zur Verfügung steht." In der Beschreibung würde ich es ganz weglassen. Ich betone das, weil eine Inflation von als Wegweisern markierten Zwischenwegweisern äußerst unübersichtlich wird (hat bei mir in der Umgebung mal jemand im Radverkehrsnetz so gemacht), und dann auch niemandem mehr hilft. Bei Wanderrouten kann die Markierungsdichte noch enger sein...

Der Verweis auf osmc:symbol=* könnte verleiten, dieses Tag am Wegweiser zu setzen. Das ist dort aber nicht sinnvoll, da häufig mehrere Symbole vorhanden sind. Die Syntax der osmc:symbol ist ohnehin schon struppig genug, so dass ich auch nicht denke, dass man sie mit Semikolon getrennt aneinanderreihen sollte. Außerdem ist die Information witzlos, da ja auch noch zugeordnet werden müßte, in welche Richtung welches Symbol weisen soll. Da ist die bisherige Praxis, die Symbole den Routenrelationen zuzuordnen wesentlich sinnvoller. Vermutlich hast Du nichts anderes gemeint (in Taginfo hab ich es bis 100 Vorkommen auch nicht gefunden). Ich ergänze da mal eine Klammer. (Man kann natürlich diskutieren, ob es bei information=route_marker nicht doch mehr Sinn macht. Das bleiben natürlich dann mehrere mit Semikolon aneinandergereihte Symbole, aber da wäre die Richtungsinformation nicht so bedeutsam. Hab ich aber auch nicht wirklich gefunden.)

Den Link auf Proposed_features/information verstehe ich nicht, auf der Seite sind erstmal keine Inhalte. Ist der Link ein Versehen?

Grüße, Sebastian --Segubi (talk) 20:33, 3 August 2022 (UTC)

Hallo Sebation @Segubi:, danke für Deine Mitteilung. Ich nehme an, Du beziehst Dich auf diese Änderung. Ich habe die Daten eigentlich nur zusammenkopiert und zwar zum Teil von der EN-Seite und die "reklamierte" Beschreibung von der Data-Item Seite).
Danke - gut aufgepasst. Ich würde das "... oder zur Markierungen von thematischen Routen" von der Beschreibung heutzutage auch rausnehmen, obwohl das von Anbeginn 2015 so drinsteht und dann durch @Kjon: vor Kurzem ins Data-item wanderte. Damals gab es wohl noch kein trail_blaze oder route_marker, oder es war noch nicht dokumentiert. Ändere das gerne so wie vorgeschlagen, oder falls Du der Meinung bist, das eine größere Allgemeinheit drüberschauen sollte, stelle es ins Forum.
Ich hätte nichts dagegen, wenn osmc:symbol=* am Wegweiser sitzt. Auch wenn es dann später redundant am Wegweiser und als Mitglied in einer Routenrelation vorkommt. Ich sehe es ähnlich wie route_ref=* (Die Liniennummern am Bus-Haltestellenschild). Naja die Zuordnung würde dann durch die Einbindung des Wegweisers als Mitglied einer Routenrelation stattfinden, am Wegweiser selbst benötigt es m.E. erst einmal keine Zurodnung. Falls man eine gewisse Zuordnung möchte, könnte man beim Vorkommen von mehreren Einheiten nach der Symbolreihenfolge am Wegweiser von "oben nach unten" im value durch Semikolon getrennt hintereinander wegschreiben. Ähnlich wird es wohl auch bei destination:symbol=* gemacht. Mit der Klammer kann ich leben ;-)
Der Link Proposed_features/information stammt von der EN-Seite aus Überschrift "See also". Dieser Vorschlag wurde archiviert und der Inhalt ist nun zu finden, wenn man dort fast ganz unten auf den Link View proposal content klickt.
Schöne Grüsse! --MalgiK (talk) 22:17, 3 August 2022 (UTC)
Vielen Dank für die Rückmeldung... mit den Data-Items habe ich mich noch nicht so ganz auseinandergesetzt. Sehe jetzt erst, dass die Daten über automatisch ins Wiki übernommen werden. Ich weiß aber nicht, wo die sonst noch landen. Ich bastel lieber nicht im Data-Item herum, solange ich nicht weiß, wofür es gedacht ist. Ich verstehe schon, dass guidepost/signpost eben auch Wegweiser mit einbezieht, die keine Ziele ausweisen. Und dann gibt es noch diese Quervernetzung mit wikidata. Das entfernt sich allerdings mit jeder Etappe weiter vom Tagging. Und es ist auch nicht die Beschreibung von information=guidepost in der Englischen Wikiseite. In der Text selbst bringe ich die Änderung an...
Viele Grüße, --Segubi (talk) 23:10, 3 August 2022 (UTC)
Ist auch nicht so wichtig, die ausformulierte geschriebene Artikelseite ist die Hauptquelle und die Data-Items die machinenlesbare Kopie (letztere wird nun leider als Quelle für die iD-Editor-Hilfeseiten-Verlinkungen benutzt, weswegen ich sie gelegentlich erneuere). Habe die Beschreibung soeben im entsprechenden Data-Item synchronisiert. --MalgiK (talk) 12:32, 6 August 2022 (UTC)

Guidepost=hiking usw.

Habe guidepost=hiking noch nie gesehen. Daher mal die Häufigkeiten für Deutschland geprüft:

  • node[tourism=information][information=guidepost][hiking=yes]: 67323 (97,7%)
  • node[tourism=information][information=guidepost][guidepost=hiking]: 2269 (3,3%)
  • node[tourism=information][information=guidepost][guidepost=hiking][hiking=yes]: 665
  • Anzahl der Wegweiser: 68927

Für bicycle:

  • bicycle=yes 50837 (94,5%)
  • guidepost=bicycle: 7361 (13,7%)
  • beides: 4389
  • Anzahl der Wegweiser: 53809

Ich übernehme mal die etwas zurückhaltendere Empfehlung aus dem Englischen Wiki - aber eigentlich sollte vielleicht noch expliziter empfohlen werden, guidepost=hiking/bicycle nicht mehr zu benutzen. (Deprecate-Proposal? mir leider zu aufwändig). --Segubi (talk) 16:36, 13 October 2022 (UTC)

Umsetzung der Piktogramme

Ich glaube, es ist eine gute Idee, wenn jeder, der Piktogramme der Wegweisung in die Relation aufnimmt, diese auch ins Wiki einträgt, eventuell mit kurzer Info in der Diskussion, eventuell auch mit Diskussion vorab, aber wenn es keinen größeren Nachhall gibt, sie eher auch wirklich in die Seite einpflegt, damit dadurch eine Einheitlichkeit entstehen kann, und nicht viele verschiedene Varianten für das gleiche Piktogramm - die ja im Prinzip Bundesweit verwendet werden, mit allenfalls geringen regionalen Abweichungen. (Farbe, Auswahl und Häufigkeit der verwendeten Piktogramme). Ich würde vorschlagen, für die Piktogramme Kürzel zu verwenden, um die Einträge nicht so lang werden zu lassen (scheint ja auch vorzukommen, dass der Platz noch nicht einmal für die Ziele reicht).

In den HBR-NRW ist festgeschrieben, dass vor dem Ziel immer Piktogramme kommen (sollen), die das Ziel charakterisieren und nach dem Ziel Piktogramme, die die Strecke beschreiben. ("Zielpiktogramme" und "Streckenpiktogramme" im Jargon der HBR-NRW). Ich habe nicht überprüft, wie die Verordnungen der anderen Länder das handhaben. Die Praxis weicht gelegentlich ab, besonders wenn Piktogramme nachträglich aufgeklebt werden. Dann kann schon auch mal ein Zielpiktogramm nach dem Ziel landen. Ich denke, wir sollten es in OSM dennoch nach vorne nehmen, dann wird es für die automatisierte Auswertung leichter. Wer Wert darauf legt, dass die Information, dass das Piktogramm an der falschen Stelle ist, nicht untergeht, sollte es m.E. eher in note=* beschreiben, und optional auch in fix_guidepost=* vermerken, und wenn er wirklich will, dass es geändert wird, einen Spam an ein Meldeportal absetzen (ich denke, es gibt relevantere Fehler...)

Konkret bin ich gerade in Frankfurt auf ein Tag mit "Campus Westend (Universität)" gestoßen (vor 2 Jahren angelegt von User:Torben_), die mir sehr nach so etwas ausgesehen haben. Ich habe die Neigung, die Piktogramme nur zu übertragen, wenn sie nicht redundant sind, auch das ist diskutierbar. (Vor dem Hintergrund, dass man OSM-Daten sowieso nie vollkommen konsistent bekommt, und höhere Ansprüche an die Ausdifferenzierung des Taggings eher dazu führen, dass zwar mehr Daten erhoben werden, aber auch mehr Fehler gemacht werden, und die Daten inkonsistenter werden nach meinem Eindruck).

Für das Piktogramm Universität würde ich vorschlagen, sich auf (Uni) zu beschränken.

Grüße, Sebastian --Segubi (talk) 12:22, 16 October 2022 (UTC)

Siehe auch Diskussion im Forum: https://community.openstreetmap.org/t/reprasentation-des-aktuellen-offiziellen-deutschen-radverkehrsnetzes-nach-den-vorgaben-der-fgsv-in-osm/ . Es gibt noch keine wirklich gute Lösung und das Wiki stellt eher einen unbefriedigenden Ist-Zustand als ein "Soll" dar... (dennoch mit dem Ziel, möglichst transparente und homogene Daten zu erhalten, ohne Informationen, die bereits erfasst sind, zu verlieren).

--Segubi (talk) 16:57, 8 October 2023 (UTC)

Gehe ich richtig in der Annahme, dass mit dem Piktogrammkürzel Fzs für Freizeitstrecke das Piktogramm für nicht-alltagstaugliche Strecken gemeint ist (Wellenlinie mit Baum)? --Bruno413 (talk) 07:42, 9 January 2024 (UTC)
Konnte mir die Frage inzwischen selbst beantworten: Im Handbuch zur Radverkehrsbeschilderung des Landes NRW [1] wird das Piktogramm mit Wellenlinie und Baum als Freizeitstrecke bezeichnet. --Bruno413 (talk) 08:54, 17 January 2024 (UTC)