Programmableweb.com ist die Adresse im Internet, um sich einen Überblick über die verschiedenen Mashups im Web sowie integrierbare APIs zu verschaffen. Derzeit sind dort über 900, vor allem amerikanische Mashups verzeichnet - und für interessierte unbedingt empfehlenswert. velyoo.com wurde kürzlich dort aufgenommen und mit fünf Sternen bewertet - thank you guys.

In regelmässigen Abständen platziert der IT Marktforschungs-Spezialist Gartner aufkommende Technologien auf einem sogenannten Hype Cycle. Idee dahinter ist, dass eine Technologie x-Jahre nach einem ersten Hype zu einer beständigen Technologie wird (Bsp. Bluetooth-Hype Ende der Neunziger, 4-5 Jahre später als Standardtechnologie in praktisch jedem Handy vertreten). Interessanterweise rangieren auf dem eben kürzlich publizierten, aktuellen Hype Cycle von Gartner Mashups ganz oben auf dem Peak des Cycles. Es kann demzufolge nur noch ein paar Jahre gehen, bis man Mashups wirklich brauchen kann

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.

velyoo verfügt seit kurzem nun ebenfalls über eine Artikeldarstellung mit Google maps. Bei ebay.ch oder ricardo.ch eingestellte Artikel zu bestimmten Themengebieten werden dabei aggregiert auf einer Karte dargestellt und ermöglichen so das lokale Auffinden von Marktplatzartikeln. Dies soll sich insbesondere für solche Artikel von Nutzen sein, welche typischerweise in der Region gekauft werden (bzw. nicht per Post versandt werden können), also z.B. Autos, Motorräder, Fahrräder etc.

Details zur Implementation von Google maps demnächst in diesem blog.

Praktisch jede Unternehmenswebsite hat irgendwo eine statische Anfahrtsskizze zu den Niederlassungen untergebracht (z.B. hier, hier oder hier). Das ist unbestritten eine nützliche Sache und unterstützt den Benutzer in dem spezifischen Task, das Unternehmen lokal aufzufinden. So wirklich brauchen kann man die Skizzen meist aber nur, wenn man die Region und Anfahrtswege schon kennt. Oder wer würde sich mit einer solchen Skizze ins Auto setzen und von Bern mal Richtung Zürich fahren? Der übliche Prozess lautet dann, einen Kartendienst wie map24.ch aufzusuchen, und den Anfahrtsweg (bzw. die Route ausgehend vom Startpunkt) abzufragen und die generierte Map in verschiedenen Detaillierungsgraden auszudrucken. Wählt man die Anfahrt per Zug, dann erfolgt das ganze Prozedere nochmals bei der Bahn um die Abfahrts- und Ankunftszeiten in Erfahrung zu bringen. Liebe Website-Betreiber, ginge das nicht einfacher?

 

Die Vision: Die Anfahrtsskizze auf einer Website besteht aus einer dynamischen Karte à la Google maps. Damit kann man den Ausschnitt und Detaillierungsgrad, anzuzeigende POIs oder andere Kartenlayers selber wählen. Durch ein zusätzliches Eingabefeld kann ich meinen jetzigen Standort angeben (automatische Geo-IP-Auflösung wär noch ein Goodie obendrauf). Darauf basierend wird die Anfahrtsroute (Auto) oder der Bahnfahrplan zum Unternehmensstandort ausgegeben. Alles auf einer Website und garantiert mit Zeitersparnis für den glücklichen Benutzer.

 

Kommerzielle Anbieter wie Map24, Yellowmap oder Maponair bieten zwar Produkte zum Einbauen auf der Website bereits an – allerdings mit dem seit Jahren bekannten, eher klobigen Kartenmaterial. Schöner wär natürlich eine dynamische Lösung mittels Google Maps API oder ähnlich. Wie z.B. ein SBB-Fahrplan sinnvoll und dynamisch in eine Karte integriert werden kann, zeigt map.search.ch.

 

 

Eine Routing-Funktion fehlt allerdings noch bei map.search.ch. Google maps bietet zwar so was wie ein Routing an, ist in der Schweiz jedoch aufgrund fehlenden Adressdaten (noch) unbrauchbar – mehr als der Weg von Zürich nach Bern lässt sich kaum darstellen.

 

 

