Transport mapping: The OSM Route

  • 2,002 views
Uploaded on

Society of Cartography Conference 2011 talk about geo mobile app development, open transport data and OpenStreetMap

Society of Cartography Conference 2011 talk about geo mobile app development, open transport data and OpenStreetMap

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,002
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
5
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • I've got four different things I want to talk about. I want to talk about Open Data, and specifically Open Transport Data. And I want to talk about the work I've been doing at placr.co.uk, and finally my hobby and passion OpenStreetMap. Lots to cover, but fortunately they're all wonderfully interelated, so it's really just one big topic.
  • So there's this open data revoluntion going on, and I believe it can be a revolution. Data owners are resistant. I think there's two main reasons. Either they are very directly protecting revenue they get from selling data, or they're just scared the data (or even just the manner in which they publish it) will make them look bad. But happly Open Data is a political hot topic at the moment so data owners are coming under pressure. One of the main political arguments for open data, is about transparency and accountability, which we see with datasets such as local council expenses. This is important of course, but I think there's something quite negative about it. It's almost like we're saying “give us your data so we can sit here and more easily complain and criticise” The second reason is to fuel innovation
  • Innovations can be be enabled by open data, but there's an aweful lot of datasets being published because of this new political pressure. Some of them are quite uninspiring. Some are just a front onto a set of less open more high value data. The more exciting innovations, really useful applications which change our lives for the better, are only enabled by what you might call “high value datasets”. Transport is an area with great potential for really useful apps. 51 billion passenger kilometers by train in a year. This a big number, although contrast it with 700 billion passenger kilometers by car. We can help change that. I like to think of it on a more personal level. How much of my life have I spent on trains and buses? If we can build apps that make this even a little bit better/easie, then that's something quite powerful and transformative.
  • The reason we can talk about innovation coming from small companies and even bedroom coders, is of course that's it's very easy to put out applications on the web, and more recently apps for mobile phones. It's easy & cheap. This is deceptive though. It's not that easy or cheap, but there are no up front costs, and people who have the the skills and the time to do it, can produce wonderful results on zero budget. The best results come from people with technical skills but also design flair and a deep understanding of user experience. Obviously for transport, if we can easily develop for mobile platforms, this lets us put our app in the hands of travellers while they are travelling. There's thriving community of developers and this all of this drives demand for useful data.
  • I'm going to show you a mobile web app which we've been developing called placr.mobi Let me say straight away, when it comes to talented app design and useability, I like to to think we're somewhere on that spectrum, but I appreciate that this isn't the greatest ever showcase. We're very much following the “release early release often approach“, and there's quite a few glitches we still need iron out in this app, but it is available to have a play with at http://placr.mobi and interestingly one of the test areas we have data for is here in Plymouth!
  • But actually we're not just in the game of trying build a great consumer oriented mobile app. It's one of three areas we're looking at. We want to help other developers create mobile apps and web services for Transport. Some transport datasets are very awkward to work with in their raw form (I'll explain more in a moment) We are offering a transport api which makes life easier for developers. We're also talking to transport operators and they are showing some interest in the analytics we can do with their data, and the channel we have to developers and end users. So we're looking at building apps, and it might allow us to earn some revenue with ads or through charging for a premium version. But it also feeds into the other two strands.
  • While I'm explaining placr, let's take a further step back. Placr is an “open data services company”. We work with organisations who need help with releasing datasets. We're working with Pearson, the global publishing firm, reformatting their data, developing RESTful APIs, to help them engage the developer community (developer.pearson.com) Along the way we also do a lot of open data campaigning, particularly my boss Professor Jonathan Raper who campaigns for open data in the highest levels of govornment.
  • For now though we need to work with what we've got. These datasets were particularly of interest to us. TfL (Transport For London) has departure board displays as HTML, which we've scraped, but we were also one of the first people to test out their new API for this. We've parsed their TransXchange files for static timetables. There's a brand new countdown display for live bus information released this past week. We will be taking a look at that. NaPTAN is a dataset of bus stops with locations. This is useful alongside other bus data. We'd love to do more with train timetable/live data, but this is an area where we're actively campaigning, because the data isn't open. ATOC are the open data villains here.
  • So the first dataset I mentioned was departures. This is data as displayed on the dot matrix screens on tube platforms, showing a train coming in 4 minutes and another train in 7 minutes for example. We take this and run statistical calculations and averaging to let us create performance stats and displays. You can see these at http://tube-radar.com
  • Here's the first bit of “cartography” I can show you. I can't really take credit for this. It's a wonderful map display engine created by a company called Faster Imaging, and available as a free iPhone app “ UK Travel Options ”. The screenshots don't do it justice actually. You have to try out the fluidity of the interface and finger gestures for manipulating the map, to fully appreciate this. The map data is OpenStreetMap. On the left though we see traffic light indicators on the tube stations, based on the performance statistics from placr.
  • And here's those same traffic light indicators again on a more basic web map. http://apps.placr.co.uk/transportapi/tube/dashboard
  • We looked at the dataset for bus timetables from TfL which was in TranXchange format. This is a rather complex XML format which feels rather hairy and bloated for people trying to do rapid development. So I spent a few days trawling through big XML files.
  • I came up with this diagram of the objects and their links within the file. It seems to be suited to loading into a database, to make sense of these linkages.
  • The desired outcome which took an aweful lot of data wrangling to achieve... was of course something which looks like a normal timetable. Once we'd figured out how to get a timetable grid like this, we made some quick progress, loading that data into a database and then into ruby on rails to produce some new outputs. For example here's a little web display of a bus-stop, showing when the next few buses are departing from the current time.
  • So this is that same content presented within the placr.mobi mobile web app. So we're parsing the transXchange and providing a content API. This can be easily consumed by mobile app developers. For placr.mobi we use a javascript library called jQuery mobile, which very quickly and easily makes a website look like an iPhone app. It's quite nice, but we're encountering a few gotchas with it.
  • We start to see a geo element to this app when we tie into bus stop location data. So the app lets you find nearby bus stops. We use the web browser location features, which result in this this prompt. This will be familiar to iPhone users. Essentially the user has to say that they're happy for placr.mobi to know their location. ...and then we can list the five nearest bus stops. When designing simple geo apps, I think its really interesting to think about foursquare. Dont worry. I think it's a pretty silly game too, but it's a poster-child of location based mobile apps, and what's really interesting is that it doesn't show any maps in it's interface. It's a terrible thing to say at a cartography conference, but you can build exciting geo-apps , without showing any maps, and maybe this can help keep things simple and appeal to a wide demographic.
  • But don't worry. I love maps just like the rest of you, and in fact I couldn't resist putting some maps into the app. This is an easy thing to do. If you're developing a web or mobile app and you have a lat/lon in your database, just drop in a link to OpenStreetMap.org You can pass the lat/lon as parameters. Use the 'permalink' feature to see how the URL should look, but then you can also add a marker by changing the url parameters to mlat and mlon. This is an iPhone screenshot, and you can see that the map fits nicely in the browser due to some custom mobile css. However the OpenLayers library used, doesn't allow pinch zooming
  • So I've started looking at using another javascript library called 'leaflet' from CloudMade. It's free and open source, and you dont have to use it with CloudMade tile servers, so they're not trying to create any lock in, which is cool. And this does allow pinch zooming.
  • But here's another simplication to think about. Static map image APIs allow you to just use a plain old img tag in your HTML. This is perhaps the ultimate map display solution for cross-browser mobile compatibility. The src URL of the img tag has all the location and size parameters. One thing to watch out for with this is that you're very dependant upon another server somewhere generating these images.
  • So we're working with transport related open data and buding a transport api at transportapi.com . We're doing some JSON/XML stuff, but also content APIs, so formatted HTML fragments which are then taken by placr.mobi and other app developers to be displayed. Looking at placr.mobi you'll also see some stuff to do with activity streams, and a short URL service pla.cr I won't talk much about that now, but essentially we're doing some experiments with social networks and social engagement with and between bus travellers. I won't tal
  • NaPTAN is the bus stops dataset. It's quite well organised in that every bus stop in the country has an atcocode. It does include a lot of closed/discontinued bus stop locations which you have to watch out for, and the locations are a little inaccurate. OpenStreetMap has imported NaPTAN bus stops in some parts of the country.
  • This might amuse you. I sometimes manipulate or view geo datasets by converting them to .osm files and then opening them in JOSM , the Java OpenStreetMap Editor. This is what happens when OpenStreetMap people try to be GIS people. I can do various comparisons this way, but what we see here is the OpenStreetMap bus stops in the south west, and highlighting in red those which have been imported from NaPTAN.
  • The interesting thing about taking this data from OpenStreetMap, is that OpenStreetMap contributors can make improvements, so in particular it could be good to encourage people to refine the accuracy of bus stop locations. It is possible to develop editing functionality within mobile apps. Users can “authorise with OpenStreetMap” via the oauth mechanism of the API. This is complex in terms of development, and also in terms of user experience. Another approach which I think lots of mobile app developers could thinkabout, is to follow a triage approach. There's a database of map bugs called “OpenStreetBugs”. Users can very easily (with a simple interface) report problems, but OSMers need to make the actual edits later In a simple mobile app it may be a challenge to explain that OpenStreetMap data should not be copied. Also smartphone GPS accuracy is not good enough for placing OSM nodes
  • We haven't delved into this much with our placr work so far, but OpenStreetMap does have bus routes data. It's not complete but the more people use the data, the more motivation there is for the community to fill it in. A great thing about working with OpenStreetMap, is that your service has the potential to be worldwide. If you get something working well in the UK, it can work just as well in New Zealand, or even in the devloping world. Wherever local people have filled in bus routes data.
  • When I'm introducing OpenStreetMap I generally explain how the data is made up of Nodes and Ways, and these have tags on them. And this data model is woderfully simple.
  • However for working with bus routes I need to introduce another datatype: “Relations”. Basically these things relate different nodes and ways in some way, and they also have tags. But they can make things a bit complicated But we can use them to represent a bus route with a relation made of roads, with the tags type=route, route=bus.
  • And we can render these bus routes on a map. Here we are in Plymouth. We can see that there's quite a few missing bus routes here. Maybe we should do a mapping party later! This is öpnvkarte.de , a very german website with an umlout in the domain name, but you can also reach it via openbusmap.org It's been around for a while, and it's one of the nicest examples of OpenStreetMap custom map styles. It looks great at the higher zoom levels too. And there's some interesting dynamic clickable bus-stop features on this site too. This site was having some some server instability, and wasn't showing OpenStreetMap updates. This thing of bringing in updates is really important as a way of spurring the OpenStreetMap community to add in more. Happily the site is now working well
  • But during a period when it was failing to update, I was motivated to come up with my own attempt. I wanted to see how the london bus routes coverage was progressing. So here's my mapnik rendering, which I did as a one-day “hack” at a rewiredstate event.
  • But this was quickly redudant because shortly after I did it, Andy Allan launched this transport map. I believe Andy presented at the Society of Catographers last year. This is his new transport map. Again some really nice catographic styles. He's gone for simple thin streets and dropped a lot of detail to highlight the bus routes. You can see this on http://opencyclemap.org if you flip to this alternative layer in the top right.
  • I didn't make it along to the OpenStreetMap conference in Vienna unfortunately, but you can see video of the talks. There was an interesting presentation from Dr Bartosz Fabianowski of dobini.com http://sotm-eu.org/talk?62 He's done some interesting work, again using Mapnik, but just rendering small images alongside strip diagrams for print display at bus stops. He has an emphasis on automation, so this whole display is generated automatically from the raw data.
  • And of course I have to mention our sponsors at this conference. Itoworld are doing some good looking stuff around bus timestables and maps, also creating print output. It's a little bit hidden behind the scenes, but the sample images on there site look impressive.
  • Thankyou for listening. Here are my contact details, and you can try out the app I've been describing by browsing to http://placr.mobi on a smartphone, or just on a desktop P.C. And of course... check out http://OpenStreetMap.org

