CycleStreets is a UK-wide online cycle journey planner and photomap that was originally created for the Cambridge Cycling Campaign. It uses open data from OpenStreetMap and a custom routing engine to plan bike routes. Users can also upload photos to the photomap to document cycling conditions. CycleStreets aims to improve bike routing data through user feedback to provide better routes and route planning across the UK.

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

2. Who are we?
System of two parts:
Cycle journey planner Photomap
Online service Campaigning tool

3. CycleStreets
Simon Nuttall Martin Lucas-Smith
Routemaster Webmaster

4. CycleStreets: history
 Cambridge-only cycle journey planner
 Originally written for Cambridge Cycling Campaign
 Launched June 2006
 Google Map –based
 5,000 lines drawn over
satellite imagery
 Google doesn’t give you
data: just cartography
 50,000 journeys planned
 15,000 photos added

5. CycleStreets: history
 Lots of requests for same thing in other places
around the UK
 Result is CycleStreets
 We are using OpenStreetMap for our data
 We don’t have money for an OS license
 OpenCycleMap cartography
 Went to public beta in March 2009
 26,000 journeys
 No promotion being done yet

6. CycleStreets: UK-wide

7. Journey Planner

8. Namefinder used for locations

9. Gives Fastest, Quietest (+ Shortest)

10. Code
 Not yet open sourced (i.e. public) but will be
 Keen to build a project team
 Routing system is all documented
 The ‘help’ pages contain all the geeky details!
 Community values
 CycleStreets is set up as a UK Not-For-Profit
 Good links with key cycling community people

11. Route feedback goes to OSM contacts

12. Route feedback goes to OSM contacts

13. „Flyover in Google Earth‟ feature

14. Routing documented

15. Routing
 Custom-written engine
 Imports all of Britain
every two days
 Import process
 Takes 5 hours to work through all stages
 ‘Cellular optimisation’ to get speed
 80% of data is discarded or abstracted
 System runs on a single webserver
 – unlike Google ...

16. OpenStreetMap
 People go out with GPS devices
 On bikes, motorbikes and in cars
 When back, they use a tool to
reduce ‘wobblyness’ of the GPS trace lines
 Add information collected on-street
 Road names, pub locations, etc., to each line
 Type of street, e.g. motorway / cycle lane / park path
 Attributes like can cycle / can walk
 ‘Tagging’ the data
 Then upload to OpenStreetMap website
 Anyone can then download and use the data
 Lat/long data plus all the names and tags

17. OpenStreetMap
 Great project
 Crowd-sourced approach
 Like Wikipedia
 Does actually work!
 None of the licensing restrictions of OS data
 The world has moved on – OS needs to catch up
 Current licensing regime simply doesn’t work with
the “mashup” model of the web
 OSM is not complete though
 Southern cities tend to have better coverage so far
 Websites like ours  more incentive to collect data

18. How our routing works: in brief
 We collapse matrix of OSM ‘tags’ into
40 ‘Provision Types’ like motorway
 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:

19. Conversion from OSM

20. Conversion from OSM

21. Provision Types – as used by the engine

22. 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

23. Corrected and new data
 New data becomes routable within a day or so
 We import every few days, so we pick up new info
 What do we do with errors in the data?
 We receive a report “weird bit of this route”
 Report goes to OpenStreetMap people
 They can fix it or request a ground survey
 Our next nightly import happens
 Corrected/new data then routes correctly/better

24. OpenStreetMap
 Lots of different renderings
 We are using OpenCycleMap by Andy Allan
 Cloudmade serves ‘tiles’ which form a static background once a route
has been planned – i.e. we just put this behind a line we have
calculated

25. OpenCycleMap: cartography
 Problem: Map feels
‘too busy’
 Red/green line hidden
by background map
 OpenCycleMap
designed for people to
print/look at, not as a
background layer for a
routing system

26. OpenCycleMap: cartography
 Problem: Map feels
‘too busy’
 Red/green line hidden
by background map
 OpenCycleMap
designed for people to
print/look at, not as a
background layer for a
routing system

27. Why don‟t we use Google Maps?
 Google Maps very popular for websites
 Google doesn’t provide data
 Only gives a cartographic rendering of a map
 A picture of a map is useless for routing!
 We need both the cartography AND the
underlying data
 So Gmaps no good for offering custom routing
 Also we wouldn’t be able to fix the data

28. OSM vs Google Maps
Google often doesn’t have information needed by
cyclists/walkers – park paths, cut-throughs, pubs!
OSM Google maps

29. Photomap: cycling photos on map

30. Photomap: cycling photos on map

31. Upload photo / video / Flickr import

32. Photomap: add categorisation data

33. Photomap: add categorisation data

34. Photomap: categorisation

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

36. Photos en route

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

38. 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
 URL API

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

40. http://cambridge.cyclestreets.net/journey/YorkStreet/DowningPlace/

41. Problems: incomplete data
Data is incomplete in some areas
 (But we have no way of knowing!)
 Or data doesn’t join up or is mis-tagged
 But we know that Cambridge data is so good
so bad routes there are due to the routing
engine not the data
 Creates a chicken-and-egg problem for
rolling out nationally

42. The joining-up problem
 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

43. The joining-up problem
 Cartographic rendering hides data errors

44. Other points
 We avoid subjective data: let the user of
the data (us) decide
 Use of generic data for use by specific
community
 The data we are using is not cycle-specific
 But there is scope for some
 Surface type, cycle lane widths, pinch
points, path quality, would all improve the
routing

45. Please try CycleStreets and give feedback!
 Feedback in areas of the UK you know is
very useful to us
 Using OSM data for real-life routing
means data errors will be found quicker
 All feedback welcome!
 Link to us! Banners on promotion page:

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