共用方式為

Gastartikel: HTML5-Geolocation

  • 發行項

Wenn es ein HTML5-Feature gibt, von dem jeder schon gehört hat, dann ist es die Geolocation-API. Sie demonstriert eine wichtige Wahrheit über HTML5, nämlich dass das Thema, obwohl es “HTML” im Namen trägt, doch vielmehr mit JavaScript als mit HTML-Tags zu tun hat. Der Grund ist klar: wie im ersten Teil der Artikelserie erwähnt, soll HTML5 einer der Bausteine für die Webapplikationen der Zukunft sein und diese Applikationen werden viel Arbeit in den Client, also den Browser, verlagern. Und wenn man den Browser programmieren möchte, ist eben JavaScript die Waffe der Wahl.

Die Geolocation-API spezifiziert eine einheitliche DOM-Schnittstelle, über die Scripts Geoinformationen vom Browser beziehen können. Dem Browser ist dabei freigestellt, woher er diese Informationen nimmt – sie könnten aus altmodischer IP-Lokalisierung stammen, aus den Standortinformationen des Betriebssystems abgefragt werden oder im Falle von Mobilgeräten aus dem eingebauten GPS-Chip oder der aktuellen Funkzelle stammen.

Der Vorteil für den Webentwickler ist, dass man einerseits eine einheitliche Schnittstelle in allen Browser zur Verfügung hat und dass man sich andererseits selbst keine Gedanken mehr um einzelne Geolocation-Techniken machen muss: man bestellt einfach die Koordinaten und der Browser liefert sie aus der besten Quelle, die ihm zur Verfügung steht.

Bei der Geolocation-API handelt es sich dabei wirklich um eine stabile und in allen (modernen) Browsern vorhandene Schnittstelle, vom Firefox 3.5 bis zum Internet Explorer 9 bieten alle Surfprogramme gute Unterstützung. Die Spezifikationen selbst haben seit Ende 2010 den Status “Candidate Recommendation” und stehen damit kurz davor, zum fertigen Webstandard geadelt zu werden. Und da neben aller Verbreitung und Stabilität die auch die Benutzung der API ausgesprochen einfach ist, gibt es nichts, was uns von ihrem Einsatz abhalten sollte … bis auf vielleicht die Frage, ob man die Geolocation-API überhaupt als HTML5 bezeichnen sollte.

HTML5 oder “HTML5”?

Für die Geolocation-API gibt eine eigene Spezifikation und sie wird weder in den HTML5-Spezifikationen des W3C noch im WHATWG-Dokument erwähnt. Man könnte es also machen wie die Betreiber von isgeolocationpartofhtml5.com und behaupten, dass die Geolocation-API gar nicht HTML5 genannt werden dürfte. Fraglich ist allerdings, ob eine so präzise Trennung nützlich oder überhaupt möglich ist. Zunächst besteht das Problem der doppelten Spezifikationen. Was bei der WHATWG Teil von HTML5 ist, kann bei beim W3C als separate Spezifikation laufen, wie es zum Beispiel bei Microdata (WHATWG HTML, eigene W3C-Spezifikation) oder dem 2D-Kontext des Canvas-Elements (WHATWG HTML, eigene W3C-Spezifikation) der Fall ist. Ist das nun HTML5 oder nicht? Andere Technologien wie Web Storage haben ihre Ursprünge in HTML5, wurden aber irgendwann einvernehmlich in einen eigenen Spezifizierungsprozess ausgelagert. Hier könnte man also nur behaupten, dass Web Storage kein HTML5 sei, sofern man angibt, auf welche exakten Koordinaten im Raum-Zeit-Kontinuum man sich bei dieser Aussage bezieht – denn die Spezifikation ändern sich ja ständig.

Wenn man die “echtes gegen falsches HTML5”-Debatte ernsthaft zu führen versucht, landet man offensichtlich schnell in Absurdistan. Hilfreicher ist es, das Wort “HTML5” weniger als Bezeichnung für eine bestimmte HTML-Version wahrzunehmen, sondern als als Dachbegriff für alles zu verstehen, was unserem Browser neue Fähigkeiten einimpft. Das ist so ähnlich wie beim Begriff Ajax. Einst stand dies als Akronym für eine Programmiertechnik namens “Asynchronous JavaScript and XML”, heute findet man unter diesem Label alle Arten von JavaScript-Kunstwerken, von denen nur die wenigsten etwas mit asynchronen Requests und fast gar keine etwas mit XML zu tun haben. Genau so eine Begriffsumbildung, bei der eine einzelne Technik Namensgeber für eine ganze Klasse von Technologien wird, ist auch bei HTML5 passiert. Damit jetzt aber genug der HTML5-Theorie und frisch ans Werk!

