Am 2. April 2012 03:13 schrieb Stephan Wolff <[email protected]>: > 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 (verschiedene Varianten in einer Relation sollte man allerdings ausgliedern) > Die Straßensegmente sind (teilweise falsch) mit > "role"-Tag "forward"/"backward", manchmal mit "route", "default", > "alternate" etc. versehen. "stop_position"- und "platform"-Punkte > haben "role"-Tags "", "stop", "platform" aber auch "stop:22" oder > "platform:60:alternate:1". Die Haltestellen sind teils zwischen > den ways, oft auch unsortiert am Ende. auch hier gibt es doch durch die unterschiedlichen Mapping-Varianten nicht grundsätzlich ein Problem, Fehler wie falsche Rollen sollte man natürlich korrigieren. > "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. > "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, so wollen manche Mapper heute auch noch zusätzlich festhalten, dass dort jeder zweite Bus ein Bus mit erhöhter Kapazität ist, mit einem durchschnittlichen Fahrzeugsalter von 3.4 Jahren, Behindertenrampe an Bord, und statistischer Verspätung von 1.2 Minuten um die Mittagszeit an Haltestelle XY (mal etwas übertrieben dargestellt). > Viele Relationen sind durch spätere Bearbeitung der ways beschädigt. kann man schnell richten, wenn man weiss, wo der Bus langfährt. Üblicherweise kenne ich das von Stellen, die zunächst noch grob gemappt waren (also z.B. nur ein Way trotz mehrerer Fahrbahnen), wo aber schonmal jemand eine Buslinie draufgelegt hat. Danach hat beim Aufsplitten der Richtungen jemand nicht aufgepasst. > Die Daten reichen aus, um eine Karte mit Liniennummern an Straßen und > Haltestellen zu erzeugen. Unsortierte Relationselemente, unsinnige > "role"-Angaben und kleine Lücken erzeugen allenfalls kleine > Kartenfehler, die der menschliche Betrachter meist ignorieren kann. stimmt. Wahrscheinlich könnte man mit nicht zu großem Aufwand auch automatische Auswertungen soweit fehlertolerant gestalten, dass sie z.B. kleine Lücken ohne menschliche Intervention schließen können oder unsinnige Role-Angaben ignorieren. Relationselemente zu sortieren ist normalerweise trivial. > 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 > Selbst wenn eine Relationen eine unverzweigte Strecke abbildet und > keine Fehler hat, kann man die Angaben nicht zur Fahrtplanung nutzen, > da keine Informationen zu Betriebszeiten, Takt oder Fahrzeiten bietet. > Viele gedruckte Reiseführer enthalten dagegen grobe Informationen wie > "bis <Ziel> ca. 70 Min., Mo-Sa 6-22Uhr, So 8-20Uhr, tagsüber alle 15 > Minuten, nach 18Uhr alle 30 Min.", die auch Jahre nach dem Druckdatum > noch nützlich sind. Solche Informationen wären auch in OSM möglich. +1, wenn der Mapper es für sinnvoll hält, dann sollte er durchaus diese Dinge eintragen können, wobei sich das je nach Gegend auch schnell und häufig ändern kann, so dass jahrealte Informationen prinzipiell mit Vorsicht zu genießen sind. In meinem Umfeld hier gibt es z.B. gar keine Fahrpläne (für Busse tagsüber), sondern nur Informationen wie von Dir genannt (d.h. z.B. "Bus verkehrt Mo-Fr von 6:00-24:00h", jeweils Abfahrt Starthaltestelle). > 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. > Wenn man etwas an Relationen geändert hat, ist immer ein Konflikt beim > Upload möglich, der von vielen Mappern nicht korrekt gelöst werden kann. die Konflikte treten viel eher bei den anderen Route-Relationen auf, die sich oft übers ganze Land oder sogar international durch die Landschaft ziehen (Fernstraßen, Fernwanderwege, etc.). Bei einer normalen Buslinie sollte das nicht allzu oft vorkommen. Klar, je mehr Leute editieren, und je größer ein Objekt ist, um so eher kommt es auch zu Konflikten. > Die Qualität der ÖPNV-Relationen hat sich nach meiner Einschätzung in > den letzten zwei Jahren nicht gebessert. Das kommt sicher darauf an, wo man mappt. Hier ist der Fortschritt unglaublich groß verglichen zum Stand vor 2 Jahren. > - ein Bot, der jede Nacht die unterbrochenen Relationen repariert, die > "role"-Tags richtig setzt und nicht automatisch korrigierbare Relationen > meldet (auch sehr schwierig umzusetzen). Die Mapper könnten unbelastet > editieren :-) könnte man machen, wobei ich automatischen Edits ziemlich kritisch gegenüberstehe: oft ist es besser, einen offenkundigen Fehler in den Daten zu haben (weil den irgendwann jemand reparieren wird), als automatisch etwas hinzuraten, was dann nicht mehr auffällt, aber falsch ist. > Beide Varianten wären mit einer Vereinheitlichung des Relationsschemas > auf das vom Programm unterstützte Format verbunden. > - 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) . > 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. AFAIK sind getrennte Relationen für hin- und rück die beste Lösung, um komplizierte Relationen zu vermeiden. Gruß Martin _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
