Diskussion über Public Transport Version 2.1

Nakaner wrote:

Das Schema wäre also, relativ kompatibel zu Version 2, daher die Nummer 2.1.

Fällt euch noch was ein, was in eine neue Revision hineinsollte?

Beim Thema Rufbusse fällt mir ein, dass man hier vorsichtig sein muss. Es gibt da der Angebote vieler. Von Linienfahrten mit einzelnen Haltestellen über Korridorbetrieb bis zum Flächenrufbus ohne festen Fahrweg.

Außerdem gabs dafür schon einmal Tags:
http://wiki.openstreetmap.org/wiki/User … sbuslinien
(on_demand)

Ja Segmentrouten!

Für public_transport=platform/highway=bus_stop wo alle andere Details wie name, ref, route_ref, operator, network, zone vermeldet sind, auch immer Nodes verwenden. Vielleicht wäre public_transport=(flag)pole ein besserer Tag gewesen.

public_transport=platform/highway=platform|railway=platform auf Ways und Areas verwenden für das eigentliche Platform. Diese aber nur an die stop_area Relation hinzufügen, und nicht an die Route Relationen.

public_transport=stop_position auch nur an die stop_area Relation hinzufügen, und nicht an die Route Relationen.

Eine stop_area Relation für jede Fahrtrichtung machen mit alles was für diese Fahrtrichtung gilt und diese Relationen sammeln in eine separate stop_area Relation. Wo es auch Metro gibt, habe ich das sogar in 3 Stufen anstatt 2 gemacht. Also alle Metroeingänge und (Roll)Treppe zusammen mit die stop_area Relationen.

Beispiel ist warscheinlich deutlicher:

https://www.openstreetmap.org/relation/4121654/history

In Belgien haben wir alle Haltestellen gemapt, mit die von Brüssel sind wir noch beschäftigt.

Wir haben 3 Transportgesellschaften. Um das QC zu erleichtern und ständig up-to-date zu bleiben können mit die upstream Datasets, habe ich für jede Gesellschaft eine separate Node gemappt. Das seht etwas komisch aus und vielleicht müssten wir Frederik's Vorschlag benutzen um die 'Virtuellen' auch mit Relationen da zu stellen. Die gleiche Situation gibt's auch wenn ein Gesellschaft über die Grenze Haltestellen bedient:

https://www.openstreetmap.org/relation/3908814/history

Am anfang hatte ich versucht um das alles mit einer Node zu machen, aber jede Gesellschat hat ihre eigene refs, route_refs, zone und manchmal auch abweichende Namen (wegen die unterschiedliche Sprachen oder sogar das die Franzosischsprechenden noch eine archäische niederländische Rechtschreibung benutzen).

Wenn wir das mit virtuellen Nodes machen wollen, dann heisst das dass auch Relationen in die Routerelationen und stop_areaRelationen als platform vorkommen können.

Gut, das sind die Anpassungen die ich notwendig gefunden habe um die PT-Situation in Belgien mappen zu können.

Polyglot wrote:

Ja Segmentrouten!

Für public_transport=platform/highway=bus_stop wo alle andere Details wie name, ref, route_ref, operator, network, zone vermeldet sind, auch immer Nodes verwenden. Vielleicht wäre public_transport=(flag)pole ein besserer Tag gewesen.

public_transport=platform/highway=platform|railway=platform auf Ways und Areas verwenden für das eigentliche Platform. Diese aber nur an die stop_area Relation hinzufügen, und nicht an die Route Relationen.

public_transport=stop_position auch nur an die stop_area Relation hinzufügen, und nicht an die Route Relationen.

Eine stop_area Relation für jede Fahrtrichtung machen mit alles was für diese Fahrtrichtung gilt und diese Relationen sammeln in eine separate stop_area Relation. Wo es auch Metro gibt, habe ich das sogar in 3 Stufen anstatt 2 gemacht. Also alle Metroeingänge und (Roll)Treppe zusammen mit die stop_area Relationen.

Dem stimme ich fast zu. Allerdings sollten die relationen nicht alle stop_area heißen. Sondern es sollte eine Relation für den gesamten Bereich geben und Relationen für stop_positon platform und pole

Polyglot wrote:

Wir haben 3 Transportgesellschaften. Um das QC zu erleichtern und ständig up-to-date zu bleiben können mit die upstream Datasets, habe ich für jede Gesellschaft eine separate Node gemappt. Das seht etwas komisch aus und vielleicht müssten wir Frederik's Vorschlag benutzen um die 'Virtuellen' auch mit Relationen da zu stellen. Die gleiche Situation gibt's auch wenn ein Gesellschaft über die Grenze Haltestellen bedient:

Hier denke ich ist mit einem Punkt/node je Unternehmen deutlich über das Ziel hinausgeschossen. Es gibt die Möglichkeit schon heute ref:unternehmen oder ref:network sowie name:unternehmen und name:network. Daher bin ich dagegen zusätzliche nodes für sonst gleiches einzufügen.

Ich finde, wenn solche großen Änderungen geplant werden, sollte noch vor dem Proposal-Prozess der Kontakt zu den ÖPNV-Unternehmen gesucht werden. In NRW war da doch vor einiger Zeit ein Treffen mit dem VRR?

Seoman wrote:

Ich finde, wenn solche großen Änderungen geplant werden, sollte noch vor dem Proposal-Prozess der Kontakt zu den ÖPNV-Unternehmen gesucht werden. In NRW war da doch vor einiger Zeit ein Treffen mit dem VRR?

Es gibt eigentlich bloß einen relevanten Nutzer, der mir einfällt. Das ist Mentz DV (steckt auch hinter der VRR-Initiative). Ich wollte denen eh eine Mail mit Hinweis auf dieses Diskussion schicken und habe es jetzt getan.

Nakaner wrote:

ÖPNV-Routen sollten in Segmente aufsplittbar sein.

Dabei braucht man dann für jedes Segment zwei Relationen: Eine für die Haltestellen und eine für den Fahrweg. Dann kann man wenn man beim Auswerten auf ein solches Objekt, das eine neue Rolle haben sollte, stösst "einfach" so tun als seien ihre Unterobjekte direkte Unterobjekte der Route.

Nakaner wrote:

an Master-Relationen (oder Routenrelationen)

Festschreiben, dass Tags ausser ref=* (also z.B. operator=*) nur an der höchsten Ebene auf die sie zutreffend sind stehen sollen.

Nakaner wrote:

Zusätzliche Rollen stop_on_demand, exit_on_demand, entry_on_demand

Ich vermute das (exit_on_demand statt z.B. stop_exit_only_on_demand) war nicht so gemeint und würde die Beschreibung davon etwa wie folgt ändern:

[Beschreibung Rollen "stop" und "platform"] An diese Rollen können mit einem Unterstrich beginnende Teilstrings zur Einschränkung angehängt werden. Auf einen dieser Teilstrings kann ein weiterer folgen. Dabei bedeuten: [Beschreibung der Teilrollen]

Nakaner wrote:

stop_sometimes, stop_on_demand_sometimes, exit_on_demand_sometimes, entry_on_demand_sometimes für Bedarfshalte

Für was soll das "sometimes" gut sein?

Nakaner wrote:

• grobe Angabe zu den Verkehrstagen (nur Mo-Fr, oder nur Fr+So)
  
• grobe Angabe zum Takt oder dem Verkehrszeitraum (alle 2 Stunden, "nur 6:00-9:00; 15:-19:00", nur bei Schnee, nur sommers, tideabhängig)
  

Kennst du schon headway=*?

Nakaner wrote:

Umgang mit Halten, die nur in Tagesrandlagen bedient werden (z.B. hält der RE Stuttgart–Würzburg frühmorgens auch in Boxberg-Wölchingen oder Besigheim)

Würde ich mit einer eigenen Route-Relation machen, die dann ein noch zu findendes Tag für "verkehrt ungewöhnlich selten" (oder ähnliches) erhält.

Tags für AEG-und-PBefG-Linien und Rufbusse (siehe das Postin von viw) wünsche ich mir auch, die übrigen Punkte sind mir eher egal.

Nakaner wrote:

... und genauso unschön, die Linien an der Systemgrenze EBO/BOStrab die Farbe wechseln zu lassen, wenn die Liniennnummer gleich bleibt.

Das ist im Moment (ich meine bei PTP) nicht so. Eine Linie ist immer durchgezogen und kann keinen Wechsel des Verkehrsmittels haben.

Einführung eines Wertes für Rufbusse (und ggf. Linientaxen).

Ich kenne jn Schweden viele Buslinien, die mal per Bus und mal per Taxi bedient werden. Wenn das Linientaxi abgetrennt wird, wird man noch einen dritten Wert für Mischbetrieb brauchen. Eigentlich interessiert das aber keinen Passagier.

Derzeit gibt es nach dem neuen Schema bei Bushaltestellen immer zwei stop_positions...

Nein. Man kann -- und sollte in so einem Fall -- eine machen.

ÖPNV-Routen sollten in Segmente (wie bei Wanderwegen, Fahrradrouten usw.) aufsplittbar sein.

Das ist schwierig, weil sie dann wieder zusammengefast werden müssen. Einfacher ist es, wenn man Segmente ohne Tags definiert und diese in den Routen "include"n kann.

...entry_on_demand_sometimes für Bedarfshalte

Dann müsste man jede Buslinie mit diesen Wortungetümen vollpflastern.

Fällt euch noch was ein, was in eine neue Revision hineinsollte?

Niklaus Wirth hat mal gesagt "Man ist erst fertig, wenn man nichts mehr weglassen kann".

Ich denke, dass man die stop_positions eigentlich nicht braucht (höchstens als Ersatz für noch nicht gemappte Platforms). Die Platforms braucht man für das Fußgängerrouting beim Ein-, Aus- und Um-steigen. Man könnte in den Routen mit den Rollen "platform" für die Steige und "substitute" für vorläufige Ersatzobjekte aller Art auskommen. Um mehrere Platforms für einen Halt zuzulassen (z.B. beidseitiger U-Bahn-Auslass an der Esprit-Arena in Düsseldorf oder wegen Brücken-Tags geteilte Bahnsteige wie in Oberhausen-Holten), könnte man für zusätzliche Angaben desselben Halts "+" benutzen (also "+platform"). So bleibt klar, wieviel Haltestellen denn nun da sind.

Wenn Bedarf an der zusätzlichen Aufnahme von Stationsangaben besteht, könnte man "+station" verwenden. (Ist nur diese Angabe da, dann "substitute")

Beim PTP ist die Bedeutung von "name" zwar eindeutig angegeben ... es ist aber schwer zu finden. Da sollte man klar angeben, dass "name" der Name der "Station i.W.S." ist. Diesen Namen optional zu machen, wenn die Angabe schon in der stop_area steht, war keine gute Idee und erschwert das Leben der Mapper und der Programme.

Im Moment wird "ref" für Gleis/Steig-nummern verwendet. Das kann sich mit anderen benötigten Nummern beißen. Ein eigenes Tag wie etwa "platform" wäre gut. Der Inhalt sollte keine Wortteile wie "Bahnsteig" oder ähnliches enthalten ... nur die nackte Nummer oder was immer es ist.

Für den Namen der Linie sollte man nicht wie in PTP <vehicle> <ref>: <from> => <via> => <to> verwenden. Praktischer für die Passagiere ist die Beschriftung, wie man sie bei Bussen z.B. vorn findet. Wo verschiedene Varianten gleiche Namen hätten, muss das ergänzt werden ... aber nur dann.

An einigen Bahnhöfen haben Linien HWG (nein, nein, das bedeutet "häufig wechselnde Gleise") und in Paris gibt es glaube ich auch schon dynamische Gleiszuweisungen. Das führt bei PTP zu gigantischen Variantenvervielfachungen. (z.B. in Koblenz beim Nahverkehr von der Nahestrecke). Noch so ein Bahnhof auf dieser Strecke würde zu zig Kombinations-Varianten führen, die nun wirklich keiner will) Man muss ja eigentlich nur wissen, welche Bahnsteige in Frage kommen (wg. Aufzug, Blindenleitbelag) und wie der Zug vor und hinter dem Weichenspaghetti des Bahnhofs fährt. Dazu könnte man eine PT-Nullrelation definieren, die als Fahrweg benutzt die uninteressanten Varianten ersetzt (damit sie nicht als fehlend gelten). Im Bahnhof lönnte man "platform" (ggf. mit "+platform") für den ersten in Frage kommenden Bahnsteig nutzen und jeden Alternativbahnsteig mit "*platform" (ggf. mit "+platform") angeben.

Die PT-Nullrelation könnte auch als Markierung für "fehlende" Halte genutzt werden. Dieser Fall tritt in der Anfangsphase der Erfassung ziemlich oft auf. "Da war noch ne Haltestelle, aber die Kamera war zu langsam"

Die im PTP nicht vorkommende stop_area_group sollte wieder eingeführt werden. Erstens zur Festlegung eines gemeinschaftlichen Namens für zusammenhängende Bus- und Zugbahnhöfe (z.B. "Solingen Hbf" für den Zugbahnhof "Solingen Hbf" und den Busbahnhof "Hauptbahnhof", der im großen Maßstabfür die Katz ist.) und zweitens könnte diese gemeinschaftliche Einrichtungen wie Parkplätze aufnehmen, die keiner einzelnen stop_area zuzuordnen sind. Im Detail: stop_areas enthalten mit der Rolle "platform" platformobjekte desselben Namens und mit der Rolle "" sonstige Objekte. stop_area_groups haben nur die Rolle "" und enthalten stop_areas und gemeinschaftliche sonstige Objekte und geben einen Globalnamen an.

Ein Tag für "verkehrt danach als ..." und "verkehrte vorher als ..." wäre auch schön. Aber nur für den Fall, dass der Passagier sitzen bleiben darf!

Mir fällt bestimmt gleich noch mehr ein...
Weide

Weide wrote:

Im Moment wird "ref" für Gleis/Steig-nummern verwendet. Das kann sich mit anderen benötigten Nummern beißen. Ein eigenes Tag wie etwa "platform" wäre gut. Der Inhalt sollte keine Wortteile wie "Bahnsteig" oder ähnliches enthalten ... nur die nackte Nummer oder was immer es ist.

Es gibt einen Tag local_ref für Steignummer. In Großbritannien wird es mit Daten aus NaPTAN verwendet, auch in VRR Tagging wird davon gesprochen. Interessant ist, dass local_ref schon in der Transportkarte gerendert wird! Beispiele:

http://www.openstreetmap.org/#map=18/49 … 3&layers=T

http://www.openstreetmap.org/#map=18/50 … 0&layers=T

Hallo,

erst einmal danke fürs Bescheid geben. Der Einladung zur Diskussion
möchte ich daher auch gerne folgen.

Es ist gut zu sehen, dass es Überlegungen zu sehr vielen Bereichen im
ÖPNV gibt. Allerdings würde ich dringend empfehlen, die verschiedenen
Themen auf mehrere Einzel-Schemata aufzuteilen. In OpenStreetMap ist
es gute Tradition, die einzelnen Aspekte so einfach wie möglich zu
halten, damit Mapper sich mit einfacheren Erklärungen beschäftigen
können - oder die Dinge sogar selbsterklärend werden.

Aus unserer Sicht aktuell ist der Leidensdruck gar nicht so hoch. mdv
nutzt vorwiegend Daten, um Personenverkehr auf dem richtigen Gleis
bzw. den richtigen Straßen routen zu können. Daher werde ich hier nur
versuchen, ein paar Themenkreise abzugrenzen, die jeder für sich
besser in einem unabhängigen Proposal münden sollten:

a) Abgrenzung von verschiedenen Arten von Ways: Dazu steht hier nichts
explizit, aber es wäre aus unserer Sicht schön, sich auf eine
Abgrenzung von railway=rail, railway=light_rail, railway=tram und
railway=subway voneinander zu einigen. Man braucht weitere Werte (z.B.
railway=funicular (Seilbahnen) und railway=monorail (Wuppertaler
Schwebebahn), aber deren Verwendung dürfte wenig Verwirrung mit den
anderen vier Werten hervorrufen, die mitunter leicht zu verwechseln
sind.

b) Abgrenzung von verschiedenen Arten von Relationen: Aus meiner Sicht
kann nicht oft genug darauf hingewiesen werden, dass Linien und die
Gleise auf denen sie verkehren, oft verschieden klassifiziert werden.
Dann sind Karlsruhe, die Vorgebirgsbahn und fast alles andere auch
kein großes Problem mehr. Das geht in dem Vorschlag noch etwas unter.

Aus Sicht von mdv wäre es sehr wünschenswert, Strecken mit
Personenverkehr sichtbar zu machen. Ob das jetzt über die Gleise geht
oder über die auf den Gleisen verkehren Relationen ist relativ egal.
Im einen Fall würde man die Relationen auf Basis des Netzes mit
wenigen Zwangspunkten routen. Im ungekehrten Fall erben die Gleise von
den darauf befindlichen Relationen die Eigenschaft, für
Personenverkehr bevorzugt zu werden. Der Ansatz über die Prioirty-Tags
hat da ja keine großen Freunde gefunden, aber das Service-Tag an
Relationen hat sich in NRW nahezu flächendeckend in nur 2-3 Stunden
eintragen lassen - die Lösung ist sehr pflegeleicht. Danke übrigens
für das Hinzufügen zu dem Proposal.

c) Struktur in die Artenvielfalt an straßengebundenen
Bedarfsverkehrsmitteln bringen

Das ist zwar wünschenswert, aber wird eine große Herausforderung. Da
sind die Betriebsformen vielfältig (mit /ohne festem Linienweg,
mit/ohne Aufnahme von Reisenden abseits der Haltestellen, mit/ohne
Vorbuchungsfrist), und das Marketing der Unernehmen am Markt
potenziert die Verwirrung noch. Es ist mühsam genug, eine einheitliche
Terminologie für den VRR zu finden.

d) Detailstruktur von Haltestellen

Aus unserer Sicht ist hier das vorrangige Interesse, dass im fertigen
Modell Fußgängerrouting funktionieren kann. Besser, wenn die Erfassung
gut genug ist, um auch Rollstuhlfahrer und Blinde leiten zu können.
Das Thema allein füllt ganze Konferenzen und ist mit einem
Forums-Teil-Thread sicher stark unterbesetzt. Ich würde es daher
unbedingt aus dieser Diskussion herausnehmen.

e) Segmente für Linien

Hat ebenfalls eine Reihe von Nebeneffekten. Es sei darauf hingewiesen,
dass das Editieren von Relationen auf Relationen alles andere als
bequem ist. Die Auswertung ist eher noch schlimmer. Wenn jetzt der
Vorschlag kommt, doch Tools dafür zu programmieren, sei darauf
hingewiesen, dass Tools, um mit großen Anzahlen an Relationen
umzugehen, ungleich einfacher zu programmieren gibt - und die gibt es
auch nicht oder nur rdumentär. Generell ist das Problem dabei, dass
Relationen auf Relationen große Menge an neuen Sonder- und
Fehlerkombinationen erlauben, von denen ein Tool oder auch ein Mapper
mit jeder einzelnen umgehen muss.

Von daher würde ich anregen, a) und b) als separate Diskussionen
weiterzuführen und dort recht zügig zu einem Proposal weiterzugehen.
c), d) und e) könnten wir uns dann angehen, wenn wir mit a) und b) ein
Erfolgserlebnis gehabt haben.

Viele Grüße,

Roland

PS: Es gibt von Michael auch bereits eine Antwort dazu. Ich vermute, dass er sie dann gleich noch hier anfügt.

drolbr_mdv wrote:

a) Abgrenzung von verschiedenen Arten von Ways: Dazu steht hier nichts
explizit, aber es wäre aus unserer Sicht schön, sich auf eine
Abgrenzung von railway=rail, railway=light_rail, railway=tram und
railway=subway voneinander zu einigen. Man braucht weitere Werte (z.B.
railway=funicular (Seilbahnen) und railway=monorail (Wuppertaler
Schwebebahn), aber deren Verwendung dürfte wenig Verwirrung mit den
anderen vier Werten hervorrufen, die mitunter leicht zu verwechseln
sind.

Das Erfolgserlebnis bei a sehe ich noch nicht so deutlich:
Schwebebahn Dresden:
Die technische Anlage der Schwebebahn basiert auf dem Einschienenhängebahn-Prinzip des Kölner Ingenieurs Eugen Langen. Dabei wird der Fahrbahnträger, auf dem die Schiene befestigt ist, von 32 Pendel- und einer Feststütze getragen.
http://www.dvb.de/de/Freizeit-Tourismus … hwebebahn/

viw wrote:

Das Erfolgserlebnis bei a sehe ich noch nicht so deutlich:
Schwebebahn Dresden:
Die technische Anlage der Schwebebahn basiert auf dem Einschienenhängebahn-Prinzip des Kölner Ingenieurs Eugen Langen. Dabei wird der Fahrbahnträger, auf dem die Schiene befestigt ist, von 32 Pendel- und einer Feststütze getragen.
http://www.dvb.de/de/Freizeit-Tourismus … hwebebahn/

Sorry, aber den Einwand verstehe ich nicht. Die Dresdner Schwebebahn ist doch mit der Wuppertaler technisch fast identisch.
Aber ich verstehe auch den ursprünglichen Vorschlag, die einzelnen Arten von ways besser abzugrenzen nicht so richtig. Was ist rail was ist light_rail (letzteres dürften die S-Bahn im VRR jedenfalls nicht sein, jedenfalls nicht nach dem proposal-Vorschlag. Was ist tram und was ist subway, in Düsseldorf fahren U-Bahnen auch oberirdisch, und in Duisburg gehen "echte" subway-Gleise in "echte" tram-Gleise über.
Die Frage ist doch eher, können trams über subway-Gleise fahren bzw. können tram-Gleise auch subway-Relationen (Linien) bedienen...
Oder habe ich hier etwas völlig falsch verstanden?

Thoschi wrote:

viw wrote:

Das Erfolgserlebnis bei a sehe ich noch nicht so deutlich:
Schwebebahn Dresden ...

Sorry, aber den Einwand verstehe ich nicht. Die Dresdner Schwebebahn ist doch mit der Wuppertaler technisch fast identisch.

Richtig! Sie ist fast identisch. Nur sie hängt am Seil und ist damit auch eine Seilbahn und unterscheidet sich im Antrieb eben gerade nicht von einer gewöhnlichen (Stand-)Seilbahn. Jetzt kann man aber nicht beide Schlüssel gleichzeitig dafür benutzen. Falls Seilbahnen nur das sein sollen, wo die Gondeln auf einem Tragseil hängen, frage ich mich wie man dann Standseilbahnen nennt.
Und was sind Standseilbahnen die die ganze Zeit im Tunnel sind? U-Bahnen wie es Istanbul behauptet?

Thoschi wrote:

Die Frage ist doch eher, können trams über subway-Gleise fahren bzw. können tram-Gleise auch subway-Relationen (Linien) bedienen...

Ja, der Routen-Typ sollte unbedingt vom Gleistyp abweichen können. Beispiele für Mehrwegefahrzeuge aller Art gibt es nunmal sehr viele. Deswegen ja auch die Aufteilung nach a) und b).

Thoschi wrote:

