OpenStreetMap Forum

huby1691

Member

Registered: 2009-08-27

Posts: 10

Re: ÖPNV Bus stop_position

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

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

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?

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.

Thoschi

Member

Registered: 2013-07-19

Posts: 767

Re: ÖPNV Bus stop_position

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:

    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

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

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.

krza

Moderator

From: Köln

Registered: 2008-05-24

Posts: 640

Re: ÖPNV Bus stop_position

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.

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

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.

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.

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.

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.

slhh

Member

Registered: 2012-09-02

Posts: 358

Re: ÖPNV Bus stop_position

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.

krza

Moderator

From: Köln

Registered: 2008-05-24

Posts: 640

Re: ÖPNV Bus stop_position

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.

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

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.

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

slhh

Member

Registered: 2012-09-02

Posts: 358

Re: ÖPNV Bus stop_position

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.

krza

Moderator

From: Köln

Registered: 2008-05-24

Posts: 640

Re: ÖPNV Bus stop_position

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

Soweit richtig.

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

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.

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

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

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.

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

rurseekatze

Member

From: Noise

Registered: 2009-02-13

Posts: 339

Website

Re: ÖPNV Bus stop_position

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

Last edited by rurseekatze (2017-02-19 21:14:24)

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

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.

slhh

Member

Registered: 2012-09-02

Posts: 358

Re: ÖPNV Bus stop_position

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.

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.

TobWen

Member

From: Ruhrgebiet

Registered: 2009-03-31

Posts: 1,112

Re: ÖPNV Bus stop_position

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.

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

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.

---

Was macht der RVR mit OpenStreetMap? https://forum.openstreetmap.org/viewtopic.php?id=63052
Aktuelle Luftbilder des RVRs (Ruhrgebiet) http://forum.openstreetmap.org/viewtopic.php?id=28511

miche101

Member

Registered: 2008-12-16

Posts: 1,297

Re: ÖPNV Bus stop_position

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?

---

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

krza

Moderator

From: Köln

Registered: 2008-05-24

Posts: 640

Re: ÖPNV Bus stop_position

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.

miche101

Member

Registered: 2008-12-16

Posts: 1,297

Re: ÖPNV Bus stop_position

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

---

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

rurseekatze

Member

From: Noise

Registered: 2009-02-13

Posts: 339

Website

Re: ÖPNV Bus stop_position

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

Last edited by rurseekatze (2017-02-20 13:17:14)

miche101

Member

Registered: 2008-12-16

Posts: 1,297

Re: ÖPNV Bus stop_position

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

---

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

krza

Moderator

From: Köln

Registered: 2008-05-24

Posts: 640

Re: ÖPNV Bus stop_position

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

miche101

Member

Registered: 2008-12-16

Posts: 1,297

Re: ÖPNV Bus stop_position

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

---

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

miche101

Member

Registered: 2008-12-16

Posts: 1,297

Re: ÖPNV Bus stop_position

@rurseekatze

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

---

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

krza

Moderator

From: Köln

Registered: 2008-05-24

Posts: 640

Re: ÖPNV Bus stop_position

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

Weide

Member

Registered: 2009-04-05

Posts: 1,491

Re: ÖPNV Bus stop_position

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)

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.

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.

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.

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.

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.

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

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.

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

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.

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.

miche101

Member

Registered: 2008-12-16

Posts: 1,297

Re: ÖPNV Bus stop_position

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

---

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