ÖPNV Vorentwurf (zurückgezogen)

viw · 2013-07-27 06:44:27

Warum erfassen so wenige Mapper Buslinien? Das ist eine gute Frage. Aber wahrscheinlich ist es einfach anders als die Straße abfahren und dann eintragen. man müsste wahrscheinlich sogar mit dem Bus fahren um zu wissen wo lang dieser fährt.
Jeder Josmbenutzer kann Straßen teilen ohne dabei irgendwelche Relationen zu beschädigen. Der Editor ist inzwischen so schlau auch die Rollen forward Backward an die drehung der Wegrichtung anzupassen.
Einzig gegen das verinigen von Wegen ist man damit nicht gewappnet. Also auch diese Ausrede mag ich nicht gelten lassen.

Aber was unterscheidet eine Straße Hausnummer oder Hydrant von einer Buslinien? Eine Straße ist ein kurzes Stück Weg eine Hausnummer oder ähnliche POI sind Punkte oder räumlich eng begrenzte Objekte.
Buslinien hingegen können durch den ganze Ort oder gar Landkreise führen. Hierfür sind nicht nur einzelne Punkte(Haltestellen) notwendig sondern eine ganze Menge. Auch wenn ich ÖPNV interessiert bin, so kenne ich nach einem Jahr noch nicht alle Buslinien die hier im Umkreis von einem Kilometer fahren, geschweige denn das ich deren Verlauf kennen würde um sie in OSM eintragen zu können. Mit Fernwanderouten und -radwegen ist das wahrscheinlich ähnlich. Und was bringen Teile von Routen?

Wie oft hast du bereits ein Routing für Buslinien durchgeführt? Du schreibst das du es einmal für deine Buslinie gemacht hast! Ich mache das etwa alle drei Monate, aber dann für ganze Landkreise. Und ich kann dir sagen, dass es immer wieder zu Abweichungen und Ungreiomtheiten kommt. Das liegt zum einen daran, dass die Accessregeln eben nur gesetzt werden wenn es explizit untersagt ist(ist ja auch richtig so) und zum anderen das uns eben nur die Haltestellen vorliegen und nicht der kürzeste Weg der richtige Weg ist. Insbesondere in ländlichen Räumen.

Was ist denn die stupide Arbeit beim erfassen von ÖPNV Routen? Das man hier außer Punkten auch noch Wege in die Relation aufnehmen soll? Macht es das wirklich stupider?

Geogast · 2013-07-27 08:22:34

viw wrote:

Was ist denn die stupide Arbeit beim erfassen von ÖPNV Routen? Das man hier außer Punkten auch noch Wege in die Relation aufnehmen soll? Macht es das wirklich stupider?

