Projektdokumentation Datenverwaltung - Erstellung von Heat Maps auf mobilen Geräten

Projektdokumentation Projektdokumentation Datenverwaltung - Erstellung von Heat Maps auf mobilen Geräten Stephan Zeisberg zeisberg@inf.fu-berlin.de Stefan Meißner stefan.meissner@inf.fu-berlin.de 16. September 2012 Inhaltsverzeichnis 1 Aufgabenstellung 2 2 Heat Maps 2 2.1 Theoretische Grundlagen........................... 2 3 Probleme und Lösungswege 3 3.1 Mapsforge Overlay Klassen.......................... 3 3.1.1 Smooth Overlay............................ 3 3.1.2 3 Color Overlay............................. 4 3.2 mapex...................................... 4 3.3 Darstellung und Neuberechnung der HeatMap mit mapex......... 4 3.4 POI Suche.................................... 4 3.4.1 Probleme................................ 6 3.5 Hilfe Menü................................... 7 4 Verwendete Technologien und Tools 8 4.1 Eclipse mit ADT Plugin............................ 8 4.2 Android SDK.................................. 8 5 Literatur und Quellen 9 1

1 Aufgabenstellung Heat Maps stellen POIs (Points of Interest, z.b. Bars, Restaurants, Supermärkte, Tankstellen, etc.) als Overlay auf Karten dar. Dabei kann durch verschiedende Parameter die Darstellung der Heat Map angepasst werden. Z.B. können unterschiedliche POIs farblich getrennt oder durch die POI-Häufigkeit in einem Umkreis die Intensität des Overlays (reguliert durch die Transparenz geringe Transparenz entspricht hoher Häufigkeit) bestimmt werden. Ziel des Projekts ist die Darstellung von Heat Maps durch eine mobile Karten Rendering Engine, wie sie die Mapsforge Bibliothek zur Verfügung stellt. Es soll eine Beispielanwendung erstellt werden, welche als eigenständige Applikation auf der Android-Plattform lauffähig ist. 2 Heat Maps - Theoretische Grundlagen Wie in [8] definiert ist eine Heatmap (englisch: heat = Hitze, Wärme ; map = Karte ) ein Diagramm zur Visualisierung von Daten, deren abhängige Werte einer zweidimensionalen Definitionsmenge als Farben repräsentiert werden. Sie dient dazu in einer großen Datenmenge intuitiv und schnell besonders markante Werte zu erfassen. Die in einer Matrix abgelegten Werte repräsentieren dabei einzelne Farbwerte. Diese Farbwerte können beliebig definiert werden, jedoch wird meißt der Wertebereich mit höherer Dichte der Werte farblich dunkler als Wertebereiche mit niedriger Wertedichte dargestellt. Die in folgender Abbildung aufzeigte Matrix zeigt die Funktionsweise einer Heatmap: Abbildung 1: Heatmaps Matrix [9] Dabei sind höhere Werte mit einer größeren Farbintensität (z.b. [0, 0]) dargestellt und kleinere Werte mit einer niedrigeren (z.b. [3, 0]). 2

3 Probleme und Lösungswege 3.1 Mapsforge Overlay Klassen Als Karten Rendering Engine wurde Mapsforge [1] verwendet. Mapsforge stellt bereits einige grundlegenden Overlay Klassen zur Verfügung, u.a. einen Kreis. Hiermit kann eine Heat Map auf verschiedene Weise dargestellt werden. Zwei Ansätze sollen hier kurz diskutiert werden. 3.1.1 Smooth Overlay Hier werden mehrere Kreise übereinander dargestellt, wobei jeder Kreis einen anderen Radius hat. Der Mittelpunkt aller Kreise ist die POI Koordinate. Durch Veränderungen des Alpha-Levels der Farbe kann die Intensität veriiert werden. Abbildung 2: Smooth Overlay Hierdurch sind bereits gute Ergebnisse erzielbar, jedoch wird hierdurch die HeatMap auf eine einzelne Farbe beschränkt. Mehrere Farben könnten nur für alleinstehende POIs umgesetzt werden. Kommt es jedoch zu Überschneidungen tritt das gleiche Problem wie beim 3 Color Overlay auf. Weiterhin sind bereits für einen POI mehrere Overlay Objekte notwendig, je nach Granularität bis zur Anzahl an Pixeln des Radius, was für glatte Übergänge notwendig ist. Dies macht diesen Ansatz sehr Speicher- und Berechnungsintensiv. 3

