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 comments.
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 (http://wiki.openstreetmap.org/wiki/OSMGB, https://www.nottingham.ac.uk/ngi/research/geospatial-science/projects/osm-gbnew.aspx) 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.
cheers Richard _______________________________________________ Talk-GB mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-gb
