Wo?-Kongress 2011 GeoMobility

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.

OpenLayers in Joomla (Einstieg)

Um die Karten von Open Street Map in Joomla zu benutzen — ich meine dynamisch nicht als statisches PNG/JPEG, o. ä. — gibt es sicher eine Menge Wege. Allerdings hat weder das Einfügen des Java Script im Template Header von Joomla, noch die Nutzung eines Plugins (injooosm) zum gewünschten Ergebnis geführt. Injooosm kann einfach zu viel für meine Zwecke, und ich habe es, wegen der schlechten Doku, garnicht zum Laufen bekommen. :(

Was ich wollte

In einem Artikel sollte eine OSM-Karte erscheinen, so wie sie bei OpenStreetMap zu sehen ist. Mit Steuerelementen und Layersteuerung. Zusätzlich sollte ein GPX-Track angezeigt werden und einige Marker mit besonderen Stellen innerhalb des Tracks (POIs). Die Grundlagen und ein ad-hoc funktionierendes Beispiel fand ich auf der Seite von OpenLayers. Die Karte, wollte ich jetzt aber in mein Joomla-CMS bringen und in einem Artikel benutzen. In weiteren Artikeln sollten anderen Karten benutzt werden, die andere GPX-Dateien darstellen.

Ein anderes Plugin für Joomla kann immer nur die gleiche Karte darstellen. Wenn ich auf meiner kompletten Site nur eine Karte benötige (Anfahrtskizze) ist das okay, in meinem Fall aber nicht.

Also habe ich mich nach einer einfacheren Variante umgesehen. Da man in Joomla hier und da mal einen Platzhalter im Editor eingeben muss (z. B. {gallery}), konnte ich gut damit leben, ein wenig Code für einen IFRAME einzugeben. Das ist ein Einzeiler, der niemanden überfordert. Zuvor sollte man sich aber mit dem Beispiel für die OpenLayers-Nutzung vertraut machen. Man benötigt für die Darstellung einer Karte nur das einfache Beispiel mit einem Marker in der Mitte (das könnte dann z. B. der Standort der Firma sein). Hier benötigt man lediglich die Koordinaten des Standortes. Wenn man einen Track darstellen möchte, sollte man das einfache Beispiel, so wie im Track example erweitern.

Mir war es nun zu alle dem aber auch noch wichtig, Waypoints in irgendeiner Form darstellen zu können — natürlich möglichst flexibel. Hierzu erweitert man dann das komplette Grundgerüst so, wie im Beispiel POI Layer Example.

Was ich getan habe

Ich habe also einen Artikel angelegt und wie üblich gestaltet (mit Bild, Text und Gallery). Im Anschluß daran sollte jetzt die Karte erscheinen. Also habe ich zunächst eine funktionierende HTML-Datei aus den OpenLayers-Beispielen zusammengebaut und ein Textfile mit den Waypoints angelegt. Das ganze habe ich per FlashUploader in einem neuen Verzeichnis (z. B. osmdata) unterhalb von images (auf dem Webserver, dort wo Joomla installiert ist!) angelegt. Zudem benötigt man noch die GPX-Datei mit dem Track. Da alle Dateien im gleichen Verzeichis liegen, passt man die Pfade so an, dass alle Links und Referenzen in HTML auf “./<dateiname>“ umgestellt sind. Auch die Icons/Symbole, die in der Textdatei mit den Waypoints (POI) stehen, sind in das osmdata-Verzeichnis hochzuladen. Fügt man jetzt den IFRAME ein, wird die Karte wie gewünscht dargestellt. Ich habe den Rahmen des IFRAME ausgeschaltet und keine Scrollbars zugelassen.

Beipieldateien

Werde ich nachreichen, wenn ich meine “produktive“ Vorlage in ein anonymisiertes Beispiel geändert habe … :)

Fazit

Ich nutze in Joomla viele Komponenten, Module und Plugins, die nichts mit Karten, GPS oder GIS zu tun haben. Leider konnte mich keins der getesteten Pakete bzgl. der OSM-Karten wirklich überzeugen. Ich habe allerdings auch nicht die Zeit, das Rad neu zu erfinden. Meine beschriebene Vorgehensweise umschließt jedoch alle Punkte, die mir wichtig waren:

• Darstellung einer dynamischen OSM-Karte in einem Joomla-Artikel
• Darstellung eines GPX-Tracks innerhalb der Karte
• Darstellung von Waypoints mit Infofenster (description) innerhalb der Karte mit anpassbarem Symbol
• beliebig viele Karten mit unterschiedlichem Inhalt (Ausschnitt, GPX-File usw.) in einem oder unterschiedlichen Artikeln

Die OpenLayers-Struktur umfasst noch eine Reihe mehr Möglichkeiten, die ich momentan noch garnicht nutzen (z. B. POIs aus einer Datenbank). Da ich aber hierin eine echte Alternative zur GoogleAPI sehe und mich weiter mit den Möglichkeiten auseinandersetzen werde, folgen diesem Einstieg sicher noch weitere Artikel.

PS: Ich bin mir sicher, dass diese Vorgehensweise das eine oder andere Problem in Joomla lösen kann, mit dem man sich ansonsten Wochenlang herumschlägt — soll heißen, der IFRAME kann auch andere Inhalte einfach einbinden, die nicht über die Multimedia-Erweiterungen abgedeckt sind und auf mehr oder weniger einfachem HTML basieren. :)

OSM-Daten in PostGIS und QGIS – Nachtrag

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.

