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:)
