ÖPNV in Germany

Bei Bushaltestellen sollte ein highway=bus_stop an der ungefähren Stelle des Haltestellenschilds ausreichen, alles andere (platform, stop_position, etc.) kann man machen, ist aber nicht unbedingt erforderlich.

Für die Linien ist glaube ich Standard, pro Richtung und pro Variante eine Relation zu erstellen und diese dann über eine route_master Relation zusammenzufassen.

Als „Nichtexperte“ gebe ich meine Erfahrung wie folg weiter:
Bei einer Bushaltestelle gibt es zwei Stellen. An einer Stelle (auf der Fahrbahn) hält der Bus, an der anderen Stelle (neben der Fahrbahn) warten die Fahrgäste.
Wie die Haltestelle anzulegen ist, wird. z.B. auf der Seite https://wiki.openstreetmap.org/wiki/DE:Public_transport beschrieben. Auf dieser Seite steht u.a. auch:
„Insgesamt macht das Mappen des Bussteigs bzw. des Haltestellenschildes bei gleichzeitigem Weglassen der Halteposition den größten Sinn.“
Man muss also bei der Public Transport Version 2 (PTv2) nur eine der beiden Stellen eingeben. Ich bevorzuge die Plattform, dann sieht man auch auf der Karte, in welche Richtung der Bus wohl fahren wird und wo ich warten muss. Ich setze also einen Punkt neben der Fahrbahn dort, wo die Fahrgäste warten und vergebe folgende unbedingt erforderlichen Tags für die „Plattform“:

kein bus=yes (nachträglich geändert, siehe #10, bus=yes nur bei stop_position, nicht bei platform)
highway=bus_stop
name=.. (Name der Haltestelle)
public_transport=platform

Manche Mapper setzen lieber den Punkt der Halteposition statt der Plattform oder diesen zusätzlich. Dieser Punkt muss dann auf der Fahrbahn-Linie sitzen. Ich würde in diesem Fall unbedingt die folgenden Tags verwenden:
bus=yes
highway=bus_stop (nur, wenn ich die Plattform nicht setze)
name=.. (Name der Haltestelle)
public_transport=stop_position
Mit diesen wenigen Tags ist JOSM schon zufrieden und die Haltestelle eignet sich für die Aufnahme in eine Relation.

Sofern ich beide Punkte (Plattform und Halteposition) setze, verwende ich ebenfalls die o.a. Tags, bei der Halteposition aber kein highway=bus_stop.
Den Punkt der Halteposition benötige ich auf jeden Fall (entweder allein oder mit der Plattform), wenn ich eine Relation anlegen will, für den Beginn und das Ende der Fahrstrecke. Dann muss (nur wenn ich eine Relation anlege) an diesen beiden Stellen der Weg auf jeden Fall auch gesplittet sein oder werden.

Bei der Plattform kann ich weitere zusätzliche Tags vergeben, z.B.:
bin=yes (bei Bushaltestellen nicht amenity=waste_basket)
bench=yes
fee_zone=3 (als Beispiel für meinen Wohnort im VVS Stuttgart)
passenger_informations_display=yes
shelter=yes (nicht amity=shelter, dies mag JOSM bei der Bushaltestelle nicht)
tactile_paving=yes

Damit ich im JOSM-Editor die Haltestellen besser sehe, verwende ich den Kartenstil Öffentlicher Verkehr. Den habe ich über Bearbeiten/Einstellungen, dann 3. Symbol linke Seite und Registerkarte Kartenstile zugefügt. Näheres dazu auch über
https://josm.openstreetmap.de/wiki/De%3AStyles
https://josm.openstreetmap.de/wiki/Help … aintStyles
https://josm.openstreetmap.de/wiki/De%3 … g/MapPaint

Wenn ich eine Routenrelation anlegen will, sehe ich mir am besten auch ein Beispiel an, bei dem kein Fehler aufgeführt ist. Dazu suche ich mir meinen Verkehrsverbund aus unter
https://ptna.openstreetmap.de/results/DE/index.php
Die Linien des Verkehrs- und Traifverbund Stuttgart (VVS), für die eine Relation angelegt ist, sind hier aufgelistet:
https://ptna.openstreetmap.de/results/D … lysis.html

Wichtig ist, dass in die Relation zuerst die Haltestellen (falls Halteposition und Plattform angelegt sind, immer zuerst die Halteposition, dann die Plattform), dann die Wegstücke eingefügt werden, jeweils in der korrekten Reihenfolge.
Nachdem das Ganze so einfach ist, hoffe ich, dass die fehlenden Haltestellen möglichst bald in der Datenbank erscheinen.

Gruß ghostrider44

ghostrider44 wrote:

Manche Mapper setzen lieber den Punkt der Halteposition statt der Plattform oder diesen zusätzlich. Dieser Punkt muss dann auf der Fahrbahn-Linie sitzen. Ich würde in diesem Fall unbedingt die folgenden Tags verwenden:
bus=yes
highway=bus_stop (nur, wenn ich die Plattform nicht setze)
name=.. (Name der Haltestelle)
public_transport=stop_position
Mit diesen wenigen Tags ist JOSM schon zufrieden und die Haltestelle eignet sich für die Aufnahme in eine Relation.

so funktioniert es nicht, dann hätte man für fast jede Haltestelle 2 stop positions (Haltestellen sind fast nie genau gegenüber mit ihren stop positions). Da muss sicherlich noch eine Richtung dran, forward/backward

Sint E7 wrote:

Die letze wochen habe ich das Filsland Verkersverbünd komplett in OSM hinzugefugt und jetzt bin ich gestartet mit das Donau-Iller-Nanverkehrsverbund. Sowohl gab es ein rückstand in OSM. Viele linien und haltestellen waren bei lange nicht komplett und (sehr) veralted.

Für Filsland und DING und andere Verbünde in der Gegend haben wir bei PTNA auch GTFS-Daten https://ptna.openstreetmap.de/gtfs/DE/index.php.

GTFS-Daten beschreiben den IST-Zustand aus Sicht der Verbünde - von kleineren Fehlern hier und da mal abgesehen.

Momentan sind bei PTNA noch nicht überall die neuesten GTFS-Daten verfügbar. Wenn du mir sagst, an welchen Daten die arbeitest, kann ich die allerdings aktualisieren.

Im Augenblick arbeite ich außerdem daran, eine *.osm-Datei (Import für JOSM) erzeugen zu lassen, in dem die Haltestellen und die Route-Relation für eine Trip-Variante enthalten sind (sozusagen als Vorlage).

Sint E7 wrote:

Die letze wochen habe ich das Filsland Verkersverbünd komplett in OSM hinzugefugt

Ich habe die Analyse der OSM-Daten für "Filsland" mal eben in PTNA eingebaut ... https://ptna.openstreetmap.de/results/D … lysis.html

Die zugehörige CSV-Liste https://wiki.openstreetmap.org/wiki/Lan … and-Linien kannst du noch nach Bedarf editieren und strukturieren.

dieterdreist wrote:

Bei Bushaltestellen sollte ein highway=bus_stop an der ungefähren Stelle des Haltestellenschilds ausreichen, alles andere (platform, stop_position, etc.) kann man machen, ist aber nicht unbedingt erforderlich.

Wenn das highway=bus_stop neben der Fahrbahn ist, dann ist es die platform (public_transport=platform wird automatisch angenommen) und man kann keine weitere platform hinzufügen. Man darf das highway=bus_stop aber auch in die Fahrbahn setzen und dann ist es die stop_position (public_transport=stop_position und bus=yes werden automatisch angenommen) und man darf keine weitere stop_position hinzufügen. Eines der zwei Objekte kann man problemlos weglassen. Wenn man es aber mappt, dann muss es mit in die Relation.

dieterdreist wrote:

ghostrider44 wrote:

Manche Mapper setzen lieber den Punkt der Halteposition statt der Plattform oder diesen zusätzlich. Dieser Punkt muss dann auf der Fahrbahn-Linie sitzen. Ich würde in diesem Fall unbedingt die folgenden Tags verwenden:
bus=yes
highway=bus_stop (nur, wenn ich die Plattform nicht setze)
name=.. (Name der Haltestelle)
public_transport=stop_position
Mit diesen wenigen Tags ist JOSM schon zufrieden und die Haltestelle eignet sich für die Aufnahme in eine Relation.

so funktioniert es nicht, dann hätte man für fast jede Haltestelle 2 stop positions (Haltestellen sind fast nie genau gegenüber mit ihren stop positions). Da muss sicherlich noch eine Richtung dran, forward/backward

Doch, funktioniert. Es gibt dann pro Mast (platform) auch eine stop_position. Ein forward/backward ist unnötig, da sich die Richtung aus der Linien-Relation ergibt.

Und nebenbei, wer explizit das tatsächlich das Haltestellenschild erfassen möchte, könnte hier einen Blick drauf werfen :-)
https://wiki.openstreetmap.org/wiki/DE: … ign=DE:224

ghostrider44 wrote:

Man muss also bei der Public Transport Version 2 (PTv2) nur eine der beiden Stellen eingeben. Ich bevorzuge die Plattform, dann sieht man auch auf der Karte, in welche Richtung der Bus wohl fahren wird und wo ich warten muss.

Seh ich auch so.

ghostrider44 wrote:

Ich setze also einen Punkt neben der Fahrbahn dort, wo die Fahrgäste warten und vergebe folgende unbedingt erforderlichen Tags für die „Plattform“:
bus=yes
highway=bus_stop
name=.. (Name der Haltestelle)
public_transport=platform

public_transport=platform ist nicht unbedingt erforderlich, da es bei highway=bus_stop neben der Fahrbahn automatisch gilt. Aber es ist üblich und schadet nichts.