Was sind die Gemeinsamkeiten?

Grundsätzlich erledigen osm2pgsql und osmosis die gleichen Arbeit: importieren von OSM-Daten (in Form einer osm-Datei aus der XAPI 0.6). Damit ist es aber auch schon vorbei mit den Gemeinsamkeiten.

Was sind die Unterschiede?

OSM2PGSQL erstellt vier Tabellen, in denen Linien, Punkte, Polygone und Straßen getrennt enthalten sind. Die Tabellen sind 54 bzw. 55 Spalten breit!! Die meisten Attribute (keys bzw. tags) sind in jeder Tabelle enthalten, ganz gleich, ob diese benutzt werden oder nicht. Die Tabellen können direkt an QGIS angebunden werden und damit auch dargestellt werden. Abfragen nach Straßennamen und anderen Attributen sind möglich. So weit, so gut.

OSMOSIS erzeugt stolze 10 Tabellen, was auf den ersten Blick auf eine stärkere Normalisierung der Daten hinweist. In der Tat werden z. B. die Attribute (keys bzw. tags) von den eigentlichen Geometrien mit den — nennen wir sie mal — administrativen Daten (z. B. Version, User-ID, Timestamp, Changeset) getrennt und per OSM-Objekt-ID miteinander verknüpft. Vorteil ist, die Tabellen sind übersichtlicher. Nachteil ist, man muss die Tabellen per JOIN verknüpfen, um z. B. den Namen zu einer Straße zu bekommen. Mit ein bisschen SQL ist das aber z. B. im PGAdminIII kein Problem.

Erstes Fazit

Was ich bei der OSM2PGSQL-Version besser finde, ist die oberflächliche Art mit den Daten umzugehen. Man sucht allerdings vergeblich nach einem Timestamp oder dem User, der die Daten ursprünglich erzeugt hat. Wer mit anonymisierten Daten ohne Zeitbezug hinkommt, ist mit dieser Version bestens bedient. Bei OSMOSIS habe ich die komplette Struktur der Daten verfügbar. Durch leichte Modifikationen an den Tabellen (Details dazu in einem anderen Artikel) kann ich eine Historie aufbauen und mir den Stand der Erfassung zu bestimmten Stichtagen (sagen wir z. B. innerhalb eines bestimmten Jahres) ansehen. Das ist z. B. der Grund, warum ich wohl eher zu OSMOSIS greifen werde. Einen Haken hat das Ganze aber doch: ich kann die OSMOSIS-Daten nicht direkt an QGIS anhängen! Wo ein Wille ist, ist aber auch ein Weg. Das Problem liegt im Primärschlüssel, der in PostGIS angelegt wird. OSMOSIS erzeugt für die Geometrietabellen eine ID als BIGINT — QGIS erlaubt derzeit aber nur INTEGER als Primärschlüssel (Hinweis: OSMOSIS erzeugt auch keine OIDs!). Momentan kommt man aber noch mit Integerwerten für die IDs aus, weshalb man einfach die Tabellenstruktur ändern kann und das Feld ID in den Tabellen ways und nodes von BIGINT in INTEGER ändert — das wars (siehe weiter unten)!

Da ich die ganze Prozedur für OSM2PGSQL schonmal beschrieben habe (siehe hier) setze ich jetzt die Installation von Postgresql, PostGIS und QGIS einfach voraus. Wir steigen dort ein, wo wir die OSM-Daten in einem Verzeichnis per wget abgelegt haben (nach dem Absatz “Her mit den OSM-Daten …“). OSM2PGSQL muss für dieses Beispiel nicht installiert sein, kann es aber.

Zuerst muss OSMOSIS installiert werden. Dazu laden Sie sich bitte die letzte Version in ein Verzeichnis Ihrer Wahl (Download OSMOSIS) und installieren es nach der Anleitung auf der Downloadseite (Subpage Installation, rechts oben in dem Kasten). In der Verzeichnisstruktur von OSMOSIS gibt es jetzt einen Ordner script, in dem sich ein Skript befindet, mit dem man die grundlegende Datenbankstruktur anlegen kann (pgsql_simple_schema_0.6.sql). Wechseln Sie zunächst in diesen Ordner (das hängt davon ab, wo Sie das OSMOSIS-Archiv entpackt haben).

In der Datenbank muss zunächst das Tabellenschema erzeugt werden. Mit dem folgenden Befehl kann man das Skript zur Erstellung der Datenbankstruktur ausführen: psql -d meingis -f ./pgsql_simple_schema_0.6.sql . Jetzt wechseln Sie bitte in das Verzeichnis mit der OSM-Datei. Alles, was Sie jetzt noch tun müssen ist, die Daten in die Datenbank zu importieren. Dazu benutzen Sie bitte den Befehl: <Pfad zu OSMOSIS>/bin/osmosis –read-xml file=“./data.osm“ –write-pgsql user=“gisadmin“ database=“meingis“ password=<ihr Passwort> . Hinweis des Autors: ich hatte keinen Erfolg, meine Daten zu importieren, solange ich kein Passwort vergeben hatte — was man bei lokalen Testinstallationen ja nicht immer macht :) .

Jetzt sollten Sie zunächst den PGAdminIII öffnen und sich mit der Datenbank meingis verbinden. In den Tabellen nodes und ways ändern sie den Typ der Spalten ID von BIGINT zu INTEGER (Doppelklick auf den Feldnamen, Typ INTEGER auswählen und mit OK bestätigen). Mit ein bisschen Zeit, werde ich mir allerdings noch die Skripts zur Erstellung der Datenbankstruktur ansehen und diese so ändern, dass man sofort eine QGIS-kompatible Struktur bekommt. Dazu später mehr …