3.1.2 3 Color Overlay Beim 3 Color Overlay können mehrere Farben zur Abstufung der Intensität genutzt werden. Kräftigere Farben bedeuten dabei eine höhere Intensität. Für jede Farbe wird ein Kreis gezeichnet, wobei kräftigere Farben einen kleineren Radius haben. Abbildung 3: 3 Color Overlay Das Ergebnis ist jedoch nicht zufriedenstellend. Die Übergänge wirken sehr stumpf. Weiterhin addieren sich verschiedene Farben bei Überschneidungen nicht, wodurch kräftigere Farben mitunter abgeschwächt werden. Abhilfe schafft hier nur, wenn zuerst alle Kreise schwächerer Farben und im Anschluss die Kreise der intensiven Farben dem Layer hinzugefügt werden. Jedoch ist hierfür ein Schleifendurchlauf über alle POIs je Farbe notwendig. 3.1.3 Kombination Smooth Overlay und 3 Color Overlay Um den Smooth Overlay mit mehreren Farben zu nutzen, ist eine Kombination der beiden Ansätze möglich. Jedoch stellt Mapsforge lediglich 11 verschiedene Farben für die Overlay Klasse bereit. Daher können die Übergänge der Farben nicht sehr gut umgesetzt werden. 4

3.2 mapex Nach vielfältigen Recherchen über die Funktionsweise bestehender Heatmap Implementierungen sind wir auf die mapex Google Maps API Extension [7] gestoßen. Diese Implementierung beruht auf der von Google bereitgestellten Maps API. Die Entwicklung von mapex wurde allerdings voraussichtlich eingestellt, der letzte Commit war im Juli 2011. Für unsere Implementierung adaptierten wir Funktionalität aus diesem Programm und implementierten diese in unsere mapsforge-basierte Heatmap-Berechnungs Klasse. mapex war dafür ausgelegt Heatmaps für größere Kartenausschnitte anzuzeigen. Unsere Implementierung benötigte allerdings einen höheren Detailgrad, da wir die Heatmap auf kleiner Kartenausschnitte legen wollten. Durch die mapex Implementierung waren wir in der Lage die Heatmap effizienter als in unseren vorherigen Versuchen zu berechnen. 3.3 Darstellung und Neuberechnung der HeatMap Für die Darstellung der Heatmap galt es folgende Probleme zu lösen: Behandlung von TouchEvents Die Heatmap wird als Overlay über die Karte gelegt und ist dadurch unabhängig von der Kartendarstellung. Dies bedeutet, dass die Events Kartenscrollen und - zoomen ebenfalls für das Overlay behandelt werden müssen. Beschränkung der Größe der Heatmap Die Heatmap besteht aus einer Pixelmatrix. Je größer diese Matrix, desto höher ist auch der Speicherverbrauch. Die Größe kann jedoch auf die Auflösung des Bildschirms beschränkt werden, da ohnehin nicht mehr angezeigt werden kann. Damit beim Scrollen die Heatmap nicht gleich neu berechnet werden muss, sollte die Heatmap um einen bestimmten Faktor größer als die Bildschirmauflösung sein. Austausch des Overlays bei Neuberechnung Muss die Heatmap durch zoomen oder scrollen der Karte neu berechnet werden, ist das alte Overlay mit dem Neuen auszutauschen. Alle Events, die die Darstellung der Karte verändern, lösen die drawoverlaybitmap Methode der Overlays aus. An diesen Stellen kann also auf Veränderungen reagiert werden. Der Zoom-Level und die aktuellen Koordinaten der Karte sind über das View leicht zu erhalten. Anhand dieser Werte können die Bewegungsdeltas errechnet werden. Hat sich der Zoom-Level verändert, muss die Heatmap in jedem Fall neu berechnet werden. Bei Scrollbewegung muss unterschieden werden. Kann die Heatmap nicht mehr komplett angezeigt werden, da die Grenzen der Pixelmatrix erreicht wurden, ist ebenfalls eine Neuberechnung notwendig. Andernfalls muss das Overlay um das Bewegungsdelta verschoben werden. Während der Neuberechnung dürfen keine Kartenbewegungen stattfinden, da sonst das 5

