

shape2kml
und laufen auf dem Mac in der XP-Emulation. Daten finden sich beispielsweise bei ¬DIVA-GIS unter dem Stichwort Country shape files. 
Die Karte mit den Ländern ist einfach nur eine eine kurze Fleißübung. Jetzt sollten sich die Länder ein- und ausschalten lassen. Es gibt tatsächlich eine ¬PHP-Klasse, die vorgibt, den Googlealgorithmus nachzuempfinden. OK, es klappt grundsätzlich – dauert eben nur „ewiglich“
Die erste Beschleunigung besteht in der Zwischenspeicherung der Kurven. Diese Maßnahme reduziert die Laufzeit enorm. Jetzt muss der Klumpatsch nur noch geholt (800kiB – das ist nicht wirklich viel) und gerendert werden. Letzteres dauert auf dem Brauser immerhin ca. 3 Sekunden. Und da kommt das Web2.0β-Warterädchen …
Das waren Überlegungen zu Firefox und Freunden. Im Explorer 6.0 läuft die Karte zwar auch, braucht aber wirklich lange. In einer der letzten c'ts war ein Browsergeschwindigkeitstest abgehandelt. Der Explorer braucht teilweise die zehnfache Renderingzeit – insbesondere, wenn er solche „unanständigen“ wie DOM-Manipulation machen soll.
Die bilderlosen Wegstrecken (bei Bramfeld, Berne und Volksdorf) erklären sich einfach dadurch, dass die sich Fuji nach längerer Nichtbenutzung selbst ausschaltet und man das beim Radfahren mit festangeschnallter Kamera nicht mitbekommt.
Es gibt immer wieder neue Herausforderungen. Zuerst gibt es ein kleines Problemchen mit der Datenverarbeitung: die Navi speichert aus ökonomischen Gründen nur die Standpunkte im Track, bei denen sich die Richtung ändert. Die Knipse hat natürlich zu anderen Zeitpunkten ihren Bildspeicher gefüllt. Es gibt also zwei völlig asynchrone Zeitleisten. Gut – mit der unzulässigen Annahme, dass zwischen den Richtungswechseln gleichmäßig geradelt wurde, lässt sich der Standort des Photos rekonstruieren. Stichwort Dreisatz.
Das zweite Problem ist ein Bug(?) in den Google-Maps. Zoomt man ran, dann kommt aber einer gewissen Vergrößerung der Fehler:
Unerwarteter Wert NaNpx beim Parsen des Attributs height.
. Verkürzt man testhalber radikal die Anzahl der Polylinestützpunkte, dann tritt das Problem nicht auf. Also offenbar knallt es in der Google-Software, wenn sehr viele (1000) Punkte der Polyline außerhalb der Sicht sind. Um das Problem zu lösen, müsste man nach jeden Zoom und jeder Bewegung in der Karte den Track in Teilen neu zeichnen lassen. Das gleiche Problem tritt übrigens auch bei GPolygon()
auf. Die Lösung: diese Polygone sind sehr speicherhungrig. Deshalb gibt es diese kodierten Linien, die dann enger mit der API sprechen. ¬Professor Mark McClure von der Uni in Ashevill hat ein kleines ¬Werkzeug gebaut, mit dem es ganz einfach ist, aus Punktlisten diesen Speziacode zu bauen. Danke!