Tag Archives: OpenStreetMap

Open Source Mapping

OpenStreetMap as Global Infrastructure

Shortly after the SotM US Conference in New York last year I was at a café discussing the future of OpenStreetMap. I was trying to describe my thoughts on how OSM could be perceived in a few years time and coined the phrase “Global Infrastructure” to label my thoughts.

So what do I mean by Global Infrastructure? I was thinking that over the next 5-10 years (bearing in mind OSM is already over 10 years old) that it would no longer be thought of as an interesting open source or open data “project”. It would no longer be something cool or unusual that you find out about, it’ll just be something that exists, that permeates the world and that people and organisations all over the globe will be using and depending on OpenStreetMap without much further thought. Like the PSTN – the global system of telephone networks that means you can call anyone else on the planet – OSM will become Global Infrastructure that powers millions of maps.

We’re already at the stage where OSM is a routine and necessary part of the world. There are hundreds of non-tech organisations using OpenStreetMap every day, from the World Bank to local advocacy groups. I could try to make a list but I’d be here all day and I’d miss hundreds that I don’t even know about. It’s been at least five years since the various interesting uses and users of OpenStreetMap become much bigger than my own knowledge horizon! And this list of users will continue to grow and grow until the absence of OpenStreetMap will become inconceivable.

So beyond a catchy label, what does the concept of Global Infrastructure mean in practice? Well, if nothing else, I use it to guide my thoughts for the OSMF Operations Working Group. We’re being depended on, and no longer by a few thousand hobbyists who can tolerate some rough edges here and there. We’re going to have to keep building and scaling the core OSM services, and yet at the same time fade into the background. In a couple of years, if not already, most people in the OpenStreetMap community won’t even consider how it all works.

There’s a never-ending series of technical challenges that the Operations team faces, some of which I can’t help with directly. So instead I’m keeping my focus on scaling our team’s activities, whether that’s automating our server information pages, systemising our capacity planning, publicising our activities or lowering the barriers to getting more people involved in the work that we do.

2016 will also see us working on new approaches to running our infrastructure. Perhaps not many visible changes, but improved systems for internal event log management and adapting various services to use scalable object storage are two projects that are high on my list – as are the perennial tasks around scaling and ensuring availability of the core database.

The challenge of moving OpenStreetMap beyond being “just a project” and into “Global Infrastructure” goes much wider than the work of the OWG. It will affect every part of the project, from our documentation to our communications to how we self-organise tens of thousands of new contributors. I hope we can set aside anything that we no longer need, keep up our momentum,  and seize the opportunities to build on what we have already achieved.

Some OpenStreetMap Futures

Earlier this year I was invited to give two presentations at the State of the Map US 2015 conference, which was held in the United Nations Headquarters in NYC. What a venue!

As well as an update on the OpenStreetMap Carto project I gave a presentation on what I see as some of the development prospects for OSM over the next few years. Making predictions is hard, especially about the future, etc, but I gave it my best shot.

I think it’ll be interesting to look back in a few years and see how much of what I discuss was prescient, and more interestingly, what topics I missed entirely!

One of the sections that interested me most (and took by far the longest to prepare the slides for) is that looking at who our developers are, and how this changes over time. It’s just before the 18 minute mark in the video if you want to have a look.

Here’s a couple of the charts, which provide food for thought (bear in mind they were produced in June, so the 2015 numbers reflect only the first 6 months of the year):

OSM Developer CohortsOSM Developer Retention ratios

I think the future success of OpenStreetMap depends on improving these figures – we should be aiming to retain at least 40% of our developers after their first year of contributing. We’re clearly getting better at attracting new developers, but what do you think is stopping them from sticking around?

OpenStreetMap Carto Workshop

At State of the Map Europe I ran a workshop about openstreetmap-carto, the stylesheets that power the Standard map layer on OpenStreetMap.org and many hundreds of other websites. The organisers have published the video of the workshop:

Thanks to the organising team for inviting me to run this workshop – it was certainly well received by the audience, and I spent the rest of the day disussing the project with other developers.

I continue to be surprised by two aspects of openstreetmap-carto. One is how much work is involved in making significant changes to the cartography – after a year and a half, to the casual observer not much has happened! But on the other hand, we now have a large group of people who are commenting on the issues and making pull requests. As of today there are 29 people whose contributions show up in the style, with over 700 issues opened and over 220 pull requests made. Much of the work is now done by Paul Norman and Matthijs Melissen who help review pull requests for me and do almost all of the major refactoring. It’s great to have such a good team of people working on this together!