Dennoch, mit etwas Programmierung lässt sich Google Maps bestens als veritable Alternative zum kommerziellen Angebot nutzen. Quikmaps bietet den Bausatz dazu und macht das ganze zum Kinderspiel. Zumindest statische Anfahrtspläne sollten damit eigentlich passé sein.

 

Folgendes Mashups integrieren die Google Maps API und stehen aktuell auf der persönlichen Bestenliste ganz oben. Die 10 muss man gesehen haben, um zu verstehen, was gerade „cutting edge“ in der Google Maps Integration ist:

 

Dude, where’s my used car?

Autos, die bei eBay motors eingestellt sind (leider nur USA) in meinem lokalen Umkreis angezeigt. Da bringt die kartographische Visualisierung endlich einen Nutzen (im Vergleich zu anderen Maps-Mashups): Gebrauchtwagen kauft man ja typischerweise eher in der Nähe.

 

 

Where am I?

Für jene die auch schon morgens aufgewacht sind, das Notebook eingeschaltet haben und sich gefragt haben: „Wo bin ich denn jetzt eigentlich?“ ist dies die Lösung: Auf Basis eines IP-Geoservices wird die aktuelle Position in die Google Maps hineingerendert (So zuverlässig wie IP Geoservices halt sind). Nutzlos wie der Dienst auch sein mag: Die Geoposition anhand der IP auslesen und aufgrund dessen z.B. den initialen Kartenausschnitt von jenem Ort anzeigen, an welchem sich der Benutzer gerade befindet, ist noch ein guter Ansatz.

 

 

On one map

Recht schön gemachte Lösung für die Wohnungssuche in England. Kommt zwar nicht ganz an immo.search.ch heran, aber doch beachtlich. Und Wohnungen sind ja ebenfalls Objekte, bei welchen die Lokalität eine wesentliche Rolle spielt – d.h. Positionierung auf einer Map durchaus sinnvoll.

 

 

Panorama Explorer

Geocodierte Fotos von Flickr in eine Google Map hineingezogen, geben neue Perspektiven. Insbesondere für die Speicherung von Ferienfotos auf einer längeren Reise wär dieses mentale Modell noch sinnvoll.

 

 

Quickmaps

Die Google Map zum selber basteln. Wer Anfahrtspläne auf Websites schon immer öde fand, findet hier mit ein paar Mausklicks die Erlösung. Per Drag and drop lassen sich Symbole auf einen Kartenausschnitt ziehen, Beschriftungen und Hinweise anbringen und schlussendlich abspeichern. Die neue Anfahrtsskizze in 5 min. mit Google Maps integriert.

 

 

Where’s Tim been?

Das ganze sieht ja nicht wirklich schön aus, aber die Idee ist fazinierend: Ein Typ namens Tim trägt ein GPS auf sich und zeichnet auf, wo er sich befindet und hinbewegt. Die Daten werden anschliessend täglich in eine Google Map hineingerendert. Nutzlos, aber definitv witzig.

 

 

 

Real time Satellite tracking

Wer schon immer mal wissen wollte, an welcher Position sich gerade der Satellit befindet, über welcher das Fernsehprogramm übertragen wird, kann dies auf diesem Map Mashup rausfinden. James Bond und Dr. No lässt grüssen.

 

 

Virtual Tourism

Google Maps hat den Nachteil, dass man alles nur von oben sieht. Wenn man dies aber mit Videos von YouTube kombiniert, dann gibt’s plötzlich neue Detailansichten.

 

 

Hotornot + Google Maps

Wer erinnert sich noch an Hot Or Not?, das Portal wo pubertierende Teenies ihr Aussehen von anderen bewerten lassen können und damit ihr Selbstwertgefühl verbessern oder meist verschlechtern können? Wers mag, der findet nun auch noch die Lokalisierung in Google Maps dazu.

 

 

Eventsites

Schön gemachte Site, und nach ein paar Fehlversuchen, weiss man auch wie navigieren. Einmal Eventful (Eventsite) mit Flickr (Photosite) und Google Maps integriert.

