You are not logged in.

#1 2013-07-22 09:33:07

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

ÖPNV Vorentwurf (zurückgezogen)

Hi,

auf http://wiki.openstreetmap.org/wiki/User:Weide findet Ihr einen Vorentwurf zum Thema ÖPNV.

Weide

Last edited by Weide (2013-07-30 06:46:03)

Offline

#2 2013-07-22 10:57:07

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

Re: ÖPNV Vorentwurf (zurückgezogen)

Ich denke da steckt sehr viel Arbeit drin.
Die Frage die sich mir stellt ist ÖPNV wie TMC? Nur noch von wenigen in seiner Gänze wirklich umsetzbar? Und damit sehr fehleranfällig?
Oder liegt das einfach nur daran, dass es keiner versteht, weil es sich so schnell ändert?

Offline

#3 2013-07-22 11:40:44

MetiorErgoSum
Member
From: Allgäu
Registered: 2009-10-05
Posts: 227

Re: ÖPNV Vorentwurf (zurückgezogen)

Sofern ich es richtig gelesen habe, willst du Varianten von einzelnen Streckenabschnitten ausschließlich für unterschiedliche platforms (z.B. Bussteige innerhalb eines Busbahnhofs) erlauben, wofür du die Rollen haltvar und wayvar und die minivar-Relation einführst.

Im ländlichen Bereich ist das Hauptproblem, dass eine einzige Linie oft Dutzende von Varianten umfasst, wobei manche lediglich ein oder zwei Haltestellen überspringen, andere aber über weite Strecken eine völlig andere Route fahren. Ohne die Möglichkeit, Streckensegmente zu definieren und dann diese Teilsegmente zusammenzusetzen (oder eine andere Möglichkeit, die eine ähnliche Vereinfachung erreicht), bleibt das bisherige Konzept praktisch unbrauchbar. Wenn ich für jede "echte" Variante eine eigene Streckenrelation mit dem gesamten Streckenverlauf anlegen und pflegen muss, ist der Verwaltungsaufwand nicht zu bewältigen. Über manche Ausfallstraßen laufen dann Hunderte von Streckenrelationen, und bei einem Umbau müssten sie alle einzeln geändert werden.

Wenn also ein Vorschlag kommt, das bisherige Schema kräftig umzumodeln, wäre das nicht eine gute Gelegenheit, auch diesen wichtigen Punkt anzupacken? Zumal du ja mit den minivar-Relationen schon ein vergleichbares Konzept einführen willst. Könntest du das nicht auf längere Streckenabschnitte erweitern?

Offline

#4 2013-07-22 11:54:09

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,672
Website

Re: ÖPNV Vorentwurf (zurückgezogen)

auf talk-de ging die sache los. etwas schwer zu finden, daher hier ein link: http://gis.19327.n5.nabble.com/Wiki-Nic … 70011.html

da sind einige interessante argumente.

gruss
walter

Offline

#5 2013-07-22 12:27:02

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

Re: ÖPNV Vorentwurf (zurückgezogen)

MetiorErgoSum wrote:

Wenn also ein Vorschlag kommt, das bisherige Schema kräftig umzumodeln, wäre das nicht eine gute Gelegenheit, auch diesen wichtigen Punkt anzupacken? Zumal du ja mit den minivar-Relationen schon ein vergleichbares Konzept einführen willst. Könntest du das nicht auf längere Streckenabschnitte erweitern?

Da spricht Du was an ... Das einzubauen war für mich sogar einer der Gründe es machen. Ich hatte es komplett beschrieben drin, habe mir presets für JOSM gebastelt und mit einigen solcher Linien experimentiert (ohne sie hochzuladen). Aber selbst wenn ich mir vorgestellt habe, dass der JOSM es noch über die Presets hinaus ünterstützen würde, wurde es nicht übersichtlich und es gibt ja auch noch andere Editoren... Ich habe sie dann wieder rausgeworfen. Das hat schon irgendwie weh getan, wenn eine Lieblingsidee beerdigt werden muss. Ich habe im Moment keine Lösung.

Weide

