Route/Commute analysis

[thoughtgap]

With the from/to filters, a route (for example a commute to work) can easily be identified.

Right now only direct travels (e.g. home > activity > work) can be filtered. For people with more complex commutes: How would you like to filter your commute?

I'm basically trying to avoid that it will count staying at home over night, riding a bike to a café and staying there for 4h, then going to work as a 4+ hours commute.

I was thinking to add a maximum stopovers filter for routes or a maximum stopover duration. Would this help?

[PalminX]

For me, the most reasonable thing would be to have a commute time range, i.e. a commute would be counted as all trips "home -> work" or "work -> home" which are between 15 minutes and 60 minutes long.

Semantically, this is a bit different from maximum stopover duration, because it will not look at the number or duration of individual stopovers, but at the time between leaving one location and arriving at the other location.

[sobri909]

This is exactly the same issue I've been dealing with (or rather, avoiding dealing with) in Arc itself.

Arc's "Common Paths" logic is currently limited to the most basic case, of "visit -> path -> visit", which means that it's useless for probably the majority of commutes.

For Arc, my goal is to design the logic so that it doesn't require the user to configure any boundaries (eg max/min times, max/min stops), but for arc-data-server it seems like having more flexibility like that would make sense.

I've had a bunch of thoughts on how to implement this over the past couple of years, but ... none them are coming to mind just now 😣 I'll have a hunt through my notes to see if I've written any of them down. But either way, I'm very interested to see how you get on with this one! 😄👍

[sobri909]

Some of my previous ideas just came back to me, so I'll note them down here. They may or may not be useful to your implementation. I suspect they're more useful for an Arc implementation, because they're specific to trying to automatically determine common routes, which is something that arc-data-server might not need.

But anyway...

1. Walk through the list of most commonly visited places
2. For each place, find the most common next place visited after
3. Store this as a "Common Trip"
4. From there, can easily pick up all the path items in each trip between those two places
5. Trim and discard outlier trips, based on something like meanTripDuration + 2sd

[thoughtgap]

@PalminX Nice approach. This could be done by adding a parameter like max_travel_duration and ask it to skip through "stops in between".

@sobri909 thanks for your input too! A "common routes" endpoint will certainly be interesting. I added #21.

In the meantime I had another idea for extended route finding, which I've added in #22