Category Archives: FOSSGIS

PostGIS and hstore for OSM Data

Unlike traditional GIS data, which usually uses just a couple of attributes per spacial object, openstreetmaps comes with a free tagging scheme. In traditional database design it is impossible to store this type of data in a single table thus adding the need for joins in any single SQL request.

Starting from Version 9.0 PostgreSQL will however include an extension called hstore which is available as a backport for current Versions of PostgreSQL (8.3 and 8.4) and even as a debian package.

Using this extension an additional key/value table is no longer needed.

Already back in March I commited a patch for osm2pgsl which would allow for storage of tag objects inside such a hstore column.

An hstore is basically what is known as hash (perl) or dictionary (python) in scripting languages. A datatype for storage of key value pairs – well suited for storage of OSM data tags.

Talking about python I took me quite some time to figure out how to convert a hstore result from an SQL query so here is how it works:

q="select (each(tags)).key,(each(tags)).value from ... where ..."
cur.execute(q)
rows = cur.fetchall()
hstore=dict(rows)

Back to the actual hstore issue…

In the meantime people are actually starting to use this stuff and MaZder even wrote a HOWTO document (currently in german language only) on howto set up such a database.

So here are the projects currently using hstore that I am aware of:

Tags:

The 201 Gigapixel Image :)

German Company Aerowest is providing Openstreetmap with high resolution Images.

Once again I have been doing most of the technical work which needed to be done behind the scenes. While wms.openstreetmap.de has been up and running for a few weeks now I still had to do some stuff to get the things going.

First of all I converted the mapscript from the older mod_python to the state of the art mod_wsgi. Furthermore the script has been extended to allow for individual copyright-watermarks based on mapfile entries. Tiles generated for Potlatch are now cached using the Apache Module mod_disk_cache.

The aerial image itself came as a raster image of 201 Gigapixels in the very good (in terms of image compression) but proprietary ECW-format. For legal reasons we are now using another format for actually serving the image (eating a huge 675 Gigabytes of disk-space) because the proprietary license of libecwj2 does not state very clearly if we are allowed to use it in our setup or not.

Announcing wms.openstreetmap.de

A few weeks ago I started to set up http://wms.openstreetmap.de to serve aerial images donated by various sources for Openstreetmap use. Currently the system holds data from german communities Lauf an der Pegnitz and Neunkirchen am Sand (thank you very much for donating the data!). It is designed to be extensible with additional data in an easy way. If anybody in the Openstreetmap community is looking for such a service just drop me a line.

The system is powered by Mapservers mapscript written in Python to allow for convenient URLs in JOSM’s WMS plugin. In addition to this I just added support for the Online Openstreetmap Editor Potlatch while learning how to use custom tile-servers with it by chance. This is done by converting tilenames in z/x/y format to the bounding boxes needed for WMS. An Apache mod_rewrite rule provides a virtual tile-URL in the syntax needed by Potlatch and allows for direct edit-links of the available areas now provided on http://wms.openstreetmap.de

The script itself will be released as free software and added to Openstreetmap SVN.

Finally I need to mention that the system is also running on one of the Servers sponsored by german webhosting company STRATO AG.

IPv6 bei Strato: Der Kenner wundert sich!

Heute lese ich bei Heise, dass Strato ab sofort IPV6 und VLAN anbietet. Nun hat die deutsche Openstreetmap Community ja freundlicherweise 3 Server von dieser Firma gesponsort bekommen und ich dachte mir dass man da ja mal IPv6 aktivieren könnte!

Über die Realisierung ist man man dann jedoch, wenn man IPv6 schon länger kennt etwas verwundert. Während die Konfiguration der IPv4 Adresse automatisch per DHCP erfolgt muss man die IPv6 Adresse manuell einstellen und das obwohl bei IPv6 im Gegensatz zu IPv4 die automatische Konfiguration eigentlich das übliche Verfahren ist.

Ich habe hier zu Hause auf meinem Desktoprechner beispielsweise keine IPv6 Adresse explizit eingestellt. Stattdessen bekomme ich diese von meinem Router per radvd automatisch anhand der MAC-Adresse zugewiesen.

Es ist schon erstaunlich, dass das bei Strato nicht so funktioniert. Trotzdem natürlich kein Vergleich zu den Mitbewerbern bei denen man IPv6 nur zum völlig absurden Aufpreis von 29 €/Monat (Hetzner) oder kostenlos per Tunnel (1&1) bekommt.

Langer Rede kurzer Sinn, die drei FOSSGIS Rechner bei Strato sind also ab sofort auch per IPv6 erreichbar!

Problems in Wikipedia that Openstreetmap does not have

Currently there are ongoing discussions in the german arm of the wikipedia about the relevance of certain articles. Some people think they should be deleted because they are not relevant enough to be mentioned in an encyclopedia.

While Openstreetmap has different and arguably harder to solve problems in other areas, we fortunately do not have them in this particular case.