"bus=yes" ist nicht erforderlich und in PTv2 nur für stop_positions vorgesehen. (Da geht es darum, dass man nicht für jede Variante jeder Route prüfen muss, ob die Eigenschaften der Ways der Nodes auch zum Fahrzeugcharakter der Variante passen. Statt dessen kann man beides -- Variante und Fahrweg -- getrennt gegen die Angabe am Node checken und so weniger testen und auch bessere Fehlermeldungen machen.)

aixbrick wrote:

Ein forward/backward ist unnötig, da sich die Richtung aus der Linien-Relation ergibt.

"forward" und "backward" gibt es in PTv2 nicht. In PTv1 ergibt es sich nicht aus der Relation: es war früher üblich, an solche Nodes z.B. ein "direction=NE" (North-East) dranzuschreiben. Aber zu der Zeit war noch strittig, ob man highway=bus_stop überhaupt neben die Fahrbahn setzen darf. Eine Platform ist in dem Fall wirklich praktischer. Nur einen Node auf der Fahrbahn sollte man besser nur dann benutzen, wenn das Ding für beide Richtungen gilt und die angegebene Ausstattung auf beiden Seiten gleich ist.

AB-inf-x-chg-AB wrote:

Und nebenbei, wer explizit das tatsächlich das Haltestellenschild erfassen möchte, könnte hier einen Blick drauf werfen :-)

Ja. highway=bus_stop ist nicht das Schild! Es gibt nur beim Setzen neben die Fahrbahn den (nicht immer, aber oft) guten Rat, den highway=bus_stop-Node zum Schild zu setzen. Aber eigentlich bedeutet es einfach "Hier ist ne Bushaltestelle"

Leicht am Thema vorbei, aber vielleicht trotzdem interessant: gelegentlich zeichne ich den Zugangsweg zur Bushaltestelle explizit ein, besonders wenn er nicht offensichtlich ist / ich es erwähnenswert finde, dass es einen rollstuhltauglichen Zugang gibt.
Eine Zeitlang hab ich die Pfade durchgezogen bis zum Node, der highway=bus_stop getaggt ist. Das mag Osmose aber nicht, schmeißt Fehlermeldung "The bus stop is part of a way, it should have public_transport=stop_position tag" Hier ein Beispiel: https://www.openstreetmap.org/node/6632 … 42/6.58921 Scheinbar denkt Osmose, der Bus hält auf dem Fußgängerweg und sagt mir: "he, die Halte gehört nebenan"
Seitdem ich das weiß, lasse ich den Zugangsweg ein kleines Stück vor der Haltestelle aufhören. Aber richtig sinnvoll erscheint mir das nicht. Wie haltet ihr es mit Zugangswegen? Wie geht das richtig?

smootheFiets wrote:

Das mag Osmose aber nicht, schmeißt Fehlermeldung "The bus stop is part of a way, it should have public_transport=stop_position tag"

Das ist ein Fehler in Osmose. PTv2 unterscheidet: "highway=bus_stop on a way/street where buses are allowed" und "highway=bus_stop beside a way/street where buses are allowed" für stop_position bzw. platform.

Hier
https://www.openstreetmap.org/way/278496873/history
wurde aus einem Abschnitt des Geh- und Radweges eine Plattform-Linie gemacht. Dort ist aber keine "richtige, separate" Plattform, wie sie es auf Busbahnhöfen gibt.
Da ist nur eine Busbucht und nebem dem Haltestellenschild ein Wartehäuschen. Ich halte den Plattform-Way dort deshalb für falsch und einen Plattform-Knoten für ausreichen.

Wie sehr Ihr das?
Fragende Grüße

Edit - Foto:
https://ibb.co/2MgQ1qh

highway=platform ist falsch und sollte footway/path sein. Auch der node daneben sollte korrigiert werden. Nach dem Luftbild von Maxar sieht es aber nach Hochbord aus (weiße Linie).

Eine public_transport=platform sollte auch Bestandteil eines Fußweges sein - egal ob als node oder als way.

geri-oc wrote:

Nach dem Luftbild von Maxar sieht es aber nach Hochbord aus (weiße Linie).

Siehe Foto.

Die frage hieroben gibt für mich an das da kein consensus ist in highway=bus_stop (node) or public_transport=platform (line). In das Verkehrsverbund Berlin-Brandenburg sie ich für das meiste alleen public_transport=platform und in das verkehrsbund VVS wurde highway=bus_stop meistens gebraucht.

Fur Filsland und DING bin ich jeweils beschäftigd mit alles um zu setzen nach public_transport=platform, was auch immer in der Schlange steht mit Pt_V2. Als einer footway entlang einer weg lauft, mit einer oberfläche von asphalt, stehen die wartenden auf einer platform.

PT-53 wrote:

geri-oc wrote:

Nach dem Luftbild von Maxar sieht es aber nach Hochbord aus (weiße Linie).

Siehe Foto.

Warum hast du das Foto nicht gleich mit verlinkt?
Ich würde diese Linie als Wartebereichlinie der Fahrgäste als Teil des Fuß-/Radweges mappen. Falsch ist der node neben der Linie.

Sint E7 wrote:

Die frage hieroben gibt für mich an das da kein consensus ist in highway=bus_stop (node) or public_transport=platform (line)

highway=bus_stop -> node auf der Straße
public_transport=platform -> node/way auf dem Fußweg/Pfad
eventuell zusammengefasst public_transport=stop_area

Weide wrote:

public_transport=platform ist nicht unbedingt erforderlich, da es bei highway=bus_stop neben der Fahrbahn automatisch gilt. Aber es ist üblich und schadet nichts.

Wie ich in #3 geschrieben habe, verwende ich im JOSM-Editor den Kartenstil Öffentlicher Verkehr, um die Haltestelle besser sehen zu können. Wenn ich da das "public_transport=platform" weglasse, ändert sich die Darstellung im Editor, weshalb ich darauf nicht verzichten möchte.
Bei dem von dir erklärten unnötigen bus=yes bei der platform möchte ich dir nicht widersprechen, da du im Gegensatz zu mir der Experte bist.

ghostrider44 wrote:

Wenn ich da das "public_transport=platform" weglasse, ändert sich die Darstellung im Editor, weshalb ich darauf nicht verzichten möchte.

das kann man einstellen

PT-53 wrote:

... Da ist nur eine Busbucht...

Bei uns im OSM an der dortigen Stelle (noch) nicht, zu finden unter:
https://wiki.openstreetmap.org/wiki/DE:Key:bus_bay

AB-inf-x-chg-AB wrote:

PT-53 wrote:

... Da ist nur eine Busbucht...

Bei uns im OSM an der dortigen Stelle (noch) nicht, zu finden unter:
https://wiki.openstreetmap.org/wiki/DE:Key:bus_bay

Sorry, das war nicht die Frage. 🙄

PT-53 wrote:

AB-inf-x-chg-AB wrote:

PT-53 wrote:

... Da ist nur eine Busbucht...

Bei uns im OSM an der dortigen Stelle (noch) nicht, zu finden unter:
https://wiki.openstreetmap.org/wiki/DE:Key:bus_bay

Sorry, das war nicht die Frage. 🙄

Stimmt, war etwas OT, wollte aber mal das eher unbekannte Merkmal bekannt machen ;-)

Edit: und es hat gleich dazu geführt, dass die wiki etwas optimiert wurde, siehe
https://wiki.openstreetmap.org/w/index. … id=2038101
Dankeschön an Toni!

ghostrider44 wrote:

Wie ich in #3 geschrieben habe, verwende ich im JOSM-Editor den Kartenstil Öffentlicher Verkehr, um die Haltestelle besser sehen zu können. Wenn ich da das "public_transport=platform" weglasse, ändert sich die Darstellung im Editor, weshalb ich darauf nicht verzichten möchte.

Seh ich auch so :-) Auch beim Einfügen in eine Relation wird gleich die Rolle gesetzt.
(Es fällt nur genau genommen nicht unter "unbedingt erforderlich".)

Es gibt so manche Sachen in PTv2 die man weglassen darf aber nicht weglassen sollte. Z.B. darf man den Haltestellennamen weglassen, wenn es eine stop_area gibt. Ich würde es aber nicht machen und niemand raten. Man darf auch bei PTv2-Routen die Master-Route weglassen ... ist aber auch keine gute Idee.

Umgekehrt kann man aber auch viele Sachen weglassen, die heute so gern eingetragen werden. Für zwei einander gegenüberstehende Schildchen auf der Landstraße reicht ein Node auf der Straße, da wird aber unheimlich gern ein Verhau aus zwei Platforms, zwei Stops und einer stop_area-Relation gebaut. Oft auch noch mit dem völlig falschen Kommentar "Umstellung auf PTv2" ... grrr

ghostrider44 wrote:

Bei dem von dir erklärten unnötigen bus=yes bei der platform möchte ich dir nicht widersprechen, da du im Gegensatz zu mir der Experte bist.

Gegenüber "Experten" sollte man immer misstrauisch sein:

Im stop_position-Abschnitt findet man den yes/no-Kram
https://wiki.openstreetmap.org/w/index. … p_Position
Im Platform-Abschnitt direkt dahinter ist nichts dergleichen.

-)

aixbrick wrote:

Ein forward/backward ist unnötig, da sich die Richtung aus der Linien-Relation ergibt.

da hast Du Recht

Ich habe wahrscheinlich eine ganze Diskussion angezündet.
Kann einer der Experten diese OSM-Beziehung überprüfen, um festzustellen, ob ich alles richtig gemacht habe?
https://www.openstreetmap.org/relation/11093583

Sint E7 wrote:

... Kann einer der Experten ...

Bin keiner, kenne aber ein Experten-Tool was automatisch drüberschauen kann, siehe:
http://tools.geofabrik.de/osmi/?view=pu … rror_nodes
Nicht wundern, die Aktualisierung passiert nicht sofort, sondern benötigt ca. 24h.

