ÖPNV Vorentwurf (zurückgezogen)

seawolff · 2013-07-24 21:16:50

viw wrote:

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.

Vor Löschungen ist fast kein Datum in OSM geschützt. Ich sehe eher einen Vorteil für das weglose Modell: wenn im bestehenden Modell eine Haltestelle aus einer Relation gelöscht wird, fällt es in der Linienkarte kaum auf, während eine neue Route ins Auge springt und schnell korrigiert werden kann.

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!

Wo ein Bus/Linientaxi fahren darf, ist durch die access-Tags (speziell "psv") festgelegt.

Mancher Bus nimmt je nach Verkehrslage verschiedene Strecken, das Anruf-Linien-Taxi wendet an anderer Stelle als der Bus und lässt ohne Anforderung manche Umwege aus, der Zug fährt über verschiedene Weichen in den Bahnhof und die Fähre nimmt je nach Wasserstand und Wind unterschiedliche Kurse. Wenn wir eine Variante als Strecke definieren, schaffen wir in vielen Fällen nur eine Pseudoinformation.

Falls der Verlauf wichtig ist, kann man durch einen via-Punkt die Strecke festlegen.

rayquaza · 2013-07-25 00:25:10

seawolff wrote:

Mancher Bus nimmt je nach Verkehrslage verschiedene Strecken, [...] der Zug fährt über verschiedene Weichen in den Bahnhof

Bei Buslinien gibt es (zumindest teilweise) offizielle Fahrtwege, die auch meist eingehalten werden und Züge haben (zumindest in Deutschland) einen Regelweg und ein paar Alternativwege für Störungen, aber wir wollen ja den Normalfall erfassen. ALT sind eh eher wie kostenloses Taxi und zu Fähren kenne ich nicht.

Wie wollte ihr das eigentlich ohne Fahrtweg machen, wenn der Fahrtweg bekannt ist, die Positionen der Haltestellen aber nicht?

Zum ursprünglichen Vorschlag: Ist da nennenswert etwas anders als es momentan genutzt wird? Also ausser den kryptischen neuen Bezeichnungen (und den jetzt hinzugekommenen Segmenten)?

viw · 2013-07-25 05:57:05

seawolff wrote:

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!
Wo ein Bus/Linientaxi fahren darf, ist durch die access-Tags (speziell "psv") festgelegt.

Nein! Ein Accesstag regelt immer nur offizielle Verbote. Es gibt in keinem Fall an wo der Bus am besten durchkommt. Ist es die Erste oder die Zweite Querstraße? Oder ist gar ein Umweg über die Hauptstraße nötig etc. Busse fahren außer auf tertiary auch noch auf residentials und in Busspuren bevorzugt auf services. Da kannst du das PKW routing gleich mal ganz neu entwickeln.

Tordanik · 2013-07-25 10:35:59

seawolff wrote:

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.

+1, ich sehe das prinzipiell als deutlich besseres Konzept an. Die Reihenfolge, in der Haltestellen angefahren werden, ist aus meiner Sicht ohnehin die entscheidende Information - der genaue Fahrtverlauf ist für den Fahrgast nur in den seltenen Fällen wirklich interessant, wo an beliebigen Stellen ein Stopp angefordert werden kann. Und in der Regel dürfte, ggf. mit sehr wenigen "via"-Punkten, auch der Fahrtverlauf eindeutig abzubilden sein.

Als Bonus wird gleich noch getestet, ob das routingrelevante Tagging zwischen den Haltestellen stimmt.

- keine einfache Überprüfung der Korrektheit

Es gibt schon ein Routing-Plugin in JOSM. Das ist zwar momentan ziemlich ... ähm, minimalistisch, aber vielleicht lässt es sich mit GraphHopper-Code oder etwas Fleißarbeit aufpeppen? Man könnte also durchaus im Editor eine Vorschau für die berechnete Strecke umsetzen, das ist kein fundamentales Problem.

viw · 2013-07-25 12:24:50

Tordanik wrote:

- keine einfache Überprüfung der Korrektheit
Es gibt schon ein Routing-Plugin in JOSM. Das ist zwar momentan ziemlich ... ähm, minimalistisch, aber vielleicht lässt es sich mit GraphHopper-Code oder etwas Fleißarbeit aufpeppen? Man könnte also durchaus im Editor eine Vorschau für die berechnete Strecke umsetzen, das ist kein fundamentales Problem.

