Einführung
Wenn Sie Ihre Daten auf einer Karte anzeigen oder Clusteranalysen betreiben möchten, benötigen Sie Geo-Informationen, wie Längen- und Breitengrade. Da diese Informationen oftmals nicht erfasst werden, bedarf es einer Lösung, die sich dieser Thematik widmet. Neben den Längen- und Breitengraden können noch weitere Zusatzinformationen erhoben werden, wie Gebäudetypen, Rezensionen, Öffnungszeiten, Kontaktdaten und weitere.
Dieser Blog versteht sich als Vertiefung zu dem ersten Blog zum Thema „SAP DATA Intelligence: GeoEnrichment per API“. Während sich der letzte Blog auf einen einfachen Anwendungsfall konzentriert hat, behandelt dieser Blog Erfahrungen und Lessons Learned, die in dem Prozess beachtet werden sollten. Hierbei wird besondere Aufmerksamkeit auf mögliche Fallstricke gelegt, die es zu beachten gilt.
Zunächst werden Anwendungsszenarien betrachtet und im Anschluss rechtliche und strukturelle Aspekte der API-Nutzung sowie die Unterschiede zwischen den verschiedenen API’s vorgestellt. Im Anschluss werden Abdeckungsraten und Suchparameter beleuchtet und schlussendlich die Verarbeitung der Ergebnisse vorgestellt.
Fallstricke und Erfahrungen
Was für ein Szenario liegt vor?
Bevor ein Projekt konkretisiert wird, muss ein Konsens darin bestehen, welches Szenario verfolgt wird. Diese Aussage ist insbesondere im Kontext von GeoEnrichment relevant.
Dabei wird sich auf die zwei bekanntesten Szenarien beschränkt:
| Szenario | Beschreibung |
| Enrichment | Es liegen bereits Points of Interests vor, zu denen Längen- und Breitengraden hinzugelesen werden sollen. |
| Sourcing |
Es sollen neue Points of Interests gesucht und abgespeichert werden. |
Ein Enrichment-Szenario könnte die Veranschaulichung der Lage aller Kunden auf einer Map in der SAP Analytics Cloud veranschaulicht sein, um herauszufinden, in welchen Gegenden noch keine eigenen Kunden vertreten sind. Die untere Abbildung zeigt vereinfacht eine entsprechende Karte. Ein anderes Szenario kann die Optimierung der Lieferwege und -strecken darstellen. Dazu bedarf es Längen- und Breitengrade, bevor kalkuliert werden kann, welches die schnellste oder die kraftstoffärmste Strecke ist.
Abbildung 1: Quelle: https://samples.azuremaps.com/controls/bring-data-into-view-control
Ein Sourcing-Szenario könnte das Aufspüren neuer Verkaufsstandorte sein. Dies beinhaltet die explizite Suche nach neuen Orten oder solchen, an denen viele Menschen aufeinandertreffen.
Abhängig von dem Szenario sollte die API gewählt werden, da diese stark differieren und großen Einfluss auf die Kostenstruktur haben können. Das bedeutet, dass beispielsweise für ein Enrichment-Szenario, bei dem es nur um das Hinzulesen von Längen- und Breitengraden geht, nicht eine API gewählt werden muss, die neben Längen- und Breitengraden auch viele weitere Informationen (Gebäudetyp, Website, Telefonnummer etc.) bereithält. Dies verursacht höhere Kosten als eine API, die lediglich die Längen- und Breitengrade zurückliefert.
Darf ich Daten speichern?
Das Wichtigste ist die Evaluierung, ob die Speicherung der Daten erlaubt ist. Um in der SAP Analytics Cloud die Geo-Maps zu nutzen, bedarf es Längen- und Breitengrade, die zwangsweise irgendwo gespeichert werden müssen. Wenn außerdem weitere potenzielle Points of Interests gefunden werden, wird die Information nur dann ihr volles Potenzial entfalten können, wenn die Daten abgespeichert werden können.
Die Speicherung von Daten ist eher die Ausnahme als die Regel. Die Datenprovider lassen sich auf eine Speicherung ein, wenn zugesichert ist, dass der kostenpflichtige Dienst (API Aufruf) regelmäßig genutzt wird. Für eine Einordnung können die Terms of Use genutzt werden. Google verbietet generell das Speichern von Daten, macht jedoch auch Ausnahmen, wenn eine regelmäßige Nutzung des Service zugesichert wird. Azure Maps bietet teilweise auch freie Speicherungen an. Hierbei hängt es jedoch von dem verwendeten Service ab. Bing ist ähnlich angesiedelt wie Azure Maps. Bei Open Source Map wird ein eigener Server aufgesetzt. Somit entstehen bei der Speicherung keine Schwierigkeiten, jedoch aber eine mögliche Restriktion beim Volumen je Abruf.
Welche Daten brauche ich und welche API ist dafür geeignet?
Diese Frage hängt stark von der Wahl des Szenarios ab. Danach sollte evaluiert werden, welche Daten benötigt werden, welche Daten optional sind und welche Daten auch in Zukunft nicht gebraucht werden. Wichtig hierbei ist der Blick in die Zukunft, damit alle Möglichkeiten weiterhin genutzt werden können, ohne jedoch das eigentliche Szenario aus den Augen zu verlieren.
Die untere Tabelle beantwortet zweierlei Fragen.
- Welche API nutze ich in welchem Anwendungsfall?
- Welche Alternative gibt es für einen Anwendungsfall?
| Anwendungsfälle | Google Service | Azure Map Service | Bing Maps Service |
|
Freitextsuche nach eine Point of Interest: „Theater, Dortmund“ |
Find Place
Text Search |
Get Search POI
Get Search Fuzzy |
Find a Location by Query |
|
Adresssuche: „Theaterkarree 1-3, 44137 Dortmund“ |
Geocoding | Get Search Address | Find a Location by Address |
|
Freitextsuche nach neuen Point of Interest: „Italienisches Restaurant, Dortmund“ |
Nearby Search
Text Search |
Get Nearby Search | Location Search |
|
Detailsuche zu einem Point of Interest: „Interne_ID“ |
Place Details | Location Data |
Generell gilt, dass nur ein kleiner Ausschnitt von den möglichen APIs gezeigt wurde. Distanz- oder Routen- APIs wurden beispielsweise nicht verglichen. Bei den Azure Maps Service ist zu betonen, dass viele auch als Batch Service ausgeführt werden können, was die Verarbeitung vereinfachen kann. Im direkten Vergleich gibt es Unterschiede. Azure Map stellt bei der Suche nach Längen- und Breitengraden eine Alternative zu Google Maps dar. Bei der freien Suche zeigt Google deutlich mehr Erfahrung und Leistung. Bei Suchen im Umkreis ist es beschwerlich, die Qualität der beiden APIs zu bewerten. Bing schneidet in allen Punkten schlechter als die Konkurrenten ab. Es wird nicht mehr weiterentwickelt, da Azure Maps weiterentwickelt wird.
Bei der API-Wahl sollte mit Bedacht vorgegangen und das Szenario detailliert getestet werden, damit Zeit und Arbeit effizient eingesetzt werden.
Es gibt auch Open Source Maps, die nur Längen- und Breitengrade liefern. Jedoch ist es schwierig, eine Aussage über die Abdeckung und Validität der Daten zu treffen, da die Open Source Maps oftmals von der Community selbst gefüllt werden.
Wie hoch ist die Abdeckungsrate?
Die Geo-APIs haben unterschiedliche Abdeckungsgrade. Somit kommt es auf stark auf den Anwendungsfall an, wann was genutzt werden sollte. Das Stichwort beim Suchen ist die Coverage. Hier kann die Abdeckung verglichen werden. Dabei beeinflusst die Abdeckung die Ausgabegenauigkeit genauso wie die Suchparameter.
| Data Provider | Amerikanischer Raum | Europäischer Raum | Asiatischer Raum | Südamerikanischer Raum |
| Google Maps | ++ | ++ | – | 0 |
| Azure Maps | ++ | ++ | – | 0 |
| Bing Maps | + | + | 0 | 0 |
| Baidu Maps | ? | ? | ++ | ? |
| MapMyIndia | ? | ? | ++ | ? |
Der europäische und amerikanische Raum ist von den großen Anbietern wie Azure und Google sehr gut abgedeckt. Die asiatischen Länder werden vom chinesischen Anbieter Baidu sowie von einem indischen Pendant dominiert. Hier müssen Länder-Restriktionen beachtet werden. Baidu Maps kann zum Beispiel nur mit einer chinesischen Telefonnummer genutzt werden.
Open Source Maps werden oftmals von Communities gepflegt. Hier ist vor allem im europäischen und amerikanischen Raum mit validen Ergebnissen zu rechnen, außerhalb sind die Ergebnisse jedoch oftmals weniger aussagekräftig als die von Google oder Azure. Bing wird nicht weiterentwickelt, kann jedoch immer noch genutzt werden. Im Vergleich zu Azure ist es aber Bing möglich, seine Dienste für Japan anzubieten. Das ist Azure noch nicht möglich.
Wie erstelle ich sinnvolle Suchparameter?
Bei dem Suchparameter muss unterschieden werden, welches Szenario und welche Daten vorliegen.
| Szenario | Suchparameter | Beschreibung |
| Enrichment | „Theaterkarree 1-3, 44137 Dortmund, Deutschland“ | Die Struktur der Postanschrift ändert sich von Land zu Land in ihrer Struktur. |
| Sourcing | „Theater, Deutschland“ |
Es wird oft nach Schlagworten gesucht und es liegt keine Adresse vor. Das Land und ggf. die Stadt sollten dabei sein. Wenn es möglich ist, kann auch als weiterer Parameter ein Gebiet als ausgewählt werden. |
Wenn weitere Informationen zu einem Point of Interest gesucht werden, kommt es immer auf die Inputparameter der jeweiligen API an. Die Place Details API von Google bedarf der Google-internen ID (placeid), die nur mit einem anderen API-Aufruf eingeholt werden kann. Die Get Location API von Bing benötigt die Adresse. Hier muss die korrekte Adresse gewählt werden, andernfalls werden das falsche Haus und somit auch die falsche Information gesourced.
Wie werden Ergebnisse beeinflusst?
Die verschiedenen APIs weisen oftmals eine Standort-Verzerrung (location bias) auf, die die Ergebnisse in Bezug auf den eigenen Standort beeinflusst. Das bedeutet, dass bei einer Suche nach einer türkischen Adresse, wenn die eigene IP von Deutschland ausgeht, zunächst nach einem deutschen Ergebnis gesucht und eventuell ausgegeben wird. Hier muss gegengesteuert werden, damit die gewünschten Ergebnisse in anderen Ländern gefunden werden.
Eine weitere Verzerrung bezieht sich auf die Sprache, in der gesucht wird. Die Suchergebnisse können in einem weiteren Schritt verbessert werden, wenn sie in der richtigen Sprache geschrieben werden. Hierbei sollte eine geeignete Lösung eingeplant werden, die das Übersetzen in die richtige Landessprache gewährleistet. Durch die Nutzung steigt jedoch auch der Aufwand.
Wie überprüfe ich meine Ergebnisse?
Die Genauigkeit lässt sich manuell als auch automatisch kontrollieren.
| Szenario | Beschreibung |
| Enrichment | Manuelle Kontrolle dringend nötig. |
| Sourcing |
Manuelle Kontrolle kommt auf das Szenario an. Die zurückgelieferten Daten sind in sich stimmig. Mögliche Fehlerquelle: Kategoriefehler. Nach „Theater in Dortmund“ wird gesucht, es wurde aber eine Oper in Dortmund zurückgeliefert. Die Informationen zur Oper sind an sich stimmig, sie passt jedoch nicht zur Kategorie. |
Um die manuellen Kontrollen so gering wie möglich zu halten, gibt es automatisierte Logiken:
Die automatische Kontrolle muss in der Verarbeitungslogik der zurückgebenden Ergebnisse eingebaut werden. Es bedarf immer der Prüfung, ob die gesuchten Ergebnisse in dem richtigen Land sind. Hierbei gilt es, dies programmatisch zu überprüfen und die Weiterverarbeitung zu kontrollieren. Leider lässt es sich nicht nur auf ein Land beschränken. Bei der Stadt muss dies auch berücksichtigt werden, wobei die Überprüfung auf Stadtbasis deutlich komplexer wird.
Es bestehen verschiedene Möglichkeiten, dies zu verarbeiten. Eine Evaluierung kann aufzeigen, in welchem Anwendungsfall welche Verarbeitung Sinn ergibt.
Wie verarbeite ich Ergebnisse?
Außerdem muss eine fehlerfreie Verarbeitung gewährleistet sein. Bei den Verarbeitungen von Get-Requests treten verschiedene Fehlerquellen auf, die beachtet werden müssen.
Beispielsweise wird von APIs nicht immer nur ein Ergebnis geliefert. Mehrere gelieferte Ergebnisse für einen Suchparameter müssen geprüft und weiterverarbeitet werden. Dies kann über selbst geschriebene Kriterien, mit speziellen Algorithmen oder aber auch über fertige Bibliotheken umgesetzt werden.
Daneben muss auch die Fehlerbehandlung beachtet werden. Hier reicht es nicht mit dem Status der Response zu arbeiten. In einigen Fällen ändert sich das zurückgegebene Paket von Informationen und enthält nicht mehr die Informationen, die erwartet werden. Dies muss abgegriffen und verarbeitet werden.
Zusammenfassend lässt sich Folgendes feststellen:
Die Evaluierung, ob und wie lange die Daten gespeichert werden dürfen, ist essenziell wichtig. Nachdem klar ist, mit welchem Suchparameter und nach welchen Daten gesucht wird, müssen verschiedene Anbieter gegenübergestellt werden, um die beste API für das vorliegende Szenario zu definieren. Die Abdeckungsrate sollte genutzt werden, um die Suche der besten Ergebnisse zu gewährleisten. Des Weiteren gilt es zu beachten, wie das Ergebnis beeinflusst wird, wie dagegen gesteuert werden kann und wie die Qualität und Genauigkeit der Ergebnisse gesteigert werden kann.
Grundsätzlich gilt: Je besser die Datenqualität eines Suchparameters und je genauer die Vorstellung, welches Ergebnis erreicht werden soll, desto besser kann das GeoEnrichment umgesetzt werden.
Das Ranking in der unteren Abbildung baut auf den oben beschriebenen Punkten auf und versucht, diese stark vereinfacht darzustellen.
| Kriterium | Google Maps | Azure Maps | Bing Maps | Open Street View |
| Datenumfang | +++ | + | + | + |
| Datenvalidität | ++ | ++ | 0 | 0 |
| Datenspeicherung | 0 | + | + | + |
| Kosten | – | – | 0 | +++ |
| Datenabdeckung | ++ | ++ | 0 | 0 |
Fazit
Auch wenn dieser Blog vor allem die Fallstricke des GeoEnrichment beschreibt, sollte nicht darüber hinweggesehen werden, dass GeoEnrichment ein enormes Potential mit sich bringt. Es können mit den bestehenden Anbietern sehr gute Ergebnisse erzielt werden, die einen Mehrwert bieten.
Bei der Entscheidung für eine Anreicherung der Daten kann dieser Blog als Hilfestellung genutzt werden. Viele Probleme treten erst bei dem Verarbeiten der Daten auf und können viel Zeit in Anspruch nehmen. Deswegen ist zu betonen, dass beim GeoEnrichment nicht der Aufwand unterschätzt werden darf. Die Möglichkeiten sind jedoch erstaunlich. Insbesondere die Google Maps API bietet durch die differenzierten Funktionalitäten eine breite Palette von verschiedenen Anwendungsfällen an.
Wenn Sie interessiert sind und evaluieren möchten, ob GeoEnrichment für Ihre Projekte sinnvoll ist, sprechen Sie uns gerne an. Auch wenn Sie weitere Fragen haben, stehen wir Ihnen gerne zur Verfügung!
Ansprechpartner
Julius Nordhues
Consultant
