OpenStreetMap Forum

miche101

Member

Registered: 2008-12-16

Posts: 1,297

Re: ÖPNV Bus stop_position

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

Last edited by miche101 (2017-04-29 18:37:43)

---

OSM-Testkarte, DE-Notes Map, DE:Emergency Map, Maypole Map

miche101

Member

Registered: 2008-12-16

Posts: 1,297

Re: ÖPNV Bus stop_position

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

---

OSM-Testkarte, DE-Notes Map, DE:Emergency Map, Maypole Map

slhh

Member

Registered: 2012-09-02

Posts: 358

Re: ÖPNV Bus stop_position

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.

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.

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.

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

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.

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)

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.

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

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

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.

krza

Moderator

From: Köln

Registered: 2008-05-24

Posts: 640

Re: ÖPNV Bus stop_position

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:

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:

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

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.

Last edited by krza (2017-04-30 13:24:10)

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

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.

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

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.

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

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.

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

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.

Jojo4u

Member

Registered: 2014-08-03

Posts: 1,090

Re: ÖPNV Bus stop_position

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

Last edited by Jojo4u (2017-04-30 17:51:31)

slhh

Member

Registered: 2012-09-02

Posts: 358

Re: ÖPNV Bus stop_position

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.

geri-oc

Member

From: Sachsen

Registered: 2011-03-21

Posts: 5,055

Website

Re: ÖPNV Bus stop_position

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)

krza

Moderator

From: Köln

Registered: 2008-05-24

Posts: 640

Re: ÖPNV Bus stop_position

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.

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

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.

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?

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

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

krza

Moderator

From: Köln

Registered: 2008-05-24

Posts: 640

Re: ÖPNV Bus stop_position

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.

slhh

Member

Registered: 2012-09-02

Posts: 358

Re: ÖPNV Bus stop_position

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?

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.

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.

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.

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.

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.

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.

krza

Moderator

From: Köln

Registered: 2008-05-24

Posts: 640

Re: ÖPNV Bus stop_position

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

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

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.

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

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.

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

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

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.

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.

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

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

krza

Moderator

From: Köln

Registered: 2008-05-24

Posts: 640

Re: ÖPNV Bus stop_position

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.

slhh

Member

Registered: 2012-09-02

Posts: 358

Re: ÖPNV Bus stop_position

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.

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

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.

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

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