Archive for the ‘Datenbanken’ Category

OpenStreetMap und GE Smallworld GIS

Juli 4, 2012

Anwendertage sind eine großartige Gelegenheit, sich mit anderen Anwendern auf einem gleichen Level zu unterhalten, Ideen auszutauschen und einfach mal zu hören, was Andere z. B. mit dem GIS anstellen, das man selbst einsetzt. Am 03. und 04. Juli 2012 hat die GIS Consult GmbH (GC) aus Haltern am See rund 80 Anwender zu einem solchen Treffen ins Hotel Seehof in Haltern am See eingeladen. Aus organisatorischen Gründen konnte ich nur am ersten Tag an der Veranstaltung teilnehmen.

(more…)

Advertisements

OSM im Unternehmen

März 4, 2012

Dieses White Paper ist eine Art Diskussionspapier und ein wenig eine Fallstudie, in wieweit die OSM-Daten überhaupt und zu welchem Zweck eingesetzt werden könnten. Ich erhebe hier keinen Anspruch auf Vollständigkeit oder Richtigkeit. Im Wesentlichen gebe ich hier meine Beobachtungen und meine Meinung wieder. (more…)

Wo?-Kongress 2011 GeoMobility

Dezember 8, 2011

Am 07. und 08.12.2011 fand in Gelsenkirchen der 2. Wo?-Kongress statt. Schwerpunktthema der Veranstaltung war GeoMobility. Etwa 130 Referenten und Teilnehmer haben hier Fachvorträge gehalten, welche in die Kategorien Best Practice und Future unterteilt waren. Eine interessante Entwicklung zum letzjährigen Kongress ist in der stärker werdenden Präsenz der OpenStreetMap Daten zu erkennen. (more…)

OSM-Daten in PostGIS und QGIS – Nachtrag

Juli 16, 2010

Im ersten Artikel OSM-Daten in PostGIS und QGIS habe ich beschrieben, wie man OSM-Daten via osm2pgsql in eine PostGIS-Datenbank importiert und mit QGIS darstellen kann. Dabei habe ich darauf hingewiesen, dass der Import in Postgis auch mit OSMOSIS geschehen kann. Leider habe ich das zu diesem Zeitpunkt noch nicht genauer beschreiben können. Mittlerweile habe ich das aber ausprobiert und bin recht schnell auf die Unterschiede aufmerksam geworden. (more…)

GIS im Alltag

Juni 13, 2010

Wenn man einmal überlegt, an welchen Stellen man in Unternehmen GIS findet, fallen den Lesern, die mit GIS zu tun haben, sicher eine Menge ein. Ist ein GIS einmal in die IT-Landschaft integriert, kann dieses seine Informationen in viele andere Applikationen, angefangen bei Tabellenkalkulationen oder externe Datenbanksysteme weitergeben.

Aber wie sieht es denn im Alltag aus? (more…)

OSM-Daten in PostGIS und QGIS

Juni 8, 2010

Ich hatte schon länger die Idee, die mittlerweile recht gut erfassten Daten aus OpenStreetMap (OSM) in eine Datenbank laufen zu lassen und dann gezielt Objekte zu ermitteln. Diese könnte ich dann z. B. in eine Tabelle füllen und zu Vetriebszwecke in unserem Unternehmen nutzen. (more…)

QGIS (III)

April 14, 2010

Ich habe heute festgestellt, dass ich hier in meinem Blog tatsächlich eine ganze Reihe Versionsnummern unterschlagen habe. Seit meinem letzten Bericht über QGIS ist die Software mittlerweile bei Version 1.4.0 (war  0.8.1) angekommen. (more…)

Funktionen rein oder raus?

Dezember 15, 2008

Letzte Woche war Upgrade-Tag (12.12.2008)! Das Unternehmen, für das ich arbeite, hat nach reiflicher Planung das Upgrade auf Version 4.1 des Smallworld GIS ins Auge genommen und eine Teststellung zum Jahresende (2008) installiert bekommen. Als GIS Sytstemadministrator bedeutet das auch, neben den notwendigen Vorbereitungen, dass für den Installationstermin und eine anschließende Testphase genug Zeit eingeplant wird. Diesmal war alles ein wenig anders. (more…)

PostGIS (I) – Zentraler Datenspeicher

Juli 28, 2006

Da ich von „meinem“ GIS auf der Arbeit weiß, dass man sich mit dem reinen Anzeigen von Objekten nicht begnügen wird, wollen wir das Ganze doch von vornherein sauber aufsetzen. Wenn Daten im Netz verfügbar sein sollen, warum denn dann nicht alle Daten zu den Objekten und wirklich zentral. PostGIS ist eine freie Erweiterung von PostgreSQL um geografische Objekttypen und Funktionen. PostgreSQL ist genauso frei und kostenlos wie PostGIS. Dabei ist PostgreSQL ein sehr mächtiges Datenbanksystem, was mit den meisten großen kommerziellen Produkten mithalten kann. Soll heißen, man kann PostgreSQL auch als Datenspeicher für alle anderen Tabellen und tabellenartigen Informationen benutzen, auf die verschiedene Leute gleichzeitig zugreifen sollen. Das ist sowieso immer eine gute Idee. :-)

