ÖPNV Bus stop_position

Damit Router wissen wo die Bushaltestelle ist. Das kann der nicht wissen wenn sich der Node neben der Straße befindet, weil er dann irgendeine Heuristik bräuchte um festzustellen welche Straße dem Node am nächsten ist und da kann es gerade in städtischen Gebieten viele false positives geben, oder auch das Gegenteil der Router merkt gar nicht dass er schon längst an der Bushaltestelle vorbei ist.

huby1691 wrote:

Für mich nur verständlich als vereinfachte Version, wenn man nicht pro Richtung eine Haltestelle ("platform") neben der Straße einzeichnen möchte.

stop_position ist die Halteposition des Busses (auf der Straße), platform ist dort wo der Fahrgast z.B. wartet (neben der Straße).
Beides ergänzt sich also und beschreibt zwei verschiedene Dinge.

Die Sketchline müsste so geändert werden, dass wenn beides vorhanden ist, die Haltestelle trotzdem nur einmal auftaucht.

Prince Kassad wrote:

Damit Router wissen wo die Bushaltestelle ist.

Welcher Router arbeitet denn mit Bushaltestellen?

whb wrote:

stop_position ist die Halteposition des Busses (auf der Straße)

Dieses ist für mich nur ein virtueller Punkt, der von der Position der platform abhängig ist und somit keine zusätzliche Information.

huby1691 wrote:

Welcher Router arbeitet denn mit Bushaltestellen?

Zum Beispiel die Anzeigen in den Bussen, die sagen, welche Haltestelle die nächste ist. Es ist nicht undenkbar, dass solche Anwendungen heute oder auch in Zukunft auf OSM-Basis arbeiten werden.

huby1691 wrote:

und in der Public-Transport Sketch-Line tauchen die Haltestellen doppelt auf.

Die Public-Transport Sketch-Line ist einfach kaputt. Es wird behauptet, dass sie Public-Transport v2 kann, tut sie aber nicht und dass schon seit einer Ewigkeit.

huby1691 wrote:

Dieses ist für mich nur ein virtueller Punkt, der von der Position der platform abhängig ist und somit keine zusätzliche Information.

Die Stopposition liefert in einigen Fällen durchaus zusätzliche Informationen. Bus- und Bahnsteige können recht lang sein und manchmal kann vorne oder hinten gehalten werden oder auf beiden Seiten. Es ist zudem nicht zwingend erforderlich, sowohl plattform als auch stop-position zu mappen um PTv2 kompatibel zu sein. Es reicht eins von beiden und kann bei sehr einfachen Verhältnissen auch sinnvoll sein.

huby1691 wrote:

Welcher Router arbeitet denn mit Bushaltestellen?

Das aktuelle "public-transport"-Schema wurde meines Wissens nach mit dem Ziel entwickelt, weitergehende Routingfähigkeit für Verkehrsunternehmen und Verbindungsauskunftsanwendungen zu bieten, was bisher nur mit zusätzlichen, meist proprietären Daten möglich ist. Soweit ich weis wird davon allerdings noch nirgendwo in nennenswertem Umfang gemacht und es ist auch unklar, ob das Schema dafür besonders geeignet ist, da sich noch kein Verkehrsunternehmen oder Anwender dazu geäußert hat. Falls ich da falsch liege bitte korrigieren.

huby1691 wrote:

Es ist damit keine zusätzliche Information vorhanden, mit Bus-Routen hat man doppelte Arbeit, um sowohl "stop_position" als auch "platform" einzusortieren und in der Public-Transport Sketch-Line tauchen die Haltestellen doppelt auf.

Ohne deine Route jetzt im Detail zu kennen, klingt es für mich danach, dass du "highway=bus_stop" und "public_transport=platform" an einem und dem selben Node getaggt hast. Das mag das Line Diagram leider nicht, da er als erstes alle "highway=bus_stop" intern zu einem "stop" übersetzt.

Nur␣Node␣"pt=stop_position"␣=>␣OK
Nur␣Node␣"pt=platform"␣=>␣OK
Node␣"pt=stop_position"␣und␣Node␣"pt=platform"␣=>␣OK
Node␣"pt=stop_position+␣hw=bus_stop"␣und␣Node␣"pt=platform"␣=>␣OK
Node␣"pt=stop_position"␣und␣Node␣"pt=platform␣+␣hw=bus_stop"␣=>␣FEHLER

Hubert87 wrote:

huby1691 wrote:

Es ist damit keine zusätzliche Information vorhanden, mit Bus-Routen hat man doppelte Arbeit, um sowohl "stop_position" als auch "platform" einzusortieren und in der Public-Transport Sketch-Line tauchen die Haltestellen doppelt auf.

Ohne deine Route jetzt im Detail zu kennen, klingt es für mich danach, dass du "highway=bus_stop" und "public_transport=platform" an einem und dem selben Node getaggt hast.

So wird es sein. Das ist gängige Praxis und zulässig, solange es nur ein highway=bus_stop pro platform/stop_position-Paar gibt. Wenn es beides gibt, gehört das dann optionale highway=bus_stop sogar an die platform-Node. Wenn die Software damit nicht klar kommt, ist sie fehlerhaft.

huby1691 wrote:

Es ist damit keine zusätzliche Information vorhanden, mit Bus-Routen hat man doppelte Arbeit, um sowohl "stop_position" als auch "platform" einzusortieren und in der Public-Transport Sketch-Line tauchen die Haltestellen doppelt auf.

Ja. Da ist viel überflüssig. Das ist geschichtlich gewachsen und es haben sich Missverständnisse etabliert.

Es gab damals nur den "highway=bus_stop"-Node. Wenn der nur für eine Richtung war, dann haben einige Mapper ihn damals neben die Straße gelegt und andere haben ihn mit einem "direction=NW" oder "dir=NW" drauf gelassen. Außerdem kamen Mapper auf die Idee, die Objekte neben der Straße als Linie oder Fläche zu mappen, was mit den damaligen Routen einfach nicht ging weil alle Haltestellen da Nodes sein mussten. Also hat man beim Neuentwurf daraus zwei Objektarten gemacht: "stop" und "platform". Diejenigen, die Objekte neben die Straße legen wollten, konnten sie mit der Rolle "platform" in die neuen Routen eintragen und diejenigen, die sie auf die Straße legen wollten, konnten sie mit der Rolle "stop" eintragen. Wenn jemand das jeweils andere Objekt ergänzen wollte, dann konnte er ja nicht ein zweites highway=bus_stop nehmen. Deshalb wurde zusätzlich public_transport=platform bzw. stop_position definiert. In die alten Routen kam aber immer nur der highway=bus_stop-Node mit keiner Rolle oder der Rolle "stop".

Das war eigentlich nicht schlecht, es kam aber zu Missverständnissen. Manche meinten, dass man das alte Tag durch die neuen ersetzen müsste oder dass überall die neuen Tags zusätzlich dran müssten oder dass überall beide Angaben zu einer Haltestelle gemappt sein müssten oder dass das highway=bus_stop nur noch das Haltestellensymbol aber keine Haltestelle definiert. Das ist alles falsch! Insbesondere ist highway=bus_stop immer ein Node und kann als "stop" oder als "platform" benutzt werden.

Diese Missverständnisse haben zu vielen überflüssigen Einträgen geführt. Sehr oft haben wir zwei stop_positions, zwei platforms und eine zusammenfassende stop_area-Relation, die insgesamt kein bischen mehr sagen als ein einfacher Node auf der Straße, der nur highway=bus_stop und name=xxx hat.

Weide

Trockennasenaffe wrote:

Wenn es beides gibt, gehört das dann optionale highway=bus_stop sogar an die platform-Node.

Es gibt tatsächlich auch noch den exotischen Fall, dass er ausnahmsweise nicht dahin gehört. Wenn zwei Platforms sich denselben stop teilen und eine platform kein Punkt ist, dann kann das highway=bus_stop nur an den stop-Node. Dann kann er aber für die Gegenrichtung nicht mehr an den platform-Node.

Weide

Weide wrote:

Diese Missverständnisse haben zu vielen überflüssigen Einträgen geführt. Sehr oft haben wir zwei stop_positions, zwei platforms und eine zusammenfassende stop_area-Relation, die insgesamt kein bischen mehr sagen als ein einfacher Node auf der Straße, der nur highway=bus_stop und name=xxx hat.
Weide

Diese Missverständnisse sind ja hauptsächlich dadurch entstanden, dass dies so nirgendwo verständlich dokumentiert war. Deshalb habe ich in diesem Bereich viele Fehler gemacht (und mache sie wahrscheinlich immer noch).
Mir war bisher nicht klar, dass "highway=bus_stop" und platform als doppelte Haltestelle erscheinen, wenn wenn platform als way und bus_stop in diesem way als node eingetragen ist.

Dieses Durcheinander lässt mich eigentlich nur wieder dafür plädieren, auf bus_stop ganz zu verzichten und sich nur noch auf ptv2 zu konzentrieren oder aber sich wirklich mal dran zu setzen und eine pt-Version zu konzipieren, die alles andere ersetzt und zukunftsfähig ist.

Wenn ich mich recht erinnere, hattest Du mal an einem ptv3 gearbeitet. Davon hört man leider gar nichts mehr. Grund ist wohl auch, dass man versucht auf v1 und v2 Rücksicht zu nehmen, statt vollkommen NEU zu konzipieren, statt sie über längere Zeit parallel lassen zu können. Ja, das gäbe bei älteren Auswertungstools sicherlich Probleme, aber ein langfristiger sukzessiver Austausch von v1 und v2 mit v3 oder v4 wäre sicherlich möglich.

Thoschi wrote:

Dieses Durcheinander lässt mich eigentlich nur wieder dafür plädieren, auf bus_stop ganz zu verzichten und sich nur noch auf ptv2 zu konzentrieren oder aber sich wirklich mal dran zu setzen und eine pt-Version zu konzipieren, die alles andere ersetzt und zukunftsfähig ist.

Bin auch der Meinung, wenn etwas bei ÖPNV passieren soll (Aktualität) dann sollte ein "System" anwendungsbereit dokumentiert werden. Somit würden auch schnell alle ptv1 aktualisiert werden. Gibt es überhaupt Nutzer von ptv1?

Thoschi wrote:

...auf bus_stop ganz zu verzichten...

Das ist echt schwierig: Man steht dann als dann als Kartenersteller auf dem Schlauch. Die Haltestelle sollte dargestellt werden. Es kann nur ein stop da sein, es kann nur eine platform da sein, es können aber auch beide da sein. Die Pärchen sind aber nur in den Routen erkennbar. Vor Ort können auch zu einem stop zwei platforms gehören oder umgekehrt. Sogar 1:3- und 1:4 - Beziehungen können vorkommen. Da ist es viel einfacher, das Symbol an das highway=bus_stop zu machen.

Thoschi wrote:

Wenn ich mich recht erinnere, hattest Du mal an einem ptv3 gearbeitet. Davon hört man leider gar nichts mehr.

Ja. Seit unserem Treffen in Dortmund vor zwei Jahren damals habe ich es aber deutlich vereinfacht (hoffe ich jedenfalls :-) ). Es liegt auf http://gafte.de/

Im Prinzip werden dabei die alten Sachen komplett neu hinzugefügt und die alten Sachen werden als ersetzt markiert, so dass das Neue von Anfang an angezeigt werden kann ohne dass irgendwas doppelt dargestellt oder doppelt ausgewertet wird.

Reaktionen habe ich gar keine -- weder positiv noch negativ -- was mich vermuten lässt, dass ich mal wieder nicht ausreichend verständlich formuliert habe :-(

geri-oc wrote:

Gibt es überhaupt Nutzer von ptv1?

Nicht viele, aber es gibt sie. Wir haben mancherorts Altbestände und aus ein bischen Wissen über die Buslinie ("Der fährt hier durch und biegt da hinten recht ab") kann man einigermaßen leicht eine PTv1-Relation machen oder ergänzen. Bei PTv2 sind "Informationsschnipsel" schwer zu verarbeiten. Manche Leute haben aber auch einfach die Nase voll von der ganzen Verwirrung und nehmen deshalb das alte Schema.

geri-oc wrote:

...dann sollte ein "System" anwendungsbereit dokumentiert werden.

Ja. Aber das ist -- für mich jedenfalls -- ein echt frustrierendes Thema. Es tauchen ständig mit PTv2 unvereinbare Dinge in den Wikis als PTv2-Eigenschaften auf. Da wird nachträglich der Abstimmungstext von PTv2 geändert, bei railway=station steht drin, man könnte da public_transport=station hinzufügen, im public transport wiki steht "Stops sind Pflicht". Ich mache da nichts mehr und mappe auch nicht mehr in Gegenden und Bereichen, in denen es Konflikte gibt.

Weide

Gibt es denn derzeit eine Wiki, die einen "korrekten" PTv2-Ansatz beschreibt? Hier kann man sicher darüber streiten, was "korrekt" ist, aber es muss ja mal eine Basis-Idee gegeben haben. Ich selbst hatte damals ein paar Buslinen in Köln auf PTv2 umgestellt, die ich teilweise Jahre zuvor mit vermutlich PTv1 oder sonstwie getaggt hatte. Dafür nutzte ich eine entsprechende Wiki, die ich für ziemlich eingängig und simpel und damit gut umsetzbar hielt.

Die ganzen oben genanngen Konflikte zwischen den Nodes undso kann ich ehrlich gesagt auch kaum nachvollziehen. Allerdings muss ich zugeben, dass ich bewusst oder unbewusst offenbar auch beides gemacht habe: highway=bus_stop und public_transport=stop_position. Letztlich halte ich ersteres aber auch für überflüssig.

In dem Zusammenhang kann ich auch dem Argument mit dem Schlauch unter dem Kartenhersteller nicht ganz beipflichten, denn wenn Halte- oder Wartepunkte teilweise über hunderte Meter verstreut liegen und trotzdem zur selben Haltestelle gehören, wird es ohnehin schwierig mit einem Symbol. Solange semantisch sauber gemappt wird, kann man als Renderer (was ich jetzt mal mit dem Kartenhersteller gleichsetze) auch eine bestmögliche Lösung herausholen. Diese kann aber nicht besser sein als das Mapping. Und wenn man relationen braucht, dann muss man die halt auch nutzen, und zwar auf der Mapperseite und auf der Auswerterseite. Dazu sind sie da, auch wenn sie einmalig etwas Mühe machen können. Dass sowas funktioniert, sieht man ja jetzt schon auf einigen Karten.

Naja, und irgendwann kommt halt der Punkt, an dem ein Renderer auch mal eine überkommene Konvention über Bord wirft. Dann wird PTv1 eben nicht mehr unterstützt. Na und? Man wird es merken und sich ranmachen, um es datenseitig auf Stand zu bringen. Ist doch in Ordnung. Das passiert doch alle Nas lang, und davon lebt OSM ja auch ein Stück weit.

krza wrote:

Gibt es denn derzeit eine Wiki, die einen "korrekten" PTv2-Ansatz beschreibt?

Ich kenne nur http://wiki.openstreetmap.org/w/index.p … did=625726
Die Wikis verändern sich recht häufig...

krza wrote:

...wenn Halte- oder Wartepunkte teilweise über hunderte Meter verstreut liegen und trotzdem zur selben Haltestelle gehören, wird es ohnehin schwierig mit einem Symbol.

Da sollen ja auch mehrere Symbole hin. Nehmen wir eine Kreuzung mit vier Eine-Richtung-Haltestellen an den vier abgehenden Straßen. In manchen Maßstäben sollten dann vier Symbole auftauchen. Dabei können aber durchaus zwei der Halte als "stop" und "platform" und einer nur als "stop" und einer nur als "platform" angegeben sein. Da sind dann insgesamt drei "stop"-Angaben und drei "platform"-Angaben und daraus müssen vier Symbole werden. Das ist schon ein Problem. Da ist es viel einfacher, die vier Nodes mit highway=bus_stop darzustellen.

Das mit dem STOP-Area hat immer ein ganz hohes Konfliktpotenzial. Gerade dann, wenn zwei gegenüberliegende Haltestellen weit auseinander liegen. Im VRR gibt's dann manchmal sogar 2-3 Stop-Areas für die gleiche Haltestelle, ich halte davon nix. Die Router sind inzwischen intelligent genug, von einem Haltestellenmasten oder eine Plattform den korrekten Punkt auf der Straße zu ermitteln (das wird mit den Gebäuden ja genauso gemacht).

Leider wurden im Rahmen der Mentz-Datenverarbeitung (hehe, was ein Wortspiel) ein Großteil der Masten z.B. bei uns ein Dortmund vernichtet. Kein Kommentar.

TobWen wrote:

Das mit dem STOP-Area hat immer ein ganz hohes Konfliktpotenzial. Gerade dann, wenn zwei gegenüberliegende Haltestellen weit auseinander liegen. Im VRR gibt's dann manchmal sogar 2-3 Stop-Areas für die gleiche Haltestelle, ich halte davon nix.

Nach meiner Erfahrung ist das ziemlich selten. Ich hab so einen Fall mal vor längerer Zeit in Wuppertal-Oberbarmen gesehen. Gibt es Gegenden wo das oft vorkommt?

TobWen wrote:

Die Router sind inzwischen intelligent genug, von einem Haltestellenmasten oder eine Plattform den korrekten Punkt auf der Straße zu ermitteln (das wird mit den Gebäuden ja genauso gemacht).

Den Zusammenhang mit den stop_areas verstehe ich nicht.

TobWen wrote:

Leider wurden im Rahmen der Mentz-Datenverarbeitung (hehe, was ein Wortspiel) ein Großteil der Masten z.B. bei uns ein Dortmund vernichtet. Kein Kommentar.

Ich kenne kein Tag für Masten.

Weide wrote:

TobWen wrote:

Das mit dem STOP-Area hat immer ein ganz hohes Konfliktpotenzial. Gerade dann, wenn zwei gegenüberliegende Haltestellen weit auseinander liegen. Im VRR gibt's dann manchmal sogar 2-3 Stop-Areas für die gleiche Haltestelle, ich halte davon nix.

Nach meiner Erfahrung ist das ziemlich selten. Ich hab so einen Fall mal vor längerer Zeit in Wuppertal-Oberbarmen gesehen. Gibt es Gegenden wo das oft vorkommt?

Sind nicht mehrere Stop_Areas für die gleichen Haltestellenbereich falsch bzw. redundant? Ich bin ein wenig raus aus der ganzen Diskussion, aber ich kann mir hier keinen richtigen Fall (mehr) vorstellen.

Weide wrote:

Thoschi wrote:

Wenn ich mich recht erinnere, hattest Du mal an einem ptv3 gearbeitet. Davon hört man leider gar nichts mehr.

Ja. Seit unserem Treffen in Dortmund vor zwei Jahren damals habe ich es aber deutlich vereinfacht (hoffe ich jedenfalls :-) ). Es liegt auf http://gafte.de/

Im Prinzip werden dabei die alten Sachen komplett neu hinzugefügt und die alten Sachen werden als ersetzt markiert, so dass das Neue von Anfang an angezeigt werden kann ohne dass irgendwas doppelt dargestellt oder doppelt ausgewertet wird.

