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

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

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

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

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

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

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?

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

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

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

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

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.

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

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

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.

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.

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.

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

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.

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

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

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

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

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

geri-oc wrote:

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.

Ich hab in meinem Vorschlag nichts zu den Haltestellen vorgeschlagen. Das ist ne ganze Menge! :-)

Es besagt nämlich, dass das Haltestellenmapping sich nach den örtlich vorhandenen Sachen richten soll und nicht nach dem Bedarf der "Routenheinis". Jedes neues ÖPNV-Schema sollte m.E. so konstruiert werden, dass das vor-Ort-Mapping ohne Routenkenntnisse möglich ist.

Beispiel aus PTv2 für das, was ein Schema nicht vom Haltestellenmapping verlangen sollte:
PTv2 kann nur eine Platform pro Halt. Sobald jemand am Bahnhof Voerde/Ndrrh. die Brücke in der Mitte des Bahnsteigs mappt haben wir da drei Bahnsteige und nur einer kann in die Route. Das ändert das Fußgängerrouting für Umsteiger.

Weide

Moin!

GeorgFausB wrote:

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

Das Verfahren ist gut, aber es setzt voraus, dass man
- josm benutzt
- diese Technik beherrscht
- alle Relationen als PTv2 vorliegen
Bei PTv1 kann josm Rollen wie "backward" und "forward:alternate:2" nicht sinnvoll zusammenfügen.
Die übrigen 99% der Mapper haben größere Probleme.

Beim Trennen von Fahrbahnen gibt es ohnehin keinen schnellen Weg.

Deshalb behindern ÖPNV-Relationen immer auch die Mapper, die sich dafür nicht interessieren.

GeorgFausB wrote:

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.

Es stimmt schon, dass einem der Relationseditor von JOSM viel Arbeit beim Auftrennen und Zusammenfügen von ways abnimmt.
Das stimmt aber leider nicht mehr, wenn in allen Routen ein Straßenstück durch ein anderes ersetzt werden muss, z.B. bei anderer Straßenführung. Da muss ich jede Relation einzeln anfassen und da kommt in den Innenstädten leicht ein Dutzend zusammen.

Es gibt übrigens seit 2011 ein Proposal Route_Segments für Segmente von Relationen.

Problem damals wie wohl auch heute noch ist aber, dass viele (auch QS-)Werkzeuge mit geschachtelten Relationen nicht zurecht kommen.
Für nicht Informatik-affine Mapper (one information at one place) mag dasselbe gelten.

Das Proposal ist in etwa das was ich mir unter Segmenten für Relationen vorstelle.

Ein Segment, bestehend aus ways, sollte in jede Relation eingefügt werden können. Also z.B. eine bestimmte Strecke von A nach B, in eine Buslinien-Relation, in eine Relation für Bundes-, Land- oder Kreisstraße oder in eine beliebige andere Route (z.B. Deutscher Schnapsdrosselweg).

Für das PTv2 oder PTv3 Thema könnte dann ja nach gleicher Schema ein Bus-Stop und Platform Segment erstellt werden und dies ebenfalls an entsprechender Stelle in die Relation eingefügt werden.

Das Argument ein Vorschlag nicht weiter zu verfolgen, nur weil die aktuellen Werkzeuge dies nicht können kann kein Argument sein.

JOSM konnte am Anfang bestimmt auch noch kein PTv2.

Es muss doch erst mal einen abgestimmten und akzeptierten Vorschlag geben. Dann können die Werkzeuge angepasst werden. Und dann kann es los gehen.
Eigentlich die gleiche Vorgehensweise wie bei jedem IT-Projekt.

Gruß
Gino

Gino-52 wrote:

Das Proposal ist in etwa das was ich mir unter Segmenten für Relationen vorstelle.

Ein Segment, bestehend aus ways, sollte in jede Relation eingefügt werden können. Also z.B. eine bestimmte Strecke von A nach B, in eine Buslinien-Relation, in eine Relation für Bundes-, Land- oder Kreisstraße oder in eine beliebige andere Route (z.B. Deutscher Schnapsdrosselweg).

Also wenn du so weit gehst, dass Segmente wieder so klein werden, dass sie in beliebige Routen eingefügt werden können, dann kann man auch gleich die Punkte in die Relation aufnehmen. Denn Wege, sind nur Relationen aus Punkten.

seichter wrote:

Es gibt übrigens seit 2011 ein Proposal Route_Segments für Segmente von Relationen.

Ich lese in dem Proposals nur die "Erlaubnis", Routen-Relationen in Routen-Relationen zu schachteln. Das einzelne "Segment" wäre ebenso störanfällig wie jede andere Relation - weil das Segment nichts anderes als eine Relation ist.

Ich lese in dem Proposals nur die "Erlaubnis", Routen-Relationen in Routen-Relationen zu schachteln. Das einzelne "Segment" wäre ebenso störanfällig wie jede andere Relation - weil das Segment nichts anderes als eine Relation ist.