Gehen wir mal davon aus, dass es im Editor noch klappen würde. Aber beim Rendern? Wenn das alles kein Problem ist warum braucht man dann für jeden zweck eigene Datenstrukturen? Auch Abfragen über die Overpassapi scheitern, wenn der Konkrette Linienverlauf und die beteiligten Wege gefragt sind. Wenn dann noch auf die Stopstellen verzichtet wird, wird es auch schwerer das Lot auf die befahrene Strecke zu fällen. Denn es sind jetzt Punkte neben der eigentlichen Strecke verbunden. Also mich als Anwender der Daten kann das noch gar nicht überzeugen.

Tordanik · 2013-07-25 13:05:19

viw wrote:

Gehen wir mal davon aus, dass es im Editor noch klappen würde. Aber beim Rendern? Wenn das alles kein Problem ist warum braucht man dann für jeden zweck eigene Datenstrukturen?

Ich verstehe nicht, worauf sich dieser Satz bezieht. Wofür braucht man eigene Datenstrukturen?

Auch Abfragen über die Overpassapi scheitern, wenn der Konkrette Linienverlauf und die beteiligten Wege gefragt sind. Wenn dann noch auf die Stopstellen verzichtet wird, wird es auch schwerer das Lot auf die befahrene Strecke zu fällen. Denn es sind jetzt Punkte neben der eigentlichen Strecke verbunden.

Ja, die Overpass API hat das nicht im Funktionsumfang, sondern man bräuchte dann eine der Routing-APIs (wobei bisher leider keine davon ein Bus-Profil hat ). Die Overpass API ist aber doch auch nicht mit dem Zweck angetreten, für alles das richtige Werkzeug zu sein?

Auch der Einwand mit dem Lot ist prinzipiell schon richtig - du würdest dann nicht das Lot auf die befahrene Strecke fällen, sondern auf die umliegenden Straßen, was natürlich mehr Kandidaten ergibt und damit etwas komplizierter, aber vermutlich doch machbar ist.

Oh, und ich persönlich bin übrigens nicht unbedingt gegen das Konzept der Stoppstellen. Ich würde es nur klar optional machen, weil in 90+ % der Fälle die Lage sowieso eindeutig ist.

Also mich als Anwender der Daten kann das noch gar nicht überzeugen.

Anwender überzeugen im Sinne von "das macht es für mich einfacher" wird der Vorschlag sicher nicht. Denn es läuft darauf hinaus, die OSM-Daten übersichtlicher zu machen (nicht nur für ÖPNV-Mapper, sondern auch für die, die einfach nur die von Bussen befahrenen Straßen bearbeiten wollen) und dafür Auswertern, die Fahrtverläufe zeichnen wollen, mehr Arbeit aufzubürden.

Ob das funktionieren könnte, hängt nicht zuletzt davon ab, ob zumindest einige der Auswerter darin einen Sinn sehen und zu so einem Schritt freiwillig bereit sind.

viw · 2013-07-25 14:32:32

Tordanik wrote:

Ja, die Overpass API hat das nicht im Funktionsumfang, sondern man bräuchte dann eine der Routing-APIs (wobei bisher leider keine davon ein Bus-Profil hat ). Die Overpass API ist aber doch auch nicht mit dem Zweck angetreten, für alles das richtige Werkzeug zu sein?

http://overpass-api.de/public_transport.html
Scheint mir doch sehr auf ÖPNV abzuzielen. Die ersten Dinge ließen sich sicher auch aus Haltestellen generieren. Aber ganz unten kann man sich auch die Linienverlauf ansehen. Das würde dann so scheitern, oder?

Geogast · 2013-07-25 19:40:32

MetiorErgoSum wrote:

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

Weiteres Problem: andere Mapper sehen 2 benachbarte ways mit identischen Tags u identischen Relation-Zugehoerigkeiten und machen daraus einen way. Schwer, Nicht-Öffi-Mapper davon abzuhalten.

Geogast · 2013-07-25 19:52:00

