PTv3: Zielsetzung eines modifizierten ÖPNV Modells

[Nakaner]

Hallo hsimpson,

@hsimpson

Ich finde, es ist am wichtigsten, dass PTv3 endlich klarheit bezüglich der zu verwendenen Schlüssel schafft. Dass PTv2 quasi parrallel zu PTv1 gebaut wurde hat sicherlich sehr viel zur allgemeinen Verwirrung beigetragen.

Die Probleme bei PTv2 sind in meinen Augen:

• Das Proposal ist zwar angenommen, aber die Wikiseiten, die sich mit ÖPNV beschäftigen, sind erst Jahre später aktualisiert worden. Solche Widersprüche fördern Missverständnisse und stiften Verwirrung. Auch ich bin diesen eine Zeit lang aufgesessen.

• Ein Taggingschema, das mehr macht, als nur ein paar Tags zu erfinden, wird ohne eine Musterimplementierung nur beschränkten Erfolg haben. Für ein x-beliebiges neues Tag foo=bar, erfordert es nur Änderungen am Kartenstil. Neue Relationstypen erfordern jedoch Support durch die Werkzeuge, die aus diesen Relationen normale Simple-Feature-Geometrien (Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon) erzeugen, wie sie von den üblichen GIS-Werkzeugen verwendet werden. Aus diesem Grund hat die site-Relation auch nur eine geringe Relevanz. Wer also möchte, dass ein von ihm vorangetriebenes Mappingschema auch unterstützt wird, muss, so hart es leider auch klingen mag, selber Software programmieren.

• Das Problem mit den schwer wartbaren Routen ist wirklich ein Problem. Ich meine damit das Schulbusproblem und die Segmentfrage. Ich kann mit Segmenten leben.

Nicht störenden Unschönheiten sind:

• Masterrouten. Mir leuchtet noch nicht ein, wozu die erforderlich sind. Das mag aus Mapperperspektive auf dem Papier schön aussehen (“dann ist da eine Relation, die die anderen Relationen zusammenfasst”). Das Konzept hat aber das oben erwähnte Problem, dass es von wenigen Anwendungen unterstützt wird und in den mir bekannten Fällen nur Informationen dupliziert. Versteht mich nicht falsch! Ich bin nicht streng gegen Duplizierung, aber wenn Duplizierung, dann bitte so, dass beide Varianten ähnlich gut für Datennutzer zugänglich sind.

• Geteilte Bahnsteige (siehe Beitrag #1 von sllh)

@hsimpson

Es ist sicherlich keine verkehrte Idee, Schlüssel wie public_transport beizubehalten, aber hier sollte es bei der Einführung vermieden werden, auf die alten PTv2 und 1 zu verweisen. Es muss ganz klar sein, dass es ab dem Zeitpunkt nur noch PTv3 gibt und nichts anderes. Auch ist es sehr wichtig, alle relevanten Renderer von anfang an im Boot zu haben. Diese sollten in einer Übergangsfrist beide Schematas unterstützen, aber nach maximal 6-12 Monaten darf es keinen Renderer mehr geben, der PTv3 nicht unterstützt.

Dem Renderer sind die Daten egal. Du meinst vermutlich “Kartenstil”, oder?

Wenn zu mir als Kartenstilautor jemand sagen würde, du musst das neue Tag foo=bar unterstützen, weil es dazu ein akzeptiertes Proposal gibt, würde ich ihm freundlich mitteilen, dass ich gerne abwarten würde, bis es angenommen ist. Der beste Weg, etwas voranzubringen, ist Dinge selber zu machen. So funktioniert Open Source.

Viele Grüße

Michael