Wenn Du mit "Relation" "PTv2-Routenrelation" meinst bin ich einverstanden.

Wir könnten aber Segmente definieren, die nicht störanfällig sind:

1.: keine Selbstberührung oder Selbstkreuzung
2.: Anfangs- und Endpunkt werden als Element mit aufgenommen ("from", "to")
3.: Löcher dürfen nicht im Segment sein.
4.: Die Reihenfolge der aufgezählten Haltestellen ist die aus der Realität.
5.: Die Reihenfolge der Wege hat dagegen keine Bedeutung. D.h. man kann sie automatisch sortieren (Es geht nur auf eine Art und es geht immer)
6.: unzerschnittene Kreisverkehre bekommen besondere Rollen
7.: Fahrwege und Halte kommen nur in Segmenten vor. Routen enthalten also nur Segmente (in der richtigen Reihenfolge).

Für die noch nicht erfassten Teilstrecken werden besondere Fehl-Segmente eingerichtet. Sie sind genauso, enthalten aber gar keine Wege. Stehen sie am Anfang/Ende einer Route, dann darf auch das "from" bzw. das "to" fehlen (wenn es unbekannt ist).

Damit sind die Dinger nicht mehr störanfällig und ein Editor hat genug in der Hand um fast jeden der heute üblichen Fehler zu finden und die meisten automatisch zu beseitigen.

Weide

Damit baust Du aber wirklich eine neu Ebene zwischen den Ways und Nodes und der Relation.
Und wenn einer einen Way löscht und dann neu anlegt? Habe ich da in deinem Konzept was überlesen oder nicht verstanden?

Aber mal ein ganz neuer Vorschlag:
Die Routen werden, wie ja schon festgestellt wurde, nur in den Verkehrskarte gezeigt. Und da ist Mapnik nicht fehlerfrei. In meiner Gegend fehlt da eine Linie, die in der Deutschlandkarte auftaucht.
Die Seite:
http://tracker.geops.ch/?z=13&s=1&x=100 … =transport
zeigt anscheinend die Routen aus OSM an, die Busse nehmen aber gelegentlich mal einen anderen Weg.

Was also wenn in den Bus-Relationen nur die Haltestellen, in der Reihenfolge in der sie angefahren werden, erfasst werden.
Wenn man die Busroute anzeigen will kann man ja aus der Reihenfolge der Haltestelle eine Route errechnen. Wenn dabei Einbahnstraßen und Haupt- und Nebenstraßen berücksichtigt werden, dürfte das sogar ziemlich genau sein.

Und wenn nicht? Wen juckt es?
Wenn ich im Bus sitze ist mir egal durch welche Straße er zu meinem Ziel fährt.

Heute ist es ja auch schon schwierig im Zweifelsfall den genauen Fahrweg eines Busses festzustellen.
Entweder man fährt mit oder man rennt hinterher.

Gruß
Gino

http://tracker.geops.ch/?z=13&s=1&x=100 … =transport nutzt OSM als Hintergrundbild und interpoliert Routen (oft) anhand einer Heuristik. Das ist detailliert unter http://geops.de/blog/mapping-von-netzen … n-verkehrs beschrieben.

Gino-52 wrote:

Damit baust Du aber wirklich eine neu Ebene zwischen den Ways und Nodes und der Relation.

Ja, und es ist mir nicht leicht gefallen. Ich mag keine zusätzliche Ebenen. Die beiden Ebenen sind aber insgesamt hoffentlich einfacher als die eine.

Gino-52 wrote:

Und wenn einer einen Way löscht und dann neu anlegt? Habe ich da in deinem Konzept was überlesen oder nicht verstanden?

Dann ist das im Segment feststellbar. Der Editor muss nur alle Nodes an Wegenden und die beiden bei "from" und "to" darauf prüfen, ob sie insgesamt genau zweimal auftauchen. (Nur die Kreisverkehre sind ein bischen aufwändiger.) Der Editor kann ggf. fragen "Wollen Sie wirklich ein Segment beschädigen?". Das Ganze führt aber auch dazu, dass der Editor oder ein Plugin ohne viel Aufwand Austauschoperationen zur Verfügung stellen kann.

Zum Weglassen der Fahrwege: Das kann man machen (gelegentlich will ich aber doch wissen, ob ich versehentlich in den falschen Bus gesprungen bin). Oft kann man auch aus dem Fahrweg schließen, dass noch Haltestellen fehlen.

Gar nichts halte ich davon, die Routen automatisch zu berechnen. Jemand macht einen kleinen Mappingfehler und man bekommt Phantasierouten. Man kann übrigens auch viele fehlende Haltestellen durch betrachten der Routen ermitteln.

Es kommt nicht darauf an, wie oft die berechneten Routen falsch sind. Auf der Seite http://tracker.geops.ch sehe ich ständig ICEs und ICs hier durch Hilden fahren. Da fahren aber keine. Woher soll ich wissen, ob es in einer anderen Gegend stimmt?