Was ist rail was ist light_rail (letzteres dürften die S-Bahn im VRR jedenfalls nicht sein, jedenfalls nicht nach dem proposal-Vorschlag. Was ist tram und was ist subway

Die S-Bahn-Gleise im VRR sind übrigens unstrittig als railway=rail getaggt.

Es gibt in dem Protokolll vom Bad-Nauheim-Treffen
http://wiki.openstreetmap.org/wiki/DE:O … 2#Gleise_2
wohlüberlegte Kriterien zur Abgrenzung der Begriffe. Ich würde anregen, das als Ausgangspunkt (für a) zu nehmen.

viw wrote:

Falls Seilbahnen nur das sein sollen, wo die Gondeln auf einem Tragseil hängen, frage ich mich wie man dann Standseilbahnen nennt.
Und was sind Standseilbahnen die die ganze Zeit im Tunnel sind? U-Bahnen wie es Istanbul behauptet?

Eine Standseilbahn ist nach meiner Erkenntnis keine, an der Gondeln hängen. Eine Standseilbahn ist für mich z.B. die in Wiesbaden oder die bei Baden-Baden (habe die Namen grad nicht parat).
Wenn eine Gondel fest an einem Seil montiert ist, dann ist es eine Seilbahn, m.E. unabhängig davon ob ein oder mehrere Gondeln dran hängen.
Bei der Dresdner Schwebebahn ist es m.E. eine Hängeseilbahn, welche ich als Standseilbahn taggen würde, denn es ist m.E. egal, ob das Gleis und das Seil oben oder unten verlegt ist, sofern sie auf einem Gleis gezogen wird.

drolbr_mdv wrote:

Die S-Bahn-Gleise im VRR sind übrigens unstrittig als railway=rail getaggt.

Ich habe mich bisher kaum um die S-Bahn Linien gekümmert, aber die S5 (Dortmund - Hagen) ist als light_rail getaggt. Dies ist ja demnach falsch. Werde das mal ändern.

Edit:
Bevor ich da jetzt was ändere, habe hier wohl das Gleis mit der Linie verwechselt. Die S5 ist als route=light_rail getaggt. Aber stimmt das?
sieh auch: http://wiki.openstreetmap.org/wiki/DE:T … light_rail

viw wrote:

Polyglot wrote:

Wir haben 3 Transportgesellschaften. Um das QC zu erleichtern und ständig up-to-date zu bleiben können mit die upstream Datasets, habe ich für jede Gesellschaft eine separate Node gemappt. Das seht etwas komisch aus und vielleicht müssten wir Frederik's Vorschlag benutzen um die 'Virtuellen' auch mit Relationen da zu stellen. Die gleiche Situation gibt's auch wenn ein Gesellschaft über die Grenze Haltestellen bedient:

Hier denke ich ist mit einem Punkt/node je Unternehmen deutlich über das Ziel hinausgeschossen. Es gibt die Möglichkeit schon heute ref:unternehmen oder ref:network sowie name:unternehmen und name:network. Daher bin ich dagegen zusätzliche nodes für sonst gleiches einzufügen.

Gut, ich bin damit beschäftigt um alle 70000 Haltestellen in Belgien um zu wandeln auf ein Schema wobei ref, route_ref, zone und manchmal name eigene Namespaces bekommen. (zb: ref:De_Lijn, route_ref:TEC). Es war konzeptuell einfacher wenn jede Unternehmen ihre eigene Nodes bekam, aber ganz zufrieden war ich auch nicht mit dieser Lösung. Die Skripts fürs QC sind jetzt wohl komplexer geworden.

Hoffentlich wird der Vorschlag mit Segmentrouten, stop_area_group, usw bald erscheinen. Ich würde das sofort Version 3 nennen, anstatt 2.1.

Für die Segmente würde ich nur die ways in Segmente unterbringen. Jede RouteRelation für die Variationen hat dann noch die ganze Liste mit den Haltestellen.

Es ist nicht wirklich problematisch das die Haltestellennodes member sind in ein Vielfalt von Relationen. Für die Ways ist das wohl problematisch, wegen mehr Arbeit beim pflegen wenn die Routerelationen zerbrochen werden und weil es Beginner möglicherweise abschreckt wenn Ways Mitglied sind in viele Relationen.

Polyglot

Polyglot wrote:

Für die Segmente würde ich nur die ways in Segmente unterbringen. Jede RouteRelation für die Variationen hat dann noch die ganze Liste mit den Haltestellen.

Es ist nicht wirklich problematisch das die Haltestellennodes member sind in ein Vielfalt von Relationen. Für die Ways ist das wohl problematisch, wegen mehr Arbeit beim pflegen wenn die Routerelationen zerbrochen werden und weil es Beginner möglicherweise abschreckt wenn Ways Mitglied sind in viele Relationen.

Ich hatte das so verstanden das die Segmente nicht nur die Wege sondern alle Teile einer Route enthalten und aus mehreren Segmenten kann man dann die eigentliche Route zusammensetzen. Ob man da jetzt die Haltestellen davon ausnehmen sollte weiß ich nicht.
Der Vorteil der Segemente wäre eigentlich, dass auf dem Weg weniger Relationen angezeigt werden und man nur diese wieder reparieren muss, wenn etwas kaputtgeht. Die Frage ist wieviel Segement sein sollte.

viw wrote:

Ich hatte das so verstanden das die Segmente nicht nur die Wege sondern alle Teile einer Route enthalten und aus mehreren Segmenten kann man dann die eigentliche Route zusammensetzen. Ob man da jetzt die Haltestellen davon ausnehmen sollte weiß ich nicht.
Der Vorteil der Segemente wäre eigentlich, dass auf dem Weg weniger Relationen angezeigt werden und man nur diese wieder reparieren muss, wenn etwas kaputtgeht. Die Frage ist wieviel Segement sein sollte.

Der Vorteil besteht nicht nur im Fehlerfall. Wenn in der Nähe des Busbahnhofes die Straßenführung geändert wird, muss man sonst in einem Dutzend Relationen überall dieselbe Änderung machen (auch bekannt als Redundanz).

Für 2 von die 3 Unternehmen in Belgien haben wir Zugang auf ihren Daten. Das bekommen 5 Tabellen und damit ist es ganz einfach um Routerelationen zu erfassen für jede Variation ihre Linien. Das funkzioniert aber nur wenn alle Haltestellen in die Routerelation sitzen bleiben.

Für mich ist es auch praktisch sofort zu sehen an welche Routevarianten Nodes teilnehmen.

Die ways füge ich dann nachher zu. Jetzt benutze ich dazu ein Skript das ways sucht die nahe zu die HS sind. Die Route ergänzen muss dann manuell gemacht werden. Diese Arbeit wäre viel einfacher wenn ways schon zusammengefasst wären in Segmentroutes. In viele Fälle würde das sogar sofort korrekt sein. In andere würden vielleicht noch Segmente getrennt werden mussen. Abhängig davon wie "klug" man war beim erfassen des Segmentes. Das ist auch der Grund warum ich route_ref auf die Haltestellen hinzufüge. Dann wird es viel einfacher um das intelligent zu tun, d.h. zu wissen wo am beste diese Segmente zu trennen, beim erfassen.

Polyglot

Ich hab mal wieder einen Entwurf gemacht .. zumindest kann man von ihm sagen, dass er viel einfacher ist als der letzte :-)

https://wiki.openstreetmap.org/wiki/Use … rschlag_P3

bis dann
Weide

Hallo Weide,

Weide wrote:

Ich hab mal wieder einen Entwurf gemacht .. zumindest kann man von ihm sagen, dass er viel einfacher ist als der letzte :-)

https://wiki.openstreetmap.org/wiki/Use … rschlag_P3

Tipp für andere Foristen: Fangt oben auf Weides Userpage an zu lesen.

Auch es nichts mit deinem Vorschlag zu tun hat – die Vergleichstabelle finde ich richtig gut!

Aber nun zu deinem Vorschlag
(1) Du möchtest eine Rolle für die Relationsmitglieder einführen, die ein Stück des Fahrwegs repräsentieren.

(2) Das Tagging von Routen ist in großen Teilen vom bisherigen Tagging verschieden. Charakteristisch ist "p3". Das fängt schon beim wichtigsten aller Relationstags an, dem type=*. Du schlägst type=p3 statt type=route vor, damit die Routen, die nach deinem Vorschlag gemappt werden, von nicht angepassten Programmen nicht ausgewertet werden.

(3) Bei PTv2 sind die möglichen Verkehrsmittel auf ein enges Set beschränkt, welches u.a. keine light_rail enthält. Du schlägst stattdessen kind=rail/road/water/other vor und überlässt die Einführung von Subtags der künftigen Entwicklung.

(4)In deinem Schema müssen nicht mehr sowohl stop als auch platform in die Routenrelation. Stattdessen kommen nur noch Bahnsteige/Wartebereiche mit der Rolle halt hinein. Wenn eine Station einen mehrteiligen Bahnsteig hat (z.B. ein Teil des Bahnsteigs liegt auf einer Brücke), dann bekommt der zweite/dritte Bahnsteigteil die Rolle +halt. Bahnsteige der Spanischen Lösung bekommen die Rolle halt#. Wenn man die Plattform nicht kennt (z.B. weil Grasbahnsteig im hohen Gras oder von Bäumen verdeckter Bahnsteig), dann fügt man bei PTv2 nur die stop_position ein. Bei dir muss man dann die stop_position einfügen und ihr die Rolle halt_fixme zuweisen.

(5) Wenn eine Linie eine Schleife fährt, dann sollten die Schleifenstücke mit den Rollen tour_ccw und tour_cw in die Relation aufgenommen werden.

(6) Für die Routen schlägst du noch optionale Zusatztags wie next_ref, prev_ref, var_ref, active usw. vor.

(7) Dein Schema trennt zwischen den bekannten Stop-Area-Relationen und "Gesamthaltestellen". Sobald eine Steig-/Bahnsteignummernkollision droht (z.B. Gleisnummer der U-Bahn-Station mit der Gleisnummer im DB-Teil des Bahnhofs), sind zwei getrennte Stop-Area-Relationen anzulegen. Eine Gesamthaltestellen-Relation verbindet dann alle Teilhaltestellen.

(8) Um die Abwärtskompatibilität zu wahren, schlägst du vor, währen einer Übergangszeit zwei Routenrelationen zu pflegen.

Meine Meinung
(1) Ich habe die leere Rolle bisher nicht als Problem wahrgenommen. Ich glaube, dass eher JOSM das Problem ist, weil er das anmeckert.

(2) Bisher gibt es das (von JOSM/JOSM-Entwicklern vorgeschlagene) public_transport:version=2, welches aber bloß von den Programmen ausgewertet wird, die auch danach suchen. Programme, die vor Urzeiten geschrieben wurden und seither verstaubt sind, tun das nicht und interpretieren PTv2-Routen als PTv1-Route. Das ist in meinen Augen gar nicht so schlimm. Die mir bekannten Tools, die nicht mit PTv2 (oder das ca. 2010/2011 diskutierten Oxomoa-Schema, welches zurückgezogen wurde bzw. in PTv2 aufging) auswerten, widmen sich i.d.R. nur der grafischen Darstellung von Routen.

Eine Unterscheidung benötigen zwischen PTv2 und deinem Entwurf nur bei Routenrelationen. Alle anderen Bereiche könnte man beim bestehenden Tagging lassen und damit Arbeit einsparen. Denn bloßes Ergänzen von p3*=* ist keine Tätigkeit, mit der man Mapper hinter dem Ofen hervorlocken kann.

(3) Diese Flexibilität gefällt mir. Dafür braucht es aber kein grundlegend anderes Schema. Das liese sich jedoch auch an PTv2 anflanschen (z.B. mit type=route, route=train, route:train=tram+train für Zwitter wie die Karlsruher Zweisystemstadtbahnen). Man kann allen komischen Verkehrsmitteln (Rufbus, Schwebebahn, Transrapid usw.) immer irgendein ähnliches System zuordnen.

(4) Mir gefällt das nicht. Derzeit kann der Relationseditor in JOSM (bzw. auch jeder andere Editor könnte es, wenn er es könnte) anhand der Tags des einzufügenden Objekts entscheiden, ob er ihm automatisch die Rolle stop oder platform zuweist. Wenn ich mehrere Bahnsteige an einer Station habe, dann ist im PTv2 die Reihenfolge egal. Mit deinem Schema kann der Editor nicht automatisch eine Rolle vorschlagen. Was die Zerbrechlichkeit angeht, gibt sich das mit PTv2 aber nichts. Wenn ich von einem dreigeteilten Bahnsteig (Damm–Brücke–Damm), den ersten Teil entferne, dann werden mit deinem Schema die beiden übrigen Teile der vorherigen Station zugeordnet. Bei PTv2 muss man hingegen eine stop_position aus der Route entfernen und schon hat man eine Fehlzuordnung. Für mich rechtfertigt das kein neues Schema.

Stattdessen handelst du dir durch den Verzicht auf die stop_positions weitere Probleme ein. Eine stop_position im Straßenway signalisiert dem Pkw-Router, dass da ein Bus anhalten und den Autofahrer zum Halten zwingen könnte (ich kenne noch kein Tag wie bus_passing_place=yes). Im Schienenverkehr (im Busverkehr nur auf Busbahnhöfen mit einer langen Bussteigkante) spielen Haltepositionen eine wichtige Rolle.
Ob meine kurze Regionalbahn in Köln Hbf (Gleis 4/5 486 m) [1], Essen Hbf (Gleis 7, ca. 685 m = ca. 27 Wagen [2]) oder Gößnitz (588 m)) vorn oder hinten am Bahnsteig steht, macht für das Routing beim Umsteigen einen großen Unterschied (1,5 Min./100m bei 4 km/h!). Daher möchte man im Bahnverkehr die Halteposition mit erfassen und in die Route aufnehmen, wenn sie konstant ist bzw. konstant von der selben Routenvariante genutzt wird.

Im Proposaltext von PTv2 findet man übrigens auch das Argument für die Einführung der stop_position – kürzere Verarbeitungszeiten für Auswerter, da man kein Lot mehr auf den Fahrweg fällen muss. Im Rahmen der Qualitätssicherung kann man ja den Abstand von stop_positon und platform (bei Flächen die Außenkante) bestimmen. Wenn dieser das verkehrsmitteltypische Maß überschreitet (Bahnoffset = Lichtraumprofil + 1 Meter Bing-Ungenauigkeit, Busoffset = lanes/2 + 3 m (für Radweg auf dem Bürgersteig zwischen Bordstein und Wartehäuschen)), dann kann ein Validator Alarm schlagen.

(5) Das gefällt mir. An das Problem habe ich bisher noch gar nicht gedacht.

(6) Die Gedanken hinter dem Zusatztags kann ich nachvollziehen. Dafür braucht es aber keine PTv3.

(7) Das gefällt mir. Im Oxomoa-Schema gab es auch ein Gesamthaltestellen-Konstrukt. Diese war aber deutlich komplexer und sehr abstrakt. Seine Mitglieder waren die einzelnen Stop-Area-Relationen, also eine Relation, die Relationen referenziert hat.

Du schreibst: "Die räumliche Zuordnung zum Gebiet (z.B. Bäckerei im Bahnhof) ist kein Grund zur Aufnahme des Objekts in die Relation." Dem kann ich voll und ganz zustimmen. In Haltestellenrelationen und Gesamthaltestellenrelationen sollten nur Bahnsteige, Haltepositionen, Stationsnode und andere ÖPNV-Kernelemente sein, keine Bäcker, Sitzbänke und Fahrkartenschalter!

(8) Das nenne ich mal Optimismus! Ich habe meine Zweifel, wie lange das gut geht. Wann endet die Übergangszeit? Wie wird man hier reagieren, wenn nach einem Jahr Umstellung ich ankündigen würde, die ersten alten Routen zu löschen, und ein Nutzer sich hier meldet mit dem Argument "Meine Software kann das aber noch nicht.". Warten wir dann noch länger? ÖPNV ist ein schwieriges Thema. Man kann die Abwärtkompatibilität nicht immer ermöglichen. Wer sich auf kostenlose Daten verlässt, muss damit leben, dass er sich dann an die Daten anpassen muss. So ist das halt. OSM bietet auch keine Premium-Extrakte für Navihersteller an.

Zusammenfassung
Eigentlich gibt es nur drei Gründe, weshalb du einen Entwurf für PTv3 geschrieben hast. Du möchtest allen Mitgliedern eine Rolle zuweisen, Schleifen im Fahrweg erfassen und stop_positions nicht mehr in der Route haben. Sorry, dass ich dir deinen zweiten Entwurf für eine Public-Transport-Reform zerede, aber ich frage mich, ob das den Aufwand einer erneuten Umstellung rechtfertigt. Die Schleifen sind das einzige, was ich für wichtig halte und mit dem Proposaltext von PTv2 inkompatibel ist. Alles andere kann man abwärtskompatibel "anflanschen".

Können wir uns darauf einigen, erst einmal die Wochenaufgabe voranzutreiben? Danach werde ich dann mit der light_rail-Frage auf der Tagging-Liste aufkreuzen. Roland hat Recht, eins nach dem anderen.

Viele Grüße

Michael

PS Meinst du mit "einfacher als der letzte" den da? :-)

[1] Doppelbelegung durch mehrere Züge hintereinander
[2] Mehr als 12 bis 14 Wagen haben selbst die längsten Reisezüge nicht.

Das mit den stop_positions hast Du falsch verstanden. Die fallen auch unter "halt". Ein typischer "halt_fixme" wäre der "railway=station"-Node aus dem keiner sehen kann, ob bei der Ankunft ein Aufzug verfügbar ist. Und ich sehe auch überhaupt keinen Grund, z.B. bei zwei einander gegenüberliegenden Bushaltestellen den einen Node auf der Straße um Steige zu ergänzen.

Eigentlich gibt es nur drei Gründe...

Es sind schon noch ein paar mehr. Der optionale Route-Master in PTv2 macht z.B. eine Karte mit Richtungspfeile an der passenden Stelle noch schwieriger als ohnehin schon. Einige Kleinigkeiten -- z.B. was optional ist und was nicht -- erlauben anderen Checks und andere Programme.

Das nenne ich mal Optimismus!

Ich nicht. Es ist Pessimismus, weil ich gesehen habe, was aus dem PTv2 geworden ist und noch mehr aus dem PTv1. Wir haben im Gegensatz zu den ÖPNV-Anbietern keine Karten mit Richtungspfeilen mehr.

bis dann
Weide

---

Der Pessimist sagt: Das Glas ist halb leer.
Der Optimist sagt: Das Glas ist halb voll.
Der Techniker sagt: Man hätte ein halb so großen Glas nehmen können.

Nakaner wrote:

Wenn ich mehrere Bahnsteige an einer Station habe, dann ist im PTv2 die Reihenfolge egal.

Nein. Es geht in PTv2 gar nicht, weil es mehrere Haltestellen wären. Zwei Halte an verschiedenen Steigen einer Haltestelle kommen bei Bussen sogar ziemlich oft vor. Nur das Päärchen stop mit direkt darauf folgendem platform bildet einen Halt. Egal was man danach dran hängt -- es ist ein neuer Halt.

Weide

Nakaner wrote:

(4)In deinem Schema müssen nicht mehr sowohl stop als auch platform in die Routenrelation. Stattdessen kommen nur noch Bahnsteige/Wartebereiche mit der Rolle halt hinein. Wenn eine Station einen mehrteiligen Bahnsteig hat (z.B. ein Teil des Bahnsteigs liegt auf einer Brücke), dann bekommt der zweite/dritte Bahnsteigteil die Rolle +halt. Bahnsteige der Spanischen Lösung bekommen die Rolle halt#. Wenn man die Plattform nicht kennt (z.B. weil Grasbahnsteig im hohen Gras oder von Bäumen verdeckter Bahnsteig), dann fügt man bei PTv2 nur die stop_position ein. Bei dir muss man dann die stop_position einfügen und ihr die Rolle halt_fixme zuweisen.
[...]
Meine Meinung

(4) Mir gefällt das nicht. Derzeit kann der Relationseditor in JOSM (bzw. auch jeder andere Editor könnte es, wenn er es könnte) anhand der Tags des einzufügenden Objekts entscheiden, ob er ihm automatisch die Rolle stop oder platform zuweist. Wenn ich mehrere Bahnsteige an einer Station habe, dann ist im PTv2 die Reihenfolge egal. Mit deinem Schema kann der Editor nicht automatisch eine Rolle vorschlagen. Was die Zerbrechlichkeit angeht, gibt sich das mit PTv2 aber nichts. Wenn ich von einem dreigeteilten Bahnsteig (Damm–Brücke–Damm), den ersten Teil entferne, dann werden mit deinem Schema die beiden übrigen Teile der vorherigen Station zugeordnet. Bei PTv2 muss man hingegen eine stop_position aus der Route entfernen und schon hat man eine Fehlzuordnung. Für mich rechtfertigt das kein neues Schema.

Stattdessen handelst du dir durch den Verzicht auf die stop_positions weitere Probleme ein. Eine stop_position im Straßenway signalisiert dem Pkw-Router, dass da ein Bus anhalten und den Autofahrer zum Halten zwingen könnte (ich kenne noch kein Tag wie bus_passing_place=yes). Im Schienenverkehr (im Busverkehr nur auf Busbahnhöfen mit einer langen Bussteigkante) spielen Haltepositionen eine wichtige Rolle.
Ob meine kurze Regionalbahn in Köln Hbf (Gleis 4/5 486 m) [1], Essen Hbf (Gleis 7, ca. 685 m = ca. 27 Wagen [2]) oder Gößnitz (588 m)) vorn oder hinten am Bahnsteig steht, macht für das Routing beim Umsteigen einen großen Unterschied (1,5 Min./100m bei 4 km/h!). Daher möchte man im Bahnverkehr die Halteposition mit erfassen und in die Route aufnehmen, wenn sie konstant ist bzw. konstant von der selben Routenvariante genutzt wird.

Ich kann deine Auffassung sehr gut verstehen! Aber es ist eben nicht möglich einer Route immer eine eindeutige Halteposition zuzuweisen!
Hier bei der S und Straßenbahn in Berlin verkehren Züge unterschiedlicher Länge auf der gleichen Route. Und allein diese Zuglänge entscheidet wo der Zug halten wird.

Nakaner wrote:

Im Schienenverkehr (im Busverkehr nur auf Busbahnhöfen mit einer langen Bussteigkante) spielen Haltepositionen eine wichtige Rolle.
Ob meine kurze Regionalbahn in Köln Hbf (Gleis 4/5 486 m) [1], Essen Hbf (Gleis 7, ca. 685 m = ca. 27 Wagen [2]) oder Gößnitz (588 m)) vorn oder hinten am Bahnsteig steht, macht für das Routing beim Umsteigen einen großen Unterschied (1,5 Min./100m bei 4 km/h!). Daher möchte man im Bahnverkehr die Halteposition mit erfassen und in die Route aufnehmen, wenn sie konstant ist bzw. konstant von der selben Routenvariante genutzt wird.

Wenn man die Haltepositionen wirklich nutzen wollte, dann bräuchte man aber noch ein Tag "diese_stop_position_ist_ausnahmsweise_ernst_zu_nehmen" :-)

Und wir haben auch noch solche Sachen wie die "Untersteignummern" in Mainz Hbf, jwd-Steige in Essen Hbf, ungenutzte(?) lange Steigteile, die eigentlich nur einen Ausgang anbinden sollen in Duisburg Hbf oder die zentrale Steiginsel vieler Busbahnhöfe, die eigentlich 6 oder 8 Steige haben müsste, aber als ein Steig gemappt wird. Ich hab da mal was eingebaut, was ohne große Änderungen rein ging.

bis dann
Weide

Hallo Weide, hallo viw,

Weide wrote:

Nakaner wrote:

Wenn ich mehrere Bahnsteige an einer Station habe, dann ist im PTv2 die Reihenfolge egal.

Nein. Es geht in PTv2 gar nicht, weil es mehrere Haltestellen wären. Zwei Halte an verschiedenen Steigen einer Haltestelle kommen bei Bussen sogar ziemlich oft vor. Nur das Päärchen stop mit direkt darauf folgendem platform bildet einen Halt. Egal was man danach dran hängt -- es ist ein neuer Halt.

Kannst du das mal bitte mit einem Zitat aus dem Proposal belegen? Der Proposal-Text trifft dazu keine Aussage. Meiner Meinung nach wäre stop1–platform1–stop2–platform2a–platform2b–platform2c–stop3–platform3–… erlaubt und platform2a, platform2b und platform2c würden zu stop2 gehören.

Solltest du doch recht haben, so kann man immer noch in einem PTv2.1 eine Rolle "+platform" einfügen.

viw wrote:

Nakaner wrote:

(4)In deinem Schema müssen nicht mehr sowohl stop als auch platform in die Routenrelation. Stattdessen kommen nur noch Bahnsteige/Wartebereiche mit der Rolle halt hinein. Wenn eine Station einen mehrteiligen Bahnsteig hat (z.B. ein Teil des Bahnsteigs liegt auf einer Brücke), dann bekommt der zweite/dritte Bahnsteigteil die Rolle +halt. Bahnsteige der Spanischen Lösung bekommen die Rolle halt#. Wenn man die Plattform nicht kennt (z.B. weil Grasbahnsteig im hohen Gras oder von Bäumen verdeckter Bahnsteig), dann fügt man bei PTv2 nur die stop_position ein. Bei dir muss man dann die stop_position einfügen und ihr die Rolle halt_fixme zuweisen.
[...]
Meine Meinung

(4) Mir gefällt das nicht. Derzeit kann der Relationseditor in JOSM (bzw. auch jeder andere Editor könnte es, wenn er es könnte) anhand der Tags des einzufügenden Objekts entscheiden, ob er ihm automatisch die Rolle stop oder platform zuweist. Wenn ich mehrere Bahnsteige an einer Station habe, dann ist im PTv2 die Reihenfolge egal. Mit deinem Schema kann der Editor nicht automatisch eine Rolle vorschlagen. Was die Zerbrechlichkeit angeht, gibt sich das mit PTv2 aber nichts. Wenn ich von einem dreigeteilten Bahnsteig (Damm–Brücke–Damm), den ersten Teil entferne, dann werden mit deinem Schema die beiden übrigen Teile der vorherigen Station zugeordnet. Bei PTv2 muss man hingegen eine stop_position aus der Route entfernen und schon hat man eine Fehlzuordnung. Für mich rechtfertigt das kein neues Schema.

Stattdessen handelst du dir durch den Verzicht auf die stop_positions weitere Probleme ein. Eine stop_position im Straßenway signalisiert dem Pkw-Router, dass da ein Bus anhalten und den Autofahrer zum Halten zwingen könnte (ich kenne noch kein Tag wie bus_passing_place=yes). Im Schienenverkehr (im Busverkehr nur auf Busbahnhöfen mit einer langen Bussteigkante) spielen Haltepositionen eine wichtige Rolle.
Ob meine kurze Regionalbahn in Köln Hbf (Gleis 4/5 486 m) [1], Essen Hbf (Gleis 7, ca. 685 m = ca. 27 Wagen [2]) oder Gößnitz (588 m)) vorn oder hinten am Bahnsteig steht, macht für das Routing beim Umsteigen einen großen Unterschied (1,5 Min./100m bei 4 km/h!). Daher möchte man im Bahnverkehr die Halteposition mit erfassen und in die Route aufnehmen, wenn sie konstant ist bzw. konstant von der selben Routenvariante genutzt wird.