ja, das stimmt schon, wenigstens bei städtischen Linien (nicht Fernbusse). JOSM unterstützt die richtige Reihenfolge der ways auch sehr gut.
Ich hab letztens die Stadtbahnlinien in H auf das neue Schema umgestellt. Da fand ich die richtige Reihenfolge der stop_posotions und platforms extrem ätzend herzustellen (vgl wambachers post #18). Und das, wo die stop_positions auf der route ja aufgereiht sind wie eine Perlenkette.

Noframe · 2013-07-27 09:05:57

seawolff wrote:

Wir diskutieren hier seltsame, pathologische Fälle, aber nicht, woran die Erfassung der Linien bislang gescheitert ist.

Gute und wichtige Erkenntnis!

seawolff wrote:

Warum erfassen bislang so wenige Mapper Buslinien? Ist der Nutzen unklar, das Datenschema unverständlich, die Editorunterstützung zu schlecht oder die Arbeit beim Erstellen zu viel?

Ich kann hier (wie jeder) nur für mich sprechen:
Der Nutzen ist teilweise klar, aber in diesem Umfang?
Ich denke die meisten von Euch habe eines von diesen Smartphones - die ÖffiApp (ein Kollege hat sie mir gezeigt - übrigens der einzige Grund mir so ein Smartdingens zuzulegen) kennen und nutzen alle?
Datenschema? OSM ist nur ein Teil meines Lebens...
Daher kümmere ich mich daher auch nicht um Editorunterstützungen (fehlende Einarbeitungsfreizeit)...

seawolff wrote:

Kann ein durchschnittlicher Mapper eine Straße editieren (z.B. eine Fahrbahnteilung einfügen) ohne die Buslinie zu beschädigen?

Ich hoffe, dass ich bisher nicht unabsichtlich Schaden angerichtet habe. Wenn, habe ich es nicht überschaut und nicht gewollt!

seawolff wrote:

Was wollen und was können wir realistisch erreichen und pflegen? Die Hauptvariante jeder Linie, einige Nebenvarianten oder alle Varianten? Nur die Strecken, auch Betriebszeiten und Fahrthäufigkeit oder sogar Abfahrtszeiten?

Ähh, was ist mit der Farbe der Abfahrtstafel....

seawolff wrote:

Wie können zukünftig verfügbare, freie Fahrplandaten in OSM integriert oder verknüpft werden?

Wenn überhaupt, bitte verknüpfen.

seawolff wrote:

Ein Datenschema, dass alle denkbaren Fälle abdeckt, aber von der Mehrheit der Mapper nicht umsetzbar ist, nützt niemandem. Keep it simple!

Je mehr Details wir anfangen zu erfassen (aus was für Gründen (ich unterstelle hier teilweise narzisstische) auch immer), desto instabiler wird OSM.
Stoße ich als "durchschnittlicher" Mapper auf komplexe Strukturen, mit denen ich mich befassen will (begrenzte Freizeit), werde ich aus Rücksicht auf den evtl. Nutzen diese und die damit verknüpften Fehler bestehen lassen und mich kopfschüttelnd abwenden.

Wer soll das alles AUF DAUER pflegen???

Keep all in OSM simple!!!

Last edited by Noframe (2013-07-27 19:05:00)

viw · 2013-07-27 14:23:33

Noframe wrote:

Wer soll das alles AUF DAUER pflegen???
Keep all in OSM simple!!!

Die Welt ist aber nicht simpel! Man muss also entweder abstriche an der einen oder anderen Seite machen. Die Frage zu wievielen Kompromissen man bereit ist kann jeder bei OSM selber treffen.
Siehe Gebäude. Manche wollen nur die Dachfläche. Die nächsten wolen die Hausnummern und wieder andere wollen neben Höhe auch noch Farbe und Dachform. Eine Karte sieht bereits schön aus wenn man die Fläche erfasst. navigieren kann man nur mit Hausnummern. Richtig schick sieht es aber erst in 3D aus oder?
Beim ÖPNV ist es ähnlich. Manche erfassen die Haltestellen weil sie daran vorbei kommen. Andere Erfassen alle Wege die von einer Linie befahren werden. Dann sehen sie schick aus auf einer Karte. Richtig auswerten kann man sie aber est wenn die Reihenfolge stimmt und die Haltestellen enthalten sind.

Weide · 2013-07-27 18:39:51

Tirkon wrote:

Zudem ist die stop_area, die bisher zum Ermitteln des Haltestellennamens notwendig war, nicht mehr zwingend erforderlich.

Das war sie vorher auch nicht. Im Public Transport Proposal steht m.E., dass name der Haltestellenname ist und ref sich ebenfalls darauf bezieht. Nur deshalb steht da, dass man sie weglassen darf, wenn es eine stop_area gibt und das stop_areas optional sind. Irgendwie ist aber ins Wiki geraten, dass name den Bahnsteig enthalten soll und ref die Bahnsteignummer und man eine stop area haben muss. Ich halte das für Unfug, den man aber jetzt ohne Edit-Wars aum noch korrigieren kann.

Weide

Weide · 2013-07-27 18:45:14

wambacher wrote:

Bei den Strecken ist das nicht nötig, da die Auswertungen sich die Wege selber zusammensuchen.

Das funktioniert nicht. Ich kenne viele ÖPNV-Linien, die nicht durch automatische Sortierverfahren in die richtige Reihenfolge gebracht werden können.

Weide

Weide · 2013-07-27 19:23:22

viw wrote:

Das heißt nach dem letzten Proposal type=route und type=route_master
Also hier kann ich keine Vereinfachung erkennen.

Die Bedeutung von Rollen und Reihenfolgen einer Relation kann man nur festlegen, wenn man einen neuen Typ definiert. Bei type=route gibt es auch unsortierte Relationen, die mit "forward" und "backward" eine monodirektionale Nutzung angeben und mit der leeren Rolle eine bidirektionale Nutzung. Mit dem Public Transport Proposal haben wir jetzt eine Relationsart, die ebenfalls type=route hat, aber mit der leeren Rolle ganz im Gegensatz zum bisherigen eine monodirektionale Nutzung des Weges angibt, "forward" und "backward" nicht kennt, bei der das alte "stop" in "stop" und "platform" unterteilt wurde, so dass ein klassisch richtiges "stop" bei PTP ein falsches "stop" sein kann.

Ich wollte in dem Vorschlag nicht viel mehr erreichen als in den PTP-Relationen auch drin steckte. Aber es steckte in den PTP-Relationen so drin, dass zusammen mit den nach wie vor sinnvollen klassischen Routen eine ziemliche Verwirrung über de Interpretation ausbrach, weil nur wenige die beiden Routenarten überhaupt als verschieden wahrgenommen haben.

Ich sags mal so: Ich bin ein Anhänger der PTP-Routen; man konnte sehr klar schreiben. Nur wurde beim Lesen vieles unklar, weil zuviele Leute die klassischen und die PTP-Routen nicht unterscheiden konnten

viw wrote:

Die Stoparea hat jedoch andere Funktionen. Sie soll Masten zusammenfassen, auch wenn diese unterschiedliche Namen haben. Hier wird eine Art Hirachie geschaffen, die man nicht aufgeben sollte. Beim Oxomoa schema gab es dafür mehrere Abstufungen. Als stoparea und stopareagroup. Dei Bedeutung hat sich aber nicht jedem erschlossen.

Die stop_area wurde in meinem Vorschlag nicht ersetzt oder gestrichen. Sie existiert völlig unverändert nach wie vor. Man ist nur nicht mehr auf sie angewiesen, um z.B. eine Haltestellenliste zu bekommen. Sie war im PTP optional und daran sollte sich nichts ändern. Bei größeren Haltestellen finde ich sie durchaus sinnvoll.

viw wrote:

Was ich hier sehe sind die Möglichkeit Segmente zu integrieren. Das macht es nicht gerade einfacher in der Auswertung/Rendering als auch ist es nicht intuitive warum das so und dort wieder anders steht. Eine Relation je Linienvariante ist nicht nur das einfachste, sondern es ist sämtlichen mir bekannten ÖV-Verwaltungssystemen gängige Praxis. Auch die Dateiaustauchformate wie HAFS, Infopool oder GTFS kennen das nicht anders.

Am Prinzip "Eine Relation je Linienvariante" ändert sich durch die Segmente absolut nichts.

Die dort genannten Daten werden einfach included (Halte zu Halten, Fahrwege zu Fahrwegen). Segmente müssen nicht interpretiert werden, da sie (außer den Vollständigkeitsangaben) gar keine Eigenschaften haben. Alles passiert nach dem Einfügen. Das ist technisch extrem einfach.

Ich habe allerdings auch etwas Bedenken, das manche das Segmentieren zum Selbstzweck machen und nicht auf die Fälle beschränken, wo Segmente zur Übersichtlichkeit beitragen...

Weide

Weide · 2013-07-27 19:35:06

seichter wrote:

Generell ist mir nach erstem Durchlesen (mehr darf man von den meisten Nutzern nicht erwarten) nicht gleich klar geworden, wo das alte Proposal abgelöst werden soll und wo es weiter gelten soll.
Was soll z.B. aus den (wenig realisierten) public_transport=stop_position werden?
Aber es soll ja wohl auch nur eine erste Diskussionsgrundlage sein.

Abgelöst werden nur route- und route_master-Relationen. Und es soll keine schlagartige Ablösung geben.

Hinzugefügt werden Tags, die mit "pt2_" anfangen.

public_transport wird ergänzt um den neuen Wert "any_platform". Der ist fast völlig identisch mit dem vorhandenen Wert "platform". Der Wert "platform" besagt bei einem Node leider, dass da in der Realität nichts ist -- da ist die Bedeutung leider anders als bei Linien oder Flächen. Der neue Wert "any_platform" sagt einfach nichts über die Ausführung der platform und kann deshalb auch benutzt werden, wenn man nur die Info "da ist ne Haltestelle" hat.

stop_position gibt es nach wie vor -- sie werden nur nicht mehr in den neuen Routen erwähnt.

Weide

Weide · 2013-07-27 19:38:19

seawolff wrote:

Das entspricht dem Fahrplan der ÖPNV-Anbieter, die auch nicht angeben, über welche Straßen/Weichen/Wasserwege die Verbindung läuft.

Ja. Der Vorschlag entspricht denLinienplänen der ÖPNV-Anbieter und nicht den Fahrplänen.

Weide · 2013-07-27 19:45:57

Tordanik wrote:

Die Reihenfolge, in der Haltestellen angefahren werden, ist aus meiner Sicht ohnehin die entscheidende Information - der genaue Fahrtverlauf ist für den Fahrgast nur in den seltenen Fällen wirklich interessant, wo an beliebigen Stellen ein Stopp angefordert werden kann. Und in der Regel dürfte, ggf. mit sehr wenigen "via"-Punkten, auch der Fahrtverlauf eindeutig abzubilden sein.

Der Normalfall ist aber die halbfertige Route. Da sieht man jetzt die Löcher in der Fahrstrecke und kann sich ausmalen, ob da auf irgendeinem langen Stück nicht noch Halte fehlen oder ob die erfasste Route nicht Hinweise auf fehlende Haltestellen liefert.

Abends und Nachts ist es darüber hinaus bei immer mehr Verkehrsbetrieben inzwischen auch offiziell möglich, den Fahrer um einen außerplanmäßigen Halt (nur auf der planmäßigen Fahrstrecke) zu bitten.

Weide

Weide · 2013-07-27 19:55:48

viw wrote:

Wenn dann noch auf die Stopstellen verzichtet wird, wird es auch schwerer das Lot auf die befahrene Strecke zu fällen.

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.

Weide

Weide · 2013-07-27 19:59:51

Geogast wrote:

Weiteres Problem: andere Mapper sehen 2 benachbarte ways mit identischen Tags u identischen Relation-Zugehoerigkeiten und machen daraus einen way. Schwer, Nicht-Öffi-Mapper davon abzuhalten.

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.

Weide

Weide · 2013-07-27 20:04:55

Geogast wrote:

Das wurde jetzt schon oft beantwortet: solche Fälle können mit via-Punkten erfasst werden

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.

Weide

Weide · 2013-07-27 20:10:16

seawolff wrote:

In den mehrdeutigen Fällen _kann_ der Mapper beim punktbasierten Modell eine Variante festlegen, beim bisherigen Modell _muss_ er eine Variante angeben, auch wenn er den Regelweg des Zuges nicht kennt

??

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.

Weide

rayquaza · 2013-07-27 20:23:08

Weide wrote:

viw wrote:
Das heißt nach dem letzten Proposal type=route und type=route_master
Also hier kann ich keine Vereinfachung erkennen.
Die Bedeutung von Rollen und Reihenfolgen einer Relation kann man nur festlegen, wenn man einen neuen Typ definiert. Bei type=route gibt es auch unsortierte Relationen, die mit "forward" und "backward" eine monodirektionale Nutzung angeben und mit der leeren Rolle eine bidirektionale Nutzung. Mit dem Public Transport Proposal haben wir jetzt eine Relationsart, die ebenfalls type=route hat, aber mit der leeren Rolle ganz im Gegensatz zum bisherigen eine monodirektionale Nutzung des Weges angibt, "forward" und "backward" nicht kennt, bei der das alte "stop" in "stop" und "platform" unterteilt wurde, so dass ein klassisch richtiges "stop" bei PTP ein falsches "stop" sein kann.
Ich wollte in dem Vorschlag nicht viel mehr erreichen als in den PTP-Relationen auch drin steckte. Aber es steckte in den PTP-Relationen so drin, dass zusammen mit den nach wie vor sinnvollen klassischen Routen eine ziemliche Verwirrung über de Interpretation ausbrach, weil nur wenige die beiden Routenarten überhaupt als verschieden wahrgenommen haben.
Ich sags mal so: Ich bin ein Anhänger der PTP-Routen; man konnte sehr klar schreiben. Nur wurde beim Lesen vieles unklar, weil zuviele Leute die klassischen und die PTP-Routen nicht unterscheiden konnten

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.

viw wrote:

Wie oft hast du bereits ein Routing für Buslinien durchgeführt? Du schreibst das du es einmal für deine Buslinie gemacht hast! Ich mache das etwa alle drei Monate, aber dann für ganze Landkreise. Und ich kann dir sagen, dass es immer wieder zu Abweichungen und Ungreiomtheiten kommt. Das liegt zum einen daran, dass die Accessregeln eben nur gesetzt werden wenn es explizit untersagt ist(ist ja auch richtig so) und zum anderen das uns eben nur die Haltestellen vorliegen und nicht der kürzeste Weg der richtige Weg ist. Insbesondere in ländlichen Räumen.

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…

Weide · 2013-07-27 20:24:11

Balgofil wrote:

Bei den neuen Relations habe ich jetzt noch nicht wirklich verstanden, was ein minivar ist. In welchen Fällen soll man den nutzen?

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
1. nichts an den Zeiten im Fahrplan ändern
2. 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.

Weide

Weide · 2013-07-27 20:36:04

EvanE wrote:

(Ich hatte seinerzeit vorgeschlagen, die Art des Schema als Tagg zu erfassen. Das erhielt jedoch keine Zustimmung.)

Mist, das habe ich verpennt. Ich hätte es unterstützt.

Weide

Edit: ersten Absatz gestrichen. Ich hatte Dich zuerst falsch verstanden.

Last edited by Weide (2013-07-27 21:25:11)

Weide · 2013-07-27 20:40:17

seawolff wrote:

Ein Datenschema, dass alle denkbaren Fälle abdeckt, aber von der Mehrheit der Mapper nicht umsetzbar ist, nützt niemandem. Keep it simple!

Das sehe ich auch so. Aber Einstein soll gesagt haben:

Make it as simple as possible, but not simpler.

Weide

Weide · 2013-07-27 20:59:09

rayquaza wrote:

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.

zu 1. Nein, bloß nicht.
zu 2. Ja, genau.

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

Weide

rayquaza · 2013-07-28 01:50:56

Weide wrote:

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

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.

Weide wrote:

Aber irgendwann sagen wir dann entweder "das Alte kommt weg" oder "das Neue kommt weg".

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.

Weide · 2013-07-28 07:54:56

rayquaza wrote:

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.

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.

...besonders wenn es keinen wirklichen Mehrnutzen gibt...

Na ja, es ist immerhin eine Liste von 15 angegangenen Problemen und nur einige von ihnen sind auch im PTP lösbar.

Vielleicht sollte man eher einfach ein Tag einführen, dass aussagt, ob die Relation nach dem veralteten oder dem aktuellen Schema ist...

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"

Weide

seawolff · 2013-07-28 09:46:28

Weide wrote:

seawolff wrote:
In den mehrdeutigen Fällen _kann_ der Mapper beim punktbasierten Modell eine Variante festlegen, beim bisherigen Modell _muss_ er eine Variante angeben, auch wenn er den Regelweg des Zuges nicht kennt
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.

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.

viw · 2013-07-28 11:41:05

seawolff wrote:

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.

Weide · 2013-07-28 13:52:54

seawolff wrote:

Auf der Bahnstrecke Kiel-Plön-... gibt es nur bei der Ausfahrt aus Kiel Hbf. zwei mögliche Fahrwege.

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.

seawolff wrote:

Im streckenbasierten Modell muss man ohne Kenntnis des Fahrwegs eine 200m Lücke lassen oder eine der Alternativen raten.

Man muss eine Lücke lassen. Raten ist falsch.

Weide

Weide · 2013-07-28 15:08:56

seichter wrote:

Kann der in talk-de erwähnte JOSM-Preset zum Ausprobieren (nicht Hochladen) zur Verfügung gestellt werden?

Hab ich hinten auf der Vorschlagsseite angehängt. Bitte bedenke, dass ich von Presets keine Ahnung habe ... ist mein erster...

Weide

Announcement

#51 2013-07-27 06:44:27

Re: ÖPNV Vorentwurf (zurückgezogen)

#52 2013-07-27 08:22:34

Re: ÖPNV Vorentwurf (zurückgezogen)

#53 2013-07-27 09:05:57

Re: ÖPNV Vorentwurf (zurückgezogen)

#54 2013-07-27 14:23:33

Re: ÖPNV Vorentwurf (zurückgezogen)

#55 2013-07-27 18:39:51

Re: ÖPNV Vorentwurf (zurückgezogen)

#56 2013-07-27 18:45:14

Re: ÖPNV Vorentwurf (zurückgezogen)

#57 2013-07-27 19:23:22

Re: ÖPNV Vorentwurf (zurückgezogen)

#58 2013-07-27 19:35:06

Re: ÖPNV Vorentwurf (zurückgezogen)

#59 2013-07-27 19:38:19

Re: ÖPNV Vorentwurf (zurückgezogen)

#60 2013-07-27 19:45:57

Re: ÖPNV Vorentwurf (zurückgezogen)

#61 2013-07-27 19:55:48

Re: ÖPNV Vorentwurf (zurückgezogen)

#62 2013-07-27 19:59:51

Re: ÖPNV Vorentwurf (zurückgezogen)

#63 2013-07-27 20:04:55

Re: ÖPNV Vorentwurf (zurückgezogen)

#64 2013-07-27 20:10:16

Re: ÖPNV Vorentwurf (zurückgezogen)

#65 2013-07-27 20:23:08

Re: ÖPNV Vorentwurf (zurückgezogen)

#66 2013-07-27 20:24:11

Re: ÖPNV Vorentwurf (zurückgezogen)

#67 2013-07-27 20:36:04

Re: ÖPNV Vorentwurf (zurückgezogen)

#68 2013-07-27 20:40:17

Re: ÖPNV Vorentwurf (zurückgezogen)

#69 2013-07-27 20:59:09

Re: ÖPNV Vorentwurf (zurückgezogen)

#70 2013-07-28 01:50:56

Re: ÖPNV Vorentwurf (zurückgezogen)

#71 2013-07-28 07:54:56

Re: ÖPNV Vorentwurf (zurückgezogen)

#72 2013-07-28 09:46:28

Re: ÖPNV Vorentwurf (zurückgezogen)

#73 2013-07-28 11:41:05

Re: ÖPNV Vorentwurf (zurückgezogen)

#74 2013-07-28 13:52:54

Re: ÖPNV Vorentwurf (zurückgezogen)

#75 2013-07-28 15:08:56

Re: ÖPNV Vorentwurf (zurückgezogen)

Board footer