Weide

Weide wrote:

Ich lese in dem Proposals nur die "Erlaubnis", Routen-Relationen in Routen-Relationen zu schachteln. Das einzelne "Segment" wäre ebenso störanfällig wie jede andere Relation - weil das Segment nichts anderes als eine Relation ist.

Wenn Du mit "Relation" "PTv2-Routenrelation" meinst bin ich einverstanden.

Ich meinte, dass die dort beschriebenen Segmente nicht identisch sind mit dem Daten-Grundelement Segment (neben node, way und relation), die Dir vorschweben.

Ich bin kein GIS-Spezi und kann mir deshalb nicht so ganz vorstellen, was ein segment in Deinem Sinn ist. Ich weiß, dass das segment einen Anfangs- und einen Endpunkt hat und ahne, dass es nicht eine Linie mit mehr als zwei Punkten (und zwischen den Punkten mit gerade Verbindungen) ist, denn dann wäre es ein way. Und es ist auch keine definierte (und sortierte) Liste von ways und nodes, denn dann wäre es eine relation (die außerdem auch andere Relationen beinhalten darf). In meiner Vorstellungs- und Wunschwelt gäbe es in "meinem" OSM z.B. noch Kurven. Aber was ein segment in Deinem Sinn positiv formuliert ist, das weiß ich nicht. Kannst Du das für einen interessierten Laien grob erklären? Ist das so etwas wie ein routen vom Anfangs- zum Endpunkt auf vorhandene Wegen? Und was passiert, wenn einer der beiden Punkte (die jeweils nodes sind?) wegfällt?

Ich glaube, dass neue grundlegende Datenelemente in OSM nicht gerade ein Ziel sind und dass es deshalb sehr guter Argumente bedarf (und vieler Anwendungsfälle), damit das eine Chance auf Realisation hat.

Swen Wacker wrote:

...kann mir deshalb nicht so ganz vorstellen, was ein segment in Deinem Sinn ist.

Ein gewöhnliche Relation mit Wegen, zwei Nodes für Anfang und Ende und Haltestellenangaben.

Also wie eine PTv2-Route, jedoch ohne Reihenfolge in den Wegen und so einfach, dass die Wegreihenfolge stets eindeutig automatisch ermittelbar ist, selbst wenn Wege noch geteilt werden. Fehlende Stücke der Route kommen stets in eine zweite Relationsart, die "Fehlsegmente". Diese dürfen gar keine Fahrwege enthalten. Anders als in PTv2-Routen erhalten vollständige Kreisverkehre eine extra Rolle, so dass die besonderen Probleme beim Aufsplitten nicht auftreten oder erkennbar sind. Die Bedingungen habe ich weiter oben aufgezählt und stehen detaillierter (mit Änderungen für die Haltestellen) im P3-Vorschlag.

Weide

Ob PTv3 oder PTv2 - ist es überhaupt sinnvoll ÖPNV-Routen zu erafssen und wozu?
Ich habe dafür einen eigenen Thread eröffnet.

Gruß
Gino

1. Es gibt wenig Sinn, die Diskussion zu zerfleddern, glaube ich

2. Fahrplan-Daten sind keine Geodaten und können in OSM nicht abgebildet werden. Sie sollten m.E. dort auch nicht in OSM gesammelt werden.

3. Routenrelationen können auch für die Darstellung der (bzw: das Wissen um die) Fahrwege, also unabhängig von der tagesaktuellen "Verfügbarkeit" der Linie, genutzt werden.

Damit man sieht wie derzeit die Routen erfasst werden, habe ich eine einfache Visualisierung erstellt: https://augustuskling.github.io/psv/ (Achtung: nicht besonders getestet und braucht je nach angezeigter Region viel Speicher)
Die Visualisierung beachtet die forward/backward-Rollen nicht und sortiert auch absichtlich nicht die Relationsmitglieder. Die Daten kommen von der Overpass API womit die Abdeckung weltweit sein dürfte.
Legende auf Deutsch ist: Busrouten sind rote Linien, die Nodes innerhalb der Relationen rote Kreise und die grünen, gestrichelten Pfeile laufen von einem Node mit Rolle stop zum nächsten (Reihenfolge wie in Relation).

Das ist relativ primitiv, zeigt aber wie je nach Gegend erfasst wird. Manchmal finden sich nur die Fahrwege, manchmal nur die Haltestellen und manchmal beides in den Relationen. Festhalten kann man, dass zumindest die Bus-Routen in OSM ein wilder Mix sind.

Wenn ich das in Belgien ansehe, wo alle Haltestellen völlig ausgewertet schon vorhanden sind als Nodes neben die Wege, gemappt als

highway=bus_stop
public_transport=platform
bus=yes

mit entsprechend role=platform

kommt diese Darstellung damit nicht zu recht. Schade weil mehr als 50% der Routen in Belgien schon erfasst sind.

Polyglot