Reaktionen habe ich gar keine -- weder positiv noch negativ -- was mich vermuten lässt, dass ich mal wieder nicht ausreichend verständlich formuliert habe :-(

Ich muss zugeben, dass ich seit ca. 1,5 Jahren mich nicht mehr groß mit der Thematik beschäftigt habe und auch in Zukunft wegen gravierenden Änderungen im familiären Umfeld nur noch wenig Zeit dafür habe. Ich werde mal versuchen, mich dort einzuarbeiten. Ohne schon auf die Seite gesehen zu haben; ptv2 und den ptv3-Vorschlag kann man nicht parallel mappen, wenn ich Dich richtig verstanden habe? - edit - habe kurz reingesehen und liege mit der Vermutung schon falsch. 😎

Auch muss ich die Buslinien in meinem Bereich noch fast alle zumindest ptv2-fähig machen und die Fahrwege aktualisieren. Für mich aktuell eine große Aufgabe.

Bzgl. fehlender Rückmeldungen: Vielleicht zu wenig "Werbung" gemacht...

EDIT: Habe erstmal quer gelesen.
Wenn ich es richtig verstehe, sind es jetzt nur noch Relationen und Objekte wie Platform, Station, Haltestelleninterieur wird nicht mehr mit der Relation verbunden?
Die Stop_position auf dem highway ist nicht mehr erforderlich?
Mit widerstrebt es, platform als highway zu definieren. Diese werden häufig als befahrbare Straßen dargestellt, deswegen war ich eigentlich froh, die mit ptv2 los zu sein. Ich habe jetzt auf Anhieb nicht gefunden, ob diese als Way oder Node gemappt werden bzw. was sinnvoller wäre. (M.E. als Node.
Und ein vollständiges zusammenhängendes Beispiel einer Bushaltestelle mit gegenüberliegenden Platformen mit einer Busroute von A nach B und zurück wäre für den Einstieg nett. Ich habe da, zumindest mit meiner begrenzten Zeit, Verständnisprobleme.
So viel erstmal für den Anfang. :-)

Thoschi

Mir leuchtet der Vorschlag von Weide für ptv3 nicht ein, das Problem sind für mich eher die Programme, welche die gemappten Daten auswerten.

Ich möchte, dass in der OSM-Standard-Karte Haltestellen angezeigt werden und solange dieses nur über highway=bus_stop möglich ist, werde ich dieses Tag verwenden.
Für mich ist völlig unklar, wer bestimmt, was gerendert wird.

Die schönen Verkehrskarten (https://öpnvkarte.de/#10.1581;54.3427;12 oder http://openptmap.org/?zoom=13&lat=54.32 … =B0000TFFT) sind ja Hobbies einzelner Herren, was auch nicht unbedingt zu großer Transparenz führt.
Ähnlich verhält es sich mit der Public-Transport-Sketch-Line.

Ich finde, man kann mit ptv2 ganz gut leben.
Es ist nicht unbedingt sinnvoll, "alles" in einer zweidimensionalen Karte abbilden zu wollen.

Thoschi wrote:

Und ein vollständiges zusammenhängendes Beispiel einer Bushaltestelle mit gegenüberliegenden Platformen mit einer Busroute von A nach B und zurück wäre für den Einstieg nett. Ich habe da, zumindest mit meiner begrenzten Zeit, Verständnisprobleme.

Ich bau mal ein paar Beispiele. Die werden dann auch auf gafte.de liegen. Kann aber 'ne Zeit dauern.

Weide

huby1691 wrote:

Mir leuchtet der Vorschlag von Weide für ptv3 nicht ein, das Problem sind für mich eher die Programme, welche die gemappten Daten auswerten.

Naja, hier beißt sich die Katze durchaus in den Schwanz. Zu viele Daten machen auch einem Auswerter Probleme. Neben den technischen, die Rechenzeit auch Überblicksprobleme. Und wenn Interpretationsprobleme (und so was passiert ganz schnell) beim Renderer auftreten, hat niemand was gewonnen. Also eine schlanke Datenstruktur, die aber trotzdem flexibel und schnell für Neues erweiterbar ist, ist durchaus von Vorteil. Und ptv2 hat nicht jeder verstanden, es wird daher viel Unsinn gemappt nur damit es in bestehenden Auswertungen angezeigt wird, somit sind wir Mapper auch hauptsächlich für dieses Durcheinander verantwortlich.

huby1691 wrote:

Ich möchte, dass in der OSM-Standard-Karte Haltestellen angezeigt werden und solange dieses nur über highway=bus_stop möglich ist, werde ich dieses Tag verwenden.

Und damit sorgst Du auch dafür, dass sich ptv2 bei Renderern nicht durchsetzt, ebenweil keine Notwendigkeit besteht. Es wird ja alles angezeigt.

huby1691 wrote:

Für mich ist völlig unklar, wer bestimmt, was gerendert wird.

Immer der, der rendert, nicht wir Mapper.

huby1691 wrote:

Die schönen Verkehrskarten (https://öpnvkarte.de/#10.1581;54.3427;12 oder http://openptmap.org/?zoom=13&lat=54.32 … =B0000TFFT) sind ja Hobbies einzelner Herren, was auch nicht unbedingt zu großer Transparenz führt.
Ähnlich verhält es sich mit der Public-Transport-Sketch-Line.

Das ist richtig, aber ohne die Hobbies einzelner Herren hätten wir fast gar keine Karten.

huby1691 wrote:

Ich finde, man kann mit ptv2 ganz gut leben.
Es ist nicht unbedingt sinnvoll, "alles" in einer zweidimensionalen Karte abbilden zu wollen.

Da möchte ich bedingt wiedersprechen.
a) ptv2 ist verdammt kompliziert und aufwendig
b) Wenn Du mit "alles" wirklich "alles" meinst, also auch jedwede Tretmine auf dem Trottoir, dann gebe ich Dir Recht. Wenn Du damit meinst, Du willst nur nicht umdenken müssen, dann gebe ich Dir nicht Recht. Zum einen gibt es dreidimensionale Karten, zum anderen gibt es Spezialkarten (meist als Hobbies einzelner Herren und Damen). Die Datenbank, in die wir unsere Informationen schreiben (=mappen), hat wesentlich mehr Informationen als z.B. die Standardkarten sinnvoll anzeigen können. Wenn Dir eine Bushaltestelle reicht, andere möchten aber z.B. gerne für Fußgängerrouting die Straßenseite der Bushaltestelle wissen und vielleicht auch welche Linie denn da fährt um ein kombiniertes Routing zwischen Fußgänger und ÖPNV anbieten zu können. Und es gibt unzählige Möglichkeiten, genau das man OSM m.E. aus.

Thoschi

Thoschi wrote:

ptv2 hat nicht jeder verstanden, es wird daher viel Unsinn gemappt

Das wird nicht dadurch besser, dass ein noch komplizierteres ptv3 eingeführt wird.

Thoschi wrote:

huby1691 wrote:

Für mich ist völlig unklar, wer bestimmt, was gerendert wird.

Immer der, der rendert, nicht wir Mapper.

Für die auf openstreetmap.org angezeigten Karten wird es doch ein festgelegtes Verfahren geben?

Thoschi wrote:

ptv2 ist verdammt kompliziert und aufwendig

Gerade das finde ich nicht, man kann sehr einfach anfangen, indem man pro Haltestelle nur eine "stop_position" mappt. Wenn man viel Zeit hat, kann man jede einzelne Fahrt aus dem Fahrplan als Relation darstellen und in der Master_Route sammeln.

Eine Zerlegung von Linien in einzelne Abschnitte (Sub-Relationen) würde m.E. die Wartbarkeit erschweren, da man Auswirkungen von Änderungen kaum nachvollziehen könnte.

huby1691 wrote:

Thoschi wrote:

ptv2 hat nicht jeder verstanden, es wird daher viel Unsinn gemappt

Das wird nicht dadurch besser, dass ein noch komplizierteres ptv3 eingeführt wird.

Was ich gelesen habe, sieht erstmal einfacher aus. Aber lass und mal Beispiele abwarten.

huby1691 wrote:

Thoschi wrote:

huby1691 wrote:

Für mich ist völlig unklar, wer bestimmt, was gerendert wird.

Immer der, der rendert, nicht wir Mapper.

Für die auf openstreetmap.org angezeigten Karten wird es doch ein festgelegtes Verfahren geben?

Sicher gibt es ein festgelegtes Verfahren, das gibt es bestimmt auch für die "privaten" Karten. Aber dieses Verfahren legt der Renderer fest. Und dazu dürften wir nicht gehören, ich kann mich nicht erinnern hier im Forum schon mal Diskussionen gesehen zu haben, wo es darum geht, was gerendert wird und was nicht. Wünsche hat es hier schon viele gegeben, aber noch keine Festlegungen.

Thoschi

huby1691 wrote:

Eine Zerlegung von Linien in einzelne Abschnitte (Sub-Relationen) würde m.E. die Wartbarkeit erschweren, da man Auswirkungen von Änderungen kaum nachvollziehen könnte.

Hab ich auch nicht gern gemacht. Aber ich habe mal eine Zeit lang versucht, die durch das Editieren von Straßen beschädigten Routen nur im Regierungsbezirk Düsseldorf zeitnah wieder in Ordnung zu bringen. Das war fast ein Full-Time-Job! Mit solchen Segmenten kann man dieses Problem komplett lösen. Dieser Vorteil ist so groß, dass ich die zusätzliche Relationsebene akzeptabel finde.

Es gab auch mal die Idee, solche Segmente so klein zu machen, dass sie als Atome des Linienplans fungieren können. Das sind nicht die in P3 vorgeschlagenen Segmente! Wenn eine Buslinie mit zwei Segmenten auskommt, dann sollen in P3 ohne Rücksicht auf andere Buslinien auch nur zwei gemacht werden.

huby1691 wrote:

Ich möchte, dass in der OSM-Standard-Karte Haltestellen angezeigt werden und solange dieses nur über highway=bus_stop möglich ist, werde ich dieses Tag verwenden.

Hier kann ich nur einmal mehr wiederholen: Wir mappen nicht für den Renderer. Das ist und bleibt eine der Grundregeln bei OSM. Die Renderer müssen sich mit dem abfinden, was an Daten vorhanden ist.

Das heißt natürlich nicht, dass man das Mapping nicht für das Rendereing optimieren könnte oder sollte. Allerdings steht selbst dabei nicht der Renderer im Vordergrund, und schon gar nicht irgendein bestimmter Renderer, sondern die Datenstruktur. Wir sollten uns beim Mappen gedanklich eigentlich komplett von den ganzen Karten lösen und nur auf die Daten konzentrieren. Das ist für "normale Benutzer" sicher schwierig, weil nun mal die Karten das zumindest prominenteste Ziel des Mappens sind. Trotzdem sollte man sich vor Augen führen, dass eine saubere Datenstruktur im Grunde automatisch zu einer guten Ausgangslage für jedweden Renderer führt. Und letztlich müssen sich, wie ich weiter oben schon andeutete, die Renderer an verbesserte Datenstrukturen anpassen und nicht umgekehrt, und natürlich auch die Mapper an eben diese verbesserten Datenstrukturen. Das Mitschleppen von veralteten Tags, nur weil sie auf einer Lieblingskarte so schön dargestellt werden, ist nicht zielführend.

Nochmal zu den Wikis. Oben wurde ja der Link auf das Proposed Feature angezogen. Da steht leider mit keinem Wort, ob es sich um PTv1, PTv2 oder sonstwas handelt. Nach einiger Suche fand ich dann die Wiki wieder, mit der ich damals gearbeitet hatte: DE:Public transport. Die fand ich damals eigentlich sehr nützlich, klar und einfach umzusetzen. Sie zielt auf PTv2 ab.

Zu PTv3 habe ich noch gar nichts gefunden. Es wurde hier gelegentlich erwähnt ... mir ist aber nicht ganz klar geworden, ob das nur so eine "Extrapolation" war oder ob es tatsächlich Ansätze gibt, eine dritte Version zu erarbeiten.

krza wrote:

Hier kann ich nur einmal mehr wiederholen: Wir mappen nicht für den Renderer. Das ist und bleibt eine der Grundregeln bei OSM. Die Renderer müssen sich mit dem abfinden, was an Daten vorhanden ist.

Da stimme ich Dir hundertprozentig zu. PTv2 hat einen Mangel in der Datenstruktur, denn man kann eine komplette Haltestelle nicht von einer Haltestellenkomponente unterscheiden. In PTv1 trat dieses Problem so nicht auf und es tritt auch nicht in kompatibel gestalteten Haltestellen auf. Deshalb sollten die Haltestellen kompatibel gemappt werden. PTv2 wird dadurch nicht im Mindesten behindert.

krza wrote:

Nach einiger Suche fand ich dann die Wiki wieder, mit der ich damals gearbeitet hatte: DE:Public transport. Die fand ich damals eigentlich sehr nützlich, klar und einfach umzusetzen. Sie zielt auf PTv2 ab.

Sie zielt, aber sie trifft nicht PTv2. Allein die Formulierung "Das Einfügen der Halteposition ist Pflicht." führt dazu, dass eine korrekt nach PTv2 gemappte Route(168910) mit 25 Halten als Route mit 5 Halten interpretiert wird. Das ist eine eindeutig inkompatible Beschreibung. Egal ob das jetzt besser oder schlechter ist: beides mit public_transport:version=2 zu kennzeichnen macht die Routen mehrdeutig und damit kaputt.

krza wrote:

Nochmal zu den Wikis. Oben wurde ja der Link auf das Proposed Feature angezogen. Da steht leider mit keinem Wort, ob es sich um PTv1, PTv2 oder sonstwas handelt.

PTv* sind nachträglich erfundene Bezeichnungen. Das Proposal definiert PTv2. Das davor wird PTv1 genannt. Das nächste nennen wir vorgreifend PTv3 und Anpassungsbestrebungen zu PTv2 werden meist PTv2.1 genannt.

krza wrote:

Zu PTv3 habe ich noch gar nichts gefunden. Es wurde hier gelegentlich erwähnt ... mir ist aber nicht ganz klar geworden, ob das nur so eine "Extrapolation" war oder ob es tatsächlich Ansätze gibt, eine dritte Version zu erarbeiten.

Ich habe einen Vorschlag für PTv3 ausgearbeitet, der P3 heißt. Er liegt auf http://gafte.de/ und wurde in Beitrag #14 dieses Threads zuerst angesprochen. Weitere Vorschläge zu PTv3 sind mir nicht bekannt.

Eine neue PT-Version wäre schon wichtig, sie muss aber grosse Vorteile bringen, damit sie sich auch durchsetzt und nicht nur das Chaos noch mehr vermehrt.
Wichtige Anforderungen wären:
1. Andere Mappingaktivitäten dürfen nur geringfügig durch das PT beinträchtigt werden. PTv1 und noch mehr PTv2 scheitern hier kläglich, sofern man nicht massiven Schaden am PT Mapping in Kauf nimmt.
2. Auch ein normaler iD Nutzer sollte in der Lage sein, das PT-Mapping zumindest bei einfachen Verhältnissen durchzuführen, zu korrigieren bzw. nach sonstigen Bearbeitung (insbesondere von highway-Elementen) wieder zu reparieren. ID wird man dazu sicher erweitern müssen, für PTv2 ist aber eine derartige Erweiterung schlicht unmöglich, da selbst ein leistungsfähiger Relationseditor ähnlich JOSM zur Nutzung PT-Experten benötigen würde.
3. Alle relevanten Informationen müssen darstellbar sein. Wenn Spezialfälle wie ein ZOB nur von PT-Experten mit JOSM komplett zu mappen sind, ist dies akzeptabel.

Die Datenstruktur und insbesondere deren vollständige Definition können durchaus kompliziert sein. Wichtig ist nur, dass sie zumindest im Regelfall einfach zu editieren ist. Wir müssen daher auch darüber Gedanken machen, wie ein optimierter Editor eine einfache ggf. graphische Editiermöglichkeit bieten kann, und die Datenstruktur dafür passend definieren.

Dazu mal ein Beispiel. Es wird viel gejammert, dass Relationen und insbesondere geordnete kompliziert sind.
Allerdings ist jeder Way eigentlich eine geordnete Relation von Nodes. Diese wird lediglich in der Datenbank etwas anders gespeichert und unterliegt den Einschränkungen, dass nur Nodes als Member und keine Rollen zulässig sind. Das jetzt Ways kein Problem für User darstellen, liegt nur daran, dass alle Editoren eine hinreichend einfache graphische Eingabemöglichkeit dafür bieten. Wenn man die Ways im Relationseditor ohne graphisches Feedback aus Nodes zusammenstellen müsste, würde wohl fast jeder aufgeben.

Habe mal einen flüchtigen Blick über das Paper auf gafte.de geworfen. Naja. Wie soll ich sagen. Ich bin selbst Ingenieur und arbeite mit Spezifikationen undso. Trotzdem wird uns so ein Paper für sich allein nicht weit bringen, weil es viel zu abstrakt ist. Es wurden zwar ein paar Beispiele angezogen, aber diese sind für einen nicht ortskundigen Leser überhaupt nicht zu erfassen. Es müsste also eine Diskussions-Wiki her, auf der man vor allem Beispiele sammelt mit Bildern, Luftbildern, Kartenausschnitten und dergleichen (dabei sollte es meines Erachtens auch möglich sein, auf Quellen wie Google zurückzugreifen, weil sie ja nicht für das Mappen genutzt werden – sofern die Quellen selbst eine Verlinkung in einer beliebigen Wiki nicht untersagen). Edit: Wie wäre es hiermit: Public_transport_schema_development?

Mit dieser Sammlung kann man dann jeden Vorschlag, jede Änderung und so weiter immer schön abgleichen und deren Funktionalität verifizieren. Und vor allem wird diese Sammlung wachsen, bis fast jede Konstellation einmal auftaucht. Diese Konstallationen kann man dann in Normal- und Spezialfälle unterteilen. Erstere müssen von einem Standardtagging abgedeckt werden können und damit auch von einfachen Editoren und Templates. Letztere erfordern dann meinetwegen Expertenwissen (wie slhh ja schon andeutete).

Eine Wiki hat auch den Vorteil, dass sie von entsprechenden Users weltweit verfolgt werden kann. Denn PT gibt es nicht nur in Deutschland. Ich denke da nur an die Metrostationen in New York, die ja oft Aufgänge haben, die nur für eine Richtung gelten, so dass man für die andere Richtung gerne mal ein, zwei Blocks weiter wandern muss. Schwedische Fälle hattest Du ja auch schon genannt.

Am Ende muss ein möglichst guter Kompromiss zwischen "humaner" Lesbarkeit und Datenintegrität gefunden werden. In dem Zusammenhang finde ich "p3" als Prefix übrigens denkbar ungeeignet. Das kann alles und nichts sein. Da finde ich das "public_transport" schon viel besser, auch wenn ich selber eigentlich auch ein Fan von Akronymen und Abkürzungen bin. Allerdings habe ich selber auch schon die Erfahrung machen müssen, dass man sich da leicht zu Tode abkürzt. Insofern sollte man den Dingen lieber ein paar mehr Buchstaben gönnen. Im konkreten Fall stört mich neben dem einfachen "p", das man auch wenigstens "pt" nennen könnte, vor allem auch die einstellige 3. Hier sollte man eine führende 0 anbringen. Wer weiß, wie schnell man bei PTv10 angekommen ist oder sogar PTv100. Also wäre hier ein "pt003_" oder "pt_v003_" aus meiner ganz persönlichen Sicht der beste Kompromiss zwischen "p3_" und "public_transport_v003_".

Achso, und das PIO ... die Abkürzung ist sofort nachvollziehbar, aber die Nähe zum POI ist schon da, so dass ich zunächst zweimal hingucken musste. Im Übrigen weiß ich nicht so recht, was der Unterschied zwischen einer Stop Position und einem PIO sein soll. Momentan haben wir stop_positon für den Punkt, an dem Leute ein- und aussteigen. Betriebliche Stop-Positionen interessieren hier nicht wirkliche, und wenn, dann ist es ein Spezialfall mit zusätzlichem Tagging. Und die Wartepositionen sind die Platforms. Mehr braucht es meines Erachtens nicht. Man sollte die Real-Life-Use-Cases nicht künstlich aufblähen – frei nach dem KIS-Ansatz: Keep It Simple.

Wie gesagt, alles geschrieben, ohne das Paper oder das Preset im Detail bzw. überhaupt angeschaut zu haben.

krza wrote:

Momentan haben wir stop_positon für den Punkt, an dem Leute ein- und aussteigen.

stop_position is der Punkt, an dem das Fahrzeug hält. Beschränkt auf die Punkte des Fahrwegs. Die Stelle an der die Leute ein- und aussteigen ist die Platform.

PIO ist die Stelle, von der die Passagiere (das können bei Autofähren auch Autos sein) den eigenen Weg etwa zum Umsteigen starten oder beenden. Das ist fast immer die Platform wenn vorhanden ... aber nicht immer.

Beispiel:
http://kartor.eniro.se/?c=57.785280,14. … 259,0.1323
Hier dürfen Passagiere niemals zur stop_position oder zur platform geleitet werden. Sie müssen ins Gebäude sonst werden sie von den rückwärts fahrenden Bussen überfahren.

krza wrote:

...finde ich "p3" als Prefix übrigens denkbar ungeeignet

Ja. Ich freue mich, wenn jemand was besseres findet. Aber ich will auch nicht wirklich Tags haben, die "public_transport_v003_area_name" heißen...

Weide

PS: In ein paar Minuten schiebe ich einige Beispiele nach gafte.de

krza wrote:

Diese Konstallationen kann man dann in Normal- und Spezialfälle unterteilen. Erstere müssen von einem Standardtagging abgedeckt werden können und damit auch von einfachen Editoren und Templates. Letztere erfordern dann meinetwegen Expertenwissen (wie slhh ja schon andeutete).

Die Unzulänglichkeiten einfacher Editoren sollten wir nur mit sehr geringer Priorität berücksichtigen, genauso wie nicht für einen bestimmten Renderer taggen sollten.

Wichtig ist dagegen, dass ein einfach bedienbarer Editor machbar ist, der eine einfache Bearbeitung zumindest der Normalfälle ermöglicht, die Programmierung des Editors muss dabei nicht unbedingt einfach sein. Es besteht durchaus die Gefahr, dass man gerade dies nicht erreicht, wenn man auf die Einschränkungen derzeitiger Editoren zuviel Rücksicht nimmt.

Eine Sammlung von Konstellationen im Wiki scheint mir sinnvoll zu sein. Der P3 Vorschlag von Weide hat einige sinnvolle Ansätze. Meines Erachtens sind da aber noch ausreichend Schwachstellen auf Spezifikationsebene erkennbar, so dass zunächst eine Überarbeitung erfolgen sollte, bevor man anfängt Umsetzungsbeispiele zu generieren.

Weide wrote:

stop_position is der Punkt, an dem das Fahrzeug hält. Beschränkt auf die Punkte des Fahrwegs.

Soweit richtig.

Weide wrote:

Die Stelle an der die Leute ein- und aussteigen ist die Platform.

Soweit falsch. Und zwar sowohl bezüglich dessen, wie die Platform in der Wiki beschrieben ist, also auch von der Logik her. Die Plattform ist nämlich der Bereich, in dem die Passagiere warten. Das ist aber genau nicht der Punkt, an dem sie die Fahrzeuge besteigen oder verlassen. Beide können natürlich physisch zusammenfallen, aber das wäre nur ein spezieller Fall. In den meisten Fällen dürfte es so gemappt sein, dass Plattform und Stop-Position noch nichtmal eine Verbindung miteinander haben. Das ist aber auch in Ordnung so (siehe unten).

Weide wrote:

PIO ist die Stelle, von der die Passagiere (das können bei Autofähren auch Autos sein) den eigenen Weg etwa zum Umsteigen starten oder beenden. Das ist fast immer die Platform wenn vorhanden ... aber nicht immer.

Der Punkt des Ein- und Aussteigens liegt zwangsläufig auf dem Way, denn dort befindet sich das Fahrzeug. Dafür gibt es auch keine Ausnahmen, sofern sich das Fahrzeug nicht (fliegend?) vom Way entfernt. Wie gesagt, wir müssen uns kompromisslos die physische Realität vor Augen führen und jegliche menschlichen Gewohnheits-Interpretationen zunächst mal außen vor lassen. Ich stimme Dir zu, wenn Du sagst, dass der PIO bzw. die Plattform der Punkt oder sagen wir besser Ort ist, an dem ein Ein/Um/Ausstieg beginnt oder endet, aber das meint eben nicht notwendigerweise den Punkt, an dem das Fahrzeug steht, insbesondere bei Schienenfahrzeugen. Wenn man es ganz genau nehmen wollte, müsste man zwischen Plattform und Stop-Position noch einen Fußweg mappen, aber das würde nur mehr Probleme verursachen als lösen, wenn dies auf einen gemeinsam genutzten Punkt hinausliefe. Hier sollte es reichen, wenn Fußweg und Stop-Position hinreichend nah beieinander liegen. Das ist für jeden passablen Router eine Standardsituation.

Weide wrote:

Beispiel: http://kartor.eniro.se/?c=57.785280,14. … 259,0.1323 Hier dürfen Passagiere niemals zur stop_position oder zur platform geleitet werden. Sie müssen ins Gebäude sonst werden sie von den rückwärts fahrenden Bussen überfahren.

Korrekt, natürlich dürfen die Passagiere nicht hinter den Bussen herumlaufen. Aber das Beispiel zeigt keine besondere Situation, sondern eine Standardsituation, und es ist keine Aufgabe für PTvx, die Fußgänger da fernzuhalten, sondern eine für das allgemeine Taggen: Die Ways, auf denen die Busse fahren, müssen halt als nicht für Fußgänger zugänglich getaggt werden. Fertig. Wenn ein Router jetzt immernoch versucht, zur Stop-Position zu leiten, passiert das zwangsläufig über die Plattformen und damit durch´s Haus. Nochmal: Beim Taggen zählt nur die glasklare und knallharte physische Realität, zu der auch Verkehrsregeln gehören.

Ich persönlich würde erwarten, dass ein Fußgänger-Router nur zu Plattformen leitet und nur dann zu einer Stop-Position (bzw. den nahesten erreichbaren Punkt), wenn keine Plattform vorhanden ist – unter der Annahme, dass kein Verkehrsplaner beides so weit voneinander entfernt anlegt, dass man noch ewig zur Stop-Position laufen muss. Ausnahmen bestätigen auch hier die Regel, aber damit müssen betroffene Navi-Nutzer dann leben, wenn sie es eilig haben und direkt an die Bustür geleitet werden wollten. Und wie gesagt: Das Schweden-Beispiel ist bei sauberem Tagging überhaupt keine Herausforderung (habe die Stelle jetzt noch nicht mit JOSM gesucht).

Weide wrote:

krza wrote:

...finde ich "p3" als Prefix übrigens denkbar ungeeignet

Ja. Ich freue mich, wenn jemand was besseres findet. Aber ich will auch nicht wirklich Tags haben, die "public_transport_v003_area_name" heißen...

Daher hatte ich ja z.B. "pt_v003_" vorgeschlagen.

slhh wrote:

Die Unzulänglichkeiten einfacher Editoren sollten wir nur mit sehr geringer Priorität berücksichtigen, genauso wie nicht für einen bestimmten Renderer taggen sollten.

Jupp.

slhh wrote:

Der P3 Vorschlag von Weide hat einige sinnvolle Ansätze. Meines Erachtens sind da aber noch ausreichend Schwachstellen auf Spezifikationsebene erkennbar, so dass zunächst eine Überarbeitung erfolgen sollte, bevor man anfängt Umsetzungsbeispiele zu generieren.

Sehe ich auch so. Und ich wollte nicht falsch verstanden werden: Ich finde den Ansatz von Weide grundsätzlich gut und dankenswert und will da gar nicht dran "rummäkeln". Aber ich habe ihn als ersten Schuss verstanden und mich halt auf diese (in meinen Augen) Lücken gestürzt 😉

Tags wie p3_object=pio oder p3_object=ignore sind absolut nichtssagend und widersprechen allen bisherigen Gewohnheiten für die Gestaltung von Tags. Damit man das ÖPNV-Tagging nicht einfacher, sondern noch komplizierter, weil das ohne Erklärung noch weniger nachvollziehbar ist als die aktuellen Tags.

Der Sinn von p3_object=ignore hat sich mir auch noch nicht so recht erschlossen. Wenn man z.B. stop_areas nicht mehr braucht, dann ignoriert man halt einfach Objekte mit public_transport=stop_area (und löscht sie irgendwann), wozu muss man das nochmal explizit kennzeichnen? Wir müssen nicht in den Daten angeben, wie Anwendungen damit zu verfahren haben, sondern brauchen Validatoren, die bei alten Daten Warnungen ausgeben, die zum Umstellen auf ein neues Schema auffordern und bei neuen Daten prüfen, ob diese dem Schema entsprechen.

Gruß
Alex

rurseekatze wrote:

Der Sinn von p3_object=ignore hat sich mir auch noch nicht so recht erschlossen.

Wenn man ersetzte Objekte sofort löschen will, dann darf die Änderung entweder nur die Routen betreffen (wie bei der Umstellung auf PTv2) oder nur die Haltestellen. In dem anderen Bereich darf nur ergänzt werden. Ansonsten muss man Routen ändern, weil sich ihre Haltestellen geändert haben und dann Haltestellen, weil sich ihre Routen geändert haben usw. Die ganze Welt müsste auf einen Schlag geändert werden.

Die Umstellung wird einige Zeit in Anspruch nehmen. Wir können nicht einfach sagen "ab September gilt das Neue". Dann müssen die Mapper bis zum Stichtag blind mappen und nach dem Stichtag wird viel in den Karten fehlen. Das funktioniert auch nicht.

Wenn wir dagegen die alte Route als ersetzt markieren sobald es eine entsprechende neue gibt, dann können Programme das vernünftig supporten. Programme mit dem zusätzlichen Code können diesen für die neuen Objekte benutzen und können am p3_object=ignore sehen, welche Daten man als doppelt vorhanden ignorieren muss. Sie verarbeiten alle noch nicht ersetzten Objekte wie vorher.
Für die Mapper bedeutet das, dass sie fast von Anfang an die Wirkung ihrer Arbeit sehen können und das ist sehr wichtig.

Weide wrote:

Wenn man ersetzte Objekte sofort löschen will, dann darf die Änderung entweder nur die Routen betreffen (wie bei der Umstellung auf PTv2) oder nur die Haltestellen. In dem anderen Bereich darf nur ergänzt werden. Ansonsten muss man Routen ändern, weil sich ihre Haltestellen geändert haben und dann Haltestellen, weil sich ihre Routen geändert haben usw. Die ganze Welt müsste auf einen Schlag geändert werden.

Einen gewissen Bedarf für ein Ignore-Tag hätte ich in dem Fall gesehen, dass eine alte und eine neue Linie eine gemeinsame Haltestelle teilen. Allerdings dürfte es gerade in diesem Fall nicht wirklich funktionieren, da auch eine PTv3 fähige Auswertung die alten Haltestellen für die alte Linie berücksichtigen muss.

Weide wrote:

Wenn wir dagegen die alte Route als ersetzt markieren sobald es eine entsprechende neue gibt, dann können Programme das vernünftig supporten.

Dass sollten wir keinesfalls tun, denn dass Verkompliziert sowohl dass PT-Mapping zunächst und auch die Beeinträchtigungen anderer Mapping_Aktivitäten werden erhöht. Die Unterstützung durch Programme würde auch verzögert. Da das PT-Mapping ohnehin in einem schlechten Zustand ist, richten wir mit einer harten Umstellung auch wenig schaden an.

Weide wrote:

Nach meiner Erfahrung ist das ziemlich selten. Ich hab so einen Fall mal vor längerer Zeit in Wuppertal-Oberbarmen gesehen. Gibt es Gegenden wo das oft vorkommt?

Überall dort, wo entweder die gegenüberliegenden Haltestellen zu weit entfernt sind oder "um die Ecke" liegen. In Dortmund gibt's einige.

Weide wrote:

TobWen wrote:

Die Router sind inzwischen intelligent genug, von einem Haltestellenmasten oder eine Plattform den korrekten Punkt auf der Straße zu ermitteln (das wird mit den Gebäuden ja genauso gemacht).

Den Zusammenhang mit den stop_areas verstehe ich nicht.

In den meisten Verkehrsverbünden hält der Bus mit der 2. Tür am Masten. In Dortmund ist es jedenfalls so (der Busfahrer soll mit der Tür dort halten). Somit ergibt sich daraus die genaue Stopposition eines Bussen, die auf die Straße übertragen werden kann. Die Plattformen sind meistens deutlich länger, da kann man dann natürlich nicht mehr ableiten, wo der Bus wirklich hält (vorallem, weil auch die Ein- und Ausschwenkbereiche meistens der Plattform zugeteilt wurden).

Weide wrote:

Ich kenne kein Tag für Masten.

Ist vermutlich aus den Schemas geflogen, als Mentz angefangen hat, massenhaft virtuelle Plattformen einzutragen. Ich frage mich echt, wo die teilweise ihre Quellen herhaben. Ich fange nach den Klausuren an, diese in Dortmund wieder zufixen.

Hi,

ich gehöre zu der Fraktion die das ganze nicht kaperien 🤔 ... für mich ist das ganze ptv2 zu kompliziert... bringt keinen Mehrwert.. schwer wartbar zu aufwändig zu erstellen usw. ich mache k.A. so irgendeine Route.. ich kann nicht einmal sagen ob meine Relationen überhaupt ptv1 genügen.. k.A. Ich überlasse es gerne anderen es besser zu machen... nur findet sich da auch keiner.... von mir aus können die auch die Relation komplett neu machen wenn sie wollen. Aber im Wiki sind Linien gelistet die seit 2009 die noch keiner bis jetzt in Angriff genommen hat... andere total veraltet.. was soll man dazu sagen..

Jetzt gibt es ptv2 ja schon ein paar Jahre... gibts es da irgendwas wo wirklich eine praktischen nutzen hat? Der den Mehraufwand der Erstellung, Pflege rechtfertigen? 🤔 z.B. unterwegs auf dem Smartphone mit einer App? oder im Browser.. was eine Route ohne irgendwas nicht kann bzw. welche Tags bringen überhaupt was?

Ich möchte jetzt nix von eine fernen Zukunft hören... , weil der Fahrplan ja auch nicht für die ferne Zukunft ist sonder nur ein Jahr gilt und dann kann es schon wieder vieles anders sein.. und man muss alles aufs neue anschauen.. Wenn man eine Linie hat die sich nie ändert ist das natürlich toll aber nicht immer der Fall 🙄

Also Beispiele, was bringts?

miche101 wrote:

für mich ist das ganze ptv2 zu kompliziert... bringt keinen Mehrwert.. schwer wartbar zu aufwändig zu erstellen usw.

Dann kannst Du kein Nahverkehrs-Mapping betreiben. So hart muss man das formulieren. Jeder User kann nur das mappen, was er oder sie auch in der Lage ist zu mappen. Wer ein Auto hat, das nur 50 fahren kann, gehört damit auch nicht auf die Autobahn, darf aber sehr wohl im Stadtverkehr und auf Landstraßen fahren (um mal einen Vergleich zu versuchen). Beim Mapping gibt es nun einmal unterschiedliche Schwierigkeitsgrade. Was einem zu hoch ist, soll man lassen und nicht stattdessen irgendwas anderes reinfriemeln. Das macht es allen anderen nur viel schwerer. Und nicht oder gar falsch zu taggen, nur weil es gefühlt noch keine Anwendung für die richtigen Tags gibt ... dazu sage ich jetzt mal nichts.

Ich dachte anfangs auch, dass PTv2 ziemlich kompliziert sei, aber das stimmt nicht. Auch dabei gibt es ja verschiedene Stufen: Es geht erstmal nur um die korrekten Tags an den relevanten Knoten (Haltestellen, ...). Wer sich an Relationen nicht herantraut, muss danach schon aufhören. Der nächste Schritt wäre dann die Zusammenfassung von Wegen in der richtigen Reihenfolge in einer Relation. Dann kommen die Haltestellen und Haltepunkte in der richtigen Reihenfolge mit den richtigen Rollen. Das ist total simpel und mit JOSM schnell gemacht. Wenn man das gemacht hat, ist schon das Meiste getan. Darüber hinaus kann man dann noch Haltestellenrelationen erzeugen und Hauptlinien und Sonderrouten und dergleichen. Auch alles recht simpel. Man muss es sich nur einmal zu Gemüte führen (eine Wiki hatte ich ja verlinkt) und Beispiele anschauen.

Ich bin in die tiefen Details von PTv2 noch nicht eingestiegen und kann daher noch nicht so richtig nachvollziehen, wo die vermeintlichen Probleme liegen. Auf den ersten Blick sehe ich nicht direkt, woran es krankt. Aber wenn es Lücken gibt, dann sollte PTv3 in Angriff genommen werden. Das heißt aber nicht unbedingt, dass man alles (inkl. Tag-Namen) über den Haufen werfen muss. Denn ... ich wiederhole mich ...:

Das Mappen ist eine reine Bestandsaufnahme. Ein stumpfes zuammenschreiben von mehr oder weniger physikalischen Fakten. Das Mappen ist aber keine (!) Interpretationsaufgabe. Daten werden nur erzeugt und nicht interpretiert! Die Interpretation ist z.B. Renderern vorbehalten.

Relationen, könnte man meinen, verstoßen ein Stück weit gegen diese Regel, denn sie gehen ja vermeintlich in Richtung Interpretation. Allerdings kann man das so oder so sehen ... eine Zusammenfassung aller Elemente, die zu einer Haltestelle gehören, könnte man schon als Interpretation werten oder doch noch als einfachen Fakt. Manchen Leuten sträuben sich bei "Zusammenfassung" im Zusammenhang mit "Relationen" nun wieder die Haare, aber man sollte die Kirchen auch in den Dörfern lassen.

Wie gesagt, beim Mappen geht es ums Datensammeln und um die eindeutige Ablage dieser Daten in der Datenbank.

krza wrote:

miche101 wrote:

für mich ist das ganze ptv2 zu kompliziert... bringt keinen Mehrwert.. schwer wartbar zu aufwändig zu erstellen usw.

Dann kannst Du kein Nahverkehrs-Mapping betreiben. So hart muss man das formulieren. Jeder User kann nur das mappen, was er oder sie auch in der Lage ist zu mappen. Wer ein Auto hat, das nur 50 fahren kann, gehört damit auch nicht auf die Autobahn, darf aber sehr wohl im Stadtverkehr und auf Landstraßen fahren (um mal einen Vergleich zu versuchen). Beim Mapping gibt es nun einmal unterschiedliche Schwierigkeitsgrade. Was einem zu hoch ist, soll man lassen und nicht stattdessen irgendwas anderes reinfriemeln. Das macht es allen anderen nur viel schwerer. Und nicht oder gar falsch zu taggen, nur weil es gefühlt noch keine Anwendung für die richtigen Tags gibt ... dazu sage ich jetzt mal nichts.

Sei dir da mal nicht so sicher 😉

Weil ich gerade in Köln vorbeigeschaut habe 😉

http://wiki.openstreetmap.org/wiki/DE:T … 3Dbus_stop

Klassischer Fehler... highway=bus_stop ist das Schild an dem man Wartet! Wo heute zusätzlich public_transport=platform getaggt wird. Hab ich bei einer Relation ganz oft gesehen das es auf die Straße getaggt wurde, also an die Stop-Position.. Müsste man in Köln mal drüberschauen... wird dadurch auch falsch gerendert... 🙄

miche101 wrote:

krza wrote:

miche101 wrote:

für mich ist das ganze ptv2 zu kompliziert... bringt keinen Mehrwert.. schwer wartbar zu aufwändig zu erstellen usw.

Dann kannst Du kein Nahverkehrs-Mapping betreiben. So hart muss man das formulieren. Jeder User kann nur das mappen, was er oder sie auch in der Lage ist zu mappen. Wer ein Auto hat, das nur 50 fahren kann, gehört damit auch nicht auf die Autobahn, darf aber sehr wohl im Stadtverkehr und auf Landstraßen fahren (um mal einen Vergleich zu versuchen). Beim Mapping gibt es nun einmal unterschiedliche Schwierigkeitsgrade. Was einem zu hoch ist, soll man lassen und nicht stattdessen irgendwas anderes reinfriemeln. Das macht es allen anderen nur viel schwerer. Und nicht oder gar falsch zu taggen, nur weil es gefühlt noch keine Anwendung für die richtigen Tags gibt ... dazu sage ich jetzt mal nichts.

Sei dir da mal nicht so sicher 😉

Weil ich gerade in Köln vorbeigeschaut habe 😉

http://wiki.openstreetmap.org/wiki/DE:T … 3Dbus_stop

Klassischer Fehler... highway=bus_stop ist das Schild an dem man Wartet! Wo heute zusätzlich public_transport=platform getaggt wird. Hab ich bei einer Relation ganz oft gesehen das es auf die Straße getaggt wurde, also an die Stop-Position.. Müsste man in Köln mal drüberschauen... wird dadurch auch falsch gerendert... 🙄

Unter https://github.com/rurseekatze/osm-pt-validator habe ich mal angefangen, Validatorregeln für JOSM zu sammeln, mit denen man genau solche Fehler erkennen kann. Aktuell habe ich zum Beispiel schon einen Check darauf, ob eine stop_position auch Teil eines Ways ist.

Einen Check darauf, ob highway=bus_stop an einer stop_position getaggt ist, ließe sich auch relativ einfach formulieren und steht schon auf meiner Todoliste. Wenn ihr beim Mappen auch fehlerhaftes Tagging stoßt, dann würde ich mich über Pull Requests, Issues oder einfach eine Mail freuen.

Gruß
Alex

@rurseekatze

Aso... wäre auch 😎 wenn eine Note die nicht Teil eins Weges ist... und mit highway=bus_stop getaggt ist und public_transport=* fehlt... man auf "Reparieren" drücken könnte und "public_transport=platform" wird hinzugefügt 🙂 🙂 🙂

Dann noch a bischen Schwerer... dann kein "Way" in der nähe der Haltestelle Mitglied der Relation ist.. z.B.

Ich hatte es eigentlich so verstanden, dass highway=* in PTv2 überhaupt nicht mehr vorgesehen ist. Beim eigenen Mappen hatte ich das in der Regel einfach drin gelassen, wobei es dabe ieigentlich immer auf dem Fahrweg war und nicht auf dem Fußweg. Um der Homogenität willen hatte ich das bei den Relationen, die ich bearbeitett hatte, entsprechend ergänzt. Aber normalerweise sollte nur noch public_transport=* verwendet werden, oder? Die Renderer haben das zwar noch nicht gerallt, aber dazu hatte ich mich ja schon oben ausgelassen 😉

highway=bus_stop ist zum eine aus Gründen der Kompatibilität noch drin und damit klar ist das diese platform für z.B. unter anderem Bus ist. Lässt man highway=bus_stop weg müsste man auf jedenfall noch bus=yes taggen... Müsste denk ich dann soweit auch gehen..

@rurseekatze

public_transport=platform ohne Angabe des Verkehrmittel das da hält... wäre auch ein Fehler 🙂

miche101 wrote:

... damit klar ist das diese platform für z.B. unter anderem Bus ist. Lässt man highway=bus_stop weg müsste man auf jedenfall noch bus=yes taggen...

Stimmt. Das Verkehrsmittel ist so nicht abgedeckt. Auch muss ich feststellen, dass das highway=bus_stop in der PTv2 doch genutzt wird, zumindest in der Wiki hier. Gleich wird es mit Bahnen undso gehandhabt. Allerdings muss ich aus heutiger Sicht sagen, dass ich das recht unsinnig finde, insbesondere railway=tram_stop. Denn das impliziert, dass das Schild auf den Schienen steht. Eine Schild-Node kann man ja machen, aber nicht mit highway oder railway, sondern dann meinetwegen auch mit public_transport=stationsign oderso.

krza wrote:

Korrekt, natürlich dürfen die Passagiere nicht hinter den Bussen herumlaufen. Aber das Beispiel zeigt keine besondere Situation, sondern eine Standardsituation, und es ist keine Aufgabe für PTvx, die Fußgänger da fernzuhalten, sondern eine für das allgemeine Taggen: Die Ways, auf denen die Busse fahren, müssen halt als nicht für Fußgänger zugänglich getaggt werden. Fertig. Wenn ein Router jetzt immernoch versucht, zur Stop-Position zu leiten, passiert das zwangsläufig über die Plattformen und damit durch´s Haus. Nochmal: Beim Taggen zählt nur die glasklare und knallharte physische Realität, zu der auch Verkehrsregeln gehören.

OK. Das Fußgängerrouting ended hier (bei gedachtem korrekten Mapping) an der richtigen Stelle. Aber nur, weil der Router bei der unmöglichen Aufgabe die Platform zu erreichen ersatzweise was möglichst nah gelegenes sucht. Er könnte auch einfach sagen "Es gibt keinen Weg". Ich finde es in jedem Fall sinnvoller, die Ziele der Fußwege in die Routen zu stecken. Die platform wird ja trotzdem als physisch vorhandenes Objekt gemappt werden. (Übrigens sind das hier lustigerweise platforms, an denen garantiert nie gewartet wird)

slhh wrote:

Einen gewissen Bedarf für ein Ignore-Tag hätte ich in dem Fall gesehen, dass eine alte und eine neue Linie eine gemeinsame Haltestelle teilen.

Das gilt für sämtliche alte Linien, da ja alle umgestellt werden sollen.

slhh wrote:

Allerdings dürfte es gerade in diesem Fall nicht wirklich funktionieren, da auch eine PTv3 fähige Auswertung die alten Haltestellen für die alte Linie berücksichtigen muss.

Im Gegenteil: nur für diesen Fall ist das ignore-Flag gemacht. Ansonsten bekommen wir bei der Unterstützung beider Sachen doppelte Objekte.

slhh wrote:

Dass sollten wir keinesfalls tun, denn dass Verkompliziert sowohl dass PT-Mapping zunächst und auch die Beeinträchtigungen anderer Mapping_Aktivitäten werden erhöht.

Das PT-Mapping wird in der Übergangszeit komplizierter und danach m.E. einfacher. Andere Mapping-Aktivitäten werden nicht komplizierter und danach wesentlich einfacher.

slhh wrote:

Die Unterstützung durch Programme würde auch verzögert.

Im Gegenteil. Wenn wir die Umstellung ohne Übergangszeit machen, dann wird kein Programm die neuen Sachen berücksichtigen solange nur wenig umgestellt ist. Das wiederum wird die beteiligten Mapper frustrieren und den Übergang langsamer machen. Mit einem geordneten Übergang kann man dagegen sofort den neuen Code einfügen und testen ohne die Qualität der Ergebnisse runterzuziehen.

slhh wrote:

Da das PT-Mapping ohnehin in einem schlechten Zustand ist, richten wir mit einer harten Umstellung auch wenig schaden an.

Sooo schlecht ist der jetzige Zustand auch wieder nicht. Wenn plötzlich alle Haltestellen weg sind, dann wird das schon auffallen.

slhh wrote:

Überall dort, wo entweder die gegenüberliegenden Haltestellen zu weit entfernt sind oder "um die Ecke" liegen. In Dortmund gibt's einige.

Ich hab langsam das Gefühl, Du meinst mit stop_area nicht eine stop_area-Relation...

Zum Masten-Tag: es gab auch früher keins.

miche101 wrote:

Klassischer Fehler... highway=bus_stop ist das Schild an dem man Wartet!

Nein. highway=bus_stop bedeutet einfach "Hier ist eine Bushaltestelle". Wenn es neben der Fahrbahn ist, dann ist es eine platform im Sinne von PTv2 und wenn es auf dem Fahrweg ist, dann ist es ein stop im Sinne von PTv2.

rurseekatze wrote:

Einen Check darauf, ob highway=bus_stop an einer stop_position getaggt ist, ließe sich auch relativ einfach formulieren und steht schon auf meiner Todoliste.

Es ist aber völlig korrekt...

krza wrote:

Ich hatte es eigentlich so verstanden, dass highway=* in PTv2 überhaupt nicht mehr vorgesehen ist. Beim eigenen Mappen hatte ich das in der Regel einfach drin gelassen, wobei es dabe ieigentlich immer auf dem Fahrweg war und nicht auf dem Fußweg. Um der Homogenität willen hatte ich das bei den Relationen, die ich bearbeitett hatte, entsprechend ergänzt. Aber normalerweise sollte nur noch public_transport=* verwendet werden, oder?

Nein. Sämtliche alte Haltestellen sind in PTv2 völlig korrekt. Die alten Tags sollen ganz ausdrücklich durch PTv2 nicht geändert oder abgelöst werden. Abgelöst werden sollten nur die Routen.

miche101 wrote:

public_transport=platform ohne Angabe des Verkehrmittel das da hält... wäre auch ein Fehler

Nein. Es ist nicht einmal vorgesehen, dass das eingetragen wird! Im PTv2 sind Einträge wie bus=yes ganz ausdrücklich für stop_positions vorgesehen und das wars.

Weide wrote:

Nein. highway=bus_stop bedeutet einfach "Hier ist eine Bushaltestelle". Wenn es neben der Fahrbahn ist, dann ist es eine platform im Sinne von PTv2 und wenn es auf dem Fahrweg ist, dann ist es ein stop im Sinne von PTv2.

Also bevor es dieses PTv2 gab... hat man das Schild bzw. das Häuschen oder wie auch immer die Haltestelle ausfällt gemappt... das was da neber der Straße steht... da wo man halt hingeht wenn man da mitfahren will, wenn es auf der Straße wäre, wäre es schnell kaputt 🤣 Das ist highway=bus_stop. Ich habe auch noch nie auf den Bus gewartet um zu sehen wo er genau stehen bleibt... diese Note ist meist geraten...

Jetzt wo es PTv2 gibt.. sind hier viele der Meinung das wäre jetzt nicht mehr so 🙄

Mfg Miche

Da hilft es nur, nochmal das damalige Proposal zu konsultieren und zu prüfen, was gemeint ist. Aber angeblich werden die Proposals ja auch hin und wieder nach dem Approval noch geändert ...

krza wrote:

Da hilft es nur, nochmal das damalige Proposal zu konsultieren und zu prüfen, was gemeint ist.

Das Original findet man unter
http://wiki.openstreetmap.org/w/index.p … did=625726

krza wrote:

Aber angeblich werden die Proposals ja auch hin und wieder nach dem Approval noch geändert ...

Zu den Linienarten hat nach der Abstimmung jemand light_rail hinzugefügt und dadurch indirekt die Bedeutung von train eingeschränkt. Jetzt steht da, wir hätten das damals beschlossen und Korrekturversuche verschiedener Leute wurden revertet.

Na okay, dann hält sich das ja in Grenzen. Lässt sich also mit arbeiten. Danke für den Link nochmal.

geri-oc wrote:

Thoschi wrote:

Dieses Durcheinander lässt mich eigentlich nur wieder dafür plädieren, auf bus_stop ganz zu verzichten und sich nur noch auf ptv2 zu konzentrieren oder aber sich wirklich mal dran zu setzen und eine pt-Version zu konzipieren, die alles andere ersetzt und zukunftsfähig ist.

Bin auch der Meinung, wenn etwas bei ÖPNV passieren soll (Aktualität) dann sollte ein "System" anwendungsbereit dokumentiert werden. Somit würden auch schnell alle ptv1 aktualisiert werden. Gibt es überhaupt Nutzer von ptv1?

Es gibt noch wenige sinnvolle Anwendungen für ptv1 - Routen:
- Bürgerbuslinien, die zwar feste Haltestellen, aber keine festen Fahrwege haben, da Haltestellen als Rufbus angefahren werden.
- Bahnlinien bei denen die angefahrenen Bahnsteige nicht bekannt sind.

Dokumentationen existieren, werden aber nicht gelesen. Auf der VRR-Seite ist ein ptv2 Taggingschema datailliert beschrieben.
Meinst du mit Dokumentation solche Darstellungen http://www.roeltgen.com/e150900/ ? Und wo sollten sie stehen ?

Gruß Axel

Hallo Axel,

axelr wrote:

Dokumentationen existieren, werden aber nicht gelesen

mein Problem ist, es gibt zu viele, sich zu Teil widersprechende Dokumentationen.

Ich finde es gut, daß du dir die Mühe gemacht hast, verschiedene tagging-Schemata zu vergleichen, mir sind die Erklärungen dazu aber zu knapp, um daraus für mich Schlüsse zu ziehen, welches man anwenden sollte.
Insbesondere die Bildchen auf deiner Wiki-Seite User:Axelr/Bushalte fand ich interessant, konnte sie allerdings nicht entschlüsseln.
Auch deine mir bisher unbekannte Seite http://www.roeltgen.com/e150900/ ist als Grundlage für einen Vortrag sicherlich sehr gut, als schriftliche Dokumentation unzureichend, angefangen mit erst bei Zoom-Faktor 250 lesbaren Schriften in den Zeichnungen bis zur Benennung der Schemata (island: weil auf den britischen Inseln verwendet? tunnel:?).

krza wrote:

Wie wäre es hiermit: Public_transport_schema_development

Die Idee finde ich gut, würde lieber erst einmal auf deutsch arbeiten, um Schwierigkeiten und Mißverständnisse sprachlicher Art auszuschließen.

Viele Grüße
Peter

Die Erklärung finde ich ganz gut.. um die Unterschiede darzustellen zwischen 1 und 2:
https://wiki.openstreetmap.org/wiki/User:Weide

Welche Punkte mich stören sind zum einen... für jede Variante eine Relation, und diese stop_position... Es mag in komplexeren Haltestellen notwendig sein... aber ein einfachen Verhältnissen braucht man diese glaub ich nicht... vor allem da diese eher geraten ist als wirklich aufgenommen...

Zum Beispiel diese Linie des MVV Nr. 614 müsste man 5 Varianten für die Hinfahrt anlegen und 5 Varianten für die Rückfahrt auch 5 anlegen und eine Master-Relation... das macht 11 Relationen das finde ich ein wenig übertrieben.. da dieser Bus nicht oft fährt.. wahrscheinlich hauptsächlich nur um Schuler aus den Dörfern aufzulesen.. wo gerade vorhanden sind.
http://efa.mvv-muenchen.de/ttb/mvv_19614___H_s17_1.pdf

miche101 wrote:

...und diese stop_position... Es mag in komplexeren Haltestellen notwendig sein... aber ein einfachen Verhältnissen braucht man diese glaub ich nicht... vor allem da diese eher geraten ist als wirklich aufgenommen...

Ja. PTv2 verlangt auch nicht, dass beides gemappt wird. Es verlangt nur, dass beide in die Routen kommen sofern beide vorhanden sind. Das hat den Sinn, dass man zu jedem Haltestellenobjekt einfach die Relationen nachschlagen kann und so die Liste der da haltenden Linienvarianten bekommt. Die meisten Pärchen aus stop und platform existieren nur deshalb, weil jemand irrtümlich angenommen hat, dass man das jetzt eben so machen muss. Ich lösche sowas normalerweise nicht, weil es ja zulässig ist ... aber 90% der Pärchen sind einfach Quatsch und man kann sie nur deshalb nicht vereinfachen, weil sie ja keine Fehler im engeren Sinne sind.

huby1691 wrote:

....Auch deine mir bisher unbekannte Seite http://www.roeltgen.com/e150900/ ist als Grundlage für einen Vortrag sicherlich sehr gut, als schriftliche Dokumentation unzureichend, angefangen mit erst bei Zoom-Faktor 250 lesbaren Schriften in den Zeichnungen bis zur Benennung der Schemata (island: weil auf den britischen Inseln verwendet? tunnel:?)....

Blätter eine Seite zurück, da stehen die Erklärungen. Zweimal 'Strg'+'+' fürs Studium des Kleingedruckten, die Registriernummer brauchst du nicht.

Farben in Bildern:
magenta Routen-Relation (Elemente in der route-relation)
grau Elemente nicht in der route-relation
blau highway-tag
dunkelblau railway-tag

Benennung:
dualnode für Zwei-Knoten-Punkt-Lösung
island für Insellösung, weil für London-Busses dokumentiert und weil nicht kompatibel,
tunnel für Tunnelblick.

Gruß Axel

miche101 wrote:

Zum Beispiel diese Linie des MVV Nr. 614 müsste man 5 Varianten für die Hinfahrt anlegen und 5 Varianten für die Rückfahrt auch 5 anlegen und eine Master-Relation... das macht 11 Relationen das finde ich ein wenig übertrieben.. da dieser Bus nicht oft fährt.. wahrscheinlich hauptsächlich nur um Schuler aus den Dörfern aufzulesen.. wo gerade vorhanden sind.
http://efa.mvv-muenchen.de/ttb/mvv_19614___H_s17_1.pdf

Wie soll denn sonst die unterschiedliche weglaufe deutlich gemacht werden? Ich hab es früher mal versucht mit eine "Alternative" role, aber das geht auch nicht mehr wenn es mehrere alternativen gibt.

Verstehe mich richtig: machmal stinkt's mir auch für eine einzige Bus eine neue Relation anlegen zu mussen. Und in Deutschland gibt es solche fälle viel öfter als in die Niederlanden.

@ axelx: ich habe schon zurückgeblättert, aber die Farbenerklärung fehlte mir zum Verständnis. Ebenso kenne ich die Tastenkombination für Zoom in/out im Browser, aber damit eine Dokumentation beachtet wird, sollte es der Leser m.E. möglichst bequem haben. Deswegen würde ich auch die Beispiele lieber als Bild (mit zusätzlichen Link) haben, außerdem könnte sich im Laufe der Zeit die Karte ändern und dann wäre das Beispiel nicht mehr nachvollziehbar.

@ miche101 / Marten Deen: Bei solchen Linien stehen für mich Aufwand und Nutzen des Anlegens von Relationen in keinem vernünftigen Verhältnis, insbesondere da mit Änderungen bei jedem Fahrplanwechsel zu rechnen ist.
Ich wäre hier zufrieden, wenn alle Haltestellen getaggt wären und man einen Link zur Webseite des Verkehrsunternehmens hätte.

Daraus ergibt sich aber auch die Frage, ob es nicht gut wäre, alle an einer Haltestelle haltenden Linien (wie am Haltestellenmast angeschrieben) in einem entsprechenden Tag aufzuzählen.

Eine unnötig hohe Komplexität ist meiner Ansicht nach dadurch entstanden, daß man versucht hat, Eisenbahn- und Bus-/Straßenbahnlinien in ein übereinstimmendes Schema zu bringen.

huby1691 wrote:

Eine unnötig hohe Komplexität ist meiner Ansicht nach dadurch entstanden, daß man versucht hat, Eisenbahn- und Bus-/Straßenbahnlinien in ein übereinstimmendes Schema zu bringen.

Seh ich auch so... dazu sind diese Fahrzeuge zu flexibel... um da immer aktuell zu bleiben. 🙄

Vielleicht kann man die Fahrweg ja mal automatisch nach routingregeln berechnen lassen 😉 Das man nur noch die Abfolge der Haltestellen in einer Relation vorhalten muss..

miche101 wrote:

huby1691 wrote:

Eine unnötig hohe Komplexität ist meiner Ansicht nach dadurch entstanden, daß man versucht hat, Eisenbahn- und Bus-/Straßenbahnlinien in ein übereinstimmendes Schema zu bringen.

Seh ich auch so... dazu sind diese Fahrzeuge zu flexibel... um da immer aktuell zu bleiben. 🙄

Vielleicht kann man die Fahrweg ja mal automatisch nach routingregeln berechnen lassen 😉 Das man nur noch die Abfolge der Haltestellen in einer Relation vorhalten muss..

public_transport (Öffentlicher Verkehr) ist eben nicht mit railway in ein Schema gebracht worden. Die Bahnsteige und Fahrwege sind nur meist die gleichen.

Mit PTv1 und PTv2 kann man ganz gut umgehen. Ich sehe zwar Vereinfachungsmöglichkeiten, aber keine Notwendigkeit etwas Neues aufzutellen.

Zur eigentlichen Forumsfrage, der Notwendigkeit der stop_position:
Der Ein- Ausstiegpunkt für eine Fußgängernavigation wird durch ein Lot von der stop_position auf die nächstgelegen platform-Linie gebildet. Der Fußpunkt oder das Linienende ist dieser Ein- Ausstiegspunkt und wäre für mich auch die Position für das Haltestellensymbol.

Leider wird auf der Mapnik Karte kein Symbol für PTv2 - Haltestellen gerendert. Die Hintergründe sind viel diskutiert, die fehlende Umsetzung ist nicht begreifbar.

Gruß Axel

miche101 wrote:

Vielleicht kann man die Fahrweg ja mal automatisch nach routingregeln berechnen lassen 😉 Das man nur noch die Abfolge der Haltestellen in einer Relation vorhalten muss..

PTv3 könnte etwas in diese Richtung gehen. Wir könnten für den Fahrweg atomare Segmente anlegen, die wir aber in der Regel nicht in die Linienrelation aufnehmen. Diese atomaren Segmente würden in der Regel von den Stop-Positionen einer Haltestelle zu denen der nächsten Haltestelle führen. Die Linienrelation würde dann in der Regel nur Haltestellen (vermutlich in Form von Stop-Positionen) auflisten. Die Auswertung hat dann die zu den genutzen Stop-Positionen jeweils aufeinanderfolgender Haltestellen passende atomare Segment zu verwenden, die über die Miglidschaft der Stop Position als from oder to node des atomaren Segments einfach aufzufinden sind. Der Editor könnte ggf. die zu einer Linienrelation fehlenden atomaren Fahrwegsegmente nach Benutzeraufforderung durch Autorouting automatisch erstellen. Für die meisten Segmente wird das korrekte Ergebnisse liefern und in den anderen Fällen kann dann der Benutzer nachkorrigieren.

Ein Ausnahmefall ist, wenn es zwischen einem Paar von Stop-Positionen mehrere verschiedene tatsächlich genutzte Fahrwege gibt, was sehr selten sein dürfte. In diesem Fall wäre zusätzlich ein Via-Node oder das betreffende Fahrwegsegment explizit in die Linienrelation aufzunehmen.

Gibt es Linien die eine Haltestelle ohne Halt durchfahren, sollte diese Haltestelle in der Regel in die Linienrelation mit aufgenommen werden und nur durch eine Rolle als durchfahren gekennzeichnet werden. Dies vermeidet zusätzlich benötigte Fahrwegsegmente und bringt somit eine wichtige Entlastung der Highway-Elemente von übermäßig vielen Relationen.

Die atomaren Segmente müssen nicht unbedingt linear sein, sondern können am Anfang und Ende zu mehreren From- bzw. To-Nodes verzweigt sein. Anhand der in der Linienrelation verwendeten Stop-Positionen, können die aus dem Fahrweg Segment tatsächlich benötigten Ways herausgefiltert werden.

Für Karten-Renderer die ohnehin den lokal vollständigen Datensatz vorliegen haben, sollten kein Problem mit den nötigen Auswertungen haben. Um Linien auf Basis einer Overpass Abfrage darstellen zu können, braucht man entweder eine Browsers-seitige Nachbearbeitung oder eine Erweiterung der Overpass-API um PT-spezifische Ausgangsfilter.

Ein großes Probem von PTv2 ist die bei konsequenter Umsetzung durch Varianten erzeugte Datenflut, die für eine manuelle Pflege ungeeignet ist. Bezüglich Varianten ist PTv2 strukturell zu einfach definiert, was durch die enorme Datenmenge ausgeglichen werden muss und damit zumindest für Menschen die Komplexität deutlich erhöht.

PTv3 sollte daher in der Lage sein, zumindest kleine Variationen innerhalb der Relationen abzubilden, um nicht für jede Untervariante eine separate Routenrelation zu benötigen.

Ein Beispiel wie sowas bei einem Segment aussehen kann:

pio A-Dorf
pio:-B_Gl2 B-Dorf an Gleis 1
+pio:-B_Gl2,-KZ B-Dorf Bahnsteigverlängerung an Gleis 1
alt-pio:+B_Gl2 B-Dorf an Gleis 2
pio C-Dorf

B_Gl2 und KZ sind dabei beliebige Bezeichner für eine Variation, die aktiv ist, wenn sie in der Rolle der Migligschaft des Segments in der Tour aufgeführt sind. Ein minus vor diesem Bezeichner in der Memberrolle deaktiviert den Member wenn die Variation aktiv ist. Ein plus vor diesem Bezeichner in der Memberrolle deaktiviert den Member wenn die Variation inaktiv ist.
Wird ein pio deaktiviert, so wird aus einem unmittelbar nachfolgenden +pio oder alt-pio ein pio.
Wird ein alt-pio deaktiviert, so wird aus einem unmittelbar nachfolgenden +pio ein alt-pio.

Für einen Kurzzug der in B-Dorf auf Gleis 1 fährt wäre diese Rolle dann:
segment:KZ

Damit wird aus obiger Membersequenz:
pio A-Dorf
pio B-Dorf an Gleis 1
pio C-Dorf

Für einen Zug der in B-Dorf auf Gleis 2 fährt wäre diese Rolle dann:
segment:B_Gl2

pio A-Dorf
pio B-Dorf an Gleis 2
pio C-Dorf

Natürlich können auch mehrere Variationen gleichzeitig wirken:
segment:KZ,B_Gl2
Dies hat für den Beispielfall aber das gleiche Ergebnis wie zuletzt.

miche101 wrote:

Vielleicht kann man die Fahrweg ja mal automatisch nach routingregeln berechnen lassen wink Das man nur noch die Abfolge der Haltestellen in einer Relation vorhalten muss..

Sowas ist nur brauchbar, wenn alles andere fehlerfrei und vollständig ist.

Da muss nur jemand bei einem Stück Fahrweg einen kleinen Fehler machen und schon hat man eine Karte mit richtig gut und plausibel aussehendem Unsinn statt einer anständigen Fehlermeldung.

Auch für teilweise erfasste Linien ist so etwas sehr ungünstig.

Und dann gibt es noch Linien, die sich damit überhaupt nicht sinnvoll erfassen lassen wie z.B. die Fährverbindung zwischen Norddeich Mole und Juist. Ob man da 40 Minuten länger fährt oder nicht macht den Unterschied zwischen "alles klar" und "Zug verpasst und ich brauche eine neue Fahrkarte" aus.

Ich seh immernoch die Zukunft... dass man mit einem Routingprogramm eine Strecke generieren kann die vielleicht noch mit Via-Punkten korrigieren und dann dass Ergebnis als z.B. Relation statisch abspeichert. 😎 😎 😎 😎 Würde auch viele potenzielle Fehler vermeiden..

Nach dem lesen dieser Beiträge:

Das ist sicher für Spezialisten interessant und richtig dies auch zu diskutieren.

Für einen einfachen unbedarften Dateneinträger sollte eine Haltestelle "einfach" einzutragen sein, meinetwegen mit ergänzenden Schlüsseln wie Bahnsteignummer, Liniennummer, Name, Referenz, ... (neuerdings bei uns mit QR-Code zu Fahrplan/-änderungen). Und bis dahin sollte das "Fußgängerrouting" führen.

Die daraus abzuleitende Relation (Fahrpläne?) sind schon spezieller. Einige werden sicher diese Aufgabe übernehmen. Dort darf aber eine Änderung an einer Haltestelle nicht zum "Chaos" führen.

Ob ein Zug auf Gleis 1 oder 1a oder 2 hält ist oft auch situationsbedingt - genauso die Bushalte. Diese müssten einfach die "Haltestellen" abfragen.

Endlich eine Verwendung für die Stop-Position? Würde es nicht genauso funktionieren, wenn die atomaren Segmente den Weg von einer Platform zur nächsten beschreiben würden?
Egal ob Stop oder Platform, an jeder Haltestelle müßten die ways aufgetrennt werden.

Grundsätzliche Frage: Wo sollte die Schnittstelle zwischen OSM-Daten und Fahrplandaten sein?

Ich könnte mir vorstellen, sofern es denn einmal freie Fahrplandaten mit eindeutig zuordnenden Haltepunkten (IFOPT?) gibt, es ausreichen sollte, die Haltestellen und die Fahrwege zwischen den Haltestellen (atomare Segmente) zu taggen.

Ich sehe keinen Sinn darin, dutzende Fahrweg-Relationen in den OSM-Daten zu haben, ohne zu wissen, wann diese bedient werden. Im Eisenbahnbereich kommt es auch immer wieder aus betrieblichen Gründen zu Gleis- und damit auch zu Bahnsteig-wechseln.

axelr wrote:

Der Ein- Ausstiegpunkt für eine Fußgängernavigation wird durch ein Lot von der stop_position auf die nächstgelegen platform-Linie gebildet. Der Fußpunkt oder das Linienende ist dieser Ein- Ausstiegspunkt und wäre für mich auch die Position für das Haltestellensymbol.

Du gehst da von Vorstellungen aus, die nicht PTv2 sind.
In PTv2 gehört zu einem stop nicht unbedingt eine platform. Es können aber auch mehrere dazu gehören.
In PTv2 gehört zu einer platform nicht unbedingt ein stop. Es können aber auch mehrere dazu gehören.
Ob eine platform "nächstgelegen" ist, ist völlig egal.

In dem Bild wird dargestellt, dass die Busse nur nach Norden fahren. Das kann man aus der Haltestellenbeschreibung nicht schließen. Man kann es nicht einmal nach Analyse aller gemappten Routen schließen.

geri-oc wrote:

Für einen einfachen unbedarften Dateneinträger sollte eine Haltestelle "einfach" einzutragen sein, meinetwegen mit ergänzenden Schlüsseln wie Bahnsteignummer, Liniennummer, Name, Referenz, ... (neuerdings bei uns mit QR-Code zu Fahrplan/-änderungen). Und bis dahin sollte das "Fußgängerrouting" führen.

Fast genau das habe im P3-Vorschlag versucht. Die real vorhandenen Objekte sollen einfach als solche gemappt werden -- ohne jede Rücksicht auf ÖPV-Routen. Die ÖPV-Routen dagegen stützen sich nur auf die Punkte des Fußgängerrouting (PIO). Oft fallen diese beiden Sachen zusammen, aber das muss nicht so sein.

Ich habe auch den Eindruck, dass seit ungefähr Oxomoa der Versuch unternommen wurde, den gesamten ÖPNV vom Ruftaxi bis zum ICE mit einem allmächtigen System zu beschreiben. Das wurde dann notwendigerweise so umfangreich, dass der Normalmapper nicht mehr überblickt, wie er relativ primitive Sachen eintragen kann und es lieber ganz bleiben lässt.

Ich plädiere dafür, das Ganze in mindestens zwei Gruppen aufzuteilen:
a) Alles was "on the ground" sichtbar ist und einfach zuzuordnen ist, wie Haltestellen (an Hand der Schilder), Bahnsteige, Gleise.
b) Alle Besonderheiten und komplizierteren Objekte wie Busbahnhöfe, U-Bahn-Ausgänge, kombinierte Strecken in einer Abteilung "für Experten", für die es natürlich einer viel ausführlicheren Beschreibung und Festlegung bedarf.