Ich kann deine Auffassung sehr gut verstehen! Aber es ist eben nicht möglich einer Route immer eine eindeutige Halteposition zuzuweisen!
Hier bei der S und Straßenbahn in Berlin verkehren Züge unterschiedlicher Länge auf der gleichen Route. Und allein diese Zuglänge entscheidet wo der Zug halten wird.

Wir sind uns aber einig, dass unterschiedliche Zuglängen zu unterschiedlichen Tageszeiten keine Duplikation von Routen rechtfertigen, oder? Die Haltepositionen von Schnellbahnen orientieren sich oft an den Bahnsteigzugängen. Wenn der Bahnsteigzugang hinten ist, wird mit Haltetafeln (bei EBO-Bahnen das Signal Ne5 [1]) gekennzeichnet, wo die Züge welcher Länge halten sollen. Nur Züge voller Länge (in Berlin 4/4-Züge) halten auf der ganzen Länge.

Da ist Intelligenz vom Auswerter und Fahrgast (Nutzer) gefragt, sodass er erkennt: "Ah! Langer Zug, da muss ich für's schnelle Umsteigen am nächsten Bahnhof hinten einsteigen."

Weide wrote:

Und wir haben auch noch solche Sachen wie die "Untersteignummern" in Mainz Hbf, jwd-Steige in Essen Hbf, ungenutzte(?) lange Steigteile, die eigentlich nur einen Ausgang anbinden sollen in Duisburg Hbf oder die zentrale Steiginsel vieler Busbahnhöfe, die eigentlich 6 oder 8 Steige haben müsste, aber als ein Steig gemappt wird. Ich hab da mal was eingebaut, was ohne große Änderungen rein ging.

Hast du dir mal das Mapping der Bahnsteige in Euskirchen angeschaut? Diese Konzept wäre mein Vorschlag. Bahnsteige mit Unternummern (eigentlich auch Bahnsteige mit mehr als einer Kante, d.h. die meisten Inselbahnsteige [2]) sind Multipolygone. Alle Tags außer die Gleisnummer hängen am Multipolygon. Das Multipolygon hat mehrere outer-Ways (Rolle outer) – die Bahnsteigkanten und die "kurzen Seiten", an denen keine Züge halten. Die Bahnsteigkanten-Ways erhalten ref=<Gleisnummer>. Bahnsteigabschnitte (A, B, C,), wie es sie in Deutschland, der Schweiz und anderen Ländern gibt, können als Node auf die Kante gemappt werden, wenn nur die Position des Schilds [3], aber nicht dessen Gültigkeit genau bekannt ist. Diese Konzept ist auf dem Mappingwochenende in Köln im Juli entstanden.

Viele Grüße

Michael

[1] https://github.com/Nakaner/railway-sign … _DS301.svg und https://github.com/Nakaner/railway-sign … _DV301.svg
[2] Manche Inselbahnsteige haben nur eine Kante, z.B. Möckmühl Gleis 2 und 3.
[3] Die Schilder werden häufig dort montiert, wo es gerade geschickt ist, z.B. an Trägern der Bahnsteigüberdachung. Daher ist ihre Lage nicht die genaue Mitte des Abschnitts.

viw wrote:

Hier bei der S und Straßenbahn in Berlin verkehren Züge unterschiedlicher Länge auf der gleichen Route. Und allein diese Zuglänge entscheidet wo der Zug halten wird.

Wie willst du das bei Bahnsteigen ohne H-Tafel machen? In Dortmund-Hörde hält die Eurobahn, wo sie will. Mal zu weit vorne, mal zu weit hinten und bei Doppeltraktion gaaanz weit hinten.

Nakaner wrote:

Hallo Weide, hallo viw,
Wir sind uns aber einig, dass unterschiedliche Zuglängen zu unterschiedlichen Tageszeiten keine Duplikation von Routen rechtfertigen, oder? Die Haltepositionen von Schnellbahnen orientieren sich oft an den Bahnsteigzugängen. Wenn der Bahnsteigzugang hinten ist, wird mit Haltetafeln (bei EBO-Bahnen das Signal Ne5 [1]) gekennzeichnet, wo die Züge welcher Länge halten sollen. Nur Züge voller Länge (in Berlin 4/4-Züge) halten auf der ganzen Länge.

Da ist Intelligenz vom Auswerter und Fahrgast (Nutzer) gefragt, sodass er erkennt: "Ah! Langer Zug, da muss ich für's schnelle Umsteigen am nächsten Bahnhof hinten einsteigen."

Ähm genau das habe ich jetzt aus deinem Vorschlag nicht so richtig entnehmen können. Welchen Vorteil hat die Stopposition, wenn Sie doch nicht genau bestimmt werden kann? Du hast recht das es für die Umsteigewege von Vorteil ist hinten oder vorne einsteigen zu können, aber wo ist denn jetzt bei einen 2/4 Zug vorne und noch schlimmer wo ist denn hinten?

Nakaner wrote:

Kannst du das mal bitte mit einem Zitat aus dem Proposal belegen?

Each stop is included with two elements (if available): first the stop_position tagged with role stop and immediately followed by the corresponding platform tagged with role platform.

bis dann
Weide

Weide wrote:

Each stop is included with two elements (if available): first the stop_position tagged with role stop and immediately followed by the corresponding platform tagged with role platform.

Ok, danke. Du hast deine Aussage belegt.

Nakaner wrote:

Hast du dir mal das Mapping der Bahnsteige in Euskirchen angeschaut?

Äh, ja, gefällt mir nicht. Wenn die Routen auf die outer-Stücke zeigen, dann zeigen sie nicht auf platforms und das sollte Fehlermeldungen triggern. Man sollte auch den Namen eintragen können und wenn der mal dargestellt wird, dann sollte er auch im Stil von Platforms dargestellt werden. Taggt man sowohl die Stücke als auch das MP als platform, dann sind zuviele Platforms in dem Bahnhof. Da würde ich schon eher die Bahnsteigfläche als highway=pedestrian machen (wo möglich ohne MP) und an den passenden Stücken über dieselben Nodes oder etwas nach innen versetzt die Platforms als Linien. Das wäre auch auf die Bahnsteiginseln der Busse anwendbar, die gewöhnlich keine MPs sind.

bis dann
Weide

PS: area=yes an den MPs ist falsch (steht so im PTv2, aber PTv2 zählt da nicht)
PPS: Es sollten zwei stop_areas sein, da die Namen verschieden sind.

Es wird sich aber allermeist eine Stelle am Bahnsteig finden lassen wo sich garantiert ein Zug befindet, oder? So Regel: "der Mittelpunkt der kürzesten Zugvariante"?

Hallo Weide,

Weide wrote:

Nakaner wrote:

Hast du dir mal das Mapping der Bahnsteige in Euskirchen angeschaut?

Äh, ja, gefällt mir nicht. Wenn die Routen auf die outer-Stücke zeigen, dann zeigen sie nicht auf platforms und das sollte Fehlermeldungen triggern.

Ja, klar. In so einem Fall sollten die platform-Member-Einträge in den Routenrelationen auf das Multipolygon zeigen. In Euskirchen ist kein Bahnsteig Teil einer Routenrelation. (habe gerade eben extra nachgeschaut)

Weide wrote:

Man sollte auch den Namen eintragen können und wenn der mal dargestellt wird, dann sollte er auch im Stil von Platforms dargestellt werden.

Du meinst also, dass man den Bahnhofsnamen an das Bahnsteig-Multipolygon taggen können sollte? Das ist doch möglich. Das wird dir im JOSM-Routeneditor dann als "Multipolygon (Euskirchen)" angezeigt.

Das Taggen von Gleisnummern an die Bahnsteigkante ist auch kein Problem für Renderer, die die Gleisnummer mitten in der Bahnsteigfläche rendern wollen. Die müssen einfach nur schauen, welche Gleisnummern auf die Mitglieder des Multipolygons getaggt sind (ref=* [1]) und diese sortieren und zu einem Label-String verketten.

Weide wrote:

Taggt man sowohl die Stücke als auch das MP als platform, dann sind zuviele Platforms in dem Bahnhof.

Ja, genauso wie ich bei einem Wald-Multipolygon mit zwei Outer-Mitgliedern (jeweils nicht geschlossene Ways, die zusammen einen Ring ergeben) nicht die beiden Ways zusätzlich zum Multipolygon mit landuse=forest tagge.

Weide wrote:

Da würde ich schon eher die Bahnsteigfläche als highway=pedestrian machen (wo möglich ohne MP) und an den passenden Stücken über dieselben Nodes oder etwas nach innen versetzt die Platforms als Linien. Das wäre auch auf die Bahnsteiginseln der Busse anwendbar, die gewöhnlich keine MPs sind..

Ich bin keine Freund von highway=pedestrian auf Eisenbahnsteigen. Bei der DB sind wir es gewohnt, dass man Bahnsteige einfach so betreten kann. In anderen Ländern gibt es jedoch Bahnsteigsperren (AFAIK gibt es im Hamburger Verkehrsverbund sogar noch "Bahnsteigkarten"). highway=pedestrian sollte von einem Mappingschema nur vorsichtig empfohlen werden, da es von Routern gegenüber railway/public_transport=platform bevorzugt wird.

Das Taggen der Gleisnummer an die Bahnsteigkante erleichtert das Blindenrouting in Bahnhöfen. In den Fahrplandaten ist vermerkt, auf welchem Gleis der Zug hält. Bei einem Inselbahnsteig gibt es jedoch meistens zwei Bahnsteigkanten. In welche Richtung soll nun der Blinde gehen, wenn der den Treppenaufgang hochkommt? Mit Gleisnummern auf der Bahnsteigkante kann das Smartphone sagen: "Benutzen Sie den Aufzug zur Gleisebene hoch und halten Sie sich dann nach links." Außerdem erleichtert es die Kartenanzeige eines Indoor-Routingergebnisses für sehende Nutzer.

Weide wrote:

PS: area=yes an den MPs ist falsch (steht so im PTv2, aber PTv2 zählt da nicht)

area=yes ist entweder Mapping for the Renderer oder Mapping for Osm2pgsql. Ich habe beobachtet, dass Multipolygonbahnsteige ohne area=yes als Linie statt als Fläche gerendert werden. Du hast aber trotzdem recht.

Viele Grüße

Michael

[1] local_ref=* wäre vielleicht besser, da ref=* durch eine netzweit einheitliche Bahnsteigkanten-ID belegt sein könnte.

Schade das Segmente nicht in dieser Version aufgenommen werden. Muss ich noch mal etwa 10 Jahre warten um das reifen zu lassen, oder doch einmal selber ein Vorschlag machen.

Ich habe Begriff dafür das Relationen in Relationen einige zusätzliche Komplexität bringen, andererseits würde es die Wartung ungeheuer viel vereinfachen. Ich habe versucht eine MapCSS zu erstellen die mit Segmente arbeiten kann, aber ich kann keine tags von Grosseltern betrachten.

Nah gut. Ich bin damit beschäftigt ein Skript zu bauen das v2 Routerelationen erfassen kann:

https://github.com/PolyglotOpenstreetma … 06ab4d581f

Es benutzt der scripting-plugin und Jython. Es läuft im JOSM.

Ich weiss nicht ob ihr in Deutschland angriff habt auf der Daten des Operators?

Das Skript fängt an mit eine geordnete Reihenfolge von Haltestellen. Es geht davon aus das alle Haltestellen auf Nodes gemappt sind. Ist das noch so in ihren Vorschlag?

• Es versucht zuerst eine Relation zu finden die eine gleiche Reihenfolge von HS hat. Wenn es die findet, benutzt es die Ways von der mit der längste Reihenfolge.
  

Das skript geht auch davon aus das alle Ways zusammen stehen, und alle HS auch. Das ist wie JOSM solche Routerelationen automatisch sortiert, deswegen schien mir das eine gute Konvention. Irgendwie wäre es natürlich einfacher HS mit ways zu verknupfen wenn die HS dazwischen stehen. Dan kann man aber nicht mehr visuell nachschauen ob die Ways eine ununterbrochen Sequenz sind.

• Wenn keine vergleichbare Route gefunden werd, dann versucht es mit dem letzten Way die nächste HS zu bereichen anhand irgendeine andere v2 Route. Die Büsse haben jedenfalls tendenz alle dieselbe "Korridors" zu benutzen.
  

• Wenn das nichts aufbringt, noch mal neu von alle Seitstrassen.
  

• Als letzte Lösung wird versucht einen gültigen Way zu finden neben die HS. Entweder mit Hilfe von Stop_area Relation, oder der näheste stop_position. So war ich etwa 2 Jahre her angefangen und es hilf, nur ist es sehr langweilig alle Variante so hinzuzufügen.
  

Das andere Problem ist natürlich die Wartung. Diese Variationen von Routen änderen sich ziemlich oft und die Relationen werden von andere benutzer ständig kaputtgemacht. Auch dafur (ver)suche ich eine halbautomatisierte oder so weit wie möglich automatisierte Lösung (zu entwickeln).

Könnt ihr mich befestigen ob meinen Ahnnahmen stimmen?

• HS nur auf Nodes
  
• Alle Wege zusammen im Route. Wenn der bus zwei mal über demselben Weg fährt, kommt er 2x vor im Relation
  
• Dann eine sortierte Reihenfolge des HSs? Wenn der bus zwei mal an dieselbe HS vorbeifährt, kommt sie 2x vor im Relation
  

Polyglot

Nakaner wrote:

Ja, klar. In so einem Fall sollten die platform-Member-Einträge in den Routenrelationen auf das Multipolygon zeigen. In Euskirchen ist kein Bahnsteig Teil einer Routenrelation. (habe gerade eben extra nachgeschaut)

Dann hab ich das total missverstanden. Ich dachte, die Routen sollen auf die Teile zeigen.

Die müssen einfach nur schauen, welche Gleisnummern auf die Mitglieder des Multipolygons getaggt sind

Da bin ich Fundamentalist. MPs sollten nichts mit dem Inhalt ihrer Member zu tun haben. Nur die Geometrie der Linien zählt. Irgendwann beim nächsten API müssen wir die MPs automatisch durch Flächenobjekte ersetzen und das beisst sich damit.

Polyglot wrote:

Schade das Segmente nicht in dieser Version aufgenommen werden. Muss ich noch mal etwa 10 Jahre warten um das reifen zu lassen, oder doch einmal selber ein Vorschlag machen.

Technisch ist es sehr einfach: Man definiert einen Segmentrelationstyp ohne eigene Eigenschaften und eine "include_halts"- und eine "include_tour"-Rolle innerhalb der p3=variant - Relationen.

Jojo4u wrote:

Es wird sich aber allermeist eine Stelle am Bahnsteig finden lassen wo sich garantiert ein Zug befindet, oder? So Regel: "der Mittelpunkt der kürzesten Zugvariante"?

Ähm ja es gibt eine Stelle Am Bahnsteig wo garantiert ein Wagen eines S-Bahnzuges halten wird. Aber das ist eben nicht die zwangsläufig die Mitte. Und bei Straßenbahnen ist es ohnehin sehr fraglich. Dort gibt es das Phänomen der Doppelhaltestellen.

Weide wrote:

Polyglot wrote:

Schade das Segmente nicht in dieser Version aufgenommen werden. Muss ich noch mal etwa 10 Jahre warten um das reifen zu lassen, oder doch einmal selber ein Vorschlag machen.

Technisch ist es sehr einfach: Man definiert einen Segmentrelationstyp ohne eigene Eigenschaften und eine "include_halts"- und eine "include_tour"-Rolle innerhalb der p3=variant - Relationen.

Ich weiss, nur wenn die Möglichkeit nicht im Vorschlag aufgenommen wird, wird überhaupt keiner Datennutzer das auch benutzen/auf der Karte darstellen. Mit dem Skript das ich jetzt entwickle wird die Wartung schon etwas niedriger. Nicht mit Routesegmente arbeiten hat das Vorteil dass man sofort visuell beobachten kann, ob die Linie nicht unterbrochen würde. Das kann ich aber viel schneller automatisiert entscheiden.

• Segmente könnten aber (langweiliger) Mapperarbeit sparen
  
• Es wäre auch möglich um Spiderdiagramme ab zu bilden, wenn auf die Segmente einige zusätzliche tags gesetzt werden wie route_ref und colour. Sogar in JOSM mit MapCSS. Das ist etwas das wir bis jetzt noch nicht machen konnten.
  

Ist es bitte möglich erst die ways und danach die HS in Routerelationen auf zu nehmen? Das ist wie JOSM die sortieren würde. (Oder die JOSM-entwickler davon überzeugen es umgekehrt zu tun.) Ich mag es aber das ich sofort aur die Ways arbeiten kann. Die HS werden hier automatisiert hinzugefügt.

Polyglot wrote:

Ist es bitte möglich erst die ways und danach die HS in Routerelationen auf zu nehmen? Das ist wie JOSM die sortieren würde.

Es ist doch gut wenn man sehen kann, dass jemand die Relation kaputt gemacht hat. Die JOSM-Sortierung auf die Haltestellen anzuwenden ist immer Quatsch. Bei den Wegen funktioniert es nur bei einfachen Routen. Und ich kenne viele Routen bei denen es richtig viel Arbeit ist, sie nach einer automatischen Sortierung wieder zu berichtigen.

Oder die JOSM-entwickler davon überzeugen es umgekehrt zu tun.

Ich würde die JOSM-Leute eher fragen, ob man die Sortierung nicht abschalten kann, wenn Haltestellen mit sortiert würden und ob sie nicht die Sortierung total verweigern könnten, wenn es keine eindeutige Lösung gibt.

Weide

Ich benutze die Sortierung innerhalb Relation Editor nicht mehr für eine ganze Route. Für Teile ist sie aber wohl praktisch. Also Klik, Shift-Klik etwas weiter, dann sortieren. Die HS werden normalerweise nicht berurt. Die Reihenfolge sollte gleich bleiben. Üblicherweise selektiere ich aber nur Ways.

Mein Skript fügt Sequenznummer ein für Ways die es hinzufügt. Das macht es auch etwas einfacher.

Vielleicht möchtest du es mal ausprobieren. Hast du irgendwo eine Route von welche alle HS auf Nodes gemappt sind?

https://github.com/PolyglotOpenstreetma … omStops.jy

Wenn du Lust hast, will ich es auch mal demonstrieren in eine Google Hangout. Es fängt an recht praktisch zu funktionieren... Findet Ways in andere Routen wenn die schon auf Version 2 stehen und ihre Wege nicht unterbrochen sind. Wenn keine andere Routen vorhanden sind, fügt es nur die anliegende Ways zu. Wenigstens hat man dann schon diese Ways in richtige Reihenfolge und versehen von Sequenznummer. Wenn man damit anfängt, muss man dan diese Ways noch verbinden, aber einmal eine Gegend gute Referenzrouten hat, kann das Skript stehts mehr selber zusammenstellen.

Jo

Mal deine letzte changeset angeguckt:

https://www.openstreetmap.org/changeset … 864/6.3710

Jetzt verstehe ich wieso es kein Reaktion kommt auf meinem Skript. Ihr mappt PT grundsätzlich anders als wir/ich. Ich habe es in Belgien alles konsistent auf ein System umgewandelt. (In Brüssel bin ich noch nicht ganz fertig) Ein System das aber wohl funkzioniert. Wenn ich mir das so ansehe, seit ihr noch halbwegs zwischen PT v2 und PT v1. Ich habe natürlich nur ein Beispiel gesehen. Hast du vielleicht irgendwo bessere Beispiele? Damit meine ich, die HS neben der Weg gemappt, am liebsten auf Nodes.

Hier in Belgien sind wir so angefangen, weil jede HS ein Referenznummer hat, das auf die Schilder angedeutet steht (wenigstens in Flandern). Deswegen hat es für uns nie Sinn gemacht HS als Node auf dem Weg zu mappen. Und deswegen sind alle Details auch auf diesen Nodes neben dem Weg.

Vielleicht müsste ich mal in England gucken gehen. Sehen wie die es machen.

Grüsse,

Jo

Polyglot wrote:

Wenn ich mir das so ansehe, seit ihr noch halbwegs zwischen PT v2 und PT v1.

-)␣So␣schlecht␣liegen␣wir␣garnicht␣im␣Rennen.␣Mein␣Programm␣liefert␣jetzt␣für␣den␣Regierungsbezirk␣Düsseldorf␣in␣Nordrhein-Westfalen␣noch␣6408␣Fehlermeldungen␣und␣für␣Belgien␣16231␣:-)␣Aber␣Belgien␣ist␣ja␣auch␣deutlich␣größer.␣:-)

bis dann
Weide

Edit: falsche Zahl korrigiert

Kann ich die Fehlermeldungen irgendwo mal sehen? Oder das Programm?

Ich komm mal in Düsseldorf schauen, wenn ich fertig bin mit dem korrigieren von Linien 1-9 in Brugge.

Jo

Polyglot wrote:

Kann ich die Fehlermeldungen irgendwo mal sehen? Oder das Programm?

Wenn Du mir eine Nachricht schickst, dann kann ich per E-Mail-Antwort mit Attachment die Liste schicken. Das Programm kannst Du auch haben; ich habe aber nur Executables für Linux (x86-64). Für die Quellen bräuchte man einen Ada-Compiler.

bis dann
Wilhelm

Ich habe mal dokumentiert wie wir das hier in Belgien mappen, basiert auf dem Artikel im Wochenaufgabe:

http://osm.be/nl/content/mapping-public … t-belgium#

Hallo Polyglot,

Polyglot wrote:

Ich habe mal dokumentiert wie wir das hier in Belgien mappen, basiert auf dem Artikel im Wochenaufgabe:

http://osm.be/nl/content/mapping-public … t-belgium#

Was das Tagging der Routen betrifft, finde ich bloß zwei Unterschiede. Ihr habt die Haltestellen am Ende der Relation eingereiht, wir am Anfang. Bei euch gibt es keine stop_positions (mit der Rolle stop) in der Route, bei uns schon.

Sehe ich es richtig, dass ihr keine stop_positions mappt?

Kennst du schon das Tag fee_zone=*? Im Gebiet des Verkehrs- und Tarifverbunds Stuttgart (VVS) wird mit diesem Tag (an Bahnhof-Nodes, Haltepositionen, Bushaltestellen, stop_area-Relationen) die Tarifzone(n)/Tarifwabe(n), in denen die Station liegt angegeben. Es scheint das Stuttgarter Äquivalent zu zone:De_Lijn=85 zu sein, oder?

Im Karlsruher Verkehrsverbund (KVV) wird das Verbundsgebiet als (Multi-)Polygon erfasst:
abbreviation=KVV
boundary=public_transport
name=Karlsruher Verkehrsverbund
type=boundary
wikidata=Q1733986
https://www.openstreetmap.org/relation/3157173/history

Viele Grüße

Michael

Polyglot wrote:

Ich habe mal dokumentiert wie wir das hier in Belgien mappen...

Das ist kein PTv2. Es wäre gut, wenn ihr es irgendwie markieren könntet.

Weide

Weide wrote:

Polyglot wrote:

Ich habe mal dokumentiert wie wir das hier in Belgien mappen...

Das ist kein PTv2. Es wäre gut, wenn ihr es irgendwie markieren könntet.

Weide

Ich möchte gerne wissen was nicht v2 dran ist. Eine Routerelation pro Variante, check, Platforme sind gemapt mit public_transport=platform/bus=yes. check. Der Validator von JOSM ist froh damit. Und ich kann die alle verwalten mit ein Pythonprogramm, weil es ausreichend konsistent ist für automatische Verwaltung.

Jo

Nakaner wrote:

Hallo Polyglot,

Polyglot wrote:

Ich habe mal dokumentiert wie wir das hier in Belgien mappen, basiert auf dem Artikel im Wochenaufgabe:

http://osm.be/nl/content/mapping-public … t-belgium#

Was das Tagging der Routen betrifft, finde ich bloß zwei Unterschiede. Ihr habt die Haltestellen am Ende der Relation eingereiht, wir am Anfang. Bei euch gibt es keine stop_positions (mit der Rolle stop) in der Route, bei uns schon.

Sehe ich es richtig, dass ihr keine stop_positions mappt?

Kennst du schon das Tag fee_zone=*? Im Gebiet des Verkehrs- und Tarifverbunds Stuttgart (VVS) wird mit diesem Tag (an Bahnhof-Nodes, Haltepositionen, Bushaltestellen, stop_area-Relationen) die Tarifzone(n)/Tarifwabe(n), in denen die Station liegt angegeben. Es scheint das Stuttgarter Äquivalent zu zone:De_Lijn=85 zu sein, oder?

Im Karlsruher Verkehrsverbund (KVV) wird das Verbundsgebiet als (Multi-)Polygon erfasst:
abbreviation=KVV
boundary=public_transport
name=Karlsruher Verkehrsverbund
type=boundary
wikidata=Q1733986
https://www.openstreetmap.org/relation/3157173/history

Viele Grüße

Michael

Es werden sicher auch stop_position gemappt. Das wichtigste sind aber die highway=bus_stop/public_transport=platform/bus=yes. Die sind jetzt alle da.

Wenn public_transport=stop_area gemacht werden, werden auch die stop_position erfasst. Wenn etwas anderes am highway gemappt werden muss, werden die auch gemappt. In die Routerelationen sind die aber nicht notwendig. Sie machen es nur schwieriger und als die jedenfalls nicht alle da sind...

Als es eine stop_area pro highway=bus_stop/public_transport=platform/bus=yes gibt, ist es einfach zu ermitteln welche stop_position(en) dazu gehört/en.

Grüsse,

Jo