Das Konzept "Öffi-Relationen ohne Linien, nur mit Haltestellen" finde ich auch nicht schlecht, zB im Blick auf die neuen Fernbuslinien mit zig Hundert members und wechselndem Fahrtverlauf in Städten (so meine Beobachtung in CE).
In anderen Ländern kann es aber genau andersrum sein: Buslinien in Argentinien werden so gut wie immer ohne Haltestellen gemappt. Das hat den Grund, dass in den zugänglichen ÖPNV-Infos immer nur die befahrenen Straßen angegeben sind (Beispiel), die Haltestellen keine Namen haben und die Busse in so regelmäßigen Abständen halten (meist alle 4 Blocks), dass das auch ausreicht.
will sagen: das herkömmliche Mapping-Konzept muss auf jeden Fall(auch) beibehalten werden. Also 2 Konzepte parallel?!?

Last edited by Geogast (2013-07-25 19:57:23)

Geogast · 2013-07-25 19:52:00

Edit: ups...

Last edited by Geogast (2013-07-25 19:55:35)

DerMario · 2013-07-25 20:11:43

Ein Routingalgorithmus kann nie funktionieren, da oft nicht klar ist, welche Straßen benutzt werden vom Bus. Beispielsweise fährt der Bus bei uns eine Schleife im Ort, obwohl er auch direkt fahren könnte. Niemand von uns weiß, warum er das tut. Die Straßen würden es zulassen und manche Busfahrer tun es auch. OK, man könnte die Fahrer mal fragen...
Aber ein Routenplaner kann das definitiv nicht wissen.

Tschüss DerMario

Geogast · 2013-07-25 20:33:16

DerMario wrote:

Ein Routingalgorithmus kann nie funktionieren, da oft nicht klar ist, welche Straßen benutzt werden vom Bus. Beispielsweise fährt der Bus bei uns eine Schleife im Ort, obwohl er auch direkt fahren könnte. Niemand von uns weiß, warum er das tut. Die Straßen würden es zulassen und manche Busfahrer tun es auch. OK, man könnte die Fahrer mal fragen...
Aber ein Routenplaner kann das definitiv nicht wissen.
Tschüss DerMario

Das wurde jetzt schon oft beantwortet: solche Fälle können mit via-Punkten erfasst werden

Balgofil · 2013-07-25 20:59:22

Ich schließe mich den Meinungen an, dass das punktmässige Erfassen eher schlecht ist. Wenn man weiß wie ein Bus fährt, sollte man auch explizit die Route taggen und sich nicht auf irgendwelche Software verlassen, die schon irgendwie den richtigen Weg finden wird. Gerade die Anzahl der nötigen via-Punkte hängt von der verwendeten Software ab.

Zu dem eigentlichen Vorschlag schließe ich mich rayquazas Meinung an. IMO muss man nur das bestehende Schema um Segmente und Minivars erweitern. Die completeness Tags würde ich nicht verwenden. Diese Information kann man variabler in fixme=* oder note=* ablegen. Der Tag public_transport=any_platform kann auch entfallen, wenn man für die Platform auch Nodes zulässt. Wenn man mehr Informationen zu einer Haltestelle hat, kann man das mit zugehörigen Tags explizit angeben (bench=yes/no, bin=yes/no, shelter=yes/no).
Bei den Namen der Haltestelle würde ich pt2_lookup weg lassen, da eine vernünftige Suche das aus groupname extrahieren kann. Irgendwie finde ich auch die Bezeichnungen subname und groupname nicht sprechend genug. Mir fällt aber gerade nichts besseres ein

Bei der Master Relation frage ich mich, wieso mit vehicle das Fahrzeug getaggt werden soll und nicht wie vorher bus=yes, train=yes etc.

Bei den neuen Relations habe ich jetzt noch nicht wirklich verstanden, was ein minivar ist. In welchen Fällen soll man den nutzen?

Durch konsequente Anwendung der Segmente ließe sich auf jeden Fall die Anzahl der Busrouten für ein Straßenabschnitt deutlich reduzieren. Ich würde dann noch dafür plädieren die Segmente in anderen ÖPNV-Linien zu verwenden. Also wenn Bus 1 und 2 für eine gewisse Zeit dieselbe Strecke befahren, kann man für beide dasselbe Segment verwenden.

seawolff · 2013-07-25 21:22:59

viw wrote:

seawolff wrote:
Über welche Straßen darf denn der Bus? Über welche nicht?
Wo ein Bus/Linientaxi fahren darf, ist durch die access-Tags (speziell "psv") festgelegt.
Nein! Ein Accesstag regelt immer nur offizielle Verbote.