Der PostgreSQL-Server kann hierzu auf einem Linux- oder Windows-Server installiert werden. Ich bevorzuge Linux, da man dann mit Sicherheit einen älteren, möglicherweise ausgemusterten, Server wieder reaktivieren kann. Selbst für eine gute Performance der Datenbank ist hier kein DualCore Pentium „irgendwas“ nötig. Eine Maschine mit RAM ab 1GB und einem Pentium mit etwa 1GHz tut hier gute Dienste. Die Festplatte kann man dann entsprechend dem geschätzen Datenvolumen, zzgl. einem gewissen Spielraum, ausrichten.

Und dann geht’s endlich los. Zunächst besorgt man sich den aktuellen Quellcode von PostgreSQL von der Homepage. Je nach Betriebssystem sollte man den beiliegenden Installationsanweisungen folgen. Den Quellcode braucht man, um später PostGIS installieren zu können. Also bitte keine fertigen Packete ohne Quellcodes nehmen! Wenn alle Voraussetzungen erfüllt sind, sollte das Compilieren und Installieren von PostgreSQL problemlos funktionieren. Anschließend nimmt man sich PostGIS vor und verfährt ebenfalls wieder, wie in der Installationsanleitung beschrieben. Ich hatte anschließend nur das Problem, das ein bestimmtes Shared-Object (‚irgendwas‘.so) nicht gefunden wurde. Ich habe das dann manuelle in das Lib-Verzeichnis des PostgreSQL-Quellcodes kopiert, und siehe da… Wenn PostGIS erzeugt ist, werden die SQL-Dateien für die eigentliche Erweiterung von PostgreSQL erzeugt, die man dann nach Anleitung in seiner Geodatenbank (vorher erzeugte Datenbank in PostgreSQL) ausführt. Jetzt steht der Arbeit mit der geospatial Extension (geografische Erweiterung) von PostgreSQL nichts mehr im Wege.

Nach diesen Schritten habe ich noch schnell den Test in den FAQs von PostGIS durchgeführt und war begeistert, wie einfach man jetzt auf seine Geodaten zugreifen kann. Als „Aushilfsprogrammierer“ fallen mir sofort eine Menge von SQL-Abfragen ein, die ich demnächst mal mit meinen Demodaten ausführen werde.

Noch eine Empfehlung: damit man auch von Windows aus, bequem auf der PostgreSQL-Server zugreifen kann, sollte man die Admin-Tool PgAdmin III installieren. Und für alle, die sich nicht von MS Access trennen wollen oder können, muss auf diesen PCs der ODBC-Treiber installiert sein, der solcher Software eine Verbindung zu PostgreSQL ermöglicht.

Und jetzt sollt man erste Schritte mit der Anbindung dieser Geometrie-Tabellen an QGIS unternehmen.

ca. 4:30 min / 3,2 Mb

Freie GIS Software oder Der Wert eines GIS

Juli 26, 2006

Neben den kommerziellen Produkten sind in den letzten Jahren auch freie GIS Systeme entwickelt worden. Diese stehen im allgemeinen als Open Source zur Verfügung. Manch einer mag jetzt schon denken: „Ach, lieber nicht!“.

Das aber ein System wie GRASS vom amerikanischen Militär entwickelt wurde, spielt hier eine wichtige Rolle. Man merkt GRASS zwar an, dass es nicht auf eine schöne Oberfläche abzielt, dafür ist die Funktionalität in der Auswertung rasterhafter Daten nahezu unschlagbar. GRASS wird erfolgreich für die Simulation von Hochwasser und Waldbränden eingesetzt. Schon der Beispieldatensatz (Spearfish) bringt dem testenden Anwender einen guten Einblick, was sich mit dem System alles anfangen lässt.

Für meine Zwecke besser geeignet sind die Systeme Jump/OpenJump und Quantum GIS, da sie Vektororientiert sind. Die Sachdaten einzelner oder einer Menge von Objekten werden tabellarisch angezeit. Jump/OpenJump hat eine Java-basierte Oberfläche, welche entweder mit einem eigenen Format für die einzelnen Layer arbeitet, oder aber bequem ESRI Shape-Files– um ein gängiges Format zu nennen– lesen kann. Quantum GIS hat eine Qt-basierte Oberfläche und besitzt ansonsten sehr ähnliche Funktionen wie Jump/OpenJump. Beide Systeme lassen sich auf den meisten gängigen Betriebssystemen installieren. Ebenso können von beiden Systemen (das gilt auch für das o. g. GRASS) PostGIS-Datensätze gelesen und angezeigt werden. Auf die Objektdaten kann dann in der Anwendung zugegriffen werden. Die Verbindung wird aus dem jeweiligen System heraus hergestellt. Die entsprechenden Layer werden wie jeder andere Layer in der Oberfläche/Workbench angezeigt. Die Datensätze können bei der Verknüpfung mit dem System mit einer Beschränkung auf SQL-Basis versehen werden, um aus einer großen Menge von Datensätzen gezielt solche herauszufiltern, die einem bestimmten Kriterium entsprechen.