Polyglot wrote:

Ich möchte gerne wissen was nicht v2 dran ist.

Each route relation has all the stops at the end.

Ist im direkten Gegensatz zu dem im PTv2 angegebenen.

To keep the number of variants limited we only have a variant for the longest...

Nach PTv2 sollen alle Varianten gemappt werden.

Stop-Areas sind völlig anders. Die im PTv2 haben mehr Ähnlichkeit mit Euern stop_area_groups, nur ohne die zweite Relationsebene dazwischen.

To keep things simple and manageable all bus and tram stops in Belgium are mapped on nodes.

In case a platform is present, this can be entered as a way or an area.

Dann sind die Platforms doppelt vorhanden.

These nodes don't get extra information like name...
Dann kann man sie nicht in die Routen stecken, was ausdrücklich von PTv2 gefordert wird. Würde man sie dann doch dort erfassen, dann hätten sie daher einen anderen Namen und wären getrennte Haltestellen. Die Haltestellenliste wäre dann falsch.

Es wird auf die Beschreibung des Bus- und Tram-Linien-Mappings für Belgien verwiesen. Dort steht:
Stops don't need roles.

Das ist ein direktes Verbot der Aufnahme von Way-Platforms. Die könnte man dann nicht mehr von Fahrwegen unterscheiden.

Weide

Weide wrote:

Polyglot wrote:

Ich möchte gerne wissen was nicht v2 dran ist.

Each route relation has all the stops at the end.

Ist im direkten Gegensatz zu dem im PTv2 angegebenen.

To keep the number of variants limited we only have a variant for the longest...

Nach PTv2 sollen alle Varianten gemappt werden.

Stop-Areas sind völlig anders. Die im PTv2 haben mehr Ähnlichkeit mit Euern stop_area_groups, nur ohne die zweite Relationsebene dazwischen.

To keep things simple and manageable all bus and tram stops in Belgium are mapped on nodes.

In case a platform is present, this can be entered as a way or an area.

Dann sind die Platforms doppelt vorhanden.

These nodes don't get extra information like name...
Dann kann man sie nicht in die Routen stecken, was ausdrücklich von PTv2 gefordert wird. Würde man sie dann doch dort erfassen, dann hätten sie daher einen anderen Namen und wären getrennte Haltestellen. Die Haltestellenliste wäre dann falsch.

Es wird auf die Beschreibung des Bus- und Tram-Linien-Mappings für Belgien verwiesen. Dort steht:
Stops don't need roles.

Das ist ein direktes Verbot der Aufnahme von Way-Platforms. Die könnte man dann nicht mehr von Fahrwegen unterscheiden.

Weide

Bin mal auf wiki gucken gegangen, sogar die Historie angesehen und es steht da tatsächlich. Erst Stops, dann Ways. Damals habe ich das nicht gesehen. Schade es gefällt mir wie wir es jetzt machen. Die Haltestellen werden automatisch erfasst. Die Ways manuell, es ist praktisch die erst zu haben.

Was alle Varianten angeht. Ich bin ein Minimalist der auch den Aufwand für die Wartung zu ein minimum zurückbringen will. Deswegen diese Entscheidung. Es gibt etwa 1000 Linien für das Norten des Landes alleine. 2-50 Variante für jede Linie (wie ich die zähle). Es gibt nicht soviele Leute die sich mit ÖPNV beschäftigen wollen, also jede gesparte Aufwand ist eine gute Sache.

Was die stop_area Relation angeht war ich sehr froh mit ihrem Vorschlag für v3. Wir machen es schon so.

Ich habe die andere Seite nicht mehr nachgelesen. HS bekommen jetzt alle die Rolle platform, weil alle umgewandelt sind auf highway=bus_stop,public_transport=platform, bus/tram=yes.

Vielleicht wäre es besser wenn die Nodes die jetzt public_transport=platform bekommen, public_transport=pole bekommen würden, wenigstens wäre das deutlicher. Mir macht es kein Unterschied dass zwei mal platform vorhanden sind. Wenn gemappt auf way, area oder MP ist das ein Steig. Wenn gemappt auf ein Node ist das der Node der alle Details enthalt für diese HS.

Welche Version sollte ich drauf kleben? 1.5, 2.5, 3.5, BE3.14? Ich benutze jetzt 2. Mein Skript considers alle Routes mit Version über 2 wo die Ways nicht unterbrochen sind als golden, und kopiert Wege davon wenn die Reihenfolge des HS übereinstimmt. Ich habe endlich eine Hilfe um die Wartung zu ermöchlichen.

Jetzt werde ich mal eine Relation in Aachen 'verbessern'. Auch dort sind die Ways erst, dann die HS, und ich hatte die noch nicht vorher bearbeitet.

Manche HS waren neben der Weg gemappt, andere als Node auf dem Weg im Route 21. Es wird noch nicht einfach sein diese 2 Schemata zu einigen für Routes die über die Grenze gehen.

Polyglot wrote:

Bin mal auf wiki gucken gegangen, sogar die Historie angesehen und es steht da tatsächlich. Erst Stops, dann Ways. Damals habe ich das nicht gesehen. Schade es gefällt mir wie wir es jetzt machen. Die Haltestellen werden automatisch erfasst. Die Ways manuell, es ist praktisch die erst zu haben.

Ja, es wäre genauso gut gewesen, wenn es im PTv2 anders herum gestanden hätte. Aber jetzt ist es so und das hat Folgen.

Jetzt darf z.B. ein Programm zum Extrahieren der Haltestellen den Rest der Relation überspringen wenn der erste Fahrweg-Eintrag kommt. Das zu tun ist sogar sinnvoll, denn in PBF-Dateien ist das Überspringen sehr zeitsparend. Viele Programme bei OSM laufen täglich und da ist es ein riesiger Unterschied, oft sie 2 Stunden oder 20 Stunden brauchen.

Es kann auch Edit-Wars geben, weil verschiedene Mapper sich auf verschiedene Quellen berufen.

Was alle Varianten angeht. Ich bin ein Minimalist der auch den Aufwand für die Wartung zu ein minimum zurückbringen will. Deswegen diese Entscheidung.

Wenn ein Mapper entscheidet, dass er abgekürzte Varianten nicht eintragen will, dann ist das völlig OK. Auch wenn viele Mapper das tun, ist es völlig OK.

Ein Problem ist es aber, das zu verbieten. Nach PTv2 darf und soll man es. Wenn ein Mapper sieht, dass eine Variante fehlt und sie einträgt (richtig nach PTv2) und ein anderer löscht sie, weil es so in dem Papier steht, dann haben wir einen Edit-War. Und da muss man klar sagen: solange PTv2 dran steht ist das Eintragen des ersten Mappers richtig und das Löschen durch den zweiten falsch.

Was die stop_area Relation angeht war ich sehr froh mit ihrem Vorschlag für v3. Wir machen es schon so.

Nein. Beispiel: Ein Bahnhof "Pusemuckel" hat 4 Bahnsteige (1 bis 4). Auf der einen Seite ist ein Busbahnhof "Pusemuckel Bahnhof" mit 8 Bussteigen (1 bis 8). Auf der anderen Seite ist ein Busbahnhof "Pusemuckel Bahnhof/Westseite" mit 3 Bussteigen (1 bis 3).

-Nach PTv2BE sind es 15 Stop-Areas und ? stop_area_groups.
-Nach PTv2 sind es 3 Stop_Areas.
-Nach meinem Vorschlag sind es drei Stop-Areas und eine Stop_Area-Group.

Mir macht es kein Unterschied dass zwei mal platform vorhanden sind.

Wenn eine zweite Platform da ist, dann darf ein Mapper sie auch in einer Route benutzen. (Er darf nicht beide Platforms benutzen, das wären dann zwei Halte und falsch.) Jetzt kann man aber an der einzelnen Platform eventuell nicht mehr alle Routen erkennen, weil einige auf der anderen Platform liegen.

Man kann nicht vorhersehen wie die Datenbank benutzt wird. Deshalb sollten die Sachen stimmen -- egal ob man einem ein Problem mit falschen Einträgen einfällt oder nicht.

Weide

Weide wrote:

Polyglot wrote:

Bin mal auf wiki gucken gegangen, sogar die Historie angesehen und es steht da tatsächlich. Erst Stops, dann Ways. Damals habe ich das nicht gesehen. Schade es gefällt mir wie wir es jetzt machen. Die Haltestellen werden automatisch erfasst. Die Ways manuell, es ist praktisch die erst zu haben.

Ja, es wäre genauso gut gewesen, wenn es im PTv2 anders herum gestanden hätte. Aber jetzt ist es so und das hat Folgen.

Jetzt darf z.B. ein Programm zum Extrahieren der Haltestellen den Rest der Relation überspringen wenn der erste Fahrweg-Eintrag kommt. Das zu tun ist sogar sinnvoll, denn in PBF-Dateien ist das Überspringen sehr zeitsparend. Viele Programme bei OSM laufen täglich und da ist es ein riesiger Unterschied, oft sie 2 Stunden oder 20 Stunden brauchen.

M.E. ist das meist wichtige dass es bequem ist für Mapper um die zu überarbeiten. Es gibt nicht viele Mapper die sich am PT interessieren, für die Wenige die es gibt muss es so angenähm wie möglich sein. Ein Komputerprogramma würde ich nie so schreiben dass es aufhört mit dem Processing in der Mitte von eine Relation. Es gibt immer die Möglichkeit das ein iD-Benutzer eine HS am Ende hinzugefügt hat, meistens ohne es sich zu realisieren. Die Optimalisazion für Programme sollte darin bestehen die Datenmenge so klein wie möglich zu halten. Das machen wir aber sowieso nicht mit unsere lange Tagnamen und vielfalt duplizierte Daten.

Weide wrote:

Es kann auch Edit-Wars geben, weil verschiedene Mapper sich auf verschiedene Quellen berufen.

Da hast du Recht. Das ist ein Problem. Wäre es möglich um die Reihenfolge für v3 um zu drehen? Oder ist sowas ausgeschlossen?

Was alle Varianten angeht. Ich bin ein Minimalist der auch den Aufwand für die Wartung zu ein minimum zurückbringen will. Deswegen diese Entscheidung.

Weide wrote:

Wenn ein Mapper entscheidet, dass er abgekürzte Varianten nicht eintragen will, dann ist das völlig OK. Auch wenn viele Mapper das tun, ist es völlig OK.

Ein Problem ist es aber, das zu verbieten. Nach PTv2 darf und soll man es. Wenn ein Mapper sieht, dass eine Variante fehlt und sie einträgt (richtig nach PTv2) und ein anderer löscht sie, weil es so in dem Papier steht, dann haben wir einen Edit-War. Und da muss man klar sagen: solange PTv2 dran steht ist das Eintragen des ersten Mappers richtig und das Löschen durch den zweiten falsch.

