GIS, UNIGIS und andere Kleinigkeiten » ESRI

ESRI Developer Summit

Peter Schär — Mon, 29 Mar 2010 11:57:12 +0000

Einer der interessantesten ESRI-Events aus meiner Sicht ist jeweils der Developer Summit, werden da doch jeweils die Features der neuen Software-Versionen nicht nur auf ein zwei Folien sondern auch im (technischen) Detail vorgestellt. Dadurch ergibt sich eine recht gute Einschätzung darüber, ob ein neues Feature wirklich einen Zusatznutzen bringt und sich der Umstieg auf eine neuen ArcGIS-Version lohnt. Mittlerweile geht das auch ohne, dass man in Palm Springs anwesend sein muss. Eine Vielzahl an Konferenzteilnehmern haben über ihre Eindrücke per Twitter undBlogs berichtet. ESRI stellt ausserdem viele Videos und Präsentationen sehr schnell ins Netz.

Dieses Jahr hat sich natürlich alles um das bevorstehende ArcGIS 10 gedreht. Es hat sich auch gezeigt, dass die Umbenennung von ArcGIS 10 auf 9.4 doch berechtigt war. Es ändert sich doch so einiges.

ArcGIS Server

Obwohl angekündigt wurde, dass eigentlich 9.3.1 das Server-Release war, gibt es doch auch im Server-Bereich einige sehr interessante Neuerungen:

neue Versionen (2.0) aller Web APIs (Flex, Javascript, Silverlight) mit vielen neuen Möglichkeiten.
Über die REST API kann neu auch editiert werden (Feature Layers). Das ist ein wichtiger Fortschritt. Noch nicht sicher bin ich, auf welchem Lizenzlevel dieses Editieren verfügbar sein wird.
In der REST API sind nun auch Informationen über Legenden und Symbologie verfügbar.
Die SOAP und die REST API können über eigene Mechanismen erweitert werden.
ein neuer Extract Service, mit dem Geodaten extrahiert, in das passende Format umgewandelt und auch gleich gezippt werden können.
Im WMS-Bereich werden nun alle SLD-Funktionen unterstützt, v.a. auch der Befehl GetLegendGraphic.

Aufgefallen ist mir die Tatsache, dass praktisch nichts über das Web ADF zu hören war. Ich gehe davon aus, dass ESRI die Zukunft im Server-Bereich eher bei den neuen Web APIs sieht, als beim Web ADF. Ich habe das Gefühl, dass das Web ADF etwas auf dem Abstellgleis steht.

Was auch erwähnt wurde, ist die Tatsache, dass der Server auch in ArcGIS 10 kein 64bit-Produkt sein wird. ESRI hat jedoch bestätigt, dass an einer solchen Version entwickelt wird (development project). Es besteht also Hoffnung.

ArcGIS Mobile

Hier ist sehr vieles im Umbruch. Bisher basierte ArcGIS Mobile auf Windows Mobile. Das wird sich ändern. ESRI wird neu auch aktuelle Plattformen wie iPhone, Android oder Windows Phone 7 unterstützen. Als erste Plattform startet das iPhone. Hier bietet ESRI eine out of the box-App (via Apples App Store) sowie ein SDK zur Entwicklung eigener Applikationen. Die weiteren Plattformen folgen später.

ArcGIS Desktop

Hier sind die interessantesten Neuerungen zu finden:

überarbeitete GUI, d.h. dockable windows (die sich verschieben lassen, ohne dass die Karte refreshed wird), ArcCatalog als dockable window in ArcMap etc.
die Python-Integration wurde komplett überabeitet. Das Python-Fenster in ArcMap ist nun mit Intellisense (automat. Befehlsvervollständigung sowie Online-Hilfe) ausgestattet. Geoprocessing-Befehle (Scripts, Models oder Tools) können nun im Hintergrund ablaufen, so dass der Anwender weiterarbeiten kann. Und mit arcpy.mapping wird eine der bislang grössten Limitationen von ArcGIS beseitigt: das Manipulieren von MXD-Dokumenten. Bisher ging das nur mit ArcObjects und war sehr mühsam. Neu können MXDs (inkl. Inhalte wie Layer, Tables, Layout-Elemente etc.) angesprochen und manipuliert werden. Es wird also möglich sein, die Datenquellen von Layern automatisiert ändern zu lassen. Das ist eine sehr wichtige Hilfe gerade in Migrations-Szenarien. Da jedoch Python auch weiterhin kein ArcObjects-Ersatz sein soll (coarse grained), gibt es auch hier noch einige mehr oder weniger bedauernswerte Lücken. So können Layer-Einstellungen wie Symbologie oder Massstabsbereiche (scale dependent rendering) nicht manipuliert werden. Nichtsdestotrotz ist arcpy.mapping ein grosser Schritt nach vorne.
Es gibt eine neue Art von Erweiterungen: die Add-Ins. Diese können in .NET oder Java (später vielleicht auch in Python) programmiert werden. Die Erweiterung können wie bisher die gesamte Bandbreite der ArcObjects nutzen. Die Installation ist vereinfacht worden. Die Add-Ins bestehen aus einer einzigen Datei (eine gezippte Datei), die nur ins richtige Verzeichnis kopiert werden kann. ArcGIS überwacht dieses Verzeichnis und lädt bei Bedarf die Applikation. Es sind somit für die Installation keinerlei Adminrechte mehr oder Einträge in die Registry mehr nötig. Das Add-In-Verzeichnis kann auf dem lokalen Filesystem aber auch auf einem Netzwerk-Laufwerk sein. In letzterem Falle übernimmt dieses Netzwerklaufwerk sozusagen die Software-Verteilung.

Geodatabase

Auch die Geodatabase wird nicht verschont:

Query Layers sind Tabellen in einer Datenbank, die einen spatial type kennt (Oracle Spatial, PostGIS, SQL Server). Solche räumliche Tabellen können in ArcGIS angezeigt werden, ohne dass ArcSDE installiert und lizenziert werden muss!
Für den Zugriff auf die File Geodatabase von ausserhalb von ArcGIS wird es eine API geben. Diese ist C++-basiert und unterstützt nur Simple Features also nicht den gesamten Geodatabase-Umfang. Das dürfte also noch nicht der erwartete Shapefile-Ersatz werden.
Für Rasterdaten gibt es ein neues Mosaic Dataset, das eine Kreuzung zwischen Rasterkatalog und Mosaik mit Cache-ähnlicher Performance sein soll. Da bin ich gespannt, ob es die Performance-Versprechen einhalten kann.
Schlussendlich erhält die Geodatabase in ArcSDE ein neues, einfacheres Schema.

Cloud

Das buzz word schlechthin war die Cloud. Was auch immer darunter verstanden wird, ESRI bewegt sich stark in diese Richtung. Dies belegen drei neue Angebote von ESRI:

Für ArcGIS Server wird es demnächst auch vorgefertigte Images (AMI) für Amazons Wolkendienst EC2 geben. Zuerst für Besitzer eines Enterprise License Agreement (ELA) und danach auch für alle Anwender (inkl. stundenbasierter Abrechnung).
ArcGIS Explorer wird es neu auch als Browser-Anwendung geben auf Basis von Silverlight. Und das ganze auch noch kostenfrei. Damit wird ein recht brauchbarer, vorkonfigurierter Webviewer auf den Markt treten, gegen den bestehende Produkte antreten müssen.
ESRI baut ein neues Portal namens ArcGIS.com auf, das es erlaubt, Karten, Dienste und Applikationen hochzuladen und mit anderen Anwendern zu teilen. Da fehlt eigentlich nicht mehr viel bis zu einem GDI-Portal.

Fazit

ArcGIS 10 ist wohl zu Recht ein Major Release. Die vielen interessanten Neuerungen dürften einen Umstieg wohl rechtfertigen. Der Releasetermin ist der Juni (vor der ESRI User Conference). Bereits diese Woche (1. April) soll ein Prerelease erscheinen. Ich bin gespannt.

