You know the drill right? You just made a beautiful map for your boss using QGIS Server. Then he walks into your office and says ‘Kiepie, I need another one in a different CRS’. Your heart drops in your chest and your jaw drops to the desk. You can’t do that using QGIS without publishing a whole new virtual host instance right? Wrong…with a little tweaking, you can publish projects in different CRS’s quite easily from the same apache virtual host. Read on after the break to see how…
The Raster Calculator in QGIS allows you to run any expression on a raster or collection of rasters. While it is definitely useful, exactly how to phrase your expression in order to reclassify a raster is not always clear. Let’s say you have a raster with values between 0 and 255, and you want everything between 100 and 150 set to 1 (and the rest to 0). If you’re like me, your first instinct would be to write an expression that looks somewhat like this:
((raster@1 > 100) AND (raster@1 < 150)) = 1 else = 0
However, this does not work. In fact, in my case it returned the opposite of what I wanted (and without the “else …”, it returned nothing at all). Instead, the proper way to do it turns out to be this:
((raster@1 < 100) OR (raster@1 > 150)) = 0
Whatever is not set to zero by this statement will be set to 1 instead.
Just a quick heads up for those of you using OpenLayers. There seem to have been a lot of problems lately with OpenLayers refusing to redraw its layers when panning, where everything was working before. One possible solution turned up in this thread on OpenLayers Users. The credit for solving the problem is therefore not mine, but I found it so useful that I had to share.
Short version: check that you’re not using OpenLayers.Control.MouseDefaults – it has been deprecated. Instead, use OpenLayers.Control.Navigation – everything else stays the same.
Quick fix for a silly problem that kept me occupied for far too long.
One of the most popular posts on my blog ever is my article about creating GDAL hillshades: ‘A workflow for creating beautiful relief shaded DEMS using GDAL‘. In the techniques outlined in the aforementioned article, colours are assigned across a continuum to and superimposed on top of a hillshaded model. The GDAL tools in QGIS have come along nicely thanks to the work of Guiseppe Sucameli – to the point that you can pretty much do the workflow from the aforementioned article within the QGIS gui environment now (barring some simple text file editing activities).
Sometimes one wants to simply assign arbitrary colours to pixel values of a raster to create a colour map. You can do this with QGIS, but the results are not persistent in the dataset, which I needed because I wanted to create my own colour map and then merge that raster with a shaded relief model. There was one extra requirement I had – I wanted to create my colour map based on polygonal areas at the beginning of my workflow. In this article I describe how I went about creating a hillshaded relief model using a polygonal overlay to define my height classes. I’m also going to show the mis-steps I took to give you a more realistic view of the process of doing such work. Read on for details…
This has been happening to me often lately:
“Rats, this function is broken when I try to do XYZ. But why? I know it worked last week before I started messing around with it. I wasn’t testing the currently broken aspect of it in the interim, though, and I can’t remember what it looked like two weeks ago. When it was working.”
Fear not! Do this:
git checkout some_branch@{"2 weeks ago"}
Yesterday I wrote a new little plugin for QGIS. It is available here: http://plugins.qgis.org/plugins/VectorTransparency/ or if you prefer to get it from GIT then here: https://github.com/timlinux/VectorTransparency. You can also get the plugin by adding the new QGIS official repository (which will be available by default from QGIS 1.8 onwards) to your repository list:
http://plugins.qgis.org/plugins/plugins.xml
The plugin is very simple but saves me hours of work. When I have complex symbologies e.g. a vector layer with many categories and I want to update the transparency level of all symbols, the process is very tedious and involves clicking on each symbol and shifting the transparency slider until I get the correct value. I need to repeat this for each symbol in the layer. My new plugin does all this in one go for you. Here are a couple of screenies that illustrate its use.
The Hoyde2 layer - all symbols are opaque (click for larger image)
Using the VectorTransparency plugin to update transparency of all layers (click for larger image)
The Hoyde2 layer - all symbols are now transparent (click for larger image)
Update: It seems doing this in the symbology tab of QGIS is possible – just select all the symbol classes, right click and choose set transparency from the context menu. I’ll leave my plugin foating around though since it is probably quicker to use when you want to update many layers. Thanks to the folks on #QGIS irc channel for bringing this to my attention.
A nice article by Aslam Parker, Chief Directorate: National Geo-spatial Information, South Africa was published this month in our local GIS/Surveying magazine ‘Position IT‘ that describes the South African CRS. It probably would be of general interest to those trying to understand CRS concepts too. Direct link to the PDF here.
In two previous articles (one one using Eclipse to build QGIS, and the other on using Eclipse as a Django development platform), I mentioned I would delve a little into using the Eclipse environment as a platform for QGIS Plugin Development. In particular we are interested in using Eclipse as a remote debugging platform. What does that mean? It means that Eclipse/PyDev will be able to attach itself to your plugin running withing QGIS and then step through the plugin code line by line, inspect variables and so on. This is incredibly useful as it allows you to break away from the very bad ‘code, launch plugin, hope for the best’ development process to one which is much more rigourous and time effecient. This article describes the process I followed to get everything set up for remote debugging with Eclipse/PyDev effectively. I also throw in a couple of other tips on how to use PyDev as an effective plugin development platform. Read more after the break below….
Recently I needed the function ST_Split for various and sundry reasons, only to discover that I couldn’t use it in my database. The reason was that ST_Split is a new function introduced in Postgis 2.0, and the database was still in 1.5.3. Obviously, time for an upgrade.
I began following the upgrade process, which I’ll summarize below.
So we use the super awesome South to manage schema changes when we change our django models. Basically South works in the background to make sure that your database is always in a consistent state with your models. Recently I have been adding South to a project and deploying these updates to my server. One of the tricky things I found is letting South know when your database is already in a consistent state and that it should mark its migration history as being up to date. Today I had a few moments to properly figure out how to do this. You can substitute RTFM for ‘figure out’ as you prefer. The trick is to do a fake migration like this:
python manage.py migrate someapp 0001 --fake
With 0001 being the migration state that you want to tell South that you are now at. This is documented here. One other noteworthy tip is that in the course of our updates, we are switching from Django 1.2.1 to 1.3.x and South gave me some pretty confusing error messages like this:
Traceback (most recent call last):
File "manage.py", line 11, in <module>
execute_manager(settings)
File "/home/web/sac/python/lib/python2.7/site-packages/django/core/management/__init__.py", line 438, in execute_manager
utility.execute()
File "/home/web/sac/python/lib/python2.7/site-packages/django/core/management/__init__.py", line 379, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/web/sac/python/lib/python2.7/site-packages/django/core/management/base.py", line 191, in run_from_argv
self.execute(*args, **options.__dict__)
File "/home/web/sac/python/lib/python2.7/site-packages/django/core/management/base.py", line 220, in execute
output = self.handle(*args, **options)
File "/home/web/sac/python/lib/python2.7/site-packages/south/management/commands/schemamigration.py", line 83, in handle
if migrations.app_label() not in getattr(last_migration.migration_class(), "complete_apps", []):
File "/home/web/sac/python/lib/python2.7/site-packages/south/migration/base.py", line 307, in migration_class
return self.migration().Migration
AttributeError: 'module' object has no attribute 'Migration'
I did’t really find any useful help on google, but eventually resolved the issue by removing the .pyc files from the app/migrations/ folder and then everything just worked like magic.