A sneak peak at Thunderforest Lightning maps

Here’s a few screenshots from my new Lightning tile-server:

transport

A refresh of the Transport Style, built on a brand new, state-of-the-art vector tiles backend.

transport-dark

Thunderforest Lightning makes it easy to create custom map styles sharing vector tile backends. Here’s a Dark variant for the Transport layer.

transport-dark-large

Vector tiles bring lots of other benefits – like high-performance retina maps!

Development is going full-steam, and Lightning will be launching soon. Check back for more updates!

Tending the OpenStreetMap Garden

Gardening Blog Photo1

Yesterday I was investigating the OpenStreetMap elevation tag, when I was surprised to find that the third most common value is ‘0.00000000000’! Now I have my suspicions about any value below ten, but here are 13,832 features in OpenStreetMap that have their elevation mapped to within 10 picometres – roughly one sixth of the diameter of a helium atom – of sea level. Seems unlikely, to be blunt.

It could of course be hundreds of hyper-accurate volunteer mappers, but I immediately suspect an import. Given the spurious accuracy and the tendancy to cluster around sea level, I also suspect it’s a broken import where these picometre-accurate readings are more likely to mean “we don’t know” than “exactly at sea level”. Curious, I spent a few minutes using the overpass API and found an example – Almonesson Lake. The NHD prefix on the tags suggests it came from the National Hydrography Dataset and so, as supected, not real people with ultra-accurate micrometres.

But what concerns me most is when I had a quick look at the data layer for that lake – it turns out that there are three separate and overlapping lakes! We have the NHD import from June 2011. We have an “ArcGIS Exporter lake” from October that year, both of which simply ignore the original lake created way back in Feb 2009, almost 5 years ago. There’s no point in having 3 slightly different lakes, and if anyone were to try to fix a misspelling, add an attribute or tweak the outline they would have an unexpectedly difficult task. There is, sadly, a continual stream of imports that are often poorly executed and, worse, rarely revisted and fixed, and this is just one case among many.

Mistakes are made, of course, but it’s clear that data problems like these aren’t being noticed and/or fixed in a reasonable timescale – even just this one small example throws up a score of problems that all need to be addressed. Most of my own editing is now focussed on tending and fixing the data that we already have, rather than adding new information from surveys. And as the size of the OpenStreetMap dataset increases, along with the seemingly perpetual and often troublesome importing of huge numbers of features, OpenStreetMap will need to adjust to the increasing priority for such data-gardening.

Make the hard things simple, and the simple things occasionally surprisingly hard

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!

  • “Use the layer switcher to change the map layers” – the layer switcher is hard to find, even when you’re deliberately looking for it. We’re using the default “+” icon on osm.org – the stacked layers icon that I use on opencyclemap.org might be better. But I think best of all would be some rectangular buttons that are always visible. OpenLayers unfortunately makes this surprisingly hard.
  • “Set your home location” – this could do with some love. People want to type in their postcode, or at least search, in order to move the map around. I also found that about half a dozen people set their home location, and pressed edit, which opens Potlatch (despite the tab being “greyed out”) at somewhere unexpected.
  • “Add the person next to you as a friend” – this was a real head-slap moment when I thought about it. Given two people, sitting side by side, how do they add one another as a friend? If they are lucky, they’ve both set their home location within a hundred metres or so and show up on the list of nearby users. If not, the most straightforward way is to go to their own home page, edit the url, replace their username with the other person’s (case-sensitive) username, and then an “add as friend” link appears among all the other links. There’s so much wrong with this it’s embarrassing – or rather, embarrassing that I put the instructions in without thinking things through! A user search, and a button (rather than a link) to add as a friend, would help for a start.

The other things are things I noticed people trying to do, which are perfectly reasonable.

  • Go to http://www.osm.org. Click help. Admire. Now try to get back to the map, without pressing “Back” or retyping the url.
  • Go to help.openstreetmap.org and click on a username. Now try adding them as a friend.
  • Go to http://www.osm.org. Switch to another map layer. Click the map key. Get a blank tab.

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

  • The p2 save dialog has too much text above the changeset comment field. People get bored reading it, I think because they aren’t expecting an interruption when they press save.
  • It’s still unclear how to start drawing lines and areas. In fact, most people accidentally start drawing lines, and press escape, without realising later on when they want to draw one that they already know how.
  • People want to add icons to points of interest that are already drawn, but as an area. Maybe we should symbolize areas, or even better, prevent icons from being dropped onto existing areas with the same tags.
  • People get mightily confused when the icons on the map don’t match the icons on the sidebar. Maybe we need to rethink how the sidebar icons appear.
  • Creating other points of interest is hard to figure out (i.e. double-click).
  • If you have a large named area, it can be non-obvious (especially when zoomed in) what’s causing the name to appear.
  • There’s useful shortcuts (like J) that don’t appear in the help.
  • There’s lots of useful actions that don’t have any GUI for them, unless you count documenting the keypresses on the 8th tab of the Help menu!
  • You can get to the situation where something hasn’t loaded – either the map, or in some cases map_features, and find yourself in a world of hurt, with no warning.
  • One person couldn’t figure out panning the map around while editing. That’s a combination of no buttons, and that if you (tentatively) click on the background, something happens (start drawing a way), so you learn not to click on the background. Of course, to pan the map you need to mousedown to drag it.
  • I’ve never seen anyone using the Potlatch 2 search button, but people often use the main search bar while editing. That often leads to pain when they click on the results.

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!

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!

Tweak a little here, fix a little there

Another round of updates to the OpenCycleMap cartography was released a week ago, after a few days of local testing, bug investigating and general “technical-debt” payments.

The biggest fix is that I’ve finally tracked down what was causing all kinds of problems with riverbanks. The OpenCycleMap code dates back from long in the past when the riverbank tag was first introduced, and since then it’s greatly expanded and is now heavily used in multipolygons. There was a bug with some code thinking they were linear features and other code treating them as polygons – which used to work fine, but was recently leading to giant triangles lurching across the landscape. Thankfully it turned out not to be a problem with the relation-handling code in osm2pgsql – I had enough of that last year!

Riverbanks gone mad

A major feature of this update is the map now treats points of interest – like shops, pubs and so on – equally, whether they are tagged as nodes or as areas. So in hyper-detailed places where shop nodes are being replaced by building outlines the names and icons will now show up properly. You can see some examples around Peckham where Tom Chance has been hard at work.

Another ‘technical debt’ problem was regarding the “cycle node networks” widely used in the Netherlands and Belgium. When I originally tried rendering the icons at the junctions mapnik blew up – there was a bug with running ShieldSymbolizer on points. Even though this was fixed in mapnik years ago it was only last summer that I started using a new enough version, and it’s taken until now for me to reinstate (and redesign) the icons. But the new circles certainly look nicer than just numbers on the map, so it’s been worth the wait!

Node network

Pedestrian areas are finally drawn properly, and cafés have been added. Bike shops get a new, clearer icon and suburbs and localities are shown. On the attention to detail front, at medium zoom levels national cycle routes are consistently prioritised over regional and local routes, and place names should behave a bit more predictably as you zoom in. And finally street labels won’t bend back on themselves so much and should therefore be easier to read.

Tangled Mess

The server is chugging away at refreshing all the tiles – it’ll take a week or so to get through them all, but you can see the updates filtering through already in the most popular areas.

Many thanks go to MotionX for supporting the project and this round of updates in particular, and to everyone who diligently filed bug reports and (gently) encouraged me to fix them!

Tiger Edited Map resurrected

Recently I’ve been working with MapQuest to rebuild the OpenStreetMap “Tiger Edited Map“. It was publicly released last week (blog, link).

Tiger Edited Map

The original map was created by Matt while he was at CloudMade, but it disappeared not long after we left at the end of last year. This is a from-scratch reimplementation with a few bonus features – it’s updated every few minutes, and the stylesheets are available on GitHub. It uses osm2pgsql with extended attribute information to enable styling by openstreetmap id and date ranges (see the nitty-gritty here) – and a word to the wise: don’t turn on extended attributes for nodes unless you have infinite hard drive space and patience to go with it!

It’s great to see how much progress there’s been this year, and it shows where we need to check for the usual TIGER issues. One of the interesting things for me is that it shows a recognisable editing pattern across the entire US – the major roads have all been edited (most multiple times), as have vast swathes of urban areas – enough that OSM is a distinct enough dataset from TIGER to stand out on its own. Hopefully this will inspire more people to fix up the streets in their own areas and drive the quality of OSM data in the US upwards – step by step. My next plans along these lines is to work on the Rapid Assessment Tool I made some time ago – moving along the QA debate from the origins of the data (I believe we’re often too hung up on the word “TIGER”) and onto assessing how good OSM data is on its own merits.

If anyone has any suggestions for improvements to the style – especially changes to the detection algorithm, or similar ideas for other regions – then I’d love to see either forks from the git sources or even plain old comments below!