-
Notifications
You must be signed in to change notification settings - Fork 1
Ideas
A lot of these ideas are big projects where a simple beginning would be a big help. We highly recommend that you implement by feature. Break down the task into very small features. Start with the first feature, adding only as much code as is necessary to accomplish it. Complete the feature to a fully usable state before moving on to the next feature. That's what we try to do.
We need a high-quality way to go from an address to a latitude/longitude (or, in the case of multiple entrances, multiple latitude/longitudes). A good base for this is Geocoder::US, a Ruby geocoder. The initial project would be to get Geocoder::US running on JRuby. There are a few directions to go from there. One useful task would be generalizing the database from just SQLite to also support PostGIS.
Another would be supporting plot-level data and points of interest. Presently, Geocoder::US is designed to just interpolate address ranges. But some cities, such as Portland, have address geographic data down to the individual plot, which would provide much more accurate geocoding. Points of interest are non-address locations, such as landmarks ("The Empire State Building") or neighborhoods ("Fort Greene, Brooklyn").
Finally, it would be useful to provide multiple matches for addresses, especially for cases where the correct match has low certainty.
We would like to be able to plan routes that take into account the most up-to-date data about vehicle locations -- and even perhaps send push notifications with revised trip plans if planned trips become infeasible. This is a gigantic project, but smaller bits of it are feasible for a summer project.
First, for cities that have delay information on the web, a button could be displayed next to each trip segment linking to the agency's page for that trip or route. For cities that have realtime APIs, when trips are planned for the near future, OTP could check each trip segment (caching the results) and display delay information. The next step would be not only displaying the information, but integrating it into trip planning.
Another way to use vehicle location information would be to use historical data to better predict arrival times. Trimet, at least, has this data available on request.
One starting point would simply be to label generated routes with their likelihood of arriving on time, and a confidence interval if available. Once routes are labeled, routing arrival times can be adjusted to reflect expected delays.
How can we make it easier for blind and vision-impaired people to navigate transit?
This is a somewhat exploratory project. The first steps are straightforward: test out OpenTripPlanner using standard screenreaders, and fix what doesn't work. It would also be useful to develop a testing procedure that ensures that we don't reintroduce accessibility bugs of this kind in the future. Finally, if you have innovative ideas about accessibility, please let us know.
Right now, all we do is check accessibility of stops, trips, and streets by slope. We would like to do a lot more. Tickets #200, #201, and #202 describe the work that needs to be done.
We have a slippy map using OpenLayers. Making OpenLayers work on mobile khtml-based web browsers would mean OTP could be used on the go. This work will need to be relatively high-performance, as mobile devices are slow. Also, it must play well with existing touchscreen gestures.
FivePoints has the "bike triangle", which allows users to balance their preferences among short distances, low slopes, and good bike lanes. A transit version of the triangle would balance among walk distance, total trip time, and waiting time. This would require changing how OTP computes the cost of pretty much all edges. It would also entail some front-end work to allow manipulation of the preferences. Finally, it would require an overhaul of the contraction hierarchy code.
This is another implement-the-research project. Imagine that you have two trains that run along the same trunk line, alternating. Each has a frequency of four minutes, but users traveling on that trunk are insensitive to which train they take. So the effective frequency of the line is every two minutes. The trick to implementing this is using hyperpaths. The passenger's position should be modeled as a superposition of positions along the various lines. Some work must be done here to present reasonable trips -- David Turner used to use an extremely complex hyperpath ("M/R to the D/N if there or B/Q at DeKalb otherwise; if Q/N, L; if B/D, A/C/E") to get to work, but I'm not sure we would want to show that to unsuspecting users. Maybe you've got a UI that makes that trip easy?
What trips are being planned? What areas are underserved? It would be awesome to track statistics of trip planning geographically and temporally, and compare the lengths of similar trips at different times of day against the number of trips being planned for that time of day. This project breaks down relatively simply: first, figure out what data to collect, then collect it, then present it, then analyze it.
We need an awesome GUI tool to create graphs.
Interested in any of these? Have other ideas? Drop by our IRC channel during US EST daytime, or catch us on the mailing list.