Sint E7 wrote:

Ich habe wahrscheinlich eine ganze Diskussion angezündet.
Kann einer der Experten diese OSM-Beziehung überprüfen, um festzustellen, ob ich alles richtig gemacht habe?
https://www.openstreetmap.org/relation/11093583

Mmm, prinziplell sind solche Relationen nicht erwünscht, da sie Sammlungen/Collections sind ... Relationen_sind_keine_Kategorien, Relations_are_not_Categories

Abgesehen davon sind die beiden Relationen Bürgerbusse in Filsland und Nachtschwärmer falsch und müssten konsequenterweise ebenfalls als type=network getagged werden, da auch sie route/route_master mit unterschiedlichen ref= zusammenfassen.

Dogmatisch gesehen würde ich die drei Relationen löschen.

Pragmatisch gesehen würde ich zumindest die beiden letzten Relationen korrigieren und deine bisherige Arbeit respektieren.

Gruß,
Toni

In der Route sind stop und platform nur dann ein Paar, wenn die Namen gleich sind.

Dass alle Namen einer Haltestelle gleich sein müssen folgt aus der PTv2-Regel, dass der Name entfallen darf, wenn eine stop_area existiert. Das wäre völliger Unsinn, wenn dort verschiedene Namen stehen dürften. Deshalb darf ein Programm die Namen Bit für Bit vergleichen und muss keine Abstände berechnen oder ähnliches.

Weide wrote:

Deshalb darf ein Programm die Namen Bit für Bit vergleichen und muss keine Abstände berechnen oder ähnliches.

Das höre ich gerne!

Denn lat/lon wird in PTNA bisher überhaupt nicht genutzt.

ToniE wrote:

Das höre ich gerne!

Die Regel verschafft uns allerdings auch an einigen wenigen Stellen der Welt ein unlösbares Problem. Die Bahnsteige in Mannheim Hbf haben m.W. Eigennamen (z.B. "Bahnsteig D"). Nach den allgemeinen Regeln von OSM müssen die in "name". Nach den PTv2-Regeln muss da "Mannheim Hbf" oder vielleicht "Mannheim Hauptbahnhof" rein. Statt dem Bahnsteig die Bahnsteigkante zu nehmen hilft auch nicht, denn das railway=platform ist auch ohne public_transport=platform eine PTv2-Platform. Wenn sie nicht in Routen auftaucht, dann hält da also laut Datenbestand nichts. Das werden wir wohl erst im nächsten Schema hinkriegen.

Weide wrote:

Die Regel verschafft uns allerdings auch an einigen wenigen Stellen der Welt ein unlösbares Problem. Die Bahnsteige in Mannheim Hbf haben m.W. Eigennamen (z.B. "Bahnsteig D"). Nach den allgemeinen Regeln von OSM müssen die in "name". Nach den PTv2-Regeln muss da "Mannheim Hbf" oder vielleicht "Mannheim Hauptbahnhof" rein.

Naive Frage: gehört "Bahnsteig D" nicht in ref? Und name dann "Mannheim Hauptbahnhof"?

https://wiki.openstreetmap.org/wiki/DE:Tag:public_transport%3Dplatform wrote:

ref: Die Gleis-/Platformnummern(n) unter der die Plattform bekannt ist.

smootheFiets wrote:

Naive Frage: gehört "Bahnsteig D" nicht in ref? Und name dann "Mannheim Hauptbahnhof"?

Das war auch mein erster Impuls (der ja nicht falsch sein muss), hatte aber keine Zeit weiter nachzuforschen.

Ich würde sogar sagen: ref=D

ToniE wrote:

Ich würde sogar sagen: ref=D

Es handelt sich um einen Bahnsteig mit der "Nummer" D

"Mannheim Hauptbahnhof" ist einer der oft diskutierten Sonderfälle so wie "Rathaus Kleinkleckerstadt".

Natürlich kann man argumentieren, dass sei kein Name, aber was dann? Eine "ref" ist es jedenfalls nicht. "Hauptbahnhof" weglassen und nur "Mannheim" als Name hinterlegen wäre aber auch falsch. Denn Mannheim ist nicht der Name des Bahnhofs sondern der Stadt. Ist ja auch beim Rathaus so, die Stadt heißt "Kleinkleckerstadt". Die Bezeichnung "Hautbahnhof" bzw. "Rathaus" ist fester Bestandteil des Namen. Also "Mannheim Hauptbahnhof" und "Rathaus Kleinkleckerstadt" ebenso wie "Rosenapotheke" oder "Apotheke am Wall".

Bahnsteige haben dagegen keine Namen sondern werden mit Nummern oder Buchstaben "durchnummeriert", was dann wieder ein typischer Fall für "ref" ist so wie Kreisstraße "K 2" oder Bundesstraße "B 3" oder Wanderweg "A 1"

Galbinus wrote:

"Mannheim Hauptbahnhof" ist einer der oft diskutierten Sonderfälle so wie "Rathaus Kleinkleckerstadt".

Sonderfall? Würde ich gar nicht mal sagen:

ref="D"
name="Mannheim Hauptbahnhof"

ist am Bahnsteig völlig OK (aber ohne "Bahnsteig" im 'ref').

"München Hauptbahnhof", "München Pasing", "München Ost", ... sind hier entsprechende Normalfälle für "name=".

ToniE wrote:

Sonderfall? Würde ich gar nicht mal sagen:

ref="D"
name="Mannheim Hauptbahnhof"

ist am Bahnsteig völlig OK (aber ohne "Bahnsteig" im 'ref').

name=Mannheim Hauptbahnhof auf einem Bahnsteig ist doch nicht ok. Das gehört an railway=station aber nicht an jeden Bahnsteig, jedenfalls nicht als "name".

dieterdreist wrote:

ToniE wrote:

Sonderfall? Würde ich gar nicht mal sagen:

ref="D"
name="Mannheim Hauptbahnhof"

ist am Bahnsteig völlig OK (aber ohne "Bahnsteig" im 'ref').

name=Mannheim Hauptbahnhof auf einem Bahnsteig ist doch nicht ok. Das gehört an railway=station aber nicht an jeden Bahnsteig, jedenfalls nicht als "name".

railway=station ist eine anderes Objekt, das das Gebäude, die Fläche identifiziert.

Gemäß PTv2 hat/kann ein Bus-/Bahnsteig auch einen 'name' (haben), so interpretiere ich das. Existiert eine stop_area, bei der der Bahnsteig 'member' ist, dann kann 'name' an der Platform wegfallen.

Was würdest du denn als 'name' am Bahnsteig nehmen? Leer lassen? Geht auch.

Im "München Hbf" haben alle public_transport=stop_position den name=München Haupfbahnhof, die public_transport=platform den name="", sind alle aber in einer public_transport=stop_area inkl. der railway=station.

Ich finde das gerade so akzeptabel bzgl. name="" an den Bahnsteigen.

Es ist schön für das ÖPV-Mapping, dass ihr das so seht: mit dem Namen "Mannheim Hbf" im "name" des Bahnsteigs oder mit leerem "name" im Bahnsteig und dafür im "name" der stop_area funktioniert PTv2. Wenn mir aber jemand sagt "In Mannheim haben die aber nunmal die Steige benannt und deshalb darf man diesen Namen eintragen", dann habe ich nicht wirklich ein Argument dagegen. Da haben die allgemeinen Regeln von OSM Vorrang, auch wenn die PTv2-Daten dann beschädigt sind.

Weide wrote:

Da haben die allgemeinen Regeln von OSM Vorrang, auch wenn die PTv2-Daten dann beschädigt sind.

Es wird ja niemand gezwungen nach PTv2 zu mappen. Man sollte PTv2-Mapping aber auch nicht halbherzig machen.

ToniE wrote:

... public_transport=stop_area inkl. der railway=station

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.

Weide wrote:

ToniE wrote:

... public_transport=stop_area inkl. der railway=station

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.

Vielleicht kann die Rolle "label" für den Zentralnode verwendet werden, analog zu Grenzrelationen.

skyper wrote:

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.

Und bitte nicht vergessen "ref_name" ;-)

AB-inf-x-chg-AB wrote:

Und bitte nicht vergessen "ref_name" ;-)

großartig 😄 😄 😄

AB-inf-x-chg-AB wrote:

skyper wrote:

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.

Und bitte nicht vergessen "ref_name" ;-)

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 ...

Weide wrote:

Ein Name fehlt uns im ÖPV-Bereich: der Name wie er auf dem Schild steht.

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: … nden.21.29

AB-inf-x-chg-AB wrote:

Weide wrote:

Ein Name fehlt uns im ÖPV-Bereich: der Name wie er auf dem Schild steht.

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: … nden.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.

ToniE wrote:

Ich denke, wir sollten in 'name' immer die ausgeschriebene Variante nehmen, unabhängig davon was auf dem Schild steht.

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.

AB-inf-x-chg-AB wrote:

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

Von mir aus kann "Benrath Btf" nach "ref_name", dann wird's auch so gefunden.

AB-inf-x-chg-AB wrote:

b) Beispiel: otg-Schildtext: "Mühle" dagegen web-Suchmaschinentext "Adorf Mühle"

da kommt "Adorf Mühle" dann in "ref_name" rein.

AB-inf-x-chg-AB wrote:

Das zählt doch nicht zu den Abkürzungen ...

Genau, denn "Mühle" ist keine Abkürzung, nur ein nicht sehr eindeutiger Name.

AB-inf-x-chg-AB wrote:

skyper wrote:

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.

Und bitte nicht vergessen "ref_name" ;-)

Was ist der Unterschied zu "uic_name"? Hatte ich bewusst weggelassen.

AB-inf-x-chg-AB wrote:

@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.

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?

ToniE wrote:

Von mir aus kann "Benrath Btf" nach "ref_name", dann wird's auch so gefunden.

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.

