Richard's diary

Recent diary entries

Deriviste, an experimental big-screen street-level editor

Posted by Richard on 7 October 2018 in English (English)

Well, you know, it's been a while since I wrote an OSM editor and I found myself missing the experience.[1]

We've pretty much reached the apotheosis of the traditional OSM editor workflow. There isn't any point building another iD, because iD is terrific and does everything that needs to be done. There might be some merit in building a new native power editor for macOS, say, but even that would be a marginal gain and the sort of project best attempted by a company which employs dozens of mappers.

But we certainly haven't reached the limit of OSM editing. The traditional workflow was never designed for integrating third-party datasets, for working with street-level imagery, for surveying on a smartphone, for QA. These activities were unheard of in 2006 when JOSM and Potlatch 1 were first conceived, but are big parts of today's OSM data landscape.

So we should be experimenting with different editor experiences, to see if we can attract wider contributions through presenting an alternative workflow/UI.


Deriviste is a POC for a big-screen street-level editor. POC may equally stand for "proof of concept" or "piece of crap" given that it's really just 300 lines of Javascript I knocked up over a day.

The idea is that the Mapillary street-view takes centre stage, and you can add POIs by just double-clicking on the imagery. My initial use case was small towns in the rural US that are less likely to get an editing community any time soon, but which might get drive-by street-cammers recording imagery that can be used to map POIs.

It isn't really an editor, in that you can't read and modify anything, only write. There's no dupe detection, the presets are a very simple hack on the iD .json file, and it suffers a little from Mapillary JS's capriciousness (sometimes it'll find a lat/lon from clicking on the imagery, sometimes it... won't). It's a POC. I don't have any great ambitions for developing it into something world-beating, but you're welcome to have a play, and if you like, send patches!

Source code:

[1] this may not be true

Debugging Lua scripts/profiles

Posted by Richard on 13 November 2017 in English (English)

osm2pgsql and OSRM can both make use of Lua scripting for tag processing, which in many cases is the best way to make sense of the often conflicting and confusing tag soup in OSM.

Firing up an osm2pgsql/OSRM run each time is, however, not the fastest way of debugging your Lua. So here's a little script that reads your Lua osm2pgsql code, passes it the tags from a way, and returns the result:

# Test osm2pgsql Lua scripting with Ruby

require 'rufus-lua'
require 'overpass_api_ruby'
require 'pp'

# Initialise
overpass =
lua =
lua.eval('require "name_of_my_lua_script"')

# Get tags for the way
way_id = ARGV[0]
response = overpass.query("way(#{way_id}); (._; > ;);out;")
tags = response[:elements].find { |h| h[:type]=='way' }[:tags]
pp tags

# Convert keys from symbols to strings
lua['way'] = Hash[{|(k,v)| [k.to_s,v]}]

# Run Lua code
cmd = "res = {}; filter,tags,poly,roads=filter_tags_way(way,nil); return tags "
pp lua.eval(cmd).to_h

Call it with a way ID like this:

ruby test_lua.rb 35222450

When I do that on my osm2pgsql script, I get:

{:access=>"private", :highway=>"service", :source=>"OS_OpenData_StreetView"}

In other words, the input tags followed by the output tags.

It's fairly easily adaptable for OSRM profiles, or for other functions in your osm2pgsql Lua script, or whatever.

I chose to write it in Ruby because there's a ready-made Overpass gem and I'm generally a bit more comfortable in Ruby than Lua, but you could of course do the whole thing in Lua if you were so inclined.

Cycle node networks and mountain passes

Posted by Richard on 4 October 2017 in English (English)

I've just added support for a couple more tags to's directions and thought it worth mentioning - everyone likes seeing their mapping being used.

First up, now includes 'knooppunten' (cycle node networks) in turn-by-turn directions. These are found in the Netherlands, Belgium and parts of Germany, and help you navigate dense cycle route networks. Here's an example:

Knooppunten example

This picks up rcn_ref= or lcn_ref= tags on nodes. also includes mountain passes in the turn-by-turn directions, for people who like riding somewhere hillier:

Mountain pass example

These are nodes (on highways) tagged natural=saddle or mountain_pass=yes with a name tag. If there's an ele tag, this will be output too.

Live in Western Europe now; will be in North America in the next update in a week or so's time. mapping and routing is updated from OSM roughly once a month. And thanks to everyone who has added knooppunten and mountain pass info to OSM!

Tagging bridge heights from open imagery