Positionen mit der Geolocation-API ermitteln

Die Geolocation-API erweitert window.navigator um das geolocation-Objekt, das wiederum drei Funktionen rund um Geokoordinaten enthält. Die wichtigste dieser Funktionen ist getCurrentPosition(), die, wie der Name schon andeutet, dem Auslesen der aktuellen Position dient. Das Finden der Position läuft dabei asynchron ab. Man übergibt getCurrentPosition() eine Callback-Funktion als Argument, der ausgeführt, sobald die Positionen gefunden wurde. Der Callback wiederum erhält als Argument ein Objekt mit den Geoinformationen:

1: // Funktion die bei erfolgreicher
2: // Positionsbestimmung ausgeführt wird
3: var erfolgCallback = function(koordinaten){
4: // "koordinaten" enthält die Geodaten
5: console.log(koordinaten);
6: }
7:
8: // Position bestimmen
9: window.navigator.geolocation.getCurrentPosition(erfolgCallback);

Bevor die Position bestimmt werden kann, muss der Browser den Nutzer um Erlaubnis für die Übermittlung der Daten fragen; heimliches ausschnüffeln ist nicht möglich. Wird die Erlaubnis erteilt, wird erfolgsCallback() ausgeführt und bekommt als Argument ein Objekt mit den Eigenschaften timestamp und coods übergeben. Die timestamp-Eigenschaft enthält, wie sollte es anders sein, den Zeitstempel für die Koordinaten, die in der coords-Eigenschaft stecken. In diesem Objekt findet man folgende Informationen vor:

  • accuracy: Gibt die Genauigkeit der Positionsbestimmung in Metern an
  • altitude: Gibt das Ergebnis der Höhenmessung in Metern an
  • altitudeAccuracy: Genauigkeit der Höhenmessung in Metern
  • heading: Gibt das Ergebnis der Richtungsmessung in Grad an
  • latitude: Geografische Breite als Dezimalwinkel
  • longitude: Geografische Länge als Dezimalwinkel
  • speed: Gibt die gemessene Geschwindigkeit in Meter/Sekunde an

Natürlich werden sich nicht bei jeder Positionsbestimmung für alle genannten Messungen Werte finden lassen. Wer an seinem PC in einem Keller sitzt, für den wird sich naturgemäß keine Geschwindigkeit oder Richtung finden lassen, anders als bei jemandem, der sein mit einem Accelerometer bestücktes Smartphone unter freiem Himmel spazieren führt. Konnte eine Messung nicht durchgeführt werden, ist ihr Wert im Koordinaten-Objekt null.

Für eine dauerhafte Positionsüberwachung bringt die Geolocation-API mit watchPosition() eine Funktion mit, die im Prinzip einem setInerval()-Wrapper für getCurrentPosition() entspricht. Sie akzeptiert die gleichen Argumente wie getCurrentPosition() und gibt eine Timer-ID zurück, die man in der Funktion clearWatch() verwenden kann, um eine laufende Überwachung wieder einzustellen:

1: // Positionsüberwachung starten
2: var ueberwachung = window.navigator.geolocation.watchPosition(erfolgCallback);
3:
4: // Überwachung nach einer Minute wieder einstellen
5: setTimeout(function(){
6: console.log('Stoppe Überwachung');
7: window.navigator.geolocation.clearWatch(ueberwachung)
8: }, 60000);

Und das, die drei Funktionen getCurrentPosition(), watchPosition() und clearWatch(), ist eigentlich schon die gesamte Geolocation-API. Alles was noch fehlt ist Fehlerbehandlung und Konfiguration der Positionsbestimmung.

Konfiguration und Fehlerbehandlung

