Map data is an essential part of my work. Often I find myself looking for raw map data, for instance of the counties of Norway in vector format, typically shape/kml or any other geo-data format. The Norwegian Mapping Authority has of course a lot of high-quality data available, additionally several (or all) governmental institutions in Norway can join a “community” of data creators and share the data among themselves. NTNU, the university I’m at, are fortunate enough to be part of this consortium although we do not contribute to the data.

This all seems to put the necessary foundation for finding fairly standard geodata – it should be easy to find, download and use fairly freely. However, that is not the situation. The system created for accessing the data has so good security that is is in practice inaccessible. When I finally find the right person who has credentials to log in – the system for finding the correct data is packed with forms which do not have any meaningful labels or content in them – at least they are not describing what you’re actually downloading. In my quest for finding the county data for Norway I summed it up in a tweet:

Putting Norway on the map seems to be inhibited by costly licensing and non-existing accessibility (yes, you http://geonorge.no)

As you may imagine, I did not get the data I was looking for. I got some data – namely the municipality data in nice vector format, even with textual names and everything – however not the county they belong to or any other geographic meaningful information.

I admittedly gave up for a day or two. Then I started searching for alternative data – and after a while I found that the US government is far beyond the Norwegian (at least in geodata:). They have released a data set termed vmap0 which is vector data covering the whole world. The data is unfortunately in a bit inaccessible form which I didn’t care to figure out. (not that difficult it seemed, just some converting here and there). I found someone already had converted it to shape format, and nicely split up in continents. So I downloaded the data from the (seemingly) nice folks at GIS-lab.

I only needed the data covering Norway I extracted it and converted to svg (not geo), png+pngw, wgs84+utm32N and wgs84+latlon. The data is not perfect, it has a line across Norway – probably relating to the curvature of the earth – however it is “cutting” some counties and I haven’t figured out how to delete it nicely, however the data is good enough – and far better than nothing!

My frustration has finally ended – through the public domain with gratitudes to the US government! As this resolved some of my issues – I thought I’d try to resolve someone else’s by sharing alike:) You can find the vector data of Norwegian counties (fylker) in different formats and projections in the file here:

http://folk.ntnu.no/alexanno/geodata/NorgeFylker.rar

I hope you enjoy the data – remember to acknowledge GIS-Lab and the US Government if you care for it – my contributions are not necessary to acknowledge :)

Finally the promised follow-up to the post on data modelling in PostGIS. In this post I will cover how I populated the database using a graphical tool called uDig.

uDig is actually a (lightweight) GIS-tool by the same guys which make PostGIS. It supports for editing and analysis of spatial data. I actually don’t know that much about uDig, but it is easy to use, and fulfilled my needs:)

So. What I needed was to draw polygons from a floor plan. The floor plan was in .jpg format, so useless to “import” directly in the database. So I needed to georefer the floor plan “photo” and draw on top of it. Fairly similar to old map making techniques using aerial photographies to make “abstract” maps.

First the georeferencing. The actual coordinate system and extent of the floor plan wasn’t actually that important. It was nice if it started close to (0,0) and had some extent (and of course scaled 1:1).  Convinced (but not certain) that uDig could handle this I set of and tried to add a layer using Layer-Add .. files and selecting the .jpg file. However that resulted in some obscure error saying; “unrecognized service…” Well, off to Google. After some searching I found that for .jpg’s to be added in uDig, they first need to be georeferenced. To me that sounds a bit strange, as one might want to actually do just this in a GIS tool. So after some more searching I discovered that one could “manually” rough-georeference a .jpg using the world-file format, named .jgw – which in essence; locks one coordinate of the image to a geo-coordinate and defines the extent of the pixels on both axis. So I guessed somewhat on the parameters and came up with a .jgw. And add layer in uDig worked like a charm.

Floor map image in uDig

Secondly I needed to connect to my PostGIS database. This is very, very easy, as expected, since the two softwares are made by the same “team”. Just add layer -> PostGIS -> Type in credentials -> Select tables and you’re off:)

Add layers from a PostGIS database

Then it was time to edit/draw/insert data into the PostGIS database. This is fairly intuitive. I found that enabling “snapping” is very useful, and quite good implementation of this feature in uDig also. However, you need to enable it: “window->preferences->tool->edit tool->snap behaviour” Why hide this? Well, maybe not everyone are interested.. Anyway. Here you can set the snap behaviour and radius to whatever suits your need. I choose “all layers” and found it working surprisingly well on drawing the “route graph” which consists of several “connected” lines.

Enabling snapping in uDig

After some editing the data looked somewhat like this:

Inserted data

Of course the entities (i.e. rows in the DB) have other properties other than their geographic extent. And uDig provides an editor to enable direct editing of these properties. However…. This is where you really experience the short-comings of an open-source, “experimental” GIS-tool.. Not all editors are in place, such as BigDecimal. This is OK, as it is a minor thing and not that much of use. However, when the table has constraints, such as “NOT NULL”, then uDig just breaks, no errors, no confirms, no notices of what is going on. A bit disappointing. Additionally when editing, often the data isn’t commited properly to the database, and some error (again no messages) occurs. Resulting in the layer can’t be rendered and you need to remove it from uDig and add it from the database again. Luckily this isn’t a complex process though:) But a bit annoying. I ended up with using PgAdmin for the non-spatial data management and uDig solely for the spatial data. Which worked quite well despite the annoyancies.

My task was fairly non-complex, for larger tasks I wouldn’t rely on uDig – yet. However the simplicity of the tool is attracting! And for easy, lightweight tasks it is perfect:)