Posted by Richard on 7 July 2017 in English (English)

OpenStreetMap is navigable for bikes, on foot, and increasingly so for cars. But one thing we're not yet great at is truck routing.

HGVs, lorries, trucks, whatever you call them, need to get from A to B without breaking either the road or themselves. Which means the map needs to know about height and width restrictions. is a good example of what happens when truck drivers don't have this information (and also can't read):

OSM coverage is good in parts but patchy. Fortunately, the existence of open street-level imagery means it's really easy to map this sort of thing from the comfort of your own armchair. Here's a brief how-to.

Step 1: Identify low bridges

The majority of important restrictions are height restrictions, and the great majority of height restrictions are railway bridges. (There are a few canal aqueducts too, though canal-related restrictions are generally weight restrictions on overbridges.)

So one way to find potential low bridges is to follow a railway on the map, looking for instances where the railway crosses the road on a bridge, rather than the other way round (or a level crossing). Doing this systematically is pretty easy.

Or you can automate it with this clever maxheight map, which looks for exactly this scenario, and highlights the map accordingly. (Github code here.)

Step 2: Find height from imagery

You can use Mapillary or OpenStreetCam as open(-ish) equivalents of Google Street View. Here, for example, is a railway bridge captured on OpenStreetCam.

Personally I like to use Geograph, the long-running UK georeferenced photography project. You can go straight to Geograph itself, but I actually use my own bike route-planner,, which has Geograph photos integrated into it. First you plan a route under the bridge:

plan route

then you click the road, and 'View photos':

see photos

and hey presto, you can see there's a pic showing the height limit signage. Click that to see the full-resolution picture on Geograph.

There's even an (undocumented?) option to show Mapillary views directly in the OSM Maxheight Map:

Step 3: Map it!

