ÖPNV Bus stop_position

Trockennasenaffe · 2017-05-02 13:06:10

Ich habe mich mit den Ptv3 Linien auseinander gesetzt. Leider verstehe ich die nicht ganz glaube ich. Im Grunde wie Ptv2 aber da werden irgendwie Nodes als Marker eingefügt, und dann ist die Relation auch ohne Sortierung eindeutig? Wie genau müssen die Marker gewählt werden?

Weide · 2017-05-02 19:27:42

Trockennasenaffe wrote:

Im Grunde wie Ptv2 aber da werden irgendwie Nodes als Marker eingefügt, und dann ist die Relation auch ohne Sortierung eindeutig?

Ja.

Trockennasenaffe wrote:

Wie genau müssen die Marker gewählt werden?

(Erstmal einer vorn und einer hinten damit man auch unbekannte Stücke am Anfang oder Ende darstellen kann. Das ging in PTv2 nicht.)

Die anderen braucht man die Marken zum Trennen der Abschnitte. Ein Abschnitt ist entweder ganz leer (er fehlt also) oder er bildet einfache Linie zwischen den Marken, die sich selbst nicht berührt und in der nichts fehlt.

Bei vielen Buslinien hat man nur einen Abschnitt.

Wenn eine Schleife drin ist, dann kommt eine Marke in die Schleife, dann enthält keiner der beiden Abschnitte eine Mehrdeutigkeit in der Reihenfolge.

So kann immer innerhalb jedes Abschnitts automatisch sortiert werden. Splitten einer Linie an einem Punkt ist kein Problem mehr. Längssplitten einer Linie in zwei parallele oneways fällt sofort auf. Verkürzen einer Linie oder Zusammenfassen mit bisher nicht dazu gehörenden fällt ebenfalls sofort auf. Falsche Einbahnstraßenbenutzung ebenfalls.

Trockennasenaffe · 2017-05-02 20:11:16

Weide wrote:

Wenn eine Schleife drin ist, dann kommt eine Marke in die Schleife, dann enthält keiner der beiden Abschnitte eine Mehrdeutigkeit in der Reihenfolge.
So kann immer innerhalb jedes Abschnitts automatisch sortiert werden. Splitten einer Linie an einem Punkt ist kein Problem mehr. Längssplitten einer Linie in zwei parallele oneways fällt sofort auf. Verkürzen einer Linie oder Zusammenfassen mit bisher nicht dazu gehörenden fällt ebenfalls sofort auf. Falsche Einbahnstraßenbenutzung ebenfalls.

Ok hier war mein Denkfehler: Die Wege und Knoten müssen weiterhin sotiert sein. Nur wenn zwischen zwei Knoten etwas durcheunander gerät, kann es so wieder automatisch sortiert werden. Man kann aber nicht die knoten und wege beliebig durcheianderwürfeln.

krza · 2017-05-02 21:17:53

Das ist mir zu hoch Jedenfalls so in Textform.

Weide · 2017-05-02 21:48:52

krza wrote:

Das ist mir zu hoch wink Jedenfalls so in Textform.

In Punkt 1.4 der Intro ist ein Beispiel. Das ist allerdings zugegebenermaßen mit heißer Nadel gestrickt, weil ich die neue Fassung ohne Segmentrelationen nicht ohne Beispiele machen wollte. Da ist bestimmt noch Luft für Verbesserungen...

Weide · 2017-05-03 13:03:31

Weide wrote:

Da ist bestimmt noch Luft für Verbesserungen...

Ein paar Verbesserungen (hoffe ich jedenfalls) habe ich gerade auf gafte.de hochgeladen. Die "-in" und "-out" suffixe für "pio"s sind auch drin (allerdings nicht in der Intro).

Trockennasenaffe · 2017-05-03 15:44:33

Eine gute Erläuterung ist essentiell für die Akzeptanz. Wenn es ernster wird am besten auch noch auf deutsch.

miche101 · 2017-05-03 16:03:36

Trockennasenaffe wrote:

Eine gute Erläuterung ist essentiell für die Akzeptanz.

...nicht nur das, aber auch wichtig!