Verboten habe ich es ja nicht. Das Skript das die Daten umwandelt, stellt die kurzere Variante von "Teleskoplinien" aber nicht zur Verfügung. Dieses Skript spart Mapper soviel Zeit (weil es nicht mehr notwendig ist, stundenlang Fahrpläne zu bestudieren um aus zu finden welche Variante es gibt. Es wäre wenig sinnvoll nicht gebrauchzumachen von die praktische Lösung. Ich kenne genau 1 Mapper der das vor einige Jahren für 2 Linien gemacht hat. Er hat das aber zeitdem nicht mehr neu gemacht und De Lijn ändert das ständige kleinere oder grossere sachen dran. Desto mehr Varianten wir beschreiben, desto mehr Arbeit der oft nicht gemacht wird.

Was die stop_area Relation angeht war ich sehr froh mit ihrem Vorschlag für v3. Wir machen es schon so.

Nein. Beispiel: Ein Bahnhof "Pusemuckel" hat 4 Bahnsteige (1 bis 4). Auf der einen Seite ist ein Busbahnhof "Pusemuckel Bahnhof" mit 8 Bussteigen (1 bis 8). Auf der anderen Seite ist ein Busbahnhof "Pusemuckel Bahnhof/Westseite" mit 3 Bussteigen (1 bis 3).

Weide wrote:

-Nach PTv2BE sind es 15 Stop-Areas und ? stop_area_groups.
-Nach PTv2 sind es 3 Stop_Areas.
-Nach meinem Vorschlag sind es drei Stop-Areas und eine Stop_Area-Group.

Für mich ist es einfacher um das zu illustrieren an Hand Beispiele.

Also habe ich mal Bahnhof in Oostende und Haltestellengruppe Gent Zuid überarbeitet.

In Oostende gibt es 3 Bahnhofe

• Eine für die Büsse von De Lijn:
  

https://www.openstreetmap.org/relation/4299252

• Eine für die Trams von De Lijn:
  

https://www.openstreetmap.org/relation/4299241

• Und das Bahnhof von NMBS:
  

https://www.openstreetmap.org/relation/4299253

Die sind dann wieder zusammgefasst in:
https://www.openstreetmap.org/relation/4299254

Es gibt auch ein Ferryterminal. Darüber fehlen mir aber die Daten, sonnst würde der auch ein Eintrag bekommen in die letzte Relation.

Gent Zuid hat Gleise für Tram und viele Steige für Büse.

Die sind durchnumeriert, also reicht eine Relation um die zu grupieren:

https://www.openstreetmap.org/relation/4307993

(In Oostende ist es eine Ausnahme dass die Gleise vom Tram ihre eigene Sequenz für Numerierung haben. Das ist historisch so gekommen und es wird warscheinlich nicht mehr so sein nachdem das ganze in welche Jahren umgebaut wird zu einem völlig integrierten Bahnhof.)

Weide wrote:

Wenn eine zweite Platform da ist, dann darf ein Mapper sie auch in einer Route benutzen. (Er darf nicht beide Platforms benutzen, das wären dann zwei Halte und falsch.) Jetzt kann man aber an der einzelnen Platform eventuell nicht mehr alle Routen erkennen, weil einige auf der anderen Platform liegen.

Man kann nicht vorhersehen wie die Datenbank benutzt wird. Deshalb sollten die Sachen stimmen -- egal ob man einem ein Problem mit falschen Einträgen einfällt oder nicht.

Weide

Wenn man in ein ganzes Land der Regel hat um die Platforme die auf Ways un MPs gemappt sind nicht in die Routerelationen auf zu nehmen, dann ist da keine Verwirrung möglich. Wir sind hier angefangen HS nur auf Nodes zu mappen und es wäre sehr schwierig um das jetzt noch zu ändern. Ich bleibe dabei dass es besser gewesen wäre um diese Nodes nicht public_transport=platform zu vergeben.

Jetzt haben wir Nodes getaggt mit highway=bus_stop, public_transport=platform, bus/tram=yes welche alle Details enthalten.
Und Ways und MPs getaggt mit public_transport=platform, bus/tram=yes, highway/railway=platform, die angeben wo es in der Wirklichkeit Steige (Platforms) gibt.
Etwas verwirrend dass 2x public_transport=platform dafür benutzt wird, aber es ist unproblematisch um die 2 auseinander zu halten.

Das einzige Problem ist denn aber wo Routes über die Grenzen gehen, sowie in Aachen, Breda, Dunkerque. Da wird eine stop_area benötigt um die zu verbinden. Das funkzioniert natürlich nur, wenn es genau 1 stop_area pro HS gibt. Ist es möglich um das so vor zu schlagen für V3?

Die Segmentrouten habe ich jetzt selber auch aufgegeben. Ich entwickle einen Skript dass die Arbeit um die zu Warten/Unterhalten (maintenance) ungeheuer leichter macht. Es ist noch nicht völlig fertig, aber es spart schon viel Zeit.

Der nächsten Schritt ist dann eine Art webservice der angibt wo Wartung benötigt ist.

Frohe Weihnachten,

Jo

Polyglot wrote:

Weide wrote:

Es kann auch Edit-Wars geben, weil verschiedene Mapper sich auf verschiedene Quellen berufen.

Da hast du Recht. Das ist ein Problem. Wäre es möglich um die Reihenfolge für v3 um zu drehen? Oder ist sowas ausgeschlossen?

ausgeschlossen ist bei OSM nichts. Aber die Frage ist ob man die "abwärtskompatibilität" einfach so aufgeben möchte. Die Frage ist welchen Aufwand macht es dein Programm anzupassen? vielleicht kann man mit Version 3 einfach die Position der Haltestellen am "anderen Ende" einfach zu lassen, ohne es explizit zu fordern.

Polyglot wrote:

Für mich ist es einfacher um das zu illustrieren an Hand Beispiele.

Also habe ich mal Bahnhof in Oostende und Haltestellengruppe Gent Zuid überarbeitet.

In Oostende gibt es 3 Bahnhofe...

Weihnachten ruft ... deshalb nur ganz kurz...

Beim Bus gäbe es nach PTv2 nur eine stop_area mit allen 28 Platforms und allen 14 stop_positions. Alle 42 Elemente und die stop_area hätten "name=Oostende Station". Der Busbahnhof wäre also eine stop_area und nicht eine stop_area_group mit 14 stop_areas.

frohe Weihnacht und guten Rutsch
Weide

Weide wrote:

Polyglot wrote:

Für mich ist es einfacher um das zu illustrieren an Hand Beispiele.

Also habe ich mal Bahnhof in Oostende und Haltestellengruppe Gent Zuid überarbeitet.

In Oostende gibt es 3 Bahnhofe...

Weihnachten ruft ... deshalb nur ganz kurz...

Beim Bus gäbe es nach PTv2 nur eine stop_area mit allen 28 Platforms und allen 14 stop_positions. Alle 42 Elemente und die stop_area hätten "name=Oostende Station". Der Busbahnhof wäre also eine stop_area und nicht eine stop_area_group mit 14 stop_areas.

frohe Weihnacht und guten Rutsch
Weide

Ich weiss. Wenn das aber alles so auf einem Häufen geschmissen wird, kann nicht mehr daraus abgeleitet werden was zueinander gehört. Dann kann man auch einfach keinen stop_area machen und alles geometrisch ableiten (versuchen).

Jo

Polyglot wrote:

Wäre es möglich um die Reihenfolge für v3 um zu drehen? Oder ist sowas ausgeschlossen?

Da ist nichts ausgeschlossen, wir bestimmen das ja alle zusammen.

In meinem Vorschlag ist aber zentral, dass die alten Relationen bleiben bis zumindest die wichtigsten Renderer beides können. Das Problem mit der Reihenfolge bleibt also -- egal ob ich das in meinem Vorschlag ändere oder nicht.

Weide

Polyglot wrote:

Ich weiss. Wenn das aber alles so auf einem Häufen geschmissen wird, kann nicht mehr daraus abgeleitet werden was zueinander gehört. Dann kann man auch einfach keinen stop_area machen und alles geometrisch ableiten (versuchen).

Wir können gern darüber diskutieren, was bei PTv2 alles schlecht ist. Aber wenn wir etwas anderes wollen, dann sollten wir es nicht PTv2 nennen. Wenn erstmal viele Mapper die Maße von Objekten in Meter angegeben haben, dann sollte man nicht mehr darüber nachdenken, welche Länge für so einen Meter denn am praktischsten wäre. Man kann über neue und bessere Einheiten reden -- aber den Meter darf man nicht alle paar Wochen ändern.

Weide

Im Public Transport Schema V2 wird für Routen ein "name"-Tag vorgeschlagen:

name = <vehicle type> <reference number>: <initial stop> => <terminal stop>
Example: Bus 201: Uitikon Waldegg, Bahnhof => Uitikon, Wängi

Dies ist unpassend und sollte verbessert werden, denn
- ein solcher Name existiert in der realen Welt nicht und widerspricht somit der Namenskonvention in OSM:
"The names should be restricted to the name of the item in question only and should not include categories, types, descriptions, addresses or notes."
- kollidiert mit dem realen Namen einer Verbindung, sofern dieser existiert

Wie die Comment-Spalte nahelegt ("Prose description of route variant.") sollte der Text in "description" statt "name" stehen.
V2.1 sollte diesen Designfehler korrigieren.

seawolff wrote:

Wie die Comment-Spalte nahelegt ("Prose description of route variant.") sollte der Text in "description" statt "name" stehen.
V2.1 sollte diesen Designfehler korrigieren.

Sollte dieses "Ungetüm" irgendwo stehen?
Bus => kommt aus dem route
201 => aus dem ref
initial stop => aus dem from
terminal stop => aus dem to
Varianten stecken im via

Also sollen jetzt statt dem Namen der Buslinie nur noch Zahlen in OSM stehen?

Na vielen Dank. Dadurch wird die Übersichtlichkeit und die Benutzerfreundlichkeit stark gefördert.

Prince Kassad wrote:

Also sollen jetzt statt dem Namen der Buslinie nur noch Zahlen in OSM stehen?

Ich meinte dieses Ungetüm:
name = <vehicle type> <reference number>: <initial stop> => <terminal stop>
was, wie seawolff für mich richtig meint, nichts mit dem Namen einer Linie zu tun hat.

name wäre für mich z.B. statt "Bus 564 Hanau ⇒ Langen-Bergheim" "Linie 564 Langen-Bergheim", was wahrscheinlich auch auf dem Bus stehen könnte.
Don't panic. 🙂

Maskulinum wrote:

Ich meinte dieses Ungetüm:
name = <vehicle type> <reference number>: <initial stop> => <terminal stop>
was, wie seawolff für mich richtig meint, nichts mit dem Namen einer Linie zu tun hat.

name wäre für mich z.B. statt "Bus 564 Hanau ⇒ Langen-Bergheim" "Linie 564 Langen-Bergheim", was wahrscheinlich auch auf dem Bus stehen könnte.

Da ist PTv2 noch kürzer: die Linie heißt dort "Bus 564". Die Linie insgesamt findet man in der route_master-Relation und nicht in den route-Relationen.

Bei den route-Relationen geht es um die Varianten und da ist der Startort genauso ein Unterscheidungsmerkmal wie der Zielort und manchmal müssen sogar Zwischenziele genannt werden. Auf dem Bus muss der Startort natürlich nicht stehen, denn den an einer bestimmten Haltestelle wartenden Passagieren ist die Vergangenheit des Busses ja völlig egal.

Statt "Bus 201: Uitikon Waldegg, Bahnhof => Uitikon, Wängi" würde man auch vermutlich auch eher "Bus 201: Waldegg=>Wängi" schreiben.

Weide

Weide wrote:

Maskulinum wrote:

Ich meinte dieses Ungetüm:
name = <vehicle type> <reference number>: <initial stop> => <terminal stop>
was, wie seawolff für mich richtig meint, nichts mit dem Namen einer Linie zu tun hat.

name wäre für mich z.B. statt "Bus 564 Hanau ⇒ Langen-Bergheim" "Linie 564 Langen-Bergheim", was wahrscheinlich auch auf dem Bus stehen könnte.

Da ist PTv2 noch kürzer: die Linie heißt dort "Bus 564". [...]
Statt "Bus 201: Uitikon Waldegg, Bahnhof => Uitikon, Wängi" würde man auch vermutlich auch eher "Bus 201: Waldegg=>Wängi" schreiben.

Hier werden Busrouten meist als "Linie 201" oder evtl. "Linie 201 Start-Ziel" genannt (sowohl umgangssprachlich wie auch vom Betreiber).
Züge heißen "RB 84" oder vielleicht "RB 84 Lübeck – Kiel".
Die Konstuktionen "<vehicle type> <reference number>: <initial stop> => <terminal stop>" sind keine Namen und gehören nicht ins name-Tag.
Als "description" oder "note" sind sie vermutlich unkritisch. Ob man sie überhaupt braucht ist eine andere Frage.

seawolff wrote:

Die Konstuktionen "<vehicle type> <reference number>: <initial stop> => <terminal stop>" sind keine Namen und gehören nicht ins name-Tag.
Als "description" oder "note" sind sie vermutlich unkritisch. Ob man sie überhaupt braucht ist eine andere Frage.

Es sind von Mappern vergebene Varianten-Namen (nicht Liniennamen) und sie werden gebraucht. Sollen wir wirklich die drei Relationen der S2 von Essen, Duisburg und Recklinghausen nach Dortmund alle "S2 Dortmund" nennen? Dann sind die Master-Relationen unlesbar.
Um es nochmal klar zu sagen: es geht nicht um den Namen der Linie. Der ist in PTv2 "Train S2" oder "S2".

Weide

Zu Linienvarianten...

Da ich mich gerade mit Buslinien in meiner Umgebung beschäftige:

Hier mal das, was wir in der Pampa haben:

http://www.openstreetmap.org/relation/4435760 Hier der Fahrplan dazu: http://www.rvs-lds.de/tl_files/fahrplaene/509.pdf

Offiziell heißt sie: 509 Glietz < > Briesensee < > Lübben wobei lediglich die wenigsten der Linien die genannte Verbindung befahren. Das ist aber Standard hier... Die Linien sind so gestrickt, daß ein regelrechter Umlauf eines Busses und Fahrers über mehrere Linien entsteht...
Die Relation enthält alle Varianten des Fahrplans... wenn ich nichts übersehen hab...

Vom Einpflegen in OSM her ein riesen Aufwand...

Ach ja, die Angabe im name-Tag der einzelnen Routen-Variante hilft mir einigermaßen bei den vielen Varianten durchzusehen... sie sind für mich unerläßlich.

Sven

Gibt es eigentlich in Deutschland auch Geselschafte die ihre Daten offenbar machen unter Lizenz die in OSM übernommen werden kann, oder die damit einstimmen das die Daten in OSM aufgenommen werden?

Wenn man das von Fahrpläne ableiten muss, ist das tatsächlich ein ungeheuer Aufwand. Speziell weil das alles jetzt von unten aus zerbrochen wird von Mappern und von 'oben' aus wird das auch hier und dort manchmal angepasst.

Jo

Ich wusste noch nicht mal dass es überhaupt erlaubt ist von Fahrplänen abzukupfern... es machen aber scheinbar viele.

Wenn nicht von die Fahrplänen und nicht von die Quelldaten, wie kann man dann sicher sein alle Varianten sind eingeschlossen? Dann muss man diese Linien allen mal benutzen, mal auf Wochentag, mal am Samstag, mal am Sonntag, Freitagabends, Sonntagabends, Mittwoch zwischen 12 und 2. Mal die erste und die letzte Fahrt, weil die auch manchmal abweichen.

Und wie weiss man denn wenn etwas geändert würde and die Fahrplänen. Oder man musste es jede 3 Monate noch mal neu machen und vergleichen ob es noch stimmt.

Kein Problem mit 1000 Mappern, sondern wir sind froh wenn 1 pro Gegend sich daran interessiert.

Ich habe 2 Jahren mails geschickt an Gesellschaft De Lijn (Flandern) (Nicht jede Woche). Und auf einem Tag haben die dann Zustimmung gegeben um ihre Daten in OSM zu übernehmen. TEC (Wallonien) haben ihre Daten dann nochmal 2 Jahre später völlig freigegeben unter freie Lizenz.

Nur die Gesellschaft in Brüssel antwortet nicht. Vielleicht müsste ich mal auf Französisch versuchen... Man kann die Daten bekommen, aber die sagen: nicht für kommerzielle Benutzung. An Google haben die die schon langst vergeben. Und Google macht da auch eine Art kommerzielle Benutzung.

Jo

Prince Kassad wrote:

Ich wusste noch nicht mal dass es überhaupt erlaubt ist von Fahrplänen abzukupfern... es machen aber scheinbar viele.

ich verweise mal auf:
http://forum.openstreetmap.org/viewtopic.php?id=19209 und auf http://daten.berlin.de/datensaetze/vbb- … ember-2015

Polyglot wrote:

Gibt es eigentlich in Deutschland auch Geselschafte die ihre Daten offenbar machen unter Lizenz die in OSM übernommen werden kann, oder die damit einstimmen das die Daten in OSM aufgenommen werden?

Wenn man das von Fahrpläne ableiten muss, ist das tatsächlich ein ungeheuer Aufwand. Speziell weil das alles jetzt von unten aus zerbrochen wird von Mappern und von 'oben' aus wird das auch hier und dort manchmal angepasst.

Jo

Es sind mir derzeit keine Unternehmen bekannt, welche das tun. Aber es gibt Verbünde die dies tun bzw. getan haben. Einer der ersten war der VRS welcher die Mapper eingeladen hat und dort GPX Routen bereitgestellt hatte um die Linien zu übernehmen.
Später folgte der VBB, welcher regelmäßig aktualsierte GTFS Daten zur Verfügung stellt. Dabei gibt es die ausdrückliche Genehmigung der Übernahme in OSM. Es fehlt lediglich ein Konzept, wie dies geschehen kann.
Ich hatte einmal begonnen für ein automatisches Einlesen vorzuarbeiten: http://www.openstreetmap.org/relation/3 … 94/13.5257
Allerdings macht es als Einzelkämpfer nur wenig Spaß. Dazu kommt das die Daten leider nur Haltestellenbereichsscharf sind und man so diverse Spezialfälle leider nicht abdecken kann.
Wenn es dazu neue Ideen gibt, würde ich mich sehr freuen.

Inzwischen gibt es auch weitere Verbünde, die Ihre Daten anbieten. Darunter ist Ulm und der VRN (http://www.vrn.de/vrn/einfach-ankommen/ … index.html) Hier als VDV Format. Auch dabei kann ich gerne bei der Umwandlung behilflich sein. Leider hat es nur mit dem Zuschicken der Daten nicht geklappt.

Weide wrote:

Es sind von Mappern vergebene Varianten-Namen (nicht Liniennamen) und sie werden gebraucht. Sollen wir wirklich die drei Relationen der S2 von Essen, Duisburg und Recklinghausen nach Dortmund alle "S2 Dortmund" nennen? Dann sind die Master-Relationen unlesbar.

Mapper vergeben keine Namen sondern erfassen existierende Namen (siehe Wiki:Names).
Mapper dürfen natürlich Bezeichnungen generieren, aber die gehören nicht nach "name" sondern in einen dafür vorgesehenen Key oder evtl. in "note" oder "description".

Um es nochmal klar zu sagen: es geht nicht um den Namen der Linie. Der ist in PTv2 "Train S2" oder "S2".

Auch "Train S2" ist in Deutschland höchstwahrscheinlich nicht der übliche Name und gehört nicht ins "name"-Tag.

Ich weiß nicht, ob wir jetzt hier OT werden...

viw wrote:

Dazu kommt das die Daten leider nur Haltestellenbereichsscharf sind und man so diverse Spezialfälle leider nicht abdecken kann.

Mit der derzeitigen Datenlage kann die Haltestellen-ID lediglich in die Haltestellen-Relation geschrieben werden, da punktscharfe Daten wie bei einigen Stationen Berlins http://daten.berlin.de/datensaetze/%C3% … estationen fehlen. Hier sollte aber auch eindeutig festgelegt werden, was an welchen Tag kommt, ob Abkürzungen verwendet werden oder nicht. letzeres wäre besser.

In dem Datensatz stop_times der aktuellen Fahrplandaten wird nur von Haltestellenbereich zu Haltestellenbereich geroutet... Dort ist nicht aufgeschlüsselt, wenn es mehrere Haltepunkte gibt. Den Haltestellen-ID also in die Stop-Position zu schreiben bringt also nichts...

... und wenn man in die Bus-Relation anstelle Platform und Stop-Position die Haltestellen-Relation schreibt? ...ist aber auch Blöd...

Sven

Es ist in JOSM möglich Namen zusamenstellen zu lassen anhand tags und sogar tags von parent relations.

Das lässt dann aber iD und Potlatchbenutzer ohne Namen, wenn wir die in description oder note verschieben. Keine ahnung ob diese Editors mittlerweile zurückfallen können auf andere tags wenn name nicht vorhanden ist. Vor einige Jahren wollte der Entwickler von Potlatch das nicht unterstutzen.

Man muss dazu sowas:

␣␣␣<item␣name="De␣Lijn"␣type="relation"
name_template="route(!{parent()␣type=route_master'?{'{operator}␣{ref:De_Lijn}␣'␣|␣'{ref}␣'}'}{ref}␣?{'{from}␣-␣{via}␣-␣{to}␣'␣|␣'{from}␣-␣{to}␣'␣|␣'{from}␣'␣|␣'{to}␣'}?{'{note}␣'})"
name_template_filter="type=route␣route=bus">
</item>

<item␣name="De␣Lijn"␣type="relation"
name_template="route_master(?{'{operator}␣{ref:De_Lijn}␣{ref}␣{name}'})"
name_template_filter="type=route_master␣route_master=bus">
</item>

<item␣name="De␣Lijn"␣type="relation"
name_template="route(!{parent()␣type=route_master'?{'{operator}␣{ref:De_Lijn}␣'␣|␣'{ref}␣'}'}{ref}␣?{'{from}␣-␣{via}␣-␣{to}␣'␣|␣'{from}␣-␣{to}␣'␣|␣'{from}␣'␣|␣'{to}␣'}?{'{note}␣'})"
name_template_filter="type=route␣route=tram">
</item>

<item␣name="De␣Lijn"␣type="relation"
name_template="route_master(?{'{operator}␣{ref:De_Lijn}␣{ref}␣{name}'})"
name_template_filter="type=route_master␣route_master=tram">
</item>

an ein Presets file hinzufügen. Das muss natürlich erst mehr generell gemacht werden. Jetzt funktioniert es nur gut für route und route_master von De Lijn. Was mich daran gefällt ist das die schön zusammen geordnet werden im Relations pane.

Jo

streckenkundler wrote:

Ich weiß nicht, ob wir jetzt hier OT werden...

viw wrote:

Dazu kommt das die Daten leider nur Haltestellenbereichsscharf sind und man so diverse Spezialfälle leider nicht abdecken kann.

Mit der derzeitigen Datenlage kann die Haltestellen-ID lediglich in die Haltestellen-Relation geschrieben werden, da punktscharfe Daten wie bei einigen Stationen Berlins http://daten.berlin.de/datensaetze/%C3% … estationen fehlen. Hier sollte aber auch eindeutig festgelegt werden, was an welchen Tag kommt, ob Abkürzungen verwendet werden oder nicht. letzeres wäre besser.

In dem Datensatz stop_times der aktuellen Fahrplandaten wird nur von Haltestellenbereich zu Haltestellenbereich geroutet... Dort ist nicht aufgeschlüsselt, wenn es mehrere Haltepunkte gibt. Den Haltestellen-ID also in die Stop-Position zu schreiben bringt also nichts...

... und wenn man in die Bus-Relation anstelle Platform und Stop-Position die Haltestellen-Relation schreibt? ...ist aber auch Blöd...

Ich kann dir gerade nicht folgen. Es gibt eine Nummer für einen Haltestellenbereich. Zum Beispiel für den S+U Zoologischer Garten Bhf (Berlin) die 9023201.
Diese Nummer gilt egal ob für U-Bahn, Bus oder S-Bahn für alles was dort hält. Das ist insbesondere für die Busse kritisch, da hier unklar ist von welchem Mast die Busse abfahren, wenn sie eine bestimmte nächste Haltestelle anfahren. Bei allen anderen Verkehrsmitteln ist das kein Problem.
Für den Alexanderplatz hat der Verbund das bereits gelöst, in dem die Haltestelle in verschiedene Haltestellenbereiche aufgeteilt wurde. Das war dort vor allem wegen der Umsteigewege notwendig.
Welcher Relation will man also nun welche Nummer geben? Meiner Meinung nach gibt es nur eine saubere Möglichkeit. Jedem Punkt den Tag ref:VBB:area mitzugeben. Damit kann man schnell alle Punkte rausfiltern welche zu diesem Bereich gehören.
Wenn man die Nummer nur in die stop_area aufnimmt, würde man am Zoo verdammt viele Relationen mit der gleichen Nummer haben. Aber auch an der stop_area_group kann man das nicht machen, da man sonst nicht alle Haltestellenbereiche des Alexanderplatzes zusammen fassen könnte ohne das Unsinn raus kommt.
In den Linienvarianten oder Linienrelationen hat das meiner Meinung nach nichts zu suchen.

Edit: Bitte nicht die veralteten Stationsnamen aus dem Link verwenden. Gerade zu diesem Fahrplanwechsel wurden wieder diverse Stationen umbenannt. Falls nötig kann ich nochmal eine XLS erstellen. Sonst sind die Informationen aber auch in den aktuellen GTFS Datensätzen in der stops.txt Datei gespeichert. http://daten.berlin.de/datensaetze/vbb- … ember-2015

Ich hab mir gerade mal aus den aktuellen Fahrplandaten eine Datenbank gebaut... um durchzusehen.

viw wrote:

Für den Alexanderplatz hat der Verbund das bereits gelöst, in dem die Haltestelle in verschiedene Haltestellenbereiche aufgeteilt wurde. Das war dort vor allem wegen der Umsteigewege notwendig.

Für Berlin Alexanderplatz ist es differenziert... anscheinend einer der Wenigen...

stop_name	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣agency_name	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣stop_id
S+U␣Alexanderplatz␣(Berlin)␣[U2]	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100703
S+U␣Alexanderplatz␣(Berlin)␣[U5]	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100704
S+U␣Alexanderplatz␣(Berlin)␣[U8]	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100705
S+U␣Alexanderplatz␣(Bln)␣[Bus␣K.-Liebknecht-Str]	␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100708
S+U␣Alexanderplatz␣Bhf␣(Berlin)	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣DB␣Regio␣AG	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣9100003
S+U␣Alexanderplatz␣Bhf␣(Berlin)	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣ODEG␣Ostdeutsche␣Eisenbahn␣GmbH	9100003
S+U␣Alexanderplatz␣Bhf␣(Berlin)	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣S-Bahn␣Berlin␣GmbH	␣␣␣␣␣␣␣␣9100003
S+U␣Alexanderplatz␣Bhf/Dircksenstr.␣(Berlin)	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100024
S+U␣Alexanderplatz␣Bhf/Gontardstr.␣(Berlin)	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100026
S+U␣Alexanderplatz␣Bhf/Grunerstr.␣(Berlin)	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100006
S+U␣Alexanderplatz␣Bhf/Memhardstr.␣(Berlin)	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100031
U␣Alexanderplatz␣(Berlin)␣[Tram]	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100005
U␣Alexanderplatz␣[Bus]	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100707

Welcher Relation will man also nun welche Nummer geben? Meiner Meinung nach gibt es nur eine saubere Möglichkeit. Jedem Punkt den Tag ref:VBB:area mitzugeben. Damit kann man schnell alle Punkte rausfiltern welche zu diesem Bereich gehören.

Meinst du damit der stop_position?

Wenn man die Nummer nur in die stop_area aufnimmt, würde man am Zoo verdammt viele Relationen mit der gleichen Nummer haben. Aber auch an der stop_area_group kann man das nicht machen, da man sonst nicht alle Haltestellenbereiche des Alexanderplatzes zusammen fassen könnte ohne das Unsinn raus kommt.

Ja... der Alex ist da sicher ein gutes Beispiel, daß meine Idee Quark war...

Wenn man sich http://datenfragen.de/openvbb/Bahnhoefe … swahl.xlsx anschaut, hat alles eine ID... Das wäre diese, die an das Objekt gehört. Das hieße, daß dann auch, daß für jede o.g. stop_id eine Haltestellen-Relation angelegt werden müsste... ??!

fragt sich Sven

streckenkundler wrote:

Ich hab mir gerade mal aus den aktuellen Fahrplandaten eine Datenbank gebaut... um durchzusehen.

Das ist sehr gut!

streckenkundler wrote:

viw wrote:

Für den Alexanderplatz hat der Verbund das bereits gelöst, in dem die Haltestelle in verschiedene Haltestellenbereiche aufgeteilt wurde. Das war dort vor allem wegen der Umsteigewege notwendig.

Für Berlin Alexanderplatz ist es differenziert... anscheinend einer der Wenigen...

stop_name	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣agency_name	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣stop_id
S+U␣Alexanderplatz␣(Berlin)␣[U2]	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100703
S+U␣Alexanderplatz␣(Berlin)␣[U5]	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100704
S+U␣Alexanderplatz␣(Berlin)␣[U8]	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100705
S+U␣Alexanderplatz␣(Bln)␣[Bus␣K.-Liebknecht-Str]	␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100708
S+U␣Alexanderplatz␣Bhf␣(Berlin)	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣DB␣Regio␣AG	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣9100003
S+U␣Alexanderplatz␣Bhf␣(Berlin)	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣ODEG␣Ostdeutsche␣Eisenbahn␣GmbH	9100003
S+U␣Alexanderplatz␣Bhf␣(Berlin)	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣S-Bahn␣Berlin␣GmbH	␣␣␣␣␣␣␣␣9100003
S+U␣Alexanderplatz␣Bhf/Dircksenstr.␣(Berlin)	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100024
S+U␣Alexanderplatz␣Bhf/Gontardstr.␣(Berlin)	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100026
S+U␣Alexanderplatz␣Bhf/Grunerstr.␣(Berlin)	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100006
S+U␣Alexanderplatz␣Bhf/Memhardstr.␣(Berlin)	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100031
U␣Alexanderplatz␣(Berlin)␣[Tram]	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100005
U␣Alexanderplatz␣[Bus]	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100707

Ja es ist besser, aber noch nicht perfekt! du kannst dir gerne mal die ref:BVG anschauen. Da siehst du dann was dem VBB noch fehlt. Über diese Nummer kann man dann die website dieses Mastes aufrufen. (Sie ist als QR Code dort aufgedruckt, der NFC Tag besitzt noch eine eingeschobene 100)

streckenkundler wrote:

Welcher Relation will man also nun welche Nummer geben? Meiner Meinung nach gibt es nur eine saubere Möglichkeit. Jedem Punkt den Tag ref:VBB:area mitzugeben. Damit kann man schnell alle Punkte rausfiltern welche zu diesem Bereich gehören.

Meinst du damit der stop_position?

Damit meinte ich stop_position genauso wie platform oder Mastschild, welches ich viel lieber verwende.

streckenkundler wrote:

Wenn man die Nummer nur in die stop_area aufnimmt, würde man am Zoo verdammt viele Relationen mit der gleichen Nummer haben. Aber auch an der stop_area_group kann man das nicht machen, da man sonst nicht alle Haltestellenbereiche des Alexanderplatzes zusammen fassen könnte ohne das Unsinn raus kommt.

Ja... der Alex ist da sicher ein gutes Beispiel, daß meine Idee Quark war...

Wenn man sich http://datenfragen.de/openvbb/Bahnhoefe … swahl.xlsx anschaut, hat alles eine ID... Das wäre diese, die an das Objekt gehört. Das hieße, daß dann auch, daß für jede o.g. stop_id eine Haltestellen-Relation angelegt werden müsste... ??!

Ich denke nicht das die Idee Quark war. Es zeigt nur wie unterschiedlich die Daten sind. Meiner Meinung nach müssten am Alex alle Bereiche eine stop_area Relation erhalten und dann die entsprechende Nummer. Zusammenfassen kann man das dann in einer stop_area_group, damit die Umsteigebeziehungen klarer werden.
Das ist allerdings am Bahnhof Zoo nicht mehr so einfach. Dort ist nach VBB Definition noch alles ein Haltestellenbereich. Aber man sollte es wenigstens in Bus U-Bahn und den Rest teilen. Diese Relationen hätten dann aber wieder die selbe Nummer.
Ich denke es ist auch nicht verkehrt die VBB Namen zu erfassen, da dies Verwechslungen vorbeugt. Am Fahrplan/Schild ist meist nur eine verkürzte Form zu finden.

streckenkundler wrote:

Ich hab mir gerade mal aus den aktuellen Fahrplandaten eine Datenbank gebaut... um durchzusehen.

viw wrote:

Für den Alexanderplatz hat der Verbund das bereits gelöst, in dem die Haltestelle in verschiedene Haltestellenbereiche aufgeteilt wurde. Das war dort vor allem wegen der Umsteigewege notwendig.

Für Berlin Alexanderplatz ist es differenziert... anscheinend einer der Wenigen...

stop_name	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣agency_name	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣stop_id
S+U␣Alexanderplatz␣(Berlin)␣[U2]	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100703
S+U␣Alexanderplatz␣(Berlin)␣[U5]	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100704
S+U␣Alexanderplatz␣(Berlin)␣[U8]	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100705
S+U␣Alexanderplatz␣(Bln)␣[Bus␣K.-Liebknecht-Str]	␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100708
S+U␣Alexanderplatz␣Bhf␣(Berlin)	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣DB␣Regio␣AG	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣9100003
S+U␣Alexanderplatz␣Bhf␣(Berlin)	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣ODEG␣Ostdeutsche␣Eisenbahn␣GmbH	9100003
S+U␣Alexanderplatz␣Bhf␣(Berlin)	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣S-Bahn␣Berlin␣GmbH	␣␣␣␣␣␣␣␣9100003
S+U␣Alexanderplatz␣Bhf/Dircksenstr.␣(Berlin)	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100024
S+U␣Alexanderplatz␣Bhf/Gontardstr.␣(Berlin)	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100026
S+U␣Alexanderplatz␣Bhf/Grunerstr.␣(Berlin)	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100006
S+U␣Alexanderplatz␣Bhf/Memhardstr.␣(Berlin)	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100031
U␣Alexanderplatz␣(Berlin)␣[Tram]	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100005
U␣Alexanderplatz␣[Bus]	␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣Berliner␣Verkehrsbetriebe	9100707

Welcher Relation will man also nun welche Nummer geben? Meiner Meinung nach gibt es nur eine saubere Möglichkeit. Jedem Punkt den Tag ref:VBB:area mitzugeben. Damit kann man schnell alle Punkte rausfiltern welche zu diesem Bereich gehören.

Meinst du damit der stop_position?

Wenn man die Nummer nur in die stop_area aufnimmt, würde man am Zoo verdammt viele Relationen mit der gleichen Nummer haben. Aber auch an der stop_area_group kann man das nicht machen, da man sonst nicht alle Haltestellenbereiche des Alexanderplatzes zusammen fassen könnte ohne das Unsinn raus kommt.

Ja... der Alex ist da sicher ein gutes Beispiel, daß meine Idee Quark war...

Wenn man sich http://datenfragen.de/openvbb/Bahnhoefe … swahl.xlsx anschaut, hat alles eine ID... Das wäre diese, die an das Objekt gehört. Das hieße, daß dann auch, daß für jede o.g. stop_id eine Haltestellen-Relation angelegt werden müsste... ??!

fragt sich Sven

So mache ich das hier jedenfalls. Für jede HS eine stop_area. Die dann wieder grupieren in eine stop_area_group. Es ist dann kein v2 mehr...

Für mich macht es mehr sinn die ref/id auf Platform zu setzen. Wir haben noch nicht überall stop_position gemappt. Was angeblich abweicht von v2 ist das wir nur nodes benutzt haben für highway=bus_stop, public_transport=platform, bus/tram=yes. Das sind hier die wichtige Nodes die name/ref/route_ref/operator/network details haben.

Wir haben wohl das Glück gehabt, dass wir vom Anfang an refs für die HS zur Verfügung hatten (Die sind angegeben auf den Schildern in der Strasse, wenigstens für De Lijn) und das hat natürlich die Entscheidung beeinflusst um HS neben den Strassen zu taggen, und diese Nodes als wichtigste zu sehen.

Ich habe jetzt auch gefunden warum ich nie überwogen habe um diese Details auf platform ways/MP zu setzen. Das hat zu tun mit MapCSS die all diese Daten schön rum die Nodes anschaut:

Ich hatte einen screenshot, sehe aber nicht wie den ein zu schliessen.

viw wrote:

Damit meinte ich stop_position genauso wie platform oder Mastschild, welches ich viel lieber verwende.

wenn wir die Daten so genau hätten... klar...

viw wrote:

Meiner Meinung nach müssten am Alex alle Bereiche eine stop_area Relation erhalten und dann die entsprechende Nummer. Zusammenfassen kann man das dann in einer stop_area_group, damit die Umsteigebeziehungen klarer werden.

Dan denken wir in die selbe Richtung... Gut...

viw wrote:

Das ist allerdings am Bahnhof Zoo nicht mehr so einfach. Dort ist nach VBB Definition noch alles ein Haltestellenbereich. Aber man sollte es wenigstens in Bus U-Bahn und den Rest teilen. Diese Relationen hätten dann aber wieder die selbe Nummer.

Nun, ich glaube es ist eine Frage der Zeit, daß der VBB auch den Bahnhof Zoo zerteilt... 😄 (Ich "liebe" den Bahnhof Zoo... vor allem wenn ich da umsteigen muß). Ein Aufteilen würde sicher schon helfen... zumal eine indirekte Zuordnung dann möglich wäre: aus den OSM-Haltestellenbereichen die mit Bus und aus den GTFS-Daten die Bus-Fahrplandaten.

Bliebe noch die Frage nach dem Tagging: ref:VBB=* an die Haltestellen-Relation und der VBB-Name als Name der Haltestellen-Relation, network=Verkehrsverbund Berlin-Brandenburg und operator=* (bei mir: Regionale Verkehrsgesellschaft Dahme-Spreewald mbH) Sifern Stop-Position und Platform (Bussteig, Bahnsteig ect. ) eine eigene ID haben, bekommen sie ihe eigene ID als ref:VBB

schlägt Sven vor

streckenkundler wrote:

Bliebe noch die Frage nach dem Tagging: ref:VBB=* an die Haltestellen-Relation und der VBB-Name als Name der Haltestellen-Relation, network=Verkehrsverbund Berlin-Brandenburg und operator=* (bei mir: Regionale Verkehrsgesellschaft Dahme-Spreewald mbH) Sifern Stop-Position und Platform (Bussteig, Bahnsteig ect. ) eine eigene ID haben, bekommen sie ihe eigene ID als ref:VBB

Also ich würde nicht ref:VBB verwenden, da es eindeutig die Referenz für den Bereich ist. Daher hatte ich ref:VBB:area benutzt. Wenn man was besseres findet kein Problem.
Und für den Name würde ich name:VBB vorschlagen, da verschiedene Anbieter für gleiche Haltestellen verschiedene Namen verwenden. So kann man die auseinander halten.
Was das ausschreiben von VBB angeht, so ist die Abstimmung mit den Füßen derzeit eindeutig.
2468 Relationen mit VBB zu 406 mit der ausgeschriebenen Variante.
und 998 Punkte kurz zu 128 mit langer Schreibweise.

Beim Operator scheint es ähnlich zu sein:
1238 Punkte mit BVG zu 18 mit Berliner Verkehrsbetriebe
936 Relationen zu 1

viw wrote:

Also ich würde nicht ref:VBB verwenden, da es eindeutig die Referenz für den Bereich ist. Daher hatte ich ref:VBB:area benutzt. Wenn man was besseres findet kein Problem.

Ok... damit kann ich leben... sollte aber dokumentiert werden...

viw wrote:

Und für den Name würde ich name:VBB vorschlagen, da verschiedene Anbieter für gleiche Haltestellen verschiedene Namen verwenden. So kann man die auseinander halten.
Was das ausschreiben von VBB angeht, so ist die Abstimmung mit den Füßen derzeit eindeutig.

Ok... kein Problem...

[Edit] Hier eine nachträgliche Frage... in den VBB-Namen sind Straßen oft abgekürzt... Aber es sind bei Straßen auch i.d.R. die Ortsnamen vorangeschrieben...

die openptmap hat nun den ersten Teil meiner Edits übernommen... noch nicht alle...

an diversen Stellen funktioniert die Abfrage gut... http://openptmap.org/?zoom=15&lat=51.94 … =B0000TFFT z.B. Haltestelle Briesener Zergoweg an anderenm nicht...: z.B. Ostbahnhof... das hinterläßt bei mir den Eindruck, daß der Abgleich über die Haltestellen-Namen passiert, Nummern hab ich noch nicht eingepflegt... Da wäre nun interessant, nach welcher Schreibweise der Namen die Auswertung passiert...
Die öpnvkarte ist zwar echneller mit der Darstellung fer Bus-Routen... aber nicht mit den Haltestellenrelationen... 🙁 [/Edit]

viw wrote:

2468 Relationen mit VBB zu 406 mit der ausgeschriebenen Variante.
und 998 Punkte kurz zu 128 mit langer Schreibweise.

Beim Operator scheint es ähnlich zu sein:
1238 Punkte mit BVG zu 18 mit Berliner Verkehrsbetriebe
936 Relationen zu 1

da sollte man gegebenfalls beide Varianten berücksichtigen... beim operator- und network-Tag habe ich das ausgeschrieben:

operator=Regionale Verkehrsgesellschaft Dahme-Spreewald mbH
network=Verkehrsverbund Berlin-Brandenburg

Gerade beim Operator gäbe es laut Taginfo Überschneidung zu "RVS Regionalbusverkehr Südwest GmbH"

Die wenigen, eindeutig dem Landkreis Dahme-Spreewald zuzuordnenden operator-Tags will ich mir noch genau anschauen...

Sven

seawolff wrote:

Mapper vergeben keine Namen sondern erfassen existierende Namen (siehe Wiki:Names).
Mapper dürfen natürlich Bezeichnungen generieren, aber die gehören nicht nach "name" sondern in einen dafür vorgesehenen Key oder evtl. in "note" oder "description".

Ja, ich sehe es ein: "name" wird hier gegen die Regeln benutzt. "note" und "description" sind aber auch nicht passend. In meinem Vorschlag habe ich für den Fall eines solchen Konfliktes "p3:name" vorgesehen -- ich hatte allerdings nicht angenommen, dass der Konflikt immer da wäre.

Varianten haben dann also keine Namen. Aber was haben wir dann? (Nehmen wir als Beispiel für den neuen Key einfach mal "xname"). Dann müssten die Editoren umprogrammiert werden, so dass bei Varianten-Relationen "name" zu ignorieren ist und "xname" überall dort zu verwenden ist, wo bisher im Code "name" steht. Die werden uns erzählen, dass wir ein Rad ab haben. Ich bin mir nicht sicher, wo man jetzt was verändern muss, aber die Definition von "name" ist vielleicht überarbeitungswürdig.

Weide

streckenkundler wrote:

viw wrote:

Also ich würde nicht ref:VBB verwenden, da es eindeutig die Referenz für den Bereich ist. Daher hatte ich ref:VBB:area benutzt. Wenn man was besseres findet kein Problem.

Ok... damit kann ich leben... sollte aber dokumentiert werden...

Ja sollte. Aber wo? Und wer findet das dann?

streckenkundler wrote:

die openptmap hat nun den ersten Teil meiner Edits übernommen... noch nicht alle...

an diversen Stellen funktioniert die Abfrage gut... http://openptmap.org/?zoom=15&lat=51.94 … =B0000TFFT z.B. Haltestelle Briesener Zergoweg an anderenm nicht...: z.B. Ostbahnhof... das hinterläßt bei mir den Eindruck, daß der Abgleich über die Haltestellen-Namen passiert, Nummern hab ich noch nicht eingepflegt... Da wäre nun interessant, nach welcher Schreibweise der Namen die Auswertung passiert...
Die öpnvkarte ist zwar echneller mit der Darstellung fer Bus-Routen... aber nicht mit den Haltestellenrelationen... 🙁

Die Auswertung der openptkarte geht sehr wahrscheinlich nach Namen. Das kannst du an der URL sehen. Die Schwierigkeit dabei ist aber nicht nur die Auswertung nach Namen und nicht VBB Namen, sondern auch dass die Abfrage bei der Auskunft der DB passiert. Diese verwendet teilweise andere Namen als der VBB.

streckenkundler wrote:

viw wrote:

2468 Relationen mit VBB zu 406 mit der ausgeschriebenen Variante.
und 998 Punkte kurz zu 128 mit langer Schreibweise.

Beim Operator scheint es ähnlich zu sein:
1238 Punkte mit BVG zu 18 mit Berliner Verkehrsbetriebe
936 Relationen zu 1

da sollte man gegebenfalls beide Varianten berücksichtigen... beim operator- und network-Tag habe ich das ausgeschrieben:

operator=Regionale Verkehrsgesellschaft Dahme-Spreewald mbH
network=Verkehrsverbund Berlin-Brandenburg

Gerade beim Operator gäbe es laut Taginfo Überschneidung zu "RVS Regionalbusverkehr Südwest GmbH"

Ist es wirklich wichtig weltweit eindeutig zu sein? Oder reicht auch wen wir in der Region eindeutig sind? Man kann das ja überall im Land sehen. S7 in Berlin ist eben nicht S7 in Frankfurt. Und auch die Buslinien im VBB sind nicht eindeutig. Bei REs und RBs wollen wir lieber gar nicht darüber reden. Da reicht schon der Blick nach Mecklenburg. Der RE2 von Cottbus kommend hat fährt von Ostbahnhof nach Bahnhof Zoo gemeinsam mit dem RE7 (Wünsdorf - Dessau) und zwischen Ludwigslust und Wismar RE7(Ludwigslust - Wismar).
Also um daraus Informationen zu gewinnen ist es immer erforderlich auch den Regionalen Kontext zu beachten.

viw wrote:

Die Auswertung der openptkarte geht sehr wahrscheinlich nach Namen. Das kannst du an der URL sehen. Die Schwierigkeit dabei ist aber nicht nur die Auswertung nach Namen und nicht VBB Namen, sondern auch dass die Abfrage bei der Auskunft der DB passiert. Diese verwendet teilweise andere Namen als der VBB.

Ich habe an einigen Stellen als Haltestellennamen den so, wie er in Fahrplan steht: z.B. "Lübben, Berliner Chaussee" da funktioniert der Aufruf; oder der Name als solches ist einmalig: "Briesener Zergoweg". Ist der Name nicht eindeutig, findet er z.T. völlig falsche Sachen...

Aber auch innerhalb des VBB, bei Busgesellschaften werden unterschiedliche Namen verwendet...:

VGOSL: "Lübben, Hauptbahnhof"
RVS: "Lübben, Bahnhof"
DB: "Lübben (Spreewald)"

VGOSL: "Lübben, Cottbusser Straße"
RVS: "Lübben, Cottbuser Straße"

Man beachte die falsche Schreibweise bei VGOSL. Die Straße heißt "Cottbuser Straße"

Das wir an den ID's nicht vorbeikommen , da sind wir uns einig... in meinem Bereich kommen sie in Kürze rein (ref:VBB:area=*), ebenso die Namen (name:VBB=*) jeweils an die Haltestellenrelation.

Sowohl openptmap als auch ÖPNVKarte werten aber den Stop-Node und nicht die Haltestellenrelation aus...

Sven

streckenkundler wrote:

Aber auch innerhalb des VBB, bei Busgesellschaften werden unterschiedliche Namen verwendet...:

VGOSL: "Lübben, Hauptbahnhof"
RVS: "Lübben, Bahnhof"
DB: "Lübben (Spreewald)"

Du hast vergessen zu erwähnen was auf dem Haltestellenschild steht. Auch das kann noch einmal was ganz anderes sein und wäre das was meiner Meinung nach in name=* gehört. Alle anderen können in name:RVS=* und name:VGOSL=* gepackt werden. Wobei sogar innerhalb eines Unternehmens verschiedene Schreibweisen auftauchen können.

viw wrote:

Du hast vergessen zu erwähnen was auf dem Haltestellenschild steht.

Ich hab jetzt keine Lust, zum Bahnhof zu gehen... auch wenn es nur 5 Minuten zu Fuß sind...

was mir aufgefallen ist: gibt z.B. man bei http://fahrinfo.vbb.de/bin/query.exe/dn den Haltestellen-ID ein, kommt der korrekte Bahnhof... Im RIS der DB ( http://reiseauskunft.bahn.de/bin/bhftafel.exe/dn?) kommt man mit der Nummer nicht weiter... nur mit dem Namen...

ich mache mal mit den Station-ID's weiter...

Sven

streckenkundler wrote:

was mir aufgefallen ist: gibt z.B. man bei http://fahrinfo.vbb.de/bin/query.exe/dn den Haltestellen-ID ein, kommt der korrekte Bahnhof... Im RIS der DB ( http://reiseauskunft.bahn.de/bin/bhftafel.exe/dn?) kommt man mit der Nummer nicht weiter... nur mit dem Namen...

ich mache mal mit den Station-ID's weiter...

Ähm ja das ist ja auch die VBB ID und nicht die HafasNummer. Die wäre für Lübben 8010217.
Das entspräche dann der IBNR welche man auch bei Wikipedia sehen kann: http://de.wikipedia.org/wiki/Bahnhof_L% … reewald%29

viw wrote:

streckenkundler wrote:

was mir aufgefallen ist: gibt z.B. man bei http://fahrinfo.vbb.de/bin/query.exe/dn den Haltestellen-ID ein, kommt der korrekte Bahnhof... Im RIS der DB ( http://reiseauskunft.bahn.de/bin/bhftafel.exe/dn?) kommt man mit der Nummer nicht weiter... nur mit dem Namen...

ich mache mal mit den Station-ID's weiter...

Ähm ja das ist ja auch die VBB ID und nicht die HafasNummer. Die wäre für Lübben 8010217.
Das entspräche dann der IBNR welche man auch bei Wikipedia sehen kann: http://de.wikipedia.org/wiki/Bahnhof_L% … reewald%29

haben wir das auch eine Liste, die man einpflegen kann?

streckenkundler wrote:

viw wrote:

Ähm ja das ist ja auch die VBB ID und nicht die HafasNummer. Die wäre für Lübben 8010217.
Das entspräche dann der IBNR welche man auch bei Wikipedia sehen kann: http://de.wikipedia.org/wiki/Bahnhof_L% … reewald%29

haben wir das auch eine Liste, die man einpflegen kann?

Es kam immer mal wieder auf. Z.B.: http://forum.openstreetmap.org/viewtopic.php?id=7487
Ob da jetzt aber abschließend geklärt ist ob es eine Liste gibt, die wir verwenden dürfen weiß ich nicht.

viw wrote:

streckenkundler wrote:

viw wrote:

Ähm ja das ist ja auch die VBB ID und nicht die HafasNummer. Die wäre für Lübben 8010217.
Das entspräche dann der IBNR welche man auch bei Wikipedia sehen kann: http://de.wikipedia.org/wiki/Bahnhof_L% … reewald%29

haben wir das auch eine Liste, die man einpflegen kann?

Es kam immer mal wieder auf. Z.B.: http://forum.openstreetmap.org/viewtopic.php?id=7487
Ob da jetzt aber abschließend geklärt ist ob es eine Liste gibt, die wir verwenden dürfen weiß ich nicht.

Ja, gerade gelesen... Danke... So wie ich das sehe, ist es ein Unterschied zwischen IBNR und UIC-Nummer...

Bahnhof "Lübben (Spreewald)"

VBB: 9261512
IBNR: 741046
UIC: 8010217

...Hm... 😐

Ich konzentriere mich erst mal auf die VBB-Nummer...

Sven

viw wrote:

ber man sollte es wenigstens in Bus U-Bahn und den Rest teilen.

Ich hab gerade im Landkreis Dahme-Spreewald noch fehlende network und operator-Tags nachgetragen, da stieß ich auf Schönefeld: http://www.openstreetmap.org/relation/1213986

wenn man einigermaßen sauberes Tagging haben will, muß man aufteilen. Die Notwendigkeit ergibt sich aus den unterschiedlichen Betreibern:
Regionalbahnsteige: DB-Regio,
S-Bahnsteige: S-Bahn Berlin
Bussteige: RVS

Damit dürfte sich als Regel herausstellen, daß, wenn an einer Haltestelle z.B. ein Übergang von Bus nach Bahn ist, so sind auch deren Haltestellenbereiche getrennt zu erfassen. Dann müssten aber wiederum z.B. ein ref:VBB:area an die stop_area_group, wenn es noch keine einzel-Refs gibt wie beim Alexanderplatz...

Sven

streckenkundler wrote:

viw wrote:

ber man sollte es wenigstens in Bus U-Bahn und den Rest teilen.

Ich hab gerade im Landkreis Dahme-Spreewald noch fehlende network und operator-Tags nachgetragen, da stieß ich auf Schönefeld: http://www.openstreetmap.org/relation/1213986

wenn man einigermaßen sauberes Tagging haben will, muß man aufteilen. Die Notwendigkeit ergibt sich aus den unterschiedlichen Betreibern:
Regionalbahnsteige: DB-Regio,
S-Bahnsteige: S-Bahn Berlin
Bussteige: RVS

Halt! Betreiber des Bahnhofs kann nicht DB-Regio sein. An Stationen mit Regional und Fernverkehr ist der Betreiber immer Station und Service. Lediglich bei Haltepunkten mit nur S-Bahn ist es derzeit noch die S-Bahn-Berlin GmbH Allerdings wechselt das zu ich glaube 2017 auch alles an DB Station und Service.
Bei dem Haltestellenbereiber ist es noch schwerer. Denn es gibt ja verschiedene Busunternehmen die diese Haltestelle anfahren. Ob da jetzt die RVS oder die BVG VTF oder noch wer ganz anderes das sagen hat weiß ich nicht.
Möglich ist sogar das die Haltestellen vom Landkreis sind und die VU das nur im Auftrag machen.

viw wrote:

Halt! Betreiber des Bahnhofs kann nicht DB-Regio sein. An Stationen mit Regional und Fernverkehr ist der Betreiber immer Station und Service. Lediglich bei Haltepunkten mit nur S-Bahn ist es derzeit noch die S-Bahn-Berlin GmbH Allerdings wechselt das zu ich glaube 2017 auch alles an DB Station und Service.

Ja, gut... Ich wollte nur darauf hinaus, daß eine Station mehrere Betreiber hat...Schönefeld fasse ich eh nicht an... zu weit an Berlin dran... 🙂
Bei mir in Lübben ist aber diese Teilung Bussteige sind ein anderer Betreiber als die Bahnsteiggleise... bei gleicher VBB-Haltestellennummer.

viw wrote:

Bei dem Haltestellenbereiber ist es noch schwerer. Denn es gibt ja verschiedene Busunternehmen die diese Haltestelle anfahren. Ob da jetzt die RVS oder die BVG VTF oder noch wer ganz anderes das sagen hat weiß ich nicht.
Möglich ist sogar das die Haltestellen vom Landkreis sind und die VU das nur im Auftrag machen.

Ich schätze mal bei den Bushaltestellen ust es bei mir ist es der RVS: Klich auf Zahlen und Fakten:http://www.rvs-lds.de/rvs_unternehmen.html

schätzt Sven

Ich habe alle HS in Belgien umgewandelt auf dieses System:

https://www.openstreetmap.org/node/495352804/history

Die Anleitung dazu findet man am Anfang dieses Threads. Ich war erst angefangen mit 4 Platform Nodes für diese HS. Jetzt sind die zusammengenommen. Das Problem sind tatsäglich manchmal die Namen.

Sowie man hier beobachten kann:

https://www.openstreetmap.org/node/778232825/history

Von TEC aus würde das eher Aachen Alter Posthof nennen. Die HS an andere Seite der Strasse ist nicht geteilt mit/bedient vom AVV und da ist noch der vom TEC vergebenen Namen da.

Jo

streckenkundler wrote:

Ich schätze mal bei den Bushaltestellen ust es bei mir ist es der RVS: Klich auf Zahlen und Fakten:http://www.rvs-lds.de/rvs_unternehmen.html

schätzt Sven

Interessant! Nach einer ersten groben Auswertung komme ich für die RVS auf 779 angefahrene Haltestellen. Das scheint ja schon eine größere Abweichung nach unten zu sein.

viw wrote:

streckenkundler wrote:

viw wrote:

Also ich würde nicht ref:VBB verwenden, da es eindeutig die Referenz für den Bereich ist. Daher hatte ich ref:VBB:area benutzt. Wenn man was besseres findet kein Problem.

Ok... damit kann ich leben... sollte aber dokumentiert werden...

Ja sollte. Aber wo? Und wer findet das dann?

Bei dem ganzen wunderbaren Fernsehprogramm kommt man endlich zum Nachdenken und nachlesen 😄

Erst mal eine Frage... Wie ist es denn außerhalb des VBB bei anderen Verkehrsverbünden? Da existieren doch sicher auch solche Geschichten mit Stations-ID's.

Grundsätzlich würde ich das auch erst mal nur auf Verkehrsverbundebene beschränken, die an den Verbund angeschlossenen Gesellschaften sollten aber auch mit erwähnt werden (siehe unten).

Unter: http://wiki.openstreetmap.org/wiki/DE:T … Dstop_area ist das schon fast so drin... nur ref:xxx:area sollte mit genannt und erklärt werden.

Auf der anderen Seite sollte auch http://wiki.openstreetmap.org/wiki/Wiki … Nahverkehr dazu weiter genutzt werden, da hier die Verbünde mit Langnamen und Kürzel gelistet...

Ich baue mal Overpass-Abfragen zusammen, die einerseits die Strecken andererseits die Haltestellen-Relationen abfragen.

Sven

streckenkundler wrote:

viw wrote:

streckenkundler wrote:

Ok... damit kann ich leben... sollte aber dokumentiert werden...

Ja sollte. Aber wo? Und wer findet das dann?

Erst mal eine Frage... Wie ist es denn außerhalb des VBB bei anderen Verkehrsverbünden? Da existieren doch sicher auch solche Geschichten mit Stations-ID's.

Alle Auskunftssysteme arbeiten mit IDs. Allerdings sind die eben nicht unbedingt zugänglich wie beim VBB. Auch müssen IDs nicht immer Nummern sein.

streckenkundler wrote:

Unter: http://wiki.openstreetmap.org/wiki/DE:T … Dstop_area ist das schon fast so drin... nur ref:xxx:area sollte mit genannt und erklärt werden.

Auf der anderen Seite sollte auch http://wiki.openstreetmap.org/wiki/Wiki … Nahverkehr dazu weiter genutzt werden, da hier die Verbünde mit Langnamen und Kürzel gelistet...

Ich weiß nicht ob man da einfach etwas ergänzen darf ohne vorher ein Proposal zu schreiben. Immerhin wird sich ja immer wieder auf das Wiki berufen wenn es darum geht, was richtig ist.

streckenkundler wrote:

Ich baue mal Overpass-Abfragen zusammen, die einerseits die Strecken andererseits die Haltestellen-Relationen abfragen.

Was ich interessant finden würde wäre eine Abfrage in der die Haltestellen der Linienroute mit den VBB-IDs stehen würden. Aber ich fürchte das ist nicht möglich. Daher war ich auch der Meinung zuerst allen Punkten die Keys mitzugeben.

Ich habe mal n'n Screencast gemacht zum schauen wie ich hier Busrouten mappe:

https://www.youtube.com/playlist?list=P … 7HzIs0KXJu

Der erste hat Unterschrifte (müssen aber noch überarbeitet werden). Die andere (noch) nicht.

Weil jetzt aus der Wochennotiz darauf verlinkt würde habe ich dieses Artikel noch mal überarbeitet. Auch mit was ich während diese Konversation neu gelernt habe.

http://osm.be/nl/content/mapping-public … rt-belgium

Leider steht es dort nicht auf der richtige Stelle, und vielleicht werde ich es später die englische Version nach meinen Diary verschieben. Jetzt habe ich aber noch kein Zeit für die Übersetzung nach Niederländisch und Französisch.

Ich meine auch der Zeit sei gekommen um das ganze auf einen Server zu verschieben:

http://wiki.openstreetmap.org/wiki/FOSS … ion_and_QC

Mal sehen ob sowas möglich ist.

Jo

Ich hab meinen Vorschlag nochmal komplett überarbeitet.
http://wiki.openstreetmap.org/wiki/User … rschlag_P3

Weide

Hallo Weide,

Ich habe versucht es zu lesen. Wird warscheinlich notwendig sein es noch 3x mehr zu lesen ehr ich eine sinnvolle Aussage darüber machen kann.

Kannst du mich ein Beispiel zeigen wo MP notwendig sind für die Erfassung von HS?

Grüsse,

Jo

Polyglot wrote:

Kannst du mich ein Beispiel zeigen wo MP notwendig sind für die Erfassung von HS?

Die Multipolygone sind nur das Thema nach dem Vorschlag und haben nichts damit zu tun. Ganz oben auf der Seite ist ein Inhaltsverzeichnis, da sieht man das sofort.

Weide

Kann es sein,dass hier http://wiki.openstreetmap.org/wiki/User … menfassung hinter dem Wort Member: was fehlt?

Swen Wacker wrote:

Kann es sein,dass hier http://wiki.openstreetmap.org/wiki/User … menfassung hinter dem Wort Member: was fehlt?

Ja, da war ein Fehler. Danke!

Die Leerzeilen sollten drüber und nicht drunter sein. Es folgt ja die Tabelle der Member. Ich hatte dasselbe auch an ein paar anderen Stellen.

Danke
Weide

Weide wrote:

Ich hab meinen Vorschlag nochmal komplett überarbeitet.
http://wiki.openstreetmap.org/wiki/User … rschlag_P3

Die folgenden Anmerkungen sind nicht als Verriss sondern als konstruktive Kritik gemeint.
Ein präzise definiertes Taggingschema begrüße ich sehr.

1. Falsche Verwendung des Name-Tags

DE:Names wrote:

name ist nur der Name
Die Namen sollten nur den eigentlichen Namen des fraglichen Objekts enthalten und keine Kategorien / Typen, Beschreibungen, Adressen oder Anmerkungen enthalten. Jegliche über den Namen hinausgehenden Informationen sollten in gesonderten Tags eingetragen werden

User:Weide#Vorschlag_P3 wrote:

name: Möglichst kurzer Text, der es dem eiligen Fahrgast ermöglicht, das richtige Fahrzeug zu finden.Bei Bussen häufig die Frontanzeige.

name: Kurzbezeichnung der Verbindung ohne Angaben von wo nach wo. Z.B. "RE3", "Bus 825", "Tram 123"

name: sinnvoller Name für das angegebene Gesamtobjekt, der auch in gröberen Maßstäben brauchbar ist.

Das sind keine Namen.

Manche Routen haben reale Namen ("Kielius", Fähre Breiholz", "Sylt Shuttle"), die mit den vorgeschlagenen Pseudonamen kollidieren würden.

Ein anderer Key würde die Probleme lösen.

User:Weide#Definitionen_und_die_Freiheit wrote:

Bereits im Gebrauch befindliche Tags werden im Wiki umdefiniert, ohne einen Gedanken an die damit geänderte Bedeutung von zigtausend Datensätzen zu verschwenden.
Wir sollten das Internet als Vorbild nehmen. Da kann jeder z.B. neue Protokolle für den Dateitransfer erfinden ... aber niemand darf deswegen FTP umdefinieren.

Sehr treffend geschrieben ;-)

2. NoName

Alle in den Routen genannten Haltobjekte haben einen Namen []
Anders als in PTv2 ist die Namensangabe nicht optional.

Bei manchen Verbindungen gibt es keine (erkennbaren) Namen (z.B. Anleger bei Kanalfähren sind oft mit Namen der Fährverbindung an beiden Ufern gleichermaßen beschriftet)

3. Besonderheiten von Fährverbindungen

- Wie werden Stop und Platform bei Fähren gesetzt?
- Wie werden verschiedene Zugangswege für Fußgänger und Fahrzeuge behandelt?
- Was tun bei abwechseln bedienten, nebeneinander liegenden Anlegestellen einer Route

seawolff wrote:

Das sind keine Namen.

Manche Routen haben reale Namen ("Kielius", Fähre Breiholz", "Sylt Shuttle"), die mit den vorgeschlagenen Pseudonamen kollidieren würden.

Ein anderer Key würde die Probleme lösen.

Ja. Deshalb gibt es den vorangestellten Abschnitt "Namen". Überall wo es einen Konflikt mit der Definition von "name" gibt soll statt dessen "p3_name" als Name im Sinne des Vorschlags genutzt werden. In der Endfassung müsste aber an jede Nennung von "name" ein Sternchen oder eine Fußnote zur Klarstellung.

seawolff wrote:

Wie werden Stop und Platform bei Fähren gesetzt?

Stops und Platforms werden in dem Vorschlag als Angelegenheit des lokalen Mappings betrachtet und nicht festgelegt. Die einzig relevanten Objekte im Vorschlag sind die "Halt-Objekte (Start- und Zielobjekte der Passagiere, die die ÖPV-Verbindung genutzt haben oder nutzen wollen). Die werden oft Platforms sein oder werden machmal ersatzweise Stop-Positions sein oder müssen als eigene (gewöhnlich nicht in Karten dargestellte) Objekte gemappt werden. Das könnte bei Fähren z.B. ein Wartebereich vor einer Schranke zur Ticketprüfung sein.

seawolff wrote:

Wie werden verschiedene Zugangswege für Fußgänger und Fahrzeuge behandelt?

Dass der "Passagier" ein Fahrzeug sein kann, hatte ich nicht bedacht. Aber es geht vermutlich trotzdem. Es kann ja mehrere Haltangaben (Ziele des Passagieroutings) zu einem Halt geben und die Routingprogramme müssen die günstigste dieser Routen finden. Das Autorouting wird dann die Angaben für Passagiere als "nicht erreichbar" verwerfen und umgekehrt geht es genauso. Man könnte also beide Angaben machen. Muss aber nochmal genau überlegt werden...

seawolff wrote:

Was tun bei abwechseln bedienten, nebeneinander liegenden Anlegestellen einer Route

Das kommt darauf an. Es könnte eine Variante der Route sein "Immer wenn das Schiff von soundso kommt, macht es da und da fest". Wenn es aber nur lokale Zusammenhänge gibt, dann wären es "+halt_alt"-Angaben, wie bei dynamischer Bahnsteigzuordnung von Zügen.

Bei manchen Verbindungen gibt es keine (erkennbaren) Namen (z.B. Anleger bei Kanalfähren sind oft mit Namen der Fährverbindung an beiden Ufern gleichermaßen beschriftet)

Da muss man sich was Kurzes ausdenken und wohl p3_name benutzen.

bis dann
Weide

Aus diesem Thread: http://forum.openstreetmap.org/viewtopi … 79#p478379

Thoschi wrote:

So wie ich es in der Standardkarte und mit dem Layer Verkehrkarte wahrnehmen, wird mit dem bisherigen PT-Schema der Name nur einmal pro stop_position und platform gesetzt. Zusätzlich habe ich einen Node auf der platform mit Highway=bus_stop und Name stehen, der wird ebenfalls nicht zusätzlich ausgewertet, sondern anscheinend "entweder oder".

Bezgl. PTv2 habe ich im Kopf, dass sich doch hier Gedanken über PTv2.1 bzw. v3 gemacht werden. Richtig?

Wenn man das Schema "rein" einsetzt dann wird der Name der Haltestelle nur in der Relation angegeben. Ich habe dafür auch eine Präzisierung ins Wiki geschrieben. http://wiki.openstreetmap.org/w/index.p … id=1126870

Wenn das dem Geist entspricht sollte es im Englischen auch geändert werden weil es bis jetzt nur heißt "recommended if no public_transport=stop_area exists, else optional"

Jojo4u wrote:

Ich habe dafür auch eine Präzisierung ins Wiki geschrieben.

Das was da schon vorher stand ist falsch und wurde vom Autor in der englischen Fassung nur eingetragen, weil er es -- auf meine Anfrage nach seiner eigenen Aussage -- nicht verstanden hat. Ich hatte angenommen, dass er es danach geändert hat...

Da es weggelassen werden kann, wenn eine stop_area existiert, gehört in die Stop-Positions und die Platforms genau der in der stop_area anzugebende Name. Also der Name der Haltestelle. "Bahnsteig C" gehört da nicht rein -- auch nicht als Bestandteil.

Weide

Mal dazu, worum es in diesem Thread ursprünglich ging...

Nakaner wrote:

Einführung eines Wertes für Rufbusse (und ggf. Linientaxen). Rufbusse muss man vorbestellen, einfach an das H-Schild stellen und warten, bringt da wohl wenig.

Dafür (on_demand=yes habe ich schon an eins, zwei Stellen verwendet).

Nakaner wrote:

service=* an Master-Relationen (oder Routenrelationen), um die Wichtigkeit der Route zu beschreiben. Derzeit kann man das nur anhand des ref-Tags entscheiden, ob es sich um Fern- oder Nahverkehr handelt. Meistens ist das sowas wie "RE 7" oder "ICE 20", aber manchmal auch die Abkürzung einer Bahngesellschaft. Geht man über die Grenze, kann man auf die Schnauze fallen. "R" ist in Tschechien eine Schnellzuggattung! Man könnte die im OpenRailwayMap-Schema definierten Werte ins PTv2.1-Schema übernehmen: high_speed, long_distance, regional, commuter, car, car_shuttle, night, tourism. Für Busse sollte es um "city" (Stadtbus) und "city_express" (innerstädtische Schnellbusse, z.B. Hamburg und Rom) ergänzt werden.

Dafür. Für Busse bräuchte es noch service=school, für Linien die nur aus ein paar Fahrten an Schultagen bestehen. Diese könnten auf Karten z. B. gestrichelt dargestellt werden. Außerdem peak und night.

Open PT Map stellt Linien mit state=alternate, sprich seltener bediente Linienvarianten, gestrichelt dar (keine Ahnung, wo der Tag herkommt...), wäre gut wenn es künftig was offizielles gäbe.

Weide wrote:

Jojo4u wrote:

Ich habe dafür auch eine Präzisierung ins Wiki geschrieben.

Das was da schon vorher stand ist falsch und wurde vom Autor in der englischen Fassung nur eingetragen, weil er es -- auf meine Anfrage nach seiner eigenen Aussage -- nicht verstanden hat. Ich hatte angenommen, dass er es danach geändert hat...

Da es weggelassen werden kann, wenn eine stop_area existiert, gehört in die Stop-Positions und die Platforms genau der in der stop_area anzugebende Name. Also der Name der Haltestelle. "Bahnsteig C" gehört da nicht rein -- auch nicht als Bestandteil.

Im Proposal vom 21.04.2011 steht für name von platform:

name␣	Individual␣name␣	The␣name␣by␣which␣the␣platform␣is␣known.␣	recommended␣if␣no␣public_transport=stop_area␣exists,␣else␣optional

Die Infos von Weide eingarbeitet habe ich jetzt folgendes im deutschen public_transport=platform:

name␣	Haltestellenname␣	Der␣Haltestellenname.␣Gleis-/Platformnummer(n)␣werden␣mit␣ref␣erfasst.␣	sehr␣empfohlen,␣wenn␣kein␣public_transport=stop_area␣existiert,␣sonst␣optional

Ist das so mehrheitsfähig?

Jojo4u wrote:

...eingarbeitet...

Danke!

"ref" als Steignummer ist etwas problematisch. Da "ref" ja eine ganz allgemeine Referenznummer ist, kann sich das mit anderen Nummern beißen. Für die meisten Sachen gibt es deshalb spezifische "ref"s wie "uic_ref" oder "route_ref". Wenn man in "ref" etwas nicht identifizierbares findet, kann man es nicht einfach überschreiben. Da "local_ref" durch den NAPTAN-Kram ziemlich eindeutig auf Haltestellennummer festgelegt ist und teilweise sogar in der Normalkarte als solche angezeigt wird, bietet es sich als Haltestellennummer an. (Man darf natürlich nicht so tun, als ob das eine PTv2-Regel wäre ... in PTv2 steht leider nichts zum Thema Steignummern.)

Weide

BTW: Gibt es eine abgesprochene Regel, wie wir mit abweichenden Haltestellen-Namen im Verkehrsverbund umgehen?
Im HVV wird z.B. - um die Eindeutigkeit des Namens zu ermöglichen - dem Haltestellennamen die jeweilige Stadt/Gemeinde vorangestellt "Lüneburg, Am Sande" (HVV-Name) vs. "Am Sande" (KVG-Name)

Du nimmst als name für die Haltestelle am besten was vor Ort am Schild steht.
Alles weitere kannst du mit name:HVV und name:KVG erfassen.

Danke. Dann schlage ich vor, den Wikieintrag zu platform um einen Eintrag name:<identifier>=* zu ergänzen.

Und dann bliebe da noch die Fahrplanauskunft der Bahn. Bei der HVV heißt die Haltestelle "Ernst-Braune-Straße" so: "Lüneburg, Ernst-Braune-Straße", Bei der Fahrplanauskunft der Bahn heißt sie "Ernst-Braune-Straße, Lüneburg". Sollte ich also auch name:Bahn erfassen? Oder überlasse ich das dem Geschick der Auswertungsprogramme?
Ist die IBNR, die (auch) die Bahn verwendet (z.B. http://reiseauskunft.bahn.de/bin/bhftaf … ut=618353) proprietär oder "offen". Ich meine hier(?) mal gelesen zu haben, dass sie proprietär sei.

ref_name wird dafür schon ziemlich lang benutzt. http://openptmap.org/ wertet es z.B. aus. Normalerweise kann man einen Inhalt finden, der für die Bahn und die lokalen Unternehmen geeignet ist. "Lüneburg, Ernst-Braune-Straße" funktioniert mit beiden Anbietern.

Weide

Okay. Ist es konsensual, wenn ich den Wikieintrag zu http://wiki.openstreetmap.org/wiki/DE:T … 3Dplatform um die Zeile

ref_name=* optional Name welcher in Internet Fahrplänen verwendet wird. Gewöhnlich in Verbindung dem Namen der Bushaltestelle und dem Name der Stadt; z.B. ref_name=Steintor, Hannover

ergänze?

Dieser Text steht übrigens hier in dem Abschnitt Halte Postion, nicht aber unter Bushaltestelle . Ist das Absicht?

Gegen den Text ist nichts einzuwenden. Nur das Beispiel sollte gut überlegt sein. Internetfahrplanauskunft ist nicht gleich Deutsche Bahn! Die meisten Verkehrsverbünde stellen den Ortsnamen vorne an. Auch bei vielen Busbetrieben habe ich das so gesehen. Warum die DB als Standard genau das andere favorisiert weiß ich nicht.
Edit: Vielleicht ist es damit die Ergebnisse schneller gefunden werden. Denn unter Berl würde man sonst erstmal tausende Beliner Haltestellen finden. Und der Kunde kennt in der Regel auch das was auf dem Schild steht und nicht zu welchem Ortsteil Gemeinde oder was auch sonst noch vorangestellt die Haltestelle gehört.

Mir gefällt es wenn Haltestellen per Dorf/Stadt bei einander sortiert werden. Man kann immer suchen auf Internet. Hier in Belgien gab es einigen die der Name der Gemeinde wohl benutzt haben, anderen nicht. So haben wir entscheiden um die 'überall' hin zu fügen. Ausnahme: Antwerpen und Brüssel. Für Brüssel gefällt mir das, weil da alles in 2 Sprachen gemacht werden muss und dann kann es wirklich lang werden:

Berchem Sainte-Agathe - Sint-Agatha-Berchem Avenue Reine Élisabeth - Konining Elisabethlaan

Die hinten dran schreiben haben wir nie überwogen.

Die Komma müsste ich nochmal vorlegen auf talk-be. Im Moment trennen wir das nicht mit Komma und es ist eigentlich vollig klar was Name und was Gemeinde/Ort ist

Für mich wäre es am saubersten die Gemeinde/Ort in einen separaten Tag zu setzen, und dann name formatters benutzen um die neben einander dar zu stellen. Das funkzioniert dann aber nur in JOSM und dennoch nur für die Leute die den Preset geladen haben welche diese Name Formatters enthalten.

Jo

Weide wrote:

ref_name wird dafür schon ziemlich lang benutzt. http://openptmap.org/ wertet es z.B. aus. Normalerweise kann man einen Inhalt finden, der für die Bahn und die lokalen Unternehmen geeignet ist. "Lüneburg, Ernst-Braune-Straße" funktioniert mit beiden Anbietern.

Weide

Die OpenPTMap greift ja auf DB-Daten zu. Gibt es eine Karte, die z.B. auf Daten des Verkehrsverbund Berlin-Brandenburg zugreift, um unterschiedliche Anwendungsfälle zu testen?

Sven

streckenkundler wrote:

Die OpenPTMap greift ja auf DB-Daten zu. Gibt es eine Karte, die z.B. auf Daten des Verkehrsverbund Berlin-Brandenburg zugreift, um unterschiedliche Anwendungsfälle zu testen?

Sven

Eine solche Karte kenne ich noch nicht.
Aber du kannst es ja mal mit den URL Parametern Input versuchen:
http://fahrinfo.vbb.de/bin/stboard.exe/ … dType=dep&

Gibt es eigentlich eine Referenzanwendung, die PTv2 in einer Karte auswertet und so den Mehrwert der einzelnen Elemente anschaulich macht?

<snip> (Doppelposting)

viw wrote:

streckenkundler wrote:

viw wrote:

Ähm ja das ist ja auch die VBB ID und nicht die HafasNummer. Die wäre für Lübben 8010217.
Das entspräche dann der IBNR welche man auch bei Wikipedia sehen kann: http://de.wikipedia.org/wiki/Bahnhof_L% … reewald%29

haben wir das auch eine Liste, die man einpflegen kann?

Es kam immer mal wieder auf. Z.B.: http://forum.openstreetmap.org/viewtopic.php?id=7487
Ob da jetzt aber abschließend geklärt ist ob es eine Liste gibt, die wir verwenden dürfen weiß ich nicht.

Es gibt zumindest hier eine Liste aller Deutschen Bahnhöfe, deren Verwendung für OSM vom VRR autorisiert ist... Stand 10/2014.
Ob die noch benötigt wird oder alle deutschen Bahnhöfe eh schon damit getagged sind, weiß ich nicht... komme eher aus der Bus-Welt ;-)
http://wiki.openstreetmap.org/wiki/VRR/ … Treffen.29

Gruß
Achim

Mir ist da noch eine Idee gekommen....

Wir haben ja derzeit die Situation, dass die unabsichtlichen Beschädigungen an PTv2-Routen durch das Auftrennen von Wegen in ganz anderen Zusammenhängen (meist Lane-Edits und Fußgängerinseln und meist in JOSM) zu einigen Stunden Reparaturarbeiten pro Tag allein in NRW führen. Diese Reparaturen sind gewöhnlich ziemlich leicht durchführbar, aber sie kosten auch mit viel Routine viel Zeit und sie bringen keinen Fortschritt sondern beseitigen nur Rückschritte. Die Verursacher bekommen von der ganzen Angelegenheit nichts mit, da die von ihnen verarbeiteten Objekte nicht geändert werden müssen. Wir arbeiten also mit Datenstrukturen, die sehr ungüstige Zusammenhänge schaffen.

Ich habe jetzt vielleicht eine Möglichkeit gefunden, die Routen einer ÖPV-Linie so zu formulieren, dass sie unempfindlich gegen anderweitige Editieroperationen werden (und leichter auf die trotzdem noch anfallenden Restschäden hin überprüfbar werden).

Dazu werden die von vielen Mappen ja ohnehin gewünschten Segmente eingesetzt. (Diese geben gemeinsame Routenstücke von mehreren Varianten an und vermeiden so vielfache Angaben derselben Sache.) Wenn nun die Routen gar keine Fahrwege mehr enthalten und also nur noch aus Segmenten zusammengesetzt werden, dann ist diese Segmentreihenfolge unabhängig von anderen Editieraktivitäten. Verlangt man nun von den Segmenten, dass sie nur ein eindeutiges Wegstück beschreiben (verzweigte Wegenetze wären da ohnehin wenig sinnvoll), dann kann man in den Segmenten ohne Reihenfolgeinformation arbeiten und sie so ebenfalls unabhängig von anderen Editieraktivitäten machen. Sie wären dann eine Art PTv1-Routen ohne Haltestellen (mit "forward", "backward" und "bidir") -- ergäben aber immer einen eindeutigen Weg. Das beträfe nur die Fahrwege, die Halte wären nach wie vor in der Route selbst.

Weide

Weide wrote:

Wir haben ja derzeit die Situation, dass die unabsichtlichen Beschädigungen an PTv2-Routen durch das Auftrennen von Wegen in ganz anderen Zusammenhängen (meist Lane-Edits und Fußgängerinseln und meist in JOSM) zu einigen Stunden Reparaturarbeiten pro Tag allein in NRW führen. Diese Reparaturen sind gewöhnlich ziemlich leicht durchführbar, aber sie kosten auch mit viel Routine viel Zeit und sie bringen keinen Fortschritt sondern beseitigen nur Rückschritte. Die Verursacher bekommen von der ganzen Angelegenheit nichts mit, da die von ihnen verarbeiteten Objekte nicht geändert werden müssen.

Du beschreibst nur eine Seite. Viele Mapper achten darauf, mit ihren Änderungen keinen Schaden an den ÖPNV-Relationen zu verursachen. Die einen passen die Relationen selbst an und brauchen dafür sehr viel Zeit, weil sie ungeübt sind und viel nachlesen müssen, die anderen verzichten darauf, solche Straßen zu bearbeiten. Die Verursacher, also die Ersteller der ÖPNV-Relationen, bekommen von der ganzen Angelegenheit nichts mit, da man den erstellten Changesets die Mehrarbeit nicht ansieht und die nicht erstellten Changesets gar nicht sichtbar sind.

Wir arbeiten also mit Datenstrukturen, die sehr ungüstige Zusammenhänge schaffen.

Ja!

Dazu werden die von vielen Mappen ja ohnehin gewünschten Segmente eingesetzt. (Diese geben gemeinsame Routenstücke von mehreren Varianten an und vermeiden so vielfache Angaben derselben Sache.)

Das wäre schon ein Fortschritt. Allerdings fügt man damit dem ÖPNV-Schema eine weitere Abstraktionsebene hinzu und macht die Kontrolle der Relationen abhängig vom Editor komplizierter.

Konsequent wäre es, nur die Haltestellen zu erfassen und die stupide Arbeit einem Router bei der Auswertung überlassen.
Damit würde man sowohl den Mappern, die ÖPNV-Relationen erstellen und pflegen, als auch jenen, die die Straßen editieren, viel Arbeit abnehmen.
Die Datenstrukturen wären zudem weniger anfällig gegen unabsichtliche Zerstörung.

Wie kann man denn mit dem Auftrennen eines Weges eine PTv2-Route kaputt machen? Auftrennen macht doch nur Abbiegeverbote und destination_signs kaputt. Das Zusammenführen ist in meinen Augen das Problem. Das ist eine der riskantesten Aktionen in OSM (und eine rein kosmetische), wobei die neueren JOSM-Versionen wenigstens mit dem mehrfachen Vorkommen in einer Relation klar kommen. Wie es sich da mit anderen Editoren verhält weiß ich ja nicht.

Aber davon ab fände ich es schade, wenn man Segmente auf eine noch höhere PT-Version verschieben müsste. Ich habe hier Buslinien, die aus insgesamt 10 Einzelvarianten bestehen mit eigentlich nur einer handvoll Variationen, wenn man Bausteine nehmen würde. Wenn dann jemand einen Baustein beschädigt, müsste man auch nicht gleich alle Relationen fixen, sondern nur den einen Baustein. Aber ohne guten Editor-Support in JOSM sehe ich schwarz für Segment-Bausteine.

Nadjita wrote:

Aber ohne guten Editor-Support in JOSM sehe ich schwarz für Segment-Bausteine.

Ich habe Segmente für ÖPNV-Stammlinien (Innenstadt, Busbahnhof) verwendet und darin keine Schwierigkeiten gesehen.
Es gibt allerdings Anwendungen, die mit geschachtelten Relationen nicht zurechtkommen.

Ich meine eher, dass man selbst den Überblick verliert, ob die Segmente überhaupt (noch) aneinanderpassen und dadurch auch, ob die Reihenfolge stimmt. In JOSM könnte ich mir das aufklappbar im Routeneditor vorstellen *träum*

Nadjita wrote:

Ich meine eher, dass man selbst den Überblick verliert, ob die Segmente überhaupt (noch) aneinanderpassen und dadurch auch, ob die Reihenfolge stimmt. In JOSM könnte ich mir das aufklappbar im Routeneditor vorstellen *träum*

Der OSM Relation Analyzer http://ra.osmsurround.org/ kann die Zusammenhängigkeit auch bei geschachtelten Relationen darstellen (konnte es zumindest damals).
Im JOSM-Relationen-Editor wäre das Feature natürlich viel effizienter angesiedelt.

Nadjita wrote:

Wie kann man denn mit dem Auftrennen eines Weges eine PTv2-Route kaputt machen? Auftrennen macht doch nur Abbiegeverbote und destination_signs kaputt. Das Zusammenführen ist in meinen Augen das Problem. Das ist eine der riskantesten Aktionen in OSM (und eine rein kosmetische), wobei die neueren JOSM-Versionen wenigstens mit dem mehrfachen Vorkommen in einer Relation klar kommen. Wie es sich da mit anderen Editoren verhält weiß ich ja nicht.

Das Auftrennen ist ein Problem, wenn nicht genügend Mitglieder der Relation geladen sind. Im Folgenden gehe ich von JOSM aus. Angenommen, der Editor hat von einer Relation nur eine Way geladen. Wenn man nun diesen Way aufsplittet, woher soll der Editor dann wissen, dass er Teil 1 vor Teil 2 oder Teil 2 vor Teil 1 in die Relation einsortieren soll? Wenn die angrenzenden Member (also das erste vor und nach dem zu teilenden Way) geladen sind, dann kann er das selbst ermitteln (außer die Relation ist so kaputt, dass die gerade an der Stelle ein Loch hat).

Bei iD kann ich mir vorstellen, dass Teil 2 des gesplitteten Ways einfach hinten am Relationsende angehängt oder hinter Teil 1 einsortiert wird. Wer möchte, darf gerne mal Versuche machen und die Erkenntnisse hier posten.

Einen großen Teil der Routen-Fehler, die durch Aufsplitten der Ways entstehen, dürfte man verhindern können, wenn JOSM einfach das Aufsplitten solcher Ways nur erlauben würde, wenn der Vorgänger und Nachfolger in der Routenrelation geladen sind. Eine Fehlermeldung im Stil "Der Way kann nicht geteilt werden, weil er Mitglied einer Relation ist und noch nicht genügend Mitglieder der Relation geladen sind. [fehlende Ways nachladen] [Way nicht aufteilen]" ([Buttonbeschriftung]) dürfte JOSM-Nutzer nicht verstören (die sind ja, um es im iD-Sprech auszudrücken, verstörende Popus gewohnt). Im Falle von iD wäre es egal, wenn der Editor sich schnell im Hintergrund den Vorgänger und Nachfolger von der API holt, da das Onlineeditor ist. (In JOSM braucht man einen Netzwerkverbindung nur zum Down- und Upload)

Nadjita wrote:

Aber davon ab fände ich es schade, wenn man Segmente auf eine noch höhere PT-Version verschieben müsste. Ich habe hier Buslinien, die aus insgesamt 10 Einzelvarianten bestehen mit eigentlich nur einer handvoll Variationen, wenn man Bausteine nehmen würde. Wenn dann jemand einen Baustein beschädigt, müsste man auch nicht gleich alle Relationen fixen, sondern nur den einen Baustein. Aber ohne guten Editor-Support in JOSM sehe ich schwarz für Segment-Bausteine.

Das Wiedereinführen von Segmenten ist halt ein tiefer Eingriff in die Datenstruktur. Wir diskutieren hier erstmal über Version 2.1, die ja möglichst auch noch abwärtskompatibel zu 2.0 sein soll. :-)

Nadjita wrote:

Wie kann man denn mit dem Auftrennen eines Weges eine PTv2-Route kaputt machen?

Die Reihenfolge der Wege in der Relation gibt die Durchfahrrichtung indirekt an. Steht da
Weg A
Weg B
Weg C
dann fährt der Bus erst durch A, dann durch B und dann durch C. Jetzt trennen wir B auf und erhalten die Teile X und Y. Nehmen wir an, dass X das Stück von B ist, dass zuerst durchfahren wurde. Die richtige Reihenfolge ist dann also
Weg A
Weg X
Weg Y
Weg C

Beim Bus in der Gegenrichtung stand da
Weg C
Weg B
Weg A
und jetzt muss da
Weg C
Weg Y
Weg X
Weg A
stehen.

Es muss also einmal das B durch XY und einmal durch YX erstetzt werden.

Das macht der JOSM nur dann richtig, wenn er zum Zeitpunkt des Auftrennens A und C und die Relation schon geladen hatte. Sonst ersetzt er B beide Male durch XY und damit ist eine der beiden Relationen falsch, Scotty muss den Bus zweimal beamen und er fährt in den Daten ein kleines Stückchen von Süd nach Nord statt wie in der Realität von Nord nach Süd.

Das kann man verhindern, wenn man vor jedem Auftrennen ("p") den zu trennenden Weg und seine beiden Endpunkte anwählt und Alt-Ctrl-D macht.

Da das sehr häufig bei großen Straßen (wegen der lanes) passiert und da notorisch auch viele Busse fahren, kann man ganz leicht ein Dutzend Relationen beschädigen ohne was zu merken.

Weide

Nakaner wrote:

Bei iD kann ich mir vorstellen, dass Teil 2 des gesplitteten Ways einfach hinten am Relationsende angehängt oder hinter Teil 1 einsortiert wird. Wer möchte, darf gerne mal Versuche machen und die Erkenntnisse hier posten.

Hab ich gemacht. Der ID hat alles richtig gemacht. Diesen Fehler hab ich bei meinen Reparaturarbeiten auch fast nur im Zusammenhang mit JOSM gefunden.

Weide

Edit: PS: Beim Längssplitten (Fußgängerinseln vor Kreuzungen. Aus einem Weg werden zwei benachbarte Oneways) muss man es in jedem Editor per Hand korrigieren und das geht im ID m.W. einfach nicht.

seawolff wrote:

Konsequent wäre es, nur die Haltestellen zu erfassen und die stupide Arbeit einem Router bei der Auswertung überlassen.

Ein Router kann die Strecke nur raten, reagiert empfindlich auf Baustellen etc. und ist bei teilweise erfassten Routen schlechter als nichts. Da würde ich eher komplett auf den Fahrweg verzichten. Wenn mehrere Mapper mal hier und mal da was beitragen, dann geht das ohne Fahrwege nur ganz schlecht, weil man keinen Überblick über den Erfassungszustand bekommt. Man sieht nicht, ob der Bus an dieser Abbiegung einfach durchfährt oder ob er noch einen Schlenker durch A-Dorf macht und da nur noch keiner Haltestellen erfasst hat.

Weide

Nakaner wrote:

Wir diskutieren hier erstmal über Version 2.1, die ja möglichst auch noch abwärtskompatibel zu 2.0 sein soll. :-)

Sollten wir dann mal für 3 extra was aufmachen?

Weide

Hallo Weide,

Weide wrote:

Nakaner wrote:

Wir diskutieren hier erstmal über Version 2.1, die ja möglichst auch noch abwärtskompatibel zu 2.0 sein soll. :-)

