Kästchenspringen for ArcGIS
Ein alternatives Adresssystem hilft, wo herkömmliche Postadressen versagen. Jetzt auch im ArcGIS Experience Builder.
Parkt ein Bayer sein Auto an ///energische.geduld.wolle und betritt das Hauptquartier von Esri Deutschland in ///poesie.schenken.backofen. Diese Situation könnte man ebensogut beschreiben mit: Parkt ein Bayer sein Auto an der Raiffeisenstr. 16 und betritt das Hauptquartier von Esri Deutschland in der Ringstr. 7. Ist ähnlich, auch wenn er sich für das Finden des richtigen Gebäudes und der Eingangstür vermutlich ein paarmal um sich selbst drehen müsste.
Kompliziert wird es, wenn er seinen Traktor nach 8 Maß auf dem Dorffest nicht mehr nach Hause gefahren, sondern im Acker geparkt hat. Am nächsten Morgen versucht er sich nun an die Anzahl und Ausrichtung der Büsche am Weg zu erinnern, um sein Fahrzeug wiederzufinden. Hätte er kurz eine ganz bestimmte App zur Hand gehabt, hätte er sich beim Aussteigen eine Erinnerung setzen können: Ganz klar, er hat auf dem Heimweg von Kranzberg nach Sünzhausen die Kurve ums Waldstück nicht geschafft und den Traktor sicherheitshalber bei ///jedoch.trennt.genauigkeit stehenlassen.
So geht das aus, wenn man in ///zeit.ursache.bringen im Büro sitzt und versucht, sich eine lebensnahe Situation eines typischen Bewohners des erweiterten Münchner Umlands vorzustellen. Auf den Realitätsgehalt der Begebenheit kommt es in diesem Fall nicht an. Wichtig ist, dass mit dem Standort im Acker ein adressenloses Fleckchen Erde eindeutig bezeichnet und wiederauffindbar gemacht wurde. Übertragen auf das Leben in der Zivilisation könnte sich der Fall ergeben, dass in meinem Büro ein Speditionslieferung erwartet wird. Der Haupteingang befindet sich in ///worunter.flair.zeilen, besser parken kann man aber im Innenhof und der dortige Eingang ist in ///berichten.ausstieg.erlassen. Die Adresse lautet für beide Punkte gleichermaßen Konrad-Adenauer-Ufer 41-45.
Was soll das alles? Konzertveranstalter Chris Sheldrick hatte dasselbe Problem: Lieferorte für Ausrüstung oder Einfahrten für Künstler sind mit postalischen Adressen nicht beschreibbar. Festivals finden nun mal auf großen Flächen statt, und außerhalb dicht besiedelter Gebiete findet man auch kein dichtes Netz von Straßen und Hausadressen. Also suchte er nach einer Idee, jeden Ort der Welt adressierbar zu machen und entwickelte zusammen mit dem Mathematiker Mohan Ganesalingam das alternative Adresssystem what3words. Dieses legt ein 3x3-Meter-Raster über den gesamten Globus und weist jedem Quadrat über einen ausgetüftelten Algorithmus eine eindeutige Adresse, bestehend aus drei Wörtern zu. Im Gegensatz zu geographischen Koordinaten, wie sie beispielsweise ein GPS-System ausgeben könnte, sind die resultierenden Bezeichnungen einprägsam und auch in natürlicher Sprache gut zu transportieren.
Die Wörter werden so gewählt, dass innerstädtische Adressen kürzere Wörter zugewiesen bekommen und ähnlich lautende Kombinationen möglichst weit auseinanderliegen. Auch wenn es vereinzelt Zweifel daran gibt, dass die getroffenen Maßnahmen zur akustischen Unterscheidung ausreichen, um das System in sicherheitskritischen Bereichen einzusetzen, findet es bereits eine breite Anwenderschaft: Als erster Autohersteller kam 2017 Mercedes Benz ins Boot. Ein Blick auf die Products-Seite der offiziellen Website zeigt, dass das System seitdem in die Fahrzeuge zahlreicher anderer Hersteller Einzug gehalten hat, aber auch von Unternehmen aus den Bereichen Mobilität, Logistik, Sport, Sicherheit und natürlich auch Karten-, GIS- und CAD-Anbietern genutzt wird.
what3words ist also in sogenannten Embedded Systems, also fest verbauten Systemen wie Navigationssystemen in Fahrzeugen, enthalten. Andere Implementierungen bringen die Quadrate als Plugin in bestehende Software, seien es Planungstools für den Desktop-Arbeitsplatz oder mobile Apps zur Lokalisierung von vermissten Paraglidern oder zur Drohnensteuerung. Eine eigene mobile Karten-App ist ebenfalls verfügbar, die das Gerät über GPS verortet und in der entsprechenden Rasterzelle lauf der Karte platziert.
Für Entwickler ist what3words vielfältig nutzbar: Die REST API ermöglicht eine Anbindung an alle Systeme, die über HTTP kommunizieren können. Dazu gibt es Bibliotheken für die gängigsten Programmiersprachen, die den Umgang mit der REST API vereinfachen. Unter den GIS-Erweiterungen findet sich auch eine Umsetzung als ArcGIS Locator Service. Alle Programmierschnittstellen können per API-Key genutzt und mit einem kostenlosen Plan getestet werden.
Der what3words GeocodeServer kommt in Ausführungen für jede verfügbare Sprache daher und auch in einer kombinierten Variante. Er kann in ArcGIS-Desktop-Software wie auch in einer ArcGIS-Online-Organisation oder einer ArcGIS-Enterprise-Installation eingehangen werden. Über das Locator-Modul der ArcGIS API for JavaScript kann die URL des jeweiligen GeocodeServers auch direkt im Code verwendet werden. Eine Schritt-für-Schritt-Anleitung findet sich auf der Website von what3words. Zusätzlich bietet das Unternehmen auf seinem GitHub-Account zahlreiche Programmierbeispiele in unterschiedlichen Sprachen, dabei auch die ArcGIS API for JavaScript.
Was wir nun noch brauchen, ist die einfache Einbindung des Systems in eine Webanwendung. Zum Glück gibt es mit dem ArcGIS Experience Builder Developer Edition eine erweiterbare, konfigurierbare WYSIWYG-Applikation für WebGIS-Apps. Der Experience Builder läuft auf dem JavaScript-basierten Server Node.js, der den Node Package Manager (NPM) mitbringt, um externe Abhängigkeiten aus dem Internet zu laden. Ein eben solches Paket bietet what3words zur Nutzung seiner REST API. Dieses haben wir uns bei der Entwicklung eines Widgets zunutze gemacht, das frei auf GitHub verfügbar ist.
Ein Klick auf die Karte schickt den Klickpunkt als Koordinate an die REST API und bekommt ein Antwortobjekt im GeoJSON-Format zurück, das unter anderem die Eckpunkte des getroffenen Quadrats und natürlich die Dreiwort-Adresse enthält. Aus diesen Informationen wird das Quadrat auf die Karte gezeichnet und das Widget mit Informationen gefüllt. Der Wrapper im NPM-Paket von what3words kommt weitgehend korrekt typisiert daher und ist deshalb mit TypeScript komfortabel anwendbar. Hier ein Ausschnitt aus den TypeScript Definitions, der das Antwortobjekt definiert:
export interface LocationProperties {
country: string;
nearestPlace: string;
words: string;
language: string;
map: string;
}
export interface LocationGeoJsonResponse {
bbox: [number, number, number, number];
geometry: {
coordinates: number[];
type: string;
};
type: string;
properties: LocationProperties;
}
Im Backend des Experience Builders, also der Konfigurationsseite, mit der man aus Datenquellen und Widgets seine App zusammenstellt, bietet das what3words Widget zahlreiche Einstelloptionen. Wie üblich muss eine Verbindung zu einem Kartenwidget hergestellt werden, um den Klickpunkt und sichtbaren Extent entgegenzunehmen und im Gegenzug auf die Karte zeichnen zu können. Der bereits erwähnte API Key wird hier hinterlegt und im Hintergrund bei jeder Anfrage an die REST API verwendet.
Direkt beim Start des Backends werden die bei what3words verfügbaren Sprachen abgefragt. Die Einstellung wirkt sich auf die Sprache der Dreiwortadresse aus, die im Widget und auf der Karte erscheint. Weitere Einstellungen beziehen sich auf die Kartenanzeige sowie die Anzeige und das Verhalten des Widgets.
Die REST API bietet eine Funktion zur Rückgabe des Grids, aber in maximal 4x4 km Größe. Das Widget reagiert auf die Zoomstufe der Kartenansicht, prüft in größeren Maßstäben den geodätischen Abstand zweier Eckpunkte. Unterschreitet er 4 km, wird das Grid heruntergeladen und als clientseitiger FeatureLayer angelegt. Dabei werden allen Linien Zahlenwerte zugewiesen, die vom Klickpunkt zum Bildrand hin kontinuierlich ansteigen. Ein Renderer visualisiert anhand dieser Werte ein Grid, das am Bildrand im what3words-eigenen Rot erscheint und zum Klickpunkt hin heller und transparenter wird.
Für die zukünftige Weiterentwicklung des Widgets gibt es eine Reihe an Ideen: Naheliegend ist natürlich die Suche per Texteingabe, also die Geokodierung einer Dreiwort-Adresse. Um eine Vorschlagsfunktion nicht manuell umsetzen zu müssen, sondern dafür das Search-Widget der ArcGIS API for JavaScript einzusetzen, könnte man diese Funktion per ArcGIS Locator Services umsetzen, anstatt die REST API zu verwenden. Weitere Ideen sind, selektierte Vertices oder Punkt-Features in Dreiwort-Adressen umzuwandeln oder zu prüfen, welche Features in dem per Klick getroffenen 3x3-Meter-Quadrat liegen.
Der Quellcode liegt öffentlich auf GitHub. Wer sich beteiligen möchte, kann einen Fork erstellen und nach Entwicklung eines neuen Features einen Merge Request schicken. Nutzt auch gerne die Diskussionsfunktionen auf GitHub oder hier in der Esri Community! Wir sind gespannt auf eure Ideen und vielleicht sogar produktive Einsatzzwecke des Widgets!
Hier gibt's eine englische Version dieses Artikels.
Please follow me and GeoDevGermany on Twitter if you liked this content.