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.
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.32954&lon=10.14146&layers=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.
Ich bau mal ein paar Beispiele. Die werden dann auch auf gafte.de liegen. Kann aber 'ne Zeit dauern.
Weide
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.
Und damit sorgst Du auch dafür, dass sich ptv2 bei Renderern nicht durchsetzt, ebenweil keine Notwendigkeit besteht. Es wird ja alles angezeigt.
Immer der, der rendert, nicht wir Mapper.
Das ist richtig, aber ohne die Hobbies einzelner Herren hätten wir fast gar keine Karten.
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
Das wird nicht dadurch besser, dass ein noch komplizierteres ptv3 eingeführt wird.
Für die auf openstreetmap.org angezeigten Karten wird es doch ein festgelegtes Verfahren geben?
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.
Was ich gelesen habe, sieht erstmal einfacher aus. Aber lass und mal Beispiele abwarten.
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
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.
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.
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.
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.
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.
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:
- 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.
- 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.
- 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.
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.165288&z=17&sv=57.784190,14.164399,5.8504,1.3259,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.
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
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.
Soweit richtig.
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).
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.
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).
Daher hatte ich ja z.B. “pt_v003_” vorgeschlagen.
Jupp.
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
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.
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.
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.
Überall dort, wo entweder die gegenüberliegenden Haltestellen zu weit entfernt sind oder “um die Ecke” liegen. In Dortmund gibt’s einige.
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).
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?