Sollten wir dann mal für 3 extra was aufmachen?

Ja, wir sollten trennen in kleine Änderungen, z.B.
- Wiedereinführung von light_rail (?)
- service=* an Routenrelationen (bei der Bahn zur Unterscheidung der Zuggattungen von S und RB bis ICE)
- Unterstützung mehrerer Plattformen für eine Stop-Position (wenn z.B. der Bahnsteig zur Hälfte gepflastert ist und die andere Hälfte unbefestigt und niedriger)

und große Änderungen, z.B.
- Segemente (ob wir das überhaupt wollen, ist eine andere Frage)
- Idee/Konzepte wie der PTv3-Entwurf von Weide
- spezielle fahrweglose Relationen für Verkehrsmittel, die keinen festen Fahrweg haben (Flächenrufbusse)

Kleine Änderungen sollten Änderungen sein, die nur einen geringen Aufwand für dem Mapper bei der Konvertierung einer Route von v2 nach v2.1 mit sich bringen und für die kein großer Programmieraufwand anfällt bzw. die zu keinen großen Problemen führen, wenn man sie nicht in seiner Auswertung berücksichtigt. Große Änderungen müssen nicht unbedingt abwärtskompatibel sein und können auch für den Mapper einen erhöhten Aufwand bedeuten.