Overlay verschoben angezeigt wird. Mit Hilfe eines ProgressBar werden Kartenbewegungen und sonstige Benutzereingaben unterdrückt. Für die Berechnung wird die BufferedImage Technik verwendet. D.h. es wird bei jeder Neuberechnung ein neues Bitmap genutzt. Ist die Berechnung fertig, kann das alte Bitmap durch das Neue ausgetauscht werden. Durch diese Methode wird ein Flackern des Overlays verhindert. Die Größe der Heatmap Pixelmatrix ist ein Vielfaches der Bildschirmgröße. Je höher das Vielfache ist, desto weniger muss die Heatmap neu berechnet werden. Allerdings wird dadurch auch um das Vielfache mehr Speicher benötigt, was bei zu hohen Werten zu Abstürzen führt. Ein guter Tradeoff ergab sich mit Faktor 2. Die Darstellung der Heatmap erfolgt über ein Canvas, welches bereits für einen weichen Übergang der unterschiedlichen Farben sorgt. Der Berechnungsalgorithmus der Pixelmatrix wurde von mapex übernommen. Abbildung 4: Darstellung der Heatmap 3.4 POI Suche Da das statische Hinzufügen der Geokoordinaten von POIs nur wenig nutzen hat, haben wir uns entschieden eine POI-Suche zu implementieren. Somit ist es möglich, über ein Suchfeld nach bestimmten POIs zu suchen und diese dann in der Heatmap zu visualisieren. Die von uns verwendete POI-Datenbank basiert auf von OpenStreetMap bereitgestellten POI-Daten, welche über [5] bezogen wurden. Diese Daten können allerdings von der mapsforge Bibliothek in dieser Form nicht verarbeitet werden und müssen 6

aus diesem Grund konvertiert werden. Dafür verwendeten wir das Tool osmosis [6]. Die über [5] bezogene Datenbank wurde dann mit folgendem Befehl konvertiert: # osmosis rb b e r l i n. osm. pbf poi w r i t e r b e r l i n. poi categoryconfigpath= POICategoriesOsmosis. xml " Listing 1: Konvertieren der POI-Datenbank Die daraus resultierende.poi-datei kann mit Hilfe der mapsforge Bibliothek verwendet werden. Dazu muss diese auf die SD-Karte des Android Gerätes kopiert werden. Diese Datei wird nun über folgende Direktive ausgelesen und verwendet: 1 S t r i n g path = Environment. g e t E x t e r n a l S t o r a g e D i r e c t o r y ( ). getabsolutepath ( ) + " / b e r l i n. poi " ; 2 PoiPersistenceManager pm = PoiPersistenceManagerFactory. getsqlitepoipersistencemanager ( path ) ; 3 PoiCategoryManager pcm = pm. getcategorymanager ( ) ; 4 P o i C a t e g o r y F i l t e r p c f = new ExactMatchPoiCategoryFilter ( ) ; Listing 2: Auslesen der.poi-datei In Zeile 1 wird der Pfad zur Datenbank-Datei bestimmt und in einer Variable abgelegt. Danach wird die Datenbank mit Hilfe des PoiPersistanceManager instanziert. Über diesen erhält man auch einen sogenannten PoiCategoryManager, mit dem man Zugriff auf die POI-Kategorien der Datenbank erlangt. In Zeile 4 wird ein PoiCategoryFilter-Objekt angelegt, welches dazu dient, POIs zu filtern. Der in der HeatMap zu visualierende POI wird über ein Suchfeld der Applikation eingeben. Dies ist in Abbildung 4 zu sehen. Abbildung 5: Suchfunktion 7

Der Ausgewählte Begriff wird dann an die sogenannte poi_search-funktion weitergegeben. Über folgenden Befehl wird dann ein PoiCategory-Objekt erstellt, welches dem PoiCategoryFilter übergeben werden kann: 1 PoiCategory pc = pcm. getpoicategorybytitle ( this. query ) ; Listing 3: POI Kategorie Objekt Dabei ist this.query der über das Suchfeld eingegebene Begriff. Damit die Suchergebnisse dem aktuell ausgewählten Kartenbereich entsprechen, wird bei jeder POI Suche die zentrale Position mittels der Mapsforge Bibliothek bestimmt. Dies geschieht über folgende Aufrufe: 1 GeoPoint center_point = view. getmapposition ( ). getmapcenter ( ) ; 2 GeoCoordinate c e n t e r = new GeoCoordinate ( center_point. g e t L a t i t u d e ( ), center_point. getlongitude ( ) ) ; Listing 4: Zentrale Kartenposition ermitteln Dabei wird die zentrale Geopunkt Position über das MapView Objekt ermittelt. In Zeile 2 werden die Längen- und Breitengradwerte in ein GeoCoordinate-Objekt übertragen. Die Liste an POIs erhält man mit folgendem Aufruf: 1 C o l l e c t i o n <P o i n t O f I n t e r e s t > s e a r c h R e s u l t s = pm. f i n d N e a r P o s i t i o n W i t h F i l t e r ( center, radiusmeters, pcf, searchlimit ) ; Listing 5: Suchen der POIs Die PoiPersistanceManager-Methode enthält die Funktion, die POIs mit einem übergebenem Filter-Objekt (siehe oben) zu suchen. Desweiteren wird die ermittelte zentrale Kartenposition, sowie der Suchradius und ein Limit an Suchergebnissen übergeben. Die Liste an POIs wird dann dem HeatMapsOverlay für die Heatmap-Berechnung zur Verfügung gestellt. Aus Gründen der Benutzbarkeit der Applikation haben wir in das Suchfeld der Applikation eine Autovervollständigung integriert. Die von der Autovervollständigung bereitgestellten Suchbegriffe entsprechen den Kategorien der aus [5] bezogenen Datenbank. Suchbegriffe die nicht diesen Kategorien entsprechen würden zu keinen Ergebnissen führen, da eine Tag-basierte suche mittels der mapsforge-poi Implementierung derzeit nicht möglich ist. Aus diesem Grund kann man in der Applikation nur aus den vorgeschlagenen Kategorien wählen. 3.4.1 Probleme mit der POI Suche Bei der Entwicklung der POI Suche sind wir auf viele Hindernisse gestoßen. Unser erster Ansatz, die POI-Daten direkt über einen OpenStreetMap-Server abzufragen schlug fehl, da eine dauerhafte Erreichbarkeit der Server nicht gewährleistet war. Desweiteren war ein komplexes Parsing der zurückgelieferten XML-Daten notwendig, um die POI Informationen zu erhalten. Aus diesem Grund wurde dieser Ansatz verworfen. 8