Transcript

  • 1. Transport mapping: the OSM route
  • 2. An Open Data Revolution
    • Data owners resisting
    • 3. Politcal hot topic
    • 4. Transparency & accountability
    • 5. Fuelling innovation
  • 6. Innovations...
      ...which make our lives better
    • Data to build useful apps
    • 7. High value datasets. The good stuff.
    • 8. Transport!
    51 billion passenger kilometres by train in 2009/10
  • 9. Web apps, Mobile apps, Mobile web apps
  • 13. placr.mobi Alpha!
  • 14. End users placr.co.uk p l ā ç r Developers Operators
  • 15. Open Data Services Help organisations releasing open data Open data campaigning
  • 16.
      Work with what's available
    • TfL tube departures data
    • 17. TfL and TravelLine bus timetables (TransXchange)
    • 18. TfL bus countdown displays (new!)
    • 19. NaPTAN bus stops
    • 20. Train times and delay information
  • 21. London Tube Performance
    • Based on TfL departures API
    • 22. Radar diagra ms
    • 23. Website (for mobile) :
    • 24. http://tube-radar.com
    and...
  • 25. 'UK Travel Options' Free iPhone app
  • 26. Tube Performance Overview Map
  • 27. TransXchange
  • 28. TransXchange
  • 29. Timetables!
  • 30. jQuery mobile
  • 31. Location lookup
  • 32. Location map Link to osm.org?mlat=...&mlon=...
  • 33.
    • leaflet.cloudmade.com
    • 34. Free & Open Source
    • 35. Multitouch zooming
  • 36. Static map image http://wiki.openstreetmap.org/wiki/Static_map_images <img>
  • 37. APIs placr.mobi pla.cr transportapi.com Formatted HTML or JSON / XML Activity streams Timetables + tube stats
  • 38. NaPTAN
    • Database of bus stop locations
    • 39. ATCOCODE
    • 40. Includes dead bus stops and other mess
    • 41. Locations sometimes inacurrate
    • 42. In OpenStreetMap (partly)
  • 43. NaPTAN & OpenStreetMap
  • 44. OpenStreetMap feedback
    • Editing OpenStreetMap
    • 45. “Authorise with OpenStreetMap”
    • 46. Alternative triage approach
    • 47. 'bugs' & OpenStreetBugs
    • 48. Simple data collection
    Pitfalls:
    • Not copying
    • 49. GPS not accurate
  • 50. OpenStreetMap bus routes
    • Not just a set of stops
    • 51. Worldwide! (potentially)
  • 52. Nodes Ways Tags amenity=pub name=Hare & Hounds highway=residential name=Court Street
  • 53. Relations
    • Roles and memberships. Linking elements
    • 54. Linking several ways to form a route
    • 55. Tags: type=route, route=bus
  • 56. öpnvkarte.de (openbusmap.org)
  • 57. My feeble attempt
  • 58. Andy Alan's Transport Map
  • 59. Dr Bartosz Fabianowski – dobini.com
  • 60.  
  • 61. Thank you mail harrywood.co.uk harrywood.co.uk placr.co.uk placr.mobi openstreetmap.org p l ā ç r