Geocaching.com stellt ja auf ihrer Seite ein KML-File zur Verfügung, mit dem in Google Earth dynamisch die im aktuellen Bildausschnitt zu sehenden Geocaches eingeblendet werden. Besonders praktisch daran ist, dass für jeden Cache-Typ ein separates Icon benutzt wird. Seit Google im Juni 2006 die neue Version 4 von Google Earth zum Download bereitgestellt hat, gibt es mit dieser nun das Problem, dass für alle Cache-Typen das gleiche Standard-Icon (ein gelber Pin) dargestellt wird. Dies hat natürlich bereits eifrige Diskussionen in den Foren ausgelöst (z.B. hier im grünen Forum).

Nun sieht es so aus, dass da eine Lösung in Sicht kommt. Im blauen Forum findet sich zu dem Problem der folgende Beitrag von Jens:

I also faced the problem and tried a fix as workaround by fixing the XML file. It seems that changing the header from version 2.0 to 2.1 is enough to bring the icons up again (even though the specification says that the icons are defined deprecated…).

To fix it until it is updated at geocaching.com I implemented a small filter proxy which does the dirty conversion job.

If you go to your Google Earth client and just replace the KML URL in the properties of the Geocahing link it is working.

Original URL:
http://api.Groundspeak.com/networkkml/geocache.aspx?key=
XYZ

Updated URL which enables Icons again:
http://www.jensscheffler.de/share/geocaching.php?key=XYZ

Also einfach die von Geocaching.com geladene ‘GeocachingNetworkKML.kml‘ editieren und im unteren Abschnitt unter <href> in der URL den Teil

api.Groundspeak.com/networkkml/geocache.aspx

durch

www.jensscheffler.de/share/geocaching.php

ersetzen und dieses geänderte KML-File neu in Google Earth laden. Was soll ich sagen? Der “Workaround” funzt prima! Dann müsste das ganze jetzt also nur noch auf dem offiziellen GC.com Server eingebaut werden…

Doch dann kamen einen paar Fragen auf… Bei mir: Was steckt eigentlich dahinter? Und im grünen Forum: Wie lange wird es dauern bis zu einer offiziellen Lösung? Und: Was ist gemeint mit “the icons are defined deprecated“? Also habe ich mir das ganze mal näher angeschaut…

Es sieht so aus, dass nicht die Icons grundsätzlich in KML 2.1 “mißbilligt” (deprecated) werden, sondern die Art und Weise, wie sie im GC.com-KML definiert werden. Ohne das hier zu sehr in die Länge ziehen zu wollen, geht es darum, dass nach KML 2.1 zuerst ein paar <style>-Tags (inkl. Icons) definiert werden sollen, die dann jedem einzelnen <placemark> (also den Orten) zugewiesen werden können. GC.com definiert aber für jeden <placemark> (jeden Cache) einen eigenen <style>. Das wird in der KML2.1-Spec “mißbilligt”.

Allerdings scheint es trotzdem zu funktionieren, solange im KML-Header als benutzte KML-Version die 2.1 angegeben wird. Der GC.com-Server schickt aber Files mit der Versionsnummer 2.0, und da werden von Google Earth 4 nun offenbar alle Icons einfach ignoriert…

Der Workaround von Jens macht nun nichts anderes, als dass er sich als Proxy zwischen den GC.com-Server und Google Earth 4 setzt und in allen Daten, die GC.com an Google Earth schickt, aus dem Versions-Eintrag ‘2.0′ im jeweiligen Header eine ‘2.1′ macht.

Somit ergeben sich ein paar Schlussfolgerungen:

Grundsätzlich funktionieren Icons mit Google Earth 4! Auch unterschiedliche Icons für unterschiedliche Objekte. Sie müssen nur “sauber” definiert sein. Opencaching.de hat übrigens keine Probleme mit den bunten Kringeln ihres KML-Files.

Der Workaround funktioniert zwar super, fällt aber in die Kategorie “Quick-And-Dirty”. (Womit ich in keinster Weise Jens zu nahe treten will, der ganz im Gegenteil eine klasse Lösung gefunden hat.) Das heißt, das KML-File wird mit einer kleinen Änderung wieder “gangbar” gemacht, allerdings wurde an der eigentlichen Spec-Verletzung nichts geändert. Es kann also durchaus sein, dass das mit einer späteren Version von Google Earth nicht mehr funktioniert, weil das KML eigentlich nicht Spec-konform ist.

Eine Änderung bei GC.com gemäß Jens’ Workaround wäre ein Klacks, es muss sich nur jemand hinsetzen, und bei jeder Anfrage aus der 0 eine 1 machen…

Besser wäre natürlich, die Skripte bei GC.com so zu ändern, dass sie (wieder) Spec-konforme KML-Files erzeugen. Das ist sicherlich ein bißchen Arbeit, sollte aber machbar sein.

Auf mich macht es den Eindruck, dass der zuständige Entwickler bei GC.com (”Raine”) im blauen Forum mit diskutiert. Hoffen wir also das beste für die Umsetzung…

Wie schnell uns GC.com da eine Lösung liefern wird, wage ich allerdings nicht zu mutmaßen..

So, und wen’s nach so viel Text noch interessiert: Hier gibt’s sozusagen den “Tag des Anstoßes” nachzulesen (siehe unter <style>): Spec zu KML 2.1.