PS: Was ich da eingebaut hatte waren Segment-Relationen, die mit einer "include"-Role hätten eingefügt werden können. Keine Rekursion. Kein Revers-Include. Ich habe allerdings damals noch keine getrennten includes für den Haltestellenteil und den Fahrwegteil probiert; auf die Idee bin ich erst bei den praktischen Tests für die Minivars gekommen. Aber ich glaube nicht, dass es damit übersichtlich genug wird.

Offline

#6 2013-07-22 12:53:59

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

Re: ÖPNV Vorentwurf (zurückgezogen)

viw wrote:

Die Frage die sich mir stellt ist ÖPNV wie TMC? Nur noch von wenigen in seiner Gänze wirklich umsetzbar? Und damit sehr fehleranfällig?
Oder liegt das einfach nur daran, dass es keiner versteht, weil es sich so schnell ändert?

Von TMC hab ich absolut keine Ahnung, da kann ich nicht vergleichen.

Schnell geändert hat es sich eigentlich nicht und schlecht war das Konzept auch nicht. Was meines Erachtens nicht angekommen ist, ist das es zwei (eigentlich noch mehr) verschiedene inkompatible Relationsarten gab, die beide type=route hatten. Jeder normale Mapper liest sich (ok, ich übertreibe) nicht die Konzepte durch, er sieht lieber nach, wie es so in der Nachbarschaft gemacht wird. Überall tauchten sonderbare Mischungen verschiedener Konzepte auf. Diese Fehler sind dann auch ins Wiki gewandert. Ich fand das original Public Transport Proposal sehr gut, aber die Dinge sind schlecht gelaufen.

Das hat dann zu schlechtem Support durch die Programme (Themenkarten, Fehlerkarten, Editoren) geführt. Die können (auch wenn ich mir das oft gewünscht hätte) nicht einfach "das beschlossene Proposal" zugrunde legen, wenn die meisten Mapper es anders machen.

Weide

Offline

#7 2013-07-22 14:18:10

Netzwolf
Member
Registered: 2008-04-01
Posts: 1,665

Re: ÖPNV Vorentwurf (zurückgezogen)

Nahmd,

MetiorErgoSum wrote:

Im ländlichen Bereich ist das Hauptproblem, dass eine einzige Linie oft Dutzende von Varianten umfasst, wobei manche lediglich ein oder zwei Haltestellen überspringen, andere aber über weite Strecken eine völlig andere Route fahren.

Gruseliges Beispiel: die Linie 336 des VRS. (Achtung: Fahrplan von vor zwei oder drei Jahren)

Ich hab noch ein paar Beispiele mehr und eine Übersicht über die Zahl der Varianten.

Ohne die Möglichkeit, Streckensegmente zu definieren und dann diese Teilsegmente zusammenzusetzen (oder eine andere Möglichkeit, die eine ähnliche Vereinfachung erreicht), bleibt das bisherige Konzept praktisch unbrauchbar. Wenn ich für jede "echte" Variante eine eigene Streckenrelation mit dem gesamten Streckenverlauf anlegen und pflegen muss, ist der Verwaltungsaufwand nicht zu bewältigen. Über manche Ausfallstraßen laufen dann Hunderte von Streckenrelationen, und bei einem Umbau müssten sie alle einzeln geändert werden.

Hatte ich mal ausprobiert: Ways und Haltestellen Segmenten zuordnen und denn per Tag/Value die Segmente zu Kursen zusammenfassen. Die Haltestellen tragen Abfahrtszeiten relativ zum Anfang des jeweiligen Segments.

Bei den ”kurs:XXX=d2e20f … …” definiert das erste Wort des Values den Kurs, wobei eine an den Kennbuchstaben des Segmentes angehängte Zahl die Fahrzeit dieses Segmentes um soviel Minuten verlängert.

Mit den folgenden Angaben (Zeit von/bis, Taktzeit und Verkehrstagskennung) kann man direkt aus der OSM-Relation diesen Unfug erzeugen. Soweit muss man aber nicht gehen.

Gruß Wolf

Offline

#8 2013-07-22 14:32:30

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

Re: ÖPNV Vorentwurf (zurückgezogen)

MetiorErgoSum wrote:

Über manche Ausfallstraßen laufen dann Hunderte von Streckenrelationen, und bei einem Umbau müssten sie alle einzeln geändert werden.