In bekannter Weise kann man jetzt in PGAdminIII oder QGIS auf die Daten zugreifen (siehe hier). Die Darstellung in QGIS ist allerdings recht simpel (keine direkte Unterscheidung der Straßentypen oder Nodes möglich), was aber Zugunsten der Datenstruktur für mich in Ordnung geht. Auch hier werde ich mich nochmal vertiefend einarbeiten, um die Attribute mit den Geometrien zu verknüpfen und damit eine differenzierte Darstellung in QGIS zu erlauben. Dazu muss man dann wohl einen VIEW oder eine ganz neue Tabelle in PostGIS erstellen. Bei VIEWs werden die notwendigen Primärschlüssel nicht erkannt. OIDs könnten hier Abhilfe schaffen. Auch dazu dann später mehr …

Und jetzt?

Wenn bis hierhin alles geklappt hat, werden sich sicher noch weitere Fragen zu speziellen Anwendungen ergeben. Die OSM-Daten sind teilweise besser, als man denkt. Ich wiederhole mich eigentlich nur ungerne, aber bitte beschweren Sie sich nicht bei mir, wenn gerade in Ihrem Bereich der Karte noch Informationen fehlen: warum haben Sie die denn noch nicht erfasst? OpenStreetMap ist ein offenes Projekt für jeden, der Daten dazu beitragen kann!
Bitte richten Sie Ihre Fragen doch einfach per EMail an mich (siehe Kontaktformular). Entweder kann ich diesen Artikel fortsetzen oder individuelle Antworten geben bzw. meine Unterstützung anbieten.

GIS im Alltag

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? Ich bin mir sicher, fast jeder hat im Alltag mit irgendeiner Form eines GIS zu tun. Manchmal aktiv, manchmal passiv. Fangen wir doch einmal an zu suchen. Sie werden sehen, dass Sie sich in der einen oder anderen Situation wiederfinden werden, ohne dass es Ihnen bisher vielleicht bewusst war.

In den letzten Monaten bin ich im meinem bevorzugten Baumarkt öfter an der Kasse nach meiner Postleitzahl (PLZ) gefragt worden. Eines der einfachsten Mittel, um Basisdaten für Geomarketing zu sammeln. Anonyme Daten dienen dazu, den Einzugsbereich des Marktes abzuschätzen, um gezielter Werbeprospekte versenden zu können. Die Schlüsse , die der einzelne Markt daraus zieht, können unterschiedlich sein. Man kann einen Soll-Ist-Vergleich anstellen, indem man die PLZ-Bereiche betrachtet, aus denen die Kunden kommen und diesen vergleicht, mit dem PLZ-Bereich, den man gerne versorgen möchte. Durch gezieltes Bewerben der schwachen Bereiche, kann der betreffende Markt jetzt versuchen, vermehrt die Kunden dort zu erreichen. Wenn dem Markt oder der Kette soziografische Daten vorliegen, könnte dieser versuchen besonders kaufstarke Bereiche vornehmlich zu erreichen. Diese Analysen kann man bis in nahezu beliebige Detailstufen verfeinern. Dies ist ein Bespiel für den passiven Kontakt mit einem GIS.

OSM-Daten in PostGIS und QGIS

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.

Voraussetzungen

Da ich gewohnt bin unter Linux (Ubuntu) zu arbeiten, beziehen sich meine Beschreibungen hier auch auf diese Umgebung. Ich habe auf meinem Notebook eine Standard Ubuntu Installation (aktuell Lucid) zu der ich die zugehörigen Pakete PostgreSQL 8.4, PostGIS 1.4, OSM2PGSQL und QGIS 1.4 installiert habe. Um in PostgreSQL mit einer grafischen Oberfläche arbeiten zu können, habe ich zusätzlich PGAdminIII installiert. Nach der Installation dieser Pakete muss man nur noch ein wenig Hand anlegen und schon hat man ein brauchbares GIS mit OSM-Daten. Aber alles der Reihe nach …

Die Datenbank vorbereiten

Nachdem PostgreSQL und PostGIS installiert sind, ist für den Datenbankserver die Spatial Erweiterung aktiviert. Bei mir war der Zugang zu pgsql (Kommandozeilen-Client für PostgreSQL) an der Kommandozeile zwar sofort möglich, aber nicht per PGAdminIII. Bei PGAdminIII wird ein Passwort erwartet, welches ich zunächst in pgsql setzen musste. Man erzeugt zunächst in einem normalen Linusterminal (z. B. bash) einen neuen Datenbankuser mit dem Befehl createuser gisadmin (sofern sich das Ganze zu Testzwecken auf dem lokalen PC abspielt, beantworte ich die Frage nach dem Superuser mit Ja). Danach erzeugt man eine Datenbank mit dem Befehl createdb meingis. Damit es später keine Probleme in PGAdminIII gibt, sollte man zu diesem Zeitpunkt ein Passwort für den gisadmin-User vergeben. Dazu verbindet man sich mit dem PostgreSQL-Server mit dem Befehl psql -d meingis und benutzt dann den Befel \password gisadmin. Man gibt jetzt zweimal das neue Passwort ein (es erscheint eine Eingabeaufforderung) und meldet sich anschließend mit \q wieder vom PostgreSQL-Server ab.
Die Datenbank muss jetzt um eine Sprachkomponente erweitert werden (PostgreSQL Programmiersprache): createlang plpgsql meingis. Jetzt  sucht man die beiden Dateien postgis.sql und spatial_ref_sys.sql. Bei mir lagen diese im Verzeichnis /usr/share/postgresql/8.4/contrib. Wichtig ist, dass man nicht das postgis-common Paket installiert hat (das enthält nämlich nicht diese beiden Dateien), sondern das von Ubuntu für PostgreSQL 8.4 angepasste. Notwendige Tabellen in der Datenbank meingis erzeugt man mit den beiden Befehlen pgsql -d meingis -f /usr/share/postgresql/8.4/contrib/postgis.sql und pgsql -d meingis -f /usr/share/postgresql/8.4/contrib/spatial_ref_sys.sql.

