RoadHog: Datenaufbereitung

Auf dieser Seite beschreibe ich, wie man mit den RoadHog-Tools MapAligner und JourneyMaker seine Daten aufbereitet und wie man mittels des Verifiers die Konsitenz überprüft.

Die XML-Datei für die Karte

Zuerst gilt es, ein Kartenobjekt in XML-Notation zu erzeugen. Dazu verwende man einen gewöhnlichen Texteditor. (Man könnte verschiedene Karten für die einzelnen Reisen verwenden, aber ich habe nur eine für alles. Man erinnere sich an die Kantendefinition auf der Datenstruktur-Seite, dort hat die Kante einen Verweis auf die verwendete Karte.)

<map> <id>mm</id> <filename>/home/maps/16x83-28x94.gif</filename> <draft-filename>/home/maps/16x83-28x94-draft.gif</draft-filename> <width>6000</width> <height>5500</height> <projection>OSGS</projection> <transform>0.05;0.0;0.0;-0.05;-8000.0;47000.0</transform> <square-width>140</square-width> <square-height>140</square-height> </map>

So sieht meine Karten-Datei aus. Sie verweist auf das GIF-Bild mit der Karte (und auch auf eine heruntergerechnete Version, die von meinen Editor-Programmen benutzt wird, um Platz zu sparen - 6000 mal 5500 Pixel sind kein Pappenstiel). Da die "projection" auf "OSGS" gesetzt ist - das "British Grid" - wird die Software alle Längen- und Breitenangaben hierin umrechnen, bevor damit weitergearbeitet wird. Das "British Grid" definiert im wesentlichen einen Nullpunkt im Südwesten des Landes und zählt von da ab die Meter ost- und nordwärts. Das "transform"-Tag legt fest, was mit den errechnen British-Grid-Daten zu tun is; die sechs Zahlen sind die Parameter für eine affine Transformation (siehe java.awt.geom.AffineTransform), und da an der 2. und 3. Stelle eine Null steht, handelt es sich nur um eine Streckung und Verschiebung. Der Wert 0.05 kommt zustande, weil ich ein Kartenpixel pro 20m habe (1/20 = 0.05). Die zweite 0.05 (für die Y-Achse) ist negativ, da die Kartenpixel von oben links gezählt werden, das British Grid aber von unten links. -8000 und 47000 sind der Ursprung meiner Karte - sie fängt 160km östlich und 940km nördlich vom British-Grid-Ursprung an.

Wenn man nicht das British Grid benutzt, kann man die "projection" auch auf "direct" stellen; dann wird die affine Transformation, die durch das "transform"-Tag gegeben ist, direkt auf die Länge und Breite angewendet. Eine solche Transformation sieht dann eher so aus:

Diese krummen Zahlen resultieren von der "Haudrauf"-Methode, mit der sich den GPS-Track mit der Karte in Einklang bringe (bereits auf der Koordinaten-Seite erwähnt). Das Programm, mit dem man diese Werte graphisch ermittelt, ist derzeit nicht in RoadHog eingebaut, kann aber von mir angefordert werden.

Die "square-height" und "square-width" geben an, in wie große Rechtecke der Compiler die Karte zerlegen soll. Es gibt auch noch andere Tags, mit denen man die Karte in verschieden große Rechtecke teilen lassen kann - das habe ich benutzt, bevor ich den "eine Karte für alles"-Ansatz hatte. Da gab es dann für jede Kante eine eigene Karte, und die habe ich dann so aufgeteilt, daß die Bereiche, die sich öfter änderten, weil der rote Punkt hindurchwanderte, kleiner waren als die statischen. In der jetztigen Web-Version sind immer 5 mal 5 Kartenrechtecke zu sehen, und das CGI-Skript sucht automatisch die aus, die um den Ausschnitt mit dem roten Punkt herum liegen. Der sichtbare Kartenausschnitt bewegt sich also mit dem Punkt, und dadurch wird es quasi unmöglich, verschieden große Kartenrechtecke zu verwenden. In der alten Version war die angezeigte Karte aber für jede Kante konstant.

Einpassen der GPS-Koordinaten

Wie schon erwähnt, muß man als nächstes ein paar Korrekturvektoren erzeugen, damit die GPS-Punkte auch da auf der Karte stehen, wo sie hinsollen.

So sieht es aus, wenn man mit dem MapAligner arbeitet. Die grauen Punkte sind die Original-GPS-Daten, die roten Punkte sind diejenigen, die ich mit der Maus angeklickt und verschoben habe, und die schwarzen sind die neuberechneten GPS-Punkte.

java org.remote.roadhog.MapAligner mapfile.xml gpstrack.txt

(vergrößern)

