BlogMapsGISKontakt

Master Thesis

Endlich geschafft! Nach einigen Mühen und unter fast vollständigem Ausnutzen des Verlängerungszeitraums habe ich meine UNIGIS Master Thesis fertiggestellt. Inhaltlich geht es in der Arbeit um den Aufbau eines GIS-basierten Grundeigentumsystems in Tansania, wobei ich mich hauptsächlich um technische Aspekte gekümmert habe. Die organisatorischen und formalen Aspekte eines solchen Systems wurden in einer separaten Arbeit von Klaus Mithöfer behandelt. Im Rückblick kann ich sagen, dass ich viel von der Arbeit an der Master Thesis profitiert habe. Auf rein technischer Ebene bin ich nun versiert im Umgang mit PostGIS, Geoserver und OpenLayers -- dem Open Source Geospatial Stack. Das Potenzial dieses Stacks scheint mir enorm. Andererseits musste ich mich für das Verfassen der Arbeit intensiv in die Materie eingraben. So eine vertiefte Auseinandersetzung mit einem Thema -- auch auf theoretischer Ebene -- tut ab und zu sicher gut. Wer an der Master Thesis interessiert ist, kann sie einfach downloaden und anschauen:
Master Thesis (pdf, 2.5Mb)

Die Master Thesis ist der letzte Baustein in meinem UNIGIS-Studium, so dass ich mich nun erneut "Master of Science" nennen kann. Auch abgesehen vom Titel hat sich der Aufwand der letzten zwei Jahre auf jeden Fall gelohnt. Folgende Punkte sind für mich die zentralen Gewinne:
  • Durch das breite Curriculum hatte ich die Gelegenheit, mir einiges an zusätzlichem Fachwissen anzueignen. Als wichtigste Bereiche sind hier Interoperabilität und ArcGIS Server zu nennen.
  • Auch in methodischer Hinsicht konnte ich stark profitieren (Projektmanagement und Kommunikation).
  • Nicht zuletzt hatte ich durch UNIGIS die Gelegenheit, interessante GIS-Interessierte aus den verschiedensten Branchen kennenzulernen.
Ein paar wenige Mängel waren auch auszumachen:
  • Die Blackboard-Plattform erschien mir nicht immer sehr anwenderfreundlich. Im Internet bin ich mich modernere, reaktionsschnellere Interfaces gewohnt, so dass ich mich des öfteren aufregen musste.
  • Die verschiedenen Module waren nicht alle gleich relevant und interessant für mich. Dies lässt sich jedoch kaum vermeiden, wenn ein so breites Angebot verfügbar ist.
Die positiven Aspekte haben jedoch deutlich überwogen. Nichtsdestotrotz bin ich mehr als froh und erleichtert, dass ich das Studium nun hinter mir habe. Es gibt ja noch andere Dinge, die man in seiner Freizeit anstellen kann...
Ähnliche Beiträge:
UNIGIS Master Thesis Workshop
UNIGIS-Modul 9: Kartographie und Visualisierung
AGIT 2007
LBS Summer School
1. UNIGIS-Tag Schweiz
Comments (0)  Permalink

Liste der WebGIS-Anwendungen des Bundes

Die Swisstopo hat es endlich geschafft, auf ihrer Internetseite eine Liste der mittlerweile doch recht zahlreichen WebGIS-Anwendungen zu publizieren. Zwar ist es nur eine PDF-Liste, aber immerhin besser als gar nichts. Die Liste konzentriert sich auf WebGIS-Anwendungen, von Webdiensten (WMS oder WFS) ist aber noch nichts zu sehen.
Ähnliche Beiträge:
Geoportal des Kantons Bern
Master Thesis
UNIGIS Master Thesis Workshop
Neue Horizonte
Eigene Geoprocessing-Tools mit ArcObjects Teil 7: Fazit
Comments (0)  Permalink

Geoportal des Kantons Bern

Nun hat auch der Kanton Bern (mein neuer Arbeitgeber) ein öffentliches Webmapping-Angebot. Das ganze firmiert unter dem Namen Geoportal des Kantons Bern und bietet eine recht grosse Auswahl an interessanten Karten. Zusätzlich dient das Geoportal auch als Anlaufstelle für den Download von Geodaten.
Ähnliche Beiträge:
Liste der WebGIS-Anwendungen des Bundes
Neue Horizonte
Master Thesis
UNIGIS Master Thesis Workshop
Eigene Geoprocessing-Tools mit ArcObjects Teil 7: Fazit
Comments (0)  Permalink

