You are not logged in.

#1 2015-02-12 10:47:19

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

Diskussion über Public Transport Version 3

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.

Im Topic "Diskussion über Public Transport Version 2.1" haben wir bis etwa Beitrag 143 sowohl Modifikationen an PTv2 als auch größere Änderungen diskutiert. Die größeren Änderungen sollten ab sofort hier diskutiert werden.

Weide

Offline

#2 2015-02-12 10:51:06

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

Re: Diskussion über Public Transport Version 3

Weide wrote:

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.

Ich hab mal in http://wiki.openstreetmap.org/wiki/User … rschlag_P3 versucht, dass konkret zu machen.

Weide

Offline

#3 2015-10-10 07:38:06

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

Re: Diskussion über Public Transport Version 3

Fortsetzung aus den Thread "Public-Transport V2 Platform als Area"

Sven Wacker wrote:

Mir ist aktuell keine Karte oder Anwendung bekannt, die die mit viel Mühe erfassten Routen(varianten) auswertet.

Mir auch nicht.

OSM-Daten werden zur Zeit experimentell in Auskunftssystemen benutzt:
http://efa.vrr.de/vrrstd/XSLT_TRIP_REQU … ompany=vrr

Dabei stammen aber die Start- und Zielpunkte des Fußgängerroutings aus den Datenbanken der Verkehrsunternehmen und von OSM werden nur die Fußwege aber nicht die Routen benutzt. Diese Start- und Zielpunkte müssen noch angepasst werden, denn ein Fehler von wenigen Metern kann den Passagier z.B. auf die andere Seite der Gleise versetzen und von dort aus hat man evtl. einen viel längeren Weg und es wird daher eine Verbindung über eine ganz andere Stadt vorgeschlagen.

Hier werden unsere Routen also nicht gebraucht...

Andererseits will man als Passagier natürlich gern sehen, wo man gerade auf der Strecke ist und ob man überhaupt auf der gewünschten Strecke ist. Die Anzeigen in den Bussen sind erstaunlich oft falsch und man kann ja auch mal unsicher sein, ob man überhaupt im richtigen Bus sitzt. Da wären unsere Routen praktisch, wenn man die Kopplung zu den Fahrplandaten hinbekommt.

Ohne die Routen kann man sowas wie in http://tracker.geops.ch/?z=12&s=1&x=772 … =transport bekommen. Da kann man sehr schön sehen, wie der gesamte Fernverkehr zwischen Köln und Düsseldorf über die Hildener Güterzugstrecke läuft. In der Wirklichkeit fahren die Züge natürlich über die Strecke weiter westlich.

Wenn wir uns aber nur darauf beschränken wollen, Linienpläne graphisch darzustellen (mit Pfeilen, wo es nur eine Richtung gibt), dann sollten wir PTv2 einstampfen, kein PTv3 erfinden und PTv1 in seiner ursprünglichen Art benutzen: das war genau für diesen Zweck konstruiert und es ist einfach. Eine Relation für die gesamte Linie und unempfindlich gegen Editiervorgänge anderer Zwecke. PTv1 wurde erst durch die Vermischung mit PTv2 schlechter und ab da waren die OSM-Linienkarten mit den Pfeilen Geschichte.

Weide

Offline

#4 2015-10-10 09:33:18

Gino-52
Member
Registered: 2015-06-02
Posts: 59

Re: Diskussion über Public Transport Version 3

Hallo,

die Fahrpläne in die Relationen einzupflegen ist gar nicht so schwierig.
Wenn gem. PTv2 alle Varianten einer Linie erfasst sind kann man an der Ralation, ähnlich den open_hours bei Geschäften, die Abfahrszeiten festmachen.
Beispiel: Mo-Fr 08:17,08:54,09:57; Sa 09:00,10:05
oder wenn die Linie im Zeitintervall fährt Mo-Sa 06:05-23:00+15

An den Einträge für die Haltestellen wird dann die Fahrzeit entweder von der vorherigen Haltestelle oder vom Startpunkt aus hinterlegt.
Von der vorherigen Haltestelle macht das Erfassen einfacher, da man im Fahrplan nur die Differenz ziehen muss.
Bei der Fahtzeit vom Startpunkt muss man immer die Differenz von Startzeit zu Abfahrtszeit ermitteln. Ist bestimmt fehleranfälliger.

Ich kenne das Datenbankmodell nicht, aber aus meiner Sicht wäre es auch über die heute vorhande Rolle machbar.
z.B. Rolle Fahrzeit:2   (Zeit in Minuten)
Die Abfahrtsstation bekommt dann Fahrtzeit:0

Über die Addition aller Fahrzeiten ergibt sich dann die Ankunftszeit.

Damit wäre auch ein Reiserouting möglich.

Sind natürlich nur erste Überlegungen. Da gibt es bestimmt noch Details zu berücksichtigen

Gruß
Gino

Offline

#5 2015-10-10 13:45:30

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

Re: Diskussion über Public Transport Version 3

Ich glaube, Netzwolf hatte mal Experimente zu der Idee gemacht. Ich kenne aber keine Resultate.

Wir brauchen aber eigentlich die Rollen als Rollen. Eine Rolle gibt ja eigentlich an, was dieses Element in der Relation soll. Typisches Beispiel ist Abbiegerestriktion: "Dieses Element ist drin, weil es die Richtung angibt aus der man kommt". Entsprechendes haben wir bei PTv2 und in meinem Vorschlag ... da ist dann eigentlich kein Platz mehr für Zusatzdaten. Jemand (Woodpeck?)hatte auch mal an Relationserweiterungen gedacht, so dass man jedem Element auch noch ganze Datensätze zuordnen kann. Ich hab aber etwas Angst vor so mächtigen Instrumenten...

