Hallo zusammen, ich möchte euch ein kleines Werkzeug vorstellen, an dem ich zurzeit arbeite: einen Routen-Segment-Viewer mit PHP-basierter Bereinigung von Routen- und Trackdaten.
Testseite:
Der Hintergrund ist meine eigene Navigations-App, die ich gerade entwickle. Beim Laden verschiedener Routen bekam ich teilweise sehr unschöne „Strickmuster“ auf der Karte zu sehen. Ursache war meistens nicht die Karte selbst, sondern dass Routensegmente nicht sauber in der richtigen Reihenfolge oder nicht in der richtigen Richtung aneinanderhingen. Dadurch wurden Punkte verbunden, die eigentlich nicht direkt zusammengehören.
Aus diesem Problem heraus ist die Idee entstanden, die Daten vor der Nutzung in der Navigation noch einmal serverseitig zu prüfen und aufzubereiten. Dafür habe ich eine PHP-Datei entwickelt, die Routensegmente analysiert, sortiert, nach Koordinaten zusammenführt und unnötige oder problematische Punkte reduziert.
Das Werkzeug unterscheidet inzwischen drei Verarbeitungswege:
Variante A – klassische Routendateien und Segmentdaten
Diese Variante ist für Dateien gedacht, die bereits eine erkennbare Routen- oder Segmentstruktur haben. Dazu gehören zum Beispiel:
- OSM-/Overpass-JSON-Dateien
- GPX-Dateien
- KML-Dateien
- GeoJSON-Dateien
- CSV-Dateien mit Koordinaten
- von mir erzeugte Navigations-JSON-Dateien
Hier geht es vor allem darum, vorhandene Segmente korrekt zu sortieren, ihre Richtung zu prüfen und Lücken oder falsche Anschlüsse sichtbar zu machen.
Variante B – aufgezeichnete Tracks aus meinem eigenen Tracker
Bei meinem Routentracker entsteht teilweise ein einzelnes sehr langes Segment mit vielen Trackpunkten. In einer Testdatei waren es zum Beispiel über 3353 Trackpunkte. Für meine Navigation ist das zu viel, weil auf dem Handy dadurch unnötig viele Berechnungen laufen und Akku verbraucht wird.
Diese Variante verarbeitet deshalb einen langen Track anders: Der Track bleibt grundsätzlich in seiner ursprünglichen Fahrtrichtung erhalten, wird aber von beiden Seiten zur Mitte hin analysiert. Ziel ist, den Track in sinnvolle Segmente zu zerlegen und die Punktzahl deutlich zu reduzieren, ohne den Verlauf unnötig zu verfälschen.
Variante C – unspezifische JSON-Dateien mit versteckten Koordinaten
Zusätzlich gibt es eine dritte Variante für JSON-Dateien, die eigentlich gar keine klassische Routendatei sind. Das können zum Beispiel Logdateien sein, in denen irgendwo verschachtelt latitude/longitude oder lat/lon vorkommen.
Diese Koordinaten werden der Reihenfolge nach herausgefiltert, intern in eine GPX-ähnliche Trackspur umgewandelt und danach wie Variante B weiterverarbeitet. So kann man auch aus unspezifischen Logdateien testweise eine Route erzeugen.
Im Viewer kann man sich anschließend ansehen:
- wie viele Segmente entstanden sind,
- wo Start und Ende liegen,
- ob Segmentanschlüsse Lücken haben,
- ob Punkte verdächtig weit auseinander liegen,
- ob eine Route durch die Bereinigung plausibler geworden ist.
Mir ist bewusst, dass so eine automatische Bereinigung nicht immer „wissen“ kann, was tatsächlich gemeint war. Das Werkzeug soll deshalb nicht blind OSM-Daten verändern oder automatisch Korrekturen zurückschreiben. Es ist zunächst ein Prüf- und Aufbereitungswerkzeug für eigene Navigationsdaten und Testdateien.
Mich würde interessieren:
- Haltet ihr diesen Ansatz für sinnvoll?
- Welche Fälle würdet ihr bei GPX/GeoJSON/KML besonders kritisch sehen?
- Gibt es typische Situationen, bei denen Segment-Reihenfolge oder Segment-Richtung besonders oft Probleme verursachen?
- Welche Schwellenwerte wären aus eurer Sicht sinnvoll, um echte Lücken von normalen Kreuzungsabständen zu unterscheiden?
Mir geht es ausdrücklich nicht darum, OSM-Daten automatisch zu verändern, sondern darum, Routen und Trackdaten vor der Nutzung in einer Navigations-App besser prüfen und aufbereiten zu können.
Gruß Lutz (gabischatz)