Wieso "Nein!"? Das war doch genau meine Aussage.

seichter · 2013-07-25 22:01:31

Ich stimme dem Vorschlag von seawolff insofern zu, dass es möglich sein soll, eine ÖPNV-Relation anzulegen, auch wenn nur die Haltestellen und deren Abfolge bekannt sind.
Den Verlauf finde ich aber auch wichtig: Ich möchte gerne wissen, von wo z.B. der Bus kommen soll. Den Verlauf durch einen Routingalgorithmus erzeugen zu lassen, halte ich für einen Bruch. Das würde einen festgelegten Standardrouter für alle Editoren und Renderer erfordern. Abgesehen davon fürchte ich, dass speziell in den Innenstädten so viele vias gebraucht würden, dass man gleich die ways nehmen kann.
Wenn man als Kriterium konsequent verwendet "was interessiert den Nutzer", kann man dreiviertel der Einträge in der OSM-DB getrost streichen.

Ebenso sollte es möglich sein, Relationen teilweise nur mit Verlauf anlegen zu dürfen, wenn die genaue Position noch nicht bekannt ist. Ich fände es einen Bärendienst für den Nutzer, eine Haltestelle irgendwohin zu setzen, nur damit ich die Relation vollständig erfassen kann. Was im Moment nicht geht ist, Haltestellen ohne Position, nur in der Abfolge zu erfassen. Damit weiß man, dass da irgendwo eine Haltestelle ist, wenn der Streckenverlauf bekannt ist. Das ist zwar unvollständig und unschön, aber besser als gar keine Information.

seawolff · 2013-07-25 22:17:43

rayquaza wrote:

seawolff wrote:
Mancher Bus nimmt je nach Verkehrslage verschiedene Strecken, [...] der Zug fährt über verschiedene Weichen in den Bahnhof
Bei Buslinien gibt es (zumindest teilweise) offizielle Fahrtwege, die auch meist eingehalten werden und Züge haben (zumindest in Deutschland) einen Regelweg und ein paar Alternativwege für Störungen, aber wir wollen ja den Normalfall erfassen.

In den meisten Fällen ist die Verbindung zweier Haltestellen eindeutig. In den mehrdeutigen Fällen _kann_ der Mapper beim punktbasierten Modell eine Variante festlegen, beim bisherigen Modell _muss_ er eine Variante angeben, auch wenn er den Regelweg des Zuges nicht kennt (kann man den offiziell einsehen und übernehmen?) oder wenn die Strecke von der Verkehrslage oder dem Fahrzeug (Gelenkbus, Kleinbus, Taxi) abhängt.

Wie wollte ihr das eigentlich ohne Fahrtweg machen, wenn der Fahrtweg bekannt ist, die Positionen der Haltestellen aber nicht?

Etwa einen via-Punkt pro unbekannter Haltestelle auf der Strecke setzen.
Der umgekehrte Falll ist häufiger. Man liest im Fahrplan den Ort der Haltestelle, weiß aber nicht, ob der Bus den kürzeren Weg über die Nebenstraße oder den längeren über die Hauptstraße nimmt.

Ich finde, diese Diskussion geht am Kernpunkt vorbei:
Das bisherige Datenmodell erfordert sehr viel Arbeit beim Erstellen der Relationen und (schlimmer) die Kontrolle und Anpassung aller Relationen bei Änderung der Straßentopologie. Straßen mit vielen Relationen sind dadurch kaum noch editierbar.
Weides Modell ist recht elegant, aber verlangt von jedem Mapper, der die Topologie einer Straße mit Buslinie verändert, das Verständnis der dreifach verschachtelten Relationen (Linie, Variante, Segment).
Ein wegloses Modell einfacher zu erzeugen und erlaubt Änderungen der Straßen ohne Berücksichtigung der Busrelationen. Dafür ist der Aufwand zum Erstellen von Linienkarten deutlich größer.

seawolff · 2013-07-25 22:35:46

seichter wrote:

Abgesehen davon fürchte ich, dass speziell in den Innenstädten so viele vias gebraucht würden, dass man gleich die ways nehmen kann.

In den Innenstädten liegen die Haltestellen so dicht, dass es kaum zu Mehrdeutigkeiten kommt.
Bitte mache einen Test mit einem OSM-Router und lege nur die Haltestellen als Start-, Via- und Zielpunkt fest.
Bei meinem Test mittels OpenRouteService.org an der nächstgelegenen Linie ergab sich keine Abweichung im gesamten Verlauf.

