Ja, das ist so. Aber wozu sollte man ein Lot auf den Fahrweg fällen wollen? Für das Fahrzeug-Routing? Ich kenne nur einen Fall in dem es möglich ist, anhand der Fahrwege ÖPNV-Routen zu ermitteln: extrem gut versorgte Gegenden mit extrem dichtem Taktfahrplan. In allen anderen Fällen ist ein Fahrzeug-Routing ohne Fahrplan grober Unfug. Und für das Fußgängerrouting beim Umsteigen brauchen wir die Haltepositionen der Fahrzeuge nicht; wir bekommen aus dem Fahrplanrouting Haltestelle und Platformnummer und ab da läuft das Fußgängerrouting.
Ja, das passiert. Da sind dann aber auch Wanderwege, administrative Grenzen, Abbiegeverbote, Multipolygone und tausend andere Sachen betroffen. Es führt kein Weg mehr daran vorbei, dass zu lernen.
Mich würde es erheblich stören, wenn die Busroute sich durch das Erfassen einer vergessenen völlig unbeteiligten Straße oder durch Änderung von Einbahnstraßenregelungen abseits der Strecke ändern würde.
Aber noch wichtiger ist mir Möglichkeit, an einer halbfertigen Route weiterarbeiten zu können. Eine komplette Route entsteht nicht schlagartig.
Nein, im Gegenteil. Stücke, die man nicht kennt, gibt man natürlich nicht an. Das ist klar erkennbar. Wollte man das im punktbasierten Modell ereichen, dann müsste man via-member einführen, die auf “nichts” zeigen, also etwa auf eine informationslose Relation.
Also willst du im Prinzip die bisherigen type=route umtaggen auf type=pt2 (also als einzigen Unterschied die Bezeichnung)? Dafür ist es jetzt etwas zu spät.
Und wenn du jemanden findest, der vom “neuen” PT-Schema noch nichts mitbekommen hat: Schreib ihm einfach eine freundliche Nachricht und biete an es zu Erklären. Das hält einen selbst vielleicht kurz vom Mapping ab (und zwar weniger als dieser Thread!), aber dafür hat man danach einen weiteren Mapper, der mithelfen kann alte Relationen neu zu erfassen.
Da fällt mir gerade noch etwas dazu ein: Der Verkehrsverbund hier versucht scheinbar mit einer Navigationsanwendung (mit Navteq-Daten) Linienverlaufspläne für Fahrgäste zu erstellen – Viele davon sind deutlich fehlerhaft…
Die Minivar ist die Notbremse gegen die Variantenvervielfachung bei Zuglinien. Viele Zuglinien benutzen verschiedene Bahnsteige je nachdem, ob gerade ein höherrangiger Zug schreit “das ist mein Gleis, das ist mein Bahnsteig”. Das sind lokale Varianten, also eigentlich keine richtigen Varianten der Routen. Die sind aber im Laufe des Zugweges beliebig kombinierbar, da sie nur lokal bedingt sind. Wenn jetzt eine Zuglinie drei solcher Bahnhöfe mit je zwei Bahnsteigmöglichkeiten hat, dann verachtfacht sich die Zahl der Varianten dieser Linie.
Es gibt Fälle, in denen wir mit “verachtfachung” nicht auskommen! Das würde alles unlesbar machen. Da immer mehr Einzelgleise getaggt werden, brauchen wir dafür jetzt eine Lösung. Das sollen die Minivars sein.
Zur konkreten Frage: Minivars sollen eingesetzt werden, wenn die Unterschiede
nichts an den Zeiten im Fahrplan ändern
nichts an der Liste der angefahrenen Bahnhöfe ändern
Im Moment werden sie meist weggelassen. Aber wir brauchen die Unterschiede zwischen den Bahnsteigen, die ja evtl. mal für Rollstuhlfahrer geeignet sind und mal nicht. Einfach die wichtigste Minivariante einzutragen, ist eigentlich genauso schlecht, wie sie als Variante einzutragen.
Die neuen existieren neben den alten. Die Programme können wählen, was sie nutzen wollen. Unveränderte Programme nutzen automatisch die alten weiter und erkennen die neuen nicht. Angepasste Programme ignorieren die alten Relationen, wenn es dazu eine neue gibt. (pt2_ignore=yes).
Umbenennungen wären auch ansonsten unsinnig. Die neuen Relationen unterscheiden sich inhaltlich deutlich von den alten. Keine stop positions, Mehrfachangaben zu einer Haltestelle, Unterscheidbarkeit von aufeinanderfolgenden gleichnamigen Haltestellen, Behandlung von Kreisverkehren, Linienbezeichnungen, …
Die neuen Relationen sind klar erkennbar und damit gut unterstützbar. OSMI, Keep Right, JOSM Validator, … werden in dem Vorschlag hoffentlich viele klare Kriterien finden.
Aber irgendwann sagen wir dann entweder “das Alte kommt weg” oder “das Neue kommt weg”.
Das ist imo auch unschön, weil das dem entspricht, dass man z.B. Adressen zweimal erfasst (als eigenständige OSM-Objekte!), einmal nach einem alten Schema, bei dem man zusätzlich angibt, dass neue Anwendungen dieses Objekt ignorieren sollen und einmal nach einem neuen Schema. Veränderungen müssten natürlich immer an beiden vorgenommen werden. Ich bezweifle, dass das wirklich umgesetzt werden würde.
Mich hatte das “neue” PT-Schema übrigens dazu gebracht hier im Gebiet sehr viele Buslinien neu zu erfassen (fast alle davon waren zuvor nicht vorhanden, schon nach dem alten Schema fehlerhaft oder zumindest veraltet). Darauf das alles umzutaggen habe ich wirklich keine Lust, besonders wenn es keinen wirklichen Mehrnutzen gibt (davon ausgehend, dass alle Buslinien im neuen Schema seien, was ja wohl Ziel ist).
Vielleicht sollte man eher einfach ein Tag einführen, dass aussagt, ob die Relation nach dem veralteten oder dem aktuellen Schema ist und bei Abwesenheit dieses muss man wie bisher raten. Für weitere “Funktionen” des Schemas wäre es effizienter dieses unter Beibehaltung der Kompatibilität zu erweitern statt ein neues einzuführen.
Ja, das ist häßlich. Aber eine schlagartige Umstellung ist nicht machbar. Die Doppelexistenz dauert aber nicht bis zur Entscheidung der Community, eines als deprecated zu erklären. Sobald die wichtigsten ÖPNV-Programme das Schema eingebaut (oder abgelehnt) haben, braucht man die Relationen nicht mehr doppelt und muss nicht mehr doppelt pflegen. Wenn die ÖPNV-Karten und die Prüfprogramme nicht mitziehen, dann ist PT2 gescheitert und sollte raus. Wenn sie mitziehen, dann gibt es einige Zeit PTP-Linien und PT2-Linien je nach Entscheidung der Mapper, aber keine doppelten.
Na ja, es ist immerhin eine Liste von 15 angegangenen Problemen und nur einige von ihnen sind auch im PTP lösbar.
Ich glaube, dass solche Tagging-Schema-Tags in OSM nicht akzeptiert werden. Mein Versuch wurde jedenfalls vehement abgelehnt. “Das nimmt den Druck zur Vereinheitlichung aus dem System. OSM geht vor die Hunde, wenn wir Tags zulassen, die Taggingschemata angeben”
Ich habe die Idee offenbar zu schlecht erklärt. Das Modell ist viel einfacher.
Auf der Bahnstrecke Kiel-Plön-… gibt es nur bei der Ausfahrt aus Kiel Hbf. zwei mögliche Fahrwege.
Ohne Kenntnis des korrekten Fahrwegs hat die Relation die Elemente
Stop Kiel
Stop Raisdorf
Stop Preetz
Stop Ascheberg
Stop Plön
mit Definition des Fahrwegs
Stop Kiel
Via <Punkt auf Ausfahrgleis>
Stop Raisdorf
Stop Preetz
Stop Ascheberg
Stop Plön
Im streckenbasierten Modell muss man ohne Kenntnis des Fahrwegs eine 200m Lücke lassen oder eine der Alternativen raten.
das ist soweit verständlich. Aber was ist jetzt der korrekte Weg bei der Auswertung? Wird dort jetzt bei der Darstellung geraten? wird dort die Lücke gelassen sobald mehr als eine Alternative gefunden wird? Wie soll man das am Ende unterscheiden wenn der Weg doch geraten wird? Der nächste glauibt doch dort ist alles i.O.
In der Realität oder in unserem Datenbestand? Wir können nicht davon ausgehen, dass beides übereinstimmt. Das via-Modell geht doch irgendwie von kompletten Daten aus.
Ich habe gestern erst eine in den Luftbildern nicht erkennbare Weiche eingetragen. Bei der automatischen Wegsuche wären die Züge schon bei der Ausfahrt aus dem davor liegenden Bahnhof auf das Gleis der Gegenrichtung gewechselt.
Das würde den Router vor eine zweite Aufgabe stellen. Nämlich erkennen dass es mehr als einen Weg gibt. Und den gibt es eigentlich immer, aber ab wann wäre er möglicherweise relevant?
Ich finde es wirklich interessant, wenn man das zuverlässich schaffen könnte. Denn vom VBB liegen solche Fahrplandaten mit den Haltestellen ohne viaPunkte vor. Ich denke das man um eine Kontrolle beim einlesen nicht drumherum kommt.
Es gibt in OSM nicht “die korrekte Auswertung”.
Eine sinnvolle Variante wäre, in der ÖPNV-Karte den kürzesten, zulässigen Weg zu rendern.
In den Endnutzerkarten sind fehlende Informationen meist nicht erkennbar. Die üblich Mapnikkarte unterscheidet z.B. nicht zwischen Feldwegen mit “tracktype=grade3” und solchen ohne den key “tracktype”.
In einer Spezialkarte für Mapper könnte man natürlich darstellen, ob es mehrere alternative, ähnlich gute Routingergebnisse gibt.
In diesem konkreten Fall stimmen Realität und Datenbestand überein
Die ÖPNV-Routen können nicht besser als das Wege- bzw. Gleisnetz sein. Ob man die Routingarbeit dem Mapper aufbürdet oder vom Computer machen lässt, ändert daran nichts.
In der Theorie ja, in der Praxis tut das niemand. Ich habe solche Lücken jedenfalls noch nie gesehen.
Genau das ist das Problem: Nehmen wir z.B. eine zweigleisige Bahnstrecke mit GWB, bei der das Ggl durch eine Kurve zwischen einem Haltepunkt und einem Bf kürzer ist, auf der ein Zug vom Regelgleis der Strecke im ersten Bf zu einem Gleis links des Ggl im zweiten Bahnhof fährt, also im auf der freien Strecke auf dem Regelgleis. Nun wird hinter dem Hp eine Üst errichtet.
Was wird an Veränderungen in OSM von einem “normalen” Mapper vorgenommen? Vermutlich würde einfach nur das Gleisstück eingefügt. Bei der bisherigen Erfassung der Relationen ist das kein Problem. Bei einer Erfassung mit Via-Punkten würde damit der Fahrweg über das Gegengleis kürzer und als befahren angenommen – Es müsste also zusätzlich zur Ergänzung der Weichen in jeder dort entlangführenden Relation mindestens ein Via-Punkt aufgenommen werden.
Andersrum kann man afaik durch korrekt ausgeführte Änderungen (d.h. z.B. Elternelemente sind bei Bearbeitung geladen) eine Relation nur beschädigen, wenn z.B. die zweigleisige Strecke zu einer eingleisigen wird. Dabei würde ich auch erwarten, dass das passiert – Ich halte es sogar für gut, da sich bei sowas häufiger auch noch mehr am Verlauf ändert.
Wenn die Routingarbeit ein Mapper macht kann er aber dabei fehlende Wege bemerken und ergänzen (selbst schon oft gemacht) – das kann eine Software nicht so gut…
