Am 02.04.2012 10:54, schrieb Martin Koppenhoefer:
Am 2. April 2012 03:13 schrieb Stephan Wolff<s.wo...@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
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