UNIGIS Master Thesis Workshop

Ende September war ich nun schon zum vierten Mal in Salzburg, um einen UNIGIS-Anlass zu besuchen. Dieses Mal waren es keine Studientage sondern der Master Thesis Workshop. Im Zentrum standen diesmal wir Studenten. Jeder Teilnehmer hielt einen kurzen Vortrag über seine Master Thesis mit anschliessender Diskussion. Ich habe dieses Vorgehen sehr geschätzt, hat es mir doch erlaubt, die Themen der anderen Studenten genauer kennenzulernen. Dabei fand ich die Bandbreite der Themen sehr interessant und faszinierend. Allein diese Tatsache war den Besuch wert und ausserdem konnte ich mir doch noch den einen oder anderen Input für meine Arbeit holen. Auch das Wiedersehen der Mitstudenten (inkl. Einlösen von Freibierversprechen) hat Spass gemacht.
Ähnliche Beiträge:
AGIT 2007
Master Thesis
UNIGIS-Modul 9: Kartographie und Visualisierung
LBS Summer School
1. UNIGIS-Tag Schweiz
Comments (0)  Permalink

Neue Horizonte

Nach fast vier Jahren Tätigkeit verlasse ich per Ende August das Bundesamt für Umwelt (BAFU) und damit die Abteilung Wasser. Die Arbeit dort hat sehr viel Spass gemacht und war rückblickend äusserst lehrreich. Nun ist es aber Zeit für einen Wechsel, der mich ab 1. September in die Verwaltung des Kantons Bern führt, genauer ins Amt für Geoinformation.

Natürlich werde ich diesen persönlichen Blog weiterführen, und es gilt weiterhin, dass alle hier gemachten Aussagen ausschliesslich meine persönliche Meinung darstellen und nicht notwendigerweise mit der meines Arbeitgebers übereinstimmen müssen.
Ähnliche Beiträge:
Geoportal des Kantons Bern
Master Thesis
Liste der WebGIS-Anwendungen des Bundes
UNIGIS Master Thesis Workshop
Eigene Geoprocessing-Tools mit ArcObjects Teil 7: Fazit
Comments (0)  Permalink

Eigene Geoprocessing-Tools mit ArcObjects Teil 7: Fazit

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)
Ähnliche Beiträge:
Eigene Geoprocessing-Tools mit ArcObjects Teil 6: IGPFunction.Execute
Eigene Geoprocessing-Tools mit ArcObjects Teil 5: IGPFunction.Validate
Eigene Geoprocessing-Tools mit ArcObjects Teil 4: IGPFunction.ParameterInfo
Eigene Geoprocessing-Tools mit ArcObjects Teil 3: IGPFunction
Eigene Geoprocessing-Tools mit ArcObjects Teil 2: IGPFunctionFactory
Comments (0)  Permalink

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

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.


Ü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)
Ähnliche Beiträge:
Eigene Geoprocessing-Tools mit ArcObjects Teil 7: Fazit
Eigene Geoprocessing-Tools mit ArcObjects Teil 5: IGPFunction.Validate
Eigene Geoprocessing-Tools mit ArcObjects Teil 4: IGPFunction.ParameterInfo
Eigene Geoprocessing-Tools mit ArcObjects Teil 3: IGPFunction
Eigene Geoprocessing-Tools mit ArcObjects Teil 2: IGPFunctionFactory
Comments (0)  Permalink

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

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.

Ü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)
Ähnliche Beiträge:
Eigene Geoprocessing-Tools mit ArcObjects Teil 7: Fazit
Eigene Geoprocessing-Tools mit ArcObjects Teil 6: IGPFunction.Execute
Eigene Geoprocessing-Tools mit ArcObjects Teil 4: IGPFunction.ParameterInfo
Eigene Geoprocessing-Tools mit ArcObjects Teil 3: IGPFunction
Eigene Geoprocessing-Tools mit ArcObjects Teil 2: IGPFunctionFactory
Comments (0)  Permalink

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

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;

