[Talk-GB] Open data

Richard Fairhurst richard at systemeD.net
Wed Mar 30 12:43:21 UTC 2016

Rob Nickerson wrote:
> 1. Would there be any cases where merging open data in OSM would reduce
> end user challenges (e.g height restrictions on bridges, traffic
> calming, cafes from the food hygiene data*)?

End-user merging any of those is reasonably easy - these datasets are 
point data, which are always easier than polyline data, but that said I 
do the latter (for traffic levels) with no great trauma. Since 
Government open data is licensed permissively in the UK, licensing 
shouldn't be an issue.

Of course, it would be great if OSM had every cafe in the world, every 
height restriction in the world, and so on. But because data consumers 
can (reasonably easily) use the original source if they want to, we 
don't need to rush it.

Treating such open data as a prompt for surveying, rather than material 
for an automated import, means we can retain what makes OSM good.

But I think we do need to give some thought on how to encourage 
responsible use of such data sources. We have seen (and continue to see) 
poor-quality manual additions from OS OpenData: people adding place 
nodes for isolated farms, people overwriting correct surveyed road 
names, and so on.

So perhaps when the next open data release comes round, we should draw 
up a "users' guide for OSMers" explaining how it maps to OSM data, and 
continuing to revise it based on our ongoing experiences - it might help 
reduce some of the incidents we've seen repeatedly queried in changeset 

> 2. You say your challenges are with the OSM data. What are the top few
> things we could do to reduce this? (Generally rather than map more
> surface tags ;-) )

Generally the challenges are planet-wide rather than UK-specific: in 
fact, UK OSM data is probably easier to work with than most other countries.

Some of the challenges are unavoidable. Differing density of data is 
always going to happen unless we have an even distribution of mappers on 
a km grid. And so on.

If I were to restrict myself to one point, it would be "stop adding 
unnecessary complexity". Make tagging degrade gracefully (see the 
current highway=social_path hoohah) rather than continually reinventing 
things that don't need reinventing. Keep tagging reasonably consistent 
across countries where possible (motorroad=yes is a good example of how 
to do this).

Jez's allusion to the old OSMGB project 
is an interesting one. I agree that there is work to be done in making 
OSM data more consumable; and that we should not expect data downloaded 
from osm.org to be ready prepared for consumers.

Where I part company with OSMGB is in the approach taken. They developed 
an in-house processing workflow, and then made "the 'improved' data 
available via standards based web services". That's a single point of 
failure (the project ended so the data is no longer updated or 
available) and doesn't allow people to adapt the process to their own needs.

What I'm more interested in is making the tools available for 
non-specialists to integrate into their own workflows. This might be as 
simple as better Lua profiles for osm2pgsql and OSRM which are reliably 
able to parse the multiplicity of OSM tags, for example; or similar 
tools for QGIS users.


More information about the Talk-GB mailing list