Nur begrenzt. Man hat an solchen Stellen zwar manchmal tierisch viel Arbeit, aber in einem häufigen Fall kann man sie sich im JOSM total sparen. Ich nutze mal die Gelegenheit, um auf diese Besonderheit im JOSM hinzuweisen:

Wenn es um das Splitten von Straßen an einem der Nodes geht, dann sollte man vorher immer eine beliebig kleine Umgebung beider Endpunkte der Straße laden. Unter dieser Voraussetzung fügt der JOSM richtig ein und man muss nicht nachbearbeiten.

Offline

#9 2013-07-22 14:44:51

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

Re: ÖPNV Vorentwurf (zurückgezogen)

Netzwolf wrote:

Gruseliges Beispiel: die Linie 336 des VRS. (Achtung: Fahrplan von vor zwei oder drei Jahren)

Ich hab noch ein paar Beispiele mehr und eine Übersicht über die Zahl der Varianten.

Das ist echt interessant und sehr hilfreich zum Testen von Ideen zu Lösungen.

Ich kriege aber so langsam den Verdacht, dass wir im nächsten API außer Flächen auch noch Arrays von Records  einbauen müssten -- sonst werden die Roles durch die Hintertür zu Datenbanken...

Weide

Offline

#10 2013-07-23 06:26:26

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

Re: ÖPNV Vorentwurf (zurückgezogen)

MetiorErgoSum wrote:

Wenn also ein Vorschlag kommt, das bisherige Schema kräftig umzumodeln, wäre das nicht eine gute Gelegenheit, auch diesen wichtigen Punkt anzupacken? Zumal du ja mit den minivar-Relationen schon ein vergleichbares Konzept einführen willst. Könntest du das nicht auf längere Streckenabschnitte erweitern?

Ich hab die Segmente jetzt doch wieder eingebaut. Jeder Mapper soll selbst entscheiden, ob die Sachen in der konkreten Situation die Angelegenheit übersichtlicher oder weniger übersichtlich machen.

Meine negativ ausgegangenen Experimente in der Hinsicht hatte ich noch mit einem einfachen include
gemacht. Vielleicht ist es mit getrennten Roles für das Einfügen der Halte und das Einfügen der Wege besser, da die Variante nicht mehr so zerstückelt wird.

Weide

Offline

#11 2013-07-23 09:59:49

errt
Member
Registered: 2009-12-01
Posts: 1,068

Re: ÖPNV Vorentwurf (zurückgezogen)

Was sich mir nicht ganz erschließt, ist das mit dem 'wayvar' vs 'haltvar' und jetzt 'wayseg' vs. 'haltseg'. Ich trage doch sowohl Wege als auch Halte in eine Relation ein?

Offline

#12 2013-07-23 10:44:31

MetiorErgoSum
Member
From: Allgäu
Registered: 2009-10-05
Posts: 227

Re: ÖPNV Vorentwurf (zurückgezogen)

errt wrote:

Was sich mir nicht ganz erschließt, ist das mit dem 'wayvar' vs 'haltvar' und jetzt 'wayseg' vs. 'haltseg'. Ich trage doch sowohl Wege als auch Halte in eine Relation ein?

Das Problem ist, dass in einer Routenrelation erst alle Haltestellen aufgelistet sind, dann alle Wegstücke. Das sind im Grunde zwei völlig getrennte Listen. Es ist nicht ersichtlich, wo sich eine Haltestelle innerhalb der Wegstrecken befindet. Nun definierst du Segmente als kurze, eigenständige Routenrelationen, die ebenfalls aus Haltestellen und Wegstücken bestehen. Und wenn du schließlich ein solches Segment in eine Routenrelation einfügst, musst du erstens festlegen, wo die Haltestellen aus dem Segment hinkommen, und zweitens, wohin die Wegstücke aus dem Segment kommen. Daher die getrennten haltseg- und wayseg-Rollen.

Wenn diese Trennung zwischen Haltestellen und Wegstücken nicht wäre, sondern die Haltestellen einfach an den passenden Stellen zwischen zwei Wegstücken stünden, könnten wir die ÖPNV-Relationen wie stinknormale Wanderrouten in Segmente aufteilen. Dort ist das simpel und seit längerem etabliert. Rückblickend war es vielleicht ein Fehler, die Haltestellen in den ÖPNV-Relationen am Anfang zusammenzufassen.