In Belgien finde ich highway=bus_stop mit public_transport=platform und dazu die Routen-Relationen, die aber nur Wege enthält. Gezeichnet werden damit nur die Fahrwege, nicht aber die Kreise für die Haltestellen. Ich weiß nicht wie ich die Haltestellen mit den Relationen in Verbindung bringen sollte – außer eben nur über ihre Nähe zum Fahrtweg. Beispiel wäre Relation 3825790.

Dann finde ich noch Routen ohne Relationen für die nur die Haltestellen als highway=bus_stop mit public_transport=platform erfasst sind. Diese werden nicht gezeichnet. Hier fällt mir nicht ein wie der Fahrweg aus den OSM-Daten ableitbar wäre.

Was ich noch machen könnte, wäre auch Relationen wie 2904977 mit den Pfeilen zu versehen. Das wären Relationen mit Fahrtwegen und Nodes in der Rolle platform. Meist du diese Fälle?

Sehe ich das eigentlich richtig, dass ref:TECL die Haltestelle und die Fahrtrichtung identifziert?

Ja, die meisten sind wie 2904977 gemappt. Rezent bin ich damit angefangen um die Haltestellen erst zu setzen. Die kamen hinterher weil das länger Zeit der Art vom sortieren war in JOSM. Heutzutage werden die HS erst sortiert.
Der Grund für mich um das zu änderen ist aber das es im Expert Mode seit einigen Monaten die Möglichkeit gibt um ab eine bestimmte Stelle im Relation Editor bis am Ende zu sortieren. Das ist sehr praktisch um die Ways in die richtige Reihenfolge zu bekommen, auch wenn Schleifen, usw. vorkommen.

Die 3825790 ist eine die ich noch nicht umgewandelt hatte. Die sollte noch nicht der public_transport:version=2 gehat haben. Da ist etwas schiefgelaufen.

ref:TECL ist der Identifier die TEC Liège-Verviers an die HS vergeben hat. Es gibt ziemlich viele HS die zwei unterschiedliche refs haben. z.B. ref:TECL und ref:TECN (Namur) oder ref:TECX (Luxembourg), oder auch ref:De_Lijn für der Flämischen Reisegesellschaft.

Zwei HS an beide Seiten der Strasse werden immer unterschiedliche refs haben. In Flandern sind die auch angegeben. Daher stammt es das wir Nodes neben die Wege haben die die Haltestellen darstellen. Die stop_position ist hier immer als viel weniger wichtig gesehen. Weil ich die Details nur einmal eintragen will, gehen die auf die highway=bus_stop/public_transport=platform/bus=yes und nur da. Das ist in Deutschland völlig anders gemappt, aber (noch) nicht überall.

Die Routen wo keine Wegen drinn sind, sind wahrscheinlich on_demand. Da kann der Faher selber unterscheiden wie er am besten die benötigte HS bedient, also keine feste Route. Das wird meistens als ein Gebiet angegeben auf die Karte, aber die sind nicht sehr wichtig.

Was ich denke dass interessant sei, ist um route_ref zu zeigen. Dann seht man sofort welche Linien eine HS bedienen. Da wird angeblich in Deutschland aber auch einen anderen Tag benutzt, etwas mit lines drinn.

Jo

Der Name der Haltestellen und route_ref werden nun bei hohem Zoom angezeigt und die Pfeile werden auch zwischen Nodes der Rolle platform gezeichnet.

ref:TECL ist der Identifier die TEC Liège-Verviers an die HS vergeben hat. Es gibt ziemlich viele HS die zwei unterschiedliche refs haben. z.B. ref:TECL und ref:TECN (Namur) oder ref:TECX (Luxembourg), oder auch ref:De_Lijn für der Flämischen Reisegesellschaft.

Es ist im Hinblick auf ein Tagging-Schema gut zu wissen, dass mehrere ref für dieselbe Haltestelle in Verwendung sind.

Zwei HS an beide Seiten der Strasse werden immer unterschiedliche refs haben.

Falls bei euch freie Fahrplandaten existieren, wäre über diese Referenzen ein kombiniertes Routing mit OSM-Daten und Bussen/Bahnen theoretisch möglich. Es bräuchte nicht einmal OSM-Relationen dafür.

Augustus Kling wrote:

Damit man sieht wie derzeit die Routen erfasst werden, habe ich eine einfache Visualisierung erstellt...

Die gefällt mir gut. Damit kann man Fehler finden, die mein Programm "putr" nicht findet.

Augustus Kling wrote:

Die Visualisierung beachtet die forward/backward-Rollen nicht und sortiert auch absichtlich nicht die Relationsmitglieder.

Das ist OK für PTv2, da dürfen sowieso keine forward/backward auftreten. Ways mit Rolle sind in PTv2 nie Fahrwege, man könnte sie also auch ruhig weglassen. (Echte PTv1 gibt es fast nirgendwo. Fast alle forward/backward sind einfach nur Fehler oder Überreste alter Daten.)

