I haven't read any of the papers yet, and before I do, I wanted to write down how it might work. It feels suspiciously simple, and I don't know why yet.
The input: a list of home positions, the preferred mode of travel (could be different for each person), and other travel constraints
For each person, do a "floodfill" on the appropriate graph, starting from the home position, and stopping after the time limit is reached. Every time an edge in the graph is visited, keep track of how long it took that person to reach that edge. For walking, cycling, and driving (*) this is just a simple Dijkstra's algorithm floodfill on a graph built with appropriate edge cost functions (which could take into account elevation, street safety/comfort, etc -- as long as the edge cost is expressed as a logical "time"). (* For driving, it gets complicated to handle turn restrictions properly -- the graph becomes much messier. But we don't need to worry about this to start.)
For PT, this is more complicated, but the same conceptual floodfill approach can still work. There are edges connecting walking edges with stops/stations, and edges connecting stops. Since we're tracking the current time to reach each place in the graph, we know what the next buses/trains arriving will be. The point is, I don't think we need something fancy like RAPTOR, and I don't know if that would help us anyway -- we don't want point-to-point routing, we want the isochrone calculation.
It won't take very much time to floodfill up to 1-2 hours away for each person. The result is a cost for each person to reach each edge. We have a one-time / offline step that snaps POIs to every edge. So once we have the cost per person, we filter for edges containing POIs of the category we want. Those are our candidate meeting points. It'll be a list of (POI info, person 1 time, person 2 time, person 3 time, ...). Then we just sort those by whatever definition of optimalness -- minimize average time, minimize worst-case time, etc.
I haven't read any of the papers yet, and before I do, I wanted to write down how it might work. It feels suspiciously simple, and I don't know why yet.
The input: a list of home positions, the preferred mode of travel (could be different for each person), and other travel constraints
For each person, do a "floodfill" on the appropriate graph, starting from the home position, and stopping after the time limit is reached. Every time an edge in the graph is visited, keep track of how long it took that person to reach that edge. For walking, cycling, and driving (*) this is just a simple Dijkstra's algorithm floodfill on a graph built with appropriate edge cost functions (which could take into account elevation, street safety/comfort, etc -- as long as the edge cost is expressed as a logical "time"). (* For driving, it gets complicated to handle turn restrictions properly -- the graph becomes much messier. But we don't need to worry about this to start.)
For PT, this is more complicated, but the same conceptual floodfill approach can still work. There are edges connecting walking edges with stops/stations, and edges connecting stops. Since we're tracking the current time to reach each place in the graph, we know what the next buses/trains arriving will be. The point is, I don't think we need something fancy like RAPTOR, and I don't know if that would help us anyway -- we don't want point-to-point routing, we want the isochrone calculation.
It won't take very much time to floodfill up to 1-2 hours away for each person. The result is a cost for each person to reach each edge. We have a one-time / offline step that snaps POIs to every edge. So once we have the cost per person, we filter for edges containing POIs of the category we want. Those are our candidate meeting points. It'll be a list of
(POI info, person 1 time, person 2 time, person 3 time, ...). Then we just sort those by whatever definition of optimalness -- minimize average time, minimize worst-case time, etc.