Offline

#13 2013-07-23 12:34:53

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

Re: ÖPNV Vorentwurf (zurückgezogen)

MetiorErgoSum wrote:

Wenn diese Trennung zwischen Haltestellen und Wegstücken nicht wäre, sondern die Haltestellen einfach an den passenden Stellen zwischen zwei Wegstücken stünden, könnten wir die ÖPNV-Relationen wie stinknormale Wanderrouten in Segmente aufteilen. Dort ist das simpel und seit längerem etabliert. Rückblickend war es vielleicht ein Fehler, die Haltestellen in den ÖPNV-Relationen am Anfang zusammenzufassen.

Das würde aber auch bedeuten das du jeden simplen Weg an jeder Haltestelle auftrennen musst. So kann man an einen Weg auch mehrere Hatlestellen haben und die hatlestelle kann auch in der Wegmitte liegen.

Last edited by viw (2013-07-23 12:35:27)

Offline

#14 2013-07-23 12:59:27

MetiorErgoSum
Member
From: Allgäu
Registered: 2009-10-05
Posts: 227

Re: ÖPNV Vorentwurf (zurückgezogen)

viw wrote:

Das würde aber auch bedeuten das du jeden simplen Weg an jeder Haltestelle auftrennen musst. So kann man an einen Weg auch mehrere Hatlestellen haben und die hatlestelle kann auch in der Wegmitte liegen.

Das stimmt. Wenn es bei leicht versetzten Haltestellen mehrere stop_position-Punkte gibt, müsstest du sogar mehrmals splitten. Andererseits ist der Split eines Wegs kein Weltuntergang.
Es gäbe bei diesem Modell aber auch andere Probleme, z. B. dass man in den Relationseditoren nicht mehr auf Anhieb sieht, ob die Strecke vollständig erfasst ist; an jeder Haltestelle gibt es einen Sprung. Man müsste dann die Relationseditoren so ändern, dass sie die Haltestellenelemente quasi ignorieren bei ihrer Auswertung, ob ein lückenloser Linienzug besteht. Von Änderungen bei den Auswertungsprogrammen ganz abgesehen.

Das war auch nicht als ernsthafter Vorschlag gedacht, sondern eher als wehmütiger Rückblick. smile Die Trennung von Haltestellen und Wegstücken in den Routenrelationen ist seit langem etabliert. Das lässt sich auf der sozialen Seite bestimmt nicht mehr ändern, selbst wenn es technisch sinnvoller wäre (was auch erst einmal zu beweisen wäre).

Offline

#15 2013-07-23 14:11:12

errt
Member
Registered: 2009-12-01
Posts: 1,068

Re: ÖPNV Vorentwurf (zurückgezogen)

@MetiorErgoSum: Danke, das hatte ich irgendwie nicht ganz überrissen.

Offline

#16 2013-07-23 14:15:27

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

Re: ÖPNV Vorentwurf (zurückgezogen)

errt wrote:

Was sich mir nicht ganz erschließt, ist das mit dem 'wayvar' vs 'haltvar' und jetzt 'wayseg' vs. 'haltseg'. Ich trage doch sowohl Wege als auch Halte in eine Relation ein?

Ja. Bis zu den Tests hatte ich einfaches "include" für Minivars und Segmente. Es war aber scheußlich unübersichtlich, weil dann wegen der richtigen Reihenfolge der Haltetellen Halte und Wege wieder kreuz und quer verteilt werden müssen. Es gefällt mir auch nicht, dieselbe Relation zweimal zu erwähnen, aber es sieht dann hinterher ganz übersichtlich aus.

Weide

Offline

#17 2013-07-23 18:02:38

Tirkon
Member
From: Ostfriesland / Germany
Registered: 2009-01-27
Posts: 305

Re: ÖPNV Vorentwurf (zurückgezogen)

viw wrote:

Ich denke da steckt sehr viel Arbeit drin.
Die Frage die sich mir stellt ist ÖPNV wie TMC? Nur noch von wenigen in seiner Gänze wirklich umsetzbar?

