Location Based Services in Bezug auf den Kontext

Location Based Services in Bezug auf den Kontext Web 2.0
von Christian Schilling, [email protected]
Gliederung des Vortrags
●
●
●
●
●
●
●
●
●
●
●
Definition
Erklärung
Reale Anwendungsbeispiele 1 (Web 1.0)
Der Trend
Reale Anwendungsbeispiele 2 (Web 2.0)
Der Nutzen
Techniken
●
IP-bezogene Lokalisierung
●
Das Prinzip
●
Die Möglichkeiten
●
Reale Anwendungsbeispiele
●
Der Nutzen
●
Die Nachteile
●
Praktisches Beispiel (URL-API von hostip.info)
●
Geotagging
●
Geoumkreisdienste
●
Das Prinzip
●
Die Möglichkeiten / der Nutzen
●
Praktisches Beispiel (PHP, MySQL, Javascript, Smarty-Templateengine, OpenGeoDB)
Über den Tellerrand
●
Mobile Dienste
●
Tracking
●
Mashups
●
Die Zukunft
Fazit
Links
Quellen- / Abbildungsverzeichnis
Themendefinition
Standortbezogene Dienste (engl. Location Based Services (LBS), auch:
Location Dependent Services (LDS)) sind über ein
Telekommunikationsnetz erbrachte mobile Dienste, die unter
Zuhilfenahme von positions-, zeit- und personenabhängigen Daten dem
Endbenutzer selektive Informationen bereitstellen oder Dienste anderer Art
erbringen. [1]
Definition für den Webkontext optimiert:
Standortbezogene Dienste sind über das Internet erbrachte Dienste, die
unter Zuhilfenahme von positionsabhängigen Daten dem Endbenutzer
selektive Informationen bereitstellen oder Dienste anderer Art erbringen.
[1] Wikipedia: http://de.wikipedia.org/wiki/Location_based_services
Erklärung
Location Based Services sind ein Aspekt des Personalisierten Webs.
Es sind Dienstleistungen, die dem Nutzer
a) einen Informationsmehrwert bieten
oder
b) eine zusätzliche Informationsfilterdimension bieten
Das Web, dessen Eigenschaft es einmal war, sich von realen
Ortsinformationen zu lösen, wird um die Lokalisierbarkeit erweitert.
Der Nutzer erhält die Möglichkeit, Dienste und Informationen in
Abhängigkeit von Standortinformationen (Ortsangeben in Form von
Ortsnamen, Postleitzahlen, Längen- und Breitengraden etc.) in Anspruch
zu nehmen.
Reale Anwendungsbeispiele 1 (Web 1.0)
www.google.de mit dem Suchstring „hochschule stuttgart“
Abb. 1: www.google.de
Reale Anwendungsbeispiele 1 (Web 1.0)
www.bahn.de Reiseauskunft
Abb. 2: www.bahn.de
Reale Anwendungsbeispiele 1 (Web 1.0)
www.map24.de Routenplaner
Abb. 3: www.map24.de
Der Trend
Abb. 4: Web 2.0 Map
Der Trend
Typisches Web 2.0 Phänomen:
Altes Prinzip in neuem Umfeld unter Zuhilfenahme neuer technologischer
Ansätze und Gimmicks.
Der Trend des Tagging als Semantic Web von unten. Zusätzliche
Dimension: Geotagging
Long Tail-Effekte: Stark regionalisierte (personalisierte) Services (Beispiel
Google AdWords)
Reale Anwendungsbeispiele 2 (Web 2.0)
www.google.de mit dem Suchstring „tankstelle stuttgart“
Abb. 5: www.google.de
Reale Anwendungsbeispiele 2 (Web 2.0)
Geotagging auf www.flickr.com
Abb. 6: www.flickr.com
Reale Anwendungsbeispiele 2 (Web 2.0)
Geotpinning auf www.pintheglobe.com
Abb. 7: www.pintheglobe.com
Der Nutzen
●
Informationsmehrwehrt für den Nutzer
●
Absatzsteigerung durch regionale Lokalisierbarkeit
●
Faktor der De-Anonymisierung als Aspekt des Social Web
Techniken
●
IP-bezogene Lokalisierung
●
Geotagging
●
Geoumkreisdienste
IP-bezogene Lokalisierung
Der Standort des Nutzers wird aus seiner IP ausgelesen.
Eine Datenbank umfasst Zuordnungen von IP-Adressräumen zu
Geoinformationen
Beispiel: MaxMind GeoIP Lite (im CSV-Format, gelistet: AOL Nutzer):
"2.6.190.56","2.6.190.63","33996344","33996351","GB","United Kingdom"
"3.0.0.0","4.17.135.31","50331648","68257567","US","United States"
"4.17.135.32","4.17.135.63","68257568","68257599","CA","Canada"
Ein Datensatz umfasst:
Startadresse des Adressraums
Endadresse des Adressraums
Start-IP-Nummer (Maxmind-Formel)
End-IP-Nummer (Maxmind-Formel)
Iso 3166 Länderkennung
Ausgeschriebener Ländername
Hilfreiche Links
Proprietäre Produkte:
www.ip2location.com
www.digitalenvoy.com
www.ipligence.com
etc.
Open Source (GPL):
www.hostip.info
Abb. 8: www.hostip.info
Nachteile
Nicht gegebene Zuverlässigkeit sowie mangelnde Genauigkeit des Ergebnisses
Ursachen:
Proxies, private und dynamische IP-Adressen
Mit freien Datenbanken relativ bedenkenlos einsetzbar auf Länderebene
Ansonsten auf Accuracy-Quote achten!
Normalerweise unterteilt in
Country-Level
State-Level
City-Level
Praktisches Beispiel (URL-API von hostip.info)
Auslesen des eigenen Landes als ISO 3166 Code via URL-Request
http://api.hostip.info/country.php
Rückgabeformat: Plain Text
Rückgabewert: DE
Auslesen von Land, Staat, Koordinaten (nur innerhalb USA sinnvoll)
http://api.hostip.info/get_html.php?ip=12.215.42.19&position=true
Rückgabeformat: Plain Text
Rückgabewert:
Country: UNITED STATES (US)
City: Sugar Grove, IL
Latitude: 41.7696
Longitude: -88.4588
Weiterverarbeitung
Beispiel PHP:
Hilfe: Auslesen der Client-IP
In PHP über Superglobals: $_SERVER['REMOTE_ADDR']
In Python CGI: os.environ["REMOTE_ADDR"]
In ASP.NET: Request.ServerVariables["REMOTE_ADDR"].ToString()
etc.
Geotagging
Informationen oder Dienste werden vom Nutzer mit Geotags versehen.
„India“
„78.042381,27.174858“
Abb. 9: Taj Mahal
●
sehr einfaches Prinzip
●
abhängig vom Contentprovider Endnutzer
www.blog.mediaprojekte.de/internet/fotos-geotaggen/
www.1000ff.de/flickr-google-maps-geotagging/
www.freesound.iua.upf.edu/geotagsView.php
Geoumkreisdienste
Zielsetzung: Auffinden von örtlich passenden Einträgen in einer Datenbank
Zugrunde liegt:
●
Eingabe von Zielsuchgebiet des Nutzers
●
Datensatz des Nutzers (z.B. Webshop-Account)
Das Prinzip
Informationen, Produkte etc. werden in der Datenbank zusätzlich mit
Geoinformationen versehen und können in eine Abstandsbeziehung zu einer
Informationstabelle (z.B. Postleitzahl) gebracht werden.
Die Möglichkeiten / der Nutzen
Möglichkeiten:
●
Umkreissuche nach Diensten/Produkten etc.
●
Zuschneidung von Angeboten auf den geographischen Umkreis des Nutzers
Nutzen:
●
Wettbewerbsvorteile durch präziseren Service
●
De-Anonymisierung
●
Long-Tail-Effekte
Praktisches Beispiel
Implementiert in PHP, Javascript inkl. Smarty-Templateengine
Datenbank: MySQL
Datengrundlage: OpenGeoDB
Struktur (ohne Hilfsklassen):
index.php
stellt Suchergebnis
mittels Templatengine
dar
empfängt Suchergebnis
ruft per JS HTTP-Request (AJAX), Parameterübergabe: type, zip, distance
search.php
mittelt
cs_radius_search.php
ermittelt Suchergebnis
Abb. 10: Schema Umkreissuche
Projektion der Geodaten
Da reine Längen- / Breitengradinformationen keine Aussage über den Abstand
zwischen zwei geographischen Punkten beinhalten, muss eine Projektionsformel
angewandt werden.
Problem: Die Erde ist keine Scheibe! Deshalb hilft Pythagoras nicht.
Lösung: Projektionsformel “Azimuthal Äquidistante Projektion”
Azimuthal Äquidistante Projektion
Abb. 11: Azimuthal Equidistant Projection
Abb. 12: Azimuthal Equidistant Projection
http://mathworld.wolfram.com/AzimuthalEquidistantProjection.html
http://en.wikipedia.org/wiki/Azimuthal_equidistant_projection
Implementiert für z.B. für PHP:
http://pear.php.net/pepr/pepr-proposal-show.php?id=165
Die Formel in SQL
SELECT radians( avg( breitengrad ) ) , radians( avg( laengengrad ) ) FROM zip2geo;
set @lat0=0.89413563813052;
set @lon0=0.24573888895262;
update zip2geo set
x=sqrt(2/(1+(sin(@lat0)*sin(radians(breitengrad)))+(cos(@lat0)*cos(radians(breitengrad))*
cos(radians(laengengrad)- @lon0))))*cos(radians(breitengrad))*sin(radians(laengengrad)-@lon0)*6380,
y=sqrt(2/(1+(sin(@lat0)*sin(radians(breitengrad)))+(cos(@lat0)*cos(radians(breitengrad))*
cos(radians(laengengrad)- @lon0))))*((cos(@lat0)*sin(radians(breitengrad)))(sin(@lat0)*cos(radians(breitengrad))*cos(radians(laengengrad)-@lon0)))*6380
Muss einmal initial auf die Geotabelle angewandt werden. Fügt die für die Abstandsbrechnung
relevanten Felder x und y ein.
Wichtig:
Die Dadurch errechneten Daten sollten statisch in die Datenbanktabelle mit den durchsuchbaren Gütern
gelegt werden. Das bricht zwar die Normalform der Datenbank auf (redundante Haltung), ist aber aus
Performancegründen unerlässlich.
Performancesteigerung: der Ergebnisfilter
Ansatz ohne Filter:
Datenbankengine muss bei jedem Datensatz die Entfernung explizit prüfen.
Das ist in Hinblick auf die Performance der Anwendung untragbar.
Lösung:
Einschränken des Suchbereichs der Datenbank durch einen dynamischen Filter
Gesamtdatenfeld
Vorauswahlfilter
Tatsächlicher Umkreis
Abb. 13: Schema Filter
Implementierung in SQL
$dist – Distanz
$start_zip - Ausgangspostleitzahl
SELECT x,y,x-{$dist} as minX,x+{$dist} as maxX,y-{$dist} as minY,y+{$dist} as maxY
FROM $this->zip2geo_db WHERE plz=\"{$start_zip}\“
s. cs_radius_search.php l. 51ff.
Auf den so dynamisch eingeschränkten Datenbereich wird die Suche mittels Abstandsmessung nach
Pythagoras ausgeführt.
Wichtig:
Da die Einschränkung dynamisch ermittelt wird, muss die Bedingung mittels „HAVING“ eingebunden
werden.
Über den Tellerrand
●
Mobile Dienste
●
Tracking
●
Mashups
●
Die Zukunft
Fazit
●
Geodaten / Location Based Services sind ein Aspekt des „neuen“ Web
●
Sinnvoller Nutzen, wenn Grenzen eingehalten und Seriosität gewahrt
●
Abwägen, was tatsächlich sinnvoll ist
●
Relativ präzise Umkreissuchen und IP-Landesortung sind mit Open Source Produkten machbar
●
Es sind kaum Grenzen gesetzt (API-Mashups)
Quellen- / Abbildungsverzeichnis
Teile des Vortrags basieren auf folgenden Quellen:
PHPmagazin 1.06
www.de.wikipida.org
www.opengedodb.de
Abbildungen:
Abb. 1/Abb. 5: Screenshot www.google.de
Abb. 2: Screenshot www.bahn.de
Abb. 3: Screenshot www.map24.de
Abb. 4: Web 2.0 Map, Luca Cremonini, 25. Dezember, 2006, railsonwave.com
Abb. 6: Screenshot www.flickr.com
Abb. 7: Screenshot www.pintheglobe.com
Abb. 8: Screenshot www.hostip.info
Abb. 9: Foto Taj Mahal, www.flickr.com
Abb. 10: Christian Schilling 2007
Abb. 11: www.mathworld.com
Abb. 12: www.wikipedia.org
Abb. 13: Christian Schilling 2007
Danke für eure Aufmerksamkeit!
Christian Schilling
[email protected]