WikiProject Belgium/Road completion project
The Belgian community is building tools to make sure that any correction in the official open data road sets is made visible to the mapping community as quickly and as accurately as possible. As a first case, we would work with Wegenregister, from the Flemish government. But because it isn’t just Flanders that has released tools like this, we will try to build something that is easily scalable to any dataset of road centerlines worldwide.
For a more general introduction, have a look at our OpenStreetMap Belgium project page
Our first dataset to use is Wegenregister, a Flemish public agency dataset containing all roads, paths and many driveways, derived from GRB, NGI and CRAB; both current and future that are known to the government. The geometric quality is excellent. Road attributes are not. The name is very reliable, though private roads that are tagged with a name do exist.
Processing code is at https://github.com/osmbe/road-completion
Our first tasks are up. Check the Instructions page to get started!
Preparing & comparing data
Based on Mapbox QA tiles. First turn external data (Wegenregister in this case) into vector tiles. Built to be generic, it will be able to consume data from any road centerline source, such as from artificial vision or processed GPS data.
Comparison code lives here https://github.com/osmbe/road-completion. Current simple set-up: find roads that are probably geometrically missing in OSM.
In a later phase: generate errors by type, with different mapping solutions depending on the type
First focus roads that are both:
- "really missing in OSM"
- "named roads only", which are an easy category with very high quality. This includes some paths, but in general "real" roads.
These roads are communicated to Maproulette, where they are turned into easy microtasks for mappers. The Maproulette process is essential, as it makes it easy to exclude false positives and wrong source data. Just offering maplayers would result in a wrong road being ignored until someone uncritically adds it to OSM.
- Download OpenStreetMap data
- Convert OpenStreetMap data to GeoJSON (keeping only `highway=*`)
- Generate buffer around OpenStreetMap data
- Download source data
- Convert source data to GeoJSON (with optional filtering)
- Convert source data to OpenStreetMap tags
- Generate vector tiles from source data
- Download false positive from [MapRoulette https://maproulette.org/] challenge (optional)
- Generate buffers around MapRoulette data (optional)
- Generate vector tiles from OpenStreetMap (+ MapRoulette) buffers
- Process difference : all the roads from the source data that are not in the OpenStreetMap (+ MapRoulette) buffers
- Update MapRoulette challenge with latest data (optional)
In the future
- find a methodology to also include road types that need local survey
- tagging evaluation (name, road type)
- reverse check: roads that are missing in official road data. This is especially useful for the open data source, but also leads to corrections in OSM.
Services for the data providers
- We will need a list of false positives to be able to remove these from further analysis. Otherwise, the same situation will be reviewed over and over again. If we make a difference between "just difference in drawing style" and "external data (Wegenregister) is wrong", then that same data is usable for external data managers to review their own dataset.
- Our mappers will focus on OSM quality first. But we could offer a package of services to local authorities to have an OSM-based validation of Wegenregister in their community. This would include training for civil servants, setting up specific tasks (Maproulette or Tasking manager) and helping out at a Mapathon where citizens are invited. This package should probably have a certain financial cost.
- Towards an Automated Comparison of OpenStreetMap with Authoritative Road Datasets, which also has a Github repository
- Quality assessment in Canada
Subproject: ensuring all official named roads are mapped at least once
A simplified approach: just check if all the official road names are on the OSM map at least somewhere. This detects both entirely missing roads and miss-spelled OSM roads.
- Select all named roads by community in OSM Flanders
- Select all named roads by community in Wegenregister Flanders
- If a named road in Wegenregister is not available in OSM:
- create a microtask for Maproulette fixing
- create a dataset to feed a mapping layer
Note: sometimes, the name on the street sign might differ from the official road name. In gov logic, the official name is always correct. In OSM logic, the street sign is always correct. To allow for special cases like this, a tag indicating a different official name might be needed.
Offering services for OSM mappers
- Microtasking : Maproulette still has some issues. Here are some how-to's:
- Mappers can now leave a comment about the task (e.g. needs a survey, I looked at it from all angles and still don't get it, etc.). See issue https://github.com/maproulette/maproulette2/issues/314
- Extract GeoJSON of tasks with their current status: http://maproulette.org/api/v2/challenge/[task number here]/tasks?limit=-1
- You can talk to Maproulette with an API. Documentation is here: http://maproulette.org/docs/swagger-ui/index.html?url=/assets/swagger.json
- Fixed and false positives are still visible for all users. They can probably be removed and processed separately using the API.
- As long as there are tasks left in your challenge, you will cycle through tasks within that challenge. More details: https://github.com/maproulette/maproulette2/issues/341
This still needs resolving:
- Mark a task as "too hard" to group them for further analysis. However, not possible between "uh, I don't get it", and "needs a survey", except with Comments. The "Too hard" button is usually used to mark something as "unsolvable".
- You can add a custom background map, which is visible in the Maproulette interface. But it does not get passed on to the editor software. See Issue https://github.com/maproulette/maproulette2/issues/342. We've decided to consider that a feature, not a bug.