rayquaza · 2013-07-26 02:07:16

Also ein Gegenvorschlag von mir: type=segment einführen (wie type=route, aber nur ein Teil davon), Vererbung durchziehen (falls nicht schon gegeben) und falls nötig die Definition des Rests an die tatsächliche Nutzung anpassen.

Neue kryptische Bezeichnungen für Dinge, die wir schon haben sind unnötig und die anderen 80% dieses Thread geht's ja um was anderes (was genauso auf Wanderrouten anwendbar und dort genauso sinnvoll ist)...

viw · 2013-07-26 06:19:36

seawolff wrote:

viw wrote:
seawolff wrote:
Wo ein Bus/Linientaxi fahren darf, ist durch die access-Tags (speziell "psv") festgelegt.
Nein! Ein Accesstag regelt immer nur offizielle Verbote.
Wieso "Nein!"? Das war doch genau meine Aussage.

Es ist und bleibt ein Unterschied ob es erlaubt (access), möglich oder praktikabel ist. Die Möglichkeiten lassen sich vielleicht noch aus den Tags für Breite usw. ablesen. die praktikabilität aber nicht. Gleiches gilt für Abbieger. Wenn eine Kreuzug hinreichend klein ist, wird dort wohl kein Gelenkbus mehr abbiegen können. Aber es wird dort von Behördenseite kein Verbotsschild aufgestellt. Vielmehr sind diese Sachen Bestandteil der Liniengenehmigung. Diese liegen uns jedoch nicht vor, so dass wir stattdessen die gefahrenen Wege erfassen.

seawolff wrote:

rayquaza wrote:
seawolff wrote:
Mancher Bus nimmt je nach Verkehrslage verschiedene Strecken, [...] der Zug fährt über verschiedene Weichen in den Bahnhof
Bei Buslinien gibt es (zumindest teilweise) offizielle Fahrtwege, die auch meist eingehalten werden und Züge haben (zumindest in Deutschland) einen Regelweg und ein paar Alternativwege für Störungen, aber wir wollen ja den Normalfall erfassen.
In den meisten Fällen ist die Verbindung zweier Haltestellen eindeutig. In den mehrdeutigen Fällen _kann_ der Mapper beim punktbasierten Modell eine Variante festlegen, beim bisherigen Modell _muss_ er eine Variante angeben, auch wenn er den Regelweg des Zuges nicht kennt (kann man den offiziell einsehen und übernehmen?) oder wenn die Strecke von der Verkehrslage oder dem Fahrzeug (Gelenkbus, Kleinbus, Taxi) abhängt.

Der Linienweg für Busse ist Besatndteil der Liniengenehmigung. Diese Unterlagen liegen bei der jeweiligen Genehmigungsbehörde vor. Ob diese Unterlagen für jedermann einsehbar sind weiß ich nicht, aber übernehmen darfst du diese mit großer Sicherheit nicht.

rayquaza wrote:

Also ein Gegenvorschlag von mir: type=segment einführen (wie type=route, aber nur ein Teil davon), Vererbung durchziehen (falls nicht schon gegeben) und falls nötig die Definition des Rests an die tatsächliche Nutzung anpassen.
Neue kryptische Bezeichnungen für Dinge, die wir schon haben sind unnötig und die anderen 80% dieses Thread geht's ja um was anderes (was genauso auf Wanderrouten anwendbar und dort genauso sinnvoll ist)...

Das klingt fast nach einer guten Lösung. Hat aber einen bis zwei kleine Haken. Zum einen werden die Relationen nicht einfacher. Das ist aber im Gegensatz zum Vorschlag nur HST zu verwenden immer noch um Welten besser. Das zweite Problem von Weide finde ich jedoch gewichtiger. Heute werden alle Schemata mit type=route bezechnet. Wie aber kann man die teils grundlegend verschiedenen Varianten in der Auswertung unterscheiden?

seawolff wrote:

seichter wrote:
Abgesehen davon fürchte ich, dass speziell in den Innenstädten so viele vias gebraucht würden, dass man gleich die ways nehmen kann.
In den Innenstädten liegen die Haltestellen so dicht, dass es kaum zu Mehrdeutigkeiten kommt.
Bitte mache einen Test mit einem OSM-Router und lege nur die Haltestellen als Start-, Via- und Zielpunkt fest.
Bei meinem Test mittels OpenRouteService.org an der nächstgelegenen Linie ergab sich keine Abweichung im gesamten Verlauf.

