200-300 geografische Punkte mittels Google maps API in eine Map zu laden, ist die Standardaufgabe bei jeder Google Maps integration und stellt keine besondere Herausforderung mehr dar: Sämtliche Punkte bzw. Markers können initial mit addOverlays() geladen werden. Verschiebt der Benutzer den Kartensausschnitt oder Zoomt er aus, sind sämtliche Markers bereits im Hintergrund vorhanden und werden sofort dargestellt. Dies funktioniert soweit gut und stabil für eine fixe und kleine Anzahl Markers, wie z.B. bei dieser Verkehrsunfall-Map.
Was aber, wenn nun die Anzahl Marker grösser ist, z.B. für den Fall dass man sämtliche Ortschaften der Schweiz mit einem Marker versehen möchte oder Artikel von eBay oder ricardo auf einer Map positionieren möchte. Hierfür können die Marker nicht mehr alle auf einmal initial geladen werden – die Ladezeit wäre einerseits zu lange, anderseits funktioniert Google Map ab 400-500 geladenen Markers derart langsam (Maus blockiert bis hin zu Browerabsturz), dass es kaum mehr usable ist. Die Lösung hierfür heisst dynamisches Laden der Markers entsprechend dem angezeigten Kartenausschnitt. Ist für die Marker-Daten eine XML-Schnittstelle verfügbar, welche als Parameter die Eckpunkte des angezeigten Kartenausschnitts entgegennimmt, ist auch dies relativ einfach zu realisieren. Das AJAX-konforme Laden der Marker funktioniert dann durch Übergabe eines URL-Strings an das Google Maps Objekt GDownloadUrl, z.B:
strFeedUrl = http://www.mydomain.com/api.xml?sw= “ + map.getBounds().getSouthWest() + “&ne= + map.getBounds().getNorthEast();
Soweit so einfach – und wahrscheinlich auch schon in zig Google maps so gelöst. Die grössere Herausforderung kommt aber noch: Das Nachladen von Markers sobald der Benutzer den Kartenausschnitt verschiebt oder auszoomt. Da vorhin ja nur die Markers innerhalb des Kartenausschnitts geladen wurden, sind beim Verschieben Teile des neuen Kartenausschnitts noch Marker-los. Um diese wiederum dynamisch nachzuladen, haben wir uns folgende Ansätze angeschaut:
1. Überschreiben: Das einfachste ist, die Markers einfach innerhalb des neuen Kartenausschnitts mit addOverlays() dazuzufügen. Falls der Kartenausschnitt bereits Markers enthielt (vom vorhergehenden Ausschnitt), werden von Google Maps an den identischen Stellen zusätzlicher Marker über die bestelhenden positioniert. Visuell stellen diese übereinander gelegten Markers kein Problem dar und erscheinen als ein Marker (ausser dass der Schatten immer dunkler wird…). Jedoch summiert sich die Anzahl der Markers so sehr schnell, dass die Karte wieder nach einigen Verschiebungen kaum benutzbar wird (z.B. bei 50 Markers auf einem Ausschnitt sind nach 10 Verschiebungen effektiv schon ca. 500 der Map hinzugefügt).
2. Verzögertes Laden: O’Reilly schlägt in Google Maps Hacks (übrigens empfehlenswert) bei grösseren Mengen Markers vor, diese nicht umgehend beim Verschieben nachzuladen, sondern das Laden der Markers zeitverzögert zur letzten Kartenverschiebung zu laden (z.B. 2 Sekunden mittels setTimeout() verzögert). Dies ist sehr hilfreich, wenn der Benutzer mehrfach hintereinander kleine Verschiebungen des Ausschnitts macht, löst aber das Grundproblem der sich addierenden Anzahl Markers eigentlich nicht.
3. Löschen und neu Laden: Die bei Google Maps Implementationen meist gesehene Lösung ist, nach jedem Verschieben und Zoomen sämtliche Markers mit clearOverlays() zu löschen und jene des aktuellen Kartenausschnitts neu zu zeichnen. Dies funktioniert zwar stabil (z.B. auf Smagoo), ist aber aus folgenden Gründen suboptimal: a) Bereits geladene Markers zeigen ein kurzes Flackern, da sie zuerst entfernt und dann wieder angezeigt werden. b) Das Datenvolumen, welches im Hintergrund transferiert wird, ist grösser (da immer wieder sämtliche Punkte des Ausschnitts geladen werden) – für den Benutzer tritt eine spürbare Ladeverzögerung auf. c) Verschiebt der Benutzer einen Ausschnitt wieder zurück auf einen Bereich, der bereits vorhin geladen war, sind die ursprünglichen Markers weg und werden nur zeitverzögert wieder nachgeladen.
4. Markers mit ID: Wenn jeder Marker mit einer ID versehen wird, kann beim Nachladen von Markers überprüft werden, ob dieser auf der map noch fehlt – und nur dann der Map hinzugefügt werden. Dies dürfte einfach funktionieren, wenn die IDs ein drei- oder maximal vierstelliger Integerwert sind, so dass z.B. direkt mit arrLoaded[intId] == true ? überprüft oder gesetzt werden kann, ob der Marker geladen ist. Ist keine solche ID vorhanden (wie z.B. bei velyoo für eBay-Arikeln, wo die ID eine zwölfstellige Zahl ist) muss die performance-aufwändiger durch loopen des Arrays gelöst werden, was ebenfalls bei grösseren Markerzahlen unpraktikabel wird: Um in einem Loop 500 geladene Artikel mit 100 neuen zu vergleichen sind bis zu 50'000 Iterationen notwendig.
5. Nachladen des Kartenausschnitt-Deltas: Für velyoo haben wir schlussendlich diese – aus meiner Sicht optimale Variante – entwickelt. Dabei wird beim Verschieben der Karte die Differenz der beiden Flächen vor dem Verschieben und nach dem Verschieben (oder Zoomen) ermittelt. Die Fläche ist in folgender Grafik gelb dargestellt:
Dieses Delta lässt sich wiederum in drei Rechtecke (bzw. bei Zoom vier) unterteilen, welche einfach analog dem gesamten Kartenausschnitt geladen werden können. Eine neue Schwierigkeit tut sich allerdings auf, weil man so die bereits geladenen Kartenausschnitte über mehrere Verschiebungen hinweg speichern muss. Je nach Richtung der Verschiebung können dabei Flächen entstehen, welche die Speicherung der geladenen Markers bzw. Berechnung der zu ladenden Markers sehr schwierig wird. Folgende Illustration soll diese Schwierigkeit aufzeigen (grau = geladene Ausschnitte, weiss = ungeladen, gelb = für aktuellen Ausschnitt nachzuladen):
Rein programmiertechnisch wär die Speicherung und Berechnung zwar möglich, wesentlich einfache ist allerdings folgende Näherungslösung, welche den Zweck ebenfalls erfüllt: Anstatt das exakte Delta von Kartenausschnitten zu laden, wird das Delta so vergrössert, dass wiederum ein einfach speicherbares Rechteck entsteht. Dadurch werden zwar etwas mehr Bereiche als gerade benötigt in die Karte geladen. Bei einem üblichen Verschiebevorgang, der sich rund um den Initialpunkt bewegt, sind die zusätzlichen Daten jedoch meist geringfügig, die dadurch verursachte Ladeverzögerung vernachlässigbar.
(grau = geladene Daten, rot = neuer Kartenausschnitt, gelb = zu ladende Daten in der Vereinfachung). Dieser Mechanismus ist bei velyoo z.B. unter im Bike Marktplatz implementiert. Javascript-Funktionen, in welchen obige Erläuterungen umgesetzt sind, finden sich unter http://www.velyoo.com/res/mapHelpers.js.