Skip navigation
All Places > GeoDev Germany > Blog > 2014 > July
2014

GeoDev Germany

July 2014 Previous month Next month

Habt Ihr schon die Global Disaster Resilience App Challenge gesehen? Gesucht sind kreative Apps auf Basis der ArcGIS Platform, die den verantwortungsbewußten Umgang mit unseren natürlichen Ressourcen fördern.

 

Registriert Euch und erhaltet von Esri ein umfangreiches Software-Paket zur Lösung Eurer Ideen. Weitere Details zur App Challenge findet Ihr hier. Wir sind gespannt auf Eure Einreichungen. Aber sputet Euch, die Challenge läuft nur noch bis zum 27. August...

 

 

 

Global Disaster Resilience App Challenge.JPG

Ein eigenes Widget für den Web AppBuilder for ArcGIS entwickeln

Anwender können miit dem Web AppBuilder for ArcGIS auch ohne Programmierkenntnisse eine eigene Webanwendung erstellen. Hierzu stellt der AppBuilder eine umfangreiche Bibliothek zur Verfügung, um GIS-Funktionen einzubinden und Layouts für solche Endgeräte zu realisieren. Doch was tun, wenn dies nicht ausreicht? In diesem Fall bietet der WebApp Builder for ArcGIS Entwicklern ein umfangreiches Framework, um eigene Widgets und Themes zu entwickeln. In diesem Blog wollen wir uns die Entwicklung eines eigenen Widgets etwas genauer ansehen.

 

Struktur einer Web AppBuilder Anwendung

Zum Einstieg betrachten wir die Struktur einer fertigen Web AppBuilder Anwendung. Diese erhalten wir, indem wir eine im Builder konfigurierte App downloaden. Der Export enthält einen Ordner mit verschiedenen Dateien und Unterordnern. Kopiert man diesen auf einen eigenen WebServer, ist die Anwendung dort sofort lauffähig. Da wir die Anwendung aber zunächst noch erweitern wollen, werfen wir einen Blick auf die Struktur dieses Ordners. Die Namen der Unterordner geben Aufschluss über ihre Funktion: Die Unterordner „images“ und „themes“ sind für das Layout der Anwendung verantwortlich. Der Ordner „jimu.js“ enthält den Quellcode mit den Kernfunktionalitäten der Anwendung. In libs sind Third-Party-Libraries enthalten. Diese beiden Ordner sollten möglichst nicht bearbeitet werden.

 

Die oben erwähnten GIS-Funktionsbausteine findet man im Ordner „widgets“. In der, im Stammverzeichnis befindlichen, Datei „config.json“ ist beschrieben, wie diese in die Anwendung eingebunden werden. Diese beiden Stellen sind somit die interessantesten für den Entwickler.

 

Ordnerstruktur.png

Abbildung 1: Ordnerinhalte einer exportierten Web-Applikation

Bestandteile eines Widgets

Im Builder werden unter „client\stemapp\widgets\samplewidgets“ einige Templates zum Entwickeln eigener Widgets mitgeliefert. Wir verwenden als Einstiegspunkt das CustomWidgetTemplate, indem wir dieses in den Widget-Ordner unserer Anwendung kopieren, passend benennen und in der Datei „config.json“ zum „widgetPool“ hinzufügen. Betrachten wir die Bestandteile des Templates fällt auf, dass wie auch im Rest der Applikation Seitenaufbau, Layout und Funktionalität getrennt sind. Eine HTML-Datei („Widget.html“) definiert Platzhalter in Form von <div>-Containern, die zwar die Bestandteile der Benutzeroberfläche grob definieren, jedoch üblicherweise keine sichtbaren Inhalte enthalten. Das Aussehen aller UI-Elemente wird über Stylesheets (Unterordner „css“) definiert. Die eigentliche Logik findet sich in den JavaScript-Dateien wieder, wobei der Einstiegspunkt die Datei „Widget.js“ ist.

 

