Im dritten Teil unserer Blogreihe schauen wir uns an, wie wir die aktuellen Buspositionen im ArcGIS GeoEvent Server prozessieren können. Konkret wollen wir eine räumliche Echtzeitanalyse bauen, die die Daten mit anderen Informationen anreichert sowie die Aufenthaltsdauer der Busse in Bereichen mit Straßenarbeiten berechnet.
Dieser Teil des Blogs baut auf dem zweiten Teil der Blogreihe auf. Falls Sie den vorherigen Teil noch nicht gelesen/gemacht habt, wäre jetzt die beste Zeit dafür. Dort haben wir die Echtzeit-Buspositionen in den GeoEvent Server integriert und eine Vorlage für den Stream Service angelegt.
Analysefunktionalitäten im GeoEvent Server
Erfolgreich integriert kommen die einzelnen Events mit den aktuellen Buspositionen im GeoEvent an. Bereits diese Positionen werden wir auf der Karte im Map Viewer oder in ArcGIS Pro (im Store erhältlich) darstellen (wie leicht das geht, zeigen wir Ihnen im nächsten Blog-Beitrag dieser Serie).
Allerdings ist reine Datenvisualisierung nur ein Bruchteil davon, was der GeoEvent Server an Funktionalität bietet! Vielmehr können wir damit verschiedenste Berechnungen und u.a. räumliche Analysen direkt in Echtzeit (!) durchführen.
Sie fragen sich bestimmt was denn alles möglich ist ? Hier sind einige Funktionalitäten:
- Filtern von Events nach verschiedenen Kriterien und räumlichen Bedingungen
- Umrechnung/Veränderung der Attributwerte
- Mehrere Echtzeitdatenquellen in die Analyse einfließen lassen oder diese verbinden
- Mit GeoFences viele räumliche Analysemöglichkeiten nutzen
- Daten mit weiteren Informationen anreichern (z.B. aus einer CSV oder einem Feature Layer)
- Puffer, Reichweite, konvexe Hüllen erzeugen usw.
Im GeoEvent Server stehen uns ca. 25 verschiedene out-of-the-box Prozessoren zur Verfügung, die wir beliebig kombinieren können, um einfache und komplexe räumliche Analysen durchzuführen. Heute werden wir ein paar davon im Einsatz für eine einfachere Analyse kennenlernen.
Mit dem mitgelieferten SDK können auch Custom-Prozessoren entwickelt werden.
Überlegungen vor der Analyse
Lassen Sie uns noch einmal einen Blick auf die eingehenden Daten werfen. Dabei sind uns mehrere Punkte aufgefallen.:
- Wie wir schon am Ende des letzten Blogs angemerkt haben, sind die Zeitstempel noch nicht korrekt, das sollten wir korrigieren.
- Im Attribut „delay“ wird die aktuelle Verspätung in Sekunden angezeigt. Für die Anwender:innen wäre es vielleicht praktischer, wenn die Verspätung in Minuten angezeigt werden würde, also können wir diese umrechnen.
- Die Haltestelleninformationen sind bisher nur durch die Haltestellenummer repräsentiert. Es wäre doch gut, wenn wir den Namen der nächsten Haltestelle, die ein Bus einfahren wird, als Text anzeigen könnten.
Außerdem nehmen wir an, dass in Münster bald an mehreren Stellen Straßenbauarbeiten beginnen, die in diesen Bereichen zu Verkehrsbeschränkungen führen werden.
Um auch zukünftig Straßenbauarbeiten besser gestalten zu können, möchte der Auftraggeber wissen, wie stark sich die Straßenarbeiten auf den Busverkehr auswirken. Dafür möchte er wissen, wie lange sich Busse in den Gebieten, wo Straßenarbeiten anstehen, aufhalten. Es soll verglichen werden, wie sich die Baustellen auf die durchschnittliche Verspätung auf der jeweiligen Buslinie auswirken.
Das sind bereits einige Punkte, die wir angehen müssen. Aber keine Sorge, mit dem GeoEvent Server können wir alles in Echtzeit bewältigen.
Eine sorgfältige Planung ist von großer Bedeutung
Lassen Sie uns zuerst einen Plan entwerfen, um die Analyse effizienter zu gestalten. Am besten reichern wir als Erstes die Daten mit Namen der Haltestellen an. Im zweiten Schritt können wir bereits die Output-Definition für die Positionen aller Busse erstellen. Danach korrigieren wir die Zeitfelder und rechnen die Verspätung um. Am Ende werden wir die Baustellenbereiche als GeoFences importieren und mithilfe des Prozessors „Incident Detector“ Busse innerhalb der Baustellenbereiche ermitteln sowie die Aufenthaltsdauer berechnen.
Die Analyse soll mehrere Outputs haben: einen für die aktuellen Positionen aller Busse mit allen neu-berechneten Attributen und einen nur für die Busse, die sich in den Baustellenbereichen befinden ebenfalls mit all den neuen Attributen inklusive Aufenthaltsdauer. Darauf gehen wir aber im nächsten Teil der Blogreihe ein.
Analyse
Gehen Sie nun im GeoEvent Manager auf den im letzten Blog-Beitrag erstellten Service „busradar-muenster“, wo sich derzeit nur der Input-Konnektor „busradar-muenster-json-poll-in“ und unser Dummy-Output „tcp-text-out“ befinden. Falls erforderlich, starten Sie den Service, um den Empfang der Events zu ermöglichen.
Schritt 1: Haltestelleninformationen anreichern
Um unseren Echtzeitfeed mit anderen Informationen anzureichern, brauchen wir natürlich erstmal die Daten. Neben den aktuellen Buspositionen lieferen die Stadtwerke Münster in der API auch die Informationen zu den Bushaltestellen: https://rest.busradar.conterra.de/prod/haltestellen.
Da diese Informationen selten aktualisiert werden, genügt es, einen Feature Layer im verknüpften Enterprise-Portal anzulegen, in dem wir die Daten speichern. Wir werden dieses Feature-Service dann mit dem GeoEvent abrufen, um den Feed anzureichern.
By-the-way: Wir gehen davon aus, dass Sie bereits mit der Oberfläche von Enterprise Portal vertraut sind, und erklären die Vorgehensweise ein bisschen weniger detailliert. Feature Layer im GIS-Server oder ArcGIS Online werden übrigens auch funktionieren, sobald sie mit dem GeoEvent Server verbunden sind.
- In einem neuen Tab öffnen Sie Ihr Enterprise Portal und erstellen bei „Inhalt“ einen neuen Ordner, in welchen Sie später auch die Outputs von GeoEvent speichern werden.
- Im Ordner erstellen Sie ein neues Element aus der URL. Als URL geben Sie https://rest.busradar.conterra.de/prod/haltestellen ein und als Typ wählen Sie GeoJSON. Fügen Sie die Daten als einen gehosteten Feature-Layer hinzu.
- Nachdem der Feature Layer erstellt wurde, überprüfen Sie, ob die Tabelle Einträge hat (hierfür auf die Feature Layer Item Seite gehen und auf den Daten Reiter anklicken).
Die Spalte „nr“ enthält die Nummer der Bushaltestellen und Spalte „lbez“ die Namen. Die Nummer der Bushaltestellen in der Spalte „nr“ besteht allerdings aus sieben Stellen und die im GeoEvent aus fünf.
Wenn wir uns die Daten genauer anschauen, dann fällt auf, dass nach den fünf Stellen jeweils Endungen 01, 02 usw. folgen, welche die Richtung der Haltestelle repräsentieren. Für einen Join mit unseren Echtzeitdaten müssen wir diese Spalte kurz neu berechnen und die hinteren zwei Zahlen mit der Funktion substring (string, intIndexBegin, intIndexEnd) entfernen.
- In der Tabelle im Portal klicken Sie oben auf das Feld „nr“ und wählen „Berechenen“ aus. Dann gehen Sie zu „SQL“, geben substring (string, 1, 5) ein und klicken „Berechenen“. Nun erscheinen nur die ersten fünf Nummern der Bushaltestellennummer. Schließen Sie das Fenster „Feld berechenen“ und prüfen Sie die Ergebnisse.
- Gehen Sie zurück zum GeoEvent Manager und öffnen ggf. den Service „busradar-muenster“. Bei „New Elements“ klicken Sie auf „Processor“.
- In der Eingabemaske geben Sie den Namen „Name der nachhst anreichern“ und wählen den Prozessor „Field Enricher (Feature Service)“ aus der Liste aus.
- Bei der „Registered server connection“ wählen Sie Ihr registriertes ArcGIS Portal aus (siehe dazu: Manage data stores—ArcGIS GeoEvent Server Help | Documentation for ArcGIS Enterprise). Registrieren Sie Ihr ArcGIS Portal am besten als Default-Verbindung.
- Bei “Reference to Layer Type” wählen Sie “Browse to Layer”.
- Bei ”Folder”, “Service” und “Layer” navigieren Sie Schritt für Schritt zum eben erstellten Feature-Layer.
- Bei „Feature Layer join Field” wählen Sie “nr” aus.
- Bei „Target Fiels“ wählen Sie „New Fields“. Das bedeutet, dass das angereicherte Feld als neues Feld erscheinen soll.
- Bei „Enrichment Fields“ geben Sie „lbez“ an. Wenn Sie noch andere Felder anreichen möchten, können Sie diese mit Komma auflisten.
- Bei „New GeoEvent Definition“ geben Sie einen Namen für die Definition ein, die auch das angereicherte Feld „lbez“ beinhaltet, z. B. „busradar-muenster-enrich-nachhst“.
- Bei „GeoEvent Join Field“ wählen Sie die „busradar-muenster-in“ Definition und das Feld „nachhst“ aus.
- Belassen Sie alle anderen Parameter bei den Standardeinstellungen und klicken auf „Ok“, um die Einstellungen im Connector zu speichern und das Fenster zu schließen.
- Löschen Sie im Service den Pfeil zwischen Input und Output und verbinden Sie den Field Enricher Prozessor zwischen diesen beiden Elementen, so wie im Bild unten abgebildet. Klicken Sie auf „Publish“, um alles zu speichern.
- Um zu überprüfen, ob das funktioniert hat, machen Sie einen Rechtsklick auf den ersten Pfeil und wählen „Sample Route“. Genauso klicken Sie auf den zweiten Pfeil und wählen „Compare Route“.
Im Sampler können wir nun die beiden Datenschemata vergleichen und feststellen, dass die Daten nach der Anwendung des Field Enricher Processors weiterhin fließen und das neue Feld ‘lbez’ erfolgreich hinzugefügt wurde.
Schritt 2: Definition für den Output aller Buspositionen erstellen
Nun erstellen wir die Output-Definition, um das angereicherte Feld „lbez“ in eine feste Definition zu mappen und danach die anderen Feldumrechnungen durchzuführen. Dazu gehen wir direkt in unserem Service unter „Site Setting“ zu den „GeoEvent Definitions“. Dort befinden sich die Ausgangsdefinition „busradar-muenster-in“ sowie durch den Field Enricher automatisch erstellte Definition „busradar-muenster-enrich-nachhst“.
Die Output-Definition werden wir auf Basis der Input-Definition „busradar-muenster-in“ erstellen, deshalb werden wir sie kopieren und ein neues Feld hinzufügen.
- Unter „Site Settings“ gehen Sie zu den „GeoEvent Definitions“ und suchen dort die vorhin erstellte Definition „busradar-muenster-in“. Ganz rechts klicken Sie auf das Symbol
, um diese Definition zu kopieren. - Veränderen Sie den Namen auf „busradar-muenster-out“.
- Klicken Sie auf „New Field“. Bei Feld Name geben Sie den Namen “nachast_name“ ein und bei Type wählen Sie „String“. Zum Bestätigen „Create“ klicken.
- Da das neu erstellte Feld in der Definition immer ganz unten erscheint, gehen Sie auf „Reorder Fields“ und ordnen mit den Pfeilen die Felder auf die passenden Stellen in der Definition zu.
- Am Ende klicken Sie auf „Save“, um die Veränderungen zu speichern und schließen den Dialog mit GeoEvent Definitionen.
Nun wollen wir die neu erstellte Definition in unserem Service anwenden. Dafür müssen wir die Felder der alten Definition auf die neue übertragen. Dafür nutzen wir den Prozessor „Field Mapper“.
- In der Arbeitsoberfläche des „busradar-muenster“ Services gehen Sie zu den „New Elements“ und machen einen Doppelklick auf „Processor“. In der Maske unter Namen geben Sie „Output-Definition anwenden“ ein.
- Bei Prozessor auf dem Menü „Field Mapper“ Prozessor auswählen.
- Bei Source GeoEvent Definition wählen Sie die „busradar-muenster-enrich-nachhst“ Definition, die als letztes verwendet wurde.
- Bei Target GeoEvent Definition wählen Sie die eben neu erstellte Definition „busradar-muenster-out“.
Es erscheinen Felder der beiden Definitionen. Felder mit den gleichen Namen werden automatisch zugeordnet und Felder, die unbekannt sind, sind noch leer.
- Um die angereicherten Haltestellennamen in das Feld „nachhst_name“ zu mappen, wählen Sie „lbez“ aus dem DropDown Menü aus und klicken auf „Okay“.
- Im Service löschen Sie den ursprünglichen Verbindungspfeil, platzieren den Konnektor zwischen dem Input und Output und verbinden die drei Elemente neu miteinander.
- Auf „Publish“ klicken, um die Änderungen zu speichern.
- Um zu überprüfen, ob dieser Schritt funktioniert hat, machen Sie einen Rechtsklick auf den ersten Pfeil und wählen „Sample Route“. Genauso klicken Sie auf den zweiten Pfeil und wählen „Compare Route“.
Schritt 3: Zeitstempel korrigieren, Verspätung umrechnen
Am Ende des letzten Blogs haben wir festgestellt, dass das Datumsfeld zwar richtig als Datum ausgelesen wird, allerdings lag der Zeitstempel ca. vier Jahre in der Vergangenheit.
Warum ist es so? Die Antwort ist einfach: Der Zeitstempel in der API wird als Unixzeit (UTC) in Unix Epoch Sekunden geliefert. Im GeoEvent wird die UTC-Zeit standardmäßig aber in Epoch Millisekunden prozessiert. Deshalb müssen wir den vorhandenen Zeitstempel für alle drei Attribute in Millisekunden umrechnen, also mal 1000 multiplizieren.
Sie denken wahrscheinlich, alles klar, ich muss dafür den Field Calculator nutzen. Das ist zwar korrekt und würde funktionieren, aber es ist effizienter, diese Umrechnung direkt im Field Mapper Processor durchzuführen. Im Field Mapper können wir auch Berechnungen ähnlich wie im Field Calculator durchführen, und zwar für mehrere Felder gleichzeitig. Und das funktioniert so:
- Öffnen Sie den gerade eben erstellten Prozessor „Field Mapper“ mit dem Doppelklick.
- Als erstes korrigieren wir die Zeitstempel. Suchen Sie die Felder „abfahrtstart“, „visfahrplanlagezst“ und „ankunftziel“ und veränderen die Ausdrücke folgendermaßen:
- Nun rechnen wir die Verspätung in Minuten um. Das machen wir über den Ausdruck „delay / 60“:
- Klicken Sie auf „Okay“, um die Einstellungen zu speichern. Im Service über „Publish“ die Veränderungen speichern.
- Aktualisieren Sie die Daten im Sampler und überprüfen die Felder mit den Zeitstempeln und Verspätung.
Ab jetzt erhält jedes Event in unserem System den aktuellen Zeitstempel und die Verspätung wird in Minuten angezeigt.
Schritt 4: Baustellen ins GeoEvent als GeoFences importieren
Im echten Case würde die zuständige Stelle uns die Daten zu den Baustellen liefern. Da wir einen fiktiven Use Case haben, werden wir ein paar Baustellen uns einfach selber erstellen. Dafür erstellen wir in unserem Portal einen Feature-Layer mit einigen Polygonen, den wir dann in den GeoEvent als GeoFences importieren und für die Analyse verwenden.
Bei GeoFences müssen Sie grundsätzlich folgendes wissen:
- Jedes Polygon gilt als ein GeoFence. Wenn Sie vorher über Union mehrere Polygone zu einem gemacht haben, dann wird es auch als ein GeoFence gelten.
- Der GeoEvent Server kann mit vielen GeoFences auf einmal problemlos umgehen.
- Polygone, die als GeoFences verwendet werden, sollten in der Form nicht zu komplex sein, d.h. nicht zu viele Koordinatenpaare aufweisen, sonst sinkt die Performance sehr stark. Je nach Use Case müssen Sie versuchen vereinfachte Formen zu verwenden.
Wir legen aber los:
- Gehen Sie zum Portal und navigieren zum vorhin erstellten Projektordner. Erstellen Sie im Ordner einen Feature-Layer als Polygon mit dem Titel „Baustellen“.
- Bei Daten ein neues Feld „Name“ als String erstellen und den Layer im Map Viewer öffnen.
- Über die Bearbeitungsfunktion zeichnen Sie ein paar Polygone in Münster ein, die Baustellen repräsentieren und füllen dabei die Attribute aus.
Sie können die Baustelleninformationen der Stadt Münster Baustellen | opendata.stadt-muenster.de auch als Punkt-Shape-Datei herunterladen und einfach einen Buffer um die Punkte erzeugen und den Buffer-Polygon-Layer für die weiteren Schritte nutzen.
- Gehen Sie wieder zum GeoEvent Manager und öffnen ggf. wieder den Service „busradar-muenster“. Im Service unter „Site Settings“ klicken Sie auf das Feld „GeoFences“.
- Klicken Sie auf Import.
- In der Eingabemaske bei „Registered Server Connection“ wählen Sie das registrierte Portal, z. B. „Default“.
- Bei „Folder“, „Service“ und „Layer“ navigieren Sie Schritt für Schritt zum neu erstellten Layer „Baustellen“.
- Bei „Category Field“ geben Sie „baustellen“ an.
Info: Dafür könnte auch ein vorhandenes Kategorie-Feld ausgewählt werden, falls sich im Feature-Layer mehrere Kategorien (z.B. Fluss, Gebäude, Straße usw.) befinden. Da in unserem einfachen Feature-Layer gar kein Kategorie-Feld vorhanden ist, definieren wir dadurch alle Objekte als Baustellen.
- Bei „Name Field“ das Feld „name“ wählen.
- Lassen Sie alle anderen Einstellungen so wie sie sind und klicken Sie auf „Import“.
- In der Liste erscheinen alle Baustellen, die Sie vorhin definiert haben. Über das Karten-Icon können Sie überprüfen, dass sie räumlich korrekt importiert wurden. Schließen Sie das GeoFences Fenster und kehren zurück zum Service.
Schritt 5: Die Aufenthaltsdauer der Busse in den Baustellenbereichen ermitteln
Nachdem wir erfolgreich GeoFences importiert haben wollen wir sie nun mit unseren Echtzeitdaten verschneiden. GeoFences im GeoEvent Server können in Filtern sowie in Prozessoren „Incident Detector“ und „GeoTagger“ eingesetzt werden. Für unsere Analyse werden wir den Prozessor „Incident Detector“ verwenden, um zu berechnen, wie lange ein Bus eine Baustelle passiert.
- Im Service unter New Elements erstellen Sie einen Prozessor mit dem Namen „Incident Detector“ und wählen den entsprechenden Prozessor aus der Liste aus.
- Bei „Incident Name“ geben Sie einen Namen für den Incident ein, z.B. „Bus_im_Baustellenbereich“.
- Bei „Opening Condition“ klicken Sie auf das grüne Kreuz und füllen die Maske folgend aus:
- Bei „Definition“ die letzte verwendete Definition „busradar-muenster-out“ auswählen.
- Beim „Field“ wählen Sie unter „TAGS“ den Tag „GEOMETRY“.
- Als Operator wählen Sie „INSIDE“.
- Bei GeoFence die Kategorie „baustellen“ auswählen.
- Im letzten Feld „.*“ einfach stehenlassen.
- Klicken Sie auf „Okay“.
Übersetzt heißt der Ausdruck Folgendes: „Lieber Prozessor, erstelle einen neuen Incident also Vorfall so bald irgendeine Geometrie (in unserem Fall ein Bus) aus der Definition „busradar-muenster-out“ sich innerhalb irgendeines GeoFences (in unserem Fall irgendeine Baustelle) befindet.“
- Bei „Keep Sourche Definition“ wählen Sie „Yes“ und bei „Output GeoEvent Definition suffix name“ geben Sie „incident-detector“ ein.
- Lassen Sie alle anderen Einstellungen so wie sie sind und im Prozessor klicken Sie auf „Okay“.
- Verbinden Sie den Incident Detector Prozessor mit dem „Field Mapper Prozessor“, erstellen ein zweites Dummy-Output „tcp-text-out-2“ („Push Text to an External TCP Socket“ Output-Konnektor) und verbinden den Incident Detector zum zweiten Output (siehe Bild unten). Klicken Sie auf „Publish“, um alle Änderungen zu speichern.
- Überprüfen Sie im Sampler, ob die Daten weiterhin fließen. Es kann manchmal etwas dauern, bis ein Incident Event generiert wird, da möglicherweise gerade kein Bus im Baustellenbereich unterwegs ist.
Der Incident Detector erzeugt automatisch eine neue GeoEvent Definition, die viele neue Felder enthält. Dabei fällt vor allem auf, dass die neue Definition quasi aus zwei Teilen besteht: neuen Feldern, wo alle Parameter und Ergebnisse dargestellt sind und der alten Definition, die jetzt bei jedem Attribut mit „source___“ beginnt. Das ist deshalb so, weil wir die vorhin die ursprünglichen Felder beibehalten wollten.
- In der automatisch erzeugten GeoEvent Definition entfernen Sie den Tag „Track ID“ vom Feld „trackId“ und weisen diesen Tag für das Feld „source___fahrzeugid“ zu. Klicken Sie auf „Save“, schließen Sie das Dialog_Feld „GeoEvent Definitions“ und klicken Sie auf „Publish“, um alle Änderungen zu speichern.
Schauen Sie sich den Output im Sampler genauer an. Gerade die Felder „status“, „description“ und „duration“ liefern uns Informationen darüber, wann der Bus den Baustellenbereich passiert hat (description), ob dieser noch innerhalb des GeoFences ist (status) und wie lange er sich schon dort befindet (duration in Millisekunden).
Der Prozessor Incident Detector gibt allerdings nicht an, auf welche Baustelle genau sich der Incident bezieht. Dafür müsste man den GeoTagger Prozessor verwenden. Falls Sie darüber gerne mehr erfahren würden, schreiben Sie uns das gerne in die Kommentare und wir schreiben einen eigenen Blog darüber.
Als letztes erstellen wir noch ein finales Datenschema für diesen Output und entfernen alle Felder, die wir nicht brauchen.
- Im Service öffnen Sie unter „Site Settings“ den Bereich „GeoEvent Definitions“ und suchen nach „busradar-muenster-out-incidents“.
- Kopieren Sie diese Definition wie wir es schon mal gemacht haben und räumen diese Definition ein wenig auf. Benennen Sie die Definition um, z.B. „busradar-muenster-incidents-out“.
Löschen Sie folgende Felder: „alertType“, „openCondition“, “closeCondition” „definitionName“, „definitionOwner“, “geometry” „dissmised“, „assignetTo“, „note“, „source___GED_Name“, „source___GED_ReceivedTime”.
Je nach Use Case lohnt es sich einige dieser Felder beizubehalten und andere zu löschen.
- Löschen Sie den „source___“ Teil im Namen der entsprechenden Felder und ordnen Sie die Felder so an, dass sie eine sinnvolle Reihenfolge für Sie haben. Am Ende „Save“ klicken, um die Änderungen zu speichern. Bei uns sieht die finale Definition folgendermaßen aus:
- Nun erstellen wir wie vorhin einen neuen Field-Mapper Prozessor, und mappen die Felder von Datenschemata „busradar-muenster-out-incident-detector“ zu „busradar-muenster-incidents-out“. Danach bauen wir den Prozessor zwischen dem Incident Detector und dem Output-Konnektor ein.
- Über „Publish“ speichern Sie alle Veränderungen.
- Prüfen Sie im Sampler, ob alle Felder korrekt gemappt wurden.
Nun haben wir erfolgreich eine Echtzeitanalyse eingerichtet. Das Komplizierteste ist somit vorbei. Sie fragen sich nun wahrscheinlich, warum habe dies bisher nicht auf einer Karte gesehen. Es fehlen natürlich noch die Outputs und die Visualisierung des Ganzen auf einer Karte. Darauf werden wir im nächsten Blog-Beitrag eingehen und ein Dashboard bauen.
Bis dahin möchten wir Sie loben für die erfolgreiche Erstellung dieser mehrstufigen räumlichen Echtzeitanalyse. Zudem freuen wir uns auf alle weiteren Fragen, die Sie haben.
Weitere Informationen
- Lesen Sie sich unbedingt den ersten und zweiten Beitrag dieser vierteiligen Blogreihe durch.
- Viele Infos zum GeoEvent finden Sie im englischsprachigen Community Blog von Esri Inc. sowie in der ebenfalls englischsprachigen Dokumentation für ArcGIS Entersprise.
- Informationen zu den letzten Neuerungen im GeoEvent Server sind in diesem Blog zu finden: Neuerungen im ArcGIS GeoEvent Server | Analytics Solutions.
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 erfahren Sie im Detail, welche Chancen und Möglichkeiten Geoanalysen bieten.
Schauen Sie sich auch gerne das Webinar Räumliche Analyse und Data Science an.
Haben Sich beim Lesen dieses Blogs Fragen ergeben? Dann freuen wir uns, wenn Sie die Kommentarfunktion auf dieser Seite nutzen!
