A lot of people are scared off from compiling QGIS on Ubuntu thinking the process is too complicated. Actually its pretty easy and you can do it in just a few steps. This weekend I am updating my desktop PC from Ubuntu Jaunty 9.4 to Ubuntu Karmic 9.10 by way of a clean OS install, so I thought I would document the steps needed to get a working QGIS build environment set up in the hopes that others might like to try. Building QGIS from source lets you be an early adopter, trying out the many new cool features that have made their way into subversion (our source code repository), but that are not yet in our mainstream releases.
Installing Dependencies the easy way
Firstly add the ubuntu-gis repository to you apt sources list:
sudo su -c "echo 'deb http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu karmic main' >> /etc/apt/sources.list"
sudo su -c "echo 'deb-src http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu karmic main' >> /etc/apt/sources.list"
Now update your package database:
sudo apt-get update
Now tell Ubuntu to install all build dependencies for QGIS:
sudo apt-get build-dep qgis
Now say ‘Y’ at the prompt and if you are in South Africa wait a few hours while the bits crawl across the wires and deplete your bank account. On my clean system it downloaded around 124mb of packages – pretty much everything you need to build QGIS including the compiler environment, the dependent libraries and their header files etc.
Building QGIS
Building QGIS is well documented in our INSTALL document that comes included but here is the quick version:
First install subversion and cmake console, cmake qt4 gui’s and a few other goodies:
Now we can go on to build QGIS. I am telling CMAKE to install my hand built copy into my home directory (under a subdirectory called apps) to that it does not conflict with with any other copies of QGIS that may be on the system – although you may run into some issues with having a system level install of QIGS and a local copy unless you have tightly managed your library search paths.
cd
mkdir -p dev/cpp
cd dev/cpp
svn co https://svn.osgeo.org/qgis/trunk/qgis
cd qgis
mkdir build
cd build
ccmake -DCMAKE_INSTALL_PREFIX=${HOME}/apps \
-DCMAKE_BUILD_TYPE=Debug -DENABLE_TESTS=True ..
Set your library search path
Note This section was added in an update on 31 Nov 2009
If you want the grass plugin to load in QGIS, you also need to ensure your library path is updated. I do it system wide. First edit /etc/ld.so.conf as root and add this line:
/usr/lib64/grass64/lib/
Now do:
sudo ldconfig
Running QGIS
I add a launcher to my Gnome panel that points to /home/timlinx/apps/bin/qgis. After that your hand build QGIS will be a simple click away. QGIS source code is always under development and we try at all times to ensure the code in SVN will build cleanly. If you want to get the latest updates, simply do:
cd
cd dev/cpp/qgis
svn update
cd build
make install
Assuming you got no error messages during the build, you QGIS launcher icon should now launch the latest build.
I’ve posted this before on my old blog so this is a repeat for those looking to get going with PostGIS in a hurry. This procedure should work on Ubuntu Jaunty or Ubuntu Karmic and possibly earlier versions.
Having done that, you should be able to connect to the database by creating a new postgis connection in QGIS. After that you can start to load data into your spatial database using SPIT (QGIS plugin to import shapefiles into QGIS) or the shp2psql command line tool.
We will be going into feature freeze for QGIS 1.4 soon. There has been so much work going on in QGIS for this release, I thought I would take a moment to show the world what you might expect rendering-wise from the upcoming release.
Symbology-ng
The symbology-ng merge has brought in many improvements to the quality of cartography we can do in QGIS. Take a look at this first screenshot (click on it to get the full image):
In the previous incarnations of QGIS, in order to make this map I would have loaded the polygon layer for country boundaries three times. Each instance would have been given a border with a different thickness, so producing the black, grey, blue outline effect you can see in the image. With the new symbology infrastructure, one can now create a custome polygon symbol type that overpaints the lines numerous times. In the screenshot below you can see how the symbology for my countries was constructed.
The key here is the concept of ‘symbol layers’. Each symbol layer can have its own fill, outline width and colour etc. They are drawn from bottom to top when the feature is rendered. The ‘symbol levels’ button you can see in the background window in the above screenshot lets you dictate if the symbol layers are drawn per feature or for all the features in the view extent. If layers are drawn per feature, then you get something like the screenie below. If you draw symbol layers for all features in the view extent then the bottom most symbol layer is drawn for all features, then the next layer up and so on. This gives you an effect as shown in my first screenshot above.
Labelling
I’ve blogged before about the new labelling engine provided as a plugin for the upcoming 1.4 release. It will be a plugin because it does not yet support data driven label placement and a few other things that we need before it can become the default labelling engine.
In the screenshot above, you can see how neatly the engine places the town labels – none of them overlap and the result is quite a readable, easy on the eye map.
Map Composer
Another area of QGIS that has been receiving a lot of attention is the map composer. It now supports rotating maps, annotations with arrows and shapes and many other improvements. Unfortunately, the new labelling engine is not yet supported in the map composer, and the new symbology framework does not produce a proper legend in composer. We will see if and which of these limitations will be addressed for the 1.4 release. In the screenie below you can see some of the new features at work.
Here is a quick and dirty bash script I wrote to extract all bands from a modis image and save each to a tiff file. The saved bands are named after the sub layer in the original hdf4 file. The script actually generates a second script called batch.sh so you can peek in there to see the undelying gdal_translate commands that are generated.
One day I need to get around to letting QGIS natively support HDF – maybe a good topic for those attending the OSGEO hackfest in NY?
#!/bin/bash
#Set field separator to linefeeds rather than spaces
echo "#!/bin/bash" > batch.sh
chmod +x batch.sh
IFS=$'\n'
for FILE in *.hdf
do
echo $FILE
LAYERS=$(gdalinfo $FILE | grep SUBDATASET | grep NAME | sed 's/[A-Z0-9\_]*=//g')
for LAYER in $LAYERS
do
LAYER=$(echo $LAYER | sed 's/ //g')
NEWFILE=$(echo $LAYER | \
sed 's/ //g' | sed 's/"//g' | sed 's/ //g'| sed 's/:/./g' ).tif
CMD="gdal_translate -of GTiff '${LAYER}' $NEWFILE"
echo $CMD >> batch.sh
done
done
exec ./batch.sh
Currently when you capture vector data in QGIS 1.3, you have some options to control the way attribute data is input. For example you can have a key value list and then the user sees a combo box with a list of possible values for that field. When an item is selected, the key part is saved into the attribute table. There are various other options which make the attribute capture process quite flexible. Fast forward a little now to the recent hackfest we had in Vienna. Juergen Fischer was working on a much more flexible approach for controlling the user interface experience when new attribute data is required. Juergen’s code is in SVN now (the source code repository for QGIS) and this evening I took his new tools for a little test drive.
Getting started
In order to be able to try this out, you need to build the QGIS SVN trunk codebase, or get the nightly build from OSGEO4W. Lets start by creating a simple point layer with two attributes: Name (text) and Age (text).
Capture a couple of points to your new layer using the digitising tools so that we have a little data to play with. You should be presented with the default QGIS generated attribute capture form each time you capture a new point.
Creating your customised form
Ok so now we want to create our own custom form for the attribute data capture phase. To do this you need to have Qt4 Designer installed (only needed for the person who creates the forms). Under ubuntu I installed it like this:
sudo apt-get install qt4-designer
Now you can start designer (under Gnome do : Applications -> Programming -> Qt4 Designer). In the dialog that appears create a new dialog. Now drop a lineedit onto the form and set the line edit’s widget name in the property list for the widget to ‘Name’. Next drop a spinbox onto the form and call it ‘Age’. Now any other elements you might want on the form. Finish your form by clicking anywhere on the form and applying a grid layout to it. Lastly save your form remembering its name and where you saved it. I saved my as /tmp/person.ui for the purposes of this blog post but you will likely want to choose somewhere a little more permanent. Here is what my form looked like in designer when I was done:
Associating the form to your layer
Ready to have some fun? Jump back to QGIS and double click the layer in the legend to access its properties. Click on ‘General’ in the property list on the left and then specify the path to your ui file.
Now save the layer properties and go and start editing and capture a new point. When you do so you should be presented with your custom dialog instead of the generic one that QGIS usually creates. Also if you click on one of your points using the identify tool, you can now bring up the form by right clicking in the identify results window and choosing ‘View Feature Form’ from the context menu. If your layer has editing enabled that context menu will show ‘Edit Feature Form’ rather and you can then adjust the attributes post initial capture.
This is really cool functionality and will be extremely useful in situations where you want to present the form in a very specific way. As a special bonus, if you name a form button after an attribute action, it will cause that action to be launched when the form is presented to the user in QGIS.
From the one more thing dept….
Thats not quite the whole story – with a little python scripting, you can completely customise all the form logic – I will be taking a closer look at that in a future blog post.
A while ago I posted a story about a GeoDjango training course I have been creating. By popular demand here are the course notes I made. Hope they are useful and I will appreciate any suggestions folks can offer to improve them.
Today I went through to the Fujitsu offices in Johannesburg to test out their Futro S450 thin client as an LTSP client. Although they have done large scale thin client roll-outs using the device, they (the SA group) havent tested it as an LTSP client before. As a brief reminder, LTSP stands for Linux Terminal Server Project and is a way to run multiple clients off a single linux server. LTSP sends a system image to the thin client at boot time and provides a log in screen after booting that image. The log in screen logs the user into a GUI desktop session on the server. I am particularly interested in this technology for its application in teaching environments where it can be used to create GIS labs for school and university labs cheaply.
The Fujitsu S450 units cost around R3000 and some change each (contact Fujitsu directly for pricing). So in theory one should be able to set up a 10 desktop lab using LTSP, a high end desktop machine and a hub, 10 thin clients, and some cabling for around R50 000 ZAR. Of course teaching and using GIS has its own special requirements and I was anxious to see how well QGIS would run on their thin clients. I have done some testing before today using XDMCP from a thin client, ssh over X (which LTSP internally uses too). On my FIT-PC systems results could be poor at times with a noticable lag when interacting with GUI elements which my wife found irritating when she tested working from the terminal. However with the S450 unit, the graphics responsiveness was extremely good – it even did compiz wobbly windows! (albeit a little slowly).
One good thing about the unit is that it supports dual screen configurations and each display can be up to 1920×1200 when using a VGA connection (or 2048×1536 using DVI). In our testing we used only a single screen running at 1280×1024. I had set up my laptop (using the procedure listed below) as the LTSP ‘server’ and it was very easily able to host a single client responsively. I suspect I could have attached a few more without too much problems.
You can see I have assigned one computer a specific address based on its mac
address, and the rest will be assigned from a pool of addresses between 20 and 250.
Every time you update your ip address or in general change your ltsp configuration you should do:
sudo ltsp-update-image --arch i386
Make sure your firewall is disabled while testing and then enable the dhcp server required for LTSP clients:
After I had my laptop started, we connected the S450 using a ethernet crossover cable to my laptop (incidently a cheap and convenient way to set up a shared computer and client environment without investing in networking equipment). Booting up the S450 in PXE/Etherboot mode caused it to immediately obtain a DHCP response from my laptop and a few seconds later it had downloaded its boot image from the laptop and was booting. The S450 has no moving parts and is silent running which is a nice benifit. It is also low power, consuming around 14Watts of electricity. After a few seconds, the LDM (LTSP Display Manager) logon screen appeared and when I logged in I landed in the same desktop environment that I usually get when logging in to the laptop.
I fired up QGIS and loaded some layers, did some panning and zooming, layer ordering etc. To be honest it was hard to tell that I was connected over ethernet rather than working locally on my PC – I was very pleased with the performance and general responsiveness I experienced. I did title this blog post a mini review as I only tested the unit for a few hours. Based on that limited usage, I would recommend this unit to anyone looking at thin client solutions with LTSP. There was only really one downside to the device I should mention – the form factor is rather large for a thin client unit and I would have preferred it it was much smaller. That said it comes with a mounting bracket for attaching it to the back of your screen and once it is there I suspect you won’t care.
The unit can be shipped with an embedded linux operating system (called eLux) stored in flash memory, but I would recommend to save the cost of that and get yours with no eLux installed since it is not needed when using LTSP.
I look forward to setting up some FOSSGIS labs using these devices, I think it is going to work out very well! Here are a couple of pics for your viewing pleasure (click for a larger view).
Front view with QGIS running in the thin client environment:
Last night Martin merged his symbology-ng branch into QGIS trunk. This also includes the new labelling engine (currently implemented as a plugin). If you are using the OSGEO4W nightly builds the updated builds should now contain this functionality. I started playing around a bit with labelling, converting some old projects to use the new labelling engine. Here is a little before and after example (click on images to enlarge):
Old:
New:
You can see that using the new version, labels no longer collide and the spacing between them is much easier on the eye.
Now that Martin’s work is in I will start drawing up the roadmap for releasing QGIS 1.4, probably we will aim for an end of December release….
So I’ve just arrived back in Zurich en route to Johannesburg after a thrilling and tiring week hackfesting in Vienna. I’m going to try to summarise some of the major activities and outcomes from the hackfest and will ask others to fill in what I forget in the comments.
First off I would like to say a big thank you to Werner Macho and Dr. Reinfried Mansberger. Dr. Mansberger (Institute of Surveying, Remote Sensing and Land Information (IVFL), Vienna) kindly allowed for the use of facilities (meeting rooms, kitchen, LCD projector, internet access). The facilities were excellent, comfortable and the perfect fit for the twenty or so attendees at the hackfest. Werner Macho organised everything and provided for a hassle free and extremely pleasant hackfest where everything ‘just worked’. As an additional bonus his girlfriend Verena baked up a storm keeping hungry hackers fed with an endless stream of delicious cakes! It should be noted that in three and a half days of hackfesting, the hackfest team consumed more coffee than is normally used in four months at the faculty! Dr. Mansberger kindly ensured that the bill for all that coffee was covered, a gesture which is heartily appreciated by the QGIS team who would otherwise been a bunch of zombies and not managed to hack into the wee hours of the morning!
Secondly let me thank the other attendees. I can honestly say that I would be hard pressed to find a nicer bunch of people to spend 3 days locked up in the same room with. Each person brought a little bit of magic to the meeting making the whole event a real pleasure. Above and beyond that, the attendees were extremely dedicated and enthusiastic QGIS and FOSSGIS users and the conversations I had with the various people I got to spend time with were extremely stimulating. It was also really great having virtual participation in the IRC channel from those who couldnt be there in person – the input from IRC was a great motivator and a good way to keep us on our toes and pick up any issues to commits to the code base.
Lastly, I would like to say a huge thank you for the people and companies who so kindly donated towards our hackfest funding drive. Personally I am self employed and needed to travel half way around the world to attend the hackfest so attending it means a week of no income for me before I even consider the travel costs. Others are in the same boat and the money that was donated was put to really good use in covering the travel expenses of a number of attendees. Not having to worry about travel and accommodation costs on top of losing a week of work time made it a lot easier for me to attend. Also some of the attendees had their presence at the hackfest paid for by their employers so thank you to those employers who made this possible. I do hope you will consider sponsoring our project or making a donation so that we can continue to hold these six monthly get togethers and keep up the momentum of the project.
Summarising the hackfest
With those thanks out of the way I would like to summarise the hackfest a little for you eager folks out there dying to know what we got up to. The hackfest is actually an ‘unmeeting’ in that we arrive with no real agenda except to ‘make QGIS better’ and then organise ourselves on the fly. This works well because it allows us to be dynamic and make the best use of the skills of the people that arrive at the hackfest. That said we did have some broad topic areas on the hackfest wiki page that we planned to cover.
Activities at the hackfest could broadly be broken up into:
- presentations
- group discussions
- break out discussions
- HACKING!
As you can see from my list, by far the most emphasised activity was hands-on work on the code base. Presentations were spread out across the event so that we did not get ‘presentation overload’ and had a chance to digest the contents.
Presentations
Martin Dobias gave the first presentation where he demonstrated the symbology-ng branch and his work on an improved labelling engine. The symbology-ng (next generation) branch is a complete overhaul of the existing symbology infrastructure in order to address some limitations of the current architecture and provide a capability to do high quality cartography within QGIS. These limitations include:
– no capability to do overpainting easily (for example needed to render freeways with a blue outline and white inner line).
– no capability to easily create new renderer types (e.g. based on different approach such as rendering a line composed of SVG symbols)
– no ability to create complex markers and markers that can be shaded (e.g. as continuous colours) beyond the current ‘hard’ markers implemented in QGIS
The symbology-ng implementation also provides a simpler interface for symbol selection and definition.
Martin’s presentation spawned a huge amount of discussion, the outcome of which was that we all voted for Martin to merge his work into trunk as soon as possible. While the symbology-ng implementation still has outstanding issues, it can run alongside the existing symbology implementation and will be turned off by default. This will allow early adopters a chance to play with the technology from within the mainstream QGIS builds. It will also provide a platform for better bug reporting and feedback. We will aim for symbology-ng to be the default symbology rendering engine in the future QGIS 2.0 release. Here are a couple of screenshots of what you can expect when his work is merged into trunk. Note that all of the images below can be clicked on for a larger view.
Martin followed up his symbology-ng presentation with one on a new labelling engine based on PAL. This provides a way to address various deficiencies within the existing QGIS labelling implementation by providing collision detection, label priorities and optimal label placement capabilities. The new labelling engine is also able to make labels follow lines. Martin showed us the labelling engine calculating label placement in various situations and it was indeed impressive. As with the symbology-ng we voted to include the new labelling engine in trunk at Martin’s earliest convenience since it runs as a plugin and will be disabled by default so is a low risk inclusion into the code base. Some screenies of the labelling plugin follow:
Massimo Di Stefano presented the work he has been involved in on the Google Summer of Code project they did to integrate QGIS and ossimPlanet. The integration work uses TCP/IP to update viewpoint position and send raster data over to the ossimPlanet application – where it is viewed on a 3D globe. The globe syncronises to the current QGIS view extents and additional tools provide fine tuned options for postioning the ossimPlanet view. We were all really impressed by their work. Some discussion followed with the general concensus being that we wouldnt be able to ship this as a core part of QGIS due to the number of dependencies it adds and the fact that it does not yet meet ease of use requirements. It is however a great step forward towards providing 3D visualisation capabilities within QGIS and we will work with the developers to make their work available as an add on to QGIS (not part of the standard installation) once the code matures and can be easily packaged.
Alexander Bruy presented work on two projects he has been involved in. In the first they have been building a high quality sample dataset for Ukranian and Russian open source GIS users to use as the basis for tutorials and learning GIS. The dataset has Russian place names etc. and so is more familiar to users than the traditionally English based datasets common in GIS tutorials. The second part of his presentations covered a plugin they have written for recording protected areas and the species that occurr in them. This work will be a great contribution towards and eventual open source EcoGIS implementation (see discussion section below). It was really gratifying to see Alex’s presentation and the great use they are putting QGIS to in the Ukraine. Alex is not the only Russian QGIS hacker – other members of the GIS-Lab group have provided us with some great improvements to QGIS especially in the Image Registration tool.
Martin gave a final presentation where he showed off the work they did with the gismapper project. The project involved building tools to map infrastructure using a car fitted with GPS, spherical camera, compass and a computer fitted with a touch screen and running Ubuntu with QGIS. I posted an earlier video about which I am including again here for your convenience.
I know the video quality isn’t brilliant but hopefully it gives you a feel for this excellent project (which is all open source by the way!). The presentation prompted some discussion about the project and which aspects of it make sense to include into QGIS core. The basic outcome of that discussion is that we will aim to include the GPS communication code and support for a moving GPS cursor on the map canvas into core, and evaluate what else makes sense to incorporate on a case-by-case basis.
Discussions
We had a number of great round table discussions covering a range of topics such as:
- the roadmap to QGIS 2.0,
- improved SVG support in QGIS,
- User Interface issues and consistency
- Adoption of the GIS icon theme
- Managing plugin repositories
- Managing plugins better within the QGIS user interface
- Forming an Ecology and Conservation management subgroup
- Dealing with user expectations
- Documentation
I am going to touch on the user interface related stuff briefly here and invite you to discuss other items in more detail on the QGIS mailing lists. Note that I did provide quite a bit of detail of the individual things people were working on over at the QGIS Blog
The main thing I worked on during the hackfest was a user interface consistency review. On the first day of the hackfest we formed a small team consisting of myself, Milena Nowotarska (Poland), Werner Macho (Austria), and Anita Graser (Austria). The goal of our work is to visit each and every dialog and ensure that it meets our Human Interface Guidelines (HIG). We started discussing the existing HIG and planning what things we were going to cover during the hackfest and beyond to the release of QGIS 2.0. This can be summarised as:
- Ensure all labels on dialogs end with no colons (there was a mish-mash of colon and non-colon based labels throughout the application)
- Ensure that all labels have a leading capital letter and then are written in lower case
- Ensure that all labels have word wrapping enabled
- Ensure that all labels have their buddies set (used for keyboard shortcut jumping between fields)
- Ensure that all forms have an appropriate tab order set
- Try to make all forms fit onto a netbook sized display
- When forms need to be horizontally constrained, use a vertical layout and place the widgets in a toolbox or scrollbox
- Ensure that all dialogs use QDialogButtonBox which gives appropriate locale and operating system rendering of buttons such as close / ok / help.
- Ensure that all dialogs have a context help button and associated context help
- Ensure that icons are consistent througout the user interface
- Ensure that plugins integrate into the userface into native menus and do away with the plugin menu
- Reduce the real estate consumed by toolbars and simplify, simplify, simplify the user interface as much as possible but removing little used elements (especially toolbar icons)
- Cleanup core plugin dialogs for visual consistency
Needless to say this is quite a tall order but we made a good dent by doing an initial pass through the dialogs – you should already be able to see quite a lot of the improvements that we have made in the nightly builds of QGIS or in your local svn checkout. The topic of icon usage within QGIS received quite a bit of attention. The GIS icon theme is great in that it is visually consistent but the feedback I received from most users was that they still preferred the ‘old’ default theme. We discussed why this may be the case, with the concensus being that it was down to:
- people who were already familiar with the old theme had to relearn to recognise the GIS theme icons so its easier just to not switch
- the contrast in the GIS theme icons is quite low so your brain has to do more work to figure out the important elements of each icon
- some of the icons contain concepts that are not recognisable – they dont provide any or enough visual clue as to what their function is (e.g. spatial bookmarks, add vector)
- Some of the icons break with existing user interface memes for example using a hand icon for a pan button and a four direction arrow to indicate that something can be moved.
We would really like to have a consistent icon theme in QGIS 2.0 so Anita has started a revision of the icons to try to address some of these issues. We will use this posting as a starting point for a discussion with Robert Szczepanek (the original authoer of the GIS theme) and try to work with him to pass our changes upstream where he is agreeable. You can see an example of the original icon theme from Robert (first image below) and the updates from Anita (second image below).
I spent quite a lot of time exploring how to improve the user friendliness of the map composer and other dialogs where there are many widgets and options. Below you can see the outcome of some of this work.
Firstly you can see that the widgets are now arranged vertically – removing horizontal widget arrangment means that the form part of the composer (to the right of the split) can occupy a lot less space and degrades gracefully as it narrows. The previous implementation shrank the widgets into non-existence as it got too narrow. You will see that where widgets have labels (e.g. Title), the label is placed above the widget. This allows the label to be longer in translated versions of QGIS without causing the related widget ot disappear into oblivion. Experimentally we are also going to be placing lables into widgets as seen in the spinboxes in the above screenie since it saves vertical space and allows more options to be viewed on the screen at one go.
You will also notice that we are making use of a toolbox (areas marked ‘General’, ‘Legend Items’, and ‘Item Options’) in the above screenie. This allows us to pack a lot more information into a small space and easily access forms in each section. In the next screenie below, you can see what happens when another toolbox item is clicked.
These kind of user interface cleanups will be taking place throughout the application with the goal of completing them for 2.0. – I hope they are a step in the right direction for everyone.
No discussion of the QGIS user interface would be complete without a lengthy and heated debate about splash screens – and of course we had one! Suffice to say that the QGIS developers are getting a little tired of planetary moons as the theme for our releases and come version 2.0 we will be switching to a new theme for our splashscreens….you will have to wait a little to find out what that will be…
Planning for QGIS 2.0
We also had a discussion about the roadmap to version 2.0. QGIS 2.0 will break API compatibility with version 1.0 and thus presents an opportunity for us to overhaul various aspects of the API that we feel are not working well or could otherwise be improved. This will include changes needed for symbology-ng, labelling, better geometry classes and other yet to be determined changes. We will aim for a release of QGIS 1.4 by December 2009. Following that we will do one more feature focussed release, planned for around March or April 2010. After 1.5, we will do only bug fix 1.5.x releases and experimental builds of trunk. 1.5 will be the last API compatible general release and the next official release will be QGIS 2.0 which will require most plugin and third party application writers to update their work to the new API. The experimental releases leading up to version 2.0 will be numbered 1.9.x.
QGIS 2.0 will be released ‘when its ready’ but hopefully some time in the latter half of 2010.
Planning for hackfest #3
We discussed options for our next hackfest – we will aim to hold it in the first half of 2010 in Piza, Italy. Paolo Cavallini will be the local organiser / liason.
General thoughts on hackfest planning
- Plan for large volumes of coffee to be consumed
- If possible have the hackfest venue where attendees can hack, eat and sleep all in the same place.
- Dont plan for too many alternative activities during the hackfest – we are there to hack and can do tourism before or after the hackfest
- Have a good quality webcam and microphone will be useful for ustream sharing
- Arrange the desks in a large circle so that hackers are facing inwards and can talk to each other and have group discussions without leaving their seats
- Have an LCD projector available for ad-hoc presentations.
- Have a flip chart and pens for ad hoc brainstorming
Thats it for now
I’m wrapping up this hackfest for summary, although I have only scratched the surface of what we did – hopefully other attendees will also blog about their activities or leave comments about what they were up to. Also don’t forget to check out the developer profiles link I mentioned above. Now I’m off to catch up on 4 nights of missed sleep….