Die Internationalisierung der Inhalte wird umgesetzt durch das Modul „i18n“ [i] des JavaScript-Frameworks „Dojo“, das der ArcGIS API for JavaScript zugrunde liegt. Die dazugehörigen Tabellen befinden sich im Unterordner „nls“ [ii]. Außerdem lassen sich Konfigurationseinstellungen auf Widget-Ebene in der Datei „config.json“ ablegen. Die Datei „manifest.json“ ist zur Angabe von Metainformationen gedacht, wie dem Namen des Widgets, dem angezeigten Label, einer Versionsnummer oder Angaben zum Autor. Die beiden Dateien sind vor allem wichtig wenn das Widget nicht nur in einer Anwendung integriert werden soll, sondern auch dem Builder zur Wiederverwendung in anderen Apps zur Verfügung gestellt wird.

 

Widgetstruktur.png

Abbildung 2: Aufbau eines Widgets

Widget.js – der Lebenszyklus

Ein Widget muss von der Klasse BaseWidget ableiten. Die Grundstruktur dieser Klasse entspricht dem Lebenszyklus eines Widgets: Die Funktion startup() ist dafür gedacht, allerlei Dinge zur „Geburt“ des Widgets zu regeln. So können zum Beispiel GUI-Elemente instanziiert und im HTML-Code platziert werden – noch unsichtbar für den User. Für den weiteren Lebenszyklus des Widgets lassen sich Funktionen definieren, die in bestimmten Situationen ausgeführt werden: onOpen() wird automatisch beim Öffnen des Widgets ausgelöst. Hier können Aktionen abgefahren werden, die direkt im Anschluss an das Öffnen geschehen sollen – beispielsweise Animationen, die der User zu Beginn sehen soll, oder das Starten einer Mediendatei. Weitere Standardsituationen werden durch onMaximize(), onSignIn() oder onClose() abgedeckt. Die Methode destroy() ist für Aufräumarbeiten gedacht. Hier können initialisierte Objekte aus dem Speicher entfernt werden.
Da es sich bei ArcGIS WebApps natürgemäß um geozentrische Anwendungen handelt, ist ein Kartenfenster immer inbegriffen. Für den Widget-Code ist das Kartenobjekt stets per this.map verfügbar. So lassen sich Informationen wie der aktuelle Kartenausschnitt oder die verfügbaren Grafiken auf einem Layer abrufen, das Widget kann auf Aktionen in der Karte reagieren oder die Karte steuern: Die Klasse esri/Map stellt dazu Methoden wie addLayer() oder centerAndZoom() zur Verfügung.

Funktionen und Eventhandler

An dieser Stelle machen wir einen kleinen Exkurs zu JavaScript-Funktionen. Funktionen werden „manuell“ aufgerufen, um beispielsweise eine Berechnung durchzuführen, bevor man mit den Ergebnissen weiterarbeitet. Das Auslagern des Codes aus dem allgemeinen Fluss in eine Funktion oder in eine separate Businessklasse dient der Übersicht, der Wiederverwendbarkeit und dem Einschränken des Gültigkeitsbereichs von Variablen. Tut man das nicht, erhält man den vielzitierten „Spaghetticode“ – ein lineares, nicht wartbares Monster mit wachsender Anzahl an unerwünschten Nebeneffekten, proportional zur Länge des Codes.

 

Eventhandler sind spezielle Funktionen, die an andere Objekte angeschlossen werden und darauf reagieren. Sie sind besonders praktisch bei asynchronen Vorgängen, und eine moderne JavaScript-Applikation ist voll davon: Jeder Zugriff auf externe Ressourcen, sei es das Laden von referenziertem JavaScript-Code, das Parsen eines RSS-Feeds oder die Ausführung einer Geoprocessing-Funktion, wird üblicherweise asynchron ausgeführt, da die Dauer einer solchen Aktion nicht vorhersehbar ist. Ohne Events bliebe einem nichts anderes übrig als den kompletten Programmfluss auf Eis zu legen und auf die Antwort zu warten. Bei der asynchronen Ausführung läuft die Applikation weiter, die GUI reagiert auf Benutzereingaben und beim Eintreffen der Daten wird ein Event gefeuert. Das kann man sich vorstellen wie ein Rauchzeichen: Unser Indianer hinter dem Hügel ist der angeschlossene Eventhandler: Dieser sieht das gefeuerte Event, und kann z.B. ein GUI-Element mit den übermittelten Daten füllen und es gleichzeitig aktivieren, sodass es von nun an für Benutzerinteraktionen zur Verfügung steht.

 

