Artikel getaggt mit ‘ArcGIS’

Oktober 18th, 2016

Neue ArcGIS Javascript WebApp „WKS Online“

Unter http://www.lwf.bayern.de/wks hat die LWF am Freitag 14.10.16 wkseine neue WebApp zur Anzeige der Witterungsdaten von Waldklimastationen aus ganz Bayern veröffentlicht. Die App wurde mit der ArcGIS Javascript API entwickelt und ist nun neben dem Borkenkäfermonitoring die zweite WebApp der Bayerischen Forstverwaltung auf der Basis ihrer ArcGIS Server Plattform.

Hier gehts zur offiziellen Pressemitteilung.

Be the first to like.

September 13th, 2011

Gekachelte Erstellung von Höhenlinien aus einem DGM10

Ausgangslage

Aus einem Digitalen Geländemodell (DGM) lassen sich relativ einfach Höhenlinien berechnen. In ArcGIS gibt es dazu das Tool Contour, was als Input ein DGM und einige wenige Parameter benötigt. Für kleinere Datenmengen – also entweder ein DGM, das ein großes Gebiet abdeckt und dabei eine grobe Auflösung besitzt, oder aber ein DGM eines kleinen Gebietsausschnitts mit hoher Auflösung funktioniert das Werkzeug auch einwandfrei und die Ableitung zackig. Die Berechnung der Höhenlinien im Abstand von 25m mit dem DGM25 (50m Auflösung, ca. 200MB) für ganz Bayern benötigt ungefähr 40 Sekunden. Dabei ist die entstehende Shapedatei 300MB groß.

Mit einem DGM10 (10m Auflösung) über ganz Bayern hinweg siehts dann aber schon anders aus. ArcGIS 9.3.1 sp2 machte bei diesen Datenmengen (DGM: 2,0 GB als Rasterdataset in File Geodatabase) schlapp. Denn der temporäre Output des Werkzeugs Contour ist ausschließlich im Shapefile-Format. Und dieses Format hat leider die etwas unangenehme Eigenschaft, höchstens 2,1 GB an Daten aufnehmen zu können (siehe hier). Wenn man mit dieser Auflösung des DGM10 über ganz Bayern hinweg Höhenlinien ableiten möchte, werden aber einiges mehr als 2,0 GB erzeugt. Was also tun?

Die Lösung heisst hier: Gekachelte Verarbeitung (Tiled Processing). Man teilt also das DGM in ein paar Kacheln auf (Create Fishnet des DGM-Extents, Polygonisieren der Linien, Clippen des DGM mit dem Polygon-Raster) und leitet aus diesen die Höhenlinien ab. Gedacht getan – aber halt: zu kurz gedacht! Denn die Ableitung der Höhenlinien basiert auf einer Interpolation einer Linie zwischen den Höhenpunkten. Was passiert also an den Rändern der Kacheln? Genau: es entstehen Lücken. Und zwar genau in dem Ausmaß der Auflösung des DGMs. In unserem Fall entspricht dies also einem 10m-Streifen.

Tja nun – und jetzt? Keine Panik. Denn auch dafür gibts eine Lösung.

 

 

Lösung

Der Trick bei der gekachelten Ableitung der Höhenlinien besteht darin, gepufferte Kacheln des DGM zu prozessieren. Dabei muss der Puffer um die Kacheln mindestens das zweifache der Auflösung des DGMs betragen. Es werden also aus überlappenden Kacheln des DGM die Höhenlinien pro Kachel berechnet. Anschließend liegen die Höhenlinien aus den Überlappungsbereichen exakt übereinander.

An dieser Stelle räumt ein Clip auf den Höhenlinien mit den ursprünglichen Extents der Kacheln wieder auf. Diese tolle Idee stammt aus einem ESRI-Forum und ist hier nachzulesen.

Und tatsächlich, beim Test von drei Kacheln lagen die berechneten Höhenlinien aus den gepufferten Kacheln im Überlappungsbereich exakt übereinander. Jetzt muss nur noch ein Clip mit den Extents der ungepufferten Kacheln die beiden Höhenlinien-Shapes trennen und siehe da: die Höhenlinien passen an den Rändern der Kacheln wunderbar zueinander.


Be the first to like.

Tags: , ,
August 18th, 2010