Schöner wäre es aber, wenn wir von der Variante aus Verweise auf die Daten im Internet hätten. Dann bekommen wir auch Verspätungen und Ausfälle mit. Das müsste mit zwei Tags pro Variante machbar sein. So mal ins unreine:
timetable_proto="VRR4711"
timetable_ref="vrr:720O3: :H:j15"
Anhand der Protokollangabe könnte dann ein Kommunikationsplugin gewählt werden und dem wird das ref gegeben, damit er die Variante findet. Oder so ähnlich...

Weide

Last edited by Weide (2015-10-10 13:47:47)

Offline

#6 2015-10-10 15:48:40

Gino-52
Member
Registered: 2015-06-02
Posts: 59

Re: Diskussion über Public Transport Version 3

Dein Vorschlag berücksichtig dann aber nur grössere Städte. Ich glaube nicht, dass es für Buslinien auf dem Lande oder in Kleinstädten Onlinedaten gibt.

Ein Feld für Zusatzdaten bei einer Relationposition würde bestimmt nicht schaden.

Aber für die PTv2 Relation könnte man die Rolle trotzdem verwenden. Keine Ahnung für was stop oder plarform gebraucht wird. Diese Daten sind ja redundant zu dem verbundenen Node.

Zur Not könnte man ja stop:MIN eintragen.

Aber für das Alles muss es ja auch irgendwann mal ein Purposal geben.
Sehr wichtig und hilfreich wäre ja die Einführung der vorgeschlagenen Segmente.

Gruß
Gino

Offline

#7 2015-10-10 17:16:15

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

Re: Diskussion über Public Transport Version 3

Gino-52 wrote:

Keine Ahnung für was stop oder plarform gebraucht wird. Diese Daten sind ja redundant zu dem verbundenen Node.

Zum Einen unterscheidet sich ein Fahrweg von einem Platformway nur durch die Rolle und zum Anderen haben nicht alle Haltestellen die zusätzlichen PTv2-Tags und diese sind auch ausdrücklich nicht erforderlich. Und dann gibt es ja auch noch Fehltaggings...

Bei PTv1 ging sowas. Da hatten wir dann aber bei den Versuchen im Vorfeld von PTv2 im Extremfall lustige Rollen wie "alternate:forward_stop:4:alternate:backward_stop:17" oder "alternate:backward:excursion". Das sind eigentlich Datensätze und nicht Rollen. Nach meiner Erfahrung sind Datenstrukturen rachsüchtig: Wenn man irgendwas reinquetscht, was nicht da rein gehört, dann werden sie irgendwann bissig... :-)

Weide

Offline

#8 2015-10-10 22:51:03

der-martin
Member
Registered: 2014-10-10
Posts: 140

Re: Diskussion über Public Transport Version 3

Weide wrote:
Sven Wacker wrote:

Mir ist aktuell keine Karte oder Anwendung bekannt, die die mit viel Mühe erfassten Routen(varianten) auswertet.

Mir auch nicht.

OSM-Daten werden zur Zeit experimentell in Auskunftssystemen benutzt:
http://efa.vrr.de/vrrstd/XSLT_TRIP_REQU … ompany=vrr

Dabei stammen aber die Start- und Zielpunkte des Fußgängerroutings aus den Datenbanken der Verkehrsunternehmen und von OSM werden nur die Fußwege aber nicht die Routen benutzt.

Weide

Das kann ich zumindest für den Berliner Raum bestätigen. Lediglich das Auskuntssystem der DB AG nutzt eine eigene Karte. Die Auskunftssysteme der BVG, der S-Bahn Berlin GmbH (Tochter der DB AG) und des Verkehrsverbundes VBB nutzen für das Fußgängerrouting die Mapnik-Karte, bei den Standpunkten der jeweiligen Bahnhöfe und Haltestellen nutzen sie jedoch nicht die OSM-Daten.
Das ist für mich aber kein Grund, das Tagging nicht so zu verbssern, dass das Fußgängerrouting verbessert wird, wenn diese Auskunftssysteme irgendwann in der Zukunft vielleicht die vorhandenen OSM-Daten nutzen. Zumal die Wahrscheinlichkeit, dass sie sich zu diesem Schritt entscheiden, meiner Meinung nach entscheidend erhöht wird, wenn sie sehen, dass die OSM-Daten viel präziser auswertbar sind, als ihre eigene Datenbank.

Zu Ginos Vorschlag in # 4: Finde ich gut. Allerdings faällt mir auch gleich ein Detail ein, an dem man noch feilen müsste: Wie kennzeichnet man es, wenn der Zug/der Bus an einem Bahnhof/einer Haltestelle 5 Minuten (oder sonstwieviel) Aufenthalt hat?

Offline

#9 2015-10-11 02:11:46

Augustus Kling
Member
Registered: 2009-05-11
Posts: 119

Re: Diskussion über Public Transport Version 3

Zu Ginos Vorschlag in # 4: Finde ich gut. Allerdings faällt mir auch gleich ein Detail ein, an dem man noch feilen müsste: Wie kennzeichnet man es, wenn der Zug/der Bus an einem Bahnhof/einer Haltestelle 5 Minuten (oder sonstwieviel) Aufenthalt hat?

