Its probably folly to stare at download numbers too much, but it has become something of a tradition for me to post them here, so here are the results for the 1.7.0 run (which is now superceded by 1.7.1). With over 100,000 downloads in just over 3 months we are doing well! Note that as before these stats only cover the windows standalone installer.
Cumulative downloads for QGIS 1.7.0
Download decay graph for QGIS 1.7.0
Today I attended the IAC conference that was held this week in Cape Town. I could write a long essay about my experience there but I believe the image below will do a better job 
Tim on the Moon
PS. I also touched a moon rock!
We do a lot of django work here at Linfiniti and always use a python virtual environment with each project so that the runtime requirements are isolated to that project. Our typical project looks like this:
projectfolder +-- django_project +-- django_app +-- python +-- bin +-- include +-- lib +-- local
…with an outer folder containing a python virtual environment and a django project with one or more django apps in it.
This works out great…until you need to change the name of your project. You can simply rename everything like this:
newfolder +-- new_django_project +-- django_app +-- python +-- bin +-- include +-- lib +-- local
Using mv and git mv. But the problem is that virtualenvs are not portable – they have the filesytem paths hard coded into them. Usually I just destroy the virtualenv and then recreate it, but in our low bandwidth office that takes quite a while. So today I came up with a formula to rename everything without rebuilding. There are four steps:
1) rename the outer project folder e.g.
mv projectfolder newfolder
2) rename the django project e.g.
git mv django_project new_django_project
3) use the linux ‘rpl’ command to replace all references to the old folder names (run from the root of the newfolder directory:
rpl -R "projectfolder" "newfolder" * rpl -R "django_project" "new_django_project" *
4) remove all old pyc files:
find . -name "*.pyc" -exec rm -rf {} \;
ValueError: bad marshal data (unknown type code)
Last week I did a short interview with Gary Sherman (the founder of the Quantum GIS project). Here is the second (of two) parts for your viewing pleasure. Part 1 is available here.
Andreas and other Non-flash users can get a copy of the .mov file directly here
Looks like they are having some post announcement jitters at apple.com:
Apple.com being evasive....
Glad its not just me who sometimes gets things screwed up….
Last week I did a short interview with Gary Sherman (the founder of the Quantum GIS project). I am busy putting together a nice presentation of the human side of the project and I thought I would start with him. Here is the first part (of two parts) for your viewing pleasure:
Andreas and other Non-flash users can get a copy of the .mov file directly here
So QGIS Server didn’t win the performance shootout at FOSS4G2011…sniff. However there is no need to be alarmed – if you hide QGIS Server behind a tilecache you don’t need to let your users wait around for their maps to render. I hadn’t tried QGIS Server with TileCache and was curious to know how well it would work. I was a bit worried about label clipping and duplication as we don’t yet have any directives you can pass to the server to make it aware that we are tiling. I used TileCache’s metatiling options:
metaTile=True metaBuffer=256
I was very pleased with the results – here is the Norwegian Trekking map I mentioned the other day delivered via TileCache.
[advanced_iframe securitykey="da39a3ee5e6b4b0d3255bfef95601890afd80709" src="http://utno.linfiniti.com/tilecache.html" height="300"]
Note that the cache is not pre-seeded, so if you are the first to visit an AOI of interest, it will take a little longer to render.
Lately I have been delving deeper into the (aweful) world of Microsoft Windows – specifically looking to be able to better support Windows users trying to get to grips with running FOSSGIS on that platform. I have mentioned before on this blog how dependent I am on GDAL for my daily work. GDAL is also one of the pillars of any FOSSGIS stack (especially if you ‘belong to the c-tribe’), so being able to build it yourself on a given platform os always useful. In my case I wanted to include openjpeg V2.0 support in my Windows builds of QGIS (and hence in my windows build of GDAL).
There are several options for building GDAL under windwos yourself (ranked from insane to mindless):
nmake gdal
Simply wait a few minutes and you will have a fresh build of the stable GDAL created in the directory called release-1500 (if you are using MSVC2008). If you want to build GDAL Trunk, I could’t find a download on Tamas’ site that directly supports that so I switched the gdal checkout inside his SDK to use trunk:
cd gdal svn switch https://svn.osgeo.org/gdal/trunk/gdal
If may take a few minutes or longer to do the switch if you are on a slow connection like I have. After that step is done, go back up a level in the directory tree and rebuld GDAL:
cd .. nmake gdal
Once again, go have a cup of fine South African Rooibos Tea while you wait because it may take a few minutes….
When it is finished compiling you will have a shiney new gdal19dev.dll binary build under release-1500-bin and a gdal_i.lib under release-1500/lib. Next you can build QGIS against this binary. To do so, simply follow the standard QGIS INSTALL process for windows, but during the cmake-gui step substitute the following variables (I build GDAL using Tamas’ SDK in c:\dev\cpp\gdal-sdk\):
Replace:
GDAL_INCLUDE_DIR : C:/OSGeo4W/include/ GDAL_LIBRARY : C:/OSGeo4W/lib/gdal_i.lib
With
GDAL_INCLUDE_DIR : C:/dev/cpp/gdal-sdk/release-1500/include GDAL_LIBRARY : C:/dev/cpp/gdal-sdk/release-1500/lib/gdal_i.lib
Then generate and configure and build QGIS as per the documentation. One last thing you need to remember : all the SDK binaries need to be copied into your QGIS runtime directory otherwise it will complain about missing GDAL.
Tamas’ work to create a GDAL SDK for Windows takes away a lot of the pain of developing ‘C-tribe’ applications under Microsoft Windows and is well worth using if you are stuck in MS land. Thanks Tamas for your efforts!
I’ve just been chatting to Aaron Racicot and Pirmin Kalberer on IRC to hear how things went during their workshops at FOSS4G in Denver. Aaron and co-conspirator Greg Corradini have put together a really nice training resource on building python plugins in QGIS which is available at www.qgisworkshop.org. The source of their workshop notes can be forked over at github : https://github.com/cugos/qgisworkshop_org. It sounds like their workshop was well attended and well received so I’ll be looking out for lots of new plugins to arrive in the QGIS plugin repository shortly
Pirmin’s talk on ‘whats new in QGIS’ also generated some buzz on twitter and he got to show off some of the cool power user features in QGIS 1.7. The notes from his talk are available here: www.sourcepole.ch/foss4g/
Valgrind is a nifty too to do code instrumentation – tell you how much time gets spent in different parts of your code tree. KCachegrind is a visualisation tool for valgrind outputs. They are two separate tools that together can provide useful insight into where you code is slow or doing too much work. To set them up on ubuntu is simple:
sudo apt-get install kcachegrind valgrind
After installation, you can lauch QGIS under valgrind like this:
cd /tmp
valgrind --tool=callgrind --dump-instr=yes --simulate-cache=yes \
--collect-jumps=yes /usr/local/bin/qgis
Note that everything you do in QGIS will take 10x longer because of the overhead valgrind places on it. Now load up a project or do something that you feel is taking longer that it should in QGIS. Then exit QGIS. You will be left with a nice big unintelligible xml file in your /tmp directory. Not to worry though, kcachegrind can open it an make sense of it for you. The file will be called something like:
callgrind.out.18364
So to open it with kcachegrind you can simply do:
kcachegrind callgrind.out.18364
KCacheGrind will take a few moments to digest it and then show you something like the screenshot below:
Application call graph for QGIS in KCacheGrind (click for larger image)
The callgraph can be displayed in a number of different ways and provides extremely useful information if you are trying to identify bottlenecks. In the image above, you can see that when QGIS starts, almost 50% of startup time is spent loading python plugins. There are also views that show how many times a given function is called which can provide some helpful hints as to what to optimise.
Valgrind can also be used to detect memory leaks, but unfortunately for GUI lovers, there isn’t a nice GUI environment to explore the leak report data. Don’t let that put you off though – you can get extremely useful feedback from the tool. Here is the syntax to do a leak check on QGIS:
valgrind --tool=memcheck -v --error-limit=no --leak-check=full /usr/local/bin/qgis
When it finishes running QGIS you will get an extremely verbose report (printed to stdout) that lists all the potential issues. Here is a short snippet of what you might see:
==3144== 627 errors in context 151 of 997: ==3144== Invalid read of size 1 ==3144== at 0x4C2A06A: __GI_strcmp (mc_replace_strmem.c:540) ==3144== by 0xA3080BA: _nl_load_locale_from_archive (loadarchive.c:161) ==3144== by 0xA30750D: _nl_find_locale (findlocale.c:107) ==3144== by 0xA306B38: setlocale (setlocale.c:379) ==3144== by 0x680F13F: QgsCoordinateReferenceSystem::setProj4String(QString) (qgscoordinatereferencesystem.cpp:753) ==3144== by 0x680C262: QgsCoordinateReferenceSystem::loadFromDb(QString, QString, QString) (qgscoordinatereferencesystem.cpp:271) ==3144== by 0x680B9B3: QgsCoordinateReferenceSystem::createFromSrsId(long) (qgscoordinatereferencesystem.cpp:213) ==3144== by 0x6776E2B: QgsDistanceArea::setSourceCrs(long) (qgsdistancearea.cpp:64) ==3144== by 0x6776CF9: QgsDistanceArea::QgsDistanceArea() (qgsdistancearea.cpp:45) ==3144== by 0x67C06DE: QgsMapRenderer::QgsMapRenderer() (qgsmaprenderer.cpp:46) ==3144== by 0x71B8D7B: QgsMapCanvas::QgsMapCanvas(QWidget*, char const*) (qgsmapcanvas.cpp:115) ==3144== by 0x5314EC: QgisApp::QgisApp(QSplashScreen*, bool, QWidget*, QFlags<Qt::WindowType>) (qgisapp.cpp:419) ==3144== Address 0x144ed1f1 is 1 bytes inside a block of size 12 free'd ==3144== at 0x4C282ED: free (vg_replace_malloc.c:366) ==3144== by 0xA306BC8: setlocale (setlocale.c:173) ==3144== by 0x680F0B0: QgsCoordinateReferenceSystem::setProj4String(QString) (qgscoordinatereferencesystem.cpp:743) ==3144== by 0x680C262: QgsCoordinateReferenceSystem::loadFromDb(QString, QString, QString) (qgscoordinatereferencesystem.cpp:271) ==3144== by 0x680B9B3: QgsCoordinateReferenceSystem::createFromSrsId(long) (qgscoordinatereferencesystem.cpp:213) ==3144== by 0x6776E2B: QgsDistanceArea::setSourceCrs(long) (qgsdistancearea.cpp:64) ==3144== by 0x6776CF9: QgsDistanceArea::QgsDistanceArea() (qgsdistancearea.cpp:45) ==3144== by 0x67C06DE: QgsMapRenderer::QgsMapRenderer() (qgsmaprenderer.cpp:46) ==3144== by 0x71B8D7B: QgsMapCanvas::QgsMapCanvas(QWidget*, char const*) (qgsmapcanvas.cpp:115) ==3144== by 0x5314EC: QgisApp::QgisApp(QSplashScreen*, bool, QWidget*, QFlags<Qt::WindowType>) (qgisapp.cpp:419) ==3144== by 0x52DFBE: main (main.cpp:607)
Just from starting QGIS and then immediately shutting it down, you will see a rather large list of errors – some of which originate from QGIS itself, and others which originate from some of the underlying libraries we use. The leak detection tool is a hand way to debug when you are getting application crashes and when it seems to be using more memory than you think reasonable. One of these days lets hope that it returns a big fat nothing when we run QGIS on it