Ich werde später noch auf jedes einzelne System eingehen. Die Anbindung an eine externe und freie Datenbank bietet dem Anwender eine große Flexibilität. Dieser Punkt trifft sehr wohl auch auf die kommerziellen Produkte zu, die Schnittstellen zu verschiedenen Datenbanksystemen bieten. Der Anwender kann auf einen zentral verwalteten und ebenso zentral gepflegten Datenbestand zugreifen. Hierzu muss er nicht zwangsläufig ein GIS bemühen, um an die Daten zu kommen. Rein alphanumerische Ergebnisse können erfahrungsgemäß durch geeignete Auswertetools schneller und komfortabler erzeugt werden. Aus der Postgres-Erweiterung PostGIS lassen sich sogar unmittelbar geometrisch Abfragen starten. Die Besonderheit eines GIS ist aber die Visualisierung der Daten und das Erkennen und Auswerten von räumlichen Zusammenhängen. Dies ist in rein sachdatenorientierten Systemen nicht oder nicht ohne weiteres möglich. Diese Systeme sind sicher sehr gut geeignet, um Sachdaten zu verwalten und unternehmerische Vorgänge abzubilden. Immer dann, wenn georeferenzierte Daten (d. h. beispielsweise mit Bezug zu einer Adresse oder Koordinate) ins Spiel kommen, kann man den vollen Wert dieser Daten nur ausschöpfen, wenn man räumlichen Zusammenhänge erkennen und auswerten kann.

Ich bin derzeit in der Wohnungswirtschaft beschäftigt und bin dort verantwortlich für das GIS. Neben dem SAP-System, was sicher sehr gut für alle wohnungswirtschaftlichen Belange auf Basis der Mieter- oder Gebäudedaten geeignet ist (z. B. Vermietung), ist der Nutzen eines GIS sehr groß. Da schätzungsweise 95% der Informationen in dieser Branche einen räumlichen Bezug haben, können diese Informationen in einem GIS auf geeignete Weise dargestellt werden. Angefangen bei den Flurstücken, Gebäuden und Katasterkarten als Basisdaten, können alle Informationen zu Verträgen, Belastungen und Besonderheiten (Denkmalschutz, Immisionsschadensverzichtsbereiche) nicht nur mit ihren Sachdaten, sondern auch lagerichtig abgebildet werden. Hier kann der Anwender auf einen Blick sehen, was bei dem Objekt ggfs. zu beachten ist. Ein großes Thema, welches in den letzten Jahren unheimlich an Gewicht gewonnen hat, ist die Abrechnung von Grünflächenpflege in den Nebenkosten. Damit sind alle pflegerischen Maßnahmen gemeint, die an den Aussenanlagen eines Gebäudes vorgenommen werden und i. d. R. durch einen Unternehmer ausgeführt werden: Rasenschnitt, Heckenschnitt, Baumschnitt; aber auch Reinigungsdienst und Winter-/Streudienst.

Alle diese Informationen sind – sobald sie erfasst sind – im System abrufbar und können angezeigt und ausgewertet werden. In der Nebenkostenabrechnung konnte jahrelang der Mengenansatz der Unternehmer, z. B. beim Rasenschnitt, nicht wirklich kontrolliert werden. Eine im GIS erfasste Rasenfläche kennt ihre Grösse auf den Quadratmeter genau. Diese Grösse lässt sich intern oder in einer externen Anwendung weiterverarbeiten, so dass für ein gesamtes Pflegequatier oder aber für einen einzelnen Mieter genauestens ermittelt werden kann, wie groß diese Fläche ist. Damit ist die Abrechnung gezielter und für den Mieter gerechter durchführbar. Die Ermittlung einer Flächensumme oder einer Teilfläche kann durch geeignete Abfragen durchgeführt werden und gibt dem Anwender mit hoher Genauigkeit die Zahlen und Werte, die er erwartet.

Durch die Anbindung z. B. von Postgres als externe Datenbank kann der Anwender seine Informationen im GIS ermitteln und ggfs. mit weiteren Non-GIS-Daten (z. B. wohnungswirtschaftliche Sachdaten) aus der Datenbank erweitern. Hierdurch wird es überhaupt erst möglich, für räumlich zusammenhängende Objekte qualifizierte Aussagen zu treffen. Solange wir uns z. B. innerhalb einer Straße bewegen, sollte dies für eine „normale“ Datenbank auch möglich sein. Das GIS bietet aber die Flexibilität Auswertungen für einen Bereich durchzuführen, der nicht durch geeignete alphanumerische Kriterien klassifiziert ist. Wirtschaftseinheiten, Quartiere, Siedlungen oder ähnliche raumbezogene Merkmale lassen sich alphanumerisch an die Objekte hängen. Diese können aber nur anhand einer Karte identifiziert werden und sobald man einen übergreifenden Bereich oder eine örtlich definierte Teilmenge benötigt unzulänglich sein.

Ich werde meine Ausführung zunächst hier abbrechen und zu einem anderen Zeitpunkt einzelne von den o. g. Aspekten im Detail und mit Beispielen weiterführen.

ca. 7:40 min / 5,3 Mb