Also, Webeditor starten und das Google Maps API integrieren!

Schon seit mehreren Jahren und mittlerweile in einer recht ausgereiften Form bietet eBay sämtliche im eBay Universum eingestellten Artikel über eine API bzw. einen SOAP-Webservice an. Über die API sind nicht nur eingestellte Artikel such- und auslesbar, sondern es können auch Artikel darüber neu eingestellt werden. Dies nutzen mittlerweile z.B. mehrere Duzend Software-Tools, welche ebay Heavy-Usern versprechen wollen, Artikel besser, schneller und schöner in eBay einzustellen, als dies eBay selbst kann (z.B. http://www.supreme-auction.de/).

 

Beschäftigt man sich mit der eBay API etwas genauer, muss man relativ schnell zugeben, dass es eBay ernst ist mit der API. Nicht nur dass die Zugriffsfunktionen auf Artikel sehr umfangreich sind, das ganze mehr oder weniger robust funktioniert und sauber versioniert ist. Auch die über 1’000 Seiten starke Dokumentation beeindruckt. Die brauchts dann allerdings auch, wenn man auf die unterschiedlichen Artikel in den weltweit verteilten eBay Marktplätzen zugreifen will. Nützlich sind fürs Erste auch die Code-Beispiele in verschiedenen Programmiersprachen, welche einen schnellen Einstieg erlauben: In wenigen Stunden kann damit ein einigermassen begabter Programmierer eBay Artikel auslesen und in eine bestehende Applikation integrieren.

 

Befasst man sich etwas intensiver mit der Materie, stellt man aber auch relativ rasch die dahinter stehende Komplexität fest. Ein Beispiel sei an dieser Stelle kurz ausgeführt: Neben allgemeinen Artikeleigenschaften wie aktueller Preis, Titel und Auktionsende speichert eBay je nach Artikeltyp weitere Attribute. Solche sind z.B. „Kilometerstand“ bei Autos oder „Auflösung“ bei Digitalkameras. Selbsterklärend, dass so eine Unzahl von Attributen zusammenkommt und nicht jeder Artikel die gleichen Attribute besitzt. eBay löst diese Problematik nun so, dass für jedes Attribut sowie für jeden Wert eines Attributs eine ID vergeben wird. Verfügbare Attribute je Artikel können über einen eigenen Call abgeprüft werden. Das ist soweit sinnvoll, etwas schwierig macht’s es allerdings, dass es kein vollständiges Verzeichnis dieser Attribut-IDs gibt (Dokumentation enthält nur die wichtigsten). Das heisst, dass je nach Aufgabenstellung das Ganze zur aufwändigen Pröbel-Aufgabe wird. Dazu allerdings stellt eBay wieder nützliche Tolls wie das API-Testtools bereit. Dieses erlaubt einen parametrisierbaren Aufruf sämtlicher API-Calls über ein simples Web-Interface. Die Responses werden direkt in XML-Struktur zurürckgegeben, so dass zumindest auf diese Weise relativ einfach eine Zugänglichkeit der Attribute und IDs gegeben ist. Die Attributlösung von eBay führt allerdings dazu, dass beim Einbau von Attribut-Informationen in eine Applikation für jeden Artikel ein eigener API-Call notwendig ist. D.h. dass zum Beispiel eine Auflistung aller gebrauchter Artikel (Attribut „Artikelzustand“ mit Wert „gebraucht“) einer bestimmten Kategorie nicht in einem Call möglich ist. Stattdessen muss ein weiterer Attribut-Call für jeden gefunden Artikel durchgeführt werden, was wiederum etwas mehr Programmieraufwand bedeutet. Betrachtet man allerdings eBays umfangreiche Artikel- und Attributstruktur von Auto über Briefmarke zu Schuhen, ist dies alles nur verständlich.

 

Entsprechend der Web 2.0 Philosophie ist die eBay API frei und kostenlos verfügbar. Wer mehr als 10'000 API Calls pro Monat ausführen will, muss seine Applikation allerdings offen legen und von eBay zertifizieren lassen. Eine Zertifizierung erfolgt ebenfalls kostenlos und dient eBay vor allem als Kontrolle dafür, dass Calls auf die eBay-Infrastruktur effizent gelöst sind und nicht unnötigen Traffic verursachen.

 

velyoo wurde zum Beispiel von eBay zertifiziert und darf sich deshalb mit folgendem Logo auszeichnen:

Währenddem Kartendienste wie Google maps oder neuerdings auch Map24 brav ihre Kartendaten über APIs zur Integration zur Verfügung stellen, scheint sich map.search.ch und das Deutsche Pendant goyellow.de noch dagegen zu sträuben. Gerade weil map.search.ch aber schöne Satellitenbilder bereitstellt (welche für die Schweiz bei Google maps in hoher Auflösung fehlen) wäre eine Integration dieser Kartendaten zur Zeit noch besonders interessant.

Glücklicherweise braucht es aber nicht unbedingt eine API, um die Daten zu integrieren - JavaScript und URL-Parameter-Modifikation bringen auch schöne Resultate. Ein Beispiel, wie dies funktioniert, ist auf den Unterseiten von velyoo (map.search.ch) oder velyoo.de (goyellow.de) integriert (auf Vergrösserungs-Icon neben der Ortschaft klicken):

Technisch funktioniert dies folgendermassen:

Die statische Version von map.search (dito goyellow) liefert Bilder in JPG oder PNG Format URL-parameterbasiert aus. Ein Aufruf auf ein Bild kann damit folgendermassen aussehen:

http://mapdata.maple.search.ch/chmap.png?layer=sym,fg,copy,circle&zd=32&x=-200&y=-150&poi=zug&q=&merge=1&w=400&h=300&base=chur

Die Parameter haben folgende Funktion:

• layer: Hier können die darzustellenden Layer angegeben werden: fg liefert z.B. die Ortsnamen, sym die Karte, circle zeichnet den gesuchten Ort auf der Karte mit einem roten Kreis und bg zeigt das gewünschte Satellitenbild.
• zd: Damit wird der Zoomfaktor eingestellt, mögliche Werte 0.5 bis 400
• x, y:Geben die Anzahl Pixel an, wo der Karteausschnitt links und oben vom Zielpunkt entfernt beginnen soll
• w, h: Geben Höhe und Breite des zurückgelieferten Bildes an
• poi: Mögliche Point of Interest Layers, z.B. zug für die Bahnhöfe
• base: der Eigentliche Suchort URL-encoded, also z.B. Chur oder St.%20Gallen, ergänzt um Adressen

Mit etwas JavaScript lassen sich die Parameter-Aufrufe nun dynamisieren, z.B. Zoomfaktor für Ein- oder Auszoomen oder ein Switch von Karte zu Satellitenbild. Diese beiden Funktionen sind auf velyoo im genannten Karten-popup integriert, die JavaScript-Funktionen sind offen unter http://www.velyoo.com/res/helpers.js verfügbar.

Leider lassen sich damit noch nicht so schön Inhalte wie Fotos oder andere Daten in die Map hineinrendern, wie dies bei Google maps möglich ist. Für die dynamische Anzeige von Adressdaten oder Ortskizzen auf einer Website jedoch allemal ausreichend und als Goodie mit hochauflösender Satellitenbilder der Schweiz.

Wikipedia definiert den Begriff Mashup folgendermassen:

"Der Mashup (engl. für Vermanschung) bezeichnet die Erstellung neuer Webinhalte durch die nahtlose (Re-)Kombination bereits bestehender Webinhalte und -angebote. So stammt der Begriff auch aus der Welt der Musik und bedeutet dort im Englischen soviel wie Remix. In den deutschen Sprachraum wurde der Begriff rund um das Schlagwort Web 2.0 importiert, da Mashups als ein wesentliches Beispiel für das Neue an Web 2.0 angeführt werden.

Typischerweise werden die Inhalte der Mashup-Website über offene Programmierschnittstellen, per Web-Feed (z.B. RSS) oder JavaScript eingebunden.

Eine besonders große Anzahl an Mashups verknüpft dabei geographische Daten, beispielsweise von Google Maps, mit anderen Inhalten wie Fotos oder Kleinanzeigen."

siehe http://de.wikipedia.org/wiki/Mashup