Wer jetzt besonders gut aufgepasst hat, hat sicher schon verstanden, dass die im vorigen Kapitel erwähnten Standard-Funktionen nichts anderes sind als EventHandler, die auf Events der WebApp reagieren: Der Indianer hinter dem Widget-Hügel weiß zwar nicht, wann und wo sie gefeuert werden, aber er kann darauf reagieren.

 

Abgesehen davon können aber in der Widget-Klasse nach Belieben weitere Funktionen und Eventhandler definiert werden. Dabei steht die komplette Bandbreite des ArcGIS API for JavaScript [iii] und des Dojo Toolkits [iv] zur Verfügung. Auch externe JavaScript Bibliotheken lassen sich problemlos einbinden.

 

Einbinden in den Web AppBuilder

Wir haben nun eine, mit Hilfe des Web AppBuilder erstellte, Anwendung um eigenen Code erweitert. Haben wir den Builder nur als Startpunkt verwendet um möglichst schnell und einfach eine WebApp zu erstellen, sind wir an dieser Stelle fertig. Soll unser Funktionsbaustein aber auch in anderen Anwendungen wiederverwendet werden können, müssen wir das Widget in das Unterverzeichnis „client\stemapp\widgets“ des Web AppBuilder kopieren. Dabei ist es wichtig die Datei „manifest.json“ korrekt zu pflegen, denn daraus liest der Builder die Attribute des Widgets.

 

Los geht’s

Mit diesem Wissen können Sie loslegen und Ihr eigenes Widget entwickeln. Jetzt brauchen Sie nur noch die passende Idee… Sollten Sie noch keinen konkreten Anwendungsfall haben, sehen Sie sich doch einmal im Internet nach Datenquellen um! Es gibt viele Webseiten, die RSS-Feeds oder APIs anbieten, über die sich Objekte mit Geoinformationen abrufen lassen. Je aussagekräftiger die Attributdaten, desto spannendere Geschichten lassen sich stricken, indem man sie verknüpft, filtert, auf der Benutzeroberfläche präsentiert und den User damit interagieren lässt.

Web AppBuilder for ArcGIS ist derzeit als Public Beta (Version 2) verfügbar. Dabei handelt es sich um eine Developer Edition, die auf eigener Hardware läuft. Nach der Registrierung auf http://betacommunity.esri.com erhält man den AppBuilder mit einer ausführlichen Dokumentation. In dieser ist auch ein umfangreicher Developer Guide enthalten.

 

 

 

Christine Brunner, Niklas Köhn, Esri Germany

 

 


[i] i18n: Kurzform für „internationalization“: 18 Buchstaben zwischen „i“ und „n“

[ii] nls: Kurzform für „National Language Support“

[iii] Eine wichtige Anlaufstelle für Entwickler mit detaillierten Informationen über die Verwendung aller Klassen finden Sie in der API-Referenz: http://developers.arcgis.com/javascript

[iv] Auch hier gibt es API-Referenz für Entwickler: http://dojotoolkit.org

Die neue Version bietet unter anderem integrierten Support für OAuth, erweiterte Popups, Label Layer, außerdem natürlich Bugfixes und weitere Verbesserungen. Dojo wird nun in der Version 1.9.1 unterstützt.

 

 

Details findet Ihr unter https://developers.arcgis.com/javascript/jshelp/whats_new.html.

 

Was haltet Ihr von der neuen Version? Was ist gut, was fehlt?

RiemerBug

Maptime BER

Posted by RiemerBug Jul 18, 2014

In der Berlin hat sich ebenfalls eine MeetUp Gruppe ( Maptime BER ) gegründet, die sie dem Spaß an Webmaps und digitalen Karten verschrieben hat.

Näheres findet ihr auf der MeetUp Website.

Der erste Termin wird im September/Oktober sein, genauer Termien und Ort müssen noch bestätigt werden

Unseren heutigen Gastbeitrag hat Andreas Forstmaier verfasst. Andreas hat zwischen Abitur und Studium den Reiseblog isTraveling.org mit der ArcGIS API for JavaScript entwickelt.

 