Interressant wird doch die Sache an zwei Punkten. Erstens wenn die Haltestelle auf einem Stichweg liegt. Sprich wie verhält sich der Router wenn es günstiger ist, auf der Stelle zu wenden um zur nächsten Haltestelle zu kommen, aber dies nicht möglich ist. Und zweitens lassen sich Viapunkte viel einfacher/unauffälliger löschen als ganze Wege. Zum Beispiel beim vereinfachen von Weggeometrien können Zwischenpunkte automatisch entfernt werden.
Reizvoll wäre das Thema aber auch jeden Fall, da ja keine Wege mehr gesplitet werden müssen.

Last edited by viw (2013-07-26 06:40:36)

rayquaza · 2013-07-26 06:33:31

seawolff wrote:

In den mehrdeutigen Fällen _kann_ der Mapper beim punktbasierten Modell eine Variante festlegen, beim bisherigen Modell _muss_ er eine Variante angeben, auch wenn er den Regelweg des Zuges nicht kennt (kann man den offiziell einsehen und übernehmen?)

Nein, den kann man nicht einsehen, ist aber das, was normalerweise genutzt wird. Also ganz klassisch "wie früher" durch Beobachtung erfassbar. Ausserdem gibt es dank der Rückbauten der DB Netz unter Beachtung von Fahrstrassenausschlüssen, Richtlinien u.Ä. (also Dingen, die Software nicht wissen kann, weil wir sie nicht erfassen (und btw wäre es aufwändiger und bräuchte mehr Relationen)) oft nur einen sinnvollen Fahrweg.

EvanE · 2013-07-26 13:53:55

viw wrote:

... Das zweite Problem von Weide finde ich jedoch gewichtiger. Heute werden alle Schemata mit type=route bezechnet. Wie aber kann man die teils grundlegend verschiedenen Varianten in der Auswertung unterscheiden?

Das alte Schema (alles in einer Relation) einerseits und Oxomoa / das akzeptierte Public Transport Proposal andererseits lassen sich gut unterscheiden.
Nach dem alten Schema erfasste Relationen haben keine Eltern-Relation. Sie haben auch keine Rollen platform und stop für Haltestellen, stattdessen gibt es die Rollen stop_## mit fortlaufenden Nummern ggfs. ergänzt um forward_ / backward_.

Relationen nach dem Oxomoa-Schema und Public Transport Proposal wären im Prinzip am Typ der Eltern-Relationen und den verwendeten Rollen zu unterscheiden. Was jedoch vorkommt, sind unvollständig auf das Public Transport Proposal umgestellte Relationen. Letzteres erschwert das algorythmische Erkennen erheblich.
(Ich hatte seinerzeit vorgeschlagen, die Art des Schema als Tagg zu erfassen. Das erhielt jedoch keine Zustimmung.)

Edbert (EvanE)

Seoman · 2013-07-26 15:18:34

Hi,

ich möchte nur noch mal daran erinnern, dass es auch mindestens eine Anwendung gibt, bei der die Reihenfolge der Haltestellen alleine nicht ausreicht, sondern auch die (feste!) Route inkl. Varianten erfasst sein muss:

Es gibt Buslinien, die - meist abends ab einer bestimmten Uhrzeit - auf Anfrage an jedem Punkt der Route anhalten, sofern das von den Verkehrsregeln her möglich ist. Wenn ich also auf einer solchen Linie aussteigen will, muss ich sehr genau wissen, was ich dem Fahrer als Haltepunkt mitteilen muss. Anders ausgedrückt: Ich muss die Strecken zwischen den Haltestellen genau kennen. Nur dann kann ich dem Fahrer mitteilen: "Lassen Sie mich bitte an der Abc-Straße, Hausnr. 123 aussteigen".