Es wäre also eine gute Idee die großen Änderungen in einem separaten Thread zu diskutieren.

Wer von euch hat eigentlich vor zur FOSSGIS zu kommen? Man könnte sich dort im Rahmen eines BOF treffen.

Viele Grüße

Michael

PS Deine Erklärung, wie man mit JOSM Routen beschädigt, ist richtig gut.

seawolff wrote:

Konsequent wäre es, nur die Haltestellen zu erfassen und die stupide Arbeit einem Router bei der Auswertung überlassen.

Denkbar wäre auch eine Trennung der Relationen in "angefahrene Haltestellen dieser Linie" und "einzelne Streckenverläufe"

Ich quäle mich gerade durch den Buslinien Lüneburgs mit ihren zig Varianten je Streckenverlauf. Dabei empfinde ich als wenig motivierend, dass die Streckenverläufe bei allen OSM-basierten ÖPNV-Anwendungen, die ich kenne, allein bunte Striche in der Landschaft sind. Was ja anderseits auch klar ist, da eine Darstellung "zeige den Streckenverlauf der nächsten Fahrt der Linie 5003 jetzt" oder "zeige mir das befahrene Streckennetz an einem Samstagvormittag" aus den OSM-Daten schon deshalb nicht abstrahierbar wäre, weil eine Tagging-Differenzierung der unterschiedlichen Varianten nicht erfolgt und auch kaum möglich erscheint "course_variant=So, während der NI-Schulferien, Fahrten um 07.16, 09.16 und 18.14".