Gerade die Einfachheit des Vorschlags von Weide gefällt mir so außerordentlich. Das Relationengetümmel im alten Proposal ist genau das, was es dem nicht so erfahrenen Mapper schwer macht, die Übersicht zu halten. Nach dem neuen Proposal sehen die Relationsbezüge für ein funktionierendes Mapping einer Standard-Buslinie ohne Varianten so aus:

Wir packen die Haltestellen und die Route pro Fahrtrichtung in dieser Reihenfolge und in Fahrtrichtung sortiert in jeweils eine Relation: type=pt2, pt2=variant.
Die beiden sich ergebenden Relationen kommen wieder in eine Elternrelation: type=pt2, pt2=master.

Das war es auch schon, was für ein erstes Funktionieren einer Buslinie zwingend notwendig ist. Es ist so einfach, dass dies nahezu jeder leisten kann, der eine Grundverständnis einer Relation hat. Selbst wenn es Varianten gibt, wird hier der Mapper ohne Informatikhintergrund in die Lage versetzt, zumindest eine Hauptvariante einer Buslinie anzugeben. Hat er dies erst einmal gemacht, ist dann auch ein abweichender Fahrweg als weitere Variante nicht mehr so schwer. Bei dem Modell ist es zudem nicht mehr notwendig, pro Halt eine Plattform und eine Stoppstelle zu definieren - die Plattform reicht. So kann diese von jedem Mapper verschoben werden, ohne dass dabei vergessen wird, die Stoppstelle auch zu verschieben oder umgekehrt.

Das Weide-Schema entspricht dann auch dem, was der einfache Bürger intuitiv auch als Haltestelle wahrnimmt. Im Allgemeinen wird eine Haltestelle in der Wirklichkeit durch das Schild am Mast symbolisiert. Auch wenn ein ÖPNV Unternehmen eine Haltestelle versetzt, wird das Haltestellenschild abgenommen und an anderer Stelle aufgestellt. Der Bus hält dann einigermaßen lotrecht dazu auf der Straße. Genau das bildet das neue Modell 1:1 ab.

Sofern eine Anwendung eine Stoppstelle benötigt, läßt sich diese leicht durch Lötfällen auf die Route automatisch ermitteln, wie der OSM Inspector zeigt:
http://tools.geofabrik.de/osmi/?view=ad … rest_roads

Zudem ist die stop_area, die bisher zum Ermitteln des Haltestellennamens notwendig war, nicht mehr zwingend erforderlich. Sie kann optional beim Zusammenfassen bei Umsteigepunkten noch angewendet werden. Die Buslinie funktioniert aber jetzt auch ohne diese - eine weitere deutliche Entblähung.

Dass das Modell etwas komplizierter werden muss, wenn Varianten gemappt werden, liegt in der Natur der Sache. Aber auch hier schafft das Weide-Schema verglichen mit dem alten, mehr Möglichkeiten bei weniger Komplexität. Obendrein beseitigt es immense Redundanzen (mit entsprechenden Fehlermöglichkeiten durch Abweichen eigentlich gleichzulautender Einträge) und ist konsistenter sowie eindeutiger.

Dass ich mich bei dieser Beurteilung zunächst auf Buslinien beschränke, hat seinen Grund. Denn sie sind es, die bis in den letzten Winkel der Republik fahren und daher von möglichst jedem Mapper mit Relationskenntnissen verstanden werden sollten. Für die Bahnen, die meist nur in größeren Städten oder überregional verkehren, sollten zumindest in den deutschsprachigen Ländern genug Mapper mit fortgeschrittenen Mappingkenntnissen existieren. Aber auch diese werden nach dem Modell von Weide einfacher. Zudem ändern sich Gleisverläufe nicht so einfach wie Busrouten.

Dennoch ein Wort zu den Straßenbahnen. Dort gibt es zumeist etablierte Bedarfsumleitungen. Diese lassen sich - einmal anläßlich einer solchen Nutzung gemappt - aus, ein- und umgliedern.

Je weiter ich mich in das Weide-Schema vertiefe, um so mehr tritt die Genialität zu Tage - verglichen mit allem Anderen, was wir bisher auf OSM im ÖPNV Bereich hatten.

Offline

#18 2013-07-23 19:30:41

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,672
Website