Just split the road to create a short way underneath the bridge, and add a maxheight= tag. You can use imperial units without a space (maxheight=12'9") or metric with a space (maxheight=4.5 m).

The results

It's a really simple, straightforward process that makes the map instantly usable for truck routing. I fixed the bridges on the Cotswold Line railway (from Oxford to Worcester) in half an hour, from Geograph and personal knowledge. Greatly improving maxheight coverage in the UK should be doable in weeks rather than years. And, of course, it's a good excuse to get out and survey those places where the height isn't visible from imagery.

Once you've reviewed a whole railway, consider noting your work somewhere so that others can focus on other railways. I've started a wiki page for the UK at .

Potlatch 2.5

Posted by Richard on 25 March 2017 in English (English)

A new version of Potlatch 2 with several improvements and bugfixes:

  • 'New-style' multipolygons are supported, where the tags are placed on the relation rather than the outer way. When you edit such a multipolygon, look at the bottom of the tag editor; you'll see that it's displaying the relation tags rather than the way. If you do want to change the tags on the way, you can choose that from the little dropdown menu there.
  • Pop-up dialogue boxes are now generally resizable.
  • In the Advanced tag view, long tag values now wrap onto multiple lines.
  • The background menu is now usable on smaller screens.
  • A 'Clear all' button on the Bookmarks menu.
  • Shift-drag to zoom into a particular area; shift-click + or - to zoom three levels at a time; and you can now zoom out beyond zoom level 14, in which case no data will be displayed or loaded.
  • Shift-< and > jump 10 nodes at a time along a way.
  • Code now compiles with Apache Flex as well as with (older) Adobe Flex.
  • Plus a bunch of other small fixes.

Potlatch 2 is somewhere between 'active development' and 'maintenance mode': there's no massive new features that I'm planning, but I intend to keep making small improvements to it along these lines, plus extra features as and when I'm doing some mapping and figure out a way to make it easier or quicker to use. OSM is lucky to have such an excellent default editor in iD, which gives P2 the freedom to develop as an efficient and comfortable editor for those who like its way of doing things.

Potlatch 2: bookmarks

Posted by Richard on 5 July 2015 in English (English)

A new little feature for Potlatch 2: you can add a bookmark for your current location, accessible via a new 'Bookmarks' dropdown menu. Use the 'Add' button at the bottom of the menu to add a new one. It works pretty much like every bookmarks menu you've ever used, to be honest.

There's also a new trademark obscure keypress, 'N', which moves to the other end of the currently selected way.

What's your OpenStreetMap story?

Posted by Richard on 28 May 2015 in English (English)

Everyone has their own reason for contributing to OpenStreetMap. Maybe you wanted a better map for your favourite activity - hiking, cycling, skiing. Maybe you were using a site or device with OSM data, and found it lacking. Maybe a friend got you involved. Maybe you believe in our aims as an open project. Or maybe you just thought it was cool.

What was your reason?

I'm giving a talk at State of the Map US in just over a week, in which I'd like to share people's stories as to why they contribute. I'd love to hear yours.

You can post in the comments here, drop me a line at, send me an OSM message, or reply on Twitter. (Anonymity offered if you want!)

Fixing the rural US

Posted by Richard on 28 January 2015 in English (English)

Folks, I've made an exciting discovery. I've stumbled across a country on the map which has 46 million inhabitants but is barely mapped. There appears to have been an import several years ago of a poor-quality dataset, and since then it's languished untouched. There's no indigenous mapping community. Can we help this poor beleaguered country to get a decent map?

Ok, you may have figured where I'm talking about. It's the rural US: 72% of the landmass, 15% of the population. And it needs your help.

The problem

For the past couple of months I've been using idle moments to address a particular, and very widespread issue in OSM's coverage of the rural US - the highway=residential problem.

TIGER data, which forms the bedrock of OSM data in the US, classes roads by CFCC - 'Census Feature Class Code'. By far the most prevalent is A41 - "Local, neighborhood, and rural road, city street, unseparated" - and the TIGER import translated this to highway=residential. This was a good fit in urban areas but covers a multitude of sins in rural areas - everything from good, fast state highways to rutted forest tracks or worse.

The effect is that our map of the rural US shows pretty much everything, save the biggest roads, as a residential road. Tarmac road with sweeping curves and a painted centreline? highway=residential. Gravel road? highway=residential. Forest track? highway=residential. Vague two-foot clearing through the woods where someone perhaps rode 50 years ago? highway=residential. Ploughed field? Etc, etc.

Rural crossroads

This is a typical example from an agricultural area. A good-quality road with centreline, running east-west: a smaller access road, running north: and nothing at all running south. In OSM, this is mapped as a crossroads with highway=residential roads in all four directions. Having the edge of a ploughed field marked as highway=residential doesn't make for a great map, nor does it make for good routing results. "In 100m, turn left." "BUT THAT'S A FRICKING FIELD YOU ACCURSED MACHINE." Sigh.

Rural crossroads

But if you really want some fun, find a less cultivated area - this forest, for example. Look at all those lovely residential roads, tagged exactly the same as a paved city street. Except none of these are paved. A few might be gravel. Many don't really appear to exist at all.

Most of this remains unchanged. In some areas a dedicated user has cleared it up and there've been a few energetic nationwide editors, but it's a massive job. It's pretty much endemic - even just a few miles from San Francisco, a hotbed of OSM activity, you'll find examples.

Perhaps we shouldn't have imported TIGER in these rural areas, but just let the map grow at its own pace. That way, the important roads would have been surveyed, traced, or imported one-by-one, and the thickets of near-impenetrable tracks would probably have never made it in. But we are where we are, and though I'm generally sceptical of "armchairing" far-flung data, we have a big heap of flat-out wrong data and no other strategy to deal with it.

A framework for fixup

So I've been fixing up roughly along these lines, though obviously adjusting for local sensitivities and network considerations:

  • highway=tertiary - paved 2-lane road with painted centreline
  • highway=unclassified - other paved road
  • highway=unclassified, surface=unpaved - unpaved road (at least a car's width, consistent surface)
  • highway=track - unpaved, often doubletrack/singletrack
  • highway=service - access to private house or farm
  • (delete entirely - no trace of trail/road)

Most of this is fixable from imagery. There are also some good datasets: Arnold, Forest Service data, various state data, etc.

In forests 90% of highway=residential should really be tracks. In the plains, the majority is either track or unpaved road, often in grids, but with the occasional paved through route. In Missouri, Tennessee, Kentucky and eastwards you start to see more paved roads.

Personally, my main priority has been to identify and retag paved through routes. Often these can be identified by squinting at the map: a river bridge is a tell-tale indicator, or a road with wide curves, or one linking settlements. Sometimes you just need to look at the aerial imagery and pan around. Of course, it's not just the highway tagging that needs fixing - ref tags and geometries would benefit from attention, too - but you can't do everything, so my chosen challenge has been to get the tagging sane.

I just use plain vanilla Potlatch 2 for fixup, accelerated by assigning common tags to function keys. One day it'd be nice to build something MapRoulette-like to tackle the issue, a bit like HotOrNot (TrackOrCack? HighwayOrLieway? RoadOrFOAD?). But for now a normal editor does fine.

So if you're sitting in your armchair with an itchy OSM finger, resist the temptation to normalise some tags or trace some buildings or whatever else you might usually do. Come and fix up the rural US.

Potlatch 2: quickly move from task to task

Posted by Richard on 20 December 2014 in English (English)

Task-based fixup workflows, such as MapRoulette, To Fix, and the HOT Tasking Manager, have become popular in OSM in recent years, presenting a series of map-improvement tasks for a user to complete.

MapRoulette is wondrous in many ways but has three issues. First, if you're using an online editor, the time taken to open each task is significant - around 3-5s to open a new instance of iD for each task. Second, that online editor has to be iD, so it's not suited for those of us who use P2. Third, the process for creating your own tasks is fairly cumbersome, especially if you're working on a small series of tasks to be completed by one or a few people.

Potlatch 2 now implements a fast, light way of moving through a series of tasks. It's intended for small-scale personal work rather than planet-sized challenges. There's no 'resolve' button - it's just a way of moving between locations efficiently.

It works like this:

Create (or find) a GPX or GeoJSON file containing the locations.

If it's a GPX file, it should contain waypoints. Each one can have a description in a <desc>, <cmt>, or <sym> element.

If it's a GeoJSON file, it should contain Point features. Each one can have a description in the 'name' property (or, failing that, the first property).

Open it in Potlatch 2 with the Tasks button.

Potlatch 2 Tasks button

You can either load a file from disk, or type a URL and click 'Fetch URL'. (For the latter, note that the usual nonsense about needing a crossdomain.xml file at the root of the server applies, sadly.)

Move from task to task with the palette.

Potlatch 2 Tasks palette

The map will centre on the first location. When you want to go onto the next one, click the forward arrow. To go to the previous one, click the back arrow. And that's it.

Try it for yourself using a GPX file of waypoints. If you don't have one to hand, these files from the Adventure Cycling Association of long-distance cycle routes across the US are fun.

I'd be interested to hear of other formats this could support, and further suggestions for improvement; and it would be lovely if authors of other editors were also interested in exploring the idea.

Fix a Forest - experimental tiles from US Forest Service data

Posted by Richard on 11 November 2014 in English (English)

Klamath Forest

I've created a set of tiles from US Forest Service road data for the 155 US National Forests.

This is to help with TIGER fixup in these rural areas, where tracks, trails and entirely non-existent paths are often tagged with a bare "highway=residential". The US Forest Service data is greatly superior to the original TIGER data and has metadata on surface type/quality, but is unsuitable for automatic import into OSM because it would overwrite mappers' existing work in these areas.

You can access the tiles at:

and they're included in the editor-imagery-index list used by P2, iD and Vespucci. The tiles are available up to z19. Use of Potlatch 2's new floating imagery window mode is recommended, so that you can work from both Bing imagery and these tiles at the same time.

You can also explore from the comfort of your browser at, where there's an "Edit this area in OpenStreetMap" link at the bottom right.


  • Surface:
    • yellow outline = paved
    • grey outline = gravel
  • Road type:
    • white with black casing = paved road
    • dashed grey = gravel road suitable for cars
    • dashed brown = dirt road
    • dotted grey = not maintained for cars
  • Maintenance level:
    • grey dots = 4x4 only
    • green dots = usable by cars
    • black dots = moderately comfortable for cars
    • black frequent dots = very comfortable for cars
  • Points of interest:
    • car = roadside park
    • flag = Forest Service station
    • ski = winter recreation area
    • hiker = trailhead
    • campsite = campsite
    • picnic site = picnic site

(There's some degree of overlap, but this is present in the original USFS data.)

When fixing up data, I would suggest the following tags as a minimum:

  • highway=unclassified - paved road
  • highway=unclassified, surface=unpaved/gravel/dirt - unpaved road suitable for cars
  • highway=service - road to isolated dwelling or other building
  • highway=track - unpaved track or road suitable for 4x4s
  • highway=path - narrow linear clearing, too narrow for motor vehicles
  • [delete entirely] - raw TIGER data with no signs of track or path in either imagery or Forest Service tiles

US Forest Service data is public domain so there's no need for further attribution when using this data, though a source= tag is always good practice.

Hope these are helpful, and let me know of any further suggestions.

Potlatch 2: see two sets of imagery at once

Posted by Richard on 20 October 2014 in English (English)

I know. Two new features in the space of a week. Don't get too used to it.

P2 now has a 'Show floating window' checkbox in the Background menu. Select this, and you'll get a second set of imagery in a floating window:

dual imagery

The window follows your main cursor location. So you can have Bing in the main window and Ordnance Survey StreetView in the floating window, or a blank background in the main window and Bing in the floating window, or whatever you like.

There's a "lock zoom" checkbox to stop the floating window zooming in or out - for example, edit at z18 with Bing but see OSSV at z16; or edit at z14 with Bing but have the floating window at z19 for a close-up view. It also respects the "max_zoom" parameter of the editor imagery index.

I coded most of this at a hack weekend a year ago but had never got round to finishing it off. Hope it's useful.

At the same time, P2 now makes a passable fist of rendering multipolygons where the tags are on the relation rather than the outer way (yeuch). It's not perfect and it won't do any of that crazy "advanced multipolygon" stuff. But it'll do until we finally get an area datatype.


Posted by Richard on 14 October 2014 in English (English)


And so is Potlatch... just about. (Insert obvious Flash reference here.)

Potlatch 2's core purposes are (a) being an intermediate-level editor and (b) annoying Germans. It's never going to get major new functionality or important rewrites, but for those of us happily using it, I've always intended to add and fix little things over time.

In the summer it gained support for the editor-imagery-index project, which provides a central list of background imagery suitable for tracing. Today it has a couple of improvements to the long-standing feature where you shift-click away from a way to add a new point (roughly comparable to JOSM's "Improve Way Accuracy" mode, but we don't do modes round here) - which is a really useful technique for TIGER fixup.

I've also added the ability to memorise tag combinations and recall them by a single keypress. Very simple: press shift and a function key to memorise the tags from the current selection. From then on, pressing that function key will add the tags to the selected items. (Those with long memories may remember this is a Potlatch 1 feature, and one I've always meant to add to P2!)

I have a couple of larger features which are 90% coded but were never quite finished, both firmly "intermediate-level" tools. As and when I get the time, I'm hoping to finally finish them off and get them out there. now has OSM-powered bike routing for Western Europe

Posted by Richard on 17 July 2014 in English (English)

I've been working on this for a while and am delighted to be able to unveil it!, my OSM-powered cycling site, now has bike routing for Western Europe: France, the Netherlands, Belgium, Germany, Denmark, Czech Republic, Slovenia, Austria, Italy, Spain, Portugal, the UK and Ireland.

You can try it at

It's built with (patched) OSRM and a complex custom profile. It takes account of elevation, cycle routes, surface quality and more. All routes are fully draggable; you can export to GPX, TCX, and PDF, and save routes if you create an account. The cartography is specially designed for the site.

Here's a ride along the Rhine:

Rhine cycleway

Or if you fancy cycling over Mont Ventoux:

Mont Ventoux

Routing details

If it doesn't follow a route you'd expect it to take, this is usually because surface tags are missing.

For example, here in France, the canalside path is tagged as 'highway=path' with no surface tags. guesses that paths in rural areas have poor quality surfaces, so will try not to route along them. Adding a 'surface=gravel' tag to this path, which the aerial imagery suggests, will make the router like it. (Access tags are also good.)

Miscellaneous notes

  • The tileserver is a little slow - please be gentle!
  • There are occasional inconsistencies in the tiles - old styles that haven't refreshed yet.
  • You can't route between the UK and mainland Europe (there's a big lake in the way. Only Chris Froome is allowed to cycle through the tunnel and look how far it got him)
  • I'm planning on weekly updates but it'll be less often at first.
  • Known issue with highway=trunk, bicycle=yes getting undue prominence.
  • Known issue with fahrradstrassen/fietsstraten not being prioritised.
  • You can switch from miles to km if you create an account and set user preferences. It'll be a bit smarter about defaulting to km for Europe soon, but I need to do a bit of work to enable that. Edit: Now defaults to km for routes in Europe.

Still lots to improve but I hope you like it - and, as ever, thanks to all the mappers who have contributed all the lovely data.

You can post comments/bugs/suggestions here, of course, or on the site forum itself.

What does the path say?

Posted by Richard on 7 November 2013 in English (English)

Cycleway goes whoosh:


Bridleway goes splush:


Footway goes plod:

(urban) urban footway

(rural) rural footway


Any and all of the above. Tarmackytarmackytarmackytar. Grassy grassy grass grass grass. Cobble cobble cobble cobble. Narrow broad narrow broad. Gra-gra-gra-gra-gra-gra-gravel.

Like the moo of a cow, everyone knows what a highway=cycleway means. Yes, there are variations. Lots of them. But in the absence of any other supporting information (like a surface tag), you can make an assumption that the above pic probably won't be too far wrong.

But just like no-one has heard a fox, no-one knows what a highway=path means. It could be anything.

So if you are using highway=path because "it makes it easier for data consumers", it doesn't. It makes it a pain in the arse for data consumers. Right now I am consuming data for a cycling router and highway=path is the bane of my life. When I see "highway=cycleway" it's a safe bet I can route a bike down there, whereas when I see "highway=path; bicycle=yes" then maybe a bike might want to go there, or maybe it's a steep drop over a precipice with a rocky surface but, by some quirk of arcane legislation, bikes are allowed.

For the love of God, if you must use highway=path, please, please, please, please add a surface tag with a commonly-used value.

And then we'll actually know what the path says.

Licence redaction ready to begin

Posted by Richard on 10 July 2012 in English (English)

For those who don't follow the mailing lists or the OSMF blog, a heads-up: the licence redaction will begin this week. Read full details here. There will be no interruption to mapping but you should be aware that there might be changes in your area.

Using vector background layers in Potlatch 2

Posted by Richard on 25 May 2012 in English (English)

The other week Development Seed posted some fresh new data for Jalisco, Mexico, together with instructions on how to use JOSM to get it into OpenStreetMap.

Of course, like most good things, it's much easier and shinier to do it in Potlatch. At which point you might ask "What? You can open .osm files in Potlatch?". Yes, you can, and here's how you do it.

First of all, go to and grab the .osm files. Camino_2011 doesn't download when I try it, but the other two are fine.

Now open Potlatch in the part of Mexico which you want to edit. Here's a handy link.

Go to the "Background" menu, and click "Vector file...":

The background menu

At the bottom, select "OSM", then "File: Open..." to load your .osm file. Do this for each one:

Adding a new layer

You'll see them appear as layers in the list. By default they're shown in 'Potlatch' style, which means they look the same as the rest of the map. You can choose any currently-loaded stylesheet to show them in, but I like to use 'GPS', which displays them as a clear cyan line:

Setting the style

Close the window and go back to the map. Look! Your .osm file is being displayed!

It's being shown as a background layer. In other words, it won't be uploaded next time you save. (Because unthinking imports are bad, right kids?) So to add it to the map, you need to pull it through from the background layer to the main map.

Couldn't be easier. Just alt-click. (Or, if you're using a Linux system that reserves alt for its own nefarious purposes, shift-control-click.)

