CycleStreets gets lots of useful feedback, both on details of routes we provide and on system features. The quality of reported route feedback bugs is generally fairly high – users tend to give enough detail to enable the problem to be investigated properly. Simple “The route was problematic here” feedbacks are very rare.
The feedback system we have is basically little changed since we added it – an HTML table of data and a webform that is hooked onto a journey display that users with a ‘feedback’ privilege can see and respond to. There isn’t a proper map based view or lots of other facilities that would be useful.
What we have learned is that feedback needs triaging. Analysis of feedback is a skilled task and can take time to result in an actual resolution.
Accordingly, we’ve found that route problems tend to have one of four main causes:
- Small data problems such as misconnected ways, surface quality issues, or one-way streets in the wrong direction;
- Absence of data in an area, meaning that the network is not sufficiently complete to enable a good route solution to be created;
- Engine deficiencies such as over-wiggly routes, going away from the signed network unnecessarily, or poor handling of busy roads;
- Mistranslation of OSM data to the format used internally by the CycleStreets routing engine.
What this shows is that we don’t want to pollute existing bug display maps with engine-related problems or feature/Photomap feedback. Furthermore, discussion with the reporting user has often been shown to improve the quality of the data repair considerably. So we have long felt that triaging feedback (and a proper means to discuss) it is essential.
Following a lot of refactoring work in recent months to improve problematic parts of the codebase, we’re proposing to develop our feedback system to enable the useful routing data within it to be available to the OSM community more widely, and have drafted a spec:
Cyclestreets feedback triaging/handling system – proposed spec
We welcome any thoughts. Our key aim is to make the data problem feedback we receive much more visible to the OSM community, so that CycleStreets and, moreover, OSM generally, sees improved data.
PS Thanks to Shaun who gave useful feedback on this last year when we first started drafting this.
