CycleStreets is a bicycle journey planner and photomap that began as a route finder for Cambridge, UK. It has expanded to cover all of the UK using OpenStreetMap data. The system includes an online route planner that provides fastest, quietest, and shortest routes. It also has a photomap where users can upload photos and categorize infrastructure issues to improve cycling conditions. CycleStreets aims to continue expanding features like showing elevation contours and integrating local authorities to address infrastructure problems identified through photos.

1. CycleStreets.net
UK-wide bicycle
journey planner & photomap
Martin Lucas-Smith
For Cyclists, By Cyclists www.CycleStreets.net
@CycleStreets

2. CycleStreets
System of two parts:
Cycle journey planner Photomap
Online service Campaigning tool

3. CycleStreets: history
 Cambridge-only
 Originally written for Cambridge Cycling Campaign
 Written by colleague Simon Nuttall
 Launched June 2006
 Google Map –based
 5,000 lines drawn over
satellite imagery
 50,000 journeys planned

4. CycleStreets: history
 Lots of requests for same thing in other places
around the UK
 OSM obvious data source for UK-wide system
 Result is CycleStreets
 Andy’s OpenCycleMap cartography
 Went to public beta in March 2009
 17,000 journeys
 No promotion so far

5. CycleStreets: UK-wide

6. Journey Planner

7. Namefinder used for locations

8. Gives Fastest + Quietest +
Shortest

9. Route feedback goes to OSM
contacts

10. Route feedback goes to OSM
contacts

11. KML and GPX export

12. Code
 Object PHP, with a few libraries used
 Currently MySQL
 Looking at PostGres
 Maybe replace core engine with C++ module?
 Or use another engine: yet to evaluate
 Keen to build a project team
 Code not yet open sourced but will be
 Routing is all documented

13. Routing documented

14. Routing
 Custom-written engine
 Takes Britain.osm around
every two days (nightly soon)
 Import process
 Import takes 5 hours to work through all stages
 ‘Cellular optimisation’ to get speed
 80% of data is discarded or abstracted
 We have one dual-core machine only (at
present)
 Handled 1 plan per second on day of tube strike

15. Scoring
 We collapse matrix of OSM tags into
40 ‘Provision Types’
 Each has:
 Maximum achievable speed (tweaked subjectively)
 Quietness factor (also tweaked subjectively)
 Cycleable? (boolean)
 Walkable? (boolean)
 One-way? (boolean)
 Delay (seconds)
 These then mapped onto each line to create 6
scores (fastest/shortest/quietest + in reverse)
 Conversion table and Provision Types table:

16. Conversion from OSM

17. Conversion from OSM

18. Provision Types – as used by the
engine

19. Cellular optimisation
 Our method of reducing data volume by 80%
A A
9 8
4
9: AC
10 7: AD,BD
D
3
B B
6 6: BC
C C
9
Park: 4 nodes & 7 ways After: 3 nodes & 3 ways

20. Photomap: cycling photos on
map

21. Photomap: cycling photos on
map

22. Upload photo / video / Flickr
import

23. Photomap: add categorisation
data

24. Photomap: add categorisation
data

25. Photomap: categorisation

26. Listings e.g. “All cycle parking
problems in Cambridge”

27. Other features: RSS feed, Galleries, More
photos near here, My journeys, Info about this
area page, Search, XML interface etc.

28. Features about to appear
 Hills/contours
 Will use SRTM (Aster later)
 Local Authority backend to prioritise
problems shown in photos and resolve them
 Tools for getting feedback to OSM people
 Photos within route listings
 In correct direction
 Gives a good idea of journey before riding
 Was in original system
 URL API

29. Photos en route

30. http://cambridge.cyclestreets.net/ journey/YorkStreet/

31. http://cambridge.cyclestreets.net/ journey/YorkStreet/Downing
Place/

32. Routing errors: three classes
1. Data incomplete in area
 (But we have no way of knowing!)
 Or data doesn’t join up or is mis-tagged
2. Conversion errors
 Our simplification from OSM matrix
to 40 provision types
3. Engine errors
 But Cambridge data is so good so bad routes
are due to the engine not the data

33. Problems
 Lack of tools to find where
ways don’t join properly
 Bad joins cause many odd routes
 So we wrote our own ‘snooker ball’ views
 No way to find out how complete an
area is
 Need for data we can query
 So we can manage expectations
 Coping with sheer volume of data!

34. Other points
 Must avoid subjective data
 Some cyclists are fine with busy traffic
 Other cyclists use only quiet streets
 Let the engine/user make the decisions
 Use of generic data for use by specific
community
 Data such as surface, cycle lane widths, pinch
points, path quality, are things which would
improve the routing
 Would it work in other countries?
 Yes, but scoring table would be different
 Cycle tracks: UK vs. Holland: different expectations

35. Please try CycleStreets and give
feedback!
 Feedback in an area you know is very
useful to us
 Use of OSM data for real-life routing
means data errors will be found quicker
 So better for OSM ...
 and better for CycleStreets
 Community aspect very important to us
 Good links with cycling bodies
 All feedback welcome!

36. Martin Lucas-Smith,
www.CycleStreets.net
Twitter: @cyclestreets
info@cyclestreets.net