Et voila

And that really is all there is to it.

Even more awesome

This is just scratching the surface, but there's lots more you can do with vector background layers. Basically, Potlatch does the hard work of making data usable, so you don't have to faff around with a bunch of preprocessing scripts.

You can open from local disc (like this) or fetch from the Internet. You can open .osm, .gpx, .kml or - yes - even shapefiles. (If loading from local disc, put the .shp, .dbf and .shx files in a .zip).

Wrong projection? No problem: P2 can reproject from OSGB or NAD83 (and we're happy to add new projections if needs be).

Data too dense? Just enable the 'Simplify' button and Potlatch will run a Douglas-Peucker line simplification over it, at the strength you've specified in the Options dialogue.

And the cleverest thing of all: MapCSS-based tag transformations. You can supply a stylesheet-like text file that tells Potlatch how to map tags in the source data to OSM standards. Use MapCSS selectors as normal, and the special 'set' and 'delete' instructions to control the output. It's best expressed through an example, so here's one I used for OS VectorMap District data.

Posted by Richard on 25 January 2012 in English (English)

Lots of you will have seen the interest recently in switching from proprietary mapping providers to OpenStreetMap - blog postings by Nestoria and StreetEasy, Wired's article, and so on. We started a Twitter hashtag, #switch2osm, and it's rather taken off.

So I'm delighted to announce the launch of a new site: .

It's a one-stop shop for would-be switchers, showing them how to get started with using and generating OSM tiles; _why_ they might want to; and where to look for more information.

Huge thanks to Harry, Kai, and lots of other people who've helped with this (and especially Matt for the layout). We'll be continuing to refine the site in the forthcoming weeks, but we're happy that it's ready to launch now. So - OSM army, get to it and promote it :)

