[Talk-de] ÖPNV-Relationen in OSM

Stephan Wolff s.wolff at web.de
Di Apr 3 00:13:39 UTC 2012


Am 02.04.2012 10:54, schrieb Martin Koppenhoefer:
> Am 2. April 2012 03:13 schrieb Stephan Wolff<s.wolff at web.de>:
>> Die Relationen beschreiben entweder nur eine Richtung einer Linie,
>> beide Fahrtrichtungen oder sogar verschiedene Linienvarianten in
>> einer Relation.
>
> ja, das ist so, und erstmal kein Problem

Routing über Relationen ist damit nicht möglich.

> (verschiedene Varianten in
> einer Relation sollte man allerdings ausgliedern)

Da es keinen Konsens gibt, wie Linienvarianten zu behandeln sind,
macht das niemand.

> auch hier gibt es doch durch die unterschiedlichen Mapping-Varianten
> nicht grundsätzlich ein Problem, Fehler wie falsche Rollen sollte man
> natürlich korrigieren.

Kein Programm kann alle Varianten richtig interpretieren.

>> "name"-Tags sind fast immer
>> willkürliche Textfolgen aus ref/operator/network/direction.
>
> solange man weiss, welche Linie es ist (ref), ist das doch egal. Den
> name-Tag könnte man i.d.R. auch einfach weglassen bzw. beim
> Interpretieren nicht weiter berücksichtigen,  da verstehe ich das
> Problem ebenfalls nicht.

Echte Namen sind von Pseudonamen nicht unterscheidbar. Das "name"-Tag
ist eines der wichtigsten in OSM. Es wird schon oft genug missbraucht,
um Texte auf die Karten zu schreiben. Hier wird das Tag als interne
Merkhilfe für Mapper, die nicht zur Auswertung genutzt werden kann,
umgedeutet.

>> "from" und "to" fehlen teilweise oder sind uneinheitlich gebildet.
>> Einzig die Liniennummer ist eindeutig im "ref"-Tag enthalten.
>
> Es kommt halt darauf an, was man haben will. Mit der Zeit sind auch
> unsere Ansprüche gestiegen, während man früher zufrieden war wenn man
> aus der Karte erraten konnte, wo der Bus der Linie 23 langfährt,

Dafür würde ein Tag am way genügen, der viel weniger Arbeit macht.
Mit den geordneten Relationen kann man weitere Informationen
unterbringen, aber sie sind leider nicht nutzbar.

>> Für andere Anwendungen sind die Daten ungenügend. Die vielen Tagging-
>> Varianten machen es unmöglich, die Daten korrekt zu interpretieren.
>
> s/unmöglich/schwieriger bzw. aufwendiger

De facto unmöglich, da Varianten wie "role=platform:60:alternate:1"
nirgendwo definiert sind, oft nicht erkennbar ist, welche Definition
genutzt wird, und Mischvarianten existieren.

>> Leider können sich die relativ großen Relationen des ÖPNV auch
>> unmittelbar störend auswirken.
>
> jede Zusatzinformation macht natürlich die weitere Bearbeitung
> komplexer, das gilt auch hier.

Zusatzinformation in Tags stört normalerweise nicht bei der Bearbeitung,
Mitgliedschaft in Relationen erfordert dagegen oft Verständnis für
den Relationstyp, macht Arbeit und birgt die Gefahr von Konflikten.
Ich finde Relationen nicht falsch, aber es sollte einen Mehrwert
gegenüber einfachen Tags geben.

>> - Umstellung auf ein stark vereinfachtes Relationsschema, bei dem nur die
>> Haltepunkte, aber nicht die Stecken Elemente der Relation sind.
>
> -1, die Routen sollten eindeutig beschrieben sein, dass wäre mit
> diesem Vorschlag nicht der Fall. Man müsste mindestens noch
> Zwischenpunkte (Via-Punkte, die es so nicht gibt in der Realität)
> erfinden, um halbwegs verlässliche Daten zu haben, die aber trotzdem
> nie ganz eindeutig sein könnten (da auch wenn sie es scheinbar jetzt
> sind, der Straßengraph jederzeit erweitert werden kann) .

Ist eine Buslinie in der realen Welt über eine exakte Strecke oder
nur über die Haltestellenabfolge definiert? Ich kenne Buslinien bei
denen die Fahrer verschiedene Strecken nehmen (z.B. Kielius: Kiel Hbf.
- Hamburg Flughafen, bei dem ich schon auf drei Wegen vom Startpunkt
zur Autobahn gefahren wurde). Auch die Bahn schickt ihre Züge 
gegebenenfalls über wechselnde Vorfeldgleise zum Zielbahnsteig.

Meist ist die Strecke zwischen zwei Haltepunkten ohnehin eindeutig.
Wenn man eine Fahrstrecke genauer definieren möchte, finde ich einen 
via-Punkt nicht schlechter als mehrere via-ways. (Auch die via-Punkte
der Abbiegerelationen gibt in der Realität nicht.)

>> Bei allen Varianten könnte man Tags für Betriebszeiten
>> (operating_hours), Takt(frequency?), Fahrzeiten (duration) und wenn
>> möglich eine URL des Fahrplans (url:timetable?) hinzufügen.
>
> +1, diese neuen Tags kann man an die Linien hängen, unabhängig von
> Deinen anderen Vorschlägen.
 >
>> oder
>> - Verzicht auf gerichtete ÖPNV-Linien in OSM. Dann genügt eine leicht
>> zu pflegende Tag-basierte Lösung um Liniennummern mit Haltestellen und
>> Fahrstrecken zu verbinden.
>
> Gerichtete Linien hat man ja nur deshalb eingeführt, weil es viele
> Linien gibt, die hin- und rückwärts nicht die genau gleiche Strecke
> abfahren.

Auch dafür würden Tags (lines:forward, lines:backward) genügen. Mit
"gerichtete ÖPNV-Linien" meine ich die Definition einer
Haltestellenabfolge, die man für potentielles Routing braucht.

Viele Grüße
Stephan





Mehr Informationen über die Mailingliste Talk-de