Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

CycleStreets presentation to Society of Cartographers


Published on

Presentation given at the Society of Cartographers annual Summer School, 9th September 2009.

Published in: Technology, Business
  • Be the first to comment

CycleStreets presentation to Society of Cartographers

  1. 1. UK-wide cycle journey planner & photomap Martin Lucas-Smith For Cyclists, By Cyclists twitter: @CycleStreets
  2. 2. Who are we? System of two parts: Cycle journey planner Photomap Online service Campaigning tool
  3. 3. CycleStreets Simon Nuttall Martin Lucas-Smith Routemaster Webmaster
  4. 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. 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. 6. CycleStreets: UK-wide
  7. 7. Journey Planner
  8. 8. Namefinder used for locations
  9. 9. Gives Fastest, Quietest (+ Shortest)
  10. 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. 11. Route feedback goes to OSM contacts
  12. 12. Route feedback goes to OSM contacts
  13. 13. „Flyover in Google Earth‟ feature
  14. 14. Routing documented
  15. 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. 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. 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. 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. 19. Conversion from OSM
  20. 20. Conversion from OSM
  21. 21. Provision Types – as used by the engine
  22. 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. 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. 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. 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. 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. 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. 28. OSM vs Google Maps Google often doesn’t have information needed by cyclists/walkers – park paths, cut-throughs, pubs! OSM Google maps
  29. 29. Photomap: cycling photos on map
  30. 30. Photomap: cycling photos on map
  31. 31. Upload photo / video / Flickr import
  32. 32. Photomap: add categorisation data
  33. 33. Photomap: add categorisation data
  34. 34. Photomap: categorisation
  35. 35. Listings e.g. “All cycle parking problems in Cambridge”
  36. 36. Photos en route
  37. 37. Other features: RSS feed, Galleries, More photos near here, My journeys, Info about this area page, Search, XML interface etc.
  38. 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. 39.
  40. 40.
  41. 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. 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. 43. The joining-up problem  Cartographic rendering hides data errors
  44. 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. 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. 46. Martin Lucas-Smith, Twitter: @cyclestreets