Ü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)
Ähnliche Beiträge:
Eigene Geoprocessing-Tools mit ArcObjects Teil 7: Fazit
Eigene Geoprocessing-Tools mit ArcObjects Teil 6: IGPFunction.Execute
Eigene Geoprocessing-Tools mit ArcObjects Teil 5: IGPFunction.Validate
Eigene Geoprocessing-Tools mit ArcObjects Teil 3: IGPFunction
Eigene Geoprocessing-Tools mit ArcObjects Teil 2: IGPFunctionFactory
Comments (0)  Permalink

Eigene Geoprocessing-Tools mit ArcObjects Teil 3: IGPFunction

Die Implementierung von IGPFunction ist etwas aufwendiger als die von IGPFunctionFactory. Hier wird nun das eigentliche GP-Tool definiert. Von zentraler Bedeutung sind dabei die Eigenschaft ParameterInfo sowie die Methoden Validate und Execute, die in den anschliessenden drei Beiträgen genauer beschrieben werden. Hier geht es um die übrigen Eigenschaften und Methoden.

Die String-Eigenschaften Name und DisplayName geben dem Tool einen Namen. DisplayName ist derjenige Name, der in der ArcGIS-Umgebung angezeigt wird (in der Toolbox oder auf der Kommandozeile). Eine ausführlichere Beschreibung des Tools erfolgt in der Eigenschaft FullName, die ein IName-Objekt zurückgibt, das u.a. auch eine ausführliche Text-Beschreibung des Tools enthalten kann:
public ESRI.ArcGIS.esriSystem.IName FullName {
    get {
     IGPName gpName = new GPFunctionNameClass() as IGPName;
     gpName.Category = "";
     gpName.Description = "Ausführliche Textbeschreibung des Tools";
     gpName.Name = "Tool-Name";
     gpName.DisplayName = "Tool-DisplayName";
     gpName.Factory = (IGPFunctionFactory) new ToolFunctionFactory();
     return gpName as IName;
    }
}
Es wird ausserdem auch mit der Untereigenschaft Factory die Beziehung zwischen GP-Tool und der dazugehörigen GPFunctionFactory hergestellt. Die Untereigenschaft Category dient dazu, innerhalb der logischen Tools-Gruppe weitere Untergruppierungen vorzunehmen.

Die Eigenschaft DialogCLSID wird nur benötigt, wenn dem Tool eine eigene GUI verpasst werden soll, die nicht der Standard Geoprocessing-GUI von ArcGIS entspricht. Dies ist wahrscheinlich nur sehr selten notwendig, so dass hier meistens NULL zurückgegeben werden kann.

Die Methode GetRenderer soll für einen der Tool-Parameter einen Renderer zurückgeben. Hier bin ich ehrlich gesagt nicht ganz schlau geworden, was diese Methode bringen soll und habe sie ebenfalls auf NULL gesetzt, ohne dass Komplikationen aufgetreten sind.

Mit den Eigenschaften HelpFile, HelpContext und MetadataFile kann dem Tool-Benutzer zusätzliche Hilfestellung gegeben werden. Ich habe mich damit begnügt, die Tools bzw. die benötigten Parameter in der Eigenschaft ParameterInfo ausführlich zu beschreiben. Der Benutzer kann die Tools auch anhand dieser Beschreibungen benutzen, ohne dass ich noch irgendwelche Helpfile schreiben muss. Wenn aber Helpfiles gewünscht werden, dann ist hier der richtige Ort.

Die IsLicensed-Methode prüft, ob dem Tool das richtige Lizenz-Level zur Verfügung steht. Ist dies nicht der Fall, wird das Tool gar nicht erst ausgeführt. In diesem Beispiel wird geprüft, ob eine ArcInfo-Lizenz vorhanden ist:
public bool IsLicensed()
{
	IESRILicenseInfo licInfo = new ESRILicenseInfoClass();
	return licInfo.IsLicensed(esriProductCode.esriProductCodeProfessional);
}

Ü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)
Ähnliche Beiträge:
Eigene Geoprocessing-Tools mit ArcObjects Teil 7: Fazit
Eigene Geoprocessing-Tools mit ArcObjects Teil 6: IGPFunction.Execute
Eigene Geoprocessing-Tools mit ArcObjects Teil 5: IGPFunction.Validate
Eigene Geoprocessing-Tools mit ArcObjects Teil 4: IGPFunction.ParameterInfo
Eigene Geoprocessing-Tools mit ArcObjects Teil 2: IGPFunctionFactory
Comments (0)  Permalink
Next1-10/54