Detaillierte Infos zur Installation von PostGIS findet man hier…

Her mit den OSM-Daten …

Wir haben zu diesem Zeitpunkt ein schönes neues GIS aber leider noch ohne Daten. Über das normale Webinterface von OpenStreetMap (OSM) (www.openstreetmap.org) kommt man allerdings nicht sehr weit. Man muss hierzu die s. g. XAPI von OSM benutzen. Anfangs dachte ich auch, hier ist wieder was ultrakompliziertes um an die Daten zu kommen, aber weit gefehlt. Die eigentliche Mühe ist die Bestimmung des Bereichs, den ich extrahieren möchte und der Objekte, die ich ggfs. einschränken möchte. Ich werde hier ein Beispiel für einen Bereich in Oberhausen nutzen und einfach alle Objekte extrahieren. Für eine verfeinerte Abfrage benutzen Sie bitte diese Beschreibung.

Ich setze mal voraus, dass Sie die LON- und LAT-Koordinaten für den Bereich (linke untere Ecke und rechte obere Ecke) gerade nicht zur Hand haben. Öffnen Sie das Webinterface von OpenStreetMap und navigieren Sie an die Stelle der Karte, wo sich der auszuwertende bereich befindet. Plazieren Sie die Kartemitte an der linken unteren Ecke (LU) des Bereichs und lesen dann die Koordinaten via Permalink (unten rechts in der Karte) ab. Das wiederholen Sie bitte mit der rechten oberen Ecke (RO). Entweder geben Sie jetzt die folgende Zeile in Ihrem Internetbrowser ein und speichern die angezeigten Daten unter dem Namen data.osm ab (http://xapi.openstreetmap.org/api/0.6/map?bbox=LON-LU,LAT-LU,LON-RO,LAT-RO). Oder Sie benutzen im Linuxterminal den Befehl wget http://xapi.openstreetmap.org/api/0.6/map?bbox=LON-LU,LAT-LU,LON-RO,LAT-RO -O data.osm. Natürlich müssen Sie die Parameter hinter bbox= mit den jeweiligen Werten ersetzen, die Sie ermittelt haben.
Die erzeugte Datei (data.osm) kann zwischen wenigen MB und einem halben GB groß sein, jen achdem, wie groß Sie den Bereich gewählt haben. Hat Ihre data.osm eine Größe von 0kb — ist also leer — dann prüfen Sie bitte, ob Sie die Eckpunktkoordinaten für den Bereich richtig eingetragen haben. Der Fehler soll öfter vorkommen …

OSM-Daten für Datenbank aufbereiten

Mit den OSM-Daten können wir leider immer noch nicht wirklich etwas anfangen. Das ändert sich aber jetzt.  Mit dem Programm OSM2PGSQL übertragen wir die OSM-Daten jetzt in besonders aufbereiteten Tabellen nach PostGIS. Für den erstmaligen Aufruf benutzt man folgende Kommandosyntax: osm2pgsql -c -d meingis -U gisadmin -W -H localhost data.osm. Das -c steht dafür, dass die notwendigen Tabellen neu erzeugt werden (create) oder schon vorhandene Tabellen neu befüllt werden und die alten Daten verworfen werden. Danach folgt der Datenbankname, der Benutzername, die Abfrageoption für das Passwort, der Name des Datenbankhosts und die eigentliche Datendatei, welche transportiert werden soll.
Ist der Befehl fehlerfrei durchgelaufen (wobei bei mir lediglich Fehler bei den Parametern vor dem Dateinamen aufgetreten sind), befinden sich in der Datenbank meingis jetzt die ausgewerteten OSM-Daten.
Neben OSM2PGSQL gibt es noch die Möglichkeit das Programm OSMOSIS zu benutzen. Das werde ich hier aber zu diesem Zeitpunkt nicht beschreiben.

PostGIS mit QGIS verbinden

Der Eine oder Andere findet es sicherlich auch sinnvoll, Abfragen direkt an der Datenbank auszuführen. Die eigentliche Stärke des GIS gegenüber textbasierten Datensammlungen ist aber doch die Visualisierung der Daten in einer Karte. Da PostGIS lediglich eine Datensammlung ist, kann man die Daten nicht ohne ein weiteres Programm als Karte darstellen. Es gibt sicher eine Reihe von anderen GIS, die ich mit PostGIS verbinden kann, traditionell beschäftige ich mich aber mit QGIS. Dies lässt sich sehr einfach mit PostGIS verbinden.
In der Leiste der Schaltflächen findet sich das blaue tonnenförmige Symbol mit dem Pluszeichen, mit dem man einen neuen PostGIS-Layer hinzufügen kann. Nach einem Klick auf das Symbol öffnet sich ein Dialogfenster, in dem ich beim ersten Verbinden über die Schaltfläche Neu eine neue Verbindung erstellen muss. Man gibt der Reihe nach den Namen der Verbindung (z. B. meingis), den Host (localhost), den Datenbanknamen (meingis) den Benutzernamen (gisadmin) und das weiter oben eingegebene Passwort ein. Klicken Sie bitte nach der Eingabe der Informationen zuerst einmal auf  Verbindung testen. Ist dieser Test erfolgreich, können Sie den Dialog mit OK verlassen. Ist der Test nicht erfolgreich, prüfen Sie bitte nochmals die eingegebenen Informationen. Im oberen DropDown-Menü sollte jetzte der soeben erstellte Eintrag erscheinen. Klicken Sie bitte auf Verbinden. In der unteren Tabelle erscheinen jetzt vier Tabellen, deren Namen mit planet_osm_… beginnen. Hier sind Linien (…_line), Punkte (…_point), Flächen (…polygon) und spezielle Straßen (…_roads) abgelegt. In meinen Daten, haben sich allerdings die meisten Straße in der Tabelle der Linien wiedergefunden und nicht in den Roads. Das nur als Hinweis! Klicken Sie jetzt alle Tabellen der Reihe nach anund klicken dann auf Hinzufügen, um Sie in QGIS anzeigen zu lassen.

Schöne Linien …

… machen noch keine ansprechende Karte. Sofern Sie mit QGIS noch nicht vertraut sind, sollten Sie möglicherweise das Tutorial durcharbeiten, in dem die Konfiguration der Eigenschaften der Objekte beschrieben wird. Als kurzen Anhaltspunkt, verrate ich soviel: klicken Sie mit der rechten Maustaste auf einen der Layernamen (z. B. planet_osm_line) und öffnen dort die Eigenschaften. Neben der Darstellung können Sie hier auch die Beschriftung beeinflussen. Setzt man den Haken bei Beschriftung anzeigen, wählt man zunächst das Beschreibungsfeld, welches i. d. R. name heißen wird, sofern Sie keine exotischen Informationen in der Karte benötigen. Probieren Sie einfach verschieden Optionen aus (z. B. Schriftgröße und Freistellung). Sollte ein Layer besser von einem anderen überdeckt werden (Flächen sollten besser von den Straßen überdeckt werden), dann ziehen Sie diesen in der Layerliste einfach bei gedrückter linker Maustaste an die entsprechende Stelle der Liste.

Und jetzt?

Wenn bis hierhin alles geklappt hat, werden sich sicher noch weitere Fragen zu speziellen Anwendungen ergeben. Die OSM-Daten sind teilweise besser, als man denkt. Aber bitte beschweren Sie sich nicht bei mir, wenn gerade in Ihrem Bereich der Karte noch Informationen fehlen: warum haben Sie die denn noch nicht erfasst? OpenStreetMap ist ein offenes Projekt für jeden, der Daten dazu beitragen kann!
Bitte richten Sie Ihre Fragen doch einfach per EMail an mich (siehe Kontaktformular). Entweder kann ich diesen Artikel fortsetzen oder individuelle Antworten geben bzw. meine Unterstützung anbieten.

QGIS (III)

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.

Die Oberfläche hat sich seit dem um einiges gebessert und ist übersichtlicher geworden. Hier und da ist die deutsche Hilfe allerdings ein wenig sprachlos. Die Anbindung einer PostgreSQL-Datenbank (mit PostGIS-Erweiterung) funktioniert stabiler und ist einfacher geworden (Danke!). Mein zweites wesentliches Interesse gilt der Arbeit mit GPS-Daten. Der Import der GPS- (GPX-) Daten funktioniert reibungslos. Die Daten werden sauber angezeigt und man kann auf die Länge und die Start- bzw. Endkoordinaten per Eigenschaften des Tracks direkt zugreifen. Je nach dem, wie man die GPS-Daten erfasst hat, kann vor dem Import, ob man alle Daten oder nur Wegepunkt, Strecken bzw. Routen in einen eigenen QGIS-Layer speichert möchte. Man hat so die Möglichkeit, zu entscheiden, was man importieren möchte. Für mich wäre noch ein Zugriff auf die Start- und die Zielzeit interessant. Ob und wie das geht, folgt möglicherweise in einem späteren Bericht. Früher war es immer ein kleines Problem für mich, die vorhandenen Daten zu bearbeiten. Sei es die Lage oder die Sachinformationen zu den Objekten. Dies gelingt bei Shape-Daten und bei Daten, die in PostGIS (PostgreSQL) abgelegt sind mittlerweile einwandfrei. Bin ich in den Bearbeitungsmodus gewechselt, kann ich mit den entsprechenden Werkzeugen Objekte löschen, zufügen oder verändern. Schließe ich den Bearbeitungsmodus, werden ich darüber informiert, dass es ungesicherte Änderungen gibt. Diese kann ich dann verwerfen oder sichern. Was mir bisher nicht aufgefallen ist, ist der DXF2Shape-Konverter, der aus DXF-Dateien, Shape-Layer macht. Das Einbinden von WMS (WebMapServices), also Karten, die im Internet abgegriffen werden können, sollte man auf jeden Fall ausprobieren. Man glaubt kaum, welche Karten hier genutzt werden können. Aus lizenzrechtlichen Gründen werde ich hier keine Links zu diesem Thema anbieten.

QGIS reift also immer mehr zu einem stabilen Werkzeug im Umgang mit den üblichen Geodaten heran. Dank der komfortableren Oberfläche lassen sich Funktionen schnell erreichen und die deutschen Kurzerläuterungen zu den Funktionsbutton (Mouse-over-Hilfe) helfen auf die Schnelle.

Da die Entwicklung von QGIS ständig weiterschreitet, wird es in Zukunft sicher weitere Artikel dieser Art geben.

Funktionen rein oder raus?

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. Die Teststellung wurde an meinem letzten Arbeitstag für dieses Jahr durchgeführt und meine GIS Kollegen haben in meiner Abwesenheit noch ein paar Tage Zeit, das System ein wenig kennenzulernen und auszuprobieren. Auf die Unterschiede der beiden Versionen möchte ich hier noch garnicht eingehen. Das spare ich mir für den Zeitpunkt auf, wenn ich mit dem System ein wenig mehr gearbeitet habe. Um das neue GIS gut unter Kontrolle zu halten, werde ich im Januar eine Konfigurationsschulung besuchen. Danach werde ich zu diesem Thema sicher eine Menge mehr sagen können.

Bei einem solchen Installationstermin — der mittlerweile nicht mehr im Serverraum, bei unsäglicher Lautstärke stattfinden muss, so wie noch zu Zeiten von SW GIS 2 — gibt es immer ein wenig Leerlauf, wenn Datenbanken kopiert werden oder die notwendigen Installationen von Webservern und sonstigen Diensten durchgeführt werden müssen. Um jetzt aber wirklich auf den Punkt dieses Beitrags zu kommen: während dieser Leerlaufzeiten habe ich die von mir gerne genutzten Gelegenheiten, mich mit Anderen auszutauschen, die Geoinformation beruflich betreiben und auch mal über den Tellerrand hinausschauen. In diesem Fall war der „Leidensgenosse“ Herr Christian Vogt. Er ist einer der Gesellschafter unseres Dienstleisters GIS Consult GmbH. GIS Consult (im weiteren als GC bezeichnet) betreut Unternehmen und Kommunen rund um das Thema GIS. Ich kenne das Unternehmen jetzt schon seit meinen Anfängen im GIS und habe ein durchweg positives Bild von den Kollegen dort in menschlicher und fachlicher Hinsicht. Genug Schleichwerbung! :-)