CSW-Dienst bei Geocat.ch

Peter Schär — Mon, 22 Mar 2010 10:18:18 +0000

Letzte Woche habe ich im RSS-Feed von Geocat.ch die Metadaten zum CSW-Dienst von Geocat.ch entdeckt. Das wollte ich doch gleich mal ausprobieren. Da in ArcGIS defaultmässig kein CSW-Dienst eingebaut ist (schade!), musste ich den CSW-Client von der ESRI-Homepage runterladen und installieren (ArcGIS Server Geoportal Extension 9.3.1 CSW Clients Update). Das ging problemlos (Anleitungen gibt’s hier und hier). Ich konnte anschliessend im vorkonfigurierten US-Portal suchen. Danach habe ich die Geocat-URL eingetragen und das Profil GeoNetwork CSW 2.0.2 APISO ausgewählt. Das ganze funktioniert jedoch nicht. Ich erhalte regelmässig eine Fehlermeldung (The server committed a protocol version. Section=ResponseStatusLine):

Eine Protokollier-Aktion mit Fiddler im HTTP-Verkehr hat folgendes ergeben. Auf den GetCapabilites-Request erhalte ich das GetCapabilities-Dokument zurück. Der Client nimmt sich dann die dort definierte URL für den GetRecords-Befehl (http://www.geocat.ch/geonetwork/srv/en/csw) und schickt den POST-Request dorthin. Als Antwort erhält er jedoch den HTTP-Status 302, d.h. eine Umleitung (moved temporarily) auf eine andere Adresse (http://www.geocat.ch/geonetwork/srv/eng/csw). Der Client holt sich diese neue Adresse und schickt einen Request dorthin, jedoch keinen korrekten (ohne Parameter), so dass es zu einem Fehler kommt. Entweder der Client kann nicht korrekt mit dem Redirect umgehen oder mit den Geocat-URLs stimmt etwas nicht. Das Fiddler-Log habe ich mal hier angehängt:

fiddler_protokoll

Hat jemand den CSW-Dienst von Geocat schon erfolgreich testen können?

[Update]: Ich habe noch etwas weitergetestet (u.a. mit handgemachten Requests). Der Dienst hat tadellos funktioniert. Der Fehler liegt somit wohl beim ArcGIS-Client, der nicht korrekt mit dem Redirect umgehen kann.

Änderungen im Geodatabase-Schema für ArcSDE 10

Peter Schär — Tue, 16 Mar 2010 17:47:52 +0000

Heute ist im “Inside the Geodatabase”-Blog von ESRI ein Artikel über die Änderungen im Geodatabase-Schema erschienen, die für ArcSDE 10 vorgesehen sind. Betroffen sind die GDB_*-Tabellen einer ArcSDE-Installation nicht jedoch die SDE_*-Tabellen. In Zukunft gibt es anstelle der Vielzahl an GDB_*-Tabellen nur noch ganze vier Tabellen. Das mag einige Vorteile bringen (da bin ich gespannt auf den Developer Summit von nächster Woche), es hat aber auch einen markanten Nachteil. Die mit ArcGIS 9.2 SP5 eingeführte Aufwärtskompatibilität zwischen ArcGIS und ArcSDE wird wieder verworfen. Bisher war es ja möglich – sei es mit Direct Connect, sei es mit SDE-Connect – z.B. mit einem ArcGIS Desktop 9.2 auf eine ArcSDE-Datenbank 9.3.1 zuzugreifen. Auf eine ArcSDE 10-Geodatabase kann laut diesem Artikel nur mit ArcGIS 10 zugegriffen werden und nicht mehr mit früheren Versionen! Konkret heisst das, dass die Datenbank erst dann auf Version 10 angehoben werden kann, wenn der allerletzte Client ArcGIS 10 installiert hat. Das kann gerade in grossen und heterogenen Umgebungen (> 400 ArcGIS Desktop-Installationen in meinem Fall) ein zu grosses Hindernis sein, weil oft aus technischen aber auch organisatorischen Gründen ein ArcGIS-Releasewechsel nicht einfach in ein paar Wochen durchgezogen werden kann, sondern dafür Monate – wenn nicht sogar mehr – benötigt werden.

Ich bin über diese Ankündigung doch ziemlich enttäuscht. Ich hätte von ESRI erwartet, dass die mit ArcGIS 9.2 eingeführte Aufwärtskompatibilität beibehalten wird. Diese Pflicht zu identischen Software-Versionen auf der Datenbank und auf Client-Seite ist sehr störend und bei anderen Software-Systemen auch nicht unbedingt üblich. ESRI, bitte nachbessern!

ArcGIS Server 9.3.1 auf Windows Server 2008 R2

Peter Schär — Thu, 11 Mar 2010 06:56:33 +0000

Heute morgen habe ich es zwitschern gehört, dass ArcGIS Server 9.3.1 von ESRI nun auch auf Windows Server 2008 R2 freigegeben wurde. Und siehe da: der entsprechende Eintrag findet sich auch auf der System Requirements-Seite.:

Das ist an und für sich eine sehr erfreuliche Entwicklung. Auffallend ist nur, dass ich vor gut einem Monat eine Anfrage zum genau gleichen Thema an den ESRI-Support gerichtet und die Antwort erhalten habe, dass Win2008 R2 erst mit ArcGIS Server 10 freigegeben wird und nicht mehr für 9.3.1! Ich würde mir in so einem Fall eine klarere Information von ESRI wünschen. Warum nicht z.B. auf der System Requirements-Seite vermerken, dass Win2008 R2 zurzeit geprüft wird und das Resultat noch offen lassen. So wäre zumindest klar, dass noch Abklärungen im Gange sind.

Wie auch immer: jetzt darf ich die frohe Kunde an unser Rechenzentrum weiterreichen.

News von der ESRI Federal User Conference

Peter Schär — Sun, 21 Feb 2010 16:04:44 +0000

Diese Woche ist in den USA die ESRI Federal User Conference zu Ende gegangen. Das Mitverfolgen ist dank Twitter und Blogs jederzeit möglich, ohne selbst vor Ort zu sein. Die aus meiner Sicht interessantesten Infos in Kürze:

ESRI hat eine Partnerschaft mit Amazon verkündet. Damit soll ArcGIS Server 10 auf der Elastic Cloud angeboten werden. Vorerst aber nur für Kunden mit einem Enterprise License Agreement.
Es wurde erstmals die schon früher angekündigte iPhone-Applikation gezeigt. ArcGIS Server 10 wird einerseits eine vorkonfektionierte iPhone-Applikation anbieten (im AppStore) und andererseits eine spezielle API für iPhone. Das ist an und für sich recht spannend. Ich bin jedoch nicht mehr so überzeugt, ob es der richtige Weg ist, im mobilen Bereich nur Angebote für einzelne Plattformen (iPhone oder Windows Mobile) anzubieten und andere Plattformen aussen vor zu lassen. Es entwickelt ja zum Glück niemand Webapplikationen, die nur in bestimmten Browsern funktionieren. In der mobilen Welt sollte das nicht anders sein. Recht drastisch zusammengefasst hat dieses Thema Peter-Paul Koch.
ArcGIS Explorer wird es in einer neuen Version geben (Build 1200) und — das ist neu — auch als Webapplikation “ArcGIS Explorer online“. Da bin ich wirklich gespannt, welche Funktionalität hier integriert ist. Das könnte eine sehr interessante und kostengünstige Alternative sogar zu ArcView werden. Der Wermutstropfen dabei: ArcGIS Explorer online ist eine Silverlight-Applikation.
Was auch schon angekündigt war, ist nun präzisiert worden. Mit ArcGIS 10 wird es mit Python möglich sein, auch die bisher “unberührbaren” MXDs und LYR-Files zu verarbeiten. Davon erhoffe ich mir einen erheblich einfacheren Umgang mit ungültigen Datenquellen und ein sehr einfaches Auslesen von MXD-Informationen (welche Layer sind enthalten etc.). Das wäre ein Quantensprung.
Und last but not least: die Entwicklung von ArcGIS 10 soll 400 Millionen Dollar gekostet haben! Wow! Kann das stimmen oder soll die Zahl die Lizenzkosten rechtfertigen

Wer mehr Informationen sucht, findet diese in den Konferenz-Videos bei ESRI. Schon sehr gespannt bin ich auf den Developer Summit (22.3. – 25.3.). Dort werden mit Sicherheit noch mehr Details zu ArcGIS 10 präsentiert werden.

JMeter mit ArcGIS Server

Peter Schär — Wed, 18 Nov 2009 16:50:02 +0000

Das Thema Performance darf beim ArcGIS Server nicht unterschätzt werden. Doch wie misst man Performance? Es gibt von ESRI zwar einige Hilfstools wie MXDPerfStat, das Geodatabase Toolset oder die Map Service Publishing Toolbar. Damit kann man ziemlich gut die Performance einzelner MXDs optimieren und messen. Schwieriger umzusetzen sind grösser angelegte Lasttests (auf mehrere Dienste, mehrere Anwender etc.). ESRI hat hier keine Haus-Lösung anzubieten, das ist aber auch gar nicht nötig, da das Testen von Diensten und Webapplikationen nicht wirklich eine GIS-spezifische Anforderung ist. Deshalb kann hier auf bestehende Tools zurückgegriffen werden.

Eines der überzeugendsten Tools ist sicherlich JMeter, ein Apache-Projekt. Damit können sehr ausgeklügelte und breit angelegte Performance-Tests (z.B. von mehreren Clients aus) gefahren werden. JMeter ist eine Java-Applikation, die somit auf fast jedem Desktop lauffähig ist. Die Dokumentation ist ziemlich gut, so dass hier auf weitere Worte verzichtet wird. Die beste Einstiegshilfe war das Aufsetzen eines JMeter-Proxies, mit dem ganze Sessions im Browser aufgezeichnet werden können. Diese Aufzeichnungen sind perfekte Vorlagen für das weitere Verfeinern eines Testplans. In Bezug auf ArcGIS Server bietet sich die REST-Schnittstelle als Test-Schnittstelle an, da hier alle Parameter einfach über URL-Parameter übertragen werden. Mit JMeter kann aber sicher auch die SOAP-Schnittstelle angesteuert werden. Es kann aber auch eine auf ArcGIS Server aufbauende Applikation wie z.B. WebOffice angesprochen werden. Der erarbeitete Testplan kann gespeichert werden, damit ist garantiert, dass immer derselbe Test ausgeführt wird. Das erleichtert den Vergleich zu verschiedenen Zeiten. Mich hat JMeter überzeugt!

Eigene Geoprocessing-Tools mit ArcObjects Teil 7: Fazit

Peter Schär — Wed, 08 Aug 2007 12:39:51 +0000

Die Bereitstellung von Funktionalität in Form von Geoprocessing-Tools hat einige gewichtige Vorteile:

Der Programmierer muss für die gesuchte Funktionalität nicht auch noch eine eigene Oberfläche programmieren, sondern kann elegant auf die bestehende Geoprocessing-Umgebung zurückgreifen und sich auf die eigentliche Programmierarbeit konzentrieren.
Der Benutzer kann die Tools in der gewohnten Geoprocessing anwenden und nahtlos mit anderen Tools vermischen. Auch können die Tools in Model Builder-Modellen oder Python-Skripten verwendet werden.
Die Validierung der Parameter geschieht automatisch und muss vom Programmierer nicht manuell codiert werden. Dies ist eine grosse Zeitersparnis.

Natürlich sind auch einige Nachteile auszumachen und zwar vorwiegend im Bereich Dokumentation. ESRI hat diesem Thema meiner Meinung nach eher wenig Zeit und Dokumentation gewidmet. Es gibt auf EDN dazu nur gerade einen Artikel (“Building a custom geoprocessing function tool“) und ein eher mageres Code-Beispiel (“GPCalculateArea“). Zusätzlich dazu gibt es in den ESRI-Foren einen längeren Thread (“Programmatically Creating Toolboxes“) zum Thema. Das Fehlen etwas ausführlicherer Dokumentation macht die Umsetzung dieses eigentlich sehr interessanten Ansatzes recht umständlich. Dies hat wahrscheinlich auch dazu geführt, dass in den ESRI-Foren oder auch sonst im Internet praktisch keine weiterführenden Informationen dazu zu finden sind. Hier würde ich mir von ESRI einen kleinen Dokumentationseffort wünschen (ausführlichere Dokumentation, mehr Beispiele).

Übersicht:
Teil 1 (Einführung)
Teil 2 (Implementierung von IGPFunctionFactory)
Teil 3 (Implementierung von IGPFunction)
Teil 4 (Implementierung von IGPFunction:ParameterInfo)
Teil 5 (Implementierung von IGPFunction:Validate)
Teil 6 (Implementierung von IGPFunction:Execute)
Teil 7 (Fazit)

Eigene Geoprocessing-Tools mit ArcObjects Teil 6: IGPFunction.Execute

Peter Schär — Wed, 08 Aug 2007 12:36:19 +0000

Hier wird nun das eigentliche Tool ausgeführt. Doch bevor dies möglich ist, müssen aus den eingegebenen Parametern gewöhnliche ArcObjects werden. Als erstes muss dazu noch einmal geprüft werden, ob die vom Benutzer übergebenen Parameter auch gültig sind. Dies geschieht durch einen Aufruf der Validate-Methode. Anschliessend wird für jeden Parameter aus der Eigenschaft Value der eigentlich übergebene Wert geholt. Dieser muss jedoch zuerst entpackt werden:

IGPParameter parameter = (IGPParameter)paramvalues.get_Element(0);IGPValue parameterValue = GPUtils.UnpackGPValue(parameter);

Danach kann der Parameter je nach Typ in das richtige ArcObject umgewandelt werden. Dazu sind die zahlreichen Funktionen der Hilfsklasse IGPUtilities nützlich. Ist der Parameter z.B. eine Feature Class, dann wird die Methode DecodeFeatureLayer benötigt:

IFeatureClass featureClass;

IQueryFilter queryFilter;

if (gpValue is IGPFeatureLayer) {

    GPUtils.DecodeFeatureLayer(gpValue, out featureClass, out queryFilter);

Und schon hat man eine herkömmliche Feature Class sowie den dazugehörigen QueryFilter, der z.B. aus einer Definition Query stammt.

Ein genaues Studium der Methoden des IGPUtilites-Objekts lohnt sich, denn für praktisch jeden Parametertyp gibt es eine passende Funktion.

Hat man die Parameter in herkömmliche ArcObjects umgewandelt, kann die Funktionalität des Tools wie gewohnt programmiert und ausgeführt werden. Hier stehen einem dann alle Möglichkeiten in der riesigen ArcObjects-Welt offen.

Eigene Geoprocessing-Tools mit ArcObjects Teil 5: IGPFunction.Validate

Peter Schär — Wed, 08 Aug 2007 12:31:50 +0000

Die in der ParameterInfo gemachten Parameter-Definitionen sind schön und gut, nützen aber nichts, wenn nicht auch geprüft wird, ob sie eingehalten werden. D.h. ob der Benutzer gültige Parameter angegeben hat. Genau dies geschieht in der Validate-Methode. Glücklicherweise muss nicht jeder Parameter einzeln geprüft werden. In der Hilfsklasse IGPUtilities gibt es die Methode InternalValidate, die genau dies erledigt. Der Aufruf dieser Funktion bewirkt, dass alle vom Benutzer eingegebenen Parameter auf die Definitionen in ParameterInfo hin geprüft werden. Erfüllt ein Parameter diese Definition nicht, wird dem Benutzer automatisch ein Warnhinweis angezeigt. Es wird auch geprüft, ob alle obligatorischen Parameter angegeben wurden und ob die angegebenen Parameter (z.B. Feature Classes) tatsächlich existieren.

Sind nun darüber hinaus spezielle Anforderungen betreffend Validierung nötig, die von InternalValidate nicht abgedeckt werden, können diese zusätzlichen Tests separat in der Validate-Methode durchgeführt werden. Sollte Kommunikation mit dem Benutzer notwendig sein, weil einer der Parameter ungültig ist, sollte dies nicht via MessageBox geschehen, sondern über das IGPMessages-Objekt. Die InternalValidate-Methode macht dies genauso. Damit werden dem Benutzer Fehlermeldungen und Warnhinweise konsistent in der GUI angezeigt.

Desweiteren muss in der Validate-Methode auch der in der ParameterInfo-Beschreibung erwähnte Spezialfall des Derived-Parameters berücksichtigt werden. Fügt ein Tool einer Feature Class ein Feld hinzu, dann ist der Output-Parameter eben vom Typ Derived. Dies dient einzig dem Zweck, dass im Model Builder dieses neue Feld bereits angezeigt wird, ohne dass es in Tat und Wahrheit schon existiert. Damit dies funktioniert muss in der Validate-Methode der Parameter d.h. die Feature Class geklont (mit dem IClone-Objekt) und dieser geklonten Feature Class das Feld hinzugefügt werden. Die geklonte Feature Class existiert nirgends in einer Datenbank oder in einem Verzeichnis sondern ausschliesslich im Speicher. Die geklonte und um das Feld ergänzte Feature Class wird anschliessend dem Parameter als Wert wieder eingespiesen. Nur so funktioniert ein Tool im Model Builder korrekt.

Eigene Geoprocessing-Tools mit ArcObjects Teil 4: IGPFunction.ParameterInfo

Peter Schär — Wed, 08 Aug 2007 12:28:39 +0000

Die Eigenschaft ParameterInfo ist von zentraler Bedeutung. Sie beschreibt nämlich die einzelnen Input- und Output-Parameter des GP-Tools. Genauer gesagt enthält die Eigenschaft einen Array von IGPParameter-Objekten. Mit IGPParameter können alle möglichen Parameter von Feature Classes über Zahlen bis zu Mehrfach-Auswahllisten definiert werden.

Der Typ des Parameters wird hauptsächlich durch die Eigenschaft DataType definiert. Eine Liste aller möglichen Parametertypen ist hier zu finden. Eine Besonderheit gilt es anzumerken: Soll der Parameter eine FeatureClass sein, hat man zwei Möglichkeiten: DEFeatureClassType oder GPFeatureLayerType. DEFeatureClassType meint immer die Feature Class so wie sie in der DB oder als Shapefile vorliegt. Mit GPFeatureLayerType ist zwar dieselbe Feature Class gemeint aber zusätzlich auch in Form eines FeatureLayers (in ArcMap). Es ist meistens sinnvoll, den DataType auf GPFeatureLayerType zu setzen, da damit auch eventuelle Definition Queries und Selections, die auf die Feature Class angewendet werden, berücksichtigt werden können. Bei DEFeatureClassType ist dies nicht möglich.

Zusätzlich kann der Parameter mit den Eigenschaften Name und DisplayName so beschrieben werden, dass der Benutzer begreift, was er hier eingeben muss.

Sehr wichtig ist daneben auch noch die Eigenschaft ParameterDependencies. Damit können Beziehungen/Abhängigkeiten zwischen verschiedene Parametern hergestellt werden. Wenn z.B. Parameter1 eine Feature Class ist und Parameter2 ein Feld (Attribut), dann wird durch die Abängigkeit dem Benutzer in der Geoprocessing-GUI für den Parameter2 automatisch eine Liste der Felder der Feature Class aus Parameter1 angezeigt, aus der er auswählen kann.

Ähnlich wichtig ist die Eigenschaft Domain. Damit kann der Parameter innerhalb des oben angegebenen DataTypes weiter eingegrenzt werden. Ist der DataType eine beliebige FeatureClass kann mit der Domain-Eigenschaft bestimmt werden, dass nur Feature Classes vom Typ Polygon akzeptiert werden. Oder: Ist der DataType eine Zahl, kann mit der Domain-Eigenschaft der gültige Wertebereich angegeben werden. Die Domain-Eigenschaft ist sehr wichtig und hilfreich, um falsche Benutzereingaben zu vermeiden.

Mit der Eigenschaft Value kann dem Parameter ein Default-Wert zugewiesen werden.

Da es sowohl Input- als auch Output-Parameter gibt, muss dies in der Parameter-Definition ebenfalls spezifiziert werden. Dies geschieht mit der Direction-Eigenschaft. Ein Input-Parameter ist ein Parameter, den das Tool als Ausgangswert benötigt. Ein Output-Parameter hingegen ist im Prinzip das Resultat des Tools. Entsteht als Ergebnis des Tools z.B. eine neue Feature Class, muss diese neue Feature Class als Output-Parameter definiert werden. Dies ist übrigens auch der Fall, wenn das Tool gar keine neue Feature Class erzeugt, sondern eine bestehende nur verändert (d.h. ein Feld hinzufügt). In diesem speziellen Fall wird der Parameter in der Eigenschaft Direction als Output-Parameter definiert und in der Eigenschaft ParameterType als Derived-Parameter. Dies ist notwendig, damit das Tool auch im Model Builder reibungslos funktioniert. Fügt ein Tool einer Feature Class ein Feld zu, dann muss dieses neue Feld im Model Builder angezeigt werden. Schliesslich ist es ja möglich, dass genau dieses Feld als Input-Parameter in einem weiteren Tool benötigt wird. Nur wenn dieses neue Feld als Derived markiert ist, taucht es im Model Builder auf. Auf den Gebrauch des Tools in der Toolbox oder in der Kommandozeile hat die Derived-Markierung keinen Einfluss.

Über die ParameterType-Eigenschaft wird ausserdem gesteuert, ob der Parameter optional oder obligatorisch ist.

Beispiel für einen Parameter, der eine Feature Class vom Typ SimpleJunction sein soll:

IGPParameterEdit gpParameter0 = new GPParameterClass();

gpParameter0.DataType = new GPFeatureLayerTypeClass();

IGPValue gpValue0 = new GPFeatureLayerClass();

gpParameter0.Value = gpValue0;

gpParameter0.Direction = esriGPParameterDirection.esriGPParameterDirectionInput;

gpParameter0.DisplayName = "Input-Layer";

gpParameter0.Enabled = true;

gpParameter0.Name = "inputLayer";

IGPFeatureClassDomain gpDomain0 = new GPFeatureClassDomainClass();

gpDomain0.AddFeatureType(esriFeatureType.esriFTSimpleJunction);

gpParameter0.Domain = (IGPDomain) gpDomain0;

gpParameter0.ParameterType = esriGPParameterType.esriGPParameterTypeRequired;

Beispiel für einen Parameter vom Typ Feld. Das Feld soll einerseits ein Feld der oben ausgewählten Feature Class sein und andererseits vom Typ Double sein:

IGPParameterEdit gpParameter1 = new GPParameterClass();

gpParameter1.DataType = new FieldTypeClass();

IGPValue gpValue1 = new FieldClass();

gpParameter1.Value = gpValue1;

gpParameter1.Direction = esriGPParameterDirection.esriGPParameterDirectionInput;

gpParameter1.DisplayName = "Feld";

gpParameter1.Enabled = true;

gpParameter1.Name = "inputLayerFeld";

gpParameter1.AddDependency("inputLayer");

IGPFieldDomain gpDomain1 = new GPFieldDomainClass();

gpDomain1.AddType(esriFieldType.esriFieldTypeDouble);

gpParameter1.Domain = (IGPDomain) gpDomain1;

gpParameter1.ParameterType = esriGPParameterType.esriGPParameterTypeRequired;