Re: ÖPNV Vorentwurf (zurückgezogen)

Tirkon wrote:

Wir packen die Haltestellen und die Route pro Fahrtrichtung in dieser Reihenfolge und in Fahrtrichtung sortiert in jeweils eine Relation

Hi, bei der ganzen ÖPVN-Geschichte hat mich eines seit Jahren am meisten gestört:

Warum müssen die Haltestellen eigentlich in aufsteigender Reihenfolge in der Relation aufgeführt werden?

Bei den Strecken ist das nicht nötig, da die Auswertungen sich die Wege selber zusammensuchen. Das sollte für die Haltestellen genau so möglich sein - schließlich liegen sie neben (oder auf?) der Strecke und diese ist "sortiert".

Das nervt mich aus drei Gründen:
- ich muß bei Änderungen der Haltestellen - ab und an kommt schon mal eine hinzu - pingelig drauf achten, diese an der richtigen Stelle einzufügen.

- Ein Sortieren der Member in Josm ist nicht so einfach möglich. Man muß erst den Abschnitt mit den Strecke selektieren und äußerst vorsichtig dabei sein. Hat man erst einmal die Haltestellen "versortet" ist der Mist nicht mehr zu retten. (es sei denn man cancelt)
Daß das Sortieren der Member einer Route durchaus "Lebensqualität" bringt, sollte wohl klar sein.

- aus Prinzip, da sowas in einen System mit Geometrie-Bezug nicht notwendig sein sollte.

Meine Konsequenzen daraus: Ich mappe seit 2011 (?) keine Buslinien mehr.

Ansonsten finde ich diese Aktion aber als höchst positiv, da dadurch viele -aber nicht alle- Hindernisse aus dem Weg geräumt werden.

Gruß
Walter

Offline

#19 2013-07-23 20:01:09

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

Re: ÖPNV Vorentwurf (zurückgezogen)

Tirkon wrote:

Wir packen die Haltestellen und die Route pro Fahrtrichtung in dieser Reihenfolge und in Fahrtrichtung sortiert in jeweils eine Relation: type=pt2, pt2=variant.
Die beiden sich ergebenden Relationen kommen wieder in eine Elternrelation: type=pt2, pt2=master.

Das war es auch schon, was für ein erstes Funktionieren einer Buslinie zwingend notwendig ist.

Das heißt nach dem letzten Proposal type=route und type=route_master
Also hier kann ich keine Vereinfachung erkennen.

Das jetzt keine Stoppositionen erfasst werden müssen/sollen ist soweit in Ordnung. Aber das verhindert eben bei S-Bahnen auch das man angeben kann wo welcher Zug gewöhnlich hält. Da dies aber bei der Stopposition auch nicht genau geregelt war ist es sicher verzichtbar.

Die Stoparea hat jedoch andere Funktionen. Sie soll Masten zusammenfassen, auch wenn diese unterschiedliche Namen haben. Hier wird eine Art Hirachie geschaffen, die man nicht aufgeben sollte. Beim Oxomoa schema gab es dafür mehrere Abstufungen. Als stoparea und stopareagroup. Dei Bedeutung hat sich aber nicht jedem erschlossen.

Was ich hier sehe sind die Möglichkeit Segmente zu integrieren. Das macht es nicht gerade einfacher in der Auswertung/Rendering als auch ist es nicht intuitive warum das so und dort wieder anders steht. Eine Relation je Linienvariante ist nicht nur das einfachste, sondern es ist sämtlichen mir bekannten ÖV-Verwaltungssystemen gängige Praxis. Auch die Dateiaustauchformate wie HAFS, Infopool oder GTFS kennen das nicht anders.

Offline

#20 2013-07-23 20:06:19

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

Re: ÖPNV Vorentwurf (zurückgezogen)

wambacher wrote:
Tirkon wrote:

Wir packen die Haltestellen und die Route pro Fahrtrichtung in dieser Reihenfolge und in Fahrtrichtung sortiert in jeweils eine Relation

Hi, bei der ganzen ÖPVN-Geschichte hat mich eines seit Jahren am meisten gestört:

Warum müssen die Haltestellen eigentlich in aufsteigender Reihenfolge in der Relation aufgeführt werden?