Weide wrote:

ToniE wrote:

Von mir aus kann "Benrath Btf" nach "ref_name", dann wird's auch so gefunden.

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.

skyper wrote:

Woraus genau die Ortsbezeichnung sich ergibt ist auch noch zu klären. Ist das der Stadt-/Ortsteil, der Ort/Bezirk oder die Gemeinde/Stadt?

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.

GeorgFausB wrote:

Da das rein situationsabhängig ist, kann man da m. E. keine eindeutige Regel aufstellen.

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).

https://www.openstreetmap.org/node/4836838140

ein node mit highway=bus_stop shelter=yes name=... an die Stelle des H-Schilds, ggf. noch den Mülleimer taggen.

skyper wrote:

• 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"?
  

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.

geri-oc wrote:

Möglichst detailliert für Eintragung der Haltestelle und des Busstop ...

Ich weiß nicht, was der Unterschied zwischen "Haltestelle" und "Busstop" bei Bussen ist. Aber egal:

Ich sehe keinen Grund, sowohl die Stop_Position (4836838141) als auch die Platform (4836838140) zu mappen. Ich würde die Stop_Position weglassen und ihr "highway=bus_stop" zur Platform rüberschieben. Aber das ist Geschmackssache.

Den Namen würde ich vom Schild abschreiben: "name=Freital Wilsdruffer Straße".

"shelter=yes" und "bin=yes" sollten raus, da sie separat gemappt sind.

Das "description" kann weg sobald die Haltestelle in die Routen eingetragen ist. (Das ist aber nicht ganz einfach, da die Routen die ich angesehen habe weder PTv1 noch PTv2 sind)

Weide wrote:

"shelter=yes" und "bin=yes" sollten raus, da sie separat gemappt sind.

wieso? Das hier sind doch Eigenschaften der Bushaltestelle, dass sie einen Mülleimer und Wetterschutz bietet? Dass diese Dinge nebenbei auch explizit gemappt sind, ändert doch daran nichts, oder?

wieso? Das hier sind doch Eigenschaften der Bushaltestelle, dass sie einen Mülleimer und Wetterschutz bietet? Dass diese Dinge nebenbei auch explizit gemappt sind, ändert doch daran nichts, oder?

Finde ich eigentlich auch. Da hätte ich auch gern Unterstellmöglichkeiten an dort vorhandenen Geschäften mit drin. Aber in der jetzigen Lage finde ich es wichtiger, PTv2 einzuhalten (und das für PTvNG vorzumerken):

shelter=yes:␣If␣there␣is␣a␣shelter␣that␣is␣not␣tagged␣separately␣with␣amenity=shelter.

Für "bench" gilt dasselbe. "bin" ist nicht erwähnt, aber eine abweichende Regel wäre verwirrend.

Weide wrote:

Für "bench" gilt dasselbe. "bin" ist nicht erwähnt, aber eine abweichende Regel wäre verwirrend

Für bridge scheint das nicht zu gelten, oder lässt Du bridge=yes auf highways weg wenn ein man_made=bridge Objekt gemappt ist?

dieterdreist wrote:

Weide wrote:

Für "bench" gilt dasselbe. "bin" ist nicht erwähnt, aber eine abweichende Regel wäre verwirrend

Für bridge scheint das nicht zu gelten, oder lässt Du bridge=yes auf highways weg wenn ein man_made=bridge Objekt gemappt ist?

Shelter=separate: Hütte vorhanden, gehört zur Halte, ist separat eingetragen. Sehe ich nicht oft, kommt aber vor.

Nach der gleichen Logik könnte man bin=separate taggen... Kommt mir aber komisch vor.

@geri-oc: Die Haltestelle heißt Wilsdruffer Straße.
Der vorgesetzte Ortsname darf auch hinzugenommen werden, ist aber entbehrlich. Der Text unter description wäre als route_ref besser untergebracht, aber wie Weide schon schrieb doppeln solche Hinweise den Wartungsaufwand und sollten nach dem Mappen der routen entfernt werden.
Nach meiner Meinung müssen wir keine Schreibfehler auf dem Haltestellenschild übernehmen und dürfen bei so Haltestellenabfolgen wie Bahnhof - Friedhof -Markt - Mitte - Markt - Dorfgemeinschaftshaus - Mitte - Friedhof durchaus mal den Ortsnamen voranstellen.

public_transport regelt die Eigenschaften von stop_position und platform. So ist shelter=yes eine Ersatzmaßnahme, solange der Unterstand noch nicht gemappt ist. Es gibt nach public_transport keine Negativeigenschaften.

Der bus_stop wird nicht von public_transport geregelt, er ist älter. Insofern könnten am bus_stop auch zählbare Eigenschaften wie shelter=no auftauchen.

Erst einmal Danke für die Meinungen. Werde am WE mal schauen.

Das mit den einzelnen Bänken oder Papierkörben war auch zur Visualisierung für die Stadt in unserem Stadtteil. Ich finde einfach ist einfacher.

axelr wrote:

Der bus_stop wird nicht von public_transport geregelt...

Das ist falsch. Bitte lies PTv2:
https://wiki.openstreetmap.org/w/index. … known_tags

"highway=bus_stop" ist von PTv2 ganz klar geregelt:

"highway=bus_stop" auf dem Fahrweg ist als "public_transport=stop_position" mit "bus=yes" zu interpretieren.

"highway=bus_stop" neben dem Fahrweg ist als "public_transport=platform" zu interpretieren.

axelr wrote:

[...] public_transport regelt die Eigenschaften von stop_position und platform. So ist shelter=yes eine Ersatzmaßnahme, solange der Unterstand noch nicht gemappt ist. Es gibt nach public_transport keine Negativeigenschaften. [...]

StreetComplete hat nach dem neusten Update (v23) eine Spielfunktion "Does the bus stop […] have a bench?". Das ist in der Tabelle [1] die Zeile mit dem Symbol einer Bank auf blauen Hintergrund. Befindet sich recht weit unten, oder nach Spalte "Since version" abwärts sortieren, dann erscheint die Zeile derzeit recht weit oben. StreetComplete schreibt eventuell die Negativeigenschaft "bench=no". Wurde hier [2] kürzlich eingeführt. Man kann in der Overpass-ql [3] Abfrage erkennen, dass dort auch nach "public_transport=(platform)" gesucht wird.
[1] wiki: https://wiki.openstreetmap.org/wiki/Str … ete/Quests
[2] github: https://github.com/westnordost/StreetCo … ssues/1079
[3] Abfrage: https://overpass-turbo.eu/s/Yfz

@Weide: Hatte ich gelesen. Ist zu interpretieren: Ja, aber
ptv2 definiert nicht rückwirkend die tagging-Regeln für den bus_stop !

AB-inf-x-chg-AB wrote:

...StreetComplete schreibt eventuell die Negativeigenschaft...

Das ist nicht der einzige Fehler in unseren Editoren oder deren Eingabehilfen.

Der bus_stop kann irgendwo an der Haltestelle stehen (z.B. auch in der Busbucht).
Die platform ist der Ort wo Passagiere warten. (Diese warten nicht in der Busbucht)

Ein solcher bus_stop neben dem Fahrweg kann als platform interpretiert werden, ist jedoch nicht gleichbedeutend.
Insofern ist jede Aufforderung der Editoren an einen highway=bus_stop auch public_transport=platform zu schreiben falsch.

axelr wrote:

AB-inf-x-chg-AB wrote:

...StreetComplete schreibt eventuell die Negativeigenschaft...

Das ist nicht der einzige Fehler in unseren Editoren oder deren Eingabehilfen.

Weiss nicht ob es ein Fehler ist, aber nach Deiner Aussage wäre es nicht PTv2 konform ein bench=no (Negativeigenschaft) hinzuzufügen, ggf. ist es ein Erweitungen von PTv2. Müsste vielleicht mal die Gemeinde sprechen, ob das gewünscht oder nicht gewünscht ist.

axelr wrote:

Der bus_stop kann irgendwo an der Haltestelle stehen (z.B. auch in der Busbucht).
Die platform ist der Ort wo Passagiere warten. (Diese warten nicht in der Busbucht)

Ein solcher bus_stop neben dem Fahrweg kann als platform interpretiert werden, ist jedoch nicht gleichbedeutend.
Insofern ist jede Aufforderung der Editoren an einen highway=bus_stop auch public_transport=platform zu schreiben falsch.

Ja, nach dieser Beschribung müsste ein Busbucht-bus_stop erstmal auf die Position wo Passagiere warten (und nicht wo Busse fahren) verschoben werden um ein public_transport=platform ranzuschreiben.
Passt aber in dem Zusammenhang mit StreetComplete nicht, da StreetComplete nicht public_transport=platform ranscheibt, sondern diese Anfrage ("Does the bus stop […] have a bench?") ausschliesslich dazu dient ein "bench=yes" (oder ein "bench=no") an highway=bus_stop (die keine public_transport=stop_position sind) oder an public_transport=platform hinzuzufügen.

AB-inf-x-chg-AB wrote:

sondern diese Anfrage ("Does the bus stop […] have a bench?") ausschliesslich dazu dient ein "bench=yes" (oder ein "bench=no")

und wenn es nicht dran steht, weil extra gemappt, wird es zugefügt?

axelr wrote:

aber
ptv2 definiert nicht rückwirkend die tagging-Regeln für den bus_stop !

Nein. Aber es definiert, wie das Tag in PTv2 zu interpretieren ist. Es ist immer entweder eine PTv2 stop_position oder eine PTv2 platform. Man darf dann keine weitere stop_position oder platform für denselben Halt in PTv2 definieren.

@Weide: Man darf doch, das Thema hatten wir doch schon zich mal durchgekaut.

axelr wrote:

@Weide: Man darf doch, das Thema hatten wir doch schon zich mal durchgekaut.

Ja, das hatten wir wirklich schon sehr oft. Und jedesmal wenn in der Sachdiskussion die Gefahr besteht, dass Du den Widerspruch Deiner Mappingideen zu PTv2 zugeben müsstest, ziehst Du den Dialog weg von der Sachdiskussion.

Da immer noch etliche Bushaltestellen nicht erfasst sind, wende ich mich als einfacher Mapper an diejenigen, die sich nicht trauen, eine Bushaltestelle einzutragen. Setzt einfach einen Punkt (sog. Node) neben der Fahrbahn an die Stelle, an der die Fahrgäste auf den Bus warten und ergänzt den Punkt mit den beiden Tags
highway=bus_stop
name=… (Name der Bushaltestelle)
Damit sind die zwingend notwendigen Tags für die sog. „platform“ schon erfüllt und die gesamte Bushaltestelle schon erfasst. Jeder, der es besser weiß, kann die platform (evtl. auch später) mit zusätzlichen Tags noch besser beschreiben. Siehe dazu auch
https://wiki.openstreetmap.org/wiki/DE:Public_transport
https://wiki.openstreetmap.org/wiki/DE: … 3Dplatform
Ich füge noch
public_transport=platform
hinzu, wenn ich die Haltestelle in eine Relation aufnehmen will, da dann auch die Rolle richtig übernommen wird.
Die meisten Fehler, die mir in letzter Zeit aufgefallen sind: Der Punkt neben der Fahrbahn wurde öfter als public_transport=stop_position bezeichnet statt als …=platform. Der Fehler fällt aber spätestens auf, wenn man die Relation mit
https://ptna.openstreetmap.de/results/D … lysis.html prüfen lässt. Schlechter ist es in jedem Fall, die Bushaltestelle überhaupt nicht zu erfassen. Deshalb nochmal die Aufforderung an die unsicheren Mapper:
Setzt den Punkt (Node) neben die Fahrbahn und fügt die beiden o.a. Tags dazu und gut ist!

Es ist immer gut ein Beispiel im WIKI - oder im Leben - zu haben.
Ich nutze jetzt das - https://wiki.openstreetmap.org/wiki/DE: … 3Dplatform
Hier einfach eine Bus-Haltestelle mit Angaben der Schlüssel und Werte - und wie man zu den Werten kommt:
1. die unbedingt da stehen müssen - stop_position, platform
2. was ergänzt werden kann und wie man zu diesen Werten kommt.
3. was nicht gemacht werden sollte.

Das ähnliche eventuell für einen Straßenbahnhaltestelle oder Bahnsteig - obwohl ich dort bei uns nichts mehr mache seit dort 3-D eingebaut wurde und Validator meckert.

Hier - https://wiki.openstreetmap.org/wiki/DE:Public_transport - wird gesagt, das die Stop-Poition unnötig ist - aber in der Relation ist sie dann als stop einzutragen. Auch wird dort noch highway=platform statt highway=footway genannt. Also wieder etwas "unordentlich".

Bei uns steht zum Beispiel nur VVO an den Schildern - ich weiß das es Verkehrsverbund Oberelbe (neuerdings ist das Regional RVSOE im Landkreis mit VVO als ein Mitglied) ist, wie kann ich das VVO am Schild /Haltestelle kenntlich machen?
Wie kann ich die VVO-stop-id an der Haltestelle eintragen? Ist das uic_ref=*?
Wichtig finde ich auch eine Verlinkung zum Haltestellenfahrplan - ich nutze dazu qr-code=* als Nachweis und website=* als link

Noch einmal zum getrennt Mappen von shelter und waste:
hier ist zwar ein Unterstand eingetragen:
https://www.openstreetmap.org/node/3900 … 1&layers=N
Aber wer fragt eine Bushaltestelle ab, wenn er eine Radkarte - https://www.openstreetmap.org/node/3900 … &layers=CN - oder Stadtplan - https://www.openstreetmap.org/node/3900 … &layers=HN - erstellt? Nicht einmal die ÖPNV-Layer zeigt einen Unterstand an: https://www.openstreetmap.org/#map=18/5 … &layers=ON
Einfach einfach bleiben - statt immer mehr an Werten und Schlüssel an "einem" node, way, ...
Sonntag ...

geri-oc wrote:

...Wie kann ich die VVO-stop-id an der Haltestelle eintragen? Ist das uic_ref=*?...

Als ref:vvo=xx
In aller Regel ist es nicht sinnvoll die lokalen Nummern einzutragen und zu pflegen.
Die uic gibt es nur für Bahnhöfen, nicht an Bushaltestellen !

geri-oc wrote:

Es ist immer gut ein Beispiel im WIKI - oder im Leben - zu haben.
Ich nutze jetzt das - https://wiki.openstreetmap.org/wiki/DE: … 3Dplatform
Hier einfach eine Bus-Haltestelle mit Angaben der Schlüssel und Werte - und wie man zu den Werten kommt:
1. die unbedingt da stehen müssen - stop_position, platform
2. was ergänzt werden kann und wie man zu diesen Werten kommt.
3. was nicht gemacht werden sollte.

+1, da fehlen jetzt leider noch genau sowas wie die Erklärung warum keine access-Tags für die Fahrzeugtypen dran sollten und die Problematik mit *name ist nicht einmal angedeutet.

Wie behandel ich Abkürzungen im Namen auf dem Schild?
Was soll ich verwenden, wenn ich lokale Haltestellen mit "Bahnhof" auf dem Schild, daneben ein ZOB mit "Steig [1-9]" und dann eben den Bahnhof mit mehreren Bahnsteigen "Gleis …". Das gleiche bitte auch mit Abkürzungen (Bf/Hbf/ZOB).
Jetzt habe ich auch noch mehrere GTFS-Datensätze von unterschiedlichen Betreiberfirmen mit unterschiedlichen Namen zu gleichen Haltestellen und auch einzelne Haltestellen der stop_area, welche nur in bestimmten Datensätzen vorkommen.

geri-oc wrote:

Das ähnliche eventuell für einen Straßenbahnhaltestelle oder Bahnsteig - obwohl ich dort bei uns nichts mehr mache seit dort 3-D eingebaut wurde und Validator meckert.

+1, dann braucht es zwei Beispiele. Eins ohne und eins mit 3-D.

geri-oc wrote:

Hier - https://wiki.openstreetmap.org/wiki/DE:Public_transport - wird gesagt, das die Stop-Position unnötig ist - aber in der Relation ist sie dann als stop einzutragen. Auch wird dort noch highway=platform statt highway=footway genannt. Also wieder etwas "unordentlich".

Mit footway habe ich aber auch meine Problem: https://forum.openstreetmap.org/viewtop … 89#p803789

geri-oc wrote:

Bei uns steht zum Beispiel nur VVO an den Schildern - ich weiß das es Verkehrsverbund Oberelbe (neuerdings ist das Regional RVSOE im Landkreis mit VVO als ein Mitglied) ist, wie kann ich das VVO am Schild /Haltestelle kenntlich machen?
Wie kann ich die VVO-stop-id an der Haltestelle eintragen? Ist das uic_ref=*?
Wichtig finde ich auch eine Verlinkung zum Haltestellenfahrplan - ich nutze dazu qr-code=* als Nachweis und website=* als link

Abkürzungen schreibe ich immer aus. Dazu verwende ich noch ein short_name sowie operator:short und network:short.

VVO-stop-id hängt von der Id ab.

• Ist das eine interne Id des VVO -> ref:vvo
  
• Ist das eine UIC Id -> uic_ref
  
• Ist das eine IFOPT -> ref:IFOPT
  
• Ist das eine stop_id aus GTFS und nicht IFOPT -> gtfs:stop_id
  

Bei den QR-Codes und den websites bin ich vorsichtig. Was machtst Du bei Haltestellen die z.B. von fünf unterschiedlichen Unternehmen angefahren werden.

geri-oc wrote:

Noch einmal zum getrennt Mappen von shelter und waste:
hier ist zwar ein Unterstand eingetragen:
https://www.openstreetmap.org/node/3900 … 1&layers=N
Aber wer fragt eine Bushaltestelle ab, wenn er eine Radkarte - https://www.openstreetmap.org/node/3900 … &layers=CN - oder Stadtplan - https://www.openstreetmap.org/node/3900 … &layers=HN - erstellt? Nicht einmal die ÖPNV-Layer zeigt einen Unterstand an: https://www.openstreetmap.org/#map=18/5 … &layers=ON
Einfach einfach bleiben - statt immer mehr an Werten und Schlüssel an "einem" node, way, ...
Sonntag ...

Ich frage mich halt nur warum ich zwingend die Tags von der Haltestelle entfernen soll, wenn die Objekte eigene Objekte sind. Die Information ist immer noch gültig und PTv1 unterstützt auch nur Punkte. Zumindest, solange es noch eine Haltestelle mit PTv1 Routen gibt halte ich die Tags sogar für angebracht und im Falle von Negationen bleibt ja auch gar nichts anderes übrig.

axelr wrote:

geri-oc wrote:

...Wie kann ich die VVO-stop-id an der Haltestelle eintragen? Ist das uic_ref=*?...

Als ref:vvo=xx
In aller Regel ist es nicht sinnvoll die lokalen Nummern einzutragen und zu pflegen.
Die uic gibt es nur für Bahnhöfen, nicht an Bushaltestellen !

Bei mir stehen die lokalen ids auf dem Schild und sind auch im GTFS enthalten. Warum macht es keinen Sinn dies einzutragen?

An Bushaltestellen gibt es in Europa ref:IFOPT, als Ersatz für UIC.

skyper wrote:

...Bei mir stehen die lokalen ids auf dem Schild und sind auch im GTFS enthalten. Warum macht es keinen Sinn dies einzutragen?