Also, eines von verschiedenen Themen, auf das wir im Laufe des Tages gekommen sind, war die Frage danach, wie und wo ich meine Geodaten ablegen kann. Aus dem Blog hier ist sicher bekannt, dass ich bei der Beantwortung dieser Frage zu Postgres/PostGIS neige. Das liegt zum Teil daran, dass PostGIS, als Geospatial-Erweiterung zu Postgres, einen großen Vorrat an OGC-konformen Funktionen mitbringt, auf die man in der Applikationsentwicklung mit z. B. PHP zurückgreifen kann. Postgres benutze ich also nicht nur als zentralen Datenspeicher für meine Geodaten, sondern nutze auch die Funktionen, die PostGIS mitbringt, um damit meine Aufgaben zu erledigen. Dies ist für mich eine sehr angenehme Variante, da ich mich sehr intensiv mit den Daten auseinander setzen kann, ohne mich um die Bereitstellung von Funktionen zu kümmern. In meinem beruflichen Umfeld verhält sich das Ganze aber z. B. genau anders herum. Wie mir Herr Vogt eindrucksvoll zeigte, lässt sich an das SW GIS 4.1 mit einem neuen kleinen Tool nahezu jede beliebige Datenquelle anhängen, die gewissen Standards genügt. Dies könnte ich bei Quantum GIS auch noch bei einem gewissen Umfang an Datenquellen erreichen. Hier habe ich allerdings das Problem der Funktionalität. Gehen wir von der Basisinstallation von Quantum GIS aus, so bringt es alles mit, um Datenquellen mit Geodaten anzuzeigen. Die Funktion ‘Pufferung’ bringt QGIS auch noch mit. Aber dann? Wonach ich hier suche, ist ein anwenderfreundliches Abfragetool, mit dem ich die Tabellen meiner Datenquellen ansprechen kann, um alphanumerische oder sogar grafische Auswertungen auszuführen. Soweit ich weiß, geht dies über eine Konsole, die ich öffnen kann, um Abfragen einzugeben. Dies erschien mir aber nicht sehr benutzerfreundlich. Das SW GIS hat hier ein anderes Konzept. Hier sind nur die Daten in der Datenbank abgelegt, welche die Aufgabe übernimmt, diese performant und komfortabel zu verwalten. In der grafischen Oberfläche des System (SW GIS Version 3.1!!) ist eine Abfrageumgebung vorhanden, welche den Anwender dabei unterstützt, Abfragen in Form von Texten (ähnlich SQL) oder grafisch orientiert, syntaktisch richtig zu erstellen. Die Abfragen in Form von Texten als auch die grafisch orientierten Abfragen führen, allgemeine Kenntnis von Abfragelogiken vorausgesetzt, sehr schnell zum gewünschten Ergebnis. Näher darauf einzugehen, würde den Rahmen dieses Beitrags sprengen. Vielleicht komme ich darauf in einem späteren Beitrag zurück. Die kompletten Funktionen sind in der Anwendung, im so genannten Image, abgelegt. Dieses wird in eine Art virtuelle Maschine geladen und stellt die generellen und die kundenspezifischen Funktionen zur Verfügung. Hier kommt dann wieder die GC ins Spiel, die als Entwicklungspartner von Smallworld Deutschland, diese Funktionen programmiert.