a) ist natürlich eine Teilmenge von b).

Mit a) und primitiven Relationen, die nur die Reihenfolge der Haltestellen enthalten, kann man z.B. schon einen Netzplan und eine kombinierte Fußgänger-ÖPNV-Navigation erzeugen. Es wäre eine Überlegung wert, ob es sich lohnt, die Linie(n) als (später redundanten) Tag in das Haltestellen-Objekt einzutragen. Das Erzeugen der Linien-Relation wird dadurch jedenfalls erleichtert.

Anders als z.B. bei Wander- oder Fahrradrouten hat beim ÖPNV der exakte Routenverlauf eine geringere Priorität für den Nutzer. Man braucht ihn eigentlich nur für die Darstellung auf der Karte.

seichter wrote:

Anders als z.B. bei Wander- oder Fahrradrouten hat beim ÖPNV der exakte Routenverlauf eine geringere Priorität für den Nutzer. Man braucht ihn eigentlich nur für die Darstellung auf der Karte.

Der Vorschlag Haltestellen in (einfache) Routenrelation zubringen, finde ich gut. Dann kann man für die Linie 333 eine Route mit Haltestellen A, B, C, ... anzeigen.
Wichtig wäre schon, wo die Route 333 verläuft - damit kann ich Haltestellen "ohne umsteigen" finden bzw. wo ich auf eine andere Route wechseln muss, wenn ich nach Z möchte.