Als ich mir nach meinem Abitur 2012 ein Jahr freinahm, um die Welt zu bereisen, wollte ich meine Erlebnisse irgendwie festhalten und gleichzeitig zeitnah mit meinen Verwandten und Freunden daheim teilen. Deswegen entschied ich mich, einen Reiseblog zu schreiben. Es gab bereits eine Auswahl an Blogplattformen, jedoch vermisste ich bei allen das Wo. Ich wollte einen Blog, der zeigte, wo ich schon war und wo ich mich gerade befinde. Um dies übersichtlich darzustellen, benötigte ich eine Karte. Da ich im Internet keinen bestehenden Blog finden konnte, der meinen Vorstellungen entsprach, programmierte ich mein eigenes Blogsystem. So entstand das Projekt isTraveling.org.

 

Eine entscheidende Frage bei der Umsetzung war für mich die nach der Technologie. Dabei entschied ich mich aus zwei Gründen für die ArcGIS API for JavaScript: Zum einen wegen eines aus meiner Sicht entwicklerfreundlichen Lizenzmodells, zum anderen wegen der großen Auswahl an Hintergrundkarten.

 

Die Blog-Plattform

Der Fokus der neuen Blogplattform liegt auf der Karte, auf der die Reiseroute als eine Linie dargestellt wird, die die einzelnen Stationen verbindet. Durch das Klicken auf die einzelnen Stationen kann man die zugehörigen Einträge lesen und so durch den Blog navigieren.

 

 

Eine intuitive Benutzeroberfläche dient dem Benutzer bei der Erstellung seines Reiseblogs. Angemeldete Nutzer können für jeden Ort, den sie besucht haben, auf einer Karte einen Marker setzen und so ihre Reiseroute aufzeichnen. Eingetippte Ortsnamen werden im Hintergrund automatisch in Positionsdaten umgerechnet und auf der Karte markiert. Zu jedem markierten Ort können Bilder und Texte hinzugefügt werden.

 

Wer ein internetfähiges Smartphone oder Tablet besitzt, kann zudem über die mobile Web-Applikation seinen Blog von unterwegs mit neuen Bildern oder Texten füllen. Zusätzlich können die Blogeinträge als Webkarte nach ArcGIS Online exportiert werden, um sie auch dort mit anderen Nutzern zu teilen und um weiteren Inhalt hinzuzufügen.

 

Wie funktioniert isTraveling.org?

Nach der Anmeldung startet ihr mit einer noch fast leeren Karte. Um diese langsam mit Inhalt zu füllen, klickt ihr auf Neuen Ort hinzufügen. Nun könnt ihr entweder durch Klicken auf die gewünschte Stelle auf der Karte einen Ort hinzufügen oder ihr tippt einfach einen Ortsnamen in das Titelfeld. Dieser wird dann in Positionsdaten umgewandelt, georeferenziert, und automatisch auf der Karte markiert.

 

 

Wenn ihr nun den Eintrag zusätzlich mit Bildern ergänzen möchtet, könnt ihr durch einen Klick auf Bilder hochladen den Upload-Manager öffnen und dort die gewünschten Bilder auswählen und hochladen.

 

 

Sobald der Blogeintrag fertig ist, reicht ein Klick auf Speichern, um den neuen Ort zur Karte hinzuzufügen. So wächst eure Reiseroute immer mehr und der Blog füllt sich. Ein Beispiel, wie so ein fertiger Blog aussehen kann, findet ihr hier.

 

 

Wenn ihr auch gerne reist und eure Erlebnisse schnell und einfach im Internet präsentieren möchtet, meldet euch doch gleich an und probiert die Seite aus. Ich freue mich über euer Feedback zu IsTraveling.org!

 

Andreas Forstmaier

Student an der TU München

AndreasForstmaier@gmx.de

isTraveling.org

Um Webanwendungen mit der ArcGIS API for JavaScript zu erstellen, braucht ihr nicht unbedingt Programmierkenntnisse. Oft reicht es, öffentliche Codebeispiele zu verstehen und sie anzupassen. Heute möchte ich auf ein Werkzeug eingehen, das beim Erstellen der Webanwendungen sehr hilfreich ist: die Sandbox. Mit ihr kann man Codes im Browser einfach und anschaulich testen, während Server und Daten unverändert bleiben.

 