Augustus Kling wrote:

...und die Pfeile werden auch zwischen Nodes der Rolle platform gezeichnet.

So isses. Jeder "stop" und jede "platform" geben einen neuen Halt an. Nur wenn eine "platform" unmittelbar auf einen "stop" folgt (nicht umgekehrt) und die beiden zusammengehören (gleicher Name) bilden die beiden Angaben zusammen nur einen Halt statt zwei. (Mit "stop" und "platform" sind dabei die Rollen in der Relation gemeint und nicht Tags in den Objekten. An diese Rollen kann auch noch "_exit_only" oder "_entry_only" angehängt sein.)

Es ist aber egal, ob die "platforms" Nodes, Ways oder Flächen (auch Multipolygone) sind. Wegen der Kompatibilität zum alten Kram wird aber gewöhnlich ein "stop"-Node hinzugefügt, wenn die platform kein Node ist. Dadurch gibt es beim kompatiblen Mappen immer irgendeinen Node an einem Halt.

Zwei Sachen könnte ich mir noch zusätzlich vorstellen:

- Eine Einschränkung der Darstellung auf nur eine Relation. Damit wäre es viel leichter, Fehler in der Reihenfolge zu finden.

- Auch Züge, Straßenbahnen usw. dazu nehmen. Die Regeln sind ja dieselben.

Weide

Ich (als einer von denen, die zeitweise sehr viel Buslinien gemappt und das Ergebnis genutzt haben) meine inzwischen, dass wir uns auf die Infrastruktur konzentriern sollten, und den darauf stattfinden Verkehr gar nicht mappen. Um da zu einem brauchbaren Ergebnis zu kommen bräuchte man mEn ein anderes Datenformat, in dem die Daten von den VU veröffentlicht werden müssten. Dazu könnten sie theoretisch von den Aufgabenträgern bzw (bei eigenwirtschaftlichem Verkehr) vom "Willen des freien Marktes" verpflichtet werden. Wenn ihr dennoch meint, dass mit OSM da ein gutes Ergebnis erreicht werden könne, will ich euch aber nicht davon abhalten das vorzuführen 😉

Weide wrote:

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.

Da habe ich andere Erfahrungen gemacht: Iirc alle von mir reparierten Beschädigungen von Buslinienrelationen liessen sich auf einen der folgenden Gründe (sortiert nach Häufigkeit) zurückführen:
1. Splitten eines Ways, wenn nicht alle angrenzenden Ways und die den Way enthaltenden Relationen geladen waren. Wenn dabei eine Relation heile bleibt ist das eher Glück. Beispielsweise Abbiegebeschränkungsrelationen gehen dabei teilweise auch kaputt.
2. Bushaltestelle ergänzt und einfach ans Ende der Relation geworfen. Ähnliches gab es auch unter bestimmten Umständen mal mit diversen Editoren beim Splitten, das wurde jedoch afaik in allen behoben.
3. Relationen bei einer grösseren Strassenänderung (z.B. neuer Kreisverkehr) gar nicht beachtet. Dabei hilft auch nur Magie.

Augustus Kling wrote:

Es ist im Hinblick auf ein Tagging-Schema gut zu wissen, dass mehrere ref für dieselbe Haltestelle in Verwendung sind.

Polyglot wrote:

Zwei HS an beide Seiten der Strasse werden immer unterschiedliche refs haben.

Für mehrere Nummern für eine Haltestelle braucht man in Deutschland nichtmal mehrere Betreiber oder Überorganisationen (Verkehrsverbünde, bahn.de, …) betrachten, einige haben auch selbst mehrere Systeme…
Bei beidseitigen Bushaltestellen kenne ich eigentlich nur entweder eine Nummer für beide zusammen oder hierachisch aufgebaute Nummern, wobei es bei HAFAS ein paar Anomalien (bei manchen Haltestellen zwei Nummern, die dasselbe Ergebnis liefern) gibt.

Irgendwo in einem der drei Threads meinte noch jemand, dass es schwierig sei, Linienvarianten aus Fahrplandaten auf die OSM-Relationen zu matchen: Über die Liste der Halte (oder einfacher: Mit from=*, to=* und via=*) geht das ganz gut.

Zwei Sachen könnte ich mir noch zusätzlich vorstellen:

- Eine Einschränkung der Darstellung auf nur eine Relation. Damit wäre es viel leichter, Fehler in der Reihenfolge zu finden.

- Auch Züge, Straßenbahnen usw. dazu nehmen. Die Regeln sind ja dieselben.

Der Query für die Overpass API kann nun bearbeitet werden. Falls der Query bearbeitet wird, bleibt die Änderung bestehen (localStorage des Browsers).

Das Ganze ist aber nur gedacht um ein Gefühl dafür zu bekommen wie Routen heute erfasst sind. Ich plane derzeit nicht die Visualisierung besonders hübsch zu machen oder mit Features auszustatten.

Hallo,

Augustus Kling wrote:

Der Query für die Overpass API kann nun bearbeitet werden. Falls der Query bearbeitet wird, bleibt die Änderung bestehen (localStorage des Browsers).

auf den ersten Blick liefert folgende Variante ein vergleichbares Ergebnis, läuft aber um einiges schneller. Das hängt damit zusammen, dass das foreach in der Overpass Query relativ teuer ist.

(relation({{bbox}})[type=route][route~"bus"];␣node(r));
out␣geom;

Link zum Testen: http://dev.overpass-api.de/tmp/psv/

Gruß,
mmd

rayquaza wrote:

Weide wrote:

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.

Da habe ich andere Erfahrungen gemacht: Iirc alle von mir reparierten Beschädigungen von Buslinienrelationen liessen sich auf einen der folgenden Gründe (sortiert nach Häufigkeit) zurückführen:
1. Splitten eines Ways, wenn nicht alle angrenzenden Ways und die den Way enthaltenden Relationen geladen waren. Wenn dabei eine Relation heile bleibt ist das eher Glück. Beispielsweise ...

Genau das meinte ich. Die dabei entstehenden Schäden sind Schäden in der Reihenfolge der Wege. Bei Relationen ohne Bedeutung der Wegreihenfolge entsteht daher kein Schaden. Dazu muss man nur von den ohnehin von vielen verlangten Segmenten zusätzlich Einfachheit fordern.

Weide

Die Probleme der Public Transport Daten wurden hier schon weitgehend beschrieben.
Wenig erwähnt wurde das Auswerteproblem: die Datenstruktur ist so komplex, dass sie ein durchschnittlicher User nicht nutzen kann (etwa mit einer Overpass-Abfrage).
Ein dritter, komplexes Schema, das neben den ersten beiden besteht und mit diesen wohlmöglich vermischt wird, würde das Auswerteproblem nochmals vergrößern.
In diesem Thread und in "Welchen Sinn machen ÖPNV-Routen in OSM" haben auch sehr aktive Mapper erklärt, dass sie keine ÖPNV-Daten erfassen.

Wir brauchen m.E. eine Datenstruktur, in der jeder Mapper mit jedem Editor und mit geringem Einarbeitungsaufwand ÖPNV-Daten erfassen kann.
Eine Möglichkeit dazu habe ich einmal skizziert:

1. Liniennummer als Tag an jede Haltestelle
"route_ref" wird dafür >130000 mal verwendet.
Liniennummern sind lokal meist eindeutig, global nicht.
- Einarbeitungsaufwand: sehr gering
- Eintrageaufwand: gering
- Editor: jeder
- Auswertung: sehr einfach, ggf. "Query"-Button der Standardkarte
- ermöglicht Darstellung der Liniennummern an der Haltestelle auf einer Karte und Abfragen wie
"Welche Linie fährt ab Haltestelle <X>?"
"Wo hält Linie <X> in Ort <Y>?"

2. zusätzlich eine Relation pro Linie mit ungeordneter Haltestellenliste
Zusatzinformationen "network", "operator", ggf. Betriebszeiten, Takt.
Liniennummern mit "network", "operator" sind dann global eindeutig.
- Einarbeitungsaufwand: gering
- Eintrageaufwand: gering, semiautomatisch aus 1.
- Editor: jeder mit Relationsunterstützung
- Auswertung: einfach
- ermöglicht Anzeige der Zusatzinformationen; Filter nach "network", "operator"

3. zusätzlich Segmente von Buslinien als ungeordnete Liste von ways
- Einarbeitungsaufwand: mittel
- Eintrageaufwand: mittel
- Editor: jeder mit Relationsunterstützung, josm vorteilhaft
- Auswertung: einfach
- ermöglicht Linienkarte mit Liniennummern an der Haltestelle und Verbindungslinien

4. zusätzlich Linienvarianten als Relation mit geordneter Liste der Haltestellen und Liste der Streckensegmente
- Einarbeitungsaufwand: hoch
- Eintrageaufwand: hoch
- Editor: vermutlich nur josm sinnvoll
- Auswertung: komplex
- ermöglicht Verbindungsanalysen, grobe Fahrzeitbestimmung

mmd wrote:

[...]auf den ersten Blick liefert folgende Variante ein vergleichbares Ergebnis, läuft aber um einiges schneller. Das hängt damit zusammen, dass das foreach in der Overpass Query relativ teuer ist.[...]

Dein Query liefert weniger Datenmenge als der bisherige von mir. Der vorige Query für die Overpass API von mir hatte zu Duplikate in den Ergebnissen geführt – die sind natürlich nicht gewünscht gewesen. Vielen Dank für den Hinweis, ich habe deinen Query gerne übernommen.

seawolff wrote:

Die Probleme der Public Transport Daten wurden hier schon weitgehend beschrieben.
Wenig erwähnt wurde das Auswerteproblem: die Datenstruktur ist so komplex, dass sie ein durchschnittlicher User nicht nutzen kann (etwa mit einer Overpass-Abfrage).
Ein dritter, komplexes Schema, das neben den ersten beiden besteht und mit diesen wohlmöglich vermischt wird, würde das Auswerteproblem nochmals vergrößern.
In diesem Thread und in "Welchen Sinn machen ÖPNV-Routen in OSM" haben auch sehr aktive Mapper erklärt, dass sie keine ÖPNV-Daten erfassen.

Das Auswerteproblem ist ein schönes Stichwort! Welches Auswerteprobleme gibt es denn?
Derzeit ist unklar nach welchem Schema die Linien getagt sind. Daher kann der Auswerter nur raten PTV1 PTV2 Oxomoa etc. Meistens auch Mischformen.
Nach deinen Vorschlägen würdest du die Erfassung total vereinfachen. Aber die Auswertung deutlich erschweren.
Mit erfassen der Liniennummern je Haltestelle würdest du zwar schnell eine overpassabfrage erstellen können, welche dir ausgibt an welchen Haltstellen diese Nummer eingetragen ist, wobei das auch nicht besser wird je mehr Linien an der Haltestelle fahren, aber die wichtigen Informationen an welchem Mast fährt der Bus in welche Richtung und welche Haltestellen erreiche ich ohne Umsteigen von wo aus gehen verloren. Ebenso die Linienwege für die Abfragen wieviel Verkehrsleistung wird eigentlich erbracht etc.

Das ihr damit argumentiert man könne die Fahrwege aus den Haltestellen berechnen, macht die Sache nicht besser. Wie oft habe ich schon Fahrplandaten in Netze eingelesen und danach völlig sinnlose Linienrouten erhalten. Insbesondere große Haltestellenabstände und Einbahnstraßen machen ein Automatismus schwierig.

Ja es gibt erfahrene aktive Mapper die mappen kein ÖPNV. Aber frage doch mal wer Mappt Grenzen oder Öffnungszeiten? Und du kannst noch weiter gehen, wer mappt Wickeltische oder Hundekottütenspender? Das sind wirklich triviale Dinge, welche aber nicht bei jedem auf Interesse stoßen. Und so ist es beim ÖPNV auch.

viw wrote:

Ja es gibt erfahrene aktive Mapper die mappen kein ÖPNV. Aber frage doch mal wer Mappt Grenzen oder Öffnungszeiten? Und du kannst noch weiter gehen, wer mappt Wickeltische oder Hundekottütenspender? Das sind wirklich triviale Dinge, welche aber nicht bei jedem auf Interesse stoßen. Und so ist es beim ÖPNV auch.

Naja, da gibt es schon einen Unterschied. Hundekottütenspender mappe ich (meistens) nicht, weil sie mich nicht besonders interessieren (duck mich und weg ...). ÖPNV mappe ich nicht, weil ich das Gefühl habe, dass ich es immer noch nicht wirklich verstehe und wahrscheinlich Unsinn produziere. Das ist also fast das Gegenteil: während die einen Dinge zu trivial sind, ist ÖPNV sehr (zu?) kompliziert.

Das heißt nicht, dass ich ÖPNV-Mapping ablehnen würde: nur weil ich mich immer noch nicht recht eingearbeitet habe, heißt das nicht, dass es schlecht/falsch/überflüssig ... wäre. Ich bin jedem dankbar, der ÖPNV mappt. Es könnte aber ein Indiz dafür sein, dass PTv3 nicht noch viel komplizierter werden sollte ...

BTW zur aktuellen Diskussion: Segmente wären, so wie Weide sie beschrieben und erklärt hat, mMn zwar komplex (eine Ebene mehr), aber nicht kompliziert (sie sind sehr klar definiert). Wenn sie also dazu beitragen würden, das ÖPNV-Mapping zu vereinfachen und sicherer zu machen, würde ich sie durchaus begrüßen.

Ich benutze in fremden Städten die ÖPNV-Karte damit ich eine schnelle Übersicht über die Linienverläufe habe.

Momentan ist das ÖPNV-Mapping sehr komplex und das Spezialgebiet von wenigen.
Erst wenn das Erfassen einfacher wird begeistern sich auch andere (vielleicht auch ich selbst).

viw wrote:

Das Auswerteproblem ist ein schönes Stichwort! Welches Auswerteprobleme gibt es denn?

Vor allem das Problem, dass kaum jemand die Daten nutzt, weil die OSM-Daten unvollständig, nicht aktuell, in unterschiedlichen, verschachtelten Datenformaten und undokumentierten Mischformen vorliegen.
Die Liniennetzkarten zeigen einfach alle Relationsmitglieder an. Da kommt es auf Lücken und Fehler in den Daten kaum an. Die meisten anderen Informationen werden nicht genutzt.