slhh wrote:

PTv3 könnte etwas in diese Richtung gehen. Wir könnten für den Fahrweg atomare Segmente anlegen, die wir aber in der Regel nicht in die Linienrelation aufnehmen. Diese atomaren Segmente würden in der Regel von den Stop-Positionen einer Haltestelle zu denen der nächsten Haltestelle führen. Die Linienrelation würde dann in der Regel nur Haltestellen (vermutlich in Form von Stop-Positionen) auflisten. Die Auswertung hat dann die zu den genutzen Stop-Positionen jeweils aufeinanderfolgender Haltestellen passende atomare Segment zu verwenden, die über die Miglidschaft der Stop Position als from oder to node des atomaren Segments einfach aufzufinden sind.

Einen richtigen Top-Down Ansatz. 🙂

Es wäre für den Auswertung einfacher die atomaren Segmenten in der Relation auf zu nehmen. Damit weiss man a) das der Segment noch benuzt wird, b) haben Overpass und andere Auswerter weiniger Probleme der Fahrweg zu identifizieren/an zu zeigen und c) kann man nicht-haltende Fahrwege machen indem man nicht der Halt aber doch die Segmenten in der Relation mit aufnimmt.

Ein Problem löst es nicht: es ist noch immer nötig für jede Variante eine Relation zu erstellen. Ich weiss auch nicht ob es weniger aufwand ist die Relationen so an zu legen.

Was sind "atomaren Segmente"

atomar --> kleines Teilchen.. bzw. Atom das kleinst überhaupt... bei OSM wäre das eine Node ohne Eigenschaften...
Segment --> ein Teilstück... bei OSM... ein Teilstück eine Weges?

Ein Weg mit 2 Nodes ohne Eigenschaften?????????????? Das hört sich toll an aber Sinn gibt das nicht.. 🤔

Maarten Deen wrote:

Ein Problem löst es nicht: es ist noch immer nötig für jede Variante eine Relation zu erstellen. Ich weiss auch nicht ob es weniger aufwand ist die Relationen so an zu legen.

Varianten kann man aus dem "verlinkte Fahrplan" lesen.
M.E. würde schon ein Routenverlauf aus der Abfolge der Haltestellen ausreichen. Wenn z.B. der "Eilbus" zwei, drei Haltestellen nicht anfährt, ist das aus dem "Fahrplan" ersichtlich.

geri-oc wrote:

Wichtig wäre schon, wo die Route 333 verläuft - damit kann ich Haltestellen "ohne umsteigen" finden bzw. wo ich auf eine andere Route wechseln muss, wenn ich nach Z möchte.

Die jetztigen Daten... bringen höchstens die Idee wie man es fahren könnte und welche Linien so möglich wären. Aber ohne Fahrplan mit Zeiten und Häufigkeit.. würd ich mit dem OSM Plan nirgends versuchen.. über 2 Linien irgendwo hinzukommen... außer ich hätte keine andere Wahl. 😉

Ich würde es viel praktischer find wenn eine Link zur Online-Auskunft des Verkehrsbetriebes hinterlegt wäre.. würd mir meist mehr helfen.. als zu raten wo es da vielleicht hingeht...

http://www.openstreetmap.org/node/37408 … 6&layers=T

Außerdem haben unsere Haltestellen den Link in einem QR_Code (bzw. der Link in OSM ist der QR-Code).

EDIT: Link

miche101 wrote:

Was sind "atomaren Segmente"

atomar --> kleines Teilchen.. bzw. Atom das kleinst überhaupt... bei OSM wäre das eine Node ohne Eigenschaften...
Segment --> ein Teilstück... bei OSM... ein Teilstück eine Weges?

Ein Weg mit 2 Nodes ohne Eigenschaften?????????????? Das hört sich toll an aber Sinn gibt das nicht.. 🤔

Wie ich es verstanden hab: Teilstücke (Relations) die von einen bis der nächsten Halt gehen. Diese definieren dann den Laufweg.
Also: Linie 1 hat Halte A, B und C.
Dann gibt es Relationen fur den laufweg A->B und B->C, diese kommen in der Busrelation zusammen mit die Halte.

geri-oc wrote:

Maarten Deen wrote:

Ein Problem löst es nicht: es ist noch immer nötig für jede Variante eine Relation zu erstellen. Ich weiss auch nicht ob es weniger aufwand ist die Relationen so an zu legen.

Varianten kann man aus dem "verlinkte Fahrplan" lesen.
M.E. würde schon ein Routenverlauf aus der Abfolge der Haltestellen ausreichen. Wenn z.B. der "Eilbus" zwei, drei Haltestellen nicht anfährt, ist das aus dem "Fahrplan" ersichtlich.

Stimmt. Es werden eigentlich nur die Segmenten zwischen die Halten gebraucht. Aber dafür soll man sie dan in der Relation mit einbinden. Wenn der laufweg herausgefunden werden muss an hand von stop_position1 => stop_position3 und es Segmenten
stop_position1 => stop_position2, stop_position2 => stop_position3, stop_position1 => stop_position5, stop_position5 => stop_position3, kann der Laufweg nicht identifiziert werden.

Sowas ist 😎 ist sogar Haltestellenscharf...

Aber des wäre schon mal cool wenn man mit OSMand mit dem Handy auf eine Bushaltestelle klickt... dann, wenn vorhanden, zur Online Auskunft des jeweiligen Verkehrbetriebes komme.... bzw. direkt zum Fahrplan dieser Linie... Abfahrsmonitor... zur App, Ticketshop usw. was auch immer....

Maarten Deen wrote:

Wie ich es verstanden hab: Teilstücke (Relations) die von einen bis der nächsten Halt gehen. Diese definieren dann den Laufweg.
Also: Linie 1 hat Halte A, B und C.
Dann gibt es Relationen fur den laufweg A->B und B->C, diese kommen in der Busrelation zusammen mit die Halte.

Aso der Weg zwischen zwei Haltestelle... diese Relation könnte man dann für mehrere Linien verwenden die zwischen den gleichen Haltestellen fahren.

Aber die Bezeichnung ist trotzdem irreführend... 😉

seichter wrote:

Ich habe auch den Eindruck, dass seit ungefähr Oxomoa der Versuch unternommen wurde, den gesamten ÖPNV vom Ruftaxi bis zum ICE mit einem allmächtigen System zu beschreiben. Das wurde dann notwendigerweise so umfangreich, dass der Normalmapper nicht mehr überblickt, wie er relativ primitive Sachen eintragen kann und es lieber ganz bleiben lässt.
(...)

Was mir fehlt sind die use-cases. Was soll mit den Daten machbar sein, und was nicht? Und dann sollte man noch kurz darüber nachdenken, ob die use-cases auch nützlich sind ... zumindest wenn die Bereitstellung der dazu notwendigen Daten kompliziert ist.