Der Leser mit etwas Erfahrung wird mir jetzt zurecht vorwerfen, dass diese Ausführungen nicht ganz fair sind. Wenn ich mich selber und die Community von QGIS bemühe, werde ich sicher mit einem gewissen Aufwand identische Funktionen für QGIS hinbekommen. Den Punkt, den ich hier herausarbeiten möchte, ist aber der Funktionsumfang der Datenbanken. Mit mehr oder weniger Aufwand kann ich jeder Applikationen mit einem entsprechenden Unterbau (Programmiersprache) die Funktionen beibringen, die ich benötige. Smallworld GIS trennt allerdings die Aufgaben der Datenhaltung und der Abfragefunktionen schärfer, als dies PostGIS tut. Auf der einen Seite haben wir eine reine Datenhaltung (jemand aus dem Smallworld Umfeld möge mir hier widersprechen, wenn das nicht so ist!!), während auf der anderen Seite OGC-konforme Funktionen bereitstehen, die ich in eine SQL-Abfrage einbauen kann.

Ich muss allerdings dazusagen, dass die Diskussion in meinen Augen weniger die Frage nach dem Besser oder Schlechter stelllt. Vielmehr geht es mir darum, unterschiedliche Philosophien aufzuzeigen. Wenn ich in meiner Datenbank keine oder nur sehr wenige Funktionen habe, die mir erlauben, Geodaten grafisch auszuwerten (z. B. MySQL), bleibt mir garnichts anderes übrig, als die Funktionen ausserhalb der Datenbank bereitzustellen. Habe ich eine Applikation, welche nahezu beliebige Datenquellen mit Geodaten öffnen kann, sollte ich mich auf darauf konzentrieren, die Basisfunktionen so zu entwerfen, dass ich diese auf alle diese Datenquellen anwenden kann. Hierzu zählen für mich Lese- und Schreibfunktionen von Sachinformationen und Geometrien. Sind in einer Datenquelle Geometrien vorhanden, möchte ich diese ggfs. auch verändern und wieder abspeichern. Solche Funktionen sollten dann immer bereitstehen.Sind in der Datenbank soviele Funktionen vorhanden, dass ich mehr Zeit darauf verwenden kann, die Sachinformationen für den Anwender in ansprechender und sinnvoller Weise darzustellen, sollte ich dies auch tun. Warum das Rad neu erfinden?

