Hallo,
erst einmal danke fürs Bescheid geben. Der Einladung zur Diskussion
möchte ich daher auch gerne folgen.
Es ist gut zu sehen, dass es Überlegungen zu sehr vielen Bereichen im
ÖPNV gibt. Allerdings würde ich dringend empfehlen, die verschiedenen
Themen auf mehrere Einzel-Schemata aufzuteilen. In OpenStreetMap ist
es gute Tradition, die einzelnen Aspekte so einfach wie möglich zu
halten, damit Mapper sich mit einfacheren Erklärungen beschäftigen
können - oder die Dinge sogar selbsterklärend werden.
Aus unserer Sicht aktuell ist der Leidensdruck gar nicht so hoch. mdv
nutzt vorwiegend Daten, um Personenverkehr auf dem richtigen Gleis
bzw. den richtigen Straßen routen zu können. Daher werde ich hier nur
versuchen, ein paar Themenkreise abzugrenzen, die jeder für sich
besser in einem unabhängigen Proposal münden sollten:
a) Abgrenzung von verschiedenen Arten von Ways: Dazu steht hier nichts
explizit, aber es wäre aus unserer Sicht schön, sich auf eine
Abgrenzung von railway=rail, railway=light_rail, railway=tram und
railway=subway voneinander zu einigen. Man braucht weitere Werte (z.B.
railway=funicular (Seilbahnen) und railway=monorail (Wuppertaler
Schwebebahn), aber deren Verwendung dürfte wenig Verwirrung mit den
anderen vier Werten hervorrufen, die mitunter leicht zu verwechseln
sind.
b) Abgrenzung von verschiedenen Arten von Relationen: Aus meiner Sicht
kann nicht oft genug darauf hingewiesen werden, dass Linien und die
Gleise auf denen sie verkehren, oft verschieden klassifiziert werden.
Dann sind Karlsruhe, die Vorgebirgsbahn und fast alles andere auch
kein großes Problem mehr. Das geht in dem Vorschlag noch etwas unter.
Aus Sicht von mdv wäre es sehr wünschenswert, Strecken mit
Personenverkehr sichtbar zu machen. Ob das jetzt über die Gleise geht
oder über die auf den Gleisen verkehren Relationen ist relativ egal.
Im einen Fall würde man die Relationen auf Basis des Netzes mit
wenigen Zwangspunkten routen. Im ungekehrten Fall erben die Gleise von
den darauf befindlichen Relationen die Eigenschaft, für
Personenverkehr bevorzugt zu werden. Der Ansatz über die Prioirty-Tags
hat da ja keine großen Freunde gefunden, aber das Service-Tag an
Relationen hat sich in NRW nahezu flächendeckend in nur 2-3 Stunden
eintragen lassen - die Lösung ist sehr pflegeleicht. Danke übrigens
für das Hinzufügen zu dem Proposal.
c) Struktur in die Artenvielfalt an straßengebundenen
Bedarfsverkehrsmitteln bringen
Das ist zwar wünschenswert, aber wird eine große Herausforderung. Da
sind die Betriebsformen vielfältig (mit /ohne festem Linienweg,
mit/ohne Aufnahme von Reisenden abseits der Haltestellen, mit/ohne
Vorbuchungsfrist), und das Marketing der Unernehmen am Markt
potenziert die Verwirrung noch. Es ist mühsam genug, eine einheitliche
Terminologie für den VRR zu finden.
d) Detailstruktur von Haltestellen
Aus unserer Sicht ist hier das vorrangige Interesse, dass im fertigen
Modell Fußgängerrouting funktionieren kann. Besser, wenn die Erfassung
gut genug ist, um auch Rollstuhlfahrer und Blinde leiten zu können.
Das Thema allein füllt ganze Konferenzen und ist mit einem
Forums-Teil-Thread sicher stark unterbesetzt. Ich würde es daher
unbedingt aus dieser Diskussion herausnehmen.
e) Segmente für Linien
Hat ebenfalls eine Reihe von Nebeneffekten. Es sei darauf hingewiesen,
dass das Editieren von Relationen auf Relationen alles andere als
bequem ist. Die Auswertung ist eher noch schlimmer. Wenn jetzt der
Vorschlag kommt, doch Tools dafür zu programmieren, sei darauf
hingewiesen, dass Tools, um mit großen Anzahlen an Relationen
umzugehen, ungleich einfacher zu programmieren gibt - und die gibt es
auch nicht oder nur rdumentär. Generell ist das Problem dabei, dass
Relationen auf Relationen große Menge an neuen Sonder- und
Fehlerkombinationen erlauben, von denen ein Tool oder auch ein Mapper
mit jeder einzelnen umgehen muss.
Von daher würde ich anregen, a) und b) als separate Diskussionen
weiterzuführen und dort recht zügig zu einem Proposal weiterzugehen.
c), d) und e) könnten wir uns dann angehen, wenn wir mit a) und b) ein
Erfolgserlebnis gehabt haben.
Viele Grüße,
Roland
PS: Es gibt von Michael auch bereits eine Antwort dazu. Ich vermute, dass er sie dann gleich noch hier anfügt.