Die grüne Linie ist eine Trennlinie; normalerweise würde die Verschiebung jedes Punktes durch die Verschiebung der nächsten Nachbarn bestimmt, aber diese Linie verhindert "Nachbarschaftsbeziehungen" über sie hinweg. So kann ich dafür sorgen, daß Korrekturen für nahe beieinanderliegende Straßen sich nicht gegenseitig beeinflussen. Trennlinien erzeugt man, indem man mit der Maus auf den gewünschten Anfangspunkt und danach auf den Endpunkt klickt.

Wenn man mit dem zufrieden ist, was man sieht, kann man die Karte abspeichern, und die XML-Datei wird dann um all die Korrekturinformationen angereichert.

Eine Reise erzeugen

Den JourneyMaker braucht man, um

eine Anzahl von Fotos,
eine Kartendatei und
einen GPS-Track

zu einem Journey-Objekt zu kombinieren. (Der JourneyMaker erzeugt auch das passende Edge-Objekt und speichert es in der gleichen Datei, aber oft braucht man das gar nicht, weil man die Kante schon früher erzeugt hat und nur eine neue Reise darauf definieren möchte.)

java org.remote.roadhog.JourneyMaker -v vertices.xml 
   -t gpstrack.txt mapfile.xml

(vergrößern)

Auf diesem Bild sind schon ein paar Fotos geladen worden (das geht im "File"-Menü, einfach mehrere Fotos auf einmal auswählen), und ich habe auch schon eine passende Zeitkorrektur eingestellt. Das mache ich einfach durch Ausprobieren; ich stelle so lange verschiedene Werte ein, bis ein paar Fotos, von denen ich "weiß", wo sie hingehören, am richtigen Platz eingezeichnet werden. Man kann Fotos auswählen, indem man sie in der Liste anklickt, oder indem man mehrere in der Liste markiert und Strg-D ("deselect") oder Strg-S ("select")drückt. Das ist sinnvoll, weil man vielleicht aus der gleichen Gruppe von Fotos mehrere Journey-Objekte erzeugen will. Der JourneyMaker zeigt auch eine Miniversion von jedem Foto an (anklicken für Vollbild) und berechnet die durchschnittliche Helligkeit jedes Bildes (das ist der kleine graue Balken). So kann man schnell sehen, ob einzelne Fotos vielleicht zu hell oder zu dunkel sind, und für diese dann eine Helligkeits- oder Gamma-Korrektur eingeben. Außerdem ist es möglich, die gelben Punkte auf der Karte zu verschieben und so die Position des späteren Positionsmarkers gewaltsam zu ändern, als eine Art letzte Zuflucht bei GPS- oder Kartenfehlern. Wenn man schließlich zufrieden ist, kann man im "Edge Data"-Tab noch einstellen, von wo nach wo die Reise geht, und dann wird das ganze abgespeichert.

Der JourneyMaker kann auch mit einem Vertex-, einem Kanten- und einem Journey-File auf der Befehlszeile aufgerufen werden, dann muß man keinen GPS-Track und keine Fotos importieren, sondern diese Daten werden aus der bereits existierenden Reise geladen. Das kann man benutzen, um früher erstellte Journey-Objekte noch zu verändern.

XML überprüfen

Ich selbst verwende eine Datei mit allen Knoten, eine mit allen Kanten, eine für die Karte, und dann für jede Reise eine eigene Datei. Aber das kann jeder halten, wie er will; wichtig ist nur, daß die Karte und die Knoten definiert sind, bevor die Kanten und Reisen eingelesen werden, die darauf basieren.

Ich habe ein kleines Programm geschrieben, das mir sagt, ob meine Datenmenge insgesamt vernünftig aussieht, oder ob irgendwelche Anomalien vorkommen:

java org.remote.roadhog.Verifier vertices.xml map.xml 
  edges.xml journeys/*.xml

vertex 'Toscaig': connector 'Applecross' has no edges
vertex 'Toscaig' is ISOLATED
vertex 'Longman': connector 'Culcabock' has no edges
vertex 'Drumrunie': connector 'Ledmore' has no edges
edge 'achnasheen-kinlochewe' has no journeys in 
   Achnasheen->Kinlochewe direction
edge 'applecross-tornapress' has no journeys in 
   Applecross->Tornapress direction

Die meisten von diesen Fehlern sind mir natürlich bewußt - hier habe ich zum Beispiel den Knoten "Toscaig" schon eingegeben, aber noch keine Kante dorthin definiert, oder ich habe dem Longman-Roundabout den Anschluß "Culcabock" verpaßt, ohne eine Kante damit zu verbinden. Aber es kann nicht schaden, den Rechner mal sagen zu lassen, was er "seltsam" findet, und dann kann man ja immer noch entscheiden. Der Verifier beschwert sich z.B. auch, wenn man zwei konkurrierende Kanten hat, oder wenn mehrere gleich-gewichtete Reisen auf einer Kante existieren.

Zurück zum Index

[deutsch] [english] [about] [contact]

Frederik Ramm, 2001-05-24