Da die immer noch weit verbreitete und sehr beliebte GIS-Anwendung ArcGIS Desktop mit ArcMap ab März 2026 von Esri nicht mehr unterstützt werden wird, haben dessen Benutzerinnen und Benutzer keine Wahl: In den nächsten zwei Jahren müssen alle Projekte und Produkte migriert werden, typischerweise nach ArcGIS Pro.
Je früher mit der Migration begonnen wird, desto mehr Zeit gibt es, um sich an die neuen Tools zu gewöhnen. Und umso mehr Zeit steht zur Verfügung, um zum Beispiel auch komplexere ArcMap-Extensions zu migrieren. Wir durften diesen Winter für einen Kunden eine umfangreiche Migration einer komplexen .NET-Extension von ArcMap zu ArcGIS Pro umsetzen und teilen in diesem Blogbeitrag Erfahrungen, die wir dabei gemacht haben.
Die Migration
Vorneweg muss beachtet werden, dass viele Neuerungen im ArcGIS Pro SDK (Software Development Kit) nicht per se rückwärtskompatibel sind mit ArcMap-Extensions. Dadurch kann bei der Migration von Extensions ein gewisser Aufwand entstehen.
Während der Migration haben uns insbesondere Themen wie die Migration von .NET 4 zu .NET 6, asynchrone Programmierung und das neue GUI beschäftigt. Bei der Migration standen wir vor verschiedenen Herausforderungen und spannenden Entdeckungen. Unser Hauptziel bestand darin, die Migration schnell und effizient durchzuführen. Wir wollten daher in Absprache mit dem Kunden den UX/UI-Aspekt und den Code möglichst wenig ändern.
Wir konnten feststellen, dass die Einhaltung von Clean-Code-Prinzipien und das Vorhandensein von umfassenden Anleitungen zur Funktionalität der Extension entscheidend waren für die Migration.
Herausforderungen
Neues Gewand durch frisches UX/UI
Das GUI unserer Anwendung war vollständig in Windows.Forms geschrieben. Dies erwies sich als Glücksfall, da es ohne zusätzlichen Aufwand weiterhin verwendet werden konnte. Die Ribbon-Buttons haben sich verbessert und sind nun einfacher zu implementieren sowie für die anwendende Person ansprechender. Die Einführung von XAML für die Dockpane-Fenster brachte aber eine Änderung mit sich, welche einiges an Aufwand bedeutete. Generell kann man sagen, dass das GUI nach der Migration nun modern daherkommt:
Async-Methoden: Ist der Aufwand gerechtfertigt?
Die neue Framework-Anforderung, alle Methoden, die Objekte in der Karte verändern, asynchron im UI-Thread auszuführen, stellte eine Herausforderung dar bei der Migration. Da ArcMap-Extensions nicht mit einer solchen Architektur geschrieben wurden, ist der Aufwand erheblich, potenziell verschachtelte Methoden zu finden und dann die Methoden, die sie aufrufen, durchgehend asynchron zu schreiben.
Ein Beispiel, wie in ArcGIS Pro ein Feature Layer erstellt werden kann, zeigt untenstehendes Code-Snippet:
internal class MyButton : Button
{
protected override async void OnClick()
{
// Call the asynchronous method
await MyAsyncMethod();
}
private async Task MyAsyncMethod()
{
// Create a new layer asynchronously
await QueuedTask.Run(() =>
{
// Create a new feature layer
var featureLayer = LayerFactory.Instance.CreateFeatureLayer();
});
}
}Um diese Architektur bei der Migration zu berücksichtigen, müssen alle Methoden, die Map-Objekte wie zum Beispiel Feature Layer erstellen oder bearbeiten, asynchron geschrieben und aufgerufen werden.
Der beabsichtigte Nutzen dieser Änderung ist, dass das UI reaktiv bleibt, auch während Prozesse im Hintergrund ablaufen. Da die Funktionalitäten der Extension jedoch sehr stark voneinander abhängig sind, muss im vorliegenden Fall dennoch auf das Ende der Berechnung jeder Methode gewartet werden. In unserem Beispiel konnten wir daher keinen grossen Vorteil aus dieser Neuerung ziehen.
Die ArcGIS Pro-Werkzeugkiste
Um Geoprocessing-Werkzeuge (GP-Tools) im ArcGIS Pro SDK zu verwenden, wird neu die Übermittlung von Parametern als Strings gefordert. Das ist nicht hilfreich in Bezug auf Typ-Sicherheit. Und: Es gibt kein direktes Feedback zur Korrektheit der Eingabeparameter, bis das Werkzeug ausgeführt wurde.
Zudem mussten wir leider feststellen, dass die Eingabeparameter für bestimmte Werkzeuge nicht immer der Dokumentation entsprachen. Ein Beispiel hierfür ist das GP-Tool «Point Statistics», welches in der Dokumentation statistics_type als letzten Eingabeparameter aufführt. Dieser Parameter muss jedoch an dritter Stelle verwendet werden, um das Tool korrekt auszuführen. Bei solchen Problemen ist man auf die Qualität der Fehlermeldungen (IGPResult) des Tools angewiesen, um den Fehler identifizieren zu können. Leider lässt deren Aussagekraft teilweise noch zu wünschen übrig, was zu «trial and error» führen kann.
Ein Beispiel, wie ein GP-Tool ausgeführt werden kann, zeigt folgendes Code-Snippet:
public async Task RunGeoprocessingTool()
{
// Specify the name or path of the geoprocessing tool
string toolName = "ToolName";
var parameterList = Geoprocessing.MakeValueArray(input_1, input_2).ToList();
var environmentArray = Geoprocessing.MakeEnvironmentArray();
IGPResult result = await Geoprocessing.ExecuteToolAsync(toolName,
parameterList, environmentArray);
}Als Alternative bietet sich die Erstellung einer ArcGIS Python-Toolbox an. ArcPy verfügt über ein bereits besser dokumentiertes API und kann GP-Tools direkt aufrufen. Über eine solche Toolbox konnten wir zum Beispiel Diagramme erstellen, welche im SDK nur sehr begrenzt vorhanden sind.
Unser Fazit aus dem zurückliegenden Migrationsprojekt ist, dass die meisten Funktionalitäten und GP-Tools von ArcMap auch in ArcGIS Pro ähnlich ausgeführt werden können. Manchmal muss man diese aber über Umwege ausführen. Die richtige Strategie zu finden, kann im Einzelfall aufwändig sein.
Fazit
Wie gross ist der Aufwand für eine Migration? – Der ist stark abhängig davon, wie gut die bestehende Extension programmiert (zum Beispiel wie sauber und verständlich die Architektur ist) und wie gut sie dokumentiert ist. Im vorliegenden Fall war die Migration herausfordernd und aufwändiger als zuerst angenommen. Der Aufwand konnte durch eine reine Migration reduziert werden – also ohne dass im gleichen Arbeitsschritt die User Experience bereits ideal auf die neuen Arbeitsschritte im ArcGIS Pro angepasst worden sind. Es lohnt sich aus unserer Sicht, möglichst frühzeitig eine fundierte Analyse dazu durchzuführen, ob ein Neu-Schreiben einer Extension oder eine Migration unter dem Strich ein attraktiveres Ergebnis mit sich bringt.
Mit dem Migrationsprojekt und unseren anderweitigen Erfahrungen in diesem Kontext fühlen wir uns sehr gut gerüstet, weitere Migrationen umzusetzen. Wir unterstützen auch Sie gerne bei Prüfung der Codequalität Ihrer ArcMap-Extensions, bei der Einschätzung des Migrationsaufwandes sowie bei der Umsetzung an sich. Sie dürfen mich gerne kontaktieren, wenn Sie in diesem Thema Fragen haben.