Man braucht auch Anwendungen dazu, wo man sieht was man damit alles tolles machen kann. So fantastische Dinge Wo man sagt: "Ja, cool... was da alles geht.. das will ich auch!"

Daran mangelt es.. für das was heute geht genügt PTv1 ein Netzplan..

Trockennasenaffe · 2017-05-03 17:46:19

Ich habe mich in letzter Zeit viel mit freien Verkehrsdaten beschäftigt. Ich stelle mir da die Frage, nach dem Zusammenspiel mit PTv3. Auf der einben Seite geben immer mehr Unternehmen ihre Daten frei. Auf der anderen Seite wissen wir, dass Erfassung und Pflege von ÖPNV Daten in OSM sehr aufwendig ist und daher nur von wenigen gemacht wird. Ich denke daher, dass der Erfolg vom PTv3 auch entscheident davon abhängen wird, in wieweit man die Freien Daten dazu nutzen kann. Dazu müssten die Konzepte zusammenpasst. Bei Bushaltestellen gibt es meist Daten zu Haltestellenmasten. Das sind die Schilder die die Halteposition markieren. Davon gibt es meistens mehrere pro Haltestelle. Die haben in der Regel Koordinaten und diverse globale und lokale Referenznummern. Das ließ sich mit PTv2 als public_transport=Platform als node moderiere. Bei aussteigen mit mehreren Masten oder räumlich sehr ausgedehnten gab es da aber schon ein Problem. Wie sieht das mit PTv3 aus?

Zu den anderen freien Daten schreibe ich ein andermal etwas.

krza · 2017-05-03 20:01:44

Wie schon oben gesagt: Die Masten halte ich persönlich für völlig überflüssig. Die Positionsinformation stellt keinen Mehrwert für die Haltestelle selbst dar. Wenn man die Masten aus irgendeinem Grunde taggen möchte, dann sollte man ein Tag verwenden, das explizit einen Mast bezeichnet. Mit Plattformen, Ausstiegen, Haltepositionen haben die Dinger aber für gewöhnlich nichts zu tun. Dann stünden sie in vielen Fällen auch ziemlich im Weg. Meine kleine Meinung. Aber ich stimme TNA insofern zu, dass kompatible und konsistente Systeme entstehen müssen.

Bezüglich Akzeptanz und Beispielen ... ich habe die Beispiele in Revision 1984* der Introduction nochmal ganz kurz überflogen. Im Zusammenspiel mit den Texten von weiter oben dämmert es mir langsam. Ob ich den Aufwand-Nutzen-Vorteil schon sehe ... hm. mal gucken. Spontan macht es die Sache für mich unnötig komplizierter, wenn es nur um das Sortieren geht. Man muss nämlich noch mehr aufpassen und nicht weniger.

*) uuh ... was will uns der Autor damit sagen ...

Weide · 2017-05-03 21:48:44

krza wrote:

...in Revision 1984* der Introduction...

Aiiii. Da muss dringend nochmal einen Tippfehler suchen :-)

slhh · 2017-05-04 01:27:03

Damit sich der Aufwand lohnt, solllte ein PTv3 zwingend auch folgendes ermöglichen:

- Eine Erweiterung von iD muss möglich sein, damit deren typische Nutzer auch PT zumindest in Standardfällen editieren können. Für PTv2 sehe ich das schicht als unmöglich an. Einbau JOSM-artiger Funktionen lößt das Problem nicht, da auch mit JOSM nur PT-Experten dies können, also nicht gerade der typische iD-User. Wir sollten da mehr an grafische Eingabemöglichkeiten denken. Im Falle der atomaren Segmente würde ich dies für machbar halten.

- Die Highways müssen von der Vielzahl an Relationen befreit werden, um Schäden bei der Bearbeitung einfach korrigieren zu können.

- Die Variantenverwaltung muss mit deutlich weniger Redundanz erfolgen. Die Variantenrelationen sind schwer zu bezeichnen und damit schlecht zu identifizieren.

Weide wrote:

Die Segmente sind übrigens wieder rausgeflogen weil sich in Tests (natürlich nicht im OSM-Datenbestand) herausgestellt hat, dass ich mit dem Erfinden von benutzbaren Segmentbezeichnern im praktischen Editierbetrieb überfordert war.

