ich betreibe seit einigen Jahren eine Seite auf der u.a. MTB und Langlauf Relationen aus OSM visualisiert werden (xctrails.org). Dabei ergibt sich immer wieder das Problem, dass Relationen “kaputt gehen”, sprich irgendjemand editiert und produziert Unterbrechungen in Relationen die ursprünglich entweder ein Kreis oder Graph waren… Ich hab das mal auf http://www.xctrails.org/relAnalyze/index.html visualisiert - sind jede Menge.
Der OSM Relation Analyzer liefert dafür in einigen Fällen eine “angeblich” lückenlose Relation - was aber m.E. in vielen Fällen für den tatsächlichen Gebrauch falsch ist weil durch die algorithmische Herangehensweise die ways “nur” so zusammen gewürfelt werden das es passt - was aber nicht zwangsläufig der Realität entspricht. (Beispiel “zick-zack” Relation in der dann einige Ways hin und her gehen um Lücken zu schließen und damit die gesamt Relation faktisch verlängern).
Wenn ich nun auf Basis einer derartigen Relation z.B. ein Höhenprofil anzeigen will, dann führt dieser Ansatz logischerweise zu Problemen.
In meiner näheren Umgebung versuche ich immer mal wieder Relationen zu fixen, aber auf Dauer wird das ermüdend und das ist ja auch nur ein Tropfen auf dem heißen Stein. Da ich mir vorstellen könnte, dass auch andere Dienste Relationen auswerten, würde mich mal interessieren wie zu dem Thema so die Meinungen sind… Bzw. wie könnte man Relationen langfristig stabiler machen?
Vorschlag für die von Mappern beschädigten Routen:
a) Du erstellst Dir einen lokalen Speicher für Routen und den Speicher stellst Du auf der Karte dar.
b) Wenn Du in OSM Routen feststellst (z.B. anhand der ID), die noch nicht im lokalen Speichert vorhanden sind, so übernimmst Du diese automatisch in Deinen lokalen Speicher (z.B. Prüfung auf Routen alle 2 Wochen)
c) Wenn Mapper eine bereits bei Dir im lokalen Speicher befindliche Route ändern, bleibt der lokale Speicher unverändert.
d) Ein Mapper kann bei Deiner Karte pro einzelner Route die Übernahme des aktuellen OSM-Stands in Deinen lokalen Speicher bewusst anstoßen. Damit kann er gewußte Verbesserungen übernehmen.
Ist eh so realisiert, da läuft ein eigener Overpass Server.
Ich denk mal d’rüber nach… Das würde verhindern, dass korrekte Relationen nachträglich kaputt gehen, verhindert aber nicht, dass von vorne herein “schlechte” Relationen in’s System gelangen. Und updates würden dann nur noch in mein System gelangen wenn man das manuell triggert - dazu hab ich zu wenig Nutzer glaube ich…
Aber tatsächliche Verbesserungen bekomm ich dann auch nicht mehr mit. Naja, ich könnte beim Update prüfen ob eine bereits vorhandene und kaputte Relation geschlossen wurde und nur dann aktualisieren…
Bin mir aber nicht sicher ob der Ansatz die Qualität insgesamt verbessert…
Wenn es in der Realität so ist, dann ist es so, klar. Vielleicht ist es aber auch so, dass die existierenden Editor Clients besser prüfen müssten und entsprechend warnen müssten…
Ergänzung zu c)
c.1) Wenn eine Route einen einzelnen, geschlossen Linienzug ergibt, so wäre zu überlegen, die Route dann automatisch (beim Deinem nächsten DB-Update) im lokalen Speicher zu aktualisieren, da es ein besonderer Zufall wäre, dass eine fehlerhafte Route einen einzelnen geschlossenen Linienzug ergibt.
Das wird immer ein Problem bleiben. Ich denke, dass wenn Routen von Profis erstellt werden, dann sind diese die ersten Tage/Wochen noch am ehesten korrekt, d.h. dann in den lokalen Speicher und nur dann aktualisieren, wenn es manuell angetriggert wird oder c.1) zutrifft.
Neue, fehlerhafte Anfängerrouten bleiben immer Schrott, bis sie jemand repariert und den Zeitpunkt wirst Du automatisiert kaum mitbekommen (es sei denn, es entsteht ein einzelner, geschlossener Linienzug => c.1)
Auch würde ich b) etwas abändern:
b) Wenn Du in OSM Routen feststellst (z.B. anhand der ID), die noch nicht im lokalen Speichert vorhanden sind, so übernimmst Du diese automatisch in Deinen lokalen Speicher, wenn diese mind. 1 Woche in der OSM-DB waren (Der Mapper braucht ja etwas Zeit zum Eintragen).
mit Relationen für Routen wirst du immer Probleme bekommen, da diese nicht so einfach auf Richtigkeit zu prüfen sind.
Ich hab es bei “meinen” Grenzen einfacher, da das immer korrekte geometrische Objekte sein müssen; da hilft mir PostGIS extem weiter. Dafür habe ich eine lokale PostGIS-Tabelle mit “richtigen” Grenzen und vergleiche diese jede Nacht mit allen geänderten auf Fehler.
Das dürfe dich aber nicht viel weiterbringen.
Tolle Ratschläge kann ich dir auch nicht geben, da mir dein techisches Umfeld nicht bekannt ist. Bei meinem Umfeld (PostgreSQL-Datenbank mit PostGIS, kontinuierliches Einspielen von Diffs) würde ich mir “einfach” einen Trigger (ja, Trigger im SQL-Umfeld) definieren, der beim Update einer Route (Relation mit type=route) aktiv wird und einige Basis-Checks macht.
Checks könnten z.B. Änderung der Anzahl der Member, Anzahl der Strecken (verkettet Liste alle Member, die aneinander hängen), Längen der Strecken, geänderte Tags und ähnliches sein. Alles was halt eine Route ausmacht. Und wenn sich da irgendwas geändert haben sollte, musst du halt nachsehen - aber nur dann.
Wenn z.B. eine Route immer aus einer einzigen Strecke bestand (#member=20, #strecken=1) und das plötzlich nur noch 19 Member und 2 Strecken sind, hat die Route jetzt wohl eine Lücke. Dagegen ist bei 21 Membern und einer Strecke mit der alten Länge wohl nur ein Weg gesplittet worden.
Potential zur Verbesserung der Routen-Relationen steckt in den Editoren (Meckern wenn man eine Route trennt), den Usern und vor allem den Qualitätssicherheit-Tools. Bei geschlossenen Routen gibt es das Tag roundtrip=yes, so dass auch eine geschlossene Route mit nur einer Unterbrechung erkannt werden kann.
Wenn es ein QS-Tool gäbe, bei dem die Routen und deren Fehler dargestellt werden, helfen sicher viele, diese Fehler zu verbessern. Könnte so ähnlich sein, wie beim OSMI (von der Geofabrik) mit den Multipolygonfehler.
Für einen qualitativ besseren Gesamtdatensatz bringen solche Korrekturen viel mehr bzw. nur etwas, wenn die Routen “erkannt” und “verbesser” werden können. Wenn jeder sein eigenes Süppchen kocht, wird dadurch OSM nicht besser, und jeder muss die selbe Arbeit doppelt und dreifach ausführen.
Wenn es eine gute Visualisierung gäbe, hätte ich bestimmt 200 Routenfehler eliminiert
Das hat mich bisher auch davon abgehalten eine Lösung zu implementieren die auf Datenredundanz (siehe oben) basiert…
Wie müsste die denn aussehen? http://www.xctrails.org/relAnalyze/index.html ist ein erster Versuch mal einen Überblick über problematische MTB und Langlauf Relationen zu bekommen… ich linke dann momentan nur weiter auf http://ra.osmsurround.org/analyzeRelation (wobei dieser Analyzer wie gesagt manche Relationen als ok betrachtet die es eigentlich nicht sind)
Über wambacher’s Vorschlag werd ich auch mal nachdenken, danke. (Im Hintergrund läuft bei mir auch eine PgSql DB mit allen MTB und XC Relationen, zur Anzeige auf der Karte kommen die Daten dann aber hauptsächlich aus einem lokalen Overpass).
Praktisch täglich: planet.osm per osmupdate aktualisieren, mit osmfilter die benötigten rels/ways/nodes extrahieren und per pgsnapshot_load laden in XC, MTB etc. DBs laden. (parallel dazu entstehen noch die respektiven overpass und routing DBs).
Die Analyse welche wiederum die DB für http://www.xctrails.org/relAnalyze/index.html erstellt (also mein simpel Algorithmus zum Erkennen von Löchern) ist in Java implementiert, greift aber direkt auf die per pgsnapshot_load erzeugten DBs zu.
Ich stell mir das mit einer Visualisierung der Route vor. So ähnlich wie hier. Dann kann man an der Seite Bus-, Rad-, Ski-, Auto-, Straßen- und Wanderrouten selektieren, sonst wirds zu unübersichtlich. Aber im Grunde funktioniert dein Analysierer auch schon gut, kannte ich vorher noch nicht. Daumen hoch
Danke für das schöne Werkzeug!
Habe eben die Königsheide-Loipe, die Saubad-Loipe und die Loipe Pfaben-Pechbrunn bearbeitet.
Die Fehler, die sich dort eingeschlichen hatten, scheinen dadurch entstanden zu sein, daß Wege verbunden wurden. Tja, an manchen Stellen verläuft die Loipe über die Wiese oder quer durch den Wald (ohne track darunter) und dann muß man den track an der Stelle teilen, wo die Loipe abzweigt. Das ist nicht unbedingt so leicht für jeden erkennbar…
Ein weiteres Problem ergibt sich beim Neuerfassen in einem bisher nicht gemappten Loipengebiet. Da ich gewöhnlich die Loipen ablaufe, wie es mir gerade in den Sinn kommt, kann ich häufig nicht zuordnen, welcher Abschnitt zu welcher Loipe gehört. Und wenn noch gar nix erfaßt ist, mache ich einfach eine neue Relation auf, um diese Elemente zu sammeln (und hoffe, daß irgendwann mal ein Ortskundiger diese Teile in neue Relationen einfügt), z.B. bei Marienbad / Marianske Lazne.
Dafür habe ich eine lokale PostGIS-Tabelle mit “richtigen” Grenzen und vergleiche diese jede Nacht mit allen geänderten auf Fehler.