Dafür reicht es meiner Meinung nach nicht, eine ungefähre Route mittels via-Punkten ermitteln zu lassen. Hauptsächlich deshalb, weil Änderungen in der Umgebung der Strecke Auswirkungen haben können. Die Eröffnung einer neuen Straße z.B., die die Verbindung zwischen zwei via-Punkten verkürzt, die der Bus aber trotzdem nicht entlang fährt: Eine automatische Routenberechnung würde das nicht bemerken. Und was noch wichtiger ist: Die Mapper, die die neue Straße einpflegen und die Mapper, die sich um die via-Punkte kümmern, würden in der Regel voneinander gar nichts mitbekommen. Der Mapper der neuen Straße merkt nicht, dass er eine Abkürzung zu einer ÖPNV-Route geschaffen hat, wenn die neue Straße nicht zufällig einen via-Punkt berührt.

Seoman

seawolff · 2013-07-27 00:31:04

Seoman wrote:

Dafür reicht es meiner Meinung nach nicht, eine ungefähre Route mittels via-Punkten ermitteln zu lassen. Hauptsächlich deshalb, weil Änderungen in der Umgebung der Strecke Auswirkungen haben können. Die Eröffnung einer neuen Straße z.B., die die Verbindung zwischen zwei via-Punkten verkürzt, die der Bus aber trotzdem nicht entlang fährt: Eine automatische Routenberechnung würde das nicht bemerken. Und was noch wichtiger ist: Die Mapper, die die neue Straße einpflegen und die Mapper, die sich um die via-Punkte kümmern, würden in der Regel voneinander gar nichts mitbekommen. Der Mapper der neuen Straße merkt nicht, dass er eine Abkürzung zu einer ÖPNV-Route geschaffen hat, wenn die neue Straße nicht zufällig einen via-Punkt berührt.

Es kommt selten vor, dass eine neue Straße die Wege zwischen zwei Haltestellen verkürzt. Wahrscheinlich wird dann die Linienführung geändert oder es werden Haltestellen verlegt. Eine Kontrolle der Buslinien ist immer ratsam. Falls der geschilderte Fall tatsächlich irgendwo vorkommt, würde es im weglosen Modell genügen während der Bauphase der neuen Straße einen via-Punkt auf die alte Strecke zu legen.

Wir diskutieren hier seltsame, pathologische Fälle, aber nicht, woran die Erfassung der Linien bislang gescheitert ist.

Warum erfassen bislang so wenige Mapper Buslinien? Ist der Nutzen unklar, das Datenschema unverständlich, die Editorunterstützung zu schlecht oder die Arbeit beim Erstellen zu viel?

Kann ein durchschnittlicher Mapper eine Straße editieren (z.B. eine Fahrbahnteilung einfügen) ohne die Buslinie zu beschädigen?

Was wollen und was können wir realistisch erreichen und pflegen? Die Hauptvariante jeder Linie, einige Nebenvarianten oder alle Varianten? Nur die Strecken, auch Betriebszeiten und Fahrthäufigkeit oder sogar Abfahrtszeiten?

Wie können zukünftig verfügbare, freie Fahrplandaten in OSM integriert oder verknüpft werden?

Ein Datenschema, dass alle denkbaren Fälle abdeckt, aber von der Mehrheit der Mapper nicht umsetzbar ist, nützt niemandem. Keep it simple!

seawolff · 2013-07-27 00:58:38

viw wrote:

Interressant wird doch die Sache an zwei Punkten. Erstens wenn die Haltestelle auf einem Stichweg liegt. Sprich wie verhält sich der Router wenn es günstiger ist, auf der Stelle zu wenden um zur nächsten Haltestelle zu kommen, aber dies nicht möglich ist. Und zweitens lassen sich Viapunkte viel einfacher/unauffälliger löschen als ganze Wege. Zum Beispiel beim vereinfachen von Weggeometrien können Zwischenpunkte automatisch entfernt werden.
Reizvoll wäre das Thema aber auch jeden Fall, da ja keine Wege mehr gesplitet werden müssen.

Zum ersten Punkt:
Den Routingalgorithmus wird man so einstellen, dass er das Wenden nicht erlaubt oder sehr teuer macht.
Um sicher zu sein, kann der Mapper einen via-Punkt in die Wendeschleife setzen.
Im schlimmsten Fall wäre die Wendeschleife in der ÖPNV-Karte nicht angemalt und die berechnete Linienlänge um diese Strecke zu kurz.

Zum zweiten Punkt:
Der Einwand trifft auf alle Punktobjekte in OSM zu. Bei einer Relation ist zumindest die Historie einsehbar, ein gelöschter POI ist praktisch unauffindbar.
Ich hoffe aber, kein Editor optimiert Punkte weg, die Teil einer Relation sind.

