<\/HEAD>
F: Was ist ArcGIS Data Interoperability? <\/P>
A: Es ist natürlich ein Produkt, eine Erweiterung für Desktop und Enterprise, aber als Technologie ist es Esris No-Code-Integrationslösung. „Integration“ bedeutet, ArcGIS mit Daten zu verbinden – zum Lesen oder Schreiben – über eine riesige Vielfalt von Formaten, Feeds und Repositorien hinweg, und dann die Daten nach Bedarf für Ihre Geschäftsanforderungen zu manipulieren. Wenn Sie darauf zugreifen können, kann Data Interoperability wahrscheinlich damit arbeiten, wie Sie es möchten.<\/P>
<\/P>
F: Das ist eine ziemlich kühne Behauptung – wenn Sie „verbinden“ können, können Sie wahrscheinlich auch „nutzen“ – von welchen Datenquellen sprechen wir hier wirklich? <\/P>
A: Historisch ging es vor allem um dateibasierte Formate wie CAD und einige proprietäre Formate, die von früherer GIS-Software verwendet wurden, plus alles Textbasierte – Dateien auf der Festplatte. Datenbankkonnektivität wurde hinzugefügt – Netzwerktransport. Dann kam eine Ära von XML sowie Raster- und Punktwolken-Daten hinzu. FTP- und HTTP-Konnektivität wurden ergänzt, um das Internet zu erreichen, dann JSON, sodass „Daten in Bewegung“ handhabbar wurden, und zuletzt Connectoren zu Cloud-Speichern. Während sich die Produkte vom Desktop über Netzwerk bis Web entwickelten, passte sich die Technologie an, um „einfach zu funktionieren“. Das alles wächst natürlich weiter, nichts verschwindet, und neue Quellen aller Art werden hinzugefügt, sobald sie auftauchen.<\/P>
<\/P>
F: Ist Data Interoperability dasselbe wie FME? <\/P>
A: Es ist so, außer wenn es das nicht ist. Sie wissen natürlich, dass es FME-Technologie ist: Safe Software entwickelt Data Interoperability für uns, aber die beiden Desktop-Produkte unterscheiden sich leicht darin, welche Funktionalitäten in einer lizenzierten Version enthalten sind, und die Serverprodukte sind unterschiedlich. Wir arbeiten sehr eng mit Safe zusammen, um sicherzustellen, dass Funktionalitäten, die Esri-Nutzer benötigen, in FME-Technologie und damit in Data Interoperability einfließen. Viele Nutzer haben beide Produkte, Sie können Workspace-Dateien zwischen ihnen teilen und Ihre Fähigkeiten in beiden sind übertragbar.<\/P>
<\/P>
F: Wenn ich mich mit Daten verbinde, kann ich sie dann einfach wie ein Geodatabase-Element oder Feature-Service oder andere ArcGIS-native Quelle in meiner Kartierung und Geoverarbeitung verwenden? <\/P>
A: Ja, nachdem Sie sie dorthin geschrieben haben, wo eine Esri-App sie sehen kann. Aber der Zugriff auf Rohdaten ist nur ein Teil der Geschichte. Es ist selten der Fall, dass Daten genau im Schema vorliegen, das Sie für Ihre Arbeit benötigen. Filterung und Geometrie-Korrektur sind häufig erforderlich. Hier kommen die hunderten von Daten-Transformationswerkzeugen ins Spiel. Sobald Sie sich mit den Daten verbunden haben, entwerfen Sie einen streambasierten Workflow, der die benötigte Verarbeitung implementiert und schreiben zuletzt Ihr Ergebnis dorthin, wo Sie es brauchen.<\/P>
<\/P>
F: Sie sagten: „diagrammieren<\/EM> eines streambasierten Workflows“. Ist das mit ModelBuilder? <\/P>A: Data Interoperability stellt eine App bereit – Workbench – die eine visuelle Programmierumgebung ähnlich ModelBuilder bietet.& nbsp; Es ist sehr einfach zu bedienen: Sie arbeiten auf einer Leinwand (Canvas), fügen sogenannte Reader, Transformer und Writer hinzu, konfigurieren und verbinden diese, führen Teil- oder Komplettläufe durch wie bei ModelBuilder und Sitzungen können als Geoverarbeitungswerkzeuge gespeichert werden – ebenfalls wie bei ModelBuilder.& nbsp; Ich möchte betonen, dass die Arbeit in Workbench ModelBuilder oder dem Erstellen von Python-Skriptools ähnelt: Sie arbeiten in der ArcGIS-Geoverarbeitungsumgebung.& nbsp; Wie ModelBuilder aber im Gegensatz zu Python-Skriptools programmieren Sie nicht im Code sondern diagrammieren.<\/P>& nbsp;<\/P>F:& nbsp; Ich kann gut mit Python umgehen. Hilft das? <\/P>A:& nbsp; Vielleicht schon, aber Python ist nicht notwendig.& nbsp; Data Interoperability ist No-Code-Technologie aber auch Code-freundlich.& nbsp; Manchmal spart es Diagrammierarbeit, eine Python-Snippet für eine Funktion zu verwenden.& nbsp; Das ist eine weitere Ähnlichkeit mit ModelBuilder: Dort gibt es ein Modellwerkzeug „Calculate Value“, mit dem man ein Python-Snippet anwenden kann.& nbsp; In beiden Fällen kann das Zeit sparen.<\/P>& nbsp;<\/P>F:& nbsp; Data Interoperability ist ETL. Aber ich sehe Cloud-Anbieter werben für ELT. Haben Sie dazu Kommentare? <\/P>A:& nbsp; Extract Transform & Load (ETL) bedeutet, dass die Transformation der Daten vor dem Senden an ein System of Record erfolgt. Extract Load & Transform (ELT) bedeutet dagegen, dass Daten zuerst in einem System of Record vorhanden sind (oder dorthin gesendet werden) und dort manipuliert werden – z.B. mittels SQL oder durch Verwendung einer Ansicht bzw. einer SQL-nachahmenden Sprache in einer JSON-Store-Technologie.& nbsp; Während Data Interoperability erstklassige Manipulationsmöglichkeiten bietet, verfügt es auch über Abfragekonnektivität innerhalb von Cloud-Plattformen. So können Sie direkt an den Daten arbeiten ohne sie hin- und herzubewegen.& nbsp; Kämpfen Sie nicht gegen die Datengravitation an. Machen Sie das was für Sie funktioniert. Data Interoperability ermöglicht Ihnen dies aus ArcGIS heraus als ETL oder ELT.<\/P>& nbsp;<\/P>F: & nbsp; Was ist der beste Lernweg für Data Interoperability? Haben Sie so angefangen? <\/P>A: & nbsp; Es gibt Online-Kurse auf esri.com/training sowie eine Fülle von Informationen auf safe.com für FME Desktop – was fast vollständig auf Data Interoperability anwendbar ist –, aber der wertvollste Lernweg ist Lernen durch Tun – also ETL-Werkzeuge erstellen – und sich mit der ETL-Community auf GeoNet und knowledge.safe.com austauschen.& nbsp; Ich habe Data Interoperability gelernt durch Beteiligung an Migrationen von CAD-Systemen zu ArcGIS.<\/P>& nbsp;<\/P>F: & nbsp; Ich habe von Data Interop für Server gehört. Können Sie die ETL-Funktionalität im Server-Kontext erklären? <\/P>A: & nbsp; Das Muster für Data Interoperability for Server liegt im Rahmen der Veröffentlichung von Geoverarbeitungsdiensten. Es ist nur ein spezieller Fall davon.& nbsp; Es gibt einige Details zu beachten wie z.B., wie man mit ETL-Werkzeugen umgeht, die einen Workspace ausgeben – etwa eine File Geodatabase –, was in Core-Geoverarbeitung nicht möglich ist (Sie können die GDB zippen und als Datei-Parameter zurückgeben). Dienste sollten asynchron sein. Ansonsten behandeln Sie ein ETL-Werkzeug einfach wie z.B. ein Python-Skriptwerkzeug.<\/P>& nbsp;<\/P>F:& nbsp; Ich habe gehört Leute nutzen Data Interoperability zur Unterstützung standardbasierter Formate und Protokolle wie GML oder WFS oder GeoPackage. Können Sie das etwas näher erläutern? <\/P>A:& nbsp; Beliebte Formate und Protokolle finden oft schließlich ihren Weg in den Kern von ArcGIS – selbst wenn deren Unterstützung ursprünglich über Data Interoperability erfolgte.& nbsp; Allerdings bleibt meist ein viel reichhaltigeres Übersetzungserlebnis in Data Interoperability verfügbar.& nbsp; Das gilt sogar für De-facto-Standards wie CSV, Excel und KML.<\/P>& nbsp;<\/P>F: & nbsp; Können Sie interessante Szenarien teilen, bei denen Data Interoperability eine wichtige Rolle gespielt hat? <\/P>A:& nbsp; Die wirkungsvollsten Ergebnisse – hier subjektiv betrachtet aber das Muster wiederholt sich häufig bei sehr vielen Nutzern – entstehen wenn ein System of Record zur Gewinnung autoritativer Daten genutzt wird. Diese Daten werden dann verbessert (amelioriert) und verwendet zur Pflege eines gehosteten Feature-Service in ArcGIS Enterprise oder Online. Dieser liefert natürlich eine performante Datenquelle für Esri-Apps.& nbsp; Das Quellsystem kann FTP sein, HTTP, WFS, Protocol Buffer oder ein REST API-Endpunkt – alles möglich.& nbsp; Der Vorteil dieses Musters besteht darin, dass man die Bereitstellung von Daten an Esri-Nutzer automatisieren kann ohne Ausfallzeiten oder Störungen des Systems of Record.<\/P>& nbsp;<\/P>F:& nbsp; Ich habe von FME Server gehört. Unterstützen Sie das? <\/P>A:& nbsp; Ich erwähnte bereits dass ArcGIS- und FME-Server-Produkte unterschiedlich sind – also getrennt –, aber funktionale Überschneidungen haben.& nbsp; Data Interoperability for ArcGIS Enterprise bietet Web-ETL im Rahmen von Geoverarbeitungsdiensten an. Ein gutes Muster um z.B. Formatübersetzungen zu skalieren oder dateibasierte Datenquellen stark genutzt in Ihrer Organisation zu verarbeiten – etwa viele Excel-Dateien.& nbsp; FME Server kann ähnlich genutzt werden wäre aber keine gute Investition verglichen mit einer Lizenzierung von Data Interoperability für eine bestehende ArcGIS Enterprise Installation.& nbsp; Allerdings hat FME Server eine umfangreiche Trigger-Aktion-Automatisierungsfunktionalität für komplexe Integrationen zwischen mehreren Systemen.& nbsp; Wenn Ihre Arbeit Integrationen betrifft die keine Ergebnisse an einen Client senden sondern Synchronisationen durchführen sollen könnte FME Server angezeigt sein.& nbsp; Wenn neben ArcGIS Enterprise installiert können Ihre Integrationen ArcGIS Software wie ArcPy oder die ArcGIS Python API einschließen.<\/P>& nbsp;<\/P>F:& nbsp; Was steht auf der Roadmap für Data Interoperability? <\/P>A:& nbsp; Es gibt immer eine lange Liste von Format- und Transformationsfunktionalitäten in Planung aber einige wenige Es gibt einige Dinge, die kurz vor der Veröffentlichung stehen, sodass sie hoffentlich zum Zeitpunkt dieses Q&A verfügbar sein werden. Das erste ist die Weiterentwicklung von Tools zur Interaktion mit Big Data. Ein Beispiel, über das ich bloggen möchte, ist das Abrufen großer komprimierter CSV-Daten (die sich täglich ändern) aus dem Web, dann die Verwendung von GeoAnalytics Desktop für eine parallelisierte Spark-Verarbeitung in Pro und anschließend das Senden der Ergebnisse als Parquet-Datei an eine Cloud-Plattform, wo sie von jedem abgefragt werden können; alles als ETL-Toolset. Die Automatisierung dieses Prozesses, sodass er täglich nach einem Zeitplan abläuft, wird den Punkt verdeutlichen. Eine zweite Entwicklung, von der wir erwarten, dass sie bei der Masse gut ankommt, ist die Möglichkeit, ArcGIS Online-Elemente innerhalb eines ETL-Workflows zu verwalten, das bedeutet das Hochladen, Überschreiben, Herunterladen oder Löschen der vielen Online-Elementtypen, die Sie mit Data Interoperability erstellen können. Dies wird den Kreis beim Teilen von ETL-Prozessen auf Esris öffentlicher Cloud schließen.<\/P> <\/P>F: Können Sie mehr über zukünftige Entwicklungen sprechen – nicht nur Data Interoperability, sondern allgemein in den Bereichen ETL, App-Integration und Ähnlichem?<\/P>A: Nichts verschwindet, daher werden dateibasierte und netzwerkbasierte Datenquellen weiterhin existieren. Aber schon seit einiger Zeit und zunehmend werden Daten in Webformaten wie JSON bewegt, und wir sehen Trends bei Diensten mit Protocol Buffer-Payloads sowie Formate, die für den Transport von Big Data optimiert sind, wie Parquet. Die Interaktion mit REST APIs ist mittlerweile fast alltäglich und wird durch Data Interoperability vereinfacht. Sie können davon ausgehen, dass Formate oder Protokolle, die in der Industrie Verbreitung finden, von Data Interoperability unterstützt werden. Konzentrieren Sie sich auf Ihre Arbeit und sagen Sie uns, was Sie brauchen – die Zukunft wird für Sie gebaut.<\/P> <\/P>F: Wo kann ich mehr Informationen speziell zu Data Interoperability und allgemein zu ETL-bezogenen Themen erhalten?<\/P>A: Ihr Esri-Vertreter berät Sie gerne zur Lizenzierung von Data Interoperability. ETL ist ein großes Thema und eine gut dokumentierte Branchen-Disziplin. Um Ihr Projekt wirklich anzustoßen, sollten Sie eine professionelle Dienstleistung mit Ihrem lokalen Esri-Vertreter oder Partner in Betracht ziehen. Für Hintergrundmaterial suchen Sie auf GeoNet im Bereich Open Platform, Standards and Interoperability.<\/P><\/BODY><\/HTML>
