Es wird ja niemand gezwungen nach PTv2 zu mappen. Man sollte PTv2-Mapping aber auch nicht halbherzig machen.
Da railway=station nur wegen des hinzugefügten public_transport=station in die stop_area darf, möchte ich die Gelegenheit nutzen, um auf ein sehr verbreitetes Missverständnis zu public_transport=station hinzuweisen. Es ist nicht entsprechend zu railway=station. railway=station ist der Zentralnode des Bahnhofs. public_transport=station ist eine Fläche, die der Nutzung öffentlicher Verkehrsmittel gewidmet ist. In dieser Fläche können Teile mehrerer stop_areas liegen.
Mentz AG hatte mal angefangen, den Namen von Plattformen nach “description=" zu verschieben und "name=” zu verbieten. Diskutiert würde darüber aber wenig und mich hat es nicht überzeugt. Auch bei existierender stop_area Relation, schadet der gleiche Name an den Kinderobjekten nicht.
Zumindest bei Plattformen als Flächen sieht das bei OSM-Carto nicht toll aus, wenn der Name gesetzt ist, aber das ist ein anderes Thema.
Leider habe ich den Überblick verloren, wie bei Plattformen und Stoppositionen die genaue Vergabe von “name”, “official_name”, “short_name”, “long_name”, “alt_name” und “loc_name” sein soll. Bei dann zum Teil bis zu fünf unterschiedlichen Namen in den GTFS-Daten von fünf unterschiedlichen Betreiberfirmen weiß ich auch nicht weiter. Wenn dann noch nur unterschiedliche Plattformen in den Datensätzen beschrieben werden habe ich auch nicht mehr identische “gtfs:name” und “gtfs:feed” und bei der stop_area wo möglich Konflikte mit den Kindern.
Können wir bei diesem Thema ein bisschen Licht ins Dunkle bringen und dies dann auch Dokumentieren? Danke.
Vielleicht kann die Rolle “label” für den Zentralnode verwendet werden, analog zu Grenzrelationen.
großartig 
Der Namensbereich ist eher ein allgemeines OSM-Problem und hat nur wenige Besonderheiten im ÖPV.
PTv2 sagt dazu wenig: in PTv2 wird nur “name” erwähnt. Und auch bei “name” geht es in PTv2-Routen nur um die Gleichheit, wenn ein Eintrag der Rolle “platform”, “platform_entry_only” oder “platform_exit_only” auf einen Eintrag der Rolle “stop”, “stop_entry_only” oder “stop_exit_only” unmittelbar folgt. Bei Gleichheit sind es zwei Einträge zu einem Halt der Route und sonst sind es zwei Halte. (Fehlt “name” im Objekt wird dabei der “name” aus der evtl. vorhandenen Stop_Area genommen. )
“ref_name” ist vielleicht außer “name” das einzige mit besonderem Bezug zum ÖPV. Dass man beim Nachschlagen von Haltestellennamen im Internet mehrere Möglichkeiten zur Auswahl bekommt ist ja normal. Aber bei Haltestellen mit Namen wie “Bahnhof”, “Rathaus” oder “Friedhof” gibt es einfach zu viele. Da sollte dann “ref_name” so gesetzt werden, dass man die Haltestelle bei allen üblichen Internetquellen finden kann. Besondere Regeln für Deutschland wie im Wiki oder das Eintragen an jeder Haltestelle finde ich persönlich unsinnig.
Ein Name fehlt uns im ÖPV-Bereich: der Name wie er auf dem Schild steht. Nicht jeder Reisende nach “Benrath Betriebshof” begreift rechtzeitig dass er jetzt aussteigen sollte, wenn das Schild “Benrath Btf” sichtbar wird … der nimmt dann bei der nächsten Reise vielleicht doch lieber wieder sein Auto …
Guter Punkt, normalerweise, so wie ich OSM bzgl. “on-the-ground” Schema verstanden hatte, ist dafür “name” reserviert. (Der Text des Schildes ist das, was otg zuerst erkannt wird.) Wenn beim ÖPNV nicht otg => name ist, wäre die Begründung interessant und auch m.E. wert im wiki zu notieren.
Edit: Oder zählen diese “name” Anpassungen (Unterscheidungen zum Schildtext) etwa bereits zur Ausnahme:? https://wiki.openstreetmap.org/wiki/DE:Names#Abk.C3.BCrzungen_.28nicht_verwenden.21.29
Ich denke, wir sollten in ‘name’ immer die ausgeschriebene Variante nehmen, unabhängig davon was auf dem Schild steht.
PTNA versucht solche Namen (in GTFS) zu ‘normalisieren’, und wenn ich da an “Höhenk.-Sieg.” in GTFS denke, grauts mir.
Ich denke, dass solche Abkürzungen im ÖPV auch technischen Limitierungen geschuldet sind, denn wie will man “Höhenkirchen-Siegertsbrunn” vorne beim Bus in der Anzeige unterbringen. Die Namen in GTFS sind z.T. auch nicht konsistent, wenn ich an die verschiedenen Abkürzungen für “Abzweig” denke.
Ja … allein schon deshalb, weil das in OSM immer gilt und der ÖPV keine Extrawurst bekommen sollte.
Aber die Angabe vom Schild könnte man auch gut brauchen. Wie schon gesagt erkennt nicht jeder “Benrath Betriebshof” in der Beschriftung “Benrath Btf” und noch weniger wissen, dass es keinesfalls “Benrath Bf” ist. Bei einem Schild mit kyrillischen oder chinesischen Schriftzeichen hätte ich gern was auf dem Smartphone, dass ich direkt vergleichen kann. Das wäre also noch ein “xxx_name” auch wenn wir schon einen großen Haufen davon haben.
@ToniE & Weide
Nochmal, war wohl oben nicht ganz deutlich was ich gemeint habe. Es gibt wohl 2 Fälle bei denen sich otg-Schildtext und “name”/web-Suchmaschinentext (beim ÖPNV) ab und zu scheinbar unterscheiden.
a) Abkürzungen , Beispiel: otg-Schildtext: “Benrath Btf” zu “name”: “Benrath Betriebshof”. Ja da stimme ich zu “keine Extrawurst” und ja gerne einen separates Merkmal in dem der otg-Schildtext erfasst wird
aber wie sieht es aus bei
b) Beispiel: otg-Schildtext: “Mühle” dagegen web-Suchmaschinentext “Adorf Mühle”
Der otg’ler schreibt name=Mühle, der der die ÖPNV Daten ggf. vom Sessel homogenisieren möchte schreibt name=“Adorf Mühle”, dann kommt wieder jemand vor Ort vorbei und denkt, na da wurde wohl der Schildtext aktualisiert und packt wieder name=Mühle hin, usw. usf. Das zählt doch nicht zu den Abkürzungen und falls das legitim und Konsens ist, darf diese otg-name-Ausnahme von mir aus gerne mit auf Key:name notiert werden.
Von mir aus kann “Benrath Btf” nach “ref_name”, dann wird’s auch so gefunden.
da kommt “Adorf Mühle” dann in “ref_name” rein.
Genau, denn “Mühle” ist keine Abkürzung, nur ein nicht sehr eindeutiger Name.
Was ist der Unterschied zu “uic_name”? Hatte ich bewusst weggelassen.
Können wir die beiden Fälle jetzt in einem Aufwasch lösen?
- Wir brauchen einen Schlüssel für “on the ground” Name. Wahrscheinlich ist es besser einen neuen zu verwenden als einen existierenden zurecht zu deuten. “name:pole”?
- Wir sollten uns über eine Ausnahme der otg-Regel für ÖPV Objekte einigen oder den zu verwenden Namen-Schlüssel finden.
- All dies sollte dann auf allen relevanten Seiten so dokumentiert werden, angefangen von den PT-Seiten bis hin zu “name=*”.
Bei den route und route-master Relationen können wir dann gleich weiter machen und die Namen aus dem GTFS und den unterschiedlichen Online- bzw Printmedien Schlüsseln zuordnen.
Da allein aus Platzgründen sowohl auf dem Schild als auch in etlichen Quellen häufig Abkürzungen beider Arten vorkommen wird im ländlichen Bereich häufig eine Ortsbezeichnung vorangestellt. Gleiches gilt für “Bahnhof” oder “Hauptbahnhof” und häufig “Rathaus”. In Städten müsste ich mich allerdings erst einmal an die Ortsbezeichnungen bei z.B. jeder Haltestelle gewöhnen. Woraus genau die Ortsbezeichnung sich ergibt ist auch noch zu klären. Ist das der Stadt-/Ortsteil, der Ort/Bezirk oder die Gemeinde/Stadt?
Das verstehe ich nicht.
Wenn ref_name existiert, dann wird nicht nach “name” sondern nach “ref_name” im Internet gesucht. Warum sollte man die Suche nach “Benrath Betriebshof” für sinnlos erklären und statt dessen nach “Benrath Btf” suchen lassen?
Und niemand, der die Schildbezeichnung angeben will (z.B. in einer App: steig nach der Haltestelle ‘xxx’ aus") wird dafür ref_name statt name angeben. Wenn ref_name existiert, dann ist da meist etwas zu name hinzugefügt, dass gerade eben nicht auf dem Schild steht.
Stimmt, du hast Recht, war zu kurz gedacht.
Ist möglicherweise sogar kontraproduktiv, denn wenn “ref_name” existiert und die erste Wahl bei der Suche ist und “Benrath Btf” drinsteht wird’s womöglich sogar noch nicht einmal gefunden.
Da das rein situationsabhängig ist, kann man da m. E. keine eindeutige Regel aufstellen.
Überwiegend ist das m. E. nur bei Überlandlinien - also in zersiedelten Bereichen - überhaupt der Fall.
Dort kenne ich bislang nur den Ortsnamen - wobei das eben auch ein Ortsteil einer Gemeinde sein kann, wenn sowohl Hauptort wie Ortsteil eine Haltestelle Kirche/Schule/Bahnhof etc. haben.
Finde ich auch (Ich nehm mal an, dass um “ref_name” geht). Da muss man einfach sehen, welche Formulierung bei allen üblichen Internet-Quellen funktioniert.
Bitte einmal an diesem Bild erklären, was wohin gehört:
Möglichst detailliert für Eintragung der Haltestelle und des Busstop (der praktisch aber nicht an dem Mast ist, da der Bus dann mit seinem Ende noch nicht in der Bustasche ist).
ein node mit highway=bus_stop shelter=yes name=… an die Stelle des H-Schilds, ggf. noch den Mülleimer taggen.
Ich bin ja eher ein Freund von expliziter Erfassung von POI’s (Also wenn es eine Sitzbank an der Haltestelle gibt, dann setze ich eher einen Extraknoten amenity=bench, anstatt am Objekt public_transport=platform neben der Strasse ein bench=yes ranzusetzen. Apropos würde die Variante Extraknoten amenity=bench und public_transport=platform + bench=yes dann als 2 Bänke gelten?)
Aber wenn man hier sowieso schon von der Regel abweicht, das otg ins “name” kommt, dann könnte man ggf. die otg-Info’ vom Extraknoten (traffic_sign=DE:224 & name=* (otg)) an einen separaten Knoten (highway=bus_stop oder public_transport=platform) wie “name:traffic_sign=*” (otg) nutzen?
Oder eben irgendwie abgeleitet davon, wie es bei den Ortseingangsschildern mit name gemacht wird.
Als Datenpunkt für die Diskussion, in Italien machen wir in “name” der Bushaltestelle genau das rein, was auch an der Haltestelle steht (sofern da alles in Großbuchstaben steht, normalisieren wir das hinsichtlich dessen, aber mehr auch nicht).
Vielleicht wird das international ja noch an mehr Orten so gemacht.