Der Vorschlag ist grundsätzlich gar nicht schlecht. Eines der Hauptprobleme bei PTv2 ist damit allerdings nicht gelöst, nämlich die Erfassung jeder einzelnen Linienvariante. Den dazu notwendigen Aufwand sehe ich in keinem Verhältnis zum Nutzen. Gerade Busse im ländlichen Bereich haben schnell mal eine Vielzahl von unterschiedlichen Fahrtwegen. Die alle zu erfassen macht einfach keinen Spaß. Wer erstellt schon freiwillig für einen Fahrplan wie http://www.suedbadenbus.de/suedbadenbus … 2_7245.pdf jede einzelne Routenvariante? (Abgesehen von ein paar Enthusiasten, die aber nicht reichen, um flächendeckend halbwegs vollständige und aktuelle Daten hinzubekommen)

Ich würde hier fast wieder zu PTv1 tendieren, wo man einfach nur in einer Relation pro Linie die befahrenen Ways gesammelt hat. Damit ist pro Linie nur noch eine Relation nötig, die auch nicht sortiert sein muss. Der Aufwand zur Pflege reduziert sich damit auch extrem, da die Infos weniger schnell veraltet sind und dann auch nur eine Relation anzupassen wäre. Für ein reines Rendering wie bei openptmap.org reicht das völlig. Und wenn jemand den genauen Fahrtverlauf einer bestimmten Fahrt wissen will, kann er das über Routing ermitteln. Dabei wäre die Relationen auch hilfreich, denn damit könnte man das Routing auf die in den Relationen enthaltenen Ways beschränken, sodass man auch ziemlich genau den exakten Fahrtweg ermitteln würde.

Wir sollten uns fragen, ob wir in OSM wirklich die einzelnen Routenvarianten so detailliert erfassen und mit jedem Fahrplanwechsel pflegen sollen (was bisher beides überhaupt nicht funktioniert), oder ob wir uns nicht auf Routen nach PTv1 oder sogar nur die reine Infrastruktur der Haltestellen beschränken sollen, sodass man mit externen Fahrplandaten die genauen Verläufe jeder einzelnen Fahrt per Routing bestimmen kann.

An dieser Stelle schon einmal die Ankündigung, dass ich auf der FOSSGIS einen Vortrag zum ÖPNV-Mapping halten werde. Dort werde ich unter anderem auf die Taggingschemata, den generellen Nutzen von ÖPNV-Daten in OSM und mögliche Vereinfachungen eingehen.

Gruß
Alex

rurseekatze wrote:

Wer erstellt schon freiwillig für einen Fahrplan wie http://www.suedbadenbus.de/suedbadenbus … 2_7245.pdf jede einzelne Routenvariante?

Das ist eine gutes Beispiel 😎 da muss man ja froh sein wenn der Fahrere des Busses weiss wo er hin muss, wer da noch durchblick... Glückwunsch.. 🤣

rurseekatze wrote:

Wir sollten uns fragen, ob wir in OSM wirklich die einzelnen Routenvarianten so detailliert erfassen ...

In #68 habe ich sowas auch schon vorgeschlagen, warum sollte man alles ausschließlich mit OSM-Daten erschlagen?

rurseekatze wrote:

Die alle zu erfassen macht einfach keinen Spaß. Wer erstellt schon freiwillig für einen Fahrplan wie http://www.suedbadenbus.de/suedbadenbus … 2_7245.pdf jede einzelne Routenvariante?

Solche Leichen ähm Routen dürfte so ziemlich jede ländliche Gegend im Keller auf der Straße haben... unser 476er ist da ähnlich: http://www.rvs-lds.de/tl_files/fahrplaene/476.pdf

Ich hatte mal angefangen, bin dann aber am Erfassungsaufwand und auch mangels Fehlerprüftools gescheitert...

Sven

huby1691 wrote:

rurseekatze wrote:

Wir sollten uns fragen, ob wir in OSM wirklich die einzelnen Routenvarianten so detailliert erfassen ...

In #68 habe ich sowas auch schon vorgeschlagen, warum sollte man alles ausschließlich mit OSM-Daten erschlagen?

Wenn ich solche Fahrpläne sehe, würde ich vermutlich auch kapitulieren und es bei einer Masterrelation mit allen Haltestellen (halbwegs geordnet) belassen. Die müsste dann den Betreiber und auch einen Link auf den Fahrplan enthalten. Nur dieser müsste idR beim halb- bis ganzjährigem Fahrplanwechsel, bei dem es sehr wahrscheinlich auch Routenänderungen gibt, aktualisiert werden.

Use-Case-Beispiel: Bei der OSM-basierten Suche nach den nächsten ÖPNV-Haltestellen wird mir neben der Navigation dorthin im ersten Schritt zusätzlich der dortige Fahrplan angeboten.

Hi,

ich hab mir... vor Tagen angefangen mich zu spielen um mir das Erstellen einer Relation für Bus einfacher zu machen.

Also... eine OSM-Datei genommen mit einer Relation wo schon alle Bushaltestellen drin sind.. automatisch (XSLT) 😎 eine HTML-Liste generieren lassen... damit ich dann die Variante bzw. überhaupt den Weg zusammen klicken kann... um dann einen Link der Haltestellen zu erhalten... um einen Vorschlag der Wegwahl zu haben...

Ist noch am Anfang aber es funktioniert schon 🙂 Aber ist mit heißer Nagel gestrickt... also nicht so genau hinsehen 🤣

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

streckenkundler wrote:

rurseekatze wrote:

Die alle zu erfassen macht einfach keinen Spaß. Wer erstellt schon freiwillig für einen Fahrplan wie http://www.suedbadenbus.de/suedbadenbus … 2_7245.pdf jede einzelne Routenvariante?

Solche Leichen ähm Routen dürfte so ziemlich jede ländliche Gegend im Keller auf der Straße haben... unser 476er ist da ähnlich: http://www.rvs-lds.de/tl_files/fahrplaene/476.pdf

Ich hatte mal angefangen, bin dann aber am Erfassungsaufwand und auch mangels Fehlerprüftools gescheitert...

Sven

Du hast doch den Bus502 auch sehr gut erfasst oder mit erfasst. http://www.overpass-api.de/api/sketch-l … tyle=padua , offensichtlich gibt es da auch etwa 7 Varianten.

Die angedachte Teilstrecken-Zusammenfassung als Unter-Relation wäre hier keine große Hilfe.

Gruß Axel

axelr wrote:

Du hast doch den Bus502 auch sehr gut erfasst oder mit erfasst. http://www.overpass-api.de/api/sketch-l … tyle=padua , offensichtlich gibt es da auch etwa 7 Varianten.

Gruß Axel

Ja, ich hab mir auch reichlich Mühe gegeben. Auch der 500er hat mehrere Varianten.

Jetzt ist unsere Bahnhofstraße mindestens bis Herbst gesperrt. Ein Umbau der Relationen ersparte ich mir aber wahrscheinlich. Hier führen viele Routen entlang: http://openptmap.org/?zoom=17&lat=51.93 … =B0000TFFT. Das wäre echt aufwändig, weil diese Straße für den Busverkehr eine zentrale Straße ist.

Sven

huby1691 wrote:

Würde es nicht genauso funktionieren, wenn die atomaren Segmente den Weg von einer Platform zur nächsten beschreiben würden?
Egal ob Stop oder Platform, an jeder Haltestelle müßten die ways aufgetrennt werden.

Das Auftrennen könnte man zwar so definieren, ist aber nicht zwingend erforderlich. Alternativ kann man nur dort trennen, wo man es auch heute schon machen muss. Dann sind bei der Auswertung Duplikate von Wegen zu entfernen. Alternativ kann die Auswertung auch die über die Stop-Positionen der atomaren Segmente überstehenden Wegabschnitte in den Ergebnisdaten abschneiden.

Technisch würde es mit EInschränkungen auch mit Platform statt Stop funktionieren.

miche101 wrote:

Hi,

ich hab mir... vor Tagen angefangen mich zu spielen um mir das Erstellen einer Relation für Bus einfacher zu machen.

Also... eine OSM-Datei genommen mit einer Relation wo schon alle Bushaltestellen drin sind.. automatisch (XSLT) 😎 eine HTML-Liste generieren lassen... damit ich dann die Variante bzw. überhaupt den Weg zusammen klicken kann... um dann einen Link der Haltestellen zu erhalten... um einen Vorschlag der Wegwahl zu haben...

Ist noch am Anfang aber es funktioniert schon 🙂 Aber ist mit heißer Nagel gestrickt... also nicht so genau hinsehen 🤣

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

Beispiel:
https://graphhopper.com/maps/?point=48. … =Omniscale

Eine (Bus-)Linien-Relation muss nur die Haltestellen enthalten. Wenn dann an den Haltestellen noch der "Fahrplan" verlinkt ist - perfekt.

Ein (noch jetziges) Problem wird es aber mit Bahn, Straßenbahn, U-Bahn, ...
Oder: Die vielen Verkehrsbetriebe (Mentz, VVN, ...) stellen einen "öffentlichen" ÖPNV-Router als "Dankeschön" für die Erfassung der Haltestellen in OSM zur Verfügung, deren Daten sie ja nun auch vermehrt nutzen.

geri-oc wrote:

Eine (Bus-)Linien-Relation muss nur die Haltestellen enthalten. Wenn dann an den Haltestellen noch der "Fahrplan" verlinkt ist - perfekt.

Und wenn eine Haltestelle fehlte und jemand sie mappt und dann mit "Zur Relation hinzufügen" hinzufügt, dann hat die berechnete Route nur noch Schrottwert. Das merkt dann aber keiner weil es keine Grundlage für eine Fehlermeldung mehr gibt.

Weide wrote:

geri-oc wrote:

Eine (Bus-)Linien-Relation muss nur die Haltestellen enthalten. Wenn dann an den Haltestellen noch der "Fahrplan" verlinkt ist - perfekt.

Und wenn eine Haltestelle fehlte und jemand sie mappt und dann mit "Zur Relation hinzufügen" hinzufügt, dann hat die berechnete Route nur noch Schrottwert. Das merkt dann aber keiner weil es keine Grundlage für eine Fehlermeldung mehr gibt.

Das ist ganz klar der Preis dafür, dass die Fahrlinien fehlen. Je weniger Informationen in der Relation stecken, desto empfindlicher wird sie gegenüber Fehlern, hier die Reihenfolge der Haltestellen.
Zur Not könnte ein QA-Tool die Abstände benachbarter Haltestellen überprüfen, "perfekt" ist das aber nicht.
Aber andererseits: Wenn jemand den Fahrweg falsch einträgt, merkt das ein QA-Tool auch nicht.

Weide wrote:

Und wenn eine Haltestelle fehlte und jemand sie mappt und dann mit "Zur Relation hinzufügen" hinzufügt, dann hat die berechnete Route nur noch Schrottwert. Das merkt dann aber keiner weil es keine Grundlage für eine Fehlermeldung mehr gibt.

Zumindest auf der Verkehrskarte wäre der Fehler wohl sichtbar. Der derzeitige Zustand ist wohl eher, QA-Tools zeigen Fehler an und niemand korrigiert sie, außer vielleicht in einigen Regionen. Das ist auch nicht besser.

geri-oc wrote:

Beispiel:
https://graphhopper.com/maps/?point=48. … =Omniscale

Eine (Bus-)Linien-Relation muss nur die Haltestellen enthalten. Wenn dann an den Haltestellen noch der "Fahrplan" verlinkt ist - perfekt.

Ganz so einfach ist es leider auch nicht. Ein Vergleich mit der Transport Map zeigt, dass die Busroute hier teilweise falsch ist.

Man könnte dem Router allerdings helfen:
- Alle highways auf denen ein Linienbus verkehrt, werden mit einem speziellen Tag gekennzeichnet. Dann brauchen nur diese zum Routen verwendet zu werden.
- Alternativ könnten wir alle längeren Ways, die von einer Linie inkl aller Varianten verwendet werden, in eine gemeinsame Fahrwegrelation (unterhalb von Route-Master) aufnehmen. Diese Wege sind dann vom Router bevorzugt zu verwenden. Da beim Aufnehmen der Wege weder Richtung noch Reihenfolge zu berücksichtigen sind und auch die Auswahl der Linienvarianten entfällt, wird der Aufwand stark reduziert, zumal auch die vielen kleinen Wege in Kreuzungsbereichen ignoriert werden können. Da Lücken zulässig wären, braucht der Editor die Relationen auch nicht mehr gegen Zerbrechen zu schützen, was die highway Bearbeitung stark vereinfacht.

geri-oc wrote:

Ein (noch jetziges) Problem wird es aber mit Bahn, Straßenbahn, U-Bahn, ...

Im Schienennetz ist das Routing wohl eher einfach, da weniger Wahlmöglichkeiten vorhanden sind, zumal man Nebengleise für Zugfahrten ignorieren kann.

Beim Rendern einer Verkehrskarte haben wir noch ein grundsätzliches Problem mit Routinglösungen: Wie erkennt der Renderer welche Linien für den zu rendernden Bereich zu routen sind? Wir werden eine maximale zulässige Entfernung zwischen Elementen in den Linienrelationen definieren müssen. Dann hat der Renderer alle Linien zu routen, die in einer entsprechenden Entfernung vom zu rendernden Kartenausschnitt direkte oder indirekte Member haben.

Weide wrote:

Und wenn eine Haltestelle fehlte und jemand sie mappt und dann mit "Zur Relation hinzufügen" hinzufügt, dann hat die berechnete Route nur noch Schrottwert. Das merkt dann aber keiner weil es keine Grundlage für eine Fehlermeldung mehr gibt.

Ja des ist dann schon eine Gefahr... dahingehend.. ist die jetzige Relation mit allen Teilen robuster.. Aber vielleicht zum erstellen einer Relation? Das mir das Routing-Programm... Eine Relation ausgibt...

Bis jetzt kann man mit einem Routing-Programm mir das anzeigen lassen... kann mir ein GPX downloaden... welches im Josm anhängen kann... usw. ist schon hilfreich..

Was ein Routing-Programm besser kann... alle Tags zu beachten... Einbahnstr. irgendwelche Beschränkungen usw. usw. Abbiegebeschränkungen usw.. Wer überblickt das schon alles beim erstellen einer Route?

Aber hier würde es schon gut funktionieren... auch wenn noch eine Bushaltestelle auf dem Weg fehlt..

https://openstreetmap.org/relation/122830

https://graphhopper.com/maps/?point=48. … =Omniscale

miche101 wrote:

Was ein Routing-Programm besser kann... alle Tags zu beachten... Einbahnstr. irgendwelche Beschränkungen usw. usw. Abbiegebeschränkungen usw.. Wer überblickt das schon alles beim erstellen einer Route?

Ich denke, niemand sollte Einbahnstraßen etc. beim Anlegen einer Busroute berücksichtigen! Man sollte einfach nur das mappen, was man festgestellt hat.

Weide wrote:

Ich denke, niemand sollte Einbahnstraßen etc. beim Anlegen einer Busroute berücksichtigen! Man sollte einfach nur das mappen, was man festgestellt hat.

OK 🤣 also lieber gegen Verkehrsregeln verstoßen...

miche101 wrote:

OK lol also lieber gegen Verkehrsregeln verstoßen...

Ja. Der Verstoß gegen die Verkehrsregeln ist ein wertvoller Hinweis. Vermutlich ist bei der Straße was falsch gemappt worden und man kann es korrigieren.

Weide wrote:

Ja. Der Verstoß gegen die Verkehrsregeln ist ein wertvoller Hinweis. Vermutlich ist bei der Straße was falsch gemappt worden und man kann es korrigieren.

Ich verstehe nicht wie du Buslinien einträgst... bzw. herausfindest wie der Bus wo fährt? Fährst du mit dem z.B. Bus von Anfang bis Ende und dann wieder mit diesen wieder zurück bis zum Anfang? Und dann das ganze mit jeder Variante die diese Buslinie hat dann das gleiche noch einmal? Mir erschliesst sich deine Arbeitweise dabei jetzt nicht ganz? 🤔 Wenn ich mit jeder Buslinie und Variante die ich schon eingetragen habe fahren müsste.. dann wüsste ich was ich das nächste halbe Jahr mache.. und wäre viel Geld los 🤣

miche101 wrote:

Ich verstehe nicht wie du Buslinien einträgst... bzw. herausfindest wie der Bus wo fährt? Fährst du mit dem z.B. Bus von Anfang bis Ende und dann wieder mit diesen wieder zurück bis zum Anfang? Und dann das ganze mit jeder Variante die diese Buslinie hat dann das gleiche noch einmal?

Ja, eigentlich schon. Meist fahre ich nicht die ganze Strecke und trage dann eben nur einen Teil ein.

Die meisten Buslinien an denen ich mitgearbeitet habe sind aber nicht von mir erfasst worden ... ich hab sie nur repariert.

Man braucht schon eine Monatskarte oder sowas sonst zahlt man sich dumm und dusselig. Da ich kein Auto habe gilt das bei mir aber sogar im Urlaub. :-)

Ich mach es so gut es geht, ohne mit den ganzen Bussen zu fahren... und auch vervollständigen.. reparieren usw. fehlende ergänzen. Mach etliche Fehler/Hinweise.. sollte was nicht stimmen kann man es ja korrigieren... aber der Anfang ist schon gemacht und der macht am meisten Arbeit 🙂 Ob jetzt der Bus die eine oder eventuell andere Straße nimmt ist eigentlich fast egal... Hauptsache er hällt an der nächsten Haltestelle 🙂

Wenn ich den Fahrweg der Buslinie nicht kenne, würde ich ihn auch nicht taggen.

seichter wrote:

und es bei einer Masterrelation mit allen Haltestellen (halbwegs geordnet) belassen.

Außerdem müßte man sich Gedanken über die Datenquelle machen, ist Abschreiben von Fahrplänen im Sinne von OSM?

huby1691 wrote:

Außerdem müßte man sich Gedanken über die Datenquelle machen, ist Abschreiben von Fahrplänen im Sinne von OSM?

Ist im Sinne von OSM 😉. Hab da mal gehört... alles was sich vor Ort überprüfen lässt kann man OSM hinzufügen. Da der Fahrplan vor Ort öffentlich aushängt und von jedermann überprüft werden kann.... passt also... 😎

Da hier im Thread auch mein damaliger PTv3-Entwurf diskutiert wurde:
Es gibt einen neuen ... die Segmente sind komplett wieder rausgeflogen und vieles wurde umbenannt. Siehe http://gafte.de

hfst wrote:

Was mir fehlt sind die use-cases. Was soll mit den Daten machbar sein, und was nicht? Und dann sollte man noch kurz darüber nachdenken, ob die use-cases auch nützlich sind ... zumindest wenn die Bereitstellung der dazu notwendigen Daten kompliziert ist.

Also ich hätte folgende Use-Cases:

-Erstellung von Netzplänen: Gibt es etwa bei der Rheinbahn

-Generieren von Services wie dem DB-Zugradar, bei denen die exakte Route bekannt sein muss.

-ÖPNV-Router, die den Weg zur platform (bei einem platform-way bis auf Höhe der entsprechenden stop-position) genau anzeigen und damit auch etwa Umsteigezeiten berechnen können.

-Abfahrtsmonitore wie Öffi könnten bei korrekten Daten die stop_areas auf einer Interaktiven Karte zeigen, ein Klick auf eine stop_area führt zu einem Abfahrtsmonitor, und wenn man dann auf eine Abfahrt klickt wird mittels der online hinterlegten Echtzeit-Halteposition die position der entsprechenden stop_position auf einer Karte angezeit.

Wie du siehst ist vieles denkbar und dank PTv2 auch machbar, man muss nur die Daten korrekt erfassen. Dass der entsprechende Aufwand sogar wirtschaftlich sein kann zeigen Unternehmen wie Menz, die immer mehr Kunden betreuen.

Dass es OSM-Daten allerdings auch in die internen Abläufe bei Verkehrsunternehmen schaffen wage ich jedoch sehr zu bezweifeln, dafür sind unsere Daten leider viel zu vandalismusanfällig und damit unzuverlässig. Für die Kundeninformation sind sie jedoch sehr gut geeignet.

Grüße

hsimpson wrote:

Dass es OSM-Daten allerdings auch in die internen Abläufe bei Verkehrsunternehmen schaffen wage ich jedoch sehr zu bezweifeln, dafür sind unsere Daten leider viel zu vandalismusanfällig und damit unzuverlässig. Für die Kundeninformation sind sie jedoch sehr gut geeignet.

Ich glaube noch nicht mal das Vandalismus das entscheidende Problem wäre. Dem kann man begegnen, in dem man beim Fahrplanwechsel eine Review der Daten macht und diese dann für den eigenen Gebrauch einfriert, bzw Änderungen nur übernimmt wenn diese überprüft wurden.

Ich glaube aber für solche Zwecke ist unser Datenformat nicht geeignet. Verkehrsunternehmen brauchen auch Angaben wie Fahrzeugumläuf, Ruhezeiten usw. Wir sollten uns auf die Fahrgastaspekte konzentrieren.

hsimpson wrote:

-ÖPNV-Router, die den Weg zur platform (bei einem platform-way bis auf Höhe der entsprechenden stop-position) genau anzeigen und damit auch etwa Umsteigezeiten berechnen können.

Da liegt die Zukunft. Bisher arbeiten die Verkehrsunternehmen in der Regel mit statischen Umsteigematritzen. Das macht das Routing sehr unfexibel und erlaubt auch nicht, dem Kunden exakte Umsteigewege anzuzeigen. Das Interesse ist groß.

Trockennasenaffe wrote:

Da liegt die Zukunft.

Das ist mancherorts schon Gegenwart. Dabei werden hier im VRR die Haltestellen als Nodes in einer Datenbank des Verkehrsunternehmens gespeichert und zwischen den Nodes wird Fußwegrouting auf OSM-Daten gemacht. D.H. also lustigerweise, dass für den ÖPNV OSM-Daten genutzt werden, soweit es keine ÖPNV-Daten sind.

Je nach Qualität der einzelnen Nodes in der Nodedatenbank des Verkehrsunternehmens ist die Qualität unterschiedlich. Wir könnten evtl. durch unsere linienförmigen und flächenförmigen Steige bei Bahnen bessere Ergebnisse erzielen, da ein einzelner Node bei einem Bahnsteig mit mehreren Abgängen schlechte Abstände liefert...

Weide wrote:

Trockennasenaffe wrote:

Da liegt die Zukunft.

Das ist mancherorts schon Gegenwart. Dabei werden hier im VRR die Haltestellen als Nodes in einer Datenbank des Verkehrsunternehmens gespeichert und zwischen den Nodes wird Fußwegrouting auf OSM-Daten gemacht. D.H. also lustigerweise, dass für den ÖPNV OSM-Daten genutzt werden, soweit es keine ÖPNV-Daten sind.

Das ist mir schon klar. Ich meine, dass bisher z.B. kein Bahnsteig zu Bahnsteig Routing gemacht wird, das geht momentan nur mit statischen Matritzen mit statischen Umsteigezeiten. Würde man auch hier die OSM daten nutzen um zu ermitteln welche Umsteigebeziegungen möglich sind, wäre das sehr viel flexibler.

Weide wrote:

Da hier im Thread auch mein damaliger PTv3-Entwurf diskutiert wurde:
Es gibt einen neuen ... die Segmente sind komplett wieder rausgeflogen und vieles wurde umbenannt. Siehe http://gafte.de

Ich haben ihn mir durchgelesen und finde ihn recht interessant, verstehe aber glaube ich nicht alles. Ich werde aber mal Feedback geben aber da immer nur einzelne Aspekte herausgreifen, da mir das sonst zu viel auf einmal wird. In diesem Fall PIOs:

Wenn ich das richtig verstanden habe, lösen PIOs u.a. das Problem, das Wartebereich und Platform nicht identisch sein müssen. PIOs markieren quasi die Grenze zwischen Fussgänger (Rollstuhl oder was auch immer) und ÖPNV-Routing richtig? Das halte ich für einen recht pragmatischen, nützlichen und intelligenten Ansatz. Hab da noch Fragen:

Lösen PIOs das Problem, dass es ggf unterschiedliche Bahnsteige zum Ein- und Ausstieg gibt und daher der PIO in beide Richtungen unterschiedlich sein müsste?

Wurde die wachsende Rolle des Bedarfsverkehrs berücksichtigt? Kann man so etwas wie "Einstieg nur nach Anmeldung 30min im Voraus" abbilden?

Was für real existierende Probleme lösen die PIOs noch?

Trockennasenaffe wrote:

Wenn ich das richtig verstanden habe, lösen PIOs u.a. das Problem, das Wartebereich und Platform nicht identisch sein müssen. PIOs markieren quasi die Grenze zwischen Fussgänger (Rollstuhl oder was auch immer) und ÖPNV-Routing richtig?