As a matter of fact, we simply don’t even try to rate something as relevant.
If you want to put an object into our database, because it is relevant for you, then you are welcome to do so. The now infamous discussion on the german mailinglist about dog-excrement-bags comes to mind.

The only thing where I could imagine a simular discussion is one about particular objects to be rendered in the standard map style or not.

There is only one reason for objects to be deleted from our database. They are nonexistent on a particular place, ever were or ever will.

If they are non-existant anymore (e.g. stuff like disused railways) they have to be marked as such. Pretty black and white stuff as you can see.

Intergeo 2009

Next week myself and other people from FOSSGIS e.V. will be present at the INTERGEO fair which is hosted In my hometown this year.

Working at the booth of my employer for most of the time, I will be at the OSGeo Park on Wednesday.

This should be a good place to spread the word about Openstreetmap. Karlsruhe was the first mayor german city to be completely mapped and this is also the place where the authors of the Openstreetmap book live.

Both of them will also be present at the OSGeo Park.

Geodatenkonvertierung für Openstreetmap

Wer sich ein wenig näher mit Geodaten befasst stellt recht schnell fest, dass man da mit unglaublichen Mengen an historisch gewachsenem Zeug zu kämpfen hat. Ähnlich grausam ist das eigentlich im EDV Bereich nur noch beiCharacter Encoding. Im Geodatenbereich hat sich jedoch das Gegenstück zu Unicode leider noch nicht in der Breite durchgesetzt. Jedes Land wenn nicht sogar jedes Bundesland kocht da meist sein eigenes Süppchen.

Daten die man von öffentlichen Stellen in Deutschland bekommt sind meist in der Gauß-Krüger-Projektion mit Bessel-Ellipsoid in 3° breiten Meridianstreifen. Für die südlichen Bundesländer sind das GK2 für RLP, GK3 für BW und GK4 für Bayern.

Für OSM brauchen wir die Daten aber im “GPS Format” mit geographischer Länge und Breite bezogen auf WGS84 (epsg:4326). Es stellt sich also die Aufgabe die Daten möglichst genau in diese Formate zu überführen.

Weil OSM ein freies Projekt ist verwenden wir dazu natürlich freie Software!

Ein Kommandozeilenprogramm zur Konvertierung von im Geobereich üblichen Vektorformaten ist das Kommandozeilentool ogr2ogr.

Da die Kommandozeilen ein wenig kryptisch sind veröffentliche ich hier mal die passenden Konvertierungsbefehle für die GK-Zonen, mit denen ich bisher zu tun hatte.

Es geht darum die Aufgabe zu lösen Dateien in GK-Format in eine OSM geeigenete Darstellung (epsg:4326) zu überführen. Dankenswerteweise gibt es dafür eine amtliche Korrekturdatei zum Download. Damit erreicht man Genauigkeiten von etwa einem halben Meter. Für OSM ist das also mehr als ausreichend. Strenggenommen ist die Korrekturdatei zwar für ETRS89 und nicht für WGS84 (Danke Tobias), aber das können wir für die nächsten paar Jahre mal vernachlässigen.

Hier sind die Befehlszeilen die man auf einem Debian GNU/Linux (apt-get install gdal-bin) zur Konvertierung benötigt. Die amtliche Korrekturdatei BETA2007.gsb sollte im aktuellen Pfad liegen.

GK Zone 2 (RLP, NRW):
ogr2ogr -s_srs '+proj=tmerc +lat_0=0 +lon_0=6 +x_0=2500000 +y_0=0 \
+k=1.000000 +ellps=bessel +units=m +nadgrids=./BETA2007.gsb +wktext' \
-t_srs epsg:4326 -f <dateityp> <outfile> <infile>

GK Zone 3 (BW, SHH):
ogr2ogr -s_srs '+proj=tmerc +lat_0=0 +lon_0=9 +x_0=3500000 +y_0=0 \
+k=1.000000 +ellps=bessel +units=m +nadgrids=./BETA2007.gsb +wktext' \
-t_srs epsg:4326 -f <dateityp> <outfile> <infile>

GK Zone 4 (BY):
ogr2ogr -s_srs '+proj=tmerc +lat_0=0 +lon_0=12 +x_0=4500000 +y_0=0 \
+k=1.000000 +ellps=bessel +units=m +nadgrids=./BETA2007.gsb +wktext' \
-t_srs epsg:4326 -f <dateityp> <outfile> <infile>

GK Zone 5 (SN):
ogr2ogr -s_srs '+proj=tmerc +lat_0=0 +lon_0=15 +x_0=5500000 +y_0=0 \
+k=1.000000 +ellps=bessel +units=m +nadgrids=./BETA2007.gsb +wktext' \
-t_srs epsg:4326 -f <dateityp> <outfile> <infile>

Wenn man nach dem gewünschten Dateityp gefragt wird ist das ESRI Shapeformat typischerweise dem Autocad DXF vorzuziehen. Für ersteres gibt es fertige Konvertierungsprogramme ins native OSM Datenformat. Diese sind zwar noch stark verbesserungsfähig, aber dennoch halbwegs brauchbar.