Diskussion über Public Transport Version 3

Weide · 2015-10-13 17:31:47

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

seawolff · 2015-10-13 18:09:34

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.

seichter · 2015-10-13 23:20:47

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.

Gino-52 · 2015-10-14 15:43:32

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

viw · 2015-10-14 18:27:28

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.

Swen Wacker · 2015-10-14 19:11:08

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.

Weide · 2015-10-15 10:05:27

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

Gino-52 · 2015-10-15 12:57:16

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

Augustus Kling · 2015-10-15 18:26:29

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.

Weide · 2015-10-15 19:29:43

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

Swen Wacker · 2015-10-15 19:35:10

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.

Last edited by Swen Wacker (2015-10-15 19:36:50)

Weide · 2015-10-15 21:10:35

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

Last edited by Weide (2015-10-15 21:11:40)

Gino-52 · 2015-10-16 13:38:17

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

Swen Wacker · 2015-10-16 13:58:30

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.

Augustus Kling · 2015-10-18 14:44:35

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.

Polyglot · 2015-10-18 15:04:27

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

Augustus Kling · 2015-10-18 15:51:56

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?

Polyglot · 2015-10-18 17:52:50

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

Augustus Kling · 2015-10-18 21:22:37

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.

Weide · 2015-10-19 13:09:04

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

rayquaza · 2015-10-19 14:18:04

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.

Augustus Kling · 2015-10-19 20:01:45

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.

mmd · 2015-10-19 20:20:22

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

Last edited by mmd (2015-10-20 18:10:41)

Weide · 2015-10-20 05:55:25

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

seawolff · 2015-10-20 17:58:57

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

Announcement

#26 2015-10-13 17:31:47

Re: Diskussion über Public Transport Version 3

#27 2015-10-13 18:09:34

Re: Diskussion über Public Transport Version 3

#28 2015-10-13 23:20:47

Re: Diskussion über Public Transport Version 3

#29 2015-10-14 15:43:32

Re: Diskussion über Public Transport Version 3

#30 2015-10-14 18:27:28

Re: Diskussion über Public Transport Version 3

#31 2015-10-14 19:11:08

Re: Diskussion über Public Transport Version 3

#32 2015-10-15 10:05:27

Re: Diskussion über Public Transport Version 3

#33 2015-10-15 12:57:16

Re: Diskussion über Public Transport Version 3

#34 2015-10-15 18:26:29

Re: Diskussion über Public Transport Version 3

#35 2015-10-15 19:29:43

Re: Diskussion über Public Transport Version 3

#36 2015-10-15 19:35:10

Re: Diskussion über Public Transport Version 3

#37 2015-10-15 21:10:35

Re: Diskussion über Public Transport Version 3

#38 2015-10-16 13:38:17

Re: Diskussion über Public Transport Version 3

#39 2015-10-16 13:58:30

Re: Diskussion über Public Transport Version 3

#40 2015-10-18 14:44:35

Re: Diskussion über Public Transport Version 3

#41 2015-10-18 15:04:27

Re: Diskussion über Public Transport Version 3

#42 2015-10-18 15:51:56

Re: Diskussion über Public Transport Version 3

#43 2015-10-18 17:52:50

Re: Diskussion über Public Transport Version 3

#44 2015-10-18 21:22:37

Re: Diskussion über Public Transport Version 3

#45 2015-10-19 13:09:04

Re: Diskussion über Public Transport Version 3

#46 2015-10-19 14:18:04

Re: Diskussion über Public Transport Version 3

#47 2015-10-19 20:01:45

Re: Diskussion über Public Transport Version 3

#48 2015-10-19 20:20:22

Re: Diskussion über Public Transport Version 3

#49 2015-10-20 05:55:25

Re: Diskussion über Public Transport Version 3

#50 2015-10-20 17:58:57

Re: Diskussion über Public Transport Version 3

Board footer