Ein Verzicht auf Segmente ist aber auch nicht wirklich eine Lösung, da die highways nicht von der Vielzahl der Routenrelationen entlastet werden.

Das Problem mit der Segmentbezeichnung habe ich erwartet. Unter anderem deshalb habe ich für meinen Vorschlag der atomaren Segmente die Trennung an die Haltestellen gelegt. Dann kann man ggf. sogar automatisch eine sinnvolle Bezeichnung für das Segment aus den Haltestellennamen der Segmentenden bilden, um das Segment im Relationseditor anzuzeigen. Da bei meiner Variante die Segmente nur in extremen Ausnahmefällen in die Route müssen, ist diese Bezeichnung dabei ohnehin etwas unwichtiger.

Bei Bedarf kann man die Segmente auch etwas weniger atomar machen und Zwischenhalte zulassen.

Es wäre möglich, die Segmente automatisch im Editor in die Linenrelation als Member aufzunehmen, oder, die benötigten Segmente erst bei der Auswertung per Datenbankabfrage zu ermitteln. Man kann die zweite Methode auch als Rückfallebene bei der Auswertung nutzen, wenn die erste Methode ein fehlerhaftes Resultat liefert.

krza wrote:

Die Masten halte ich persönlich für völlig überflüssig. Die Positionsinformation stellt keinen Mehrwert für die Haltestelle selbst dar.

Man könnte die Masten vielleicht als Landmarke zur Orientierung im Haltestellenbereich ansehen, ansonsten sind sie wohl eher nutzlos.

krza wrote:

Mit Plattformen, Ausstiegen, Haltepositionen haben die Dinger aber für gewöhnlich nichts zu tun.

Da würde ich eine Abhängigkeit nicht ausschließen, jedoch ist dies wohl eher von lokalen Geflogenheiten abhängig. Somit ist die Information in einer globalen Datenbank nutzlos, zumindest wenn man nicht die Lage dieser Bereiche relativ zum Mast durch Tags definiert.

miche101 · 2017-05-04 11:45:54

Wenn man sich Relation "generieren" lassen könnte.. anhand einer sortierten Liste an Bushaltestellen die angefahren werden, würd die Sache auch leichter machen...

z.B.
http://greymiche.lima-city.de/osm_buslinie/output.html

kommt dann sowas raus wenn man da eine Variante zusammenklickt:
https://graphhopper.com/maps/?point=48. … =Omniscale

Trockennasenaffe · 2017-05-04 11:49:19

krza wrote:

Wie schon oben gesagt: Die Masten halte ich persönlich für völlig überflüssig. Die Positionsinformation stellt keinen Mehrwert für die Haltestelle selbst dar. Wenn man die Masten aus irgendeinem Grunde taggen möchte, dann sollte man ein Tag verwenden, das explizit einen Mast bezeichnet. Mit Plattformen, Ausstiegen, Haltepositionen haben die Dinger aber für gewöhnlich nichts zu tun. Dann stünden sie in vielen Fällen auch ziemlich im Weg. Meine kleine Meinung.

Ich habe mir die Diskussion nicht von Anfang an durchgelesen, sondern nur alles ab dem neuen PTv3 Entwurf.
Dass Die Verkehrsunternehmen auf Basis von Masten arbeiten muss man nicht gut finden, ist aber so. Die Mastdaten stehen dabei aber auch repräsentativ für die einzelne Haltestelle.
Letztendlich sind es aber auch die Haltestellenmasten, die eine Haltestelle in der realen Welt ausmachen. Im einfachsten und durchaus gängigen Fall ist eine Bushaltestelle aus physischer Sicht nur ein Haltestellenmast, der an der Straßen steht. Das ist oft das einzige, das der Fahrgast von der Haltestelle sieht und zwar schon von weiter weg. Daran stehen die essentiellen Informationen wie Haltestellenname, Linien und Richtung. Dort kommt auch in der Regel die Spitze des Busses zum Halten. Es sollte daher in den meisten fällen der Ort sein, zu dem die Fahrgäste geroutet werden wollen und wo ein Icon auf der Karte erscheinen soll. Ob der Mast hingegen als physisches Objekt gemappt werden sollte, da habe ich auch zweifel.