Ja. Wobei auch mal noch ein ganzes Stück zwischen PIO und Verkehrsmittel liegen kann. Z.B. wäre bei der Fähre Kiel-Göteborg der PIO im Gebäude von Stena Line, denn da muss man als Fußgänger hin -- da ist die Kontrollschleuse. Das Schiff fährt aber ein ganzes Stück entfernt ab. Dazwischen liegt ein langer Gang, der dann nicht erfasst ist. Aber in dem Gang gibt es auch keine Möglichkeit, sich zu verlaufen.

Trockennasenaffe wrote:

Lösen PIOs das Problem, dass es ggf unterschiedliche Bahnsteige zum Ein- und Ausstieg gibt und daher der PIO in beide Richtungen unterschiedlich sein müsste?

Nein. Aber man könnte die Rollen "pio-in" und "pio-out" dazunehmen. Über das "+" kann man ja beliebig viele Einzelangaben zu einem Halt machen. Man kann das Problem bei Autos (als Fährpassagiere) auch über oneway lösen ... aber das geht bei Fußgängern vermutlich nicht.

Trockennasenaffe wrote:

Wurde die wachsende Rolle des Bedarfsverkehrs berücksichtigt? Kann man so etwas wie "Einstieg nur nach Anmeldung 30min im Voraus" abbilden?

Nein. Jedenfalls habe ich keine Idee, wie man das mit vertretbarem Aufwand da reinbekommen kann. Das muss wohl über Fahrplanangaben gemacht werden.

Trockennasenaffe wrote:

Was für real existierende Probleme lösen die PIOs noch?

Konflikte mit dem Mapping physischer Objekte. Ich kenne einige gute Mapper, die keinen Nerv mehr haben auch nur eine Bushaltestelle anzulegen.

PIOs sind nie physisch. Es ist immer klar, dass man für einen Bahnsteig railway=platform und für einen physisch vorhandenen Bussteig highway=platform oder highway=pedestrian oder was-weiss-ich nehmen muss. Man kann das nie durch ptv3_object=pio ersetzen. Dadurch kann man auch mehrere PIOs auf einem Bahnsteig haben. In Mainz Hbf gäbe es z.B. auf dem physischen Bahnsteig an den Gleisen 4 und 5 die PIOs 4a, 4b, 4, 5a, 5b und 5. In Duisburg Hbf gäbe es z.B. einen PIO für die relativ zum Bahnsteig sehr kurzen Doppelstockzüge. Damit käme man für das Umsteigen vom Zug in die U-Bahn auf realistische 300m ... vom Bahnsteig zur U-Bahn sind es dagegen nur 30m. (Die Zahlen sind grobe Schätzungen. Die genauen Zuglängen und Haltepositionen hab ich nicht.)

Trockennasenaffe wrote:

hsimpson wrote:

Dass es OSM-Daten allerdings auch in die internen Abläufe bei Verkehrsunternehmen schaffen wage ich jedoch sehr zu bezweifeln, dafür sind unsere Daten leider viel zu vandalismusanfällig und damit unzuverlässig. Für die Kundeninformation sind sie jedoch sehr gut geeignet.

Ich glaube noch nicht mal das Vandalismus das entscheidende Problem wäre. Dem kann man begegnen, in dem man beim Fahrplanwechsel eine Review der Daten macht und diese dann für den eigenen Gebrauch einfriert, bzw Änderungen nur übernimmt wenn diese überprüft wurden.

Ich glaube aber für solche Zwecke ist unser Datenformat nicht geeignet. Verkehrsunternehmen brauchen auch Angaben wie Fahrzeugumläuf, Ruhezeiten usw. Wir sollten uns auf die Fahrgastaspekte konzentrieren.

So ein Reviev dürfte zu viel Aufwand bei einer zu hohen Fehlerwarscheinlichkeit darstellen.

Fahrzeugümläufe etc. wären mit OSM problemlos errechenbar, wenn die Infrastruktur komplett erfasst ist. Die derzeitigen Programme, die so etwas berechnen, basieren auf deutlich rudimentärerern Daten, die nur die Entfernungen, Höchstgeschwindigkeiten, Signalpositionen, Haltepositionen und Steigungen beinhalten. Mehr braucht man dafür auch Infrastrukturseitig nicht und bis auf die Steigungsdaten sind unsere Daten in einigen Regionen schon sehr nahe an dem, was tatsächlich gebraucht wird. Dazu kommen natürlich dann noch die Fahrzeugeigenschaften wie der Beschleunigungswert und die Bremshundertstel. Aber das hat ja mit OSM nichts zu tun.

Aus den Daten wird dann erst mal die reine Fahrzeit berechnet und daraus kann man dann die notwendige Wendezeit ableiten. In einem späteren Schritt wird dann meist erst die Schichtplanung erstellt.

Aber ich bin da ganz deiner Meinung, dass wir uns besser auf die Fahrgastinformation fokussieren sollten, zumal die Reiseauskünfte in den wenigsten Fällen direkt vom Betreiber ausgegeben werden. Das ist eigentlich nur noch im eigenwirtschaftlichen Verkehr der Fall. Im Regionalverkehr kommen die Infos meist von den Verbünden, für die es auch ein nicht unerheblicher Aufwand sein kann die notwendigen Informationen zusammen zu tragen und dann alle auf ein Format zu bringen. Da kann OSM schon eine sehr gute Stütze sein.

Nicht umsonst sind die Verbünde mit die ersten kommerziellen Akteure gewesen, die nicht nur für das erstellen eines normalen OSM-Routers sehr tief in die OSM-Materie eingestiegen sind. Die meisten anderen kommerziellen Anwendungen von OSM beschränken sich auf das verwenden vom Mapnik als Hintergrundbild, manchmal werden noch kleinere Sachen gemacht wie die Auslesung der highway=motorway ways, um damit eine Echtzeit-Verkehrskarte zu erstellen, wie etwa beim WDR.

Grüße

Weide wrote:

Trockennasenaffe wrote:

Wenn ich das richtig verstanden habe, lösen PIOs u.a. das Problem, das Wartebereich und Platform nicht identisch sein müssen. PIOs markieren quasi die Grenze zwischen Fussgänger (Rollstuhl oder was auch immer) und ÖPNV-Routing richtig?

Ja. Wobei auch mal noch ein ganzes Stück zwischen PIO und Verkehrsmittel liegen kann. Z.B. wäre bei der Fähre Kiel-Göteborg der PIO im Gebäude von Stena Line, denn da muss man als Fußgänger hin -- da ist die Kontrollschleuse. Das Schiff fährt aber ein ganzes Stück entfernt ab. Dazwischen liegt ein langer Gang, der dann nicht erfasst ist. Aber in dem Gang gibt es auch keine Möglichkeit, sich zu verlaufen.

Für das Problem "Wie komme ich zum Verkehrsmittel" ist das ausreichend. Das Problem "Wie viel Zeit brauche ich zum Umsteigen?" bzw. "Wann muss ich da sein?" lässt sich damit aber ggf. nicht ohne externes Zusatzwissen lösen oder? Oder müsste dass dann schon in den Reisezeiten und Abfahrts- und Ankunftszeiten mit drin sein?

Ich frage mich auch wie das ist, wenn sich die Wege nach dem Wartebereich noch aufteilen können wie beim Flughafen. Was wäre dann der PIO? Was ist mit Systemen wie der TGV in Frankreich, bei denen es gar keine festen Bahnsteigzuordnungen gibt, sondern diese dynamisch disponiert werden? Aber vielleicht ist das sogar einfacher, das ist mir gerade nicht ganz klar.

Weide wrote:

Trockennasenaffe wrote:

Lösen PIOs das Problem, dass es ggf unterschiedliche Bahnsteige zum Ein- und Ausstieg gibt und daher der PIO in beide Richtungen unterschiedlich sein müsste?

Nein. Aber man könnte die Rollen "pio-in" und "pio-out" dazunehmen. Über das "+" kann man ja beliebig viele Einzelangaben zu einem Halt machen. Man kann das Problem bei Autos (als Fährpassagiere) auch über oneway lösen ... aber das geht bei Fußgängern vermutlich nicht.

Das würde wohl gehen. Ich denke da an Systeme wie die sog. "Spanische Lösung" z.B. rechts einsteigen links aussteigen. Ist bei vielen Metrosystemen weltweit recht verbreitet und sollte daher funktionieren.

Weide wrote:

Trockennasenaffe wrote:

Wurde die wachsende Rolle des Bedarfsverkehrs berücksichtigt? Kann man so etwas wie "Einstieg nur nach Anmeldung 30min im Voraus" abbilden?

Nein. Jedenfalls habe ich keine Idee, wie man das mit vertretbarem Aufwand da reinbekommen kann. Das muss wohl über Fahrplanangaben gemacht werden.

OK, da werde ich mir noch gedanken machen. Das ist wohl auch für die linien relevant, da werde ich vielleicht später noch etwas zu sagen.

Weide wrote:

In Mainz Hbf gäbe es z.B. auf dem physischen Bahnsteig an den Gleisen 4 und 5 die PIOs 4a, 4b, 4, 5a, 5b und 5.

Wären dass dann Nodes, Ways oder Flächen? Die würden dann immer zusätzlich zu vorhandenem physischer Objekten angelegt? Wenn ein PIO "4a" heißt, wie erfolgt dann die Zuordnung zu Mainz Hbf?

hsimpson wrote:

So ein Reviev dürfte zu viel Aufwand bei einer zu hohen Fehlerwarscheinlichkeit darstellen.

Wenn man die Daten ohnehin schon hat ist das natürlich erst mal ein großer Zusatzaufwand. Letztendlich müssen die Daten aber ohnehin einmal richtig erfasst und auf Fehler überprüft werden. Danach nur noch die Änderungen. Beim erfassen macht man sich noch zu nutze, dass die Community da viel kostenlose Vorarbeit geleistet hat. Gibt sogar Feuerwehreinsatzkarten auf OSM Basis: https://www.youtube.com/watch?v=1__IjaP1EY8. Da werden solche Verfahren beschrieben.

Trockennasenaffe wrote:

Für das Problem "Wie komme ich zum Verkehrsmittel" ist das ausreichend. Das Problem "Wie viel Zeit brauche ich zum Umsteigen?" bzw. "Wann muss ich da sein?" lässt sich damit aber ggf. nicht ohne externes Zusatzwissen lösen oder? Oder müsste dass dann schon in den Reisezeiten und Abfahrts- und Ankunftszeiten mit drin sein?

Ich denke, dass es bei solchen Gatesystemen immer Vorschriften gibt, wann man spätestens vor Abfahrt auftauchen muss. Ist man erstmal durch wird man auch mitgenommen und die Weglänge spielt keine Rolle.

Ich fürchte, dass man diese Vorlaufzeiten nicht mal sicher im Fahrplan findet. Ich meine mich zu erinnern, dass man bei den Fahrten mit der Fähre ab Göteborg je nach Wochentag und Saisonablauf verschiedene Zeiten hatte und erst ein oder zwei Tage vorher per Internet oder Telefon was genaues dazu erfahren hat.

Trockennasenaffe wrote:

Was ist mit Systemen wie der TGV in Frankreich, bei denen es gar keine festen Bahnsteigzuordnungen gibt, sondern diese dynamisch disponiert werden?

Die verschiedenen möglichen Bahnsteige werden mit der "alt-pio"-Rolle angegeben. Die alternativen Gleise im Bahnhof werden dabei ignoriert.

Das gilt aber nur, wenn es eine lokal auf den Bahnhof beschränkte Variation ist. Wenn die Züge ab Gleis 4 z.B. immer schon in A-Dorf statt in B-Dorf enden, dann ist es eine echte Variante und damit eine eigene Relation.

Trockennasenaffe wrote:

Das würde wohl gehen. Ich denke da an Systeme wie die sog. "Spanische Lösung" z.B. rechts einsteigen links aussteigen. Ist bei vielen Metrosystemen weltweit recht verbreitet und sollte daher funktionieren.

Ich hab das mal von Japan gehört. Da war auch die Rede von versetzten Türen, so dass die ein- und aussteigenden Massen sich gegenseitig garnicht behindern.

Ich denke auch, dass es rein sollte. Eigentlich müsste es ja "pi" und "po" statt "pio-in" und "pio-out" heißen, aber ich glaube dann flippt die Mehrheit aus :-)

Trockennasenaffe wrote:

Wären dass dann Nodes, Ways oder Flächen?

Ja :-)

Ich würde in dem Fall Linien nehmen.

Die würden dann immer zusätzlich zu vorhandenem physischer Objekten angelegt?

Auf jeden Fall ist das ptv3_object=pio an sich nichts physisches. Normalerweise bekommt ein mit anderen Tags beschriebenes physisches Objekt zusätzlich ein ptv3_object=pio. Wo es sinnvoll ist, legt man statt dessen neue Datensätze mit ptv3_object=pio an. Es kann auch mal vorkommen, dass da physisch absolut nichts ist und es trotzdem eine Bushaltestelle ist; dann hat man eben nur einen Datensatz mit ptv3_object=pio.

Wenn ein PIO "4a" heißt, wie erfolgt dann die Zuordnung zu Mainz Hbf?

Das wäre "ptv3_name=Mainz Hbf" und "ptv3_number=4a".

("ptv3_name" darf anders als "name" Abkürzungen enthalten und gibt die Beschriftung der Schilder wörtlich und ohne Steignummern wieder. Dann hat auch der Kollege aus Japan eine Chance, rechtzeitig auszusteigen.)

Weide wrote:

Trockennasenaffe wrote:

Lösen PIOs das Problem, dass es ggf unterschiedliche Bahnsteige zum Ein- und Ausstieg gibt und daher der PIO in beide Richtungen unterschiedlich sein müsste?

Nein. Aber man könnte die Rollen "pio-in" und "pio-out" dazunehmen. Über das "+" kann man ja beliebig viele Einzelangaben zu einem Halt machen.

Da Pio nicht gerade eine intuitiv verständlich ist, könnten wir statt "pio", "pio-in" und "pio-out" auch einfach die Rollen "inout", "in" und "out" verwenden.

Die spanische Lösung (beidseitige Bahnsteige) gibt es übrigens auch im Münchner S-Bahn-Tunnel.

Sofern auf einem Gleis mehr als eine Linie verkehrt, wird man aber keine reine "in" und "out" Aufteilung haben, sondern mindestens eine Seite wird eine eingeschränkte inout Funktion für Umsteiger haben. Welche das ist, wird durch die Anordnungen zum Aussteigen bestimmt.
Vielleicht könnten da Rollen wie "in+change" und "out+change" helfen.

Wir sollten den Spezialfall flughafenartiger Gates von dem Pio Konzept separieren, zumal es auch wenn solche Gates vorhanden sind, oft zusätzlich eine nachgeschalteten fahrzeugnahen Wartepunkt gibt und ggf. auch der Ausstieg ggf. nicht über das Gate erfolgt.

Wir können das Gate entweder statisch per spezieller Relation den fahrwegnahen Pios zuordnen oder es zusätzlich in die Linienrelation aufnehmen. In letzterem Fall sollte es durch z.B. eine "gate"-Rolle und/oder entsprechende Tags am Gate-Objekt von sonstigen Pios unterschieden werden.

Wenn wir die Gates separiert haben, können wir das Konzept für die Pios auf die fahrwegnahe Verwendung optimieren.

Ich schlage daher vor, als Pio die virtuelle Fläche zwischen Fahrweg und Bahnsteigkante zu definieren. Damit bringen wir den Pio in Kontakt mit dem Fahrweg, was zusätzliche Möglichkeiten für eine möglichst einfache definition des Fahrwegs bietet.

Wir müssen diese Fläche nicht unbedingt als geschlossenen Weg zeichnen. Eine U-förmige Linie, die die mit dem Fahrweg deckungsgleichen Kanten weglässt, wäre auch zur Definition dieser Fläche geeignet. GGf. kann man auch noch den Startpunkt weglassen und erhält eine L-förmige Linie, die nur im Endpunkt Kontakt zum Fahrweg hat. Bei einer Bushaltestelle (Länge vernachlässigbar) kann der Pio zu einer Zweipunktlinie zwischen Platform und Stop-Position entarten. Platform und Stop-Position-Tags an den Nodes können dann ggf. entfallen.

Für den Fall, dass der Pio keinen Kontakt (gemeinsamer Node) zu einer Platform hat, können wir folgendes definieren:
Diejenigen Nodes/Kanten, die den Fahrweg nicht berühren, werden als Platformkante interpretiert.

slhh wrote:

Da Pio nicht gerade eine intuitiv verständlich ist, könnten wir statt "pio", "pio-in" und "pio-out" auch einfach die Rollen "inout", "in" und "out" verwenden.

Könnte ich mir vorstellen. Hmm, aber dann ist intuitiv nicht so klar, dass hier Ein- und Aussteigestellen keine Rolle spielen und ausschließlich PIOs als Member in Frage kommen.

slhh wrote:

Sofern auf einem Gleis mehr als eine Linie verkehrt, wird man aber keine reine "in" und "out" Aufteilung haben, sondern mindestens eine Seite wird eine eingeschränkte inout Funktion für Umsteiger haben. Welche das ist, wird durch die Anordnungen zum Aussteigen bestimmt.
Vielleicht könnten da Rollen wie "in+change" und "out+change" helfen.

Das verstehe ich nicht. Die Rolle bezieht sich auf Halte einer Tour (Route). Andere Linien haben damit doch nichts zu tun.

slhh wrote:

... Pios auf die fahrwegnahe Verwendung optimieren ... als Pio die virtuelle Fläche zwischen Fahrweg und Bahnsteigkante zu definieren... dass der Pio keinen Kontakt (gemeinsamer Node) zu einer Platform hat...

Das ist ein ganz anderes Konzept. Ich will die physischen Objekte völlig von den PIOs trennen -- auch wenn sie fast immer mit ihnen zusammenfallen. In den Regeln für das Mappen physisch vorhandener Objekte wie Bahnsteigen soll kein einziges Wort über PTv3 fallen und es soll keine Kompatibilitätseinschränkungen geben. PTv3 setzt darauf nur auf. Die Fährleute sollen die Häfen mappen wie immer sie wollen und die Bahnleute sollen die Bahnanlagen mappen wie immer sie wollen. Wenn da etwas als PIO brauchbares schon gemappt ist, dann kommt ein Tag ptv3_object=pio hinzu und wenn da nichts brauchbares ist, dann wird ein getrenntes Objekt mit ptv3_object=pio angelegt.

Also ich hatte hier lange nicht mehr mitgelesen und eben auch nur mal überfliegen können. So ganz warm werde ich mit dem PIO-Kram allerdings noch nicht. Ich habe immernoch den Eindruck, dass hier zu viel Komplexität reingebracht wird, die gar nicht nötig ist, von eventuellen zusätzlichen dicht gedrängten Objekten, mit denen man sich im Editor herumschlagen muss, mal abgesehen.

Mir wird immernoch nicht klar, welchen Vorteil ein PIO gegenüber der Kombinaltion aus Stop-Position und Plattform haben soll. Mit letzterem ist doch fast alles gesagt. Es fehlt ggf. nur eine Richtung (rein oder raus oder einfach nur Linien-Fahrtrichtung). Dazu braucht man aber keine zusätzlichen PIOs, das ist alles schon vorhanden.

Ich verstehe auch die vermeintlichen Schwierigkeiten nicht, die Leute an die richtigen Stellen zu schicken. Hatte ich ja vorher schon mal geschrieben. Wenn die Physik sauber eingetragen ist, hat man alles, was man braucht.

Und eins noch: Wir sprechen hier von PTv2 und PTv3. Eigentlich löst eine v3 ja eine v2 ab. Das heißt nicht, dass es nicht auch beide gleichzeitig geben kann, aber es heißt, dass man auch allein mit der v3 alles erledigen kann. Nun habe ich aber irgendwie das Gefühl, dass PTv3 hier manchmal als Aufsatz zu/auf PTv2 gehandelt wird. Wenn das aber so wäre, dann darf man es nicht PTv3 nennen, sondern muss einen komplett anderen Namen verwenden. Sonst versteht man das überhaupt nicht mehr.

Achso, und das mit dem Routing ... ich habe jetzt nicht versucht herauszufinden, wo das herkommt, aber irgendwie halte ich das für unsinnig. Ein Router hat bei Verkehrlinien nichts verloren, weil die Linienführung ausschließlich von den ÖPNV-Unternehmen festgelegt wird und nicht von irgendwelchen Routern. Eine berechnete Route führt also bestenfalls zu Verwirrung, wenn sie nicht zufällig die Realität abbildet. Auch hier sehe ich nicht, wo das Problem mit PTv2 ist: Man fügt alle Wege und Haltestellen in der richtigen Reihenfolge zusammen, und gut ist. Und wenn es 30 Varianten gibt, dann gibt es eben 30 Relationen. Wo ist das Problem? Und wenn sich was ändert, dann ändert man es eben. Oder halt nicht, dann stimmt es eben nicht mehr. Aber dieses Problem lösen auch PIOs oder Router nicht. Spezielle Rufbusse und dergleichen fahren natürlich u.U. nach Navi oderso. Das sind aber Spezialfälle, die eher in Richtung Taxi gehen, und für diese muss man dann auch keine speziellen Visualisierung oder Kalkulationen haben, oder?

Wie gesagt, ich habe den Eindruck, dass hier einige Dinge in eine Richtung laufen, die netto keinen Mehrwert bieten. Dieser Eindruck mag falsch sein, aber es gab ja auch von anderen Seiten schon den Einwand, dass Nutzen und Nutzbarkeit auf einem einfache Level gewahrt werden sollten.

Weide wrote:

slhh wrote:

Sofern auf einem Gleis mehr als eine Linie verkehrt, wird man aber keine reine "in" und "out" Aufteilung haben, sondern mindestens eine Seite wird eine eingeschränkte inout Funktion für Umsteiger haben. Welche das ist, wird durch die Anordnungen zum Aussteigen bestimmt.
Vielleicht könnten da Rollen wie "in+change" und "out+change" helfen.

Das verstehe ich nicht. Die Rolle bezieht sich auf Halte einer Tour (Route). Andere Linien haben damit doch nichts zu tun.

Nehmen wir als Beispiel eine Station mit zwei Gleisen und drei Bahnsteigen, so dass es an jedem Gleis beidseitige Bahnsteige gibt. Zu den beiden Außenbahnsteigen führen nur Zugangstreppen und am gemeinsamen Mittelbahnsteig gibt es nur Abgangstrepppen.
Es verkehren zwei Linien von A nach B und C nach D auf dem gleichen Gleis und die Gegenrichtungen auf dem zweiten Gleis.

Zunächst scheinen an den Außenbahnsteigen "in"-Pios und am Mittelbahnsteig "out"-Pios sinnvoll. Dies wird aber problematisch bei Umsteigern:

Fall 1: Jemand will umsteigen, um von A nach C zu fahren. Normal wäre, dass er zum gemeinsamen Mittelbahnsteig hin aussteigt und von dort am gegenüberliegenden Gleis wieder einsteigt. Das bedeutet aber, dass wir am Mittelbahnsteig keinen reinen "out"-Pio plazieren dürfen, sonst führt der Fussgängerrouter die Umsteiger über zwei Treppen zum Außenbahnsteig. Andererseits wäre ein "inout"-Pio auch unerwünscht, da dann ggf. reine Einsteiger zu diesem geführt werden.

Fall 2: Jemand will umsteigen, um von A nach C zu fahren. Dies kann wie Fall 1 gehandhabt werden, nur das am gleichen Gleis wieder eingestiegen wird. Physikalisch möglich ist jedoch auch zum AUssenbahnsteig hin auszusteigen (was der Router bei einem reinen "in"-Pio nicht akzeptieren würde) und von dort in den Zug der anderen Linie wieder einzusteigen. Welche Variante zu wählen ist, hängt von den Aussteigeanweisungen ab.

Fall 3. Wenn man die Zugangs- und Abgangsfunktion zwischen Außen- und Mittelbahnsteig tauscht, wird es wahrscheinlicher, dass es gesonderte Aussteigeanweisungen für Umsteiger gibt und somit für Umsteiger eingeschränkte "in+change"-Pios benötigt werden. Ansonsten wäre ein bahnsteiggleicher Umstieg für die Fahrt von A nach C und B nach D unmöglich.

slhh wrote:

Nehmen wir als Beispiel eine Station mit zwei Gleisen und drei Bahnsteigen, so dass es an jedem Gleis beidseitige Bahnsteige gibt. Zu den beiden Außenbahnsteigen führen nur Zugangstreppen und am gemeinsamen Mittelbahnsteig gibt es nur Abgangstrepppen.

Ja des gibt es... sollte auch berücksichtigt werden. Die Fahrgast wird auch darauf hingewiesen.. "Bitte an der nächsten Haltestelle rechts aussteigen." z.B.

