Stream Services - Visualisieren von Echtzeitdaten (ohne Verzögerung)
Was ist ein Stream Service?
Neben den bekannten und schon lange existierenden Map- & Feature Services gibt es seit ein paar Jahren (erster Release mit 10.3.) noch einen neuen Servicetyp in der ArcGIS Welt, welcher primär zur effizienten Visualisierung von Echtzeitdaten entwickelt wurde - der Stream Service.
Der Stream Service ist an den ArcGIS GeoEvent Server gekoppelt, Esri's Softwarelösung um Echtzeitdatenströme zu integrieren, in Echtzeit eventbasierte Analysen auf den einkommenden Daten durchzuführen und diese anschließend zu verteilen, sprich innerhalb und außerhalb der ArcGIS Plattform nutzbar zu machen. Dabei spielt natürlich die Anforderung die Daten in Echtzeit nicht nur zu prozessieren sondern auch zu visualisieren eine wichtige Rolle. Aufgrund dieser Anforderung hat sich das Entwicklungsteam rund um den GeoEvent Server Gedanken gemacht, wie man die Latenzzeit bei der Visualisierung von dynamischen Daten verringern kann um nicht nur zu zeigen WO etwas geschieht sondern auch direkt WENN es geschieht!
Ein Beispiel für einen Stream Service, welcher die aktuelle Position der International Space Station von einer API abfragt und visualisiert kann hier angeschaut werden.
Ein neues Konzept zur Visualisierung von dynamischen Daten!
Klassischerweise sind die Daten welche einem dynamischen Feature Services zugrunde liegen in einer Enterprise Geodatabase (EGDB) oder anderen Form von Datenspeicher wie z.B. dem Spatiotemporal Big Data Store (SBDS*) gespeichert. Dies bedeutet, dass bei der Visualisierung der Klient, also z.B. unsere Web Anwendung, in regelmäßigen Abständen den aktuellen Status aus dem Datenspeicher abfragen muss, um die Visualisierung der Features auf der Karte zu aktualisieren. In diesem Zusammenhang spricht man von Polling was einem Aktualisierungsintervall gleich kommt, welches somit eine Verzögerung in der Prozessierung von Echtzeitdatenströmen verursacht nachdem der GeoEvent Server diese verarbeitet und in die Datenbank geschrieben hat.
Um diese Latenzzeit zu minimieren, baut der Stream Server auf ein Konzept auf, bei welchem die Daten nicht erst in eine Datenbank geschrieben werden sondern direkt an den Klienten gepusht werden. Hierzu werden WebSocket Verbindungen direkt zwischen dem Stream Server und dem Stream Layer im Klienten aufgebaut, über welche die Features ohne jegliche Verzögerung übertragen und visualisiert werden!
Persistieren der Daten
Vielleicht kommt nun die Frage auf, was passiert wenn sich ein Klient initial mit dem Stream Server verbindet und die existierenden Daten nicht gespeichert wurden? Dies würde bedeuten, dass der Klient existierende Features erst visualisieren kann wenn ein neues Event also Statusupdate für dieses Feature vom GeoEvent Server prozessiert und an den Stream Server weiter geleitet wurde. Dies ist natürlich kein ideales Szenario, besonders wenn nicht alle Features in kurzen regelmäßigen Intervallen aktualisiert werden und somit unter Umständen für einen längeren Zeitraum gar nicht in der Anwendung auftauchen würden.
Deshalb, gibt es für die Stream Server das Konzept eines "Store Latest" Feature Service, welcher begleitend zu dem Stream Service veröffentlicht werden kann und wo, wie der Name es bereits vermuten lässt, parallel die aktuellsten Zustände der jeweiligen Features gespeichert werden. Wählt man diese Option, werden die Informationen über den "Store Latest" Feature Service in der Beschreibung des Stream Services hinterlegt. So können Klienten auf Basis dieser Information beim initialen Verbinden mit dem Stream Server parallel eine Query für die aktuellen Zustände der Features aus dem Feature Service durchführen und auf der Karte visualisieren. Anschließend übernimmt wieder der Stream Layer und visualisiert neue Events umgehend in Echtzeit!
Join der Geometrien und statischen Attribute im Klienten
Natürlich sollen im Idealfall nur dynamische Informationen eines Features ständig aktualisiert werden, in dem Fall von z.B. statischen Sensoren in einem Sensornetzwerk sind dies in der Regel sich immer aktualisierende Messwerte, Informationen wie z.B. die Geometrie oder weitere Sensoreigenschaften sind jedoch überwiegend statisch. Daher wurde auch für diese Anwendungsfälle eine Konzept in dem Stream Server integriert, welches es erlaubt einen Feature Service mit "Related Features" zu referenzieren. Mit diesen Informationen, welche dem Klienten ebenfalls über die Stream Server Beschreibung zur Verfügung gestellt werden, können statische Informationen direkt im Klienten an das eingehende Event über eine eindeutige ID (Track ID) hinzugefügt werden.
Möglichkeiten für Entwickler
Stream Server bzw. der Stream Layer in den Anwendungen bieten ebenfalls für Entwickler interessante Möglichkeiten diese Technologie weitergehend zu nutzen. Seit dem ursprünglichen Release der Technologie in 10.3. ist der Stream Layer in JavaScript basierenden Web Anwendungen über die ArcGIS API für JavaScript nutzbar und wird kontinuierlich in die weiteren ArcGIS Komponenten und API's integriert. Eine Interessante Möglichkeit ist hier sich dem "onMessage" (JS API) / "on_features" (Python API) Events des Stream Layer zu verschreiben, welches es ermöglicht jedes Event, welches im Esri JSON Format gesendet wird, zu analysieren bevor es auf der Karte visualisiert wird.
In der bereits erwähnten ISS Demo, verwende ich zum Beispiel das "onMessage" Event eines StreamService, welcher bei dem überfliegen der ISS über ein Land bzw. des Ozeans dieses als GeoTag mitsendet, um die Textanzeige beim "Landeswechsel" zu aktualisieren.
Viel Spaß beim Erkunden und Verwenden dieses neuen Layer-Typs in euren Echtzeit Anwendungen!
Tom
*PS: Mehr Details zu dem Spatiotemporal Big Data Store wird es in einem der nächsten Blog Einträge geben!