Bei den Strecken ist das nicht nötig, da die Auswertungen sich die Wege selber zusammensuchen. Das sollte für die Haltestellen genau so möglich sein - schließlich liegen sie neben (oder auf?) der Strecke und diese ist "sortiert".

Ist dem wirklich so? Welche Auswerter machen das denn? Beim Rendering spielt es keine Rolle welcher der befahrenen Wege wo steht. Daher kannst du das in keiner Karte wirklich sehen. Die Haltestellen zu sortieren ist vor allem beim mehrfach anfahren kein leichtes unterfangen. Aber als Datenbankprofi fällt dir da vielleicht etwas besseres ein als die bereits vorgegebene Reihenfolge.
Ich dachte das war unteranderem ein Grund warum die Member jetzt in der API mit einer bestimmten Reihenfolge ausgegeben werden.

Offline

#21 2013-07-23 20:29:58

seichter
Member
Registered: 2011-05-21
Posts: 3,149

Re: ÖPNV Vorentwurf (zurückgezogen)

MetiorErgoSum wrote:

Es gäbe bei diesem Modell aber auch andere Probleme, z. B. dass man in den Relationseditoren nicht mehr auf Anhieb sieht, ob die Strecke vollständig erfasst ist; an jeder Haltestelle gibt es einen Sprung. Man müsste dann die Relationseditoren so ändern, dass sie die Haltestellenelemente quasi ignorieren bei ihrer Auswertung, ob ein lückenloser Linienzug besteht. Von Änderungen bei den Auswertungsprogrammen ganz abgesehen.

Nicht mehr auf Anhieb: ja. Geht aber in wenigen Schritten auch mit dem jetzigen JOSM-Relationseditor: Relation kopieren, sortieren und schon sind alle Wege hintereinander. Kopie kann nach Überprüfung weggeworfen werden.
Vom Informationsgehalt her würde ich die Haltestellen zwischen den Ways bevorzugen. Die Version Haltestellen zuerst lässt sich automatisch mit geringem Aufwand erzeugen, umgekehrt geht es nicht. Beim Rendern sieht man den Informationsverlust nicht, da Ways und Haltestellen simpel auf Grund der Koordinaten eingetragen werden. Beim Übergang zu Relationen mit type=pt2 lässt sich das doch wieder so einführen. Die meist (aber nicht immer) genutzte Version Haltestellen zuerst könnte im Relationstyp route (bis zum Aussterben in vielleicht 20 Jahren) so bleiben.

Die Segmente hätte ich sehr gerne als eigenständiges Objekt optional drin. Es gibt Linienbereiche (meist in Nähe Zentralbusbahnhof), in denen ein Dutzend Linien denselben Straßenzug nutzen. Wenn dann dort Umbauten erfolgen, muss man das wenigstens nur an einer Stelle ändern. Redundanz sollte man da vermeiden, wo das mit vernünftigem Aufwand möglich ist.

Generell ist mir nach erstem Durchlesen (mehr darf man von den meisten Nutzern nicht erwarten) nicht gleich klar geworden, wo das alte Proposal abgelöst werden soll und wo es weiter gelten soll.
Was soll z.B. aus den (wenig realisierten) public_transport=stop_position werden?
Aber es soll ja wohl auch nur eine erste Diskussionsgrundlage sein.

Kann der in talk-de erwähnte JOSM-Preset zum Ausprobieren (nicht Hochladen) zur Verfügung gestellt werden? Ich hätte da einige Gemeinheiten im Auge wie Achter-Kurs mit gemeinsamer Strecke, aber Halt nur in einer Richtung.

Was ich noch hilfreich fände, wenn man die Haltestellenart besser kennzeichnen könnte: Bussteig mit Fahrbahn auf beiden Seiten, vom Fußweg abgesetzte Haltestellen (oft auch mit Haltebucht) oder simples Haltestellenschild auf Gehweg oder am Straßenrand. Der Ansatz des Proposals ließe das m.E. ja zu. Der platform-Value ist mir da zu ungenau bis irreführend.

Last edited by seichter (2013-07-23 20:32:03)

Offline

#22 2013-07-23 21:16:57

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

Re: ÖPNV Vorentwurf (zurückgezogen)

