Donate using PayPal

CycleStreets blog

News from CycleStreets

Archive for the ‘Feedback’ Category

CycleStreets feedback triaging/handling system

Sunday, June 17th, 2012

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:

  1. Small data problems such as misconnected ways, surface quality issues, or one-way streets in the wrong direction;
  2. Absence of data in an area, meaning that the network is not sufficiently complete to enable a good route solution to be created;
  3. Engine deficiencies such as over-wiggly routes, going away from the signed network unnecessarily, or poor handling of busy roads;
  4. 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.

What do we do with your feedback?

Monday, July 13th, 2009

Currently we’re finding that about 1% of users who plan a journey are leaving us feedback about their routes.

If the feedback comes directly from the route listing page, then that route is immediately marked as requiring our attention.

We try to look at the route as soon as possible alongside your comments. We then try to understand what is the problem (if any – as we do get quite a few compliments) with the route by classifying it into one of about 15 categories.

The main actions we can take following feedback are:

  1. Check the underlying map data to see if there are missing links. If there are we can inform the (OSM) project. We can usually fix simple things like mis-spelled street names quite quickly. If there is a missing link the fix won’t get into CycleStreets until a few days after a local OSM contributor has responded.
  2. Check how we translate the map data from the OSM project into our routing structures.
  3. Check whether the route published has shortcomings because of features we’ve yet to add to CycleStreets.
  4. Change some of the parameters of our routing engine to find a better route.

The diagnosis, once made, appears in the heading of the original route listing page, sometimes with a link to an alternative route.

If contact details have been provided we then usually write back to you explaining what we have done.

Loads of feedback already

Tuesday, March 31st, 2009

In the first week since CycleStreets has gone live we have received over 100 items of feedback from users.

Most of the replies have been concerned with the quality of the routes produced by the Journey Planner. While some people were highly satisfied with the routes generated there were more complaints about the routes being very strange. Most of the dissatisfaction  seems to be with route planning in hilly areas, and where the base maps we are using are incomplete. Most of the satisfaction with the planned routes lies in the built up areas where the map data is much more complete.

We are responding to this feedback as quickly as we can. We have already made several changes, for instance to improve the searching for addresses and postcodes. We have also got a way of marking routes as having known problems that we acknowledge need fixing.

CycleStreets has ‘grown up’ in Cambridge which is flat and urban, and initially those are the types of route that it will handle best. In Cambridge, where we once had a ban on cycling in the centre of the city, there are a few places where it is quicker to get off your bike and walk a short stretch and remount. This is why on the Journey Planner page there is an option to ‘Include routes requiring a dismount’. Now we have gone national we have discovered that using this setting means that the route planner is too eager to include footpaths in the route listing. We are going to review this option and hopefully make the way it handles it a bit more intelligent so that for instance it will allow one or two dismounts on a route rather than either none or  very many.

Our basemaps are provided by a comminuty project known as In most large urban areas of the country their data is complete and up to date. With a few exceptions, their maps are more likely to be complete where there is a large population and so this means that rural locations are sometimes have rather bare maps. So for the time being we can’t pretend to offer good routing in these areas. Currently we don’t have an automatic way of acknowledging this in our system.

We have had a very warm response to the look of the website and how easy it is to plan a route. We have had to make only a few changes to make sure the system works on as wide a set of computers and operating systems as possible, and we’ve already had several requests for a mobile ‘phone version.  It is also satisfying to have new contributors to our Photomap which will hopefully will transform it from a Cambridge focussed to more national system.

Initial feedback

Monday, March 23rd, 2009

E-mail has been mad today on the first full working day after Friday afternoon’s go live.

Lots of positive feedback has been flowing in but also several comments about unexpected routes being generated.

In particular the Journey Planner does not yet understand hills, so it doesn’t mind sending you up a long hill on a quiet road if that seems a lot quieter than a shorter section of flat road. We have got plans to take account of this, but as the system grew up in Cambridge which is very flat its not found its way into this inital release.

The other main feedback about routing has been that it does unexpected things. This is mostly because the map data for an area is incomplete. We know data for Cambridge is excellent, and also very good for London, but other areas like Oxford are only just getting filled in to the required level of detail by the (OSM) project.

The system is also not yet making full use of all the tags in the OSM data – e.g. where some one-way streets are two -way for cycling. I thought I’d done this but its not picking up some cases so I shall have to look again.

We’ve had some reports saying that the routes the system is generating are exactly what people are already using and that is very pleasing. But we do know that hills, traffic lights and banned turns are all priorities for improving the routing system.

We welcome your feedback, especially to report bugs or give us route feedback.

My comments relate to: *

Your comments: *
URL of page: *
How did you find out about CycleStreets?:
Your name:
Our ref: Please leave blank - anti-spam measure

* Items marked with an asterisk [*] are required fields and must be fully completed.