The trouble with imports (translated)

Posted by Richard on 9 November 2010 in English (English)

Paris mapper Pieren has written an excellent half angry, half regretful diary entry that sums up why unthinking imports are such a curse to OSM. For those that don't speak French, I'm posting a (slightly loose) translation here. Apologies for any errors of translation.

[start quote]

I sadly discovered today that the import of buildings in the 16th arrondissement [district of Paris] has been brutally completed by someone else, by means of the simple import of a file.

I'd been working on this area for several weeks and yes, that might seem too slow for some. But if I was progressing slowly, that’s because I was taking the time to check names and one-way streets on the ground, block by block; to clean up errors (disappeared names and POIs); to add extra information such as traffic lights, missing vélib [cycle hire] points, missing names, barriers, other POIs, addresses. Everything that a semi-automatic import doesn’t do (after all, I could have done the import myself in 15 minutes long ago).

I've already carried out this work for other arrondissements (smaller ones, true) over a long period. You only have to read my OSM diary to see the list. I was three-quarters of the way through working on this arrondissement, but here I'm stopping, disgusted. I shall leave the work of completing the missing information to others, so that the arrondissement may be consistent in a far future (if ever), as well as the other arrondissements of Paris.

I understand that many people work on each area, and it’s better like that. But a tiny bit of co-ordination and investigation, to check what others were doing, would seem to me to be a minimum before embarking on such an import.