Werfen wir einen Blick auf die Codebeispiele auf den Seiten der ArcGIS API for JavaScript. Die Beispiele sind thematisch gegliedert, zum Beispiel nach Analyse, Geocoding oder Routing. Beim Klick auf eines der Beispiele habt ihr fast immer die Option Explore in the Sandbox. Bei der Auswahl dieser Option öffnet sich die Sandbox als zweigeteilter Viewer: Links erscheint der Code, rechts die Anwendung. Wenn ihr links den Code ändert, seht ihr rechts in der Anwendung, was die Codeänderungen bewirken.

 

Anwendungsbeispiel: Was kann ich sehen, wenn ich auf der Zugspitze stehe?

Den Einsatz der Sandbox stelle ich anhand des Codebeispiels Viewshed vor, das das Sichtfeld von einem gewissen Punkt aus berechnet.

 

 

Auf der Webseite zu diesem Beispiel gibt es eine Beschreibung, was in der Anwendung mit dem jetzigen Code passiert: Beim Klick auf die Karte wird mit einem von Esri zur Verfügung gestellten Geoprocessing-Dienstes berechnet, welche Bereiche bei einer Sichtweite von 5 Meilen vom geklickten Punkt aus zu sehen sind. Dabei befindet sich die Kartenmitte beim Laden des Dokuments in Kalifornien und die Hintergrundkarte ist eine Straßenkarte.

 

Ich möchte die Karte nun auf meine Bedürfnisse anpassen: Nehmen wir an, wir haben heute in den Alpen eine Sicht von 20 Kilometern. Mich interessiert, welche Gegenden ich sehen kann, wenn ich jetzt auf die Zugspitze steige. Um die Koordinaten der Zugspitze und jedes anderen Punkts auf der Erde zu ermitteln, können wir dieses hilfreiche Beispiel aus der ArcGIS API for JavaScript nutzen. Um anschaulich zu sehen, was Änderungen im Code bewirken, klicke ich im Viewshed-Beispiel auf Explore in the Sandbox.

 

 

Zunächst will ich den Kartenmittelpunkt von San Diego auf die Zugspitze verschieben. Die Mitte der Karte wird im Parameter center definiert, der immer geografische X- und Y-Koordinaten enthält. Ich ändere den Wert center: [-122.436, 37.73] in center: [10.99393, 47.42118], also die Koordinaten der Zugspitze. Klicke ich jetzt auf die orange Schaltfläche RUN rechts oben, werden die Änderungen im Code übernommen und der Kartenmittelpunkt ändert sich direkt im Kartenfenster. Um nun noch als Hintergrundkarte statt einer Straßenkarte eine topografische Karte anzeigen zu lassen, ändern wir basemap: "streets" in basemap: "topo".

 

Nun will ich die Veränderungen der Sichtweite durchführen, die der öffentlich verfügbare Geoprocessing-Dienst in folgendem Codeblock übermittelt bekommt:

vsDistance.distance = 5;

vsDistance.units = "esriMiles";

 

Jetzt muss ich nur noch die Werte bei distance zu 20 und units zu "esriKilometers" ändern. Natürlich lässt sich das Layout der Karte weiter beliebig verändern. Beispielsweise kann ich in den Tag <div id="info" class="esriSimpleSlider"> den Inhalt des Textfelds unten links auf der Karte modifizieren, sodass der Benutzer der Anwendung genau weiß, was ihn erwartet.

 

 

Sobald ich mit den Änderungen der Anwendungen fertig und zufrieden bin, kann ich den Code herunterladen. Die HTML-Datei mit dem JavaScript-Code, die in der linken Seite der Sandbox steht, kann ich nun als funktionsfähige Anwendung im Internet zur Verfügung stellen. Zur Erinnerung: Dazu musste ich nicht from scratch Code schreiben und die Anwendung entwerfen, sondern nur ein paar Änderungen im bestehenden Code machen. Außerdem benötigte ich dazu keine Software. Lediglich einen Webbrowser.

 

Weitere Anwendungsfälle