Es heißt "Bitte" also.. es muss dann der Router gewichten, wenn der Umweg nicht sehr groß ist diesen zu wählen im Beispiel den rechten Ausstieg zu wählen..

krza wrote:

Wenn die Physik sauber eingetragen ist, hat man alles, was man braucht.

Sehe ich auch so man soll es so einfach halten wie möglich... Es muss ja auch jemand andere verstehen können was da so gemappt ist und es muss wartbar bleiben..

Das größten Probleme beim ÖPNV-Routing ist hier nicht das Routing... da irgendwas zu berechnen.. Was bringt mir die ganze Berechnung wenn..

- das Handy in größeren Bahnhöfen... die mehrstöckig usw. sind einfach keinen GPS-Empfang habe.. (Hier könnte man mit Aushangplänen bzw. QR-Code arbeiten um dem Handy die aktuelle Position und Stockwerk zu geben an der man sich gerade befindet...
- die Bahnhöfe oft schlecht bzw. unzureichend ausgeschildert..
- der Mensch einfach nicht z.B. vorne einsteigt sondern hinten und dadurch durch anders geführt wird. Oder mit den Namen der Ausgängen nichts anfangen kann..

Da lache ich immer wenn da dasteht "2min gehen". Ja 2min, wenn man den Weg weiss 🤣

Das Hauptproblem ist der fehlende GPS-Empfang gerade dann wenn man es braucht 🤔

Zum QR-Code Idee vielleicht sowas... Position lat , lon... Kartenansicht vielleicht.. layers=INDOOR.. und Stockwerk brächte man auch level=-2

des dann x-mal im Bahnhof angebracht dann könnt das Navi einem auch da leiten.. 🤔

krza wrote:

Mir wird immernoch nicht klar, welchen Vorteil ein PIO gegenüber der Kombinaltion aus Stop-Position und Plattform haben soll. Mit letzterem ist doch fast alles gesagt. Es fehlt ggf. nur eine Richtung (rein oder raus oder einfach nur Linien-Fahrtrichtung). Dazu braucht man aber keine zusätzlichen PIOs, das ist alles schon vorhanden.

Stop-Position und Platform sind nicht miteinander, was dazu führt, dass beide in die Linienrelation müssen. Dies macht die Linienrelationen unnötig kompliziert und fehleranfällig. Es fehlt auch die Information über die Länge des Bereichs, in dem der Fahrgastwechsel erfolgt.
daher hat das Pio-Konzept schon eine gewisse Daseinsberechtigung. Allerdings sehe ich hier noch einigen Überarbeitungsbedarf.

krza wrote:

dass man auch allein mit der v3 alles erledigen kann.

Das ist wohl von allen Beteiligten so gedacht, außer vielleicht Dingen, die der jeweilige Beteiligte als für OSM nicht relevant ansieht.
Letzteres halte ich für sehr problematisch. Ein v3, dass die Löschung von in OSM vorhandenen Daten erfordert, dürfte sich kaum vollständig durchsetzen. Ein dauerhafter Paralellbetrieb verschiedener Taggingschemata verkompliziert alles noch mehr.

krza wrote:

Auch hier sehe ich nicht, wo das Problem mit PTv2 ist: Man fügt alle Wege und Haltestellen in der richtigen Reihenfolge zusammen, und gut ist. Und wenn es 30 Varianten gibt, dann gibt es eben 30 Relationen.

Wenn man alle Informationen über eine Linie mit Varianten hat, mag das Anlegen aller dieser Relationen mit JOSM noch recht effizient sein, da man viel kopieren kann. Unverhältnismäßig schwierig wird dagegen die spätere Wartung. Wenn das Wissen über die Linie auf mehrere Personen verteilt ist, erfolgt auch das Anlegen im Wesentlichen in Wartungsform und damit sehr ineffizient. Bei der Wartung muss man zunächst die angelegten Relationen verstehen und Copy&Paste ist nur noch eingeschränkt anwendbar.

PTv2 ist einbe absolute Zumutung gegenüber denjenigen, die Straßen und Gleise bearbeiten wollen, wo viele Linien oder Linienvarianten vorhanden sind. Diese Benutzer sind zumeist keine PT-Experten und vielleicht sogar iD-Nutzer. Wenn man von der PT-Seite nicht mehr Rücksicht auf diese Nutzer nimmt, hat man es nicht anders verdient als das Editor und Nutzer Kollateralschäden an den PT-Daten ignorieren.

krza wrote:

Mir wird immernoch nicht klar, welchen Vorteil ein PIO gegenüber der Kombinaltion aus Stop-Position und Plattform haben soll. Mit letzterem ist doch fast alles gesagt. Es fehlt ggf. nur eine Richtung (rein oder raus oder einfach nur Linien-Fahrtrichtung). Dazu braucht man aber keine zusätzlichen PIOs, das ist alles schon vorhanden.

Die sind auch nicht als zusätzlich zu stops und platforms gedacht. Der Normalfall wird eher sein, dass zwei stop_positions und zwei platforms und eine stop_area durch einen Node ersetzt werden.

krza wrote:

Und eins noch: Wir sprechen hier von PTv2 und PTv3. Eigentlich löst eine v3 ja eine v2 ab. Das heißt nicht, dass es nicht auch beide gleichzeitig geben kann, aber es heißt, dass man auch allein mit der v3 alles erledigen kann. Nun habe ich aber irgendwie das Gefühl, dass PTv3 hier manchmal als Aufsatz zu/auf PTv2 gehandelt wird.

PTv3 (besser gesagt: mein Vorschlag zu einem PTv3) setzt nicht auf PTv2 auf und auch nicht auf PTv1, soweit man bei letzterem die Routen meint. PTv2 und (je nachdem was man damit meint) PTv1 sollen komplett abgelöst werden. Das Mappen physisch vorhandener Objekte geschieht aber wie bisher (z.B. railway=platform) und ist in PTv3 nicht festgelegt oder auch nur eingeschränkt. (PTv2 hat da Einschränkungen produziert)

krza wrote:

Ein Router hat bei Verkehrlinien nichts verloren, weil die Linienführung ausschließlich von den ÖPNV-Unternehmen festgelegt wird und nicht von irgendwelchen Routern.

Da sind wir uns hundertprozentig einig. Wo hier vom Routing die Rede ist, geht es nur um Fußgängerrouting etc. vor und nach der Nutzung eines Verkehrsmittels ... b.B. beim Umsteigen. In PTv3 wird genauso wie bei PTv2 der Fahrweg durch Wege angegeben mit einer Variante pro Relation.

Nur in einem Sonderfall werden Varianten gestrichen: wenn lokal in einem Bahnhof ohne Auswirkungen auf den Rest der Strecke mal der und mal der Steig benutzt wird, dann kommt das in eine Relation. In PTv2 wurden durch sowas Varianten vervielfacht.

krza wrote:

Dieser Eindruck mag falsch sein, aber es gab ja auch von anderen Seiten schon den Einwand, dass Nutzen und Nutzbarkeit auf einem einfache Level gewahrt werden sollten.

"gewahrt bleiben" hört sich danach an, als ob wir im Moment was brauchbares hätten. Das Einzige was im Moment funktioniert, ist aber das Erfassen der Informationen. Beim Editieren von Fahrspuren und dem Einbau von Grüninseln bei Kreisverkehren werden die PTv2-Routen sehr oft zerstört und die Datenstrukturen erlauben anders als in PTv3 keinen Support durch Editormeldungen. Der Nutzen ist sogar 0, denn niemand benutzt unsere Routen. Einige ÖPV-Betreiber nutzen OSM-Daten -- aber auf keinen Fall die ÖPV-Strukturen in den OSM-Daten. Innerhalb von OSM ist es genauso. Einige Freunde sagen mir ganz klar "Ich mappe alles was ich auf der Radtour sehe -- aber kein ÖPV. Da muss man ja für jede einfache Bushaltestelle ein ganzes Konzept lernen."

slhh wrote:

Zunächst scheinen an den Außenbahnsteigen "in"-Pios und am Mittelbahnsteig "out"-Pios sinnvoll.

Das ist glaube ich ein Missverständnis; es ging um die Rollen in der Route und nicht um das Tagging.

Hm. Um nochmal ganz deutlich zu sein bzw. zu fragen: Momentan werden potenziell folgende physikalische Gegebenheiten gemappt, die auch Teil der PTv2-Strategie sind:

• public_transport = stop_position
• public_transport = platform

Ob man die Plattform jetzt noch nach Verkehrsmittel trennen möchte, sei mal dahingestellt (es gibt ja z.B. auch noch railway=platform und highway=platform). Ich persönlich halte es nicht für nötig, da die Elemente ja normalerweise einer Relation angehören und daraus abgeleitet werden kann, ob um was es sich handelt (und es können dadurch sogar Mischnutzungen sein).

Beide Informationen halte ich für sinnvoll, nützlich und notwendig. Für sich alleine sind sie aber natürlich nur begrenzt nutzbar.

Daher kommt zur Physik noch die Organisation hinzu, sprich, die Verknüpfung zu Strukturen. Das kann man z.B. über gleiche Namen zum Gruppieren erreichen und über eine eindeutige Nummerierung für die reihenfolge. Letzteres wurde ganz am Anfang sogar mal gemacht, glaube ich. Stattdessen kann man den Zusammenhang aber über Relationen darstellen, und genau das wird ja mittels PTv2 getan. Hier können weitläufige Haltestellen zusammengefasst, deren Reihenfolge definiert und sogar die Fahrwege erfasst werden. Für sich genommen also eigentlich sehr einfach und transparent.

Ein Problem stellt sicher dar, dass Änderungen an den verwendeten wys für die Fahrwege schnell zu korrupten Fahrwegen führen können (Stichwort "Zumutung" in Post #128). Okay. Das ist doof. Aber letztlich ist die Reihenfolge und Konsistenz der Haltestellen und deren Zugangspunkten wichtiger. Die Fahrwege sind eigentlich nur für die Visualisierung wichtig, auch wenn diese in bestimmten Fällen auch sehr nützlich ist. Auf der anderen Seite ist jeder Netzplan, den ich bisher gesehen habe, von den exakten Fahrwegen entkoppelt und stellt lediglich synmbolische Wege dar. Man könnte dies also als Argument nehmen, auf die Fahrwege komplett zu verzichten, um der Gefahr der Zerstörung durch unerfahrene oder unsensible Mapper zu entgehen. Ich persönlich würde sie trotzdem mappen.

So. Nun lese ich aus der Introduction auf gafte.de heraus, dass ein PIO die Kombination aus Plattform und Stop ersetzen soll. Ich interpretiere das so, dass es sich nur auf die Rollen in der Relation bezieht (darauf zielte wohl auch Posting #130 ab). Das kann ich zunächst mal noch nachvollziehen. Aber damit fallen die physikalischen Objekte komplett oder teilweise aus der Relation heraus. Ersteres würde erfordern, einen zusätzlichen Node oder Way zu erzeugen, der über getaggten physikalischen Objekte hinausgehen. Letzteres führt dazu, dass man sich entscheiden muss, ob man die PIOs an die stop_position oder die Plattform hängt. Gewählt wird natürlich die Plattform, aber damit fällt die Stop-Position aus der Relation raus und schwebt damit völlig frei im Raum. Und wenn die Plattform nicht dem Wartepunkt entspricht, muss noch ein solcher definiert werden, aber das geht auch ohne PIO. Dazu braucht man lediglich ein paar neue Werte, und zwar genau die, die hier oft für die PIOs angezogen werden.

In diesem Zusammenhang möchte ich mal den folgenden Satz aus der Introduction in Frage stellen:

introduction.pdf wrote:

PTv2 couln’t handle splitted platforms as only one platform per halt of the vehicle could be included in the relation. (Including another one would denote a second halt of the vehicle.)

Klar, es hängt immer davon ab, wie man etwas interpretiert, aber ich halte die Aussage für falsch. Warum sollte es nicht mehrere Plattformen geben können? Die Plattformen haben mit den Haltepositionen nichts zu tun, so dass ein zweiter Halt nicht impliziert wird. Wenn es zwei Plattformen für den gleichen Haltepunkt gibt, dann sind diese auch alternativ nutzbar. Das ist dann eben so, und der geneigte Datennutzer muss sich dann halt für eine entscheiden – wie "im wahren Leben" auch, wenn er oder sie vor Ort ist.

Anders ist es, wenn es verschiedene Plattformen für verschiedene Richtungen oder Linien gibt. Aber das ist ja auch kein Problem, da jede Linie und Richtung ja ohnehin eine eigene Relation hat. In dem Zusammenhang stand oben dies hier:

slhh wrote:

Stop-Position und Platform sind nicht miteinander, was dazu führt, dass beide in die Linienrelation müssen. Dies macht die Linienrelationen unnötig kompliziert und fehleranfällig.

Sehe ich nicht so. Was ist daran kompliziert und fehleranfällig? Im Gegenteil: Es ist ziemlich straight forward, wie man neudeutsch sagt. Es gibt eigentlich nur zwei Regeln, die eingehalten werden müssen: Haltestellenreihenfolge und innerhalb der Haltestelle die Rollenreihenfolge, obwohl letztere eigentlich völlig egal sein sollte (ich wüsste jedenfalls keinen Nutzwert davon).

slhh wrote:

Es fehlt auch die Information über die Länge des Bereichs, in dem der Fahrgastwechsel erfolgt. daher hat das Pio-Konzept schon eine gewisse Daseinsberechtigung. Allerdings sehe ich hier noch einigen Überarbeitungsbedarf.

Die Länge eines Bereichs hat in der Organisationsstruktur auch nichts verloren und wird dort auch nicht gebraucht. Das ist Physik und wird von den Elementen selbst vorgehalten, indem eine Plattform zum Beispiel als Way ausgeführt wird. Das ist ja auch üblich. Theoretisch könnte man das sogar mit Stop-Positionen machen, ich persönlich würde aber eher die übliche Fahrzeugmitte als Punkt setzen. Und jetzt komme bitte keiner mit Kurzzügen, die ab Null Uhr fahren oderso ... man muss die Kirche auch im Dorf lassen, denn wir können hier ohnehin keine zentimetergenaue Navigation ermöglichen. Bei langen Bahn- und Bussteigen gibt es dann eben mehrere Stop-Positionen. Das ist ja auch kein Problem, und es ist vor allem die (relativ einfache) Aufgabe des Renderers, diese in geeigneter Weise für jede Zoomstufe zusammenzufassen oder eben nicht. In welcher Weise publick_transport=stop_area zu verwenden wäre, erschließt sich mit in diesem Zusammenhang übrigens nicht aus der Wiki.

So, zuletzt noch einmal zu den Use Cases, die hier ja auch schon eingefordert wurden:

Wofür machen wir das alles? Der Hauptgrund für die PIOs scheint mir die Fußgängernavigation zu sein. Ich will eine Person also zu einem bestimmten Punkt lotsen, an dem sie ein Verkehrsmittel besteigen bzw. zumindest darauf warten kann (von da bis zum Fahrzeug aus übernimmt normalerweise der Betreiber mit Hinweisschildern, wenn nötig). Oder wir wollen eine Person von einer Haltestelle zu einem Ziel außerhalb der Haltestelle lotsen. In beiden Fällen muss der Navi-Nutzer angeben, in welche Richtung gefahren werden soll oder wurde, damit ggf. die richtige Einstiegs-Plattform angesteuert bzw. die richtige Ausstiegsplattform als Startpunkt gesetzt werden kann. Wenn ich mir nun PTv2 anschaue, erkenne ich nicht, was da fehlt. Es ist alles möglich. Hier geht es auch nicht so sehr um Geschmack, sondern um konsistente Daten.

Zweiter Use Case ist die Erstellung und Wartung der Daten. Hier spielt der Geschmack bzw. der "Nutzertyp" eine gewisse Rolle, ja. Dummerweise haben wir nun aber verschiedene Tools, und nicht jeder nutzt JOSM. Das ist ein Problem. Lösen könnte man es nur, in dem man "zu einfachen" Editoren bestimmte Änderungen nicht erlaubt. Konsequent umgesetzt würde das aber oft heißen, dass man gerade in Städten gar nichts mehr ändern kann, weil alles irgendwie von Relationen durchsetzt ist. Dafür habe ich auch keine spontane Lösung.

Eine Möglichkeit wäre natürlich, Relationen von den physikalischen Objekten zu trennen, aber das ist leider ein Widerspruch in sich und fällt damit raus. Ein Kompromiss wäre, Relationseigenschaften zu entwerfen, die einen Basissatz von Eigenschaften optional ergänzt. Das ist ja ein nicht unüblicher Ansatz. Wenn das mit den PIOs in diese Richtung ginge, wäre das in Ordnung, hätte dann aber nichts mit PTv3 zu tun, sondern wäre eine Ergänzung, die ab PTv3 hinzu kommt. Damit würde PTv3 PTv2 ersetzen, da es dieses vollständig umfasst. Oder man muss für Ergänzungen mit einem Sub-Index arbeiten: PTv2.1, PTv2.2 und so weiter. Das würde bedeuten, dass alle abwärtskompatibel sind. Dies wäre bei einem neuen Hauptindex nicht mehr unbedingt der Fall, also PTv3 wäre nicht mehr mit PTv2 kompatibel.

Sorry für die Textmenge und Glückwunsch an diejenigen, die bis hierher gekommen sind 😉

PS: Wir können mit dem OSM-Ansatz nur eine bestimmte Komplexität erreichen. Alles, was über diese hinausgeht, ist mit einem offenen System nicht mehr leistbar. Das sollte man auch immer im Hinterkopf behalten.

krza wrote:

Die Plattformen haben mit den Haltepositionen nichts zu tun, so dass ein zweiter Halt nicht impliziert wird. Wenn es zwei Plattformen für den gleichen Haltepunkt gibt, dann sind diese auch alternativ nutzbar.

In PTv2 ist es so, dass ein stop oder eine platform oder ein stop gefolgt von einer gleichnamigen platform einen Halt des Fahrzeugs beschreibt. Beide sind in PTv2 völlig gleichberechtigt. Das ist das, was im beschlossenen Proposal steht.

In der deutschen Version des Public_Transport Wiki ist dagegen ein völlig anderes Konzept beschrieben in dem mehrere Platforms bei einem Halt möglich wären, da der stop dort zur Pflicht erklärt wird. Ich finde es ausgesprochen destruktiv, wenn ein Konzept fundamental geändert und dann als dasselbe ausgegeben wird.

krza wrote:

Man könnte dies also als Argument nehmen, auf die Fahrwege komplett zu verzichten, um der Gefahr der Zerstörung durch unerfahrene oder unsensible Mapper zu entgehen. Ich persönlich würde sie trotzdem mappen.

Es gibt eine dritte Möglichkeit, die in PTv3 realisiert wurde. Man mappt sie und teilt die Gesamtstrecke in Abschnitte auf, die entweder leer oder einfach sind. (Einfach bedeutet hauptsächlich: keine Selbstberührung) Dann müssen diese Abschnitte in sich nicht mehr sortiert sein und praktisch alle versehentlichen Zerstörungen spielen entweder keine Rolle mehr oder werden zu erkennbaren und meldbaren Fehlern.

krza wrote:

Dummerweise haben wir nun aber verschiedene Tools, und nicht jeder nutzt JOSM. Das ist ein Problem.

Die meisten Beschädigungen an PTv2-Routen werden lustigerweise mit dem JOSM gemacht. Hier hat man die Möglichkeit, nur einen Teil der im Gesichtsfeld liegenden Daten geladen zu haben und so können die Verdrehungen in der Wegreihenfolge entstehen. Wer im JOSM die Einstellung "automatisch nachladen" benutzt oder mit anderen Editoren arbeitet, der produziert diese Fehler nicht.

Ich nutze die Gelegenheit, nochmal auf das Splitten von Wegen im JOSM hinzuweisen. Vor dem Splitten eines Weges den Weg und seine beiden Endpunkte anwählen und ALT+Ctrl+D machen. Beim nachfolgenden Auftrennen des Weges mit "p" passiert dann nichts Böses.

krza wrote:

Eine Möglichkeit wäre natürlich, Relationen von den physikalischen Objekten zu trennen, aber das ist leider ein Widerspruch in sich und fällt damit raus. Ein Kompromiss wäre, Relationseigenschaften zu entwerfen, die einen Basissatz von Eigenschaften optional ergänzt. Das ist ja ein nicht unüblicher Ansatz. Wenn das mit den PIOs in diese Richtung ginge, wäre das in Ordnung, hätte dann aber nichts mit PTv3 zu tun, sondern wäre eine Ergänzung, die ab PTv3 hinzu kommt.

Hmmm. Ich hab langsam das Gefühl, dass wir unter physikalisch oder physisch ganz verschiedene Dinge verstehen. public_transport=stop_position und public_transport=platform und highway=bus_stop beschreiben für mich keine physischen Objecte. railway=platform ist dagegen ein physisches Objekt, ein Bauwerk eben.

Weide wrote:

Public_transport=stop_position und public_transport=platform und highway=bus_stop beschreiben für mich keine physischen Objecte. railway=platform ist dagegen ein physisches Objekt, ein Bauwerk eben.

Ich bin auch der Meinung dass man public_transport=plaform nur als Rolle sehen sollte und hab schon ein Proposal im Draft dafür:
https://wiki.openstreetmap.org/wiki/Pro … astructure

Weide wrote:

slhh wrote:

Zunächst scheinen an den Außenbahnsteigen "in"-Pios und am Mittelbahnsteig "out"-Pios sinnvoll.

Das ist glaube ich ein Missverständnis; es ging um die Rollen in der Route und nicht um das Tagging.

Ich meinte schon die Rolle in der Route. Wobei man natürlich auch überlegen könnte, die in/out-Eigenschaften ins Tagging des Pio zu verlagern. Der Nachteil bei Tags wäre, dass man zwei Pios an gleicher Position benötigt, wenn dort eine Linie nur zum Ausstieg und die andere zum Ein- und Ausstieg hält. Der Nachteil bei Rollen wäre, dass die Rollenvielfalt nochmal durch die "+", "alt-" und "+alt-" Präfixe vervierfacht wird.

Das wäre eine "einfache" Sache des Eintragens (und m.E. ausreichend für einen ÖPNV-unbedarften Mapper):

An der Stelle des Schildes auf der Straße habe ich
bus=yes
highway=bus_stop
public_transport=stop_position
nicht in der Vorlage
- description:de=Linie A
- name=In der Tilke
- ref=A
- website=http://www.vvo-online.de/de/fahrplan/aktuelle-abfahrten-ankuenfte/abfahrten?stopid=33001181 (aus QR-Code)

eingetragen.

als node lässt sich die Haltestelle (JOSM-Vorlage) nicht eintragen - deshalb habe ich einen way vor der Wartehalle mit
bus=yes
highway=platform
public_transport=platform

was aber m.E. nicht richtig ist: keine Kante oder Markierung - ein node wäre "richtiger".
Dann könnte der node auch Bestandteil eines Fußweges und Routingziel sein.

(Mit Kante könnte auch higway=footway statt *=platform stehen, da schon public_transport=platform.)
(Relation habe ich noch nicht geändert - weil sehr falsch)
(waste_basket, shelter und bench sind separat eingetragen)

Weide wrote:

In der deutschen Version ...

Ich habe mich offensichtlich vor allem von der deutschen Version leiten lassen. Diese erscheint mir im Vergleich mit dem, was Du über die offenbar originale Version sagst, auch plausibler.

Weide wrote:

Ich finde es ausgesprochen destruktiv, wenn ein Konzept fundamental geändert und dann als dasselbe ausgegeben wird.

Da stimme ich allerdings komplett zu. Ich hatte von Unstimmigkeiten gelesen, aber grundsätzlich sollte es nur 1 "Wahrheit" geben. Will das hier nicht weiter vertiefen, darüber wurden schon Abhandlungen verfasst, glaube ich 😉

Weide wrote:

Es gibt eine dritte Möglichkeit, die in PTv3 realisiert wurde ... Abschnitte ... Selbstberührung ...

Ehm, was genau habe ich nicht oder zu flüchtig gelesen? Ich kann mich düster erinnern, etwas über Marker undso in dem Paper auf gafte gelesen zu haben, aber schon damals hatte ich es nicht wirklich verstanden, zumal aussagekräftige Beispiele fehlen. oder gibt es inzwischen welche? Damals wie heute sehe ich den großen Unterschied zwischen PTv2 und PTv3 noch nicht, wenn man von anderen Namen und ein paar zusätzlichen Tags mal absieht.

Weide wrote:

Vor dem Splitten eines Weges den Weg und seine beiden Endpunkte anwählen und ALT+Ctrl+D machen. Beim nachfolgenden Auftrennen des Weges mit "p" passiert dann nichts Böses.

So solltest Du das nicht formulieren, also ohne zu sagen, was eigentlich passiert und warum das Böses verhindern sollte. Übrigens kannst man sich das Auswählen des Weges (leider) sparen, da diese Operation nur auf Knoten wirkt. Wählst man also die Endpunkte aus, werden auch nur die dort angeschlossenen Wege nachgeladen, nicht aber diejenigen, die zwischen diesen Punkten mit dem Weg verbunden sind.
Und damit wären wir bei der Funktion (für diejenigen, die sie nicht kennen). Im Unterschied zu "download along" (Alt+Shift+D) wird halt nicht die ganze Umgebung geladen, sondern nur die direkt verbundenen Objekte. Ob es ein Bug ist, dass es nur mit Knoten funktioniert, aber nicht mit ganzen Wegen, weiß ich nicht. Umgehen kann man es, indem man sich entweder die OSM-Karte drunter legt und gezielt die Knoten auswählt, die relevant sind, bevor man Ctrl+Alt+D drückt, oder man wählt den Weg aus, drückt danach Ctrl+Shift+N und dann erst Ctrl+Alt+D. Die erste Kombination findet man auch oben im Selection-Menü, und man kann sie sich auch in die Symbolleiste ziehen. Sie wählt den markierten Weg ab und stattdessen alle seine Knoten aus.
Das allein hilft allerdings noch nicht so viel. Wenn man die angrenzenden Wege heruntergeladen hat, kann man lediglich mehr sehen und weiß besser, was man macht. Man ist also nicht automatisch vor dem o.g. "Bösen" gefeit 😉

PS: Weide, das Ctrl+Alt+D taucht in keinem Menü auf, oder habe ich es immer übersehen?

Weide wrote:

Hmmm. Ich hab langsam das Gefühl, dass wir unter physikalisch oder physisch ganz verschiedene Dinge verstehen. public_transport=stop_position und public_transport=platform und highway=bus_stop beschreiben für mich keine physischen Objecte. railway=platform ist dagegen ein physisches Objekt, ein Bauwerk eben.

Hm. Ich stimme Dir teilweise zu. Dazu müsste man aber public_transport konsequent als nicht physisch betrachten. Wenn man das allerdings tut, dann braucht man diese beiden Key-Werte gar nicht mehr: public_transport=stop_position und public_transport=platform könnten gelöscht werden, weil die Information ja von den anderen von Dir genannten Tags beigesteuert wird (dann müssten allerdings auch Mehrfachnennungen möglich sein, wenn z.B. Bus und Bahn die Knoten gemeinsam nutzen). Dann hätte man zunächst mal das reine physische Tagging und die Relationen, und in letzteren gibt es ja keine Tags mehr, sondern nur noch Rollen. Allerdings hat man hier zwangsläufig die Verknüpfung zur Physik, weil ein Member einer Relation in diesem Falle ja nur ein physisches Objekt sein kann, wenn man davon ausgeht, dass ein Knoten oder ein Way immer die Physik beschreibt. Hinzu kommen potenziell natürlich noch weitere Relationen als Members.
In diesem Sinne sind übrigens auch die PIOs physische Objekte bzw. verweisen auf solche. Denn ohne einen Knoten kann man keinen PIO erstellen und ein Knoten kann nur ein phyisches Objekt beschreiben, kein virtuelles. Dabei muss man "physisch" vielleicht ein bisschen weiter sehen, aber es reicht in meinen Augen schon, wenn man theoretisch einen weißen Punkt auf eine Stelle malen könnte und diesen Punkt als physisches Objekt betrachtet. Knackpunkt ist die Koordinate. Ein logisches Objekt kann meiner Meinung nach keine Koordinate haben.

So, und jetzt sind wir eigentlich wieder bei PTv2, und ich habe mich im Kreis gedreht. Wenn ich nochmal in das Paper schaue, finde ich dort nicht wirklich etwas, was einen Vorteil für den Informationsgehalt bringt. Die Ein- und Ausstiegepunkte (PIO) kann man einfach in PTv2 integrieren, und dass diese dort hin und wieder fehlen (wenn die Plattform nicht diesen Punkt darstellt), hatte ich ja vorher schon mal erwähnt.

Darüber hinaus scheint mir in dem Paper einiges sehr kompliziert zu sein, und ich frage mich, warum das helfen soll, Dinge einfacher und robuster zu machen. Aber wie gesagt, es fehlen Beispiele, die alles einmal zeigen. Das können ja schon einfach OSM-Files sein. Vielleicht relativiert sich das dann ein bisschen.

Eines allerdings lehne ich persönlich entschieden ab, und ich war ehrlich gesagt sehr erstaunt, sowas zu lesen (muss ich beim ersten Mal damals übersehen haben):

Paper wrote:

PIOs are grouped by using common names and not by creating relations like the old stop_area and stop_area_group.

Ich erinnere mich an Diskussionen, ob Relations zum Gruppieren genutzt werden sollen oder nicht. Ich sage ganz klar: Ja, denn es sind auch Relationen, die damit beschrieben werden. Meine private und vor allem auch berufliche Erfahrung sagt mir aber auch, dass eine Gruppierung auf der Basis von individuellen Namen eine Katastrophe wäre. Das geht gar nicht. Genau mit sowas erzeugt man Fehler ohne Ende, und bei OSM kommt noch hinzu, dass es sich überhaupt nicht richtig warten lässt. Hier gibt es für mich nur eins: Relationen. Die sind robust und einfach zu handhaben.

Grundsätzlich sehe ich in dem PTv3-Ansatz richtige und nützliche/notwendige Aspekte angesprochen, wie ich ja auch früher schon mal sagte, aber es bleiben nach wie vor Lücken in meinem Verständnis bzw. z.T. auch Dinge wie das mit dem Gruppieren, die es mir nicht erlauben, es als Replacement für PTv2 zu betrachten. Völlig offen bleibt im Moment für mich der Umgang mit den Wegen.

PS: Alles, was ich schreibe, ist Meinung, nicht Behauptung. Fast alles jedenfalls 😉

geri-oc wrote:

als node lässt sich die Haltestelle (JOSM-Vorlage) nicht eintragen - deshalb habe ich einen way vor der Wartehalle mit bus=yes, highway=platform, public_transport=platform, was aber m.E. nicht richtig ist: keine Kante oder Markierung - ein node wäre "richtiger". Dann könnte der node auch Bestandteil eines Fußweges und Routingziel sein.

Warum lässt sich das nicht als Node eintragen? Das ist doch ein klassischer Knoten-Fall. Die Diskussion mit der Schild-Position finde ich übrigens völlig überflüssig. Wen interessiert das Schild? Der Betreiber wird schon dafür sorgen, dass es an einer günstigen Stelle steht. Wichtig für Darstellung und Routing sind meiner Meinung nach lediglich

• die Positionen, an der ein Fahrzeug hält (stop_position)
• die Position, an der Fahrgäste warten (platform)
• die Position, an der Fahrgäste das Fahrzeug bzw. den dafür vorgesehenen Zubringerweg betreten (pio)

Dies können zusammenfallen, müssen es aber nicht.

krza wrote:

Ob man die Plattform jetzt noch nach Verkehrsmittel trennen möchte, sei mal dahingestellt (es gibt ja z.B. auch noch railway=platform und highway=platform). Ich persönlich halte es nicht für nötig, da die Elemente ja normalerweise einer Relation angehören und daraus abgeleitet werden kann, ob um was es sich handelt (und es können dadurch sogar Mischnutzungen sein).

Und wenn dann die Linienrelation fehlt, oder ein Bahnsteig ungenutzt (nur bei Betriebstörungen genutzt wird) ist, wird er nicht mehr gerendert oder einheitlich mit Bushaltestellen gerendert?

krza wrote:

Stattdessen kann man den Zusammenhang aber über Relationen darstellen, und genau das wird ja mittels PTv2 getan. Hier können weitläufige Haltestellen zusammengefasst ... werden.

Das sollten wir auch beibehalten. Wenn man die Zusammenfassung für Anwendungen für hinreichend wichtig hält, könnte man definieren, dass die Anwendungen über Namensgleichheit zusammen fassen sollen, wenn nicht ein spezielles Tag gesetzt ist, dass gerade dieses unterdrückt, und auch keine Mitgliedschaft in einer Stop-Area-Relation besteht.

krza wrote:

Ein Problem stellt sicher dar, dass Änderungen an den verwendeten wys für die Fahrwege schnell zu korrupten Fahrwegen führen können (Stichwort "Zumutung" in Post #128). Okay. Das ist doof. Aber letztlich ist die Reihenfolge und Konsistenz der Haltestellen und deren Zugangspunkten wichtiger.

Wenn wir schon viel Aufwand in das Mappen der Fahrwege stecken, sollten die Daten aber auch korrekt sein. Soweit wir die Beschädigung nicht verhindern können, sollten sie wenigstens einfach behebbar sein. Der Ansatz von Weide bietet hir zwar gewisse Vorteile, ist aber bei weitem noch nicht ausreichend.

krza wrote:

slhh wrote:

Stop-Position und Platform sind nicht miteinander, was dazu führt, dass beide in die Linienrelation müssen. Dies macht die Linienrelationen unnötig kompliziert und fehleranfällig.

Sehe ich nicht so. Was ist daran kompliziert und fehleranfällig?

Vertauschung der Rollenreihenfolge generiert einen zusätzlichen Halt gemäß PTv2. Mehrere Halte in einer Haltestellen kommen aber auch in Realität vor und müssen unterstützt werden.
Kompliziter wird es, da mehr Member in der Relation zu deutlich höherem Sortieraufwand führen und auch die Gefahr besteht, Rollen zwischen den ggf. Namensgleichen stop und platform Elementen zu vertauschen.

krza wrote:

Die Länge eines Bereichs hat in der Organisationsstruktur auch nichts verloren und wird dort auch nicht gebraucht. Das ist Physik und wird von den Elementen selbst vorgehalten, indem eine Plattform zum Beispiel als Way ausgeführt wird. Das ist ja auch üblich.

Die Platform kann viel länger oder auch kürzer (z.B. wegen Brücke/Tunnel, covered unterteilt) sein. Es kann der Teilbereich auch eine besondere Bereichnung haben.
Zur Visualisierung des Fußgänger Routingziels ist es schon sinnvoll, den ganzen Zielbereich darstellen zu können. Die Mitte des Zielbereichs als Routing-Ziel zu verwenden führt ggf. auch zu einer ungünstigen Wegwahl und zu einer schlechten Berechnung von Umsteigezeiten.
Beispiel: ein Bahnsteig mit Zugangstreppen an beiden Enden und in der Mitte. Der Fußgänner nährt sich dem Bahnhof entlang der Strecke. Der Router mag die mittlere treppe wählen, um eionen Zielpunkt in Bahnsteigmitte zu erreichen, wenn er jedoch von einem längeren Zielbereich ausgeht, wäre die zuerst erreichte Treppe an einem der Bahnsteigenden besser, sowohl um den nächstgelegenen Teil des Zuges zu erreichen, als auch im Mittel über alle Wagen des Zuges.

krza wrote:

Theoretisch könnte man das sogar mit Stop-Positionen machen,

Dies ist durchaus möglich, wenn wir die Stop-Position als Linie oder Fläche mappen, die den Node auf dem Fahrweg mit der Platform (und bei Bedarf dem genutzten Bereich der Platformen) verbindet. Dann kann diese Stop-Position in der Art der von Weide vorgeschlagenen Pios in der Routenrelation verwendet werden. Platforms brauchen dann nicht mehr in die Relation, da diese durch gemeinsame Nodes zur Stop-Position auffindbar sind.

krza wrote:

ich persönlich würde aber eher die übliche Fahrzeugmitte als Punkt setzen.

Hier scheint auch wieder einmal eine Definition zu fehlen, wo die Stop-Position zu liegen hat.
Nachträglich definieren oder durch ein Tag bezeichnen?
Bei mittiger Lage der Stop-Position könnte auch ein Tag die Länge des Haltebereichs angeben.
Es fehlt dann nur noch die Verknüpfung zur Platform. Ggf. könnten wir darüber nachdenken, dies in der Stop-Area Relation, z.B. durch eindeutige Zusätze zur Rolle, zu machen. Dann könnten wir auch auf die Platform in den Routen verzichten.

slhh wrote:

Und wenn dann die Linienrelation fehlt, oder ein Bahnsteig ungenutzt (nur bei Betriebstörungen genutzt wird) ist, wird er nicht mehr gerendert oder einheitlich mit Bushaltestellen gerendert?

Wenn etwas fehlt, dann ist es ein Fehler. Wir müssen uns von dem Gedanken lösen, alle möglichen Fehler oder Unzulänglichkeiten durch irgendwelche Tagging-Konstruktionen kompensieren zu wollen. Das wird nichts. Das obige Beispiel könnte allerdings ein Argument sein, diese Tags zu behalten, ja, denn die Frage, ob eine Linienrelation fehlt oder einfach nur nicht existiert, entscheidet, ob es ein Fehler ist oder nicht. Auch hier gilt allerdings der Grundsatz, dass wir Daten liefern und keine Renderer-Instruktionen 😉

Mehr Member in einer Relation erhöhen übrigens nicht unbedingt den Sortieraufwand. Es wird vielleicht unübersichtlich, wenn icht alles auf einen Schirm passt, aber kompliziert wird es meines Erachtens erst, wenn es verschiedene Regeln für eine große Anzahl unterschiedlicher Rollentypen gibt. Vielleicht muss man auch den Editor da noch ein bisschen pimpen, aber das kann man ja machen. Der soll sich schließlich an den Bedarfen orientieren und nicht die Tagging-Strategie am Editor.
Ich halte das mit dem Sortieren undso eigentlich für relativ intuitiv, zumal der Editor in JOSM einen dabei ja auch jetzt schon unterstützt. Viel mehr braucht es meines Erachtens auch nicht.

Zur Länge von Plattformen und Stop-Positionen: Das Argument mit der Berechnung der Wegezeit und dergleichen zählt nicht, wenn nicht die Plattform benutzt wird, sondern der PIO. Bisher hat man nur nicht zwischen beiden unterschieden. Den Gedanken, diese dritte Information, die nun hier PIO genannt wird, irgendwie mit aufzunehmen, geistert mir auch schon seit Jahren im Kopf rum. Ich sehe nur (noch) nicht, dass man dafür ein neues Konzept braucht. Wie gesagt, die Stop-Position der Fahrzeuge ist für die meisten Datennutzer ziemlich unerheblich. Und der Rest hat in der Regel weiterführende Informationen zur Verfügung wie Fahrzeuglänge und dergleichen und kann sich mit einer genormten Position (wie z.B. übliche Mitte oder auch der Anfang, der bei Bahnen oft sogar beschildert ist) weiterhelfen. Ob eine Verbindung zur Plattform wirklich nötig ist ... ich glaube nicht. Dann müssten wir ja auch eine Line zu jedem Gebäude zeichnen, um ein Routing zur Hausnummer zu ermöglichen. Macht kein Mensch (hoffe ich), weil es nicht nötig ist. Und die Stop-Position wird in den meisten Use-Cases auch nicht vorkommen.

Ich plädiere nochmal dafür, Beispiele zu erzeugen. Vielleicht schaffe ich es ja sogar, selber eins beizusteuern, an dem man sich austoben kann 😉

krza wrote:

Da stimme ich allerdings komplett zu. Ich hatte von Unstimmigkeiten gelesen, aber grundsätzlich sollte es nur 1 "Wahrheit" geben. Will das hier nicht weiter vertiefen, darüber wurden schon Abhandlungen verfasst, glaube ich

Na ja, um so hehre Dinge wie Wahrheit gehts da ja nicht. Nicht mal darum, welche Idee besser wäre. Ich könnte mich ohne Weiteres mit der Idee anfreunden, dass der stop verpflichtend wäre. Damit hätten wir ein Problem weniger.

Nicht anfreunden kann ich mich mit der Behauptung, dass das PTv2 wäre. Denn dadurch haben wir jetzt zu einem Datensatz (Beispielrelation 934910) zwei Interpretationen. Nach einer hat der Bus 28 Haltestellen und nach der anderen 2. Das macht die Daten weitgehend wertlos.

krza wrote:

Ehm, was genau habe ich nicht oder zu flüchtig gelesen? Ich kann mich düster erinnern, etwas über Marker undso in dem Paper auf gafte gelesen zu haben, aber schon damals hatte ich es nicht wirklich verstanden, zumal aussagekräftige Beispiele fehlen. oder gibt es inzwischen welche?

Es gibt welche.

Das liegt an mir. Ich hätte deutlicher machen sollen, dass diese Papiere sehr veränderlich sind. Vor kurzem waren da noch Segmentrelationen statt der Auftrennung durch Marker sowie andere oder keine Beispiele.

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.

krza wrote:

Übrigens kannst man sich das Auswählen des Weges (leider) sparen, da diese Operation nur auf Knoten wirkt.

Nein. Gerade ausprobiert:
Node 213444181 mit "Datei" "Objekt herunterladen" laden
Den langen Way selektieren.
Alt+Ctrl+D läd jetzt 5 Relationen, die diesen Weg enthalten und vorher nicht da waren.

krza wrote:

Wählst man also die Endpunkte aus, werden auch nur die dort angeschlossenen Wege nachgeladen, nicht aber diejenigen, die zwischen diesen Punkten mit dem Weg verbunden sind.

Ja, das ist Absicht.

krza wrote:

So solltest Du das nicht formulieren, also ohne zu sagen, was eigentlich passiert und warum das Böses verhindern sollte.

OK:

In einer Relation stehen drei Wege hintereinander:
A
B
C
Jetzt spaltet man B auf und da steht
A
B1 (das ist der Teil, der an A grenzt)
B2 (das ist der Teil, der an C grenzt)
C
In einer anderen Relation (z.B. Gegenrichtung) steht
C
B
A
Dann muss in dieser nach dem Aufspalten von "B"
C
B2
B1
A
stehen.

Man kann also nicht einfach "B" überall durch "B1","B2" ersetzen, denn es könnte genausogut "B2","B1" richtig sein. Man muss in jeder betroffenen Relation nachsehen, welche Nachbarelemente das B hat. JOSM macht das aber nur soweit die Daten schon geladen sind, sie werden also nicht automatisch beschafft.

Alle betroffenen Relationen zum Weg und alle brauchbaren potentiellen Nachbarelemente bekommt man, wenn man den Weg und seine beiden Endpunkte anwählt und Alt+Ctrl+D macht, denn das läd alle referenzierenden Objekte zu den drei gewählten. Nur wenn die Relation an der Stelle sowieso schon kaputt war, wird dann vielleicht falsch eingefügt.

krza wrote:

PS: Weide, das Ctrl+Alt+D taucht in keinem Menü auf, oder habe ich es immer übersehen?

Huch. Ich finde es jetzt auch nicht. Ich habe den Tipp hier aus dem Forum ... ist lang her. Ich hatte irgendwann hier geschrieben, dass ich eine "Millimeterumgebung" um die Endpunkte lade und jemand sagte mir dann "Nimm doch Alt+Ctrl+D". Seitdem ist das meine wichtigste Tastenkombination :-)

Hi Weide, danke für die Erwiderungen.

Die "Wahrheit" hatte ich ja bewusst in Geflügelfüße gesetzt. Ich finde auch die Einheitlichkeit am wichtigsten, auch wenn sie natürlich am einfachsten umzusetzen ist, wenn sie der eigenen Vorstellung entspricht 😉

Bei den Beispielen ... hatte mir schon gedacht, dass es veränderliche Versionen gibt. Vielleicht wäre eine Wiki dazu besser geeignet, zumindest zum Auslagern von Zwischenständen, Diskussionen und Beispielen. Wikis haben allerdings leider auch das Problem, dass man sie kennen muss. Zufällig kommt man selten auf eine drauf, und die Suche ist auch nicht immer hilfreich.

Zur Tastenkombination: Achso, ich wusste nicht, dass es um das Nachladen von Relationen geht. Ich nahm an, dass es nur die Objekte betrifft. Okay, dafür hatte ich ein ungünstiges Beispiel ausprobiert, das keine enthielt. Unterstreicht aber meinen Einwand mit dem Formulieren 😉 Ich werde mir die TK jedenfalls auch merken. Habe sie eben übrigens immerhin in einer JOSM Wiki gefunden, wobei auch hier die Sprache wichtig ist: In der deutschen Version steht da nur "Verweise herunterladen ...", in der englischen immerhin ein verlinktes "Download parent ways and relations", und dort ein Hinweis auf´s File-Menü ... dort hatte ich gar nicht geguckt, aber es ist tatsächlich drin, und das bedeutet, dass man es sich auch als Symbol in die Leiste legen kann*. Und es bedeutet, dass ich es schon genutzt hatte, ohne allerdings die TK zu erkennen 😉 Denn genau für die saubere Bearbeitung von Relationen ist das eine unerlässliche Funktion, da kann ich nur zustimmen.

• ) Nur das Icon ist etwas unglücklich, weil es dasselbe ist wie zum normalen Daten-Download. Aber man muss es sich ja nicht genau daneben legen und kann notfalls auch die TK ändern.
  

Weide wrote:

Nicht anfreunden kann ich mich mit der Behauptung, dass das PTv2 wäre. Denn dadurch haben wir jetzt zu einem Datensatz (Beispielrelation 934910) zwei Interpretationen. Nach einer hat der Bus 28 Haltestellen und nach der anderen 2. Das macht die Daten weitgehend wertlos.

Die Behauptung, dass das PTv2 wäre, erscheint mir noch das kleinste Problem zu sein, da die PT-Version nicht zwingend getagt wird.
Das eigentliche Problem ist, das man eine Änderung gemacht hat, die zu einer falschen Interpretation vorhandener Daten führt. Dass die Änderung dann auch noch nur in einer Sprache dokumentiert ist, beschränkt zwar die Ausbreitung des Problems regional, ist ansonsten aber besonders destruktiv.

Hätte man für weitere platforms eine "+platform"-Rolle oder ähnliches verwendet, wäre das zwar auch formal wohl kein PTv2 mehr, ein wesentliches Problem hätten wir aber nicht.

krza wrote:

Ich erinnere mich an Diskussionen, ob Relations zum Gruppieren genutzt werden sollen oder nicht. Ich sage ganz klar: Ja, denn es sind auch Relationen, die damit beschrieben werden. Meine private und vor allem auch berufliche Erfahrung sagt mir aber auch, dass eine Gruppierung auf der Basis von individuellen Namen eine Katastrophe wäre. Das geht gar nicht. Genau mit sowas erzeugt man Fehler ohne Ende, und bei OSM kommt noch hinzu, dass es sich überhaupt nicht richtig warten lässt. Hier gibt es für mich nur eins: Relationen. Die sind robust und einfach zu handhaben.

Ja, ich habe selbst ein Problem damit, die stop_area und die stop_area_group rauszunehmen und würde gern die Tags "operator" und "network" durch Relationen ersetzen und "vrr:wabe" und ähnliche durch Flächen.

Aber die stop_areas werden zwar gut angelegt aber gehen bei der Pflege (oder Nicht-Pflege) oft kaputt. Eine unzutreffende stop_area ist aber für die Auswertung meist schlechter als garkeine. Die Renderer neigen garnicht dazu, sie zu benutzen. Man lastet den nicht an ÖPV interessierten Mappern zusätzlich zum Mappen der Haltestelle jedesmal die Pflege einer Relation auf. Die kleinen Namensabweichungen, die die Zusammenfassung bei Network und Operator so schwer machen, treten aber bei der Zusammenfassung von Einzelhaltestellen seltener auf, da schon vorhandene Namen aus der Umgebung oft in den Editoren zu den Vorschlägen beim Eintragen gehören.

Ich bin da bei der Gesamtabwägung zum Ergebnis gekommen, dass zwei zusätzliche Relationstypen zu wenig bringen und habe sie wieder rausgeworfen. Man könnte sie aber wieder reinnehmen.

krza wrote:

• die Positionen, an der ein Fahrzeug hält (stop_position)
• die Position, an der Fahrgäste warten (platform)
• die Position, an der Fahrgäste das Fahrzeug bzw. den dafür vorgesehenen Zubringerweg betreten (pio)

Letzteres finde ich etwas irreführend. Ich würde eher sagen
• die Position, zu der die Fahrgäste zum Einsteigen oder ab dem Aussteigen geroutet werden sollten

Dabei wird (für mich jedenfalls) deutlicher, dass es fast immer mit einem der beiden anderen zusammenfällt und es nicht um Zubringerwege geht.

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?

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.

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.

Das ist mir zu hoch 😉 Jedenfalls so in Textform.

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

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

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

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.

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

krza wrote:

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

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

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.

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

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.

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.

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?