An Bushaltestellen gibt es in Europa ref:IFOPT, als Ersatz für UIC.

Die ref:vvo gilt nur innerhalb des VVO, wir sollten uns auf die überregionale Bedeutung konzentrieren.
Der gtfs-Datensatz ist für uns nur ein Hilfsmittel und kein Ersatz für unsere genaueren Datenbestände. Seitens der Ersteller (meist Verkehrsverbund) ist es auch nur ein zusätzlicher Datensatz, der aus den richtigen Fahrplandaten abgeleitet wird. Es ist also auf beiden Seiten ein Fremdkörper der eher als Klotz am Bein zusätzlich erstellt wird.

Wir haben Deutschlandweit die ref:ibnr (6stellige Bus- und Straßenbahn- Haltestellennummer), die auch mal als Hafas-Nummer genannt wurde und mit deren Hilfe man Bushaltestellen unter bahn.de eindeutig findet.

Die ref:IFOPT setzt sich nur langsam durch und bisher kenne ich noch keine Fahrplanauskunft, die sie benutzt. Vielleicht sollten wir eine solche mal selbst aufbauen.

Die UIC wird durch keine dieser Nummern ersetzt, es ist eine reine Bahnhofsnummer, die als uic_ref und uic_name nur an Bahnhöfen erfasst wird.

Zu deinem vorherigen Beitrag: Warum suchst du die Probleme, wenn es einfache Sachverhalte gibt.
- Eine Haltestelle hat nur einen operator und wird auch von fremden Busunternehmen angefahren.
- Eine Abkürzung str. steht für straße. Der Schilderbauer benutzt die Abkürzungen, wir nicht.
- Die public_transport=platform ist eine Ortsangabe und keine Straße, der highway-tag ist überflüssig.

axelr wrote:

Der gtfs-Datensatz ist für uns nur ein Hilfsmittel und kein Ersatz für unsere genaueren Datenbestände. Seitens der Ersteller (meist Verkehrsverbund) ist es auch nur ein zusätzlicher Datensatz, der aus den richtigen Fahrplandaten abgeleitet wird. Es ist also auf beiden Seiten ein Fremdkörper der eher als Klotz am Bein zusätzlich erstellt wird.

Aus Sicht der Verkehrsverbünde ist das wohl so und ich sehe sehr oft Fehler in den GTFS-Daten, die aus dieser Herleitung stammen.

Aus meiner Sicht ist es das Bindeglied zu den offiziellen Daten der Verkehrsverbünde. Die GTFS-Daten erlauben uns eine Überprüfung unserer Daten - mit Vorsicht und mit Lizenz.

axelr wrote:

Zu deinem vorherigen Beitrag: Warum suchst du die Probleme, wenn es einfache Sachverhalte gibt.
- Eine Haltestelle hat nur einen operator und wird auch von fremden Busunternehmen angefahren.
- Eine Abkürzung str. steht für straße. Der Schilderbauer benutzt die Abkürzungen, wir nicht.
- Die public_transport=platform ist eine Ortsangabe und keine Straße, der highway-tag ist überflüssig.

Sehe ich auch so.
Beim letzten Punkt würde ich das auch gerne so sehen, nur: 'Bahnsteig' heißt wohl "platform" und wird eher als Fläche gesehen - und so wurde es in München massenhaft gemapped.
"platform" als Ortsangabe gefällt mir, weil es für mich einen "Node" impliziert - wie bei "place".

axelr wrote:

Die ref:IFOPT setzt sich nur langsam durch und bisher kenne ich noch keine Fahrplanauskunft, die sie benutzt. Vielleicht sollten wir eine solche mal selbst aufbauen.

Die Fahrplanauskuft der NVBW lässt sich auch mit ref:IFOPT nutzen. Habe das aber auch nur durch Zufall herausgefunden.

skyper wrote:

Bei den QR-Codes und den websites bin ich vorsichtig. Was machtst Du bei Haltestellen die z.B. von fünf unterschiedlichen Unternehmen angefahren werden.

In der Praxis ist es noch krasser. Die Buskante (tactile_paving und evtl. ein Betonfahrbelag) wird durch die Gemeinde hergestellt/betrieben, der H-Lolli vom Hauptverkehrsunternehmer oder einem Zweckverband, der Unterstand durch ein Werbeunternehmen oder Zweckverband oder - bei Holzhütten - wieder die Gemeinde :-)

ToniE wrote:

axelr wrote:

Der gtfs-Datensatz ist für uns nur ein Hilfsmittel und kein Ersatz für unsere genaueren Datenbestände. Seitens der Ersteller (meist Verkehrsverbund) ist es auch nur ein zusätzlicher Datensatz, der aus den richtigen Fahrplandaten abgeleitet wird. Es ist also auf beiden Seiten ein Fremdkörper der eher als Klotz am Bein zusätzlich erstellt wird.

Aus Sicht der Verkehrsverbünde ist das wohl so und ich sehe sehr oft Fehler in den GTFS-Daten, die aus dieser Herleitung stammen.

Aus meiner Sicht ist es das Bindeglied zu den offiziellen Daten der Verkehrsverbünde. Die GTFS-Daten erlauben uns eine Überprüfung unserer Daten - mit Vorsicht und mit Lizenz.

axelr wrote:

Zu deinem vorherigen Beitrag: Warum suchst du die Probleme, wenn es einfache Sachverhalte gibt.
- Eine Haltestelle hat nur einen operator und wird auch von fremden Busunternehmen angefahren.
- Eine Abkürzung str. steht für straße. Der Schilderbauer benutzt die Abkürzungen, wir nicht.
- Die public_transport=platform ist eine Ortsangabe und keine Straße, der highway-tag ist überflüssig.

Sehe ich auch so.
Beim letzten Punkt würde ich das auch gerne so sehen, nur: 'Bahnsteig' heißt wohl "platform" und wird eher als Fläche gesehen - und so wurde es in München massenhaft gemapped.
"platform" als Ortsangabe gefällt mir, weil es für mich einen "Node" impliziert - wie bei "place".

Vielleicht habe ich meine Situation nicht genau erklärt, aber ich versuche keine Probleme zu schaffen sondern ich versuche rauszufinden wie auch kompliziertere Sachverhalte sich beschreiben lassen, damit wir das im Wiki anhand eines Beispiel dokumentieren können.

Bei mir hat der Verkehrsverbund nichts mit den Haltestellen am Hut sondern nur einzelne Unternehmen. Es stimmt, das grundsätzlich ein Unternehmen für die Haltestelle verantwortlich ist, aber das ist nicht am Schild zu erkennen, außer bei einem Unternehmen an der internen Id. Dort ist das Unternehmen aber nicht identisch zum Operator. Bei den GTFS-Daten ist es auch bunt gemischt und ich habe etliche Quellen und keine vom Verbund.

Am Hauptbahnhof habe ich Haltestellen der Stadtlinien mit "Hauptbahnhof" auf dem Schild an mehreren Ort. Daneben den zentralen Omnibusbahnhof mit nur Steignummern und meist mit "Stadtname (ZOB)" oder auch "Stadtname Hauptbahnhof (ZOB)" bezeichnet. Zu allem Überfluss halten manche Stadtbuslinienvarianten auch am ZOB. Last but not least, noch die Bahnsteige für den Zugverkehr, wo von "Hauptbahnhof" über "Stadtname Hbf" zu "Stadtname Hauptbahnhof" alles vorkommt.

stop_area_group ist in PTv2 nicht definiert, somit Ende ich mit mindestens drei stop_area.
Welcher Namen soll jetzt bei der jeweiligen Haltestelle bzw stop_area unter name=*, short_name, reg_name, official_name?

In einem Stadtteil der eingemeindet wurde existiert die Haltestelle "Rathaus". Da hier einige Überland-Linien halten mit mehreren Haltestellen in unterschiedlichen Orten mit dem Namen "Rathaus" brauchen wir den Ort in einem *name* Tag. In welchem? Wie soll der lauten "Stadt Stadtteil Name"?

--

Ich würde liebend gerne den highway von pt=platform trennen bzw entfernen. Von Plattformen nur als Punkt, wenn es sich um eine separate Fläche handelt, halte ich nicht so viel, da die räumliche Information verloren geht und aus der Fläche einen Punkt zu berechnen sollte möglich sein. Woran ich mich bei den Flächen am meisten störe ist, wenn ich sie in Abschnitte aufteilen muss, da sich z.B. surface, covered, layer oder lit ändert.

jengelh wrote:

skyper wrote:

Bei den QR-Codes und den websites bin ich vorsichtig. Was machtst Du bei Haltestellen die z.B. von fünf unterschiedlichen Unternehmen angefahren werden.

In der Praxis ist es noch krasser. Die Buskante (tactile_paving und evtl. ein Betonfahrbelag) wird durch die Gemeinde hergestellt/betrieben, der H-Lolli vom Hauptverkehrsunternehmer oder einem Zweckverband, der Unterstand durch ein Werbeunternehmen oder Zweckverband oder - bei Holzhütten - wieder die Gemeinde :-)

Habe ich Glück, dass es bei mir das städtische Tiefbauamt für alles zuständig ist. Hat nur wenig mit ÖPV zu tun.

@skyper: Kannst du mal sagen welchen Bahnhof du meinst.

Eine route kann durchaus mehrere Haltestellen Rathaus haben. Liegen sie dicht beieinander sollte eine unterscheidende Ortsbezeichnung hinzukommen. Das wird von den Verkehrverbünden aber meist schon berücksichtigt. Es gibt aber ländliche Bereiche wo an jede zweiten Haltestelle Mitte (für Dorfmitte) steht. Ich hab hier schon mal den Griff in die Zukunft gemacht und nur den Dorfnamen eingesetzt.