Das vorgestellte Beispiel ist ein einfaches Modell. Und gerade in den Alpen variiert die Sichtweite aufgrund vieler Faktoren zeitlich und räumlich stark. Es sollte jedoch auch klar geworden sein, dass den Anpassungsmöglichkeiten mit der Sandbox kaum Grenzen gesetzt sind: Ihr könnt nicht nur Karteneigenschaften und die Aus- und Eingabeparameter bestehender Geoprocessing-Dienste ändern, sondern außerdem in den bestehenden Beispielcode völlig andere Dienste einbinden, die andere Aufgaben erledigen, als die Beispielwendungen.

 

Beim EDC Entwicklerforum an der TU Dresden zu „Geoprocessing im Web“ haben wir die Anwendung als Grundlage genommen, die über einen Yahoo!-Dienst Pizzerien in Kalifornien in einem gewissen Fahrtzeit-Polygon sucht. Mit ein paar Anpassungen im ursprünglichen Code haben wir eine Anwendung erstellt, die über einen anderen Suchdienst (Nominatim) aus der umfangreichen OpenStreetMap-Datenbasis Schulen in Dresden findet, die in einer bestimmten Zeit fußläufig zu erreichen sind.

 

Eine Übersicht über frei verfügbare Geometrie-Dienste von Esri, die sich in JavaScript-Anwendungen integrieren lassen, gibt es hier.

Immer mehr Menschen verwenden Smartphones und Tablets, wenn sie unterwegs sind. Durch die permanente Ermittlung des eigenen Standorts auf diesen Geräten eröffnen sich vielfältige und interessante Anwendungsmöglichkeiten. Zum Beispiel können dem Benutzer spezifische Benachrichtigungen zu seinem aktuellen Aufenthaltsort gesendet werden. So können etwa Touristen über Sehenswürdigkeiten informiert werden, sobald sie in ihre Nähe kommen. Verkehrsteilnehmer bekommen eine Nachricht, wenn sie sich einer gesperrten Straße nähern. Kunden können maßgeschneiderte Angebote zugesendet werden, sobald sie ein Geschäft betreten. Das Spektrum vergleichbarer Szenarien ist riesig.

 

Tourist in der Nähe des Kölner Doms erhält Nachricht

 

Esri hat für die Realisierung den ArcGIS Geotrigger Service entwickelt. Damit können ortsbezogene Benachrichtigungen in mobilen Apps mit Android, iOS oder JavaScript verwendet werden. Der Geotrigger Service ist ein cloudbasierter Dienst, mit dem sogenannte Geotrigger angelegt werden. Dies sind Flächen, mit denen Nachrichten oder Aktionen verknüpft sind. Die Fläche des Geotriggers kann als Kreis über Mittelpunkt und Radius oder als Polygon definiert werden. Tritt der Benutzer mit dem mobilen Gerät in die Fläche des Geotriggers ein oder aus ihr heraus, so erhält er eine entsprechende Push-Benachrichtigung auf seinem Gerät. Zur zeitlichen Eingrenzung können Zeitbereiche definiert werden, in denen die Geotrigger aktiv sind, sodass man nur in diesen Zeiträumen eine Benachrichtigung erhält. Die Geotrigger werden dabei durch Tags den mobilen Geräten zugeordnet. Es ist auch möglich, eine Benachrichtigung an einen Server zu schicken, um dort eigene Funktionalität aufzurufen.

 

 

Um den ArcGIS Geotrigger Service anzusprechen, verwendet man die Geotrigger Service API. Sie basiert auf HTTP-Requests und auf Antworten im JSON-Format. Ein HTTP-Request zum Anlegen eines Geotriggers könnte beispielsweise wie folgt aussehen:

 

Die API verwendet OAuth 2.0 für die Authentifizierung. Man kann über die API Geotrigger anlegen, ändern und löschen und Informationen über Trigger, Tags und die Geräteposition abfragen. Zum grafischen Anlegen der Geotrigger gibt es eine fertige Webapplikation, mit der das Erstellen und Bearbeiten der Geotrigger sehr einfach möglich ist.

 