Weide · 2017-05-04 19:36:46

Trockennasenaffe wrote:

Ich habe mich in letzter Zeit viel mit freien Verkehrsdaten beschäftigt. Ich stelle mir da die Frage, nach dem Zusammenspiel mit PTv3. Auf der einben Seite geben immer mehr Unternehmen ihre Daten frei. Auf der anderen Seite wissen wir, dass Erfassung und Pflege von ÖPNV Daten in OSM sehr aufwendig ist und daher nur von wenigen gemacht wird. Ich denke daher, dass der Erfolg vom PTv3 auch entscheident davon abhängen wird, in wieweit man die Freien Daten dazu nutzen kann.

PTv3 ist eigentlich nur der Versuch, aus den Erfahrungen mit einigen Jahren PTv2 etwas zu machen, das weniger fehleranfällig ist, mehr Support durch Editoren erlaubt und mehr Fälle abdeckt. Über den Zweck habe ich dabei ehrlich gesagt wenig nachgedacht ... vielleicht auch weil OSM ohnehin nicht zum Löschen von Daten neigt :-)

Ich kann mir zwar vorstellen, dass freigegebene Daten an Routen koppelbar sind, aber spätestens bei den Verspätungsdaten wird an Haltestellen angekoppelt ("Der IC hält daher heute nicht in Düsseldorf Hbf und Duisburg Hbf, sondern in Solingen Hbf" ist etwas, für dass wir dann keine passende Route hätten). Damit wären PTv2/PTv3-Daten überflüssig.

Routendaten bräuchten wir dann nur zum Erstellen von Netzplänen. PTv1 ist aber i.W. ein Netzplan. Dabei bräuchte man einige Ergänzungen, denn PTv1 kann keine linien- und flächenförmigen Haltestellen. Andererseits könnten die im Vorfeld der Entstehung von PTv2 entstandenen Rollentricks wie "alternate_forward_stop:17" rausfliegen, denn derartige Informationen kann man nicht wirklich vernünftig in PTv1 unterbringen. Ein solches "PTv1.5" würde wieder mit einer Relation pro Linie auskommen und bräuchte nur die Rollen "halt", "way", "forward_way" und "backward_way" ohne irgendwelche Modifikatoren.

Trockennasenaffe · 2017-05-04 20:08:59

Ich denke wenn jemand alle Varianten in PTv2 Mappen will soll ihn niemand davon abhalten. Wie wäre es wenn man parallel dazu für Linien wo das zu komplex ist, für eine schnelle Ersterfassung oder für Mapper die sich nicht die Mühe machen möchten ein PTv2 light oder von mir aus PTv1.5 anbieten würde?

Last edited by Trockennasenaffe (2017-05-04 20:09:40)

Announcement

#151 2017-05-02 13:06:10

Re: ÖPNV Bus stop_position

#152 2017-05-02 19:27:42

Re: ÖPNV Bus stop_position

#153 2017-05-02 20:11:16

Re: ÖPNV Bus stop_position

#154 2017-05-02 21:17:53

Re: ÖPNV Bus stop_position

#155 2017-05-02 21:48:52

Re: ÖPNV Bus stop_position

#156 2017-05-03 13:03:31

Re: ÖPNV Bus stop_position

#157 2017-05-03 15:44:33

Re: ÖPNV Bus stop_position

#158 2017-05-03 16:03:36

Re: ÖPNV Bus stop_position

#159 2017-05-03 17:46:19

Re: ÖPNV Bus stop_position

#160 2017-05-03 20:01:44

Re: ÖPNV Bus stop_position

#161 2017-05-03 21:48:44

Re: ÖPNV Bus stop_position

#162 2017-05-04 01:27:03

Re: ÖPNV Bus stop_position

#163 2017-05-04 11:45:54

Re: ÖPNV Bus stop_position

#164 2017-05-04 11:49:19

Re: ÖPNV Bus stop_position

#165 2017-05-04 19:36:46

Re: ÖPNV Bus stop_position

#166 2017-05-04 20:08:59

Re: ÖPNV Bus stop_position

Board footer