Jeder hat so seine Sammelwut. Auf Xing sollen schon Menschen gesichtet worden sein, die über 700 bestätigte Kontakte haben. AADS? Auf jeden Fall ist dieses Netzwerkportal eine gute Möglichkeit, seine Arbeitszeit im Kontor auf angenehme Weise zu verkürzen oder einfach nur sein Mütchen zu kühlen.

Es kommt immer wieder vor, dass Kunden auf einer Welt- oder Europakarte irgend etwas darstellen wollen. Und zuerst soll der geneigte User das Land vorwählen. Also braucht es KML-Daten von der politischen Ländergrenzen. Trotz moderner Suchmaschinen ist das nicht ganz trivial. Nach längere Recherche stellt sich ein gewisser Lernprozess ein. Es gibt schon freie Daten – nur sind die in dem Shape-Format. OK, da gibt es Umwandlungsprogramme. Die heißen so etwa shape2kml und laufen auf dem Mac in der XP-Emulation. Daten finden sich beispielsweise bei ¬DIVA-GIS unter dem Stichwort Country shape files.

Nach erfolgreicher Wandlung mit obiger Software sind die ¬Karten dann erstmal roh verfügbar. Alle Länder dieser schönen Welt als Kurvendaten – das geht natürlich nicht unter drei ¬Megabyte. Superplietsch wäre es, wenn man schon auf der Serverseite aus den Zifferkolonnen in dem JSON dieses komprimierte Format, wie es die Google-Gmap-API kennt, baut.

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.

Montag: das ist der Tag, an dem das Wochenendvergnügen ausgewertet wird. Man gönnt sich ja sonst nichts …


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!