Für Android und iOS gibt es SDKs, mit denen Entwickler die Geotrigger-Funktionalität in mobilen Apps realisieren können. Mit diesen SDKs können auch bestehende Apps um Geotrigger-Funktionalität erweitert werden. Die Kommunikation mit dem Server erfolgt auch in den SDKs über die Geotrigger Service API. Die Apps verwenden dabei die plattformspezifischen Benachrichtigungsdienste Google Cloud Messaging für Android und Apple Push Notification Service für iOS. Die mobilen Geräte senden beim Verwenden der Apps kontinuierlich ihre Positionsdaten an den Geotrigger Service. Durch eine intelligente Implementierung wird der Batterieverbrauch der mobilen Geräte dabei auf ein Minimum reduziert. Dafür kann zwischen unterschiedlichen Trackingprofilen gewechselt werden (Fine, Adaptive, Rough, Off). Bei großer Entfernung zum Geotrigger ist dadurch der Stromverbrauch gering und nur nahe des Triggers wird er höher.

 

Softwareentwickler, die den ArcGIS Geotrigger Service in ihrer App verwenden wollen, finden weitere Informationen hier.

 

Rainald Suchan, Esri Deutschland.

Idee

Seit 2006 verbreiten Millionen User weltweit ihre Gedanken und Aufenthaltsorte über den Microblogging-Dienst Twitter. Zu fast jedem Thema lassen sich dort Beiträge finden, die zum großen Teil mit Geoinformationen versehen sind. Das Portal setlist.fm sammelt Informationen über Konzerte, beteiligte Künstler und gespielte Songs.

 

Die beiden voneinander unabhängigen Crowd-Sourcing-Datenquellen wurden für das Projekt “Concert Telling Tweets” kombiniert. Die entstandene Karte zeigt, wie sich das Konzert in Tweets rund um den Veranstaltungsort widerspiegelt und gibt ein Stimmungsbild über das Interesse der User an einem Event ab.

Das System in Schlagworten

 

Umsetzung

Ein Webservice fragt alle bei setlist.fm neu erfassten Konzerte mit den relevanten Informationen ab und speichert diese in einem Hosted Feature Service auf ArcGIS Online. Parallel dazu werden über den ArcGIS GeoEventProcessor for Server alle öffentlich zugänglichen Tweets mit Geoinformation gesammelt, in denen die Künstler der gesammelten Konzerte erwähnt werden. Berücksichtigt werden nur diejenigen Tweets, die am Veranstaltungstag selbst oder am Tag danach erstellt wurden.

 

Beide Datenquellen werden in Echtzeit abgefragt und direkt in ArcGIS Online gespeichert. Um die Datenmenge einzugrenzen, werden alle Tweets, die älter als zehn Tage sind, automatisch wieder gelöscht.

Zusammenspiel technischer Komponenten (hier: GEP = GeoEventProcessor; AGOL = ArcGIS Online)

 

Anwendung

Die Konzerte auf der Karte

 

Der JavaScript Web-Client zeigt alle Konzerte, die zu einem ausgewählten Datum innerhalb des aktuellen Kartenausschnitts stattgefunden haben. Die Anzeige ist aktualisierbar und weltweit anwendbar. Der Startausschnitt wird auf Basis der Geolocation des Browsers gewählt. Wird diese nicht mitgeteilt, wird Deutschland als Standard gesetzt. Rechts werden die Künstler außerdem in einer Liste aufgeführt, die sich sowohl alphabetisch als auch nach Häufigkeit von "nahen Tweets" (innerhalb eines Umkreises von 1000 Kilometern vom Veranstaltungsort) sortieren lässt.

 

Anzeige der Tweets zu einem Konzert

 

Durch Auswahl eines Künstlers werden neben dem Veranstaltungsort alle Tweets in der Karte angezeigt, die einen Bezug zum Künstler haben. Der blaue Kreis markiert den Bereich der Tweets innerhalb von 1000 Kilometern Entfernung zum Veranstaltungsort. Beim Klick auf einen Tweet in der Karte wird dessen Inhalt in einem Pop-up dargestellt.

 

Bei der entwickelten JavaScript-Komponente handelt es sich um ein Widget für die konfigurierbare ArcGIS Web Application, wie sie vom ArcGIS Web AppBuilder (derzeit im Betastadium) exportiert wird.

 

Zur Applikation “Concert Telling Tweets” geht’s hier. Auf ArcGIS Online unter Concert Telling Tweets gibt es ebenfalls den Link zur Applikation und eine deutsche und eine englische Beschreibung der Applikation.

 

 

Rainer Herzog & Niklas Köhn, Esri Deutschland

Filter Blog

By date: By tag: