Today in our our OpenStreetMap interview series we talk with Richard Fairhurst, maker of OpenStreetMap editor Deriviste. Our friends over at Mapillary recently has a great post about the technical details of Deriviste, but in this interview we get into the motivations for the project.

1. Who are you and what do you do? What got you into OpenStreetMap?

I’m an OSM old-stager (OSM user id: Richard)- one of a few people still here from the first months of the project, together with Matt Amos, Jo Walsh, and obviously user #1 himself, Steve Coast. I’d been working on a similar project, called Geowiki, when OSM came along. OSM had better code (and worse cartography), but the real difference was that Steve was doing the whole evangelism thing and going out to sell OSM as this great new project that everyone should contribute to - or be left behind. So it became pretty clear that this was a great star to hitch a wagon to. Since then I’ve done a bunch of things with OSM: coding and maintaining the default editor (Potlatch 1 and 2) for six years, writing a bunch of tools, mapping of course, and serving on the Foundation board.

I work as a freelance developer, cartographer and writer. In between times, I’m developing a cycle mapping and routing site, cycle.travel, which finds great bike routes from OSM data.

2. You are a long time OSMer, and have over the years been active in almost every different facets of the project. Today though we’re talking about your new editor Deriviste. Why did you make this tool? Who is the target audience? How does it differ from the many other editors?

It’s a proof of concept, really, of an idea I’ve had going through my mind for a while.

Essentially most OSM editors - iD, JOSM, Potlatch, Vespucci, Go Map - are full-featured, mature pieces of software. The amount of complexity beneath the surface in iD, for example, is phenomenal. And you can do anything with them: editing with JOSM is pretty much like sitting at the deck of the Starship Enterprise, with equal ability to blat an entire planet out of existence, whereas iD is like sitting at the deck of an equally fast starship but one where the designers engaged some UX consultants. (Potlatch is a slightly cranky old starship where bits keep falling off, but with endearing quirks and a dedicated fanbase…)

And that’s great, but making a better, fuller OSM means broadening the contributor base out beyond wannabe starship pilots. The entry barrier for contributing to OSM should be simply “I have some local knowledge about my area and I want to add it to OSM”. We needn’t force everyone to understand what a node or a relation is before they can add a postbox.

So that’s Deriviste - exploring the concept of a simple editor where you can just click on a postbox/restaurant/bar in a Street View-style image (courtesy of Mapillary) and say “hey, there’s a postbox/restaurant/bar here, add it to OSM”.

It’s the same genre of tool as StreetComplete or the maps.me editing tool. I think there’s a lot more to be done in quick-fire editing scenarios like this - and arguably quick, direct tools like this are the best chance OSM has of matching Google in POI coverage and addressing. I’m really intrigued to see what people come up with.

3. You’ve worked on so many different OSM tools (thanks, BTW!). What are the main learnings along the way? Any advice to anyone looking to develop an editor or OSM tools in general?

“Don’t”?

Seriously… I wouldn’t advise anyone to start on an all-purpose editor unless you have significant funding. It’s such a big task these days. Just writing the code to, say, split a way without breaking data would be days of work. And even though OSM’s API hasn’t had any formal revisions, the expectations and behaviours around OSM data change subtly over time, so you’re setting yourself up for an ongoing maintenance burden. Don’t get me wrong, I would love to see (for example) a native MacOS power-user editor, but short of Apple themselves building one it’s not going to happen.

Instead, write small, focused editing tools. We need more work on conflation tools and other smart ways of dealing with third-party data; more surveying apps rather than full-blown editors. Throw the ideas out there and see what sticks. That would be my advice: find an itch and scratch it.

4. What is the best way to get involved in Deriviste development? Are you looking for contributors?

Absolutely, yes. The first version was something I knocked up over a weekend. Christopher Beddow from Mapillary has now taken it a step further with some really good improvements that make it a more plausible editor. It’s pretty simple JavaScript - just fork it from Github and have a play.

The next step is to get a user-friendly tagging interface in there. The dream scenario would be if that part of iD could be extracted and used as a JavaScript library…

5. What steps could the global OpenStreetMap community take to help support editor makers?

Generally the OSM community is responsive and helpful. Power users could be perhaps sometimes be more forgiving and less demanding. OSM veterans will dream up complex new tagging schemes and loudly insist that the editors are updated to support them. Two years down the line you find that actually no data consumers are making use of the supposed advantages of the new scheme, to which my reaction would be “ok, maybe stop inventing new schemes on a whiteboard” but which the tag enthusiasts take as an opportunity to reinvent the whole thing again, as per https://xkcd.com/927/. highway=path and the various Public Transport schemas are good examples of this.

6. In 2019 OSM will celebrate its 15th birthday, so we are well into the “teenager” stage of the project. But what will it look like when it “grows up”? Where do you think the project will be in 10 years time, both in terms of the geodata comprehensiveness but also the software and infrastructure around the project?

I’m optimistic about POI coverage, less so about addresses. Right now we’re seeing Microsoft and Apple use OSM as their basemap in a few countries and that’s only going to accelerate: in ten years OSM will probably be *the* de facto basemap for Europe, Russia, perhaps Africa and South America. The curve isn’t yet pointing the right way for OSM to be the geocoding solution in these areas. But I may be pleasantly surprised.

Obviously billions of dollars are being pumped into self-driving cars right now, and the geodata to support them. It’ll be interesting to see how OSM fits into this. There’s no technical reason OSM can’t be a platform for what are sometimes called “HD maps”. But thus far, such maps have been professionally surveyed for an entirely commercial imperative, whereas OSM is mostly volunteer-surveyed for altruistic reasons.

So perhaps what we’ll see is increasing divergence between OSM and the auto-focused suppliers, a sharper distinction between “machine maps” and OSM’s “people’s map”. Which isn’t to say OSM need be “uncommercial” - increasingly, people are getting around the world’s wealthiest cities by bike, scooter or on foot, and OSM is unequivocally the best map for this. And as a militant cyclist I’m good with that!

OSM’s infrastructure has kept pace with demand without breaking sweat for over a decade now and I’m sure that will continue. It may need to be slightly firmer with people leeching the tileservers - using them for prototyping is great; using them for your £10/user/month mass-market tracking app really isn’t (yes, it happens). Same goes for firms using OSM without proper attribution, but that’s another story.

But the message is cutting through. I was browsing a cycling subreddit the other day and someone posted “I don’t get why anyone would create yet another walled garden for this kind of data. Just add it to OpenStreetMap so anyone can benefit from it.” Absolutely - and mass-market adoption of OSM means that more and more people should be receptive to this message. The future’s looking good.

Thanks Richard, for our work on Deriviste, and on OSM in general! Great to see more OSM editors, and totally agree that what is needed is not more full-feature editors, but rather more niche tools to draw ever more contributors into the project.

We (and our satisfied customers) will have to disagree that OpenStreetMap isn’t there yet for geocoding. There are many different types of geocoding; for many OSM is more than adequate, for others it is the best datasource at any price. That said, it is certainly true that there remains room for improvement.

In that sense, OpenStreetMap remains the project of a lifetime, and it’s great to have the chance to chat with someone who has been there since the very begining. Keep up the great work, Richard!

happy mapping,

Ed

Please let us know if your community would like to be part of our interview series here on our blog. If you are or know of someone we should interview, please get in touch, we’re always looking to promote people doing interesting things with open geo data.