CycleStreets main presentation to OSM State of the Map 2009


Published on

CycleStreets main presentation to OSM State of the Map 2009 on 10th July 2009.

Published in: Travel, Sports
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

CycleStreets main presentation to OSM State of the Map 2009

  1. UK-wide bicycle journey planner & photomap Martin Lucas-Smith For Cyclists, By Cyclists @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. journey/YorkStreet/
  31. 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, Twitter: @cyclestreets