Nach Absprache mit Karsten Groll verwendeten wir dann die mapsforge eigene POI- Suche. Diese wurde allerdings im Projektverlauf gerade erst entwickelt und stellte uns somit vor weitere Probleme. Verschiedene Fehler in der mapsforge Bibliothek wurden nach Absprache mit Karsten Groll von ihm beseitigt. Desweiteren ist es durch die verwendete mapsforge Lösung nicht möglich die Suchfunktion im Android-SDK Emulator laufen zu lassen. Diese lief nur auf Android Geräten und erschwerte die Entwicklung. 3.5 Hilfe Menü Um die Applikation leicht zu verstehen und abzurunden haben wir uns dafür entschieden, ein Hilfe Menü zu entwickeln. Dieses ist sehr simpel und bietet aus Gründen der intuitiven Benutzbarkeit unserer Applikation wenige aber ausreichende Information auf. Das Hilfe Menü erreicht man über die Betätigung des Menü-Buttons auf Android Geräten. Dies ist in Abbildung 6 dargestellt. Abbildung 6: Hilfe Menü Betätigt man den in der Abbildung aufgezeigten Menü-Button erschein der in Abbildung 5 abgebildete Hilfetext. 9

Abbildung 7: Hilfetext 4 Verwendete Technologien und Tools 4.1 Eclipse mit ADT Plugin Die Android Development Tools (ADT) sind ein Plugin für die Eclipse IDE [2]. Da Google die Verwendung von ADT empfiehlt, ist es der Quasi-Standard zur Entwicklung von Android Anwendungen. Durch die Verwendung der Eclipse Platform kann ADT plattformunabhängig auf allen gängigen Betriebssystemen genutzt werden. 4.2 Android SDK Das Android SDK wird von Google vertrieben und kann unter [3] heruntergeladen werden. Es stellt die Programmierschnittstelle zur Entwicklung von Android Anwendungen dar. Für die Entwicklung der Heat Map Application wurde die API Version 11 genutzt unter der Android Plattform 4.0.3. 4.3 Android Hardware Durch bekannte Probleme mit dem PoiPersistenceManager ist es unabdingbar, dass die Anwendung auf einem Hardwaredevice läuft. In Emulatoren kann die POI-Suche nicht verwendet werden. 10

5 Literatur und Quellen [1] Mapsforge Libary für Android, http://mapsforge.org [2] ADT Plugin für Eclipse, http://developer.android.com/tools/sdk/eclipse-adt. html [3] Android SDK, http://developer.android.com/sdk/index.html [4] Leland Wilkinson, Michael Friendly, The History of the Cluster Heat Map, The American Statistician, 2008 [5] GeoFabrik POI Datenbank, http://download.geofabrik.de/osm/europe/ [6] Osmosis Tool, http://wiki.openstreetmap.org/wiki/osmosis [7] Mapex Google Maps API Extension, https://code.google.com/p/mapex/ [8] Heatmap Wikipedia, http://de.wikipedia.org/wiki/heatmap [9] Heatmap Matrix Grafik, http://gnuplot.sourceforge.net/demo/heatmaps.1.png 11