Hat man ein bestehendes GIS, stellt sich die Frage danach, wo die Funktionen zu finden sind, meist garnicht. Man kann bei der Auswahl nach einem neuen GIS aber auf diesen Punkt sein besonderes Augenmerk legen. Man sollte sich hier also die Fragen stellen:

• Muss ich regelmäßig externe Datenbestände mit meinen eigenen Datenbeständen in Verbindung bringen?
• Enthalten die externen Datenbestände Geodaten und stehen diese in einem Standarddateiformat zur Verfügung?
• Kann ich über geeignete Software (ODBC-, JDBC- oder sonstige Treiber) externe Datenquellen bequem anbinden?

Sind das Punkte, die überwiegend zutreffen, könnte man die Funktionen auf Seiten der Applikation suchen und ausbauen. In dieser Kategorie sind IMHO spezielle GIS zu finden, die externe Daten benötigen, die weniger aus dem GIS-Umfeld stammen und sich häufig ändern.

• Werden die externen Daten nur in größeren Zeitabständen aktualisiert?
• Sind die Geodaten in sehr einfachen Dateiformaten verfügbar (z. B. Textformat)?
• Lassen sich die externen Geodaten bequem in meine zentrale Datenbank importieren?

Sind das Punkte, die überwiegend zutreffen, könnte man nach einer performanten Datenbank suchen, die neben den Geometriedatentypen auch den größten Teil der Funktionen zur Verfügung stellt, die ich benötige.

Leider werden die Grenzen zwischen den Kategorien stark verwischt, wenn man in den Bereich der Webanwendungen kommt. Man kann seine Daten in geeigneter Weise auf einen vorhandenen Webkartendienst aufsetzen, und auch ohne viel Mühe einen eigenen Mapserver aufsetzen, der die speziellen Karten bereitstellt. Hier kann man auf beide Varianten zurückgreifen. Ich werde mich in einem späteren Beitrag speziell mit der Thematik der WEB-GIS-Anwendungen auseinanderstzen, weshalb ich hier die Ausführungen einfach bis dahin unterbreche.

Ein Fazit kann ich zu diesem Thema, wie schon erwähnt, also nicht wirklich geben. Ich kann dem interessierten Leser lediglich ein paar Punkte an die Hand geben, mit denen er in die Diskussion einsteigen kann, wo die Geodaten in dem speziellen Fall möglicherweise bessser aufgehoben sind. In konkreten Fällen versuche ich gerne, etwas Licht in die Situation zu bringen. Man kann aber genauso gut ein entsprechendes Forum besuchen oder ein beratendes Unternehmen wie die GC konsultieren.

GIS nochmal anders – Open Streetmap

Nachdem ich als letztes einen Beitrag zum GeoCaching geschrieben habe, hier nochmal etwas anderes, was sich neben dem klassischen GIS bewegt. Auf einer Fachtagung habe ich einen Beitrag zu einem Projekt gehört, das sich Open Streetmap nennt. Das Projekt hat das Ziel, mit der Hilfe von Freiwilligen eine freie Datenbank für Straßenpläne weltweit zu erstellen. Diese wird aus den gesammelten GPS-Daten der Freiwilligen erstellt.

Hierzu werden die Daten (Tracks) aus dem Handheld oder Auto-Navigationssystem ausgelesen, in das Standard GPX-Format gebracht und zunächst auf die Hompage des Projektes übertragen. Auch wenn es sich so anhört: das ist keine Hexerei und für jeden der halbwegs mit einen GPS-Handheld und einem PC umgehen kann einfach zu bewerkstelligen. Danach kann man sich eine freie Software von der Projekthomepage besorgen (z. B. JOSM) in der dann die Straßenzüge erstellt werden, die Straßennamen vergeben werden und andere POI (Points Of Interest) angelegt werden können. Die Genauigkeit ist hierbei stark abhängig von den eingesetzten Geräten und wird i. d. R. nicht schlechter sein, als bei einem normalen Navi. Die Tracks, die ich hochgeladen habe, hatten allesamt eine Genauigkeit von +/- 3m.

Man darf sich nicht vertun und annehmen, man benötige eine Genauigkeit von kleiner als 1m um mit dem Auto auf einer Straße zu fahren. Zur Orientierung reichen diese Daten allemale aus. Moderne Navigationssoftware „zwingt“ die angezeigte Position des Fahrzeuges auf die Straße und das Gerät entscheidet anhand der Abweichung von der Straßenlinie, ob man sich noch auf der Straße befindet oder schon auf der Abbiegespur. Die Handhelds zeigen immer die genaue Position an, daher fällt hier schneller auf, ob man sich noch auf dem Weg befindet oder nicht. Achten Sie doch einfach mal vorsichtig bei der nächsten Fahrt mit dem Navi darauf. Aber bitte achten Sie trotzdem immer genau auf den Verkehr, damit Sie sich nicht selbst in eine gefährliche Situation bringen!!

Zu mehr ist das Kartenmaterial momentan auch nicht gedacht. Bisher gibt es noch keine Routingfunktion, d. h. ich kann keine Route planen. Allerdings kann ich die Karten auf mein GPS Gerät laden und dann bei einer Radtour oder beim Wandern sehen, wo ich mich befinde. Dabei brauche ich kein schlechtes Gewissen zu habe oder viel Geld für entsprechende Karten ausgeben. Das Kartenmaterial von Open Streetmap ist frei verfügbar.

Als ich mir den Plan angesehen habe, für den Bereich in Wanne-Eickel (Herne), in dem ich wohne, stellte ich fest, dass hier ein riesiger weißer Fleck war. Die Betonung liegt auf „war“. Mit anfänglicher Euphorie habe ich eine ganze Reihe von Straßenzügen erstellt und erfolgreich in das Projekt eingebracht. Momentan holt mich das Studium wieder ein, so dass ich meine Zeit anders verwenden muss. Sobald ich im April aber wieder ein bisschen Zeit habe und das Wetter besser wird, werde ich wieder ein paar neue Strecken hinzufügen.

GIS einmal anders — GeoCaching

Das GIS auch einen Freizeitwert haben kann, erlebe ich seit kurzem. Ein Arbeitskollege hat mich mit dem Thema GeoCaching konfrontiert. Ich habe vorher noch nicht viel davon gehört, obwohl ich mich durch meine berufliche Vergangenheit mit dem Thema GPS intensiv auseinander setzen musste.

Gesagt getan habe ich mir einen Account auf www.geocaching.com besorgt, genauso wie einen simplen Garmin etrex — ein Einsteigermodell. Und was soll ich sagen: ich bin seit ca. einer Woche offiziell angemeldet und habe mit meinen Kindern schon 6 Caches („Schätze“) gefunden. Auch wenn wir sonst ohne dies schon viel spazieren gehen, erfahren diese Spaziergänge momentan eine besondere Aufwertung. Man sollte das Ganze sicher nicht zu ernst nehmen, aber immerhin gibt es in Deutschland rund 30.000 Caches und weltweit ungefähr 400.000 Caches. Wer mehr zu dem Thema erfahren möchte, kann dies in Wikipedia tun (sehr ausführlicher Artikel) oder sich auf www.geocaching.de bzw. www.geocaching.com informieren.

Ich denke, bei den 6 Caches wird es sicher nicht bleiben. Der Urlaub auf einer beliebten Insel der Balearen sollte mindestens 2 Founds bringen! :-)

QGIS (II)

Seit einiger Zeit ist auf der Seite der Programmierer ein neuer Release von QGIS zu bekommen (www.qgis.org) — nämlich die Version 0.8.1. Das ich das überhaupt ausdrücklich erwähne liegt daran, dass ich letztens versucht habe, einen WMS-Dienst (Kartenserver im Internet) anzubinden. Da ich selbst noch eine Version 0.7 im Einsatz hatte, suchte ich den Dateityp im „Öffnen“-Dialog vergeblich.

Ein Blick auf die Homepage von QGIS brachte die Lösung meines Problems. Ab der Version 0.8 wird das Einbinden eines WMS-Layers unterstützt und funktioniert sehr gut. Einige freie WMS-Server sind unter folgender Adresse im Internet zu finden: http://www.skylab-mobilesystems.com/ger/wms_serverlist.html. Zum Ausprobieren sollte einigs dabei sein.