Man könnte einfach einen Zeitraum in die Rolle schreiben. Das steht etwas ausführlicher in einem Entwurf / Notitzen.

Etwas in die Rolle zu kodieren, ist zwar für die Auswertung nicht besonders praktisch, aber für den Mapper einfach. Zudem wären solche OSM-Daten relativ gut mit dem JOSM-Relationseditor überblickbar.

Darüber hinausgehende Fahrtdaten (Ausfälle, Fahrtgeschwindigkeiten, Tarife, Zugteilungen, …) gehören meiner Meinung nach nicht in OSM weil diese Daten kaum noch Geobezug haben und das Datenmodell von OSM dafür nicht geeignet ist. Hier müssen in OSM eher Referenzen geschaffen werden damit Dritte den Bezug von OSM-Daten und verfügbaren Fachdaten herstellen können (vorstellbar wäre die stop_id aus GTFS in OSM zu pflegen, wenn wir mal annehmen, dass die verwendete stop_id allgemeingültig ist wäre).

Offline

#10 2015-10-11 08:44:53

Osmonav
Member
Registered: 2013-05-19
Posts: 33

Re: Diskussion über Public Transport Version 3

Gino-52 wrote:

Dein Vorschlag berücksichtig dann aber nur grössere Städte. Ich glaube nicht, dass es für Buslinien auf dem Lande oder in Kleinstädten Onlinedaten gibt.

Gino

??

Zumindest in der DB-Auskunft bekomme ich den Busfahrplan bis ins letzte Kuhdorf.

Ich halte aber überhaupt nichts davon, Fahrplandaten in OSM integrieren zu wollen (oder habe ich da was missverstanden?).

1. sind Fahrplandaten keine Geodaten, sondern Zeittabellen
2. wird die Datenbank sinnbefreit aufgebläht
3. werden die Daten kaum jemals vollständig sein
4. veralten die Daten viel schneller als man sie erfassen kann
5. sind die Fahrpläne häufig viel zu kompliziert, mit Zeitintervallen ist es nicht getan

Viel sinnvoller ist es, die bereits vorhandenen Online-Daten mit der OSM-DB in Auswertungen zu verbinden.

Extrem wichtig finde ich es, zu Liniensegmenten zu kommen. Dann besteht eine Linie nur noch aus einem Hinweg und einem Rückweg, die jeweils alle Liniensegmente aller Alternativen der jeweiligen Richtung zusammenfassen.

Die Liniensegmente stelle ich mir als Liste der ways vor, die von den Verkehrsmitteln, z.B. Bus, benutzt werden, im Prinzip wie heute die Linie, aber nur als Teilestücke daraus.

Der Nutzen liegt darin, dass die Segmente viel kürzer sind als jetzt die ganzen Linien und von allen Linien referenziert werden können. Dann hat man auch im Zentrum der Großstadt nur noch ein bis drei Liniensegmente (geradeaus, links/rechts abbiegen) am Way und nicht wie heute 20 und mehr. Das erleichtert das Bearbeiten der Straßen ganz erheblich. Auch das Bearbeiten der Segmente wird viel einfacher als jetzt die Linien. Man braucht auch dann, wenn der Bus von der Bundesstraße nach A-Dorf und wieder zurück fährt, keine doppelten Wege mehr, sondern benutzt einfach 2 Segmente, die dann für Hin- und Rückweg referenzierbar sind. Die Bearbeitung in JOSM wird wesentllich einfacher, die Relation kann sortiert werden und es ist sofort ersichtlich, ob das Segment eine geschlossene Linie abbildet oder irgendwo unterbrochen ist. Außerdem erschlägt man mit dem Erstellen eines Segments gleich alle Buslinien, die den Weg benutzen.

Ich finde es auch sinnbefreit, bei OSM alle Fahrtvarianten abbliden zu wollen. Es reicht völlig, jeden befahrenen Weg durch Segmente zu erfassen und alle Segmente in einer Hin- bzw Rückwegrelation zu referenzieren. Welchen Weg welcher Bus wann fährt, ergibt sich aus den Fahrplandaten, und die zu erfassen ist meiner Meinunng nach Unsinn, s.o.

Wolfgang

Offline

#11 2015-10-11 16:15:39

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

Re: Diskussion über Public Transport Version 3

Osmonav wrote:

Extrem wichtig finde ich es, zu Liniensegmenten zu kommen. Dann besteht eine Linie nur noch aus einem Hinweg und einem Rückweg, die jeweils alle Liniensegmente aller Alternativen der jeweiligen Richtung zusammenfassen.

Von Hin- und Rückweg kann man aus Sicht der Passagiere nicht in allen Fällen reden.

Beispiel: Wenn die Busse folgenden Varianten fahren:
1. ABCDB (eine große Schleife durch den Zielort)
2. ABDCB (genauso, nur anders rum)
3. BCDBA (Umkehrung von 3. aus Sicht des Fahrers)
4. BDCBA (Umkehrung von 1 aus Sicht des Fahrers)

Für manche Verbindungen ist es so wie für den Fahrer. Aber für die Leute, die nur die Schleife am Zielort benutzen, sind 2. und 4. die Umkehrungen von 1. und 3.

Wir brauchen für dieses Konzept aber keine Unterscheidung von Hin- und Rückweg. Wenn wir die Varianten nicht unterscheiden, müssen wir Hin- und Rückweg auch nicht unterscheiden. Da es dann auch nur noch eine Relation pro Buslinie gibt, ist der Bedarf nach Segmenten auch entfallen. Man anderen Worten: PTv1.