[end quote]

Lancashire: where men are men and sheep are scared

Posted by Richard on 26 September 2010 in English (English)

I cycled two-thirds of the Way of the Roses, Sustrans' newest challenge cycle route, last week - from Morecambe, on the west coast, over the Dales to York. (The route continues to Bridlington, but I'm leaving the small bit of unmapped route there for our East Yorkshire correspondent to finish.)

A beautifully scenic route, well chosen, and generously signed - which is just as well, as I was cycling 'blind', the official route map not having turned up. There were some pretty strenuous hills; the worst of the lot was one on an off-piste detour I foolishly took out of Settle, having mapped the official route there already. Actually, the flattest bit (railway paths notwithstanding) was the most boring - the section from Ripon to York, which was fairly featureless countryside. The Ouse crossing on the rickety old Aldwarke Bridge was an experience, though!

It's now mapped as National Route 69, 68, 688 and 65.

Location: Halton-with-Aughton, Lancaster, Lancashire, North West England, England, United Kingdom

National Cycle Network - filling the gaps

Posted by Richard on 8 March 2010 in English (English)

OSM's National Cycle Network coverage is astounding and one of the reasons why everyone loves OpenCycleMap.

With the sun finally emerging once again (yay) we've got the chance to fill some of the gaps and make it really useful. Anna and I went out on Saturday to map a recently opened section of National Route 45 (south of Worcester), and it occurred to me that a few afternoons like that would complete coverage of several high-profile routes.

