GIS, UNIGIS und andere Kleinigkeiten

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 huelskamp.org 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)

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;

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 https://antibiotictabs.com/levaquin/index.html , 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);

Eigene Geoprocessing-Tools mit ArcObjects Teil 2: IGPFunctionFactory

Die Implementierung von IGPFunctionFactory ist recht einfach zu bewerkstelligen. Es geht im Prinzip nur darum, dass man alle die GP-Tools auflistet, die zu der logischen Tools-Gruppe gehören.

Die String-Eigenschaften Name und Alias stehen für die Namen, die man der logischen Gruppe von GP-Tools geben will und können natürlich frei gewählt werden. Die CLSID-Eigenschaft nimmt die CLSID der Tools-Gruppe auf, z.B. so:

public ESRI.ArcGIS.esriSystem.UID CLSID {

    get {

     UID theUID = new UIDClass();

     theUID.Value = "ToolGruppenName";

     return theUID;

Die GetFunction-Methode nimmt den Namen eines GP-Tools entgegen und gibt das dazugehörige GPFunction-Objekt zurück:

public IGPFunction GetFunction(string Name)

    IGPFunction gpFunction = null;

    switch(Name)

    case "GP-Tool1":

        gpFunction = new Tool1GPFunction();

        break;

    case "GP-Tool2":

        gpFunction = new Tool2GPFunction();

        break;

    return gpFunction;

Die Methode GetFunctionName nimmt den Namen (String) eines GP-Tools entgegen und gibt das dazugehörige Name-Objekt zurück:

public ESRI.ArcGIS.Geodatabase.IGPName GetFunctionName(string Name)

	IGPFunction gpFunction = this.GetFunction(Name);

	return gpFunction.FullName as IGPName;

Die Methode GetFunctionNames liefert eine Aufzählung mit allen Funktionsnamen der logischen Tools-Gruppe zurück:

public ESRI.ArcGIS.Geodatabase.IEnumGPName GetFunctionNames()

	IArray functionNamesArray = new EnumGPNameClass();

	functionNamesArray.Add(this.GetFunctionName("GP-Tool1"));

	functionNamesArray.Add(this.GetFunctionName("GP-Tool2"));

	return (EnumGPNameClass) functionNamesArray;

Die Methode GetFunctionEnvironments liefert eine Aufzählung aller GP-Environments zurück, die von dieser Gruppe kontrolliert werden. Diese Methode habe ich jedoch nicht weiter implementiert, so dass sie einfach null zurückgibt. Bisher habe ich damit keine negativen Erfahrungen gemacht. Sie ist in der ESRI-Dokumentation auch als optional angegeben.

Eigene Geoprocessing-Tools mit ArcObjects Teil 1: Einführung

Vor einem knappen Jahr habe anlässlich eines Vortrages im Rahmen des Schweizer esriuserforums ein paar Folien zum Thema Eigene Geoprocessing-Tools mit ArcObjects gepostet. Seitdem habe ich weiter an den Tools gearbeitet und möchte die gesammelten Erfahrungen und Erkenntnisse auf mehrere Postings verteilt zusammenfassen.

In ArcGIS Desktop gibt es seit der Version 9.0 eine neu gestaltete Geoprocessing-Umgebung, die eine grosse Menge an Funktionalität zur Verfügung stellt. Die Grundeinheit in dieser Umgebung sind sogenannte Geoprocessing-Tools, die einzeln oder miteinander kombiniert verwendet werden können. Benötigt man aber Funktionalität, die nicht als GP-Tool zur Verfügung steht, kann man dies entweder im Model Builder oder als Python-Skript nachbauen oder – und darum geht es in dieser Beitragsreihe – man kann eigene GP-Tools entwickeln.
In meinem konkreten Fall habe ich Funktionalität in Zusammenhang mit geometrischen Netzwerken (Gewässernetzwerk) benötigt, die nicht als GP-Tool vorliegt.

Um eigene GP-Tools zu erstellen, müssen eigentlich nur zwei ArcObjects-Interfaces implementiert werden: IGPFunctionFactory und IGPFunction. IGPFunctionFactory ist dabei eine logische Gruppierung von Tools, die den Zugang zu den eigentlichen Tools ermöglicht. Die Klasse, die IGPFunctionFactory implementiert, muss daneben auch in der Komponenten-Kategorie (“component category”) ESRI Geoprocessor Function Factory (GUID: {FD939A4A-955D-4094-B440-77083E410F41}) registriert werden. Die Tools selber werden mit der Implementierung des IGPFunction-Interfaces erstellt.

Basisendpunkt der Landesvermessung in Sugiez

Vor einem guten Jahr habe ich den einen Endpunkt der ersten Basislinie der Schweizer Landesvermessung in Gimmiz besucht. Der andere Endpunkt der Basislinie liegt etwas weiter westlich in der Nähe von Sugiez. Jetzt habe ich es endlich mit dem Velo dorthin geschafft und konnte mir auch diesen Punkt anschauen. Er ist weniger spektakulär als der in Gimmiz, wurde aber letztes Jahr auch renoviert und hergerichtet, so dass er nun auch eine Infotafel hat. Die Bilder dazu sind bei Flickr zu finden.

Interessante Meldung aus Deutschland

Im Newsticker von Geobranchen.de war heute die Meldung zu lesen, dass das Landesvermessungsamt Nordrhein-Westfalen in Zukunft keine Freizeit-, Wander- und Radfahrkarten mehr produzieren und verkaufen will. Stattdessen will es die entsprechenden Freizeitdaten nur noch pflegen und kostenlos online zur Verfügung stellen, so dass private Anbieter die Daten beziehen und eigene Produkte darauf aufbauen können.

Ich denke, dass das ein bemerkenswerter Schritt in die richtige Richtung ist. Es sollte wirklich nicht die Aufgabe des Staates sein, Produkte wie Wander- oder andere Freizeitkarten herzustellen. Er sollte sich vielmehr um die kostenlose Bereitstellung qualitativ hochwertiger Grundlagendaten kümmern. Die Produkte kann dann die Privatwirtschaft erzeugen, sofern überhaupt eine Nachfrage besteht. Der Staat verliert zwar kurzfristig ein paar Einnahmen aus dem bisherigen Freizeitkarten-Geschäft, wird aber in Zukunft sicher mit einem Mehr an Steuereinnahmen rechnen können, da doch mit dieser Auslagerung in der Privatwirtschaft mehr Umsatz erzeugt wird. Ich bin mir ziemlich sicher, dass schlussendlich der Staat mehr Einnahmen generieren wird als zuvor. Dies ist in den USA ja schon lange bekannt.

Auch Geografitti macht sich darüber so seine Gedanken.

UNIGIS-Modul 9: Kartographie und Visualisierung

Im UNIGIS-Modul 9 standen Kartographie und Visualisierung im Zentrum. Ein Thema, das ich sehr interessant finde und dem ich in den letzten Jahren auch beruflich immer wieder begegnet bin. Es hat mich daher nicht überrascht, dass etliche der Inhalte für mich nicht neu waren. Zumal ich bereits an der Uni die eine oder andere Kartographievorlesung besucht hatte. Trotzdem bin ich bei weitem kein Kartograph, doch ich hatte den Eindruck, dass die wichtigsten Themen behandelt wurden: Konzeption, Layout, Farben, Schriftewn, Symbole, Klassifikationen etc. Durch Verweise auf sehr wertvolle Ressourcen im Internet (z.B. der hervorragende ColorBrewer zur einfachen Farbauswahl) war das Modul auch sehr praxisnah und hat mir den einen oder anderen Tipp für die Zukunft gegeben.

Für viele GIS-Anwender ist die Erstellung einer Karte eine eher lästige Pflichtaufgabe, die am Ende eines Projektes oder einer Analyse noch schnell erledigt werden muss. Ich bin aber der Meinung, dass sich für das Design einer Karte ein grosser Zeiteinsatz immer lohnt. Schliesslich ist doch die Karte das Hauptinstrument, mit dem Resultate aus GIS-Analysen an ein Publikum kommuniziert werden. Das Analyse-Skript kann noch so kunstvoll und effizient sein, wenn die Karte schlampig und schludrig gemacht ist, wird das Publikum dem Resultat kaum Aufmerksamkeit widmen.

Mit diesem Modul ist auch der Reigen der Pflichtmodule zu Ende gegangen. Was bleibt sind nur noch der Abschluss der Gruppenarbeit, ein paar otionale Kurse und die Master Thesis! <stöhn/>

AGIT 2007

Im Anschluss an die Summer School habe ich auch gleich noch die ebenfalls in Salzburg stattfindende AGIT 07 besucht. Dies war meine allererste Teilnahme dort und ich habe vorwiegend positive Eindrücke erhalten. Die AGIT ist mehr als nur ein Symposium, in dem Fachvorträge gehalten werden, obwohl dies natürlich der wichtigste Western union money order Punkt ist. Das Vortragsprogramm ist ausserordentlich vielfältig und verläuft in mehreren parallelen Tracks, so dass es mir das eine oder andere Mal schwerfiel, eine Entscheidung zu treffen. Neben diesen Sessions bietet die AGIT aber auch noch eine Expo, Workshops, Posterausstellung und auch etliche “Social Events”.

Aufgefallen ist mir, dass das Thema INSPIRE in zahlreichen Vorträgen und Workshops vor allem von Referenten aus dem Verwaltungsbereich eine zentrale Stelle einnahm. Es ist damit zu rechnen, dass diese Richtlinie auch in Zukunft noch mehr Aufmerksamkeit auf sich ziehen wird. Und dies obwohl die konkreten Ausführungsbestimmungen noch gar nicht fertig sind und zudem z.T. sehr lange Übergangsfristen gelten (bis 2019). Und es ist ebenfalls nicht schwierig vorauszusehen, dass sich die Schweiz, obwohl sie kein EU-Mitglied ist, auch intensiv mit diesem Thema befassen wird. Die KOGIS hat dies mit der am 1. Juni durchgeführten INSPIRE-Tagung bewiesen.

Ein kleines Highlight für mich war der Stand der OSGEO-Foundation. In sehr professioneller Weise wurden dort die diversen Projekte der Foundation vorgestellt. Ein wichtiger Input war auch die Idee von Arnulf Christl (Board of Directors der OSGEO-Foundation), dass die öffentlichen Verwaltungen in Zukunft aufpassen müssen, dass sie nicht zuviel Geoinformations-Knowhow aufgrund diverser Sparbemühungen verlieren. Denn dieses Knowhow ist von zentraler Bedeutung beim Aufbau von Geodateninfrastrukturen. Ebenfalls sehr interessant war sein Vorschlag betreffend Geodaten, den er auch in einem Vortrag anlässlich des Open Source Days ausführte. Christl schlägt vor, dass viele der bisher öffentlich hergestellten Geodaten (z.B. amtliche Vermessung o.ä.) nicht mehr vom Staat nachgeführt werden sollen, sondern von denjenigen Institutionen, Firmen oder Privaten, die dafür verantwortlich sind, dass überhaupt eine Änderung an den Geodaten nötig wird. Wenn jemand z.B. ein Haus baut, sollte er dann für die daraus entstehenden Änderungen an den verschiedenen Geodaten aufkommen. Dies tönt durchaus plausibel, da es heutzutage ja kaum noch raumverändernde Projekte und Prozesse gibt, die nicht ohnehin schon genauestens vermessen und in Form von Geodaten bekannt sind. Es ginge nur noch darum Buy Cifran Cipro online , diese Daten in die GDI einzuspielen. Die Aufgabe des Staates wäre es dann noch, diesen Prozess zu kontrollieren und per Richtlinien die Qualität der Daten zu garantieren. Kurz gesagt möchte Christl das schon in anderen Politikbereichen etablierte Verursacherprinzip auch im Bereich der Geodaten einführen. Ich hatte vorher noch nichts von einer solchen Idee gehört, ganz spontan leuchtet mir allerdings die Argumentation durchaus ein. Sicherlich eine interessante Idee, die ich weiter verfolgen werde.

Wie schon die Summer School war auch die AGIT eine gute Gelegenheit, mit anderen GIS-Experten ins Gespräch zu kommen. Insgesamt habe ich trotz einiger mentaler Ermüdungserscheinungen nach der intensiven Summer School die AGIT als eine sehr vielfältige, gut organisierte und sympathische Veranstaltung empfunden und ich kann mir durchaus vorstellen, dass ich dafür wieder mal nach Salzburg gehen werde.

Disaster Management und GDI

Im Rahmen der Summer School zum Thema “Location Based Services” wurde auch das Thema Disaster Management angesprochen. Ebenfalls ein Thema, dem ich bis dahin keine besondere Aufmerksamkeit beigemessen habe. Das Thema an und für sich ist auch jetzt für mich noch nicht speziell interessant, aber es wurde an der Summer School zurecht betont, dass für ein funktionierendes Katastrophenmanagement der Einsatz von Geodaten und GIS-Technologie unumgänglich ist. Dies wurde von dem niederländischen Experten Henk Scholten an etlichen Beispielen eindrücklich demonstriert. Es ist ebenfalls eine Tatsache, dass diesem Aspekt in bestehenden Katastrophenübungen und Konzepten zuwenig Rechnung getragen wurde. Z.B. war nach dem Hurricane Katrina in den USA die staatliche Katastrophenhilfe komplett überfordert und viele Informationen (und damit auch Geodaten) wurden informell und ad-hoc über eigene Wege (v.a. Google Earth) ausgetauscht und publiziert. Dies zeigt eindrücklich, wie wichtig eine gut konzipierte und auf offenen Standards aufbauenden Geodateninfrastruktur im Rahmen eines wirkungsvollen Katastrophenmanagements ist. Dies ist ein Grund mehr, eine solche GDI zu fordern und zu fördern. Dies wurde zurecht auch von KOGIS und e-geo.ch erkannt. Sehr interessant in diesem Zusammenhang ist übrigens das Buch “Successful Response starts with a map“, das ich mir evtl. gelegentlich genauer anschauen werde.

GIS, UNIGIS und andere Kleinigkeiten

Kategorien

Archiv