Andererseits motiviert (mich) die Verknüpfung der Haltestellendaten mit einem Fahrplan, wie sie openptmap macht, sehr. Deshalb dachte ich auch schon mehrfach: "Relationen trennen in Haltestellen und Streckenverlauf".

Ich finde es ebenfalls müßig, jede Linienvariation als eigene Route zu definieren. Aber ist es nicht das, was man zum routen braucht? Ich stelle mir vor, für ganz Deutschland einen Routenplan zu haben, der aber die Strecken nicht wie bei diesem hier als gerade Strecke sondern als richtigen Streckenverlauf auf Basis der OSM Karte darstellt. Die Basisdaten (einschl. Erfassung der Routen) dafür können nur von OSM kommen, die Fahrpläne vom jeweiligen Netzbetreiber. Was geregelt werden müsste, ist dann die regelmäßige Pflege der Routen. DAS ist kurzfristig allerdings nicht zu machen.

seawolff wrote:

Du beschreibst nur eine Seite. Viele Mapper achten darauf, mit ihren Änderungen keinen Schaden an den ÖPNV-Relationen zu verursachen. Die einen passen die Relationen selbst an und brauchen dafür sehr viel Zeit, weil sie ungeübt sind und viel nachlesen müssen, die anderen verzichten darauf, solche Straßen zu bearbeiten. Die Verursacher, also die Ersteller der ÖPNV-Relationen, bekommen von der ganzen Angelegenheit nichts mit, da man den erstellten Changesets die Mehrarbeit nicht ansieht und die nicht erstellten Changesets gar nicht sichtbar sind.

Ja, da stimme ich Dir zu.

Schuld sind weder die Ersteller der Routen, die ja nur Daten erfassen wollen, noch die Leute, die mit dem JOSM Routen beschädigen, die sie oft nicht mal auf dem Bildschirm haben. Deshalb sind Datenstrukturen wichtig, die unempfindlich gegen Splitten sind.

Ein ähnliches (aber seltenes) Problem haben wir übrigens bei Multipolygonen. Auch da kann bei den erlaubten Berührungen der Ränder durch Splitting ein MP beschädigt werden, wenn dabei ein Knoten mit mehreren Verbindungsmöglichkeiten entsteht.

Weide

Swen Wacker wrote:

Dabei empfinde ich als wenig motivierend, dass die Streckenverläufe bei allen OSM-basierten ÖPNV-Anwendungen, die ich kenne, allein bunte Striche in der Landschaft sind.

Früher hatten wir wenigstens noch bunte Striche und bunte Pfeile. Die Pfeile galten für die Streckenstücke, die nur in einer Richtung durchfahren wurden. Ich fand das damals sehr hilfreich -- die Streckenpläne waren so wie sie sein sollten.

Mit der Einführung von PTv2 sind die Pfeile "verstorben":

1.: für die PTv2-Routen ist es schwer rauszukriegen. Man muss quer über alle Varianten anhand des Kontextes analysieren. (Wenn die Route nicht komplett und fehlerfrei ist, kann das richtig kompliziert werden.)

2.: für die PTv1-Routen wurde durch Verwechslung mit PTv2-Eigenschaften der Datenbestand entwertet. Eigentlich sind PTv1-Routen Linienpläne. Es gibt nur eine Relation pro Linie und jede Straße taucht nur einmal auf. Dann musste man nur die Straße in der Relation finden und hatte:
Rolle "forward": Linie mit Pfeil in OSM-Richtung des Wegs
Rolle "backward": Linie mit Pfeil gegen die OSM-Richtung des Wegs
Rolle "": Linie ohne Pfeil (Bus fährt von links nach rechts und von rechts nach links)
Richtige PTv1-Routen sind sehr selten geworden.

Weide

Thoschi wrote:

Ich finde es ebenfalls müßig, jede Linienvariation als eigene Route zu definieren. Aber ist es nicht das, was man zum routen braucht? Ich stelle mir vor, für ganz Deutschland einen Routenplan zu haben, der aber die Strecken nicht wie bei diesem hier als gerade Strecke sondern als richtigen Streckenverlauf auf Basis der OSM Karte darstellt.

Das ist im Grunde PTv1. Eine Straßenliste mit Durchfahrrichtungsergänzungen(den Rollen "forward", "backward" und "" für bidirektional)

PTv2 kam, weil einige Sachen nicht aus dem Streckenplan hervorgehen. Auf dem Plan kann es so aussehen, als ob der Bus von A-Dorf nach B-Dorf fährt. Tatsächlich gibt es aber nur die Varianten "ohne die beiden Dörfer", "über A-Dorf" und "über B-Dorf", aber eben nicht "über beide". Oder etwa Sprungbusse (bin ich in Schweden mal drauf reingefallen), die auf derselben Strecke die meisten Haltestellen auslassen.

Weide

seawolff wrote:

Dazu werden die von vielen Mappen ja ohnehin gewünschten Segmente eingesetzt. (Diese geben gemeinsame Routenstücke von mehreren Varianten an und vermeiden so vielfache Angaben derselben Sache.)

Das wäre schon ein Fortschritt.

Es ging mir aber nicht darum, dass man etwas Arbeit spart weil man auf weniger Relationen Rücksicht nehmen muss. Ich will die ganze Rücksichtnahme-auf-ÖPV-Arbeit beim Splitten beseitigen. Derartige Segmente würden ohne Reihenfolgeinformation funktionieren und daher müsste man beim Splitten keine Rücksicht auf sie nehmen.

Weide

Nakaner wrote:

Ja, wir sollten trennen in kleine Änderungen, z.B.
- Wiedereinführung von light_rail (?)
- service=* an Routenrelationen (bei der Bahn zur Unterscheidung der Zuggattungen von S und RB bis ICE)
- Unterstützung mehrerer Plattformen für eine Stop-Position (wenn z.B. der Bahnsteig zur Hälfte gepflastert ist und die andere Hälfte unbefestigt und niedriger)

und große Änderungen, z.B.
- Segemente (ob wir das überhaupt wollen, ist eine andere Frage)
- Idee/Konzepte wie der PTv3-Entwurf von Weide
- spezielle fahrweglose Relationen für Verkehrsmittel, die keinen festen Fahrweg haben (Flächenrufbusse)

Kleine Änderungen sollten Änderungen sein, die nur einen geringen Aufwand für dem Mapper bei der Konvertierung einer Route von v2 nach v2.1 mit sich bringen und für die kein großer Programmieraufwand anfällt bzw. die zu keinen großen Problemen führen, wenn man sie nicht in seiner Auswertung berücksichtigt. Große Änderungen müssen nicht unbedingt abwärtskompatibel sein und können auch für den Mapper einen erhöhten Aufwand bedeuten.

Es wäre also eine gute Idee die großen Änderungen in einem separaten Thread zu diskutieren.

Ich mache dann mal einen neuen Thread auf "Diskussion über Public transport Version 3"

Weide

Ist das nur für Deutschland/deutschsprächige Gebiete? Sonst wäre es vielleicht besser das auf English zu machen.

Jo

Polyglot wrote:

Ist das nur für Deutschland/deutschsprächige Gebiete? Sonst wäre es vielleicht besser das auf English zu machen.

Wir können uns hier ja auf einen Vorschlag einigen und diesen mit allen Pro- und Kontraargumenten, die im Laufe der Zeit aufgetaucht sind, anschließend international zur Diskussion stellen.

Darf ich mal einen Vorschlag einwerfen?
Ein Attribut für elektronische Anzeigetafeln wäre sehr sinnvoll. Diese sind zunehmend auch bei Bushaltestellen verbreitet und können sehr nützlich sein, vor allem weil dort Verspätungen und Umleitungen erscheinen, die man aus dem Fahrplan (logischerweise) nicht herauslesen kann.

Prince Kassad wrote:

Ein Attribut für elektronische Anzeigetafeln wäre sehr sinnvoll.

+1

http://taginfo.openstreetmap.org/keys/p … lay#values

Prince Kassad wrote:

Darf ich mal einen Vorschlag einwerfen?
Ein Attribut für elektronische Anzeigetafeln wäre sehr sinnvoll. Diese sind zunehmend auch bei Bushaltestellen verbreitet und können sehr nützlich sein, vor allem weil dort Verspätungen und Umleitungen erscheinen, die man aus dem Fahrplan (logischerweise) nicht herauslesen kann.

+1

Das kann problemlos in PTv2.1 aufnehmen, da es 100 % abwärtskompatibel ist. Ich würde es an die Plattform taggen. Welches Tag schlägst du vor?

Nakaner wrote:

Prince Kassad wrote:

Darf ich mal einen Vorschlag einwerfen?
Ein Attribut für elektronische Anzeigetafeln wäre sehr sinnvoll. Diese sind zunehmend auch bei Bushaltestellen verbreitet und können sehr nützlich sein, vor allem weil dort Verspätungen und Umleitungen erscheinen, die man aus dem Fahrplan (logischerweise) nicht herauslesen kann.

+1

Das kann problemlos in PTv2.1 aufnehmen, da es 100 % abwärtskompatibel ist. Ich würde es an die Plattform taggen. Welches Tag schlägst du vor?

Hallo,

ich hab vor kurzem auch nach einem Tag für Anzeigetafeln gesucht und bin auf departures_board="" gestoßen. Dabei hab ich die folgenden Werte benutzt:
- realtime -> Anzeige der Abfahrtszeit in Minuten ("in 1 min" typisch bei Straßenbahnen und Bussen)
- delay -> Anzeige von Verspätungen ("heute ca. 5min später", typisch für kleinere Bahnhöfe und Haltepunkte der DB)
- timetable -> Anzeige der fahrplanmäßigen Abfahrtszeit ("10:00" wenn keine Informationen zu Verspätungen angezeigt werden)
- delay;timetable -> Anzeige sowohl der planmäßigen Abfahrtszeit als auch von Verspätungen (typisch für größere Bahnhöfe)

Ich hab meistens direkt die Stelle, an der die Anzeigetafel steht, getaggt, zusätzlich mit public_transport=departures_board.
Ich denke man könnte hier analog zu bin=yes, shelter=yes, amenity=waste_basket und amenity=shelter vorgehen und es sowohl an den Bahnsteig als auch an die konkrete Position taggen.

Ich wollte das Schema eigentlich schon länger mal dokumentieren, bin aber bisher noch nicht dazugekommen.
Einige so getaggte Anzeigetafeln findet ihr in diesem Bereich.
Die könnte man vielleicht als Basis für eine weitere Diskussion verwenden.

Im Wiki steht es schon länger als passenger_information_display=*

http://wiki.openstreetmap.org/wiki/DE:T … us_stop.29

surveyor54 wrote:

Im Wiki steht es schon länger als passenger_information_display=*

http://wiki.openstreetmap.org/wiki/DE:T … us_stop.29

Da schütteln sich ja nicht nur Muttersprachler.
Das Ding heißt departure board
http://www.collinsdictionary.com/dictio … ture-board

hurdygurdyman wrote:

Das Ding heißt departure board]

Das heißt, dass dieser Hinweis im engl. Wiki upgedated ;-) werden sollte?:

http://wiki.openstreetmap.org/wiki/Tag: … 3Dbus_stop

surveyor54 wrote:

Im Wiki steht es schon länger als passenger_information_display=*

http://wiki.openstreetmap.org/wiki/DE:T … us_stop.29

Toll...da hat sich im Juli 2014 jemand einfach etwas neues ausgedacht. Ich habe seit Januar 2014 "passenger_information_system" genutzt. Vor allem, weil es systemoffen ist und man mehr sinnvolle Kombinationen als nur yes/no hinzufügen kann.

passenger_information_systen:timetable=yes (gedruckter Fahrplan)
passenger_information_system:display_board=yes (elektronische Abfahrtsübersicht)
passenger_information_system:sound=yes (Lautsprecheransagen möglich)
passenger_information_system:personal=yes (persönliche Auskunft)
passenger_information_system:robot=yes (zukünftiges Auskunftssystem per Roboter)
passenger_information_system:electronic_information=yes (einzeiliges Informationssystem z.B. an kleineren Bahnhöfen)
passenger_information_system:departure_board=yes (Mehrzeilige Abfahrtsanzeige an Bahnsteigen)

edit:Vorschlag

Dies ist die Antwort die ich bekam Ende 2010:

https://lists.openstreetmap.org/piperma … 01141.html

Jo

Nadjita wrote:

Wie kann man denn mit dem Auftrennen eines Weges eine PTv2-Route kaputt machen? Auftrennen macht doch nur Abbiegeverbote und destination_signs kaputt. Das Zusammenführen ist in meinen Augen das Problem. Das ist eine der riskantesten Aktionen in OSM (und eine rein kosmetische), wobei die neueren JOSM-Versionen wenigstens mit dem mehrfachen Vorkommen in einer Relation klar kommen. Wie es sich da mit anderen Editoren verhält weiß ich ja nicht.

Aber davon ab fände ich es schade, wenn man Segmente auf eine noch höhere PT-Version verschieben müsste. Ich habe hier Buslinien, die aus insgesamt 10 Einzelvarianten bestehen mit eigentlich nur einer handvoll Variationen, wenn man Bausteine nehmen würde. Wenn dann jemand einen Baustein beschädigt, müsste man auch nicht gleich alle Relationen fixen, sondern nur den einen Baustein. Aber ohne guten Editor-Support in JOSM sehe ich schwarz für Segment-Bausteine.

Völlig einverstanden mit dir,

Jo

Hallo erstmal,
Wie macht ihr das, um die Busrouten für http://overpass-api.de anzupassen? Es gibt hier das Problem, dass die Abfrage der Overpass-API nicht richtig funktioniert, wenn man sowohl eine Platform, als auch eine stop position hat. Somit passt da das Overpass nicht mit dem p_t:v2, oder umgekehrt, zusammen. Gibt es irgend eine Seite, auf der Vorschläge für bessere Formatierungen vorschlagen kann?

~emergency99

Hier geht das richtig und auf manche Stellen mappe ich beide platform und stop_position. Platform aber immer (auf Nodes), stop_position nicht immer. Es sind dann auch die Platform nodes die alle Details enthalten. Das ist in Deutschland und Österreich ganz anders gemacht/evoluiert.

Roland hat viel Hokus Pokus einbauen mussen, um das alles so richtig wie möglich zu interpretieren.

http://www.overpass-api.de/api/sketch-l … =wuppertal

http://www.overpass-api.de/api/sketch-l … yle=DeLijn
http://www.overpass-api.de/api/sketch-l … &style=TEC

Ich habe nämlich die Buslinien in Wien so angepasst (platform immer und mit Linie in Relation/ stop positions gar nicht oder halt ohne relation). Jetzt funktioniert die Abfrage für alle Linien in Wien (1A-99B network=VOR) aber ein andere User stößt sich daran, da der es strikt nach der Wiki machen will (aber so die Overpass-Kompatibilität wieder kaputt macht....) Das Proposal p_t:v2 ist da leider etwas misslich 😐 . Also ist die Formatierung auch Auslegungssache 🙁 . Danke für die Antwort!

emergency99 wrote:

...aber ein andere User stößt sich daran...

Na ja, Du hast ja auch richtig gemappte Informationen gelöscht.

PTv2 sagt dazu ganz klar:

Each␣direction/variant␣relation␣contains␣all␣available␣stop_positions,␣platforms␣and␣ways.

sowie

Each␣stop␣is␣included␣with␣two␣elements␣(if␣available):␣first␣the␣stop_position␣tagged␣with
role␣stop␣and␣immediately␣followed␣by␣the␣corresponding␣platform␣tagged␣with␣role␣platform.
The␣stops␣(stop_positions␣and␣platforms)␣should␣be␣inserted␣beginning␣with␣the␣initial
stop_position/platform␣and␣ending␣with␣the␣terminal␣stop_position/platform.

Die zwischen den Wegen liegende linienförmige Platform (bei der der Name "Stephansplatz" fehlt), müsste auch oben mit eingeordnet werden. Auch die Wege müssten in sich noch geordnet werden.

After␣all␣the␣stops␣all␣the␣used␣ways␣should␣be␣inserted␣into␣the␣relation␣with␣an
empty␣role.␣The␣ways␣should␣be␣inserted␣beginning␣with␣the␣way␣at␣the␣initial␣stop␣position
and␣ending␣with␣the␣way␣at␣the␣terminal␣stop␣position.

Wenn die Overpass-Abfrage das nicht richtig darstellt, dann liegt dort das Problem. Das sollte man nicht in den Daten lösen.

frohes Mappen
Weide

Ich denke halt, dass hier dieses p_t:v2 etwas schlecht gelöst ist. Es gibt eben offiziell bei Buslinien keine fixe Stop-position sondern nur eine Bushaltestelle, bei der man wartet, und manchmal (aber nicht immer) einen etwa 18M langen Haltestellenbereich auf der Straße.... Somit ist das proposal/die Regel für Österreich etwas schlecht gelöst... Ich kann an einer Linie mal versuchen auch Haltepositionen zu verwenden. Wenn es funktioniert ändere ich alle Linien so um. Wenn nicht, dann wird eher das p_t etwas abgeändert werden müssen, un auch die reale Welt widerzuspiegeln...

Ah ja, hier in Belgien gehen die stop_positionen auch nicht in die Route relationen. Die sind auch nicht alle anwesend in die Daten weil die m.E. weniger wichtig sind als die Platform nodes neben die Straßen.
Wenn ich alle 60000+ HS in Belgien gemappt habe, habe ich mich auf die Platforme (eigentlich die Schilder konzentriert).

Wie die stop_position sich zu Platform verhalten kann man finden durch die stop_area Relationen. Eine pro Richtung wie das damals auch mal im Wiki stand, wenn ich mich das angeguckt habe. Mittlerweile ist das angeblich geändert worden in eine stop_area für alle mit demselben Nahmen. Damit komme ich nicht raus.

Die routerelatione möchte ich gerne so einfach wie möglich haben, also public_transport=platform und die Ways.

Jo

Polyglot wrote:

Ah ja, hier in Belgien gehen die stop_positionen auch nicht in die Route relationen. Die sind auch nicht alle anwesend in die Daten weil die m.E. weniger wichtig sind als die Platform nodes neben die Straßen.
Wenn ich alle 60000+ HS in Belgien gemappt habe, habe ich mich auf die Platforme (eigentlich die Schilder konzentriert).

Wie die stop_position sich zu Platform verhalten kann man finden durch die stop_area Relationen. Eine pro Richtung wie das damals auch mal im Wiki stand, wenn ich mich das angeguckt habe. Mittlerweile ist das angeblich geändert worden in eine stop_area für alle mit demselben Nahmen. Damit komme ich nicht raus.

Die routerelatione möchte ich gerne so einfach wie möglich haben, also public_transport=platform und die Ways.

Jo

So wäre es meiner meinung nach auch richtig. Die Wartung soll ja auch leicht sein. Und sich mit stop_positions die auf 2 oder mehr Linien liegen abzumühen ist da eher dumm. Grad wenn die Wieber Linien in Wien gerne mal Haltestellen jedes Jahr verlegen... Da ist das dann immer ein Kampf: Mann gegen Node 😛 . Da ist besser nur die Platforms zu haben...

PS: Ich versuche grad am 33A in Wien den an das p_t 2 Schema, ohne Verlust der Overpass-api.de-Kompatibilität anzupassen. --> WAS NICHT GEHT!

emergency99 wrote:

Somit ist das proposal/die Regel für Österreich etwas schlecht gelöst

PTv2 verlangt ja nicht, dass jede Haltestelle einen stop hat. Wenn der stop nicht sinnvoll ist, dann kann man ihn einfach (nach Diskussion mit den anderen Mappern) löschen. PTv2 verlangt nur, dass ein existierender stop eingetragen wird, es verlangt nirgendwo, dass es ihn gibt.

emergency99 wrote:

...ohne Verlust der Overpass-api.de-Kompatibilität anzupassen. --> WAS NICHT GEHT!

Ja. Das Script für das Overpass-API sollte geändert werden. Es war als PTv2-kompatibel gedacht ... ist es aber nicht. Daher ist es im Moment auch kein Maßstab für richtiges Mappen.

Weide

PS: Eine kleine Ausnahme von der o.g. Regel gibt es allerdings. Wenn zwei direkt nacheinander angefahrende Haltestellen gleichen Namens drin sind, dann kann man nicht bei der ersten nur einen Stop haben und bei der zweiten nur eine Platform. Das würde dann aussehen, als wäre es nur eine Haltestelle. Da muss man entweder beim ersten eine Platform oder beim zweiten einen Stop hinzufügen.

Hallo,

Ich habe eine neue Funktionalität für JOSM vorgeschlagen und Simon hat das implementiert. Jetzt gibt es eine neuen 'Button' im Relation Editor, der alle Members ab die heutige Position sortiert.

Das ist sehr praktisch. Vorher musste ich immer die Members andeuten die ich sortiert haben wollte. Die die schon in die richtige Reihenfolge standen wollte ich nicht mehr vom automatische Sortiervorgang zerstören lassen.

Ich habe noch ein anderer Vorschlag gemacht:

https://josm.openstreetmap.de/ticket/11558

Nicht ganz sicher ob ich das deutlich genug beschrieben habe.

Grüsse,

Polyglot