Nach deinen Vorschlägen würdest du die Erfassung total vereinfachen. Aber die Auswertung deutlich erschweren.
Mit erfassen der Liniennummern je Haltestelle würdest du zwar schnell eine overpassabfrage erstellen können, welche dir ausgibt an welchen Haltstellen diese Nummer eingetragen ist, wobei das auch nicht besser wird je mehr Linien an der Haltestelle fahren, aber die wichtigen Informationen an welchem Mast fährt der Bus in welche Richtung und welche Haltestellen erreiche ich ohne Umsteigen von wo aus gehen verloren. Ebenso die Linienwege für die Abfragen wieviel Verkehrsleistung wird eigentlich erbracht etc.

Nein, damit wird die Möglichkeit geschaffen, die Basisdaten auf einfache Weise zu erfassen und ebenso einfach auszuwerten.
Für viele Anwendungen reicht das bereits aus. Viele Nutzer können selbst erkennen, zu welcher Straßenseite sie gehen müssen um den richtigen Bus zu erwischen. Diese Daten sind auf jeden Fall besser, als eine nicht erfasste Buslinie!

Die Möglichkeit, alle Streckenvarianten in allen Details zu erfassen und auszuwerten, bleibt ja trotzdem erhalten.
Wenn man mehr Mapper gewinnt, die zumindest die Basisdaten erfassen und pflegen, kann man deren Daten nutzen, um auch die komplexen Datenstrukturen auf Fehler zu überprüfen und zu verbessern.

BTW, kennst du eine Anwendung, die mit den bislang erfassten Daten anzeigt, welche Haltestellen man ohne Umsteigen von wo erreichen kann oder wie viel Verkehrsleistung erbracht wird?

Ja es gibt erfahrene aktive Mapper die mappen kein ÖPNV. Aber frage doch mal wer Mappt Grenzen oder Öffnungszeiten?

Die Grenzen sind in OSM weitgehend vollständig, werden regelmäßig auf Datenfehler geprüft und ggf. repariert und liegen in einem einheitlichen Datenformat vor. Damit sind sie gut nutzbar.
Für die ÖPNV-Daten gilt das leider nicht.

PS: Der ZOB in Kiel wurde Anfang des Jahres abgerissen und soll bis Ende 2017 neu gebaut werden. Bislang hat niemand die Buslinien angepasst.

seawolff wrote:

BTW, kennst du eine Anwendung, die mit den bislang erfassten Daten anzeigt, welche Haltestellen man ohne Umsteigen von wo erreichen kann oder wie viel Verkehrsleistung erbracht wird?

PTV Visum macht das zum Beispiel. Aber das ist natürlich ein mächtiges Tool.

Werden OSM-Daten von Verkehrsunternehmen mit PTV Visum produktiv genutzt?
Wie geht das Programm mit fehlerhaften Relationen um?

seawolff wrote:

Werden OSM-Daten von Verkehrsunternehmen mit PTV Visum produktiv genutzt?
Wie geht das Programm mit fehlerhaften Relationen um?

Ich weiß nicht was Verkehrsunternehmen mit diesem Programm machen. PTV pflegt ja ein eigenes Straßenmodell. Mit OSM Daten ist es aber sehr einfach ein neues Model in anderen Gegenden aufzubauen.
Fehlerhafte Relationen werden einfach soweit wie möglich in Linienrouten umgewandelt. Allerdings werden keine zwei Routen für eine getrennte Relation angelegt. Auch mit Haltestellen hat das Programm Probleme. Es ist einfach auf Stop_positionan auf dem Weg angewiesen.

Meine Idee für ein PTv3 Datenmodell:
Es gibt Fahrwegrelationen, die eine Relation zwischen zwei aufeinanderfolgenden Haltestellen und den zwischen diesen Haltestellen gelegenem Fahrweg darstellen. Im allgemeinen werden diese Fahrwegrelationen völlig linienunabhängig sein. Nur in seltenen Ausnahmefällen wird werden mehrere Linien verschiedene Fahrwege zwischen dem gleichen Haltestellenpaar haben, so dass es hier verschiedene Fahrwegrelationen geben muss.

Es gibt Linienrelationen, die eine geordnete Liste der Haltestellen enthalten. Dazwischen können die jeweiligen Fahrwegrelationen optional eingefügt sein. Diese ist aber nur zwingend, wenn es zwischen einem Haltestellenpaar mehrere Fahrwegrelationen gibt.

Um einfacher Auswertungen (z.B. mit Overpass-API) machen zu können, kann man auch festlegen, dass möglichst alle Fahrwegrelationen enthalten sein sollen. Dann sollte aber der Editor oder ein Bot diese redundante Information automatisch hinzufügen.

Ebenso könnte es einen Bot geben, der automatisch Fahrwegrelationen durch Autorouting erstellt oder korrigiert, wenn ein Haltestellenpaar als aufeinanderfolgende Haltestellen der Linienrelation vorkommt. Durch ein Tag sollten automatisch erzeugte oder korrigierte Fahrwegrelationen gekennzeichnet werden. Durch geeignete Tags in Fahrweg- und Linienrelation sollte der Bot steuerbar sein.