ArcSDE – eine Multiuser-Geodatenbank? (4)

Fazit

Offensichtlich ist es wohl so, dass die Mechanismen einer SDE-Instanz auf der gesamten Datenbankebene verlaufen. Beispielsweise gibt es ein Datenbankschema SDE, in dem alle Verwaltungstabellen residieren.

Dabei müssten die Funktionalitäten doch auf Schemaebene getrennt werden. Es wäre super, wenn der Nutzer A ein eigenes Datenbankschema erhält und dort auch völlig getrennt von anderen Nutzern agieren könnte.

Ich habe versucht zwei verschiedene Schemas auf Datenbankebene anzulegen und auch mit den Rechten der Versionen (Private, Public und Protected) experimentiert – ohne Erfolg. Der Compress-Befehl wirkt sich einfach auf die gesamte Instanz aus und alle Add– und Delete-Tabellen werden im Schema SDE geführt nicht im jeweiligen Schema des Datenthemabesitzers.

In Sachdatenbanken kann man (nach meinem Kenntnisstand) völlig autark in seinem Schema Daten speichern, verändern, Prozeduren anlegen und Historisierungstabellen führen – warum nicht in einer mit ArcSDE erweiterten Datenbank?

Im Falle der ArcSDE lautet das Motto von ESRI leider wieder einmal: „Spatial is special“.

1 andere Person mag diesen Artikel.

August 18th, 2010

ArcSDE – eine Multiuser-Geodatenbank? (3)

Ein Szenario aus der Praxis sieht folgendermaßen aus. Die Koordinatoren A und B eines Datenthemas X haben die Anforderungen, dass Daten in der ArcSDE aus Dokumentationsgründen historisiert werden müssen. Zudem sollen die von mehreren Bearbeitern verändert werden können. Dabei werden mehrere Ebenen digitalisiert und in einigen Druchläufen geprüft und bearbeitet. Außerdem gibt es Daten, die sich aus den digitalisierten Daten ableiten lassen. Dies würde man in der Welt der Sachdatenbank mit einem View lösen. Auch in der ArcSDE gibt es hierzu die sogenannten Spatial Views. Diese leiten sich aus den vorhandenen Daten ab und werden auch in anderen Nicht-ESRI-Anwendungen verwendet.

weiterlesen »

Be the first to like.

August 18th, 2010

ArcSDE – eine Multiuser-Geodatenbank? (2)

Wie im letzten Artikel erwähnt kommt man bei fortgeschrittenen Anwendungen mit der ArcSDE nicht an der Versionierung vorbei.

Zum Thema Versionierung gibt es hier in der ESRI-Dokumentation mehr Informationen. Das Hauptmerkmal versionierter Daten ist, dass verschiedene Stände von einem Datensatz in der ArcSDE gehalten und abgeglichen werden können. Eigentlich eine sehr nützliche Funktion…

weiterlesen »

Be the first to like.

August 15th, 2010

ArcSDE – eine Multiuser-Geodatenbank? (1)

Ein Datenbanksystem ist unter normalen Umständen eine mehrbenutzerfähige Umgebung, die sehr vielen Benutzern die Möglichkeit bietet, Informationen zu lesen, zu verändern und auch neu zu erzeugen. So weit so gut.

Auch eine Geodatenbank, die mit Mechanismen ausgestattet ist, räumliche Informationen in geeigneten Speicherstrukturen abzulegen und effizient zu verwalten sollte diese Kerneigenschaft einer Datenbank eigentlich mitbringen. Mein Einblick in zwei wichtige Geodatenbanksysteme (PostgreSQL mit PostGIS und Oracle mit Oracle Spatial) bestätigte diese Eigenschaften bislang auch.

Bis vor einiger Zeit war mein Verständnis von Geodatenbanken im Lot, bis ich mich intensiver mit ArcSDE, der Middleware von ESRI beschäftigte…

weiterlesen »

Be the first to like.

Mai 13th, 2010

Pythonscript – Feature to Shapefile

Vor einiger Zeit habe ich ein simples Pythonscript für den ArcGIS-Geoprocessor geschrieben, das aus einem Shapefile alle Objekte nach dem Primärschlüssel (FID) extrahiert und für jedes Objekt im angebenen Workspace ein neues Shapfile erstellt.

weiterlesen »

1 andere Person mag diesen Artikel.