Eki Bright – The Case for DIY Routing
twocentstudios.com
twocentstudios.com
Maybe one suggestion I could think of, would be a risk score. Given a set of segments, which transfers are the most "risky"? (From those departures, arrivals and transfer estimates, how bad would the impact be going forward from missing a transfer?)
The main thing I get from Google Map's estimates is an indication that something has changed. If google gives me a route I wouldn't expect, it's normally because some trains/busses have been removed from the schedule today/running slow. Without forcing a route on you, it would be nice to have it hint at the fact that I'll be catching the last train that hour, thus making segments before it "riskier", scaled by how often they arrive + how long my transfer time is + how out of sync they are from the next segment's departures.
I like this idea a lot. If I were to do a full-featured routing app concept using an API to get route proposals, I think it'd be possible to supplement each proposal with a risk score the way you describe.
> The main thing I get from Google Map's estimates is an indication that something has changed.
Great point here.
I've seen this in google maps routing where it will say 'next bus/train in N minutes (or Day and time if this was the last one for the day)'
You can sometimes work around this by accessing the web versions or using 2 different navigation apps, but it's dumb.
Yes, I want transit instructions. No, I am not walking to that station, I am on a bike. No, I am not going to take that particular bus because the road is full of potholes and my bike is heavy enough the rack on the front is questionable. Yes, I intend to skip one train because this station has cover I can wait under while the one I will transfer at doesn't and I want to wait under cover here and get there just in time rather than get there ASAP and wait without cover.
There are just so many considerations to navigation when you're not in a car, mixing modes, and know the city and system pretty well already.
I haven't seen any convincing attempt to tackle what an app for this sort of case might look like, but the linked article does seem to be getting towards it!
Yes! This is exactly the niche I'm trying to solve.
You mentioned 4 or 5 different routing considerations I'd never have been able to predict. And I'm sure anyone you ask could add another couple to the list.
I'm hoping that Eki Bright hits that sweet spot between too much and too little creative freedom in helping the user solve the problem of getting from A to B in the way that works best for them.
- I can break a route into segments.
- Segments modes can be chosen, or the fastest (or some other metric) one is computed.
- Segment routes might be manually entered (waypoints) or computed.
- Arbitrary sequences of segments can be strung together, whether automatic or manual.
- Can ask for a whole trip to be computed to start, and then "sculpt" it by splitting it into segments I can modify (manually override, change modes, etc).
Maybe one day I'll try to whip something up that matches what seems would work to me. I get the sense this kind of tool might be like knowledge management tools where there's no one size fits all solution.
* Multi-modal planning: where walking, transit, biking, and driving can be independently selected for each leg of the journey (in a multi-stop trip)
* Travel breaks with duration: for a multi-stop trip, allow the inclusion of estimated stop time (e.g. I plan to stop for a meal at a particular restaurant on my upcoming road trip and I intend for that stop to take 1.5 hours). That stop time would then affect the ETA for all stops along the way and may even impact which public transit options are available at later stops.
* Multi-day journeys: for more specifically planning road trips or vacations.
* Constraints on the journey: the most familiar of these (which is already somewhat implemented in the popular maps apps) is whether a business will be closed when you arrive. Others could involve weather predictions (on a multi-day, multi-stop trip I only want to go to the beach on a day it's not raining), daylight hours (I don't want to go to the park after dark), etc. I would expect this feature to let users provide their constraints and the planned route would warn users if their constraints aren't met.
* As mentioned in another comment, route comparisons: for single-stop or multi-stop trips, it should be incredibly simple to compare two or more routes. This should be possible prior to travel _and_ while en route. CityMapper provides some amount of this feature: while on a route, you can return to the form where you input your origin and destination and can get an idea of comparisons.
* Another comment (and the article) mentioned exploration while en route: it should be trivial to explore the map in a way that's completely unrelated to one's current trip. Similarly, it should be easier to search for locations that are nearby your route (that is, wouldn't take more than X amount of time out of your way).
An obvious stretch goal after having these features would be to allow for trip optimization given a number of modes of travel, destinations, timing constraints, ordering constraints (want to pick up food before I go to the park for a picnic, so restaurant must come before picnic), and even proposed start and finish times for a trip. This of course falls into the realm of the traveling salesman problem, but if I'm able to reasonable build a few proposals for routes manually (by setting arrival / departure times and choosing transport modes in my maps app) one stop at a time, an app could certainly check a few permutations.
Google was great this time around but it just didn't understand that people might want to stop and look at stuff while walking between trains, and I found myself having to fiddle with it and sometimes restart whole trips when being able to pause and restart them would have worked (or maybe I just don't know how to do that?).
DIY routing sounds closer to having an intelligent version of those books of timetables I used to carry around.