Bei der Positionsbestimmung kann viel schiefgehen. Nicht nur könnte sie an technischen Problemen scheitern, sondern es wäre ja auch denkbar, dass ein Nutzer sich dazu entschließt, seinen aktuelle Aufenthaltsort nicht preiszugeben. Diese und andere Fehler kann man einfach abfangen, indem man einen Fehler-Callback definiert und diesen als zweites Argument an getCurrentPosition() bzw. watchPosition() übergibt. Der Fehler-Callback ist keine Pflichtangabe, sondern kann auch weggelassen werden. Als Argument erhält die Callback-Funktion ein Objekt mit zwei Eigenschaften, dem Fehlercode code und einer Fehlermeldung message:

1: // Funktion die im Fehlerfall ausgeführt wird
2: var fehlerCallback = function(fehler){
3: console.log('Fehler ' + fehler.code + ': ' fehler.message);
4: }
5:
6: // Position bestimmen
7: window.navigator.geolocation.getCurrentPosition(erfolgCallback,
8: fehlerCallback);

Die Fehlermeldung ist ein kurzer, für den Webentwickler gedachter Text mit Fehlerinformationen und der Fehlercode ist immer einer der folgenden Werte:

  • 1 (PERMISSION_DENIED): Der Nutzer hat keine Erlaubnis für die Positionsbestimmung gegeben
  • 2 (POSITION_UNAVAILABLE): Die Position konnte nicht bestimmt werden
  • 3 (TIMEOUT): Zeitüberschreitung bei der Positionsbestimmung

Wann Fehler Nummer 3, die Zeitüberschreitung, eintritt, kann man selbst steuern. Als drittes Argument kann man an getCurrentPosition() bzw. watchPosition() ein Konfigurations-Objekt übergeben:

 1: // Funktion die im Fehlerfall ausgeführt wird
2: var configObjekt = {
3:  enableHighAccuracy: true,  // Super-Präzisions-Modus
4:  timeout:            3000,  // Millisekunden bis zum Timeout
5:  maximumAge:         5000   // Lebenszeit Daten-Cache in ms
6: }
7:
8: // Position bestimmen
9: window.navigator.geolocation.getCurrentPosition(erfolgCallback,
10: fehlerCallback, configObjekt);

Die enableHighAccuracy-Angabe im Konfigurations-Objekt legt fest, ob auf Kosten der Geschwindigkeit eine genauere Positionsbestimmung durchgeführt werden soll. Unter timeout kann man bestimmen, nach wie vielen Millisekunden ohne Erfolg der Timeout-Fehler stattfinden soll und maximumAge erlaubt es schließlich, die Haltbarkeit des API-internen Caches zu steuern.

Fazit

Überschaubarer Umfang, große unmittelbare Nützlichkeit und umfassende Verbreitung: Die Geolocation-API ist eins der pflegeleichteren HTML5-Features. Manches anderes, was noch nicht bugfrei in allen Browsern gelandet ist, von seiner Konzeption her etwas fremdartig daherkommt oder einfach nur schwieriger zu verwenden ist, macht auf den ersten Blick nicht ganz so viel Spaß, ist aber auch zu bändigen. Neu sind diese Probleme nicht: das DOM an sich, also unsere gesamte Browser-Schnittstelle, ist eigentlich eine Katastrophe, doch dank Tools wie jQuery kann man es benutzbar machen. Wo HTML5 ähnliche Herausforderungen für uns bereit hält, sehen wir dann im nächsten Teil dieser Serie.

Über den Autor

Peter Kröner ist selbstständiger Webdesigner und -entwickler, Autor des HTML5-Buchs und Dozent für alle Fragen rund um HTML5 aus der Nähe von Osnabrück. Auf peterkroener.de bloggt er über alle Themen rund um Web(zukunfts)technologie.

Webentwickler aufgepasst!

Dev_unplugged

Microsoft hat einen Wettbewerb für HTML5-Entwickler gestartet. Bei Interesse schaut einfach bei www.beautyoftheweb.com/#/unplugged vorbei.

Comments

  • Anonymous
    January 01, 2003
    Da gebe ich Dir recht, David, das ist unschön so. Ich habe den Code mal mit Umbruch versehen und eingefügt. So sollte das besser aussehen.

  • Anonymous
    March 11, 2011
    Schöner Artikel, aber muss das so sein, dass die Quellcode-Beispiele auf der rechten Seite abgehackt sind?