Das Modell wäre vor allem reizvoll, weil es weniger (stupide) Arbeit für den Mapper bedeutet und damit hoffentlich mehr Linien erfasst werden.

rayquaza · 2013-07-27 01:06:07

seawolff wrote:

Wie können zukünftig verfügbare, freie Fahrplandaten in OSM integriert oder verknüpft werden?

Die Tags network=*, ref=*, from=* und to=* sowie via=* sollten für eine Verknüpfung in fast allen Fällen ausreichen. Für die anderen Fälle kann man eine Sonderlösung finden wenn es soweit ist.

Eine Integration der Fahrplandaten in OSM halte ich für nicht sinnvoll, solange es keine speziellen Datentypen dafür gibt und dies nicht von den VU genutzt und entsprechend gepflegt wird (was dann btw auch z.B. Leerfahrten umfassen würde).

seawolff wrote:

Kann ein durchschnittlicher Mapper eine Straße editieren (z.B. eine Fahrbahnteilung einfügen) ohne die Buslinie zu beschädigen?

Kommt drauf an, was ein "durchschnittlicher Mapper" ist. Es ist auf jeden Fall genauso z.B. für Rad- und Wanderrouten gültig.

seawolff wrote:

Warum erfassen bislang so wenige Mapper Buslinien?

Wenn ich mir hier das Verhältnis erfasste Buslinien/erfasste Hausnummern/Hydranten/maxspeed/Neubaugebiete/whatever ansehe: Wir brauchen allgemein mehr Mapper. Die Buslinien sind bei der Liste übrigens hier das vollständigste (was nicht nur an mir liegt).

Announcement

#26 2013-07-24 21:16:50

Re: ÖPNV Vorentwurf (zurückgezogen)

#27 2013-07-25 00:25:10

Re: ÖPNV Vorentwurf (zurückgezogen)

#28 2013-07-25 05:57:05

Re: ÖPNV Vorentwurf (zurückgezogen)

#29 2013-07-25 10:35:59

Re: ÖPNV Vorentwurf (zurückgezogen)

#30 2013-07-25 12:24:50

Re: ÖPNV Vorentwurf (zurückgezogen)

#31 2013-07-25 13:05:19

Re: ÖPNV Vorentwurf (zurückgezogen)

#32 2013-07-25 14:32:32

Re: ÖPNV Vorentwurf (zurückgezogen)

#33 2013-07-25 19:40:32

Re: ÖPNV Vorentwurf (zurückgezogen)

#34 2013-07-25 19:52:00

Re: ÖPNV Vorentwurf (zurückgezogen)

#35 2013-07-25 19:52:00

Re: ÖPNV Vorentwurf (zurückgezogen)

#36 2013-07-25 20:11:43

Re: ÖPNV Vorentwurf (zurückgezogen)

#37 2013-07-25 20:33:16

Re: ÖPNV Vorentwurf (zurückgezogen)

#38 2013-07-25 20:59:22

Re: ÖPNV Vorentwurf (zurückgezogen)

#39 2013-07-25 21:22:59

Re: ÖPNV Vorentwurf (zurückgezogen)

#40 2013-07-25 22:01:31

Re: ÖPNV Vorentwurf (zurückgezogen)

#41 2013-07-25 22:17:43

Re: ÖPNV Vorentwurf (zurückgezogen)

#42 2013-07-25 22:35:46

Re: ÖPNV Vorentwurf (zurückgezogen)

#43 2013-07-26 02:07:16

Re: ÖPNV Vorentwurf (zurückgezogen)

#44 2013-07-26 06:19:36

Re: ÖPNV Vorentwurf (zurückgezogen)

#45 2013-07-26 06:33:31

Re: ÖPNV Vorentwurf (zurückgezogen)

#46 2013-07-26 13:53:55

Re: ÖPNV Vorentwurf (zurückgezogen)

#47 2013-07-26 15:18:34

Re: ÖPNV Vorentwurf (zurückgezogen)

#48 2013-07-27 00:31:04

Re: ÖPNV Vorentwurf (zurückgezogen)

#49 2013-07-27 00:58:38

Re: ÖPNV Vorentwurf (zurückgezogen)

#50 2013-07-27 01:06:07

Re: ÖPNV Vorentwurf (zurückgezogen)

Board footer