wambacher wrote:

Warum müssen die Haltestellen eigentlich in aufsteigender Reihenfolge in der Relation aufgeführt werden?
Bei den Strecken ist das nicht nötig, da die Auswertungen sich die Wege selber zusammensuchen.

Auch die Ways müssen selbstverständlich sortiert sein! Hier gibt es einige Buslinien, bei denen man sonst nicht ermitteln könnte, in welcher Richtung sie zwischendrin ein Stück Kreis fahren.

Offline

#23 2013-07-24 00:06:37

Tirkon
Member
From: Ostfriesland / Germany
Registered: 2009-01-27
Posts: 305

Re: ÖPNV Vorentwurf (zurückgezogen)

rayquaza wrote:
wambacher wrote:

Bei den Strecken ist das nicht nötig, da die Auswertungen sich die Wege selber zusammensuchen.

Auch die Ways müssen selbstverständlich sortiert sein! Hier gibt es einige Buslinien, bei denen man sonst nicht ermitteln könnte, in welcher Richtung sie zwischendrin ein Stück Kreis fahren.

Hier biegen die Überlandlinien bisweilen von der Hauptstraße ab, drehen eine Runde und kommen am gleichen Punkt wieder auf die Hauptstraße zurück. Ohne Reihenfolge der ways ist der Weg nicht mehr zu ermitteln. Das gleiche Problem hat man, wenn der Bus nach einer Schleife seine eigene Route kreuzt.

Das Sortieren und Erfassen der Route und der Haltestellen wird mittlerweile vom JOSM Relationseditor und dem public_transport Plugin recht gut unterstützt.

Last edited by Tirkon (2013-07-24 01:09:30)

Offline

#24 2013-07-24 16:25:40

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

Re: ÖPNV Vorentwurf (zurückgezogen)

Ich würde generell ein Datenmodell bevorzugen, bei dem nur die Haltestellen, aber nicht die verbindenden Wege Teil der Relation sind.
Das entspricht dem Fahrplan der ÖPNV-Anbieter, die auch nicht angeben, über welche Straßen/Weichen/Wasserwege die Verbindung läuft.
Falls doch einmal die Angabe der Fahrstrecke erwünscht ist, könnte man Via-punkte ins Modell aufnehmen.

Vorteile:
- weniger Arbeit beim Erstellen und Bearbeiten
- keine Konflikte beim Bearbeiten des Straßennetzes
- keine Verschachtelung in Segmente nötig
- weniger Aufwand für Fußgängerrouting durch einfaches Datenmodell
- keine widersprüchlichen/unterbrochenen Relationen möglich

Nachteile:
- Kartendarstellung des Linienverlaufs benötigt einen Routingalgorithmus
- keine einfache Überprüfung der Korrektheit

Offline

#25 2013-07-24 18:08:54

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

Re: ÖPNV Vorentwurf (zurückgezogen)

seawolff wrote:

Vorteile:
- weniger Arbeit beim Erstellen und Bearbeiten
- keine Konflikte beim Bearbeiten des Straßennetzes
- keine Verschachtelung in Segmente nötig
- weniger Aufwand für Fußgängerrouting durch einfaches Datenmodell
- keine widersprüchlichen/unterbrochenen Relationen möglich

Nachteile:
- Kartendarstellung des Linienverlaufs benötigt einen Routingalgorithmus
- keine einfache Überprüfung der Korrektheit

Ich traue dem Frieden nicht so ganz. Denn wenn jetzt jemand die Haltestelle löscht ist auch die Information das er daran vorbeikommt weg. Im Zweifel findet der Router ganz andere Wege. Ich sehe das bei größeren ÖPNV Modellen immer wieder, das eine Kurzwegsuche von Haltestelle zu Haltestelle zwar einfach ist, aber das Problem nicht wirklich löst. Über welche Straßen darf denn der Bus? Über welche nicht? Dürfen vielleicht auch nur Linientaxis über die Anwohnerstraße, während die anderen die Bundeststraße fahren. Also du würdest damit viele Informationen einfach aufgeben. Auch Dinge wo wendet ein Bus etc. Von mir also dafür auf jeden Fall ein klares nicht besser!

Offline

Board footer

Powered by FluxBB