If you want some to give out to potential new mapper recruits, you can order the OpenStreetMap leaflets and I’ll post them to you.
If you want some to give out to potential new mapper recruits, you can order the OpenStreetMap leaflets and I’ll post them to you.
I’ve previously discussed using Chef as a great way to manage servers, the key part of the process being writing “cookbooks” to describe what software you want installed, how it should be configured, and what services should be running. But a question that I’ve been asked by a few people is how do I test my cookbooks as I are writing them?
Of course, a simple way to test them is run them on my laptop – which would be great, except that I would end up with all kinds of things installed that I don’t need, and there’s things that I don’t want to repeatedly uninstall just to check my cookbooks install it properly. The second approach is to keep run and re-run them on a server as I go along, but that involves uploading a half-written cookbook to my chef server, running chef-client on the server, seeing if it worked, rinsing and repeating. And I’d have to be brave or foolhardy to do this when the server is in production!
Step forward Vagrant. Vagrant bills itself as a way to:
“Create and configure lightweight, reproducible, and portable development environments.”
but ignore the slogan, that’s not what I use it for. Instead, I treat Vagrant as:
“A command-line interface to test chef cookbooks using virtual machines”
After a few weeks of using chef, I’d started testing cookbooks using VirtualBox to avoid trashing my laptop. But clicking around in the GUI, installing VMs by hand, and running Chef was getting a bit tedious, never mind soaking up disk-space with lots of virtual machine images that I was loathe to delete. With Vagrant, however, things become much more straightforward.
Vagrant creates virtual machines using a simple config file, and lets you specify a local path to your cookbooks, and which recipes you want to run. An example config file looks like:
Vagrant.configure("2") do |config| config.vm.box = "precise64" config.vm.provision :chef_solo do |chef| chef.cookbooks_path = "/home/andy/src/toolkit-chef/cookbooks" chef.add_recipe("toolkit") end config.vm.network :forwarded_port, guest: 80, host: 11180 end
You then run `vagrant up` and it will create the virtual machine from the “precise64” base box, set up networking, shared folders and any other customisations, and run your cookbooks. If, inevitably, your in-development cookbook has a mistake, you can fix it and run `vagrant provision` to re-run Chef. No need to upload cookbooks anywhere or copy them around, and it keeps your development safely separated from your production machines. Other useful commands are `vagrant ssh` to log into the virtual machine (if you need to poke around to figure out if the recipes are doing what you want), `vagrant halt` to shut down the VM when you’re done for the day, and finally `vagrant destroy` to remove the virtual machine entirely. I do this fairly regularly – I’ve got half a dozen Vagrant instances configured for different projects and so often need to free up the disk space – but given I keep the config files then recreating the virtual machine a few months later is no more complex than `vagrant up` and a few minutes wait.
Going back to the original purpose of Vagrant, it’s based around redistributing “boxes” i.e. virtual machines configured in a particular way. I’ve never needed to redistibute a box, but once or twice found myself needing a particular base box that’s not available on vagrantbox.es – for example, testing cookbooks on old versions of Ubuntu. Given my dislike of creating virtual machines manually, I found the Veewee project useful. It takes a config file and installs the OS for you (effectively pressing the keyboard on your behalf during the install) and creates a reusable Vagrant base box. The final piece of the jigsaw is then writing the Veewee config files – step forward Bento, which is a pre-written collection of them. Using all these, you can start with a standard Ubuntu .iso file, convert that into a base box with Veewee, and use that base box in as many Vagrant projects as you like.
Finally, I’ve also used Vagrant purely as a command line for VirtualBox – if I’m messing around with a weekend project and don’t want to mess up my laptop installing random depenedencies, I instead create a minimal Vagrantfile using vagrant init, vagrant up, vagrant ssh, and mess around in the virtual machine – it’s much quicker than installing a fresh VM by hand, and useful even if you aren’t using Chef.
Do you have your own way of testing Chef cookbooks? Or any other tricks or useful projects? If so, let me know!
A little over a year ago I was plugging through setting up another OpenCycleMap server. I knew what needed installing, and I’d done it many times before, but I suspected that there was a better way than having a terminal open in one screen and my trusty installation notes in the other.
Previously I’d taken a copy of my notes, and tried reworking them into something resembling an automated installation script. I got it to the point where I could work through my notes line-by-line, pasting most of them into the terminal and checking the output, with the occasional note requiring actual typing (typically when I was editing configuration files). But to transform the notes into a robust hands-off script would have been a huge amount of work – probably involving far too many calls to sed and grep – and making everything work when it’s re-run or when I change the script a bit would be hard. I suspected that I would be re-inventing a wheel – but I didn’t know which wheel!
The first thing was to figure out some jargon – what’s the name of this particular wheel? Turns out that it’s known as “configuration management“. The main principle is to write code to describe the server setup, rather than running commands. That twigged with me straight away – every time I was adding more software to the OpenCycleMap servers I had this sinking feeling that I’d need to type the same stuff in over and over on different servers – I’d prefer to write some code once, and run that code over and over instead. The code also needs to be idempotent – i.e. it doesn’t matter how many times you run the code, the end result is the same. That’s about the sum of what configuration management entails.
There’s a few open-source options for configuration management, but one in particular caught my eye. Opscode’s Chef is ruby-based, which works for me since I do a fair amount of ruby development and it’s a language that I enjoy working with. And chef is also what the OpenStreetMap sysadmins use to configure their servers, so having people around who use the same system would simply be a bonus.
What started off as a few days effort turned into a massive multi-week project as I learned chef for the first time, and plugged through creating cookbooks for all the components of my server. It was a massive task and took much longer than I’d initially expected, but 18 months on it was clearly worth it – I’d have never been able to run enough servers for all the styles I have now, nor been able to keep up with the upgrades to the software and hardware without it. It’s awesome.
So here’s some tips, for those who have their own servers and are in a similar position to what I was.
I’ll be writing more about developing and testing cookbooks in the future – it’s a whole subject in itself!
I’ve run two OpenStreetMap-themed training courses recently – one for university students, and one for a Local Authority. It’s great helping even more people get started with OpenStreetMap, and as is becoming a bit of theme, I took the opportunity to observe more people getting started with OSM.
Unlike previous outings to UCL, these two sessions had “getting started” notes that I had written – not a click-by-click tutorial, but notes of what things to try in a particular order. This lead to a little embarrassment when some of the seemingly innocuous instructions turned out to be surprisingly hard!
The other things are things I noticed people trying to do, which are perfectly reasonable.
Some maps don’t have a key (I’m guilty of that), but showing an empty panel isn’t helpful. We also found the wrong key appearing beside the different layers, but I can’t reproduce that today. As for the integration with the help centre – I know fine and well how tough it is to integrate separate software products, but users really neither know nor care about it.
And finally some run-of-the-mill observations, mainly of Potlatch 2
One of the things that I want to work on within Potlatch 2 is to (mis)use the sidebar to provide context sensitive help. So I imagine when you’re drawing a way, a little square at the bottom of the sidebar says “You’re drawing a line. Double click to stop drawing, click on another way to create a junction” and so on. I think it’ll be especially useful for the first 10 minutes while people get to grips with things.
But, in saying all this, the feedback I get time and time again is how easy it is to get started with OSM, very rarely do I hear that participants found it hard. We can, however, make it even easier!
A few months ago I started exploring some new technologies from DevelopmentSeed – namely Carto and TileMill. Carto is a CSS-style map description language, similar to Cascadenik, and TileMill is a browser-based application that lets you view maps while you’re designing them.
Initially my efforts were a complete flop – at that point neither Carto nor TileMill had any support for storing the map data in PostGIS, which is a key component of making maps from OSM data. A month later and support was added, so I got cracking – mainly bashing my head against the weirdness of the node package management system NPM. But after a lot of effort and only a little swearing, I got it all working. It’s totally worth it.
Designing maps is hard – both in the amount of complexity in the style rules (there’s lots of colours, widths and so on) and also in the data – every town is different, and the way a map looks varies wildly between town and countryside. So a key thing is to be able to iterate quickly, to make changes and to see how things look in different areas. My previous toolchain – effectively just a modified version of generate_image.py – was a complete pain. To check different areas I’d need to find out the coordinates, pick a zoom level, wait for the image, check it, rinse, lather and repeat. The power of having live-updating maps in TileMill is not to be underestimated!
My first map style produced with Carto and TileMill was the Transport layer. I had originally created the Transport layer using Cascadenik – similar to Carto, it’s a CSS-inspired approach to describing map styling, and much easier than writing individual symbolizers in XML. Carto takes the idea another step forward with sophisticated rules nesting, which I’ve been using more and more in recent months. Since porting the Transport layer, I’ve ported all my other styles to Carto, but more on that some other time. If you’re still creating mapnik style rules by editing XML, I’d advise you check out Carto instead!
At the end of September I took a half-day off from the day job and visited UCL. They were again running an Introduction to OpenStreetMap Mapping Workshop for their new masters students. I went along last year and created some great notes on usability for OSM newbies and did the same again this year. It’s rare for me to be able to watch (and help) so many newbies at the same time.
The main difference between last year and this have been the move to Potlatch 2 as the main editor, so I was especially looking forward to seeing how this performed. Also the students were this year focussing on wheelchair accessibility mapping, which had implications mainly for the detail of our presets compared to this highly-detailed (and relatively unusual) mapping focus.
So here’s the list of notes that I made, in the order that I made them
Some of these things are familiar from previous user testing, some are new, and some will need a bit of discussion to tackle. This is a good opportunity to plug the upcoming Hack Weekend!
Thanks to Dr Patrick Weber for inviting me along.
Getting GDAL and Mapnik to play nice is a complete pain. Now that I’ve managed it, I’ll give you the solution and explain some of the background.
Mapnik has two plugins for reading image files and using them as background in maps. For OpenCycleMap I currently use the “raster” plugin which reads the files directly, and I need to calculate and supply mapnik with all the coordinates for each image. It’s a bit tedious, but when we set up OpenCycleMap a few years ago it was the only way we could get things to work.
Time moves on, and for new projects (and the massive forthcoming OpenCycleMap upgrade) I’m using the “gdal” plugin. This uses the wonderful (but sometimes infuriating) GDAL libraries to read the images and use any geo-information that’s embedded within them. Saves a lot of hassle, and when you’re dealing with tens of thousands of raster images then things like .vrt files are a godsend.
However, gdal has a secret lurking deep within its sourcecode, and it’s all to do with libtiff. libtiff is the library for reading .tif files, which are normally limited to 4Gb in size. There’s a new version of libtiff that deals with giant tiff files that are greater than 4Gb (known as BigTIFF). The version of libtiff that comes with Ubuntu doesn’t have BigTIFF support, so the GDAL packages use their own internal copy of the library. With version 0.8.0 of gdal, a feature was added to throw an error if multiple versions of gdal were found active at the same time (in 0.8.1 this was downgraded to a warning). But for most applications using gdal there’s no big problem – they use the gdal libraries, and hence use the BigTIFF version of libtiff. Meanwhile the standard libtiff (which loads of other things need – trust me, don’t try uninstalling it) is left out of the picture and usused.
The problem is if your application – say, mapnik – compiles against both the system libtiff and gdal-with-BigTiff. If you’re using gdal before 0.8.0 then you might get silent corruption of the output, if you’re using 0.8.0 the mapnik will keep crashing with “ERROR 1: WARNING ! libtiff version mismatch : You’re linking against libtiff 3.X but GDAL has been compiled against libtiff >= 4.0.0”
The trick to this is to avoid using any ubuntu packages of gdal – whether from the ubuntugis PPA repositories or anywhere else – until someone somewhere sorts it all out (probably in some future Ubuntu libtiff will have BigTiff support built-in). In the meantime, grab yourself gdal from source (0.8.0 is fine, btw) and configure it with
This forces gdal to use the system libtiff, and prevents any corruptions or segfaults in applications (like mapnik, which you’ll need to recompile too). It means you don’t get BigTiff support, but hey-ho. But most importantly, you can stop spending all your life juggling gdal versions trying to find which particular combination of packages and PPAs work (hint: none of them do). Thanks to Dane for the final clue – I’ve spent days of my life repeatedly battling this!
I’ve been involved in a small amount of cycle campaigning over the last few years, and one theme comes up over and over. To coin a new phrase – there’s too much “cycle complaining” and not enough “cycle campaigning”. By “cycle complaining” I mean where well-intentioned people just draw attention to problems – poor junction layout, narrow lanes, aggressive driving – without either talking about the good stuff or actually doing anything to help fix the problems they identify. It also gives other cycle campaigners a bad name, since the complainers come across as confrontational and obstructionist, and I only need to read my twitter feed to realise that most times cycling campaigning is mentioned, someone somewhere is complaining about something and concrete suggestions are few and far between.
One example that particularly struck a chord was when I went along to a local campaign group meeting to discuss some new developments our local highways authority (in this case TfL) were making. On one road the proposal was to remove a 1m wide “cycle gap”, and the 3ft steel bollard that was slap bang in the middle of it, and add a proper contraflow cycle lane instead. The campaign group were going to formally object to the improvement since it the resulting lane wasn’t quite wide enough for their liking – despite it clearly being an improvement over what was there already. I was slightly shocked, but on further discussion realised that their position was more of a battle-hardened “cycle complaining” mentality than anything they could rationally justify about the matter at hand. Which got me thinking.
Cycle campaign groups are at a huge disadvantage when discussing plans with local councils. Even when TfL showed us some sneak peaks of the roadway engineering diagrams it was tough for the campaigners to deal with them effectively – they were just printouts, not the actual files; even if they had been CAD files there was nobody there who would be able to examine them or draw the suggested amendments. Ideally a campaign group could respond by saying “here are the places where the proposal doesn’t meet standard X, AND here are our suggestions for improvements we’d like to see”.
This works on a wider scale too. If a council approaches a cycle group to ask where they would like more bike parking installed, the cycle group are unlikely to be able to help much more than just saying “roughly here” (even supposing they maintain a list of sites), rather than “here, have some CAD files for our top ten sites prioritised using density analysis of existing locations” . If a cycle group want to approach a council to convert one-way roads into two-way, they are unlikely to have the traffic simulations to show the five most useful changes. There’s just a huge gulf in tools and technologies available to each side, so when the only way things work is for one side to suggest and the other to accept/refuse, it’s easier to see where so much reactionary complaining comes from.
Enter the guys behind CycleStreets, with their “Helping campaigners campaign” proposal. You can read it for yourself, but in summary is a web-based tool to track, manage and develop solutions to infrastructure problems facing cyclists. While it’s not a panacea for everything I’ve discussed, I think it’s a hugely important step forward for all cycle campaigning groups. Their proposal has been short-listed for the GeoVation awards finals in two weeks’ time and I wish them the best of luck, the funding from that would really kick things off. If you want to show your support then go for it, through your blogs, twitter or however you see fit. Even if they don’t manage the grand prize I hope to see their proposals come to fruition in the near future, especially given their track record of getting things done. I hope to get the opportunity to help their ideas see the light of day – it will be an excellent tool to help turn cycle complaining into the results we want to see.
I recently added a new Transport layer to OpenCycleMap, which some of you will have spotted, and I hope you find interesting. The eagle-eyed among you may even have spotted it as one of the maps on Grant’s curious OpenWhateverMap!
I first visualised bus routes in 2008, and ran a few experiments on railways as part of an experiment in terrain maps just over a year ago. In the mean time I’ve had these ideas on the back burner while I focussed on OpenCycleMap, but recently made some space to put them together into a fully-fledged project. I’m not the first to make a transport map, with öpvnkarte being a famous but no-longer-updated example, but the cartography is something personal that I have my own take on and I enjoy the challenge of creating special-interest maps. So while taking a break from terrain-data processing I put the transport map together. There are certain features of the map that are drawn directly from OpenCycleMap, and there are new developments that I will eventually re-incorporate too.
One of the phrases I started using a few years ago is “render and they will map” – or, in other words, if you are interested in a particular aspect of mapping data being improved then the best way to encourage mappers to improve that is to make it visible and useful. Certainly after I started rendering cycle routes their number in OpenStreetMap increased dramatically, and similarly for the other specialist things in OpenCycleMap. I’m hoping that my world-wide transport layer will encourage similar things in the area of transport data such as adding greater detail to railway stations. In the UK we have patchy levels of detail in bus stops and bus routes; even in London many bus stops have obvious errors in their names. I suspect since they aren’t shown on the current mainstream maps nobody is noticing (and hence fixing) the problems, but, over time, the data should mature and the transport map will therefore improve too.
Another aspect of the OSM data is the high level of detail in the data, which can make some mid-range zoom levels incoherent. I’ve tackled these in two different ways – for example, railway yards and sidings can be distracting when looking at inter-city rail corridors, but the transport map checks for the appropriate tags to hide them where possible. However, the tags aren’t widely used at the moment since they aren’t rendered on other maps, but in this way my map will improve over time as the mapping volunteers add ever greater details. In contrast, I’ve used the station buildings to obscure some of the track details at mid-zoom levels, and gone one step further in simplifying the building geometries at the same time – but losing some of the complex detail of OSM can give better cartographic results. I’ve got further examples and some experiments lined up, and if my talk is accepted I’ll be discussing these at State of the Map Europe later in the year.
For now I’m working on speeding up the rendering – this is the first full-blown map I’ve made with Cascadenik and the performance is surprisingly poor. I’ll be trying to nail down what’s causing this and share that with you soon. In the meantime I continue to work on the cartography and I’m interested in your feedback and questions.
Last weekend we held another Hack Weekend for OpenStreetMap, and I thoroughly enjoyed it from start to finish. Especially the start, which involved sitting outside on a warm spring evening with a cold beer and unwinding!
This was probably one of the largest Hack Weekends that we’ve ran so far – I counted 25 people at one point – and I volunteered to help anyone who was interested in using git, developing Potlatch2 and improving the Rails Port (aka the OpenStreetMap website). As part of this I ran a few short workshops which were surprisingly well attended – I’d expected 2 or 3 people for each one but ended up with 10-15 each instead! I’ll be interested to see what workshops people are interested in for the next Hack Weekend.
When I wasn’t running workshops or helping other people, I was working with Richard Fairhurst on the Potlatch 2.0 release – and this was the point where we made it the default editor on the OpenStreetMap website. It’s been painful for the last few months watching thousands of people learning to use potlatch1, so we’ve just made a big step in making OpenStreetMap easier to get started with. The news made it onto OpenGeoData and even ReadWriteWeb. Development doesn’t stop at 2.0, of course – we’ve got lots of in-progress work on branches (including the long-awaited History dialog that I’ve been working on) and it’ll be good to see them being merged in when they are ready. We also managed to spot a few bugs within the first few hours of the new release!
It was also great to see a bunch of people committing code to projects they’d never worked on before – one of the main reasons we run the weekends. There was lots of work on the Rails Port, including improving the layout on mobile screens and working round bugs with postgres 9. But I’ve no idea what everyone was up to at the far end of the room – it was such a big, busy weekend that I couldn’t keep track! One thing that was prevalent were people picking up git for the first time, and our recent migration to using git for Potlatch2 proved really useful when juggling which features to include in 2.0 and which to leave for further development.
I’m looking forward to the next Hack weekend, which Matt is already organising. If you’re tempted to come help develop OSM and learn something new, you should come along!