Die teilüberdachte platform ist kein Problem, wenn man das Dach einzeln taggt.
Die platform halb auf der Brücke und halb neben der Brücke kann nach meiner Meinung nur als Multipolygon erfasst werden.

Die platform ist nach public_transport-Proposal ein way oder area. Nur in Ausnahmefällen ein node. Die Interpretationen in unserem wiki sind haarsträubend.

Die stop_area_group ist nicht willkommen, aber auch nicht verboten. Wenn der Zusammenhang nicht anderst darstellbar ist, setze sie ein.

Bahnhof ohne ZOB

• https://www.openstreetmap.org/way/223760658 + https://www.openstreetmap.org/node/7567613828
  
• https://www.openstreetmap.org/relation/9709891 + https://www.openstreetmap.org/node/1482533328 + https://www.openstreetmap.org/node/340236103
  

Kleiner Bahnhof mit ZOB:

• https://www.openstreetmap.org/way/37140775 + https://www.openstreetmap.org/relation/7159186
  
• https://www.openstreetmap.org/way/76274895 + https://www.openstreetmap.org/relation/7159183
  

mittlerer Bahnhof mit ZOB und zusätzlichen Busstop

• https://www.openstreetmap.org/node/2727124071 + https://www.openstreetmap.org/node/2727124071 + https://www.openstreetmap.org/node/7294254350
  
• https://www.openstreetmap.org/way/30612951 + https://www.openstreetmap.org/relation/6087996 + https://www.openstreetmap.org/relation/6082392
  

Hauptbahnhof:

• https://www.openstreetmap.org/relation/6311483 + https://www.openstreetmap.org/relation/7159172 + https://www.openstreetmap.org/relation/6062551 + https://www.openstreetmap.org/relation/7159173
  

Bei den Beispielen geht es mir jetzt erst Mal nur um die Namens-Tags, dass hier einiges verbessert werden kann, ist mir bewusst.

Das Mitten den Ortsnamen davor hat sich hier auch verbreitet im ländlichen Raum. Da ist jetzt halt die Frage nach dem Schlüssel für den Namen am Schild. Wo ist die Grenze nach oben? In Berlin jetzt alle Haltestellen mit "Berlin ..." zu versehen wird wohl wenig Zustimmung bekommen. Wie sieht das in einer Klein-Stadt aus?

Bei z.B. https://www.openstreetmap.org/node/459998738 steht "Apotheke" auf dem Schild. Die VAG hat die Haltestelle unter "Freiburg, Apotheke" gelistet. Ist "Freiburg-Munzingen Apotheke" hier angebracht?

Haben wir uns falsch verstanden? pt=platform ist doch wohl auch für Punkte definiert. Anders lassen sich tausende von Bushaltestellen auch nicht darstellen. Kenne in Europa schon etliche Haltestellen ohne jeglichen realen Hinweis der Existenz. Im Fahrplan sind die Stops zum Teil verzeichnet und die Busse halten.

Wenn es um *way=platform geht ist ein Punkt wohl nicht angebracht.

Der Hauptbahnhof enthält schon etliche platforms as area z.B. hat Gleis 8 unterschiedlichen Belag.
Weiteres Beispiel: https://www.openstreetmap.org/relation/10031889

Eigentlich würde ich die Plattform gern als ein Objekt darstellen, aber MPs aus aneinanderliegenden Flächen sind inkorrekt und so bleibt mir dann wohl nur das Trennen von Eigenschaften zwischen den einzelnen Flächen mit surface, layer ... und der pt=platform mit den PT-Tags und den Tags welche für die gesamte Fläche gelten.

skyper wrote:

Das Mitten den Ortsnamen davor hat sich hier auch verbreitet im ländlichen Raum. Da ist jetzt halt die Frage nach dem Schlüssel für den Namen am Schild. Wo ist die Grenze nach oben? In Berlin jetzt alle Haltestellen mit "Berlin ..." zu versehen wird wohl wenig Zustimmung bekommen. Wie sieht das in einer Klein-Stadt aus?

Bei z.B. https://www.openstreetmap.org/node/459998738 steht "Apotheke" auf dem Schild. Die VAG hat die Haltestelle unter "Freiburg, Apotheke" gelistet. Ist "Freiburg-Munzingen Apotheke" hier angebracht?

Man beachte:
Freiburg [Komma] Apotheke
Der Name der Haltestelle ist 'Apotheke' - dies ist natürlich nur innerhalb des Ortes eindeutig.
Sobald es eine ortsübergreifende Linie oder ein Verbund ist, braucht man zur Unterscheidung die Ortsangabe - die wird aber deswegen nicht Teil des Namens.
Auch auf einer Karte ist der Name 'Apotheke' durch die räumliche Zuordnung ausreichend - in einem Fahrplan oder Liste aber eben nicht.

GeorgFausB wrote:

skyper wrote:

Das Mitten den Ortsnamen davor hat sich hier auch verbreitet im ländlichen Raum. Da ist jetzt halt die Frage nach dem Schlüssel für den Namen am Schild. Wo ist die Grenze nach oben? In Berlin jetzt alle Haltestellen mit "Berlin ..." zu versehen wird wohl wenig Zustimmung bekommen. Wie sieht das in einer Klein-Stadt aus?

Bei z.B. https://www.openstreetmap.org/node/459998738 steht "Apotheke" auf dem Schild. Die VAG hat die Haltestelle unter "Freiburg, Apotheke" gelistet. Ist "Freiburg-Munzingen Apotheke" hier angebracht?

Man beachte:
Freiburg [Komma] Apotheke
Der Name der Haltestelle ist 'Apotheke' - dies ist natürlich nur innerhalb des Ortes eindeutig.
Sobald es eine ortsübergreifende Linie oder ein Verbund ist, braucht man zur Unterscheidung die Ortsangabe - die wird aber deswegen nicht Teil des Namens.
Auch auf einer Karte ist der Name 'Apotheke' durch die räumliche Zuordnung ausreichend - in einem Fahrplan oder Liste aber eben nicht.

Ja, deshalb gibt es doch "ref_name" (= "Freiburg, Apotheke"), um aus dem nicht eindeutigen "Name" etwas eindeutiges zu machen.

War doch weiter oben schon erwähnt.

ToniE wrote:

GeorgFausB wrote:

skyper wrote:

Das Mitten den Ortsnamen davor hat sich hier auch verbreitet im ländlichen Raum. Da ist jetzt halt die Frage nach dem Schlüssel für den Namen am Schild. Wo ist die Grenze nach oben? In Berlin jetzt alle Haltestellen mit "Berlin ..." zu versehen wird wohl wenig Zustimmung bekommen. Wie sieht das in einer Klein-Stadt aus?

Bei z.B. https://www.openstreetmap.org/node/459998738 steht "Apotheke" auf dem Schild. Die VAG hat die Haltestelle unter "Freiburg, Apotheke" gelistet. Ist "Freiburg-Munzingen Apotheke" hier angebracht?

Man beachte:
Freiburg [Komma] Apotheke
Der Name der Haltestelle ist 'Apotheke' - dies ist natürlich nur innerhalb des Ortes eindeutig.
Sobald es eine ortsübergreifende Linie oder ein Verbund ist, braucht man zur Unterscheidung die Ortsangabe - die wird aber deswegen nicht Teil des Namens.
Auch auf einer Karte ist der Name 'Apotheke' durch die räumliche Zuordnung ausreichend - in einem Fahrplan oder Liste aber eben nicht.

Ja, deshalb gibt es doch "ref_name" (= "Freiburg, Apotheke"), um aus dem nicht eindeutigen "Name" etwas eindeutiges zu machen.

War doch weiter oben schon erwähnt.

Ok, war nicht das beste Beispiel, da nur die VAG GTFS-Daten dafür hat. Das Komma ist mit Vorsicht zu genießen, zumindest was die Beschriftung des Schilds angeht.

Ein Stop weiter südlich wird mein Dilemma deutlicher:

SBG:
de:08311:5220,Munzingen Romansstraße,47.968470,7.698849

SWEG:
de:08311:5220:1:1,Munzingen Romanstraße,47.967887,7.699245

VAG:
"de:08315:5220:0:1","Romanstraße","47.9678988075301","7.69924470559197","","Parent5220"
"de:08315:5220:0:2","Romanstraße","47.9679649685477","7.69906504253512","","Parent5220"
"Parent5220","Romanstraße","47.9679288807304","7.69914589091071","1",""

Nebenbei wohl mal wieder ein Typo in den GTFS-Daten.

Zwei bzw drei Stadtteile weiter nördlich sieht es dann so aus, als ob nur da ein Stadtteilname verwendet wird, wo es zur Unterscheidung innerhalb der kleinen Anzahl von eigenen Haltestellen nötig ist:

"de:08311:30055:0:1","Freiburg, Waltershofen Ochsen","48.0234441990401","7.71921425436073","","Parent30055"
"de:08311:30055:0:2","Freiburg, Waltershofen Ochsen","48.0234682317162","7.71930408588915","","Parent30055"
"de:08311:30055:0:3","Freiburg, Waltershofen Ochsen","48.0234441990401","7.71920527120789","","Parent30055"
"de:08311:30055:0:4","Freiburg, Waltershofen Ochsen","48.0234682317162","7.71930408588915","","Parent30055"
"Parent30055","Freiburg, Waltershofen Ochsen","48.0234502072102","7.71925917012494","1",""

"de:08311:30061:0:1","Freiburg, Opfingen Ziegelei","47.9991654754011","7.72640975978753","","Parent30061"
"de:08311:30061:0:2","Freiburg, Opfingen Ziegelei","47.9990272222218","7.72776621586674","","Parent30061"
"de:08311:30064:0:1","Freiburg, Opfingen Rathaus","48.0001873352371","7.71536946494416","","Parent30064"
"de:08311:30064:0:2","Freiburg, Opfingen Rathaus","48.0002534548822","7.71554014484817","","Parent30064"
"Parent30061","Freiburg, Opfingen Ziegelei","47.9990933433538","7.7270385804865","1",""
"Parent30064","Freiburg, Opfingen Rathaus","48.0002234005086","7.71545031331975","1",""

