Monthly Archives: April 2011

The Problem of Cycle Complaining

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.

Transport Map

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!

Transport Map

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.

OpenStreetMap Hack Weekend

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!