OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

#1 2014-11-09 19:30:06

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,535
Website

Diskussion über Public Transport Version 2.1

Hallo,

im Thread über die Stadtbahn Heilbronn Nord habe ich es schon anregt, ich lagere es aber mal aus dem Thread hierher aus.

Das Public-Transport-Schema 2 zwar gut ist, aber ihm fehlen ein paar Sachen.

  • Einführung von light_rail für Mischwesen aus Tram und Train. Stadtbahnen, die nach EBO und BOStrab verkehren, sollten dann route=light_rail sein. Diese gibt es in Karlsruhe, Saarbrücken, Kassel, Köln/Bonn (Linien 16 und 18) und vermutlich auch noch anderen Städten. Es ist kartographisch unschön, in ÖPNV-Plänen quer durch die Innenstadt Eisenbahnlinien zu zeichnen, und genauso unschön, die Linien an der Systemgrenze EBO/BOStrab die Farbe wechseln zu lassen, wenn die Liniennnummer gleich bleibt.

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

  • public_transport=station sollte "bevorzugt für Flächen verwendet werden", wie das Proposal schreibt. Ich denke, dass wir dafür aber keine Flächen brauchen. Es gibt die stop_area-Relation, aus der man Flächen berechnen kann (einfach eine konvexe Hülle um die Mitglieder). Es gibt bloß Anlass zum Streiten, wenn man Flächen mappt. Daher spreche ich mich für eine Empfehlung von Nodes aus.

  • public_transport=station soll derzeit nur für wichtige Stationen (Busbahnhöfe, Umsteigebahnhöfe) verwendet werden. Das sollte man ändern. Für das Rendern von Bushaltestellen und Bahnhöfen/Haltepunkten in niedrigen Zoomstufen, ist es jedoch sinnvoller, den Renderern "vorgeneralisierte Daten" bereitzustellen. Das kann in Form eines mittig platzierten Nodes geschehen. Derzeit gibt es nach dem neuen Schema bei Bushaltestellen immer zwei stop_positions (eine pro Richtung), die sich in niedrigen Zoomstufen gegenseitig überdecken. Es gibt aber Fälle, wo zwei unterschiedlich benannte Haltestellen eng beieinander liegen und sich gegenseitig (die Labels) überdecken könnten.

  • Bei Bahnhöfen gibt es schon railway:station_category=<1, …, 7> zur Angabe der Relevanz des Bahnhofs. Das Schema stammt von der Deutschen Bahn, die Daten sind frei (sic!). Das Schema ist international anwendbar.
    So etwas Ähnliches bräuchte man dann auch für Bus- und Tramhaltestellen sowie U-Bahnhöfe. Wie wär's mit public_transport:station_relevance=<Nummer>?

  • ÖPNV-Routen sollten in Segmente (wie bei Wanderwegen, Fahrradrouten usw.) aufsplittbar sein. Das würde das Mappen von mäandrierenden Schulbuslinien erleichtern (Wiederverwendung von Routensegmenten). Straßen/Gleise in Zentren, wo viele Linien zusammenkommen, hätten dann weniger Mitgliedschaften in Routenrelationen (z.B. Stammtstreckentunnels vieler S- und U-Bahnnetze).

  • Zur Kennzeichnung der Relationen sollte public_transport:version=2.1 verwendet werden.

  • Zusätzliche Rollen stop_on_demand, exit_on_demand, entry_on_demand, stop_sometimes, stop_on_demand_sometimes, exit_on_demand_sometimes, entry_on_demand_sometimes für Bedarfshalte (und Bedarfsausstiegsstellen/Bedarfseinstiegsstellen) einführen. Es ist nämlich eine Eigenschaft der verkehrenden Linie, nicht des Haltepunkts, dass dort nur bei Bedarf gehalten wird. (Ich weiß, es gibt dann bei Bahnen oft Haltewunschtaster auf dem Bahnsteig, aber nicht immer)

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

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?

Auf Version 2.2 sollte man meiner Meinung nach mit folgenden Themen noch warten (erst mal alles auf 2.0 oder 2.1 umstellen, bevor man sich auf Nebensächlichkeiten fixiert!):

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

  • nicht alle landesüblichen Klassen. In manchen Privatbahn-Regionalzügen gibt es keine erste Klasse. Im Gegenzug gibt es Züge ohne niedrige Klassen. In  Deutschland hatten TEE-Züge (ja, das ist schon ein Weilchen her) keine 2. Klasse, woanders gibt es bestimmt  noch Luxus- oder Fernzüge ohne 2./3. Klasse. Diese Züge will man vielleicht gar nicht rendern.

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

Ich würde das gerne erstmal hier diskutieren, bevor ich mit einem Proposal auf der Tagging-Mailingliste aufkreuze.

Viele Grüße

Michael


Ein aussagekräftiger Änderungssatzkommentar gehört zum guten Ton.
Moderator im Bereich users: Austria.

Offline

#2 2014-11-10 01:51:36

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: 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)

Last edited by viw (2014-11-10 01:53:56)

Offline

#3 2014-11-10 09:59:42

Polyglot
Member
From: Belgium
Registered: 2011-11-25
Posts: 241

Re: Diskussion über Public Transport Version 2.1

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.

Offline

#4 2014-11-10 10:23:31

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Diskussion über Public Transport Version 2.1

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.

Offline

#5 2014-11-10 13:49:32

Seoman
Member
Registered: 2011-07-14
Posts: 61

Re: Diskussion über Public Transport Version 2.1

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?

Offline

#6 2014-11-10 14:47:20

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,535
Website

Re: Diskussion über Public Transport Version 2.1

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.


Ein aussagekräftiger Änderungssatzkommentar gehört zum guten Ton.
Moderator im Bereich users: Austria.

Offline

#7 2014-11-10 15:05:05

rayquaza
Member
From: DE-BW
Registered: 2012-11-18
Posts: 2,007

Re: Diskussion über Public Transport Version 2.1

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.

Offline

#8 2014-11-10 18:04:24

Weide
Member
Registered: 2009-04-05
Posts: 1,317

Re: Diskussion über Public Transport Version 2.1

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

Offline

#9 2014-11-10 22:21:20

Jedrzej Pelka
Member
Registered: 2013-12-09
Posts: 90

Re: Diskussion über Public Transport Version 2.1

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

Offline

#10 2014-11-11 09:52:41

drolbr_mdv
Member
Registered: 2014-11-11
Posts: 13

Re: Diskussion über Public Transport Version 2.1

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.

Offline

#11 2014-11-11 19:02:49

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Diskussion über Public Transport Version 2.1

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/

Offline

#12 2014-11-11 21:51:13

Thoschi
Member
Registered: 2013-07-19
Posts: 767

Re: Diskussion über Public Transport Version 2.1

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?

Last edited by Thoschi (2014-11-11 21:51:55)

Offline

#13 2014-11-12 06:04:21

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Diskussion über Public Transport Version 2.1

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?

Offline

#14 2014-11-12 09:19:41

drolbr_mdv
Member
Registered: 2014-11-11
Posts: 13

Re: Diskussion über Public Transport Version 2.1

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.

Offline

#15 2014-11-12 15:49:48

Thoschi
Member
Registered: 2013-07-19
Posts: 767

Re: Diskussion über Public Transport Version 2.1

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.

Offline

#16 2014-11-12 15:53:29

Thoschi
Member
Registered: 2013-07-19
Posts: 767

Re: Diskussion über Public Transport Version 2.1

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

Last edited by Thoschi (2014-11-12 15:59:35)

Offline

#17 2014-11-17 11:05:29

Polyglot
Member
From: Belgium
Registered: 2011-11-25
Posts: 241

Re: Diskussion über Public Transport Version 2.1

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

Offline

#18 2014-11-17 11:19:00

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Diskussion über Public Transport Version 2.1

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.

Offline

#19 2014-11-17 11:55:48

seichter
Member
Registered: 2011-05-21
Posts: 2,640

Re: Diskussion über Public Transport Version 2.1

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

Offline

#20 2014-11-17 11:56:24

Polyglot
Member
From: Belgium
Registered: 2011-11-25
Posts: 241

Re: Diskussion über Public Transport Version 2.1

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

Offline

#21 2014-12-16 13:39:49

Weide
Member
Registered: 2009-04-05
Posts: 1,317

Re: Diskussion über Public Transport Version 2.1

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

Offline

#22 2014-12-16 21:35:52

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,535
Website

Re: Diskussion über Public Transport Version 2.1

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.


Ein aussagekräftiger Änderungssatzkommentar gehört zum guten Ton.
Moderator im Bereich users: Austria.

Offline

#23 2014-12-16 23:14:15

Weide
Member
Registered: 2009-04-05
Posts: 1,317

Re: Diskussion über Public Transport Version 2.1

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.

Last edited by Weide (2014-12-16 23:15:18)

Offline

#24 2014-12-16 23:24:24

Weide
Member
Registered: 2009-04-05
Posts: 1,317

Re: Diskussion über Public Transport Version 2.1

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

Offline

#25 2014-12-17 08:05:17

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Diskussion über Public Transport Version 2.1

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.

Offline

Board footer

Powered by FluxBB