So I had a look at the map and have identified a few that could be ticked off in an afternoon by nearby mappers. Obviously, some are already in hand - Gregory W cycled most of NCN 1 last year, for example, and I've got a few planned for this year.


  • To complete NCN 3: St Austell to Truro is only partly mapped
  • To complete NCN 4: Tiny little section in north Bristol (near Catbrain!) needs doing


  • To complete Great Central Cycle Ride: missing section through Daventry


  • To complete Lon Teifi: NCN 82 from Cardigan to Fishguard


  • To complete the C2C: Forest section near Keswick - the one gap in our coverage of the NCN's most popular route!
  • To complete the Pennine Cycleway: NCN 68's alternative route via Burnley and the Leeds & Liverpool canal towpath is only partly mapped.
  • The new Way of the Roses*: a coast-to-coast route being launched this year, roughly Morecambe-Settle-Harrogate-York-Bridlington. East of York it's fully mapped. Morecambe to York is not yet fully signed. But it'd be great to have it mapped on OSM at launch.
  • Hadrian's Cycleway (NCN 72) and the Reivers Route (NCN 10) could be completed with a little effort.
  • A few gaps around Sheffield could also be completed fairly easily.

Any takers? Or any other gaps in big routes that people have spotted?

(I posted this to talk-gb too and there's been some discussion already.)

Location: Severn Stoke, Malvern Hills, Worcestershire, West Midlands, England, United Kingdom