[Talk-GB] Open data
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