Echtzeitdaten können über sehr unterschiedliche Protokolle und in verschiedenen Datenformaten bereitgestellt werden. Diese Protokolle können dann von anderen Anwendungen gelesen, verarbeitet und gespeichert werden. Zu den gängigen Protokollen gehören z.B. REST-API, WebSockets, MQTT, RabbitMQ, Kafka u.a.
In unserem fiktiven Use Case (lese dazu Teil 1 unserer Reihe) wollen wir die aktuelle Verkehrssituation in Münster abbilden und die wichtigsten Daten zur Busverspätung abbilden. Anhand dieser Fragestellung können wir festlegen, was wir mit unserer Echtzeitanwendung abbilden wollen und welche Daten wir dafür benötigen.
Die Stadt Münster gemeinsam mit Stadtwerke Münster stellen als Smart City sehr gute öffentliche Daten zur Verfügung, die wir für unseren Use Case gut nutzen können. Viele zusätzliche Layer können direkt aus dem Esri Living Atlas im Map Viewer abgerufen werden. Darauf gehen wir in späteren Teilen genauer ein.
Für unseren Use Case passen Daten zu den aktuellen Buspositionen in Echtzeit perfekt. Hierbei handelt es sich um aktuelle GPS-Positionsmeldungen der Busse im GeoJSON-Format, die sich alle 3 Sekunden aktualisieren. Diese Daten werden über eine REST-API von der Stadtwerke Münster in Zusammenarbeit mit con terra GmbH frei zugänglich bereitgestellt (herzlichen Dank an dieser Stelle!).
Bevor wir durch die einzelnen Schritte der Datenimplementierung in ArcGIS GeoEvent Server durchgehen, ist es ratsam, die wichtigsten Informationen über die REST API und GeoJSON-Format zu verstehen.
Falls Sie mit diesen Themen bereits vertraut sind, gehen Sie direkt zum nächsten Punkt.
Eine REST-API (Representational State Transfer Application Programming Interface) ist ein Daten-Architekturstil für die Entwicklung von Netzwerk-Anwendungen und Datenkommunikation. Sie zeichnet sich durch eine einfache und einheitliche Architektur, Skalierbarkeit und Flexibilität aus und wird deshalb im Kontext der Echtzeitdaten oft angewendet.
JSON (JavaScript Object Notation) Format ist besonders verbreitet, weil es sowohl von Menschen als auch von Maschinen leicht gelesen werden kann. Die Datenfilterung wird direkt in der URL vorgenommen.
Sie können mal versuchen, den Datensatz im Map Viewer als GeoJSON hinzuzufügen und werden tatsächlich erfolgreich sein! Allerdings können wir die Daten so nur alle 30 Sekunden aktualisieren und nichts prozessieren oder speichern, weshalb die GeoJSON Query-Layer Funktionalität für unseren Anwendungsfall nicht ausreicht.
Dadurch, dass die Buspositionen sich alle paar Sekunden aktualisieren, müssen wir den ArcGIS GeoEvent Server nutzen. Dieser ist in der Lage, hochfrequente Daten von Drittsystemen abzufragen, zu analysieren und sofort auf der Karte zu Visualisieren oder sie an weitere Systeme weiterzuleiten.
Als Alterativ-Werkzeug kann auch ArcGIS Velocity - unsere SaaS mit vergleichbaren Funktionalitäten - genutzt werden.
Nachfolgend leiten wir Schritt für Schritt durch den Prozess der Datenimplementierung in ArcGIS GeoEvent Server.
Nun legen wir los. Bevor wir mit dem Input starten, sollten wir kontrollieren, ob alle Verbindungen funktionieren. Zwei Aspekte sollten beachtet werden:
Im GeoEvent Manager unter Site>Data Store können wir prüfen, ob eine valide Verbindung zu ArcGIS Enterprise besteht. Dies sehen wir bei der Status-Meldung. Falls noch keine Verbindung aufgebaut wurde, sehen wir ein rotes Symbol (siehe Abb. unten) – alles klar, hier müssen wir was tun.
Über das✏️-Symbol gelangen wir in die Registrierungsmaske und können hier unseren Named-User der ArcGIS Enterprise Organisation mit den Zugangsdaten eingeben. Der Named-User muss mindestens über Publisher-Rechte im ArcGIS Enterprise Portal verfügen. Mehr dazu kannst Du hier nachlesen.
Nach einer erfolgreichen Anmeldung wird sich der Status sofort ändern - perfekt!
Nun checken wir noch den Big Data Store. Unter Site > Spatiotemporal Big Data Store prüfen wir, ob es eine gültige Verbindung zu einem Big Data Store gibt. Sobald Sie ein Spatiotemporal Big Data Store konfiguriert haben, wird dieser automatisch unter der eingerichteten Data Store Verbindung (hier Default) erscheinen.
Für den Import von Echtzeitdaten muss im GeoEvent Server ein Input-Konnektor konfiguriert werden. Dazu gehen wir zurück auf den Manager Reiter und klicken auf Add Input.
Der GeoEvent Server hat zahlreiche Out-of-the Box Konnektoren, mit denen sich die gängigsten Datenformate wie JSON, GeoJSON, Text, RSS oder XML von verschiedenen Endpunkten leicht importieren lassen.
Unsere Echtzeit-Beispieldaten liegen im GeoJSON-Format vor und sind direkt über die API abrufbar. Hierfür werden wir deshalb den „Poll an external Website für GeoGSON“ verwenden. In der Eingabemaske müssen wir einige Parameter ausfüllen, damit die Daten richtig ankommen.
Auf der rechten Fensterseite könnt ihr übrigens Erklärungen zum jeweiligen Parameter nachgelesen, sobald ihr die Maus über das Feld bewegt.
Alle anderen Parameter können in diesem Fall einfach übernommen werden. Eine Beschreibung der Parameter können Sie hier nachlesen.
Nun speichern wir den Konnektor und müssen den Input nur starten. Das macht man mit dem
Sobald der Input läuft, verändern sich auch die Statistiken. Sie bedeuten Folgendes:
Nun kommen die einzelnen Buspositionen an – Klasse! Wir sollten das Ganze aber noch ein bisschen aufhübschen. Lasst uns dafür einen Service anlegen, um zu schauen, was für Daten wir nun erhalten. Dafür klicken wir auf Add Service und gib dem Service einen Namen, ich habe es „busradar-muenster“ genannt.
Nach dem Erstellen gelangt man in eine Arbeitsoberfläche, die noch leer ist (das wird sich natürlich ändern).
Apropo Daten, diese wollen wir ja sehen. Dafür müssen wir im Service unseren neu erstellten Konnektor hinzufügen und ein Output erstellen. Unter den Inputs suche ich nun meinen Konnektor „busradar-muenster-geojson-poll-in“ und schiebe ihn per Drag Drop in das Arbeitsfeld.
Tipp
Und jetzt kommt ein absoluter Tipp für alle, die einen neuen Service bauen: erstellet einen Output-Konnektor für Testzwecke, um die Daten während des Entwicklungsprozesses zu überprüfen und keine unnötigen Daten zu speichern.
Dafür eignet sich am besten der Konnektor „Push Text to an External TCP Socket“, mit dem man quasi nichts falsch machen kann. Er kann eigentlich immer gestoppt sein, denn alle Daten im Sampler können abgelesen werden. Den „richtigen“ Output erstellen wir in Teil 4 dieser Blogreihe (folgt bald).
Man kann Konnektoren übrigens auch direkt in der Service Oberfläche erstellen. Dafür ein Doppelklick auf New Elements > Output und in diesem Fall „Push Text to an External TCP Socket“ auswählen.
Wir lassen alle Einstellungen so wie sie sind, weil das Ganze eben nur für Testzwecke ist, und klicken auf „Speichern“. Dieser Konnektor erscheint ebenfalls in der Arbeitsfläche. Nun verbinden wir den Input- und Output-Konnektor und klicken auf „Publish“, um es zu speichern und gleichzeitig zu starten.
Nach dem Starten gehen die Statistiken hoch und jetzt können wir uns mit dem Sampler die Daten anschauen. Dafür klicken wir mit der rechten Maustaste auf den Vierbindungspfeil und wählen „Sample Route“. Im Sampler werden dann die ersten zehn Events im JSON Format angezeigt. Wir können aber auch eine Kartenansicht wählen, um zu schauen, ob die Objekte richtig verortet sind.
Wenn wir uns die Daten von einem Event im Sampler genauer anschauen, dann sehen wir, dass sie genau so in der API aussehen. Das bedeutet, dass GeoEvent das Datenschema richtig erkannt hat.
{
"GED_Name": "busradar-muenster-in-temp",
"linienid": "15",
"richtungsid": "2",
"akthst": "44211",
"delay": 403.0,
"richtungstext": "Albachten Bahnhof",
"starthst": "45310",
"betriebstag": "2024-08-21",
"sequenz": 34.0,
"linientext": "15",
"fahrzeugid": "5703",
"fahrtstatus": "Ist",
"fahrtbezeichner": "210824_100008_9_15_8",
"abfahrtstart": "1724241840",
"visfahrplanlagezst": 1.724245244E9,
"ankunftziel": "1724245920",
"zielhst": "46350",
"geometry": {
"x": 7.5918861,
"y": 51.9300903,
"spatialReference": {
"wkid": 4326
} Datenschemata sind ein sehr wichtiger Aspekt, wenn es um Echtzeitdaten geht. Zu Beginn passieren hier am häufigsten Fehler. Es ist sehr wichtig, dass GeoEvent Server weiß, welche Daten und in welchem Format ankommen.
Im Falle von JSON bzw. GeoJSON müssen die Attribute im Datenschema mit den Feldnamen in der API übereinstimmen. Außerdem muss der korrekte Datentyp für die Attribute ausgewählt werden, damit der GeoEvent Server die Daten richtig lesen kann. In späteren Analysen können Bezeichnungen, Datenformate angepasst und unnötige Felder gelöscht werden.
Ein Input-Konnektor greift im Prinzip alle paar Sekunden auf die Datenquelle bzw. Protokoll zu und parsed, also interpretiert, das entsprechende Datenschema: Welche Attribute gibt es? In welchem Format werden sie geschrieben? Der Konnektor muss das Datenschema kennen, um die Informationen richtig lesen zu können.
Beim Erstellen des Input Konnektors haben wir ein automatisches Datenschema generieren lassen. Dieses Datenschema können wir unter GeoEvent Definitions ansehen und bearbeiten. Dazu gehen wir in unserem Service zu Site Settings > GeoEvent Definitions und suchen nach „busradar-muenster-in-temp“. Unter Owner Name sehen wir, dass diese Definition autogeneriert ist und durch unseren Input-Konnektor verwendet wird.
Anstelle einer automatisch generierten Definition, ist es ratsam, eine fixe Definition für einen Input-Konnektor festzulegen, die sich nicht ändert und wo die Datentypen und Tags korrekt konfiguriert sind. Deshalb schließen wir diese Ansicht und machen eine Kopie der Definition, indem wir in der Liste aller Definitionen auf folgendes Symbol klicken:
Es öffnet sich die Definitionsmaske, die wir nun verändern wollen:
Im letzten Schritt ersetzten wir die automatisch erstellte Definition im Input-Konnektor. Dafür klicken wir zweimal auf den grünen Input-Konnektor und verändern die Einstellungen:
Nun speichern wir den Konnektor sowie den Service („Publish“-Button) und schauen im Sampler, ob sich die Daten geändert haben. Tatsächlich stehen nun in den drei Zeit-Feldern nicht mehr Zahlen, sondern Daten.
Aber Achtung: Wenn wir genauer hinsehen, fällt auf, dass der Zeitstempel circa vier Jahre in der Vergangenheit liegt. Das müssen wir beim nächsten Mal noch unbedingt beseitigen. Aber für heute reicht es erstmal. Der dritte Teil der Reihe folgt in Kürze auf unserem Blog.
Sind bei Dir beim Durchlesen dieses Blogs Fragen entstanden? Dann nutze gerne dafür die Kommentar-Funktion unten!
Liest noch unbedingt den ersten Beitrag dieser vierteiligen Blogreihe. Dort beschreiben wir, was man bei der Arbeit mit Echtzeitdaten beachten muss und erklären, wofür wir uns jetzt mit all den Konnektoren und Datenschemata beschäftigen.
Ihr wollt tiefer in die Welt der Geospatial Analytics eintauchen?
Geospatial Analytics – die Verbindung von Data Science und räumlichen Daten – spielt eine entscheidende Rolle bei der Enthüllung von Mustern, Trends und Zusammenhängen, die in herkömmlichen Analysen oft verborgen bleiben.
In unserem E-Book erfahrt Ihr im Detail, welche Chancen und Möglichkeiten Euch Geoanalysen bieten.