Weide

Offline

#12 2015-10-12 07:53:27

Osmonav
Member
Registered: 2013-05-19
Posts: 33

Re: Diskussion über Public Transport Version 3

Weide wrote:

Wir brauchen für dieses Konzept aber keine Unterscheidung von Hin- und Rückweg. Wenn wir die Varianten nicht unterscheiden, müssen wir Hin- und Rückweg auch nicht unterscheiden. Da es dann auch nur noch eine Relation pro Buslinie gibt, ist der Bedarf nach Segmenten auch entfallen. Man anderen Worten: PTv1.

Die Unterscheidung von Hin- und Rückweg kann je nach Einzelfall tatsächlich entfallen, wenn bei kleineren Straßen dieselben ways benutzt werden.

Dagegen halte ich die Segmente für extrem wichtig.

Vorteil 1: Die Konsistenz eines geschlossenen Weges kann im Segment gut kontrolliert werden, Fehler sind sofort offensichtlich. Ob die Segmente aneinander anschließen, muss extra geprüft werden, aber auch dafür kann man eine Funktion schreiben.

Vorteil 2: Die Segmente können von verschiedenen Buslinien, die abschnittsweise die gleiche Straße befahren, referenziert werden. Damit habe ich dann nur noch eine Segment-Relation am way und nicht 20 Routen, wie es in manchen Innenstädten der Fall ist.

Vorteil 3: Die Segmente sind wesentlich kürzer und können leichter bearbeitet werden.

Die Arbeit für den Mapper, der den way als solches anfassen muss, wird damit entscheidend vereinfacht und die Einstiegshürde für OSM wird etwas gesenkt.

Also gerade nicht PTv1, das ist mit den zerrissenen Wegen, dem ständigen forward/backward und der Vielzahl der Routen am way ein einziger Alptraum, ebenso wie die Vielzahl der Routen am way in PTv2.

Wolfgang

Offline

#13 2015-10-12 08:46:58

Swen Wacker
Member
From: Lüneburg
Registered: 2014-07-25
Posts: 339

Re: Diskussion über Public Transport Version 3

Zur Klarstellung: Reden wir von Segmenten als zusätzliches Daten-Grundelement (das es bis Oktober 2007 schon mal gab). Oder verstehen wir unter Segmenten (normale) Relationen, die Teilstücke des Fahrweges beschreiben?

Wenn es ein zusätzliches Daten-Grundelement sein soll: Wie wahrscheinlich ist es, dass das eingeführt wird? Gibt es andere Anwendungsfälle, in denen Segmente "vermisst" werden?

Unabhängig davon: Gäbe es Sinn, dass mal "face to face" zu diskutieren, am besten auch mit Vertretern derjenigen, die diese OSM-Datenstruktur nutzen wollen (Fa. Mentz und andere). Zum Beispiel auf dem kommenden FOSSGIS Hacking Event.

Offline

#14 2015-10-12 12:27:23

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

Re: Diskussion über Public Transport Version 3

Osmonav wrote:

Damit habe ich dann nur noch eine Segment-Relation am way...

Ich kann mir nicht vorstellen, dass die Routen mit solchen Minisegmenten dann noch lesbar und pflegbar sind.

Die Arbeit für den Mapper, der den way als solches anfassen muss, wird damit entscheidend vereinfacht...

Ich denke, man kann unabhängig von der Anzahl der Relationen dafür sorgen, dass im Normalfall gar keine Arbeit mit den Relationen entsteht. Das hab ich jedenfalls in meinem Vorschlag zu erreichen versucht.

Also gerade nicht PTv1, das ist mit den zerrissenen Wegen, dem ständigen forward/backward...

Wenn wir in einer Gesamtrelation auch noch das "''/forward/backward" streichen, dann kann man nicht einmal mehr eine Linienkarte mit Pfeilen erstellen. Dann kann man die Routen besser ganz streichen.

Also gerade nicht PTv1 ... Vielzahl der Routen am way ein einziger Alptraum, ebenso wie die Vielzahl der Routen am way in PTv2.

Bist Du Dir sicher, dass Du PTv1 wirklich meinst? In PTv1 hat man eine einzige Route für die gesamte Buslinie und jeder Weg kommt da nur einmal vor! Das ist nichts im Vergleich zu PTv2. (Es gibt allerdings viele fehlerhaft gemappte)


Weide

Offline

#15 2015-10-12 12:32:55

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

Re: Diskussion über Public Transport Version 3

Swen Wacker wrote:

Zur Klarstellung: ... Oder verstehen wir unter Segmenten (normale) Relationen, die Teilstücke des Fahrweges beschreiben?

Die meine ich.

Unabhängig davon: Gäbe es Sinn, dass mal "face to face" zu diskutieren, am besten auch mit Vertretern derjenigen, die diese OSM-Datenstruktur nutzen wollen (Fa. Mentz und andere).

Die Verkehrsunternehmen und Mentz DV haben zur Zeit und m.W. auch in Zukunft mit den OSM-Routen nichts vor. Die Mitarbeiter bei Mentz DV editieren Routen nur deshalb, weil sie beim Editieren der Haltestellen angepasst werden müssen.

Weide

Offline

#16 2015-10-12 14:39:55

Swen Wacker
Member
From: Lüneburg
Registered: 2014-07-25
Posts: 339

Re: Diskussion über Public Transport Version 3

Weide wrote:

Die Verkehrsunternehmen und Mentz DV haben zur Zeit und m.W. auch in Zukunft mit den OSM-Routen nichts vor. Die Mitarbeiter bei Mentz DV editieren Routen nur deshalb, weil sie beim Editieren der Haltestellen angepasst werden müssen.

Und wer könnte denn mal was mit Routen vorhaben?

Ich bin sehr pragmatisch eingestellt und schätze es, wenn mein Aufwand einem gefühlten Nutzen gegenübersteht. Routen wären für mich gefühlt die Kür. Innerstädtische Haltestellen (also überwiegend Bus- oder Straßenbahnhaltestellen) einheitlich zu mappen und die diversen Schemata abzulösen scheint mir demgegenüber das naheliegende Pflichtprogramm zu sein - und vom Aufwand her schon gigantisch genug.

Offline

#17 2015-10-12 17:28:31

seawolff
Member
From: Kiel
Registered: 2008-08-29
Posts: 436

Re: Diskussion über Public Transport Version 3

Moin,

bevor wir Details neuer Datenstrukturen entwerfen, sollten wir überlegen, was das Ziel der Public Transport Daten in OSM ist.
Insbesondere bei den Buslinien liegt vieles im Argen:

- die Daten sind unvollständig; in manchen Kleinstädten ist keine Buslinie erfasst, weder lokal, noch regional, noch Fernbus
- die Daten sind als PTv1 oder PTv2 oder in undokumentierten Mischformen erfasst
- die vorhandenen Daten werden selten gepflegt, es gibt zum Teil Lücken, zum Teil Datenfehler
- Linien mit vielen Varianten können nicht praktikabel erfasst werden
- nur wenige Mapper sind bei Buslinien aktiv
- Straßen mit vielen Buslinien können von vielen Mappern nicht editiert werden ohne die Buslinien kaputt zu machen

Der einzig erkennbare Nutzen ist bislang eine sehr unvollständige und teilweise fehlerhafte Linienkarte.

Ein sinnvolles Fußgänger-ÖPNV Routing würde die vollständigen Fahrplandaten in allen Linienvarianten erfordern.
Das ist mit unseren Mitten nicht möglich, wie schon Osmonav geschrieben hat.
Mittelfristig werden sich ohnehin Onlinedienste zu diesem Zweck durchsetzen, da sich mobile Datenverbindungen verbreiten und
Onlinedienste auch kurzfristige Fahrplanänderungen und teilweise aktuelle Verspätungen berücksichtigen können.

Eine Ausnahme der Betrachtungen zu Fahrplandaten sind Fähren, die zwischen zwei Anlegern pendeln.
Dort sind Fahrzeit, Takt und Betriebszeiten recht leicht zu erfassen und stellen eine Hilfe für das Routing dar.

Die von Weide vorgeschlagene Linienerfassung über Segmente würde es vereinfachen, Straßen zu editieren, da nur eine Relation angepasst werden muss.
Andererseits würde eine weitere Abstraktionsebene (Linie - Variante - Segment - Way) den Einstieg in das Thema erschweren.
Wenn diese Variante zusätzlich zu den bestehenden Schemata eingeführt wird, müssten Mapper und Datennutzer noch mehr Regeln lernen.
Eine Verbesserung würde dieser Vorschlag nur ergeben, wenn er die alten Varianten ersetzt. Aber ist das realistisch?

Mehr aktive Mapper und somit bessere Daten kann man m.E. nur gewinnen, wenn man die Datenstrukturen einfach hält.
Eine Linienerfassung als geordnete Liste der Haltestellen ohne Streckenelemente wäre einfach und für jeden verständlich.
Defekte Relationen wären fast ausgeschlossen. Mapper, die Straßen bearbeiten, müssen sich nicht mehr mit Buslinien beschäftigen.
Eine Linienkarte müsste man dann allerdings mit Hilfe eines Routers erstellen. An wenigen, mehrdeutigen Streckenabschnitten wären Zusatzdaten nötig.

Eine radikale Vereinfachung wäre der Verzicht auf Buslinien in OSM.
Man könnte dann zu jeder Haltestelle die Liniennummern (mit Angabe des Verkehrverbunds) erfassen und dies als Schnittstelle zu anderen Diensten nutzen.
Linienkarte wären dann allerdings nur mit Daten Dritter zu erstellen.

Offline

#18 2015-10-12 19:11:14

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

Re: Diskussion über Public Transport Version 3

seawolff wrote:

Mehr aktive Mapper und somit bessere Daten kann man m.E. nur gewinnen, wenn man die Datenstrukturen einfach hält.
Eine Linienerfassung als geordnete Liste der Haltestellen ohne Streckenelemente wäre einfach und für jeden verständlich.
Defekte Relationen wären fast ausgeschlossen. Mapper, die Straßen bearbeiten, müssen sich nicht mehr mit Buslinien beschäftigen.
Eine Linienkarte müsste man dann allerdings mit Hilfe eines Routers erstellen. An wenigen, mehrdeutigen Streckenabschnitten wären Zusatzdaten nötig.

Eine radikale Vereinfachung wäre der Verzicht auf Buslinien in OSM.
Man könnte dann zu jeder Haltestelle die Liniennummern (mit Angabe des Verkehrverbunds) erfassen und dies als Schnittstelle zu anderen Diensten nutzen.
Linienkarte wären dann allerdings nur mit Daten Dritter zu erstellen.

Oder gar nicht mehr. Denn das Routing über OSM netze ist auch nicht ganz trivial.

Ich denke es gibt nicht umsonst Liniennetzpläne. Damit kann man sich wunderbar orientieren. Warum sollten wir in OSM darauf verzichten. Und weil wir die Daten erfassen, können wir noch mehr als einen Liniennetzplan anbieten. Nämlich die Information welche Haltestelle mit welcher ohne Umsteigen verbunden ist.

Offline

#19 2015-10-12 22:50:02

Osmonav
Member
Registered: 2013-05-19
Posts: 33

Re: Diskussion über Public Transport Version 3

Weide wrote:

Ich kann mir nicht vorstellen, dass die Routen mit solchen Minisegmenten dann noch lesbar und pflegbar sind.

Das sehe ich als lösbare Aufgabe für die Editoren, vor allem Josm. Wenn ich in der Routenrelation ein Segment anklicke, sollte es möglich sein, die zu dem Segment gehörigen Ways zu highlighten. Im Gegenteil, kleinere Segmente sind wesentlich übersichtlicher. Das einzige Problem liegt in den Schnittstellen der Segmente. Aber auch das ist anhand der Nodes an den Schnittstellen, die in beiden Segmenten gleich vorhanden sein müssen, lösbar.

Weide wrote:

Ich denke, man kann unabhängig von der Anzahl der Relationen dafür sorgen, dass im Normalfall gar keine Arbeit mit den Relationen entsteht. Das hab ich jedenfalls in meinem Vorschlag zu erreichen versucht.

Dann hast du noch nie in einer Großstadt eine Straße angefasst. Stichwort z.B. bauliche Trennung, Kreisverkehr etc. Wenn du da 20 Relationen anfassen musst (in jeder Relation muss erst einmal die Stelle gesucht werden, an der geändert wird), nur weil du einen Weg auftrennen musstest (auftrennen im Sinne von Gegenverkehr, z.B. wegen Mittelstreifen - aber auch das Gegenteil, Gegenverkehrswege zusammenfassen, weil jede bauliche Trennung fehlt), wirst du schnell den Vorteil einer einzigen Relation kennenlernen.

Weide wrote:

Wenn wir in einer Gesamtrelation auch noch das "''/forward/backward" streichen, dann kann man nicht einmal mehr eine Linienkarte mit Pfeilen erstellen. Dann kann man die Routen besser ganz streichen.

Ich gehe mal davon aus, du meinst mit der "Linienkarte mit Pfeilen" kein Linienschema, sondern die Landkarte mit eingezeichneten Buslinien. Du selbst hast geschrieben, dass man auf die Unterscheidung Hin/Rückweg verzichten kann, wenn der Bus denselben Weg zweimal benutzt, etwa um von der B xx nach A-Dorf und zurück zu fahren. Eine "Linienkarte ohne Pfeile" ist auf jeden Fall machbar. Ob wir unbedingt eine Karte "mit Pfeilen" aus nur unseren Daten erstellen können wollen, müssen wir überlegen. Möglicherweise könnte die forward/backward/both-Rule ja auch in der Routenrelation an das Member-Segment gesetzt werden. Das Segment zählt die betreffenden ways in der befahrenen Reihenfolge auf, bzw. in der Gegenrichtung, wenn es mit der Role "backward" eingetragen würde. Damit ergibt sich die Richtung, in der der way befahren wird, aus der Reihenfolge im Segment. Zugegeben etwas mehr Aufwand bei der Auswertung, aber viel einfacher für den Mapper. Die Richtung der einzelnen ways spielt dann keine Rolle mehr.

Weide wrote:

Bist Du Dir sicher, dass Du PTv1 wirklich meinst? In PTv1 hat man eine einzige Route für die gesamte Buslinie und jeder Weg kommt da nur einmal vor! Das ist nichts im Vergleich zu PTv2. (Es gibt allerdings viele fehlerhaft gemappte)

Es ist richtig, dass in PTv1 jeder Weg nur einmal in der Route drin ist. Aber weil die ways für die Fahrtrichtungen teilweise aufgesplittet sind und teilweise nicht, ist es nicht mehr möglich, den Weg zu überblicken, ganz abgesehen von Sonderwegen für einzelne Fahrten. In Segmenten könnte man die JOSM-Sortierfunktion benutzen, danach müssen alle Wege im Segment eine zusammenhängende Kette bilden. Was fehlt, ist die Kontrolle, ob die Śegmente selbst zusammenhängen, s.o. Ich empfehle hier als Beispiele die Buslinien 31 oder 39 in Hamburg. Das ist in PTv1 einfach nur gruselig.

Sven Wacker wrote:

Zur Klarstellung: Reden wir von Segmenten als zusätzliches Daten-Grundelement (das es bis Oktober 2007 schon mal gab). Oder verstehen wir unter Segmenten (normale) Relationen, die Teilstücke des Fahrweges beschreiben?

Auf jeden Fall "normale" Relationen, die Teilstücke der Fahrwege aller hier verkehrenden Buslinien beschreiben.

Sven Wacker wrote:

Und wer könnte denn mal was mit Routen vorhaben?

Die Routen werden zumindest in den sich mit ÖPNV befassenden Karten dargestellt. Einzelne Fahrtvarianten darzustellen, wäre eine Aufgabe, die zusätzlich die Daten der Fahrpläne auswerten müsste.

Eine ausschließliche Erfassung der Haltestellen, wie Seawolf sie vorschlägt, wäre zwar denkbar, aber es wäre schade, wenn die bedienten Straßenabschnitte nicht mehr eindeutig darstellbar wären. Sicher haben wir im Moment noch Lücken und kommen mit der Aktualisierung den ständigen Linienänderungen kaum noch nach. Das liegt aber vor allem an den unhandlichen Relationen in PTv1 und PTv2.

Den Vorschlag von Sven Wacker, einmal "face to face" zu diskutieren, halte ich für sehr sinnvoll.

Wolfgang

Offline

#20 2015-10-13 07:51:02

geri-oc
Member
From: Sachsen
Registered: 2011-03-21
Posts: 5,055
Website

Re: Diskussion über Public Transport Version 3

Ich würde hier aber eine "Vereinfachung" für unbedarfte Mapper vorschlagen:

Eine Haltestelle ist für jeden zu erkennen. Damit der Name, die Linie und der Operator. Wenn man diesen Node neben die Fahrbahn an die richtige Stelle platziert ist auch die Fahrtrichtung ablesbar. Weitere Angaben Bank, Schutz, Papierkorb kann auch einfach erfolgen. Man könnte sogar ein Bild verlinken.

Nun müsste ein "Relationserfahrener" nur noch eine Relation erstellen und die Straßenabschnitte dazwischen einfügen - eventuell über den Fahrplan.

So können einfache Dinge mit Erweiterungen zu nützlichen Sachen werden. (Ich selbst tue mich auch mit den ÖPVN schwer:
- nimmt mann das alte oder das neue?
- warum meckert JOSM wenn die Haltestelle neben einem hw liegt?
- muss ein Bahnsteig in den Fußweg eingebunden, darübergelegt oder nur verbunden werden?

Um Dresden hat mal jemand einige notes zu fehlenden Bushaltestellen oder Linien gesetzt. Ich ändere so etwas nur, wenn ich vor Ort bin, nach meinem Wissen.

Offline

#21 2015-10-13 08:04:24

Chrysopras
Member
From: Baden-Württemberg
Registered: 2015-04-01
Posts: 1,595

Re: Diskussion über Public Transport Version 3

Osmonav wrote:

Sicher haben wir im Moment noch Lücken und kommen mit der Aktualisierung den ständigen Linienänderungen kaum noch nach. Das liegt aber vor allem an den unhandlichen Relationen in PTv1 und PTv2.

Ehm ... ohne eure Diskussion stören zu wollen, möchte ich als PT-unbedarfter Mapper hier fragen: liegt es nicht vielleicht auch einfach daran, dass schon PTv1, erst recht PTv2 zumindest auf den ersten Blick recht abschreckend wirken, sodass einfach nicht genug Mapper mitarbeiten? Ich muss gestehen, dass ich bis heute einfach vor der Mühe zurückgeschreckt bin, die das Einarbeiten in PTv* zu erfordern scheint ... auch wenn beides auf den 2. Blick wahrscheinlich gar nicht so schlimm und gut durchdacht sein mag.

Segmente mögen eine tolle Idee sein. Aber wenn sie eine weitere Zwischenebene zwischen Straßen und Routen-Relationen schaffen (? so liest sich das jedenfalls bisher für mich Ignoranten), dann wird man ihre Benutzung und v.a. ihren Nutzen sehr gut erklären müssen, damit PT nicht noch abschreckender wird.

seawolff wrote:

Mehr aktive Mapper und somit bessere Daten kann man m.E. nur gewinnen, wenn man die Datenstrukturen einfach hält.

Jep; nämlich jedenfalls nicht noch komplexer als PTv2, sonst wird die Pflege der Buslinien etc. auf ewig einer erhabenen Minderheit vorbehalten bleiben. smile

Last edited by Chrysopras (2015-10-13 08:06:24)

Offline

#22 2015-10-13 08:04:52

GeorgFausB
Member
From: Probstei, Schleswig-Holstein
Registered: 2008-10-14
Posts: 1,859

Re: Diskussion über Public Transport Version 3

Moin,

Osmonav wrote:

Dann hast du noch nie in einer Großstadt eine Straße angefasst. Stichwort z.B. bauliche Trennung, Kreisverkehr etc. Wenn du da 20 Relationen anfassen musst [...], wirst du schnell den Vorteil einer einzigen Relation kennenlernen.

nichts für ungut, aber der Bearbeitungsaufwand solcher Fälle ist in JOSM unabhängig von der Anzahl der Relationen:

Kreisverkehr:
1. Trennen aller Wege an neuen Punkten ein Stück vom Kreuzungspunkt entfernt.
2. Aüflösen der Kreuzung in einzelne Mini-Wegstücke.
3. Verbinden aller Miniwege zu einem einzigen Wegstück, Anpassen der Länge(Durchmesser) und Erstellen eines Kreises.
4. Einbau des Kreisverkehrs in die Wege.

Zusammenführen von getrennten Fahrbahnen:
1. Trennen der getrennten Fahrbahnen jeweils am Ende des oneway (WICHTIG: Nicht am Anfang des oneway!).
2. Verbinden der getrennten Fahrbahnen zu einem einzigen Wegstück.
3. Anpassen der Länge/Führung des Wegstücks und der Eigenschaften (oneway etc.).

Hintergrund:
Durch das Verbinden der vormals getrennten Wegstücke zu einem einzigen Wegstück werden alle beteiligten Relationen über dieses Wegstück geführt, die Reihenfolge der Wege bleibt auch erhalten.

Gruß
Georg

Offline

#23 2015-10-13 16:38:46

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

Re: Diskussion über Public Transport Version 3

Osmonav wrote:

Dann hast du noch nie in einer Großstadt eine Straße angefasst.

Wenn du da 20 Relationen anfassen musst ... wirst du schnell den Vorteil einer einzigen Relation kennenlernen.

Das ist jetzt ein Witz, oder?

...(in jeder Relation muss erst einmal die Stelle gesucht werden, an der geändert wird)...

Markier den betroffenen Weg bzw. die betroffenen Wege und mach dann die 20 Relationseditoren auf und editier erst danach weiter.

Damit ergibt sich die Richtung, in der der way befahren wird, aus der Reihenfolge im Segment.

Die Routen in PTv2 haben ebenfalls diese Eigenschaft. Genau diese Eigenschaft sorgt für eine enorme Empfindlichkeit der Strukturen gegen Editiervorgänge an Straßen. Schätzungsweise über 90% der versehentlichen Zerstörungen an PTv2-Routen kommen daher. (Meist mit JOSM und nicht selten von erfahrenen Mappern.) Meine Konsequenz ist, dass das nicht an diesen Mappern liegt sondern an der zu empfindlichen Datenstruktur. Wir sollten uns bei Fahrwegen nicht mehr auf die Reihenfolge von Ways in Relationen stützen. Entsprechend habe ich in meinem Vorschlag die Segmente anders konstruiert. Ohne Bedeutung der Wegreihenfolge im Segment und mit Bedeutung der Segmentreihenfolge in der Route. Damit ist das Ganze völlig unempfindlich gegen die meisten Auftrennvorgänge (die JOSM "p"-Trennungen). Bei den von Dir angesprochenen Längsauftrennungen sind (glaube ich) bei meiner Segmentart alle Fehler automatisch erkennbar und müssten eigentlich sogar meist automatisch zu beseitigen sein (hab ich noch nicht genau geprüft).

Du selbst hast geschrieben, dass man auf die Unterscheidung Hin/Rückweg verzichten kann, wenn der Bus denselben Weg zweimal benutzt, etwa um von der B xx nach A-Dorf und zurück zu fahren.

Nein, das hab ich nicht geschrieben und auch nicht gemeint. Ich habe geschrieben, dass man beim Verzicht auf Varianten auch auf getrennte Relationen für Hin- und Rückweg verzichten sollte, weil Wegstücke derselben Richtung in einer Variante zum Hinweg und in der anderen zum Rückweg gehören können. Die "forward"/"backward"-Angaben an Wegen haben übrigens nichts damit zu tun, ob der Bus den Weg sowohl auf dem Hinweg als auch auf dem Rückweg benutzt -- sie beziehen sich nur auf die Richtung des Weges und nicht auf die Richtung der Tour.

Weide

Offline

#24 2015-10-13 17:06:49

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

Re: Diskussion über Public Transport Version 3

geri-oc wrote:

...tue mich auch mit den ÖPVN schwer:
- nimmt mann das alte oder das neue?
- warum meckert JOSM wenn die Haltestelle neben einem hw liegt?
- muss ein Bahnsteig in den Fußweg eingebunden, darübergelegt oder nur verbunden werden?

zu 1:
Bei den Routen: das Neue (Nicht mit dem alten vermischt. Die beiden sind inkompatibel. Schreib von Anfang an das public_transport:version=2 mit rein, das verbesser den Support im JOSM)
Bei den Haltestellen: Die alten sind mit PTv1 und PTv2 kompatibel. Bei Bedarf ergänzt mit neuen Tags. Die alten Haltestellen sind aber immer nur Nodes. Wenn Dir ein Node reicht, dann mach den Namen und ein highway=bus_stop rein - fertig. Vielleicht noch shelter, tactile_paving und bench angeben.

zu 2: Meine Glaskugel meint: Hast Du public_transport=stop_position reingeschrieben? Die ist immer ein Node des Fahrweges -- egal wo sie geographisch tatsächlich liegt. Die andere Glaskugel sagt: JOSM meckert gern, wenn man rein alt getaggte Haltestellen in neuen Routen verwendet. Da hat JOSM unrecht: In PTv2 steht:

This proposal does not replace, deprecate or obsolete the already existing and well known tags.
The usage of the proposed tags is recommended but not mandatory.

http://wiki.openstreetmap.org/w/index.p … did=625726

zu 3: Da habe ich unterschiedliche Meinungen gehört. Das Fußgängerrouting sollte jedenfalls funktionieren. Der Streit geht glaube ich darum, ob man für einen kleinen Abstand einen Weg braucht oder nicht. Vielleicht können die Routingexperten was dazu sagen...

Weide

Offline

#25 2015-10-13 17:18:40

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

Re: Diskussion über Public Transport Version 3

Chrysopras wrote:

Segmente mögen eine tolle Idee sein. Aber wenn sie eine weitere Zwischenebene zwischen Straßen und Routen-Relationen schaffen (? so liest sich das jedenfalls bisher für mich Ignoranten), dann wird man ihre Benutzung und v.a. ihren Nutzen sehr gut erklären müssen, damit PT nicht noch abschreckender wird.

Aus dem Grund war ich bis vor ein paar Monaten auch gegen Segmente. Aber wenn man damit die Strukturen unempfindlich gegen Editierarbeiten an den Straßen bekommt und deutlich bessere Unterstützung im Editor bekommt, dann lohnt sich das Ganze m.E. Was man mit den von mir vorgeschlagenen zwei Segmentarten allerdings nicht bekommt ist eine Garantie, dass es pro Straße nur ein Segment gibt. Viel weniger: ja; eine: nein.

Weide

Offline

Board footer

Powered by FluxBB