noch mal eine Ortschaften weiter nach Osten, jetzt außerhalb der Stadt:

SBG:
de:08315:30050,Umkirch Im Brünnleacker,48.029422,7.771065
de:08315:30050:0:1,Umkirch Im Brünnleacker,48.029524,7.771092
de:08315:30924,"Umkirch, Gärtnerei",48.035784,7.761381
de:08315:30924:0:1,"Umkirch, Gärtnerei",48.035675,7.761444

VAG:
"de:08315:30050:0:1","Umkirch, Im Brünneleacker","48.0292898173644","7.77181959740609","","Parent30050"
"de:08315:30050:0:2","Umkirch, Im Brünneleacker","48.0293859370993","7.77094823158037","","Parent30050"
"de:08315:30924:0:1","Umkirch, Gärtnerei","48.0356753825665","7.76144405587307","","Parent30924"
"de:08315:30924:0:2","Umkirch, Gärtnerei","48.0358856182003","7.76126439281622","","Parent30924"
"Parent30050","Umkirch, Im Brünneleacker","48.029325862286","7.77138840606965","1",""
"Parent30924","Umkirch, Gärtnerei","48.0357835038568","7.76138117380317","1",""

Was kommt jetzt in reg_name=*, die Stadt und/oder der Stadtteil mit Komma oder ohne? Eventuell auch analog zu uic_name mit multiplen Werten?
Was soll in name=* und wie soll der Name auf dem Schild abgebildet werden.

Weiter oben lese ich auch die Forderung nach dem sich lösen von "on the ground" und den Ruf nach generellem Eintragen der Ortschaftsnamen.

Ich würde das gerne im Wiki festhalten.

skyper wrote:

Was kommt jetzt in reg_name=*, die Stadt und/oder der Stadtteil mit Komma oder ohne?

Also in 'ref_name' würde ich die Stadt/Gemeinde mit aufnehmen, mit Komma.

Innerhalb einer Stadt würde ich Gemeinde-/Stadt-Teile (zunächst) nicht aufnehmen, es sei denn,

• der Name ist mit "Stadt, xxx" immer noch nicht eindeutig
  
• der Stadtteilname ist auch auf dem Schild zu seien (on-the-ground).
  

Bei "name" bin ich dagegen, den Namen der Stadt (z.B. "Berlin") flächendeckend in "name" aufzunehmen.

BTW: bei SBG "Umkirch Im Brünnleacker, und VAG "Umkirch Im Brünneleacker" ist bei der VAG wohl ein Typo?

Ich habe zufällig diesen Wikieintrag gesehen:

https://wiki.openstreetmap.org/wiki/DE:Key:ref_name

Kenne mich leider mit ÖPNV in Germany nicht so gut aus.

ToniE wrote:

skyper wrote:

Was kommt jetzt in reg_name=*, die Stadt und/oder der Stadtteil mit Komma oder ohne?

Also in 'ref_name' würde ich die Stadt/Gemeinde mit aufnehmen, mit Komma.

Innerhalb einer Stadt würde ich Gemeinde-/Stadt-Teile (zunächst) nicht aufnehmen, es sei denn,

• der Name ist mit "Stadt, xxx" immer noch nicht eindeutig
  
• der Stadtteilname ist auch auf dem Schild zu seien (on-the-ground).
  

Bei "name" bin ich dagegen, den Namen der Stadt (z.B. "Berlin") flächendeckend in "name" aufzunehmen.

BTW: bei SBG "Umkirch Im Brünnleacker, und VAG "Umkirch Im Brünneleacker" ist bei der VAG wohl ein Typo?

Eher bei der SBG, in diesem Fall. Habe bisher schon mehrfach gedacht ein System zu erkennen und habe es immer wieder verworfen. Zu Letzt in Gundelfingen (direkt nördlich der Stadt). Will hier nicht die halbe Datei zitieren, aber Ihr könnt ja gerne die drei - fünf gültigen Feeds (SPVN, S-und-U-Bahn, BW-SBG, BW-SWEG und BW-VAG) mit der jeweiligen stops.txt runterladen. Ist auf https://ptna.openstreetmap.de/results/D … lysis.html alles verlinkt.

surveyor54 wrote:

Ich habe zufällig diesen Wikieintrag gesehen:

https://wiki.openstreetmap.org/wiki/DE:Key:ref_name

Kenne mich leider mit ÖPNV in Germany nicht so gut aus.

Die englische Version verstehe ich, da ist der Vergleich zu uic_name. Bei der deutschen Version steht dann was anderes. Wenn ich meine Beispiele der Bahnhöfe verwende, haben zwei kleine Bahnhöfe (Endingen und Gundelfingen) eine siebenstellige IBNR auch für die Bushaltestellen während ansonsten die ZOBs und sonstigen Bushaltestellen nicht aufgelistet werden (https://www.michaeldittrich.de/ibnr/online.php). Was nun? Bei der Bushaltestelle in Endingen, bestehend aus einem Schild am Fahrbahnrand, ein uic_name und in Gundelfingen, der einzige Stop mit uic_name und ansonsten ausschließlich reg_name an fast allen Linien?

Es wird von uic_ref und HAFAS gesprochen aber leider fehlt ein Link zu der Datenbank oder wo ich zumindest diese Informationen zum Abgleich finden kann.

Ich verstehe, dass uic und HAFAS nicht unter uic zusammengefasst werden soll, allerdings wenn ich mir allein die GTFS-Daten anschaue, ohne digitale und Print-Fahrpläne, komme ich schon mit nur einem Wert nicht wirklich aus. Ich habe auch kein Problem mit long_name, short_name, official_name, alt_name und local_name, wenn wir uns einigen können, welcher Schlüssel , bei Haltestellen, wie zu verwenden ist.

surveyor54 wrote:

Ich habe zufällig diesen Wikieintrag gesehen:

das sehe ich ja noch als richtig, wie im (en):

ref_name= * kann Suchmaschinen einen Namen wie einen Suchschlüssel geben (z. B. Zeitpläne / Zeitpläne).

Das dann aber in (de) steht:

ref_name=* wird derzeit ausschließlich zur Verknüpfung von Haltestellen des öffentlichen Nahverkehrs mit der HAFAS-Datenbank,

1. Ist diese die einzigste Datenbank in DE?
2. Ist sie öffentlich zugänglich?
3. Ist sie an den Haltestellen zu erkennen?
4. Sollten wir überhaupt so weit gehen so etwa in OSM zu verknüpfen?

ref_name sollte hier mit aufgeführt werden als allgemeiner Name einer Verbindung:
https://wiki.openstreetmap.org/wiki/Names

Für den speziellen Namen würde ich hafas_name=* vorschlagen. Außerdem ist die WIKI-Seite gerade erst erstellt.

Ich versuche es einfach erst einmal einfach, was an der Haltestelle vorhanden ist.

Wie erstellt man egtl. die stop_area, wenn die Stops in die eine Fahrtrichtung A heisst und in die Gegenrichtung B? Das kommt in China haeufiger vor, da hier die Haltestellen nach den sich kreuzenden Strassen benannt sind.

Oder wenn die Haltestelle der Metro leicht anders benannt ist als die zugehoerige Bushaltestelle?

aighes wrote:

Wie erstellt man egtl. die stop_area, wenn die Stops in die eine Fahrtrichtung A heisst und in die Gegenrichtung B?

Die beiden Haltestellen A und B bilden getrennte stop_area (mit stop+platform) und die stop_areas kommen zusammen in eine stop_area_group.

aighes wrote:

Oder wenn die Haltestelle der Metro leicht anders benannt ist als die zugehoerige Bushaltestelle?

Jeweils eigene stop_areas, die dann zusammen in eine stop_area_group kommen.

ToniE wrote:

aighes wrote:

Wie erstellt man egtl. die stop_area, wenn die Stops in die eine Fahrtrichtung A heisst und in die Gegenrichtung B?

Die beiden Haltestellen A und B bilden getrennte stop_area (mit stop+platform) und die stop_areas kommen zusammen in eine stop_area_group.

aighes wrote:

Oder wenn die Haltestelle der Metro leicht anders benannt ist als die zugehoerige Bushaltestelle?

Jeweils eigene stop_areas, die dann zusammen in eine stop_area_group kommen.

Und dann fehlt mir leider noch eine übergeordnete Ebene für die komplette Station mit den nach Fahrtrichtung unterschiedlich benannten Metro-Stationen und den dazugehörenden Bushaltestellen. Wie bekomme ich die einzelnen stop_area_group jetzt miteinander verknüpft?

Gleiches Problem habe ich mit Hauptbahnhof, ZOB und daneben/-drüber/-drünter liegenden zusätzlichen Haltestellen.

skyper wrote:

Und dann fehlt mir leider noch eine übergeordnete Ebene für die komplette Station mit den nach Fahrtrichtung unterschiedlich benannten Metro-Stationen und den dazugehörenden Bushaltestellen.

Die stop_area_group nimmt alle stop_area-Relationen auf, die sich in der Gegend befinden, quasi alle stop_area, die zu einem Umsteige-Bereich gehören.

Gibt es das, wo eine Station mal Ax und dann man wieder Ay heißt (selbes Gebäude/Areal), wo x und y was mit der Fahrtrichtung zu tun haben?

Sowas wie für Züge in München?

• S- und U-Bahn : Ostbahnhof
  
• Regional und Fernzüge : München-Ost (mit oder ohne '-', egal)
  
• Busse und Tram : Ostbahnhof
  

analog dazu 'Pasing' und 'München-Pasing'