What "Open" Means for Next Generation Cities

Editor's Notes

2. OpenPlans’ team consists of software engineers, designers, and journalists, all working to make cities more livable and citizens more informed, and technology more effective. Our major skill areas are (from least to most technical): 1) online journalism covering urban policy issues 2) web applications and technology strategy for “open cities” and “open government”, and 3) open source software development
3. OpenPlans’ team consists of software engineers, designers, and journalists, all working to make cities more livable and citizens more informed, and technology more effective. Our major skill areas are (from least to most technical): 1) online journalism covering urban policy issues 2) web applications and technology strategy for “open cities” and “open government”, and 3) open source software development
4. OpenPlans’ team consists of software engineers, designers, and journalists, all working to make cities more livable and citizens more informed, and technology more effective. Our major skill areas are (from least to most technical): 1) online journalism covering urban policy issues 2) web applications and technology strategy for “open cities” and “open government”, and 3) open source software development
5. OpenPlans’ team consists of software engineers, designers, and journalists, all working to make cities more livable and citizens more informed, and technology more effective. Our major skill areas are (from least to most technical): 1) online journalism covering urban policy issues 2) web applications and technology strategy for “open cities” and “open government”, and 3) open source software development
6. OpenPlans’ team consists of software engineers, designers, and journalists, all working to make cities more livable and citizens more informed, and technology more effective. Our major skill areas are (from least to most technical): 1) online journalism covering urban policy issues 2) web applications and technology strategy for “open cities” and “open government”, and 3) open source software development
7. OpenPlans’ team consists of software engineers, designers, and journalists, all working to make cities more livable and citizens more informed, and technology more effective. Our major skill areas are (from least to most technical): 1) online journalism covering urban policy issues 2) web applications and technology strategy for “open cities” and “open government”, and 3) open source software development
8. OpenPlans’ team consists of software engineers, designers, and journalists, all working to make cities more livable and citizens more informed, and technology more effective. Our major skill areas are (from least to most technical): 1) online journalism covering urban policy issues 2) web applications and technology strategy for “open cities” and “open government”, and 3) open source software development
9. OpenPlans’ team consists of software engineers, designers, and journalists, all working to make cities more livable and citizens more informed, and technology more effective. Our major skill areas are (from least to most technical): 1) online journalism covering urban policy issues 2) web applications and technology strategy for “open cities” and “open government”, and 3) open source software development
10. OpenPlans’ team consists of software engineers, designers, and journalists, all working to make cities more livable and citizens more informed, and technology more effective. Our major skill areas are (from least to most technical): 1) online journalism covering urban policy issues 2) web applications and technology strategy for “open cities” and “open government”, and 3) open source software development
11. OpenPlans’ team consists of software engineers, designers, and journalists, all working to make cities more livable and citizens more informed, and technology more effective. Our major skill areas are (from least to most technical): 1) online journalism covering urban policy issues 2) web applications and technology strategy for “open cities” and “open government”, and 3) open source software development
12. One area of focus is Transportation Technology. We are working with a number of transportation agencies around the US to develop open source tools for better customer information, more meaningful involvement in transportation planning, and new insights into how transportation systems function.
13. One area of focus is Transportation Technology. We are working with a number of transportation agencies around the US to develop open source tools for better customer information, more meaningful involvement in transportation planning, and new insights into how transportation systems function.
14. One area of focus is Transportation Technology. We are working with a number of transportation agencies around the US to develop open source tools for better customer information, more meaningful involvement in transportation planning, and new insights into how transportation systems function.
15. One of our current projects is with New York’s MTA, bringing real-time bus information to the web.
16. “Where is the bus” is a critical question, and one that NYC has yet to completely solve. Our pilot project is intended to demostrate the potential of doing things in an “open” way.
17. We are building a web server that takes vehicle locations and serves them up to web and mobile applications.
18. We are building a web server that takes vehicle locations and serves them up to web and mobile applications.
19. We are building a web server that takes vehicle locations and serves them up to web and mobile applications.
20. We are building a web server that takes vehicle locations and serves them up to web and mobile applications.
21. We are building a web server that takes vehicle locations and serves them up to web and mobile applications.
22. We are building a web server that takes vehicle locations and serves them up to web and mobile applications.
23. We are building a web server that takes vehicle locations and serves them up to web and mobile applications.
24. We are building a web server that takes vehicle locations and serves them up to web and mobile applications.
25. We are building a web server that takes vehicle locations and serves them up to web and mobile applications.
26. Here is an early example of real location data coming from NYC buses.
27. We are not starting from scratch. Rather, we are building upon a proven (and very popular) open source bus tracking project called OneBusAway. OneBusAway was developed by Brian Ferris for use in Seattle, and is one of Seattle’s most popular apps. By starting with OneBusAway, we are able to reduce many of the up-front costs of developing these tools.
28. OneBusAway did a survey of riders, which shows what a powerful impact adding a simple information layer can have on riders.
31. In the end, better transit information can lead to happier riders, a greener city, and double cost savings for transit agencies -- both from increased ridership and lower software costs.
32. In the end, better transit information can lead to happier riders, a greener city, and double cost savings for transit agencies -- both from increased ridership and lower software costs.
33. In the end, better transit information can lead to happier riders, a greener city, and double cost savings for transit agencies -- both from increased ridership and lower software costs.
35. The overall architecture represents 3 layers - 1) on-bus hardware, 2) server middleware and 3) user-facing applications. The “closed” model wraps all of these into an end-to-end solution. The “open” model allows for flexibility between and within each layer. For simplicity’s sake, this is represented as a binary choice (closed vs. open), when in reality it is actually more of a spectrum.
36. The overall architecture represents 3 layers - 1) on-bus hardware, 2) server middleware and 3) user-facing applications. The “closed” model wraps all of these into an end-to-end solution. The “open” model allows for flexibility between and within each layer. For simplicity’s sake, this is represented as a binary choice (closed vs. open), when in reality it is actually more of a spectrum.
37. The overall architecture represents 3 layers - 1) on-bus hardware, 2) server middleware and 3) user-facing applications. The “closed” model wraps all of these into an end-to-end solution. The “open” model allows for flexibility between and within each layer. For simplicity’s sake, this is represented as a binary choice (closed vs. open), when in reality it is actually more of a spectrum.
38. The overall architecture represents 3 layers - 1) on-bus hardware, 2) server middleware and 3) user-facing applications. The “closed” model wraps all of these into an end-to-end solution. The “open” model allows for flexibility between and within each layer. For simplicity’s sake, this is represented as a binary choice (closed vs. open), when in reality it is actually more of a spectrum.
39. The overall architecture represents 3 layers - 1) on-bus hardware, 2) server middleware and 3) user-facing applications. The “closed” model wraps all of these into an end-to-end solution. The “open” model allows for flexibility between and within each layer. For simplicity’s sake, this is represented as a binary choice (closed vs. open), when in reality it is actually more of a spectrum.
40. The overall architecture represents 3 layers - 1) on-bus hardware, 2) server middleware and 3) user-facing applications. The “closed” model wraps all of these into an end-to-end solution. The “open” model allows for flexibility between and within each layer. For simplicity’s sake, this is represented as a binary choice (closed vs. open), when in reality it is actually more of a spectrum.
41. The overall architecture represents 3 layers - 1) on-bus hardware, 2) server middleware and 3) user-facing applications. The “closed” model wraps all of these into an end-to-end solution. The “open” model allows for flexibility between and within each layer. For simplicity’s sake, this is represented as a binary choice (closed vs. open), when in reality it is actually more of a spectrum.
42. In the closed model, a single solution delivers a single interface. While this can be simpler to purchase and install, it is limited in its long-term flexibility.
43. The open approach treats each layer separately and allows them to be developed independently. We will explore each layer in detail.
44. At the top is the “app” layer -- an Application Programming Interface (API) is created, which allows anyone to write apps to use the data in the system. This approach has led to an explosion in transit-related apps (for instance, hundreds in the iPhone app store alone).
45. The server layer takes the raw data from individual buses and prepares it to be queried by applications. In our case, we are building the server layer from an open source toolkit (OneBusAway). In the future, agencies running this software will be able to customize it themselves, or hire anyone to improve it for them (i.e., they will not be tied to us as a vendor), which increases their long-term flexibility.
46. At the hardware layer, a variety of hardware components can be used to communicate location data to the server. On the left is a unit produced from commodity components by researchers at MIT. You could also use a smartphone, or hardware that’s already installed on the bus (the farebox, if it is equipped with GPS).
47. Long-term, we are working towards the development of a suite of open source components for transportation management. Real-time bus locations is just the first step.
48. An important takeaway is that while delivering new information to the public is exiting and valuable, it’s also important to architect these information systems so as to provide the best long-term value and the most flexibility possible.
49. If you like these issues, come to TransportationCamp, an pair of unconferences about transportation technology that we’re hosting this spring.