Closed elslooo closed 9 years ago
What is the reason that you have implemented this opposed to use max_transfers?
Yes unless the idea is to "cancel" the search by modifying router->n_rounds from another thread?
The idea is to have one thread:
for (i = 0; i < route->n_rounds; i++)
if (self.isCancelled)
break;
router_route(...);
}
Then another thread (e.g. the UI thread):
Now with the appropriate locking (Objective-C provides this), this is able to cancel a route request. In my Teova app, this is used to cancel generating the shortest route in the auto-suggestion box. When a user types A for example, it starts generating the shortest routes for both Almere and Amsterdam. Then when the user types an m, it cancels the Almere route and continues calculating the Amsterdam route. Given that a user usually types quicker than the router is able to generate a journey, this ensures that the app runs smoothly.
You do understand that the only thing you require for that feature is the origin location? Every arrival time is known, no need to redo any query. Requires one if statement in the planner to enable this feature ;) Or actually: to disable the optimisation.
It's usually the same arrival location but a different origin (or the same origin and a different arrival location).
Doesn't really matter as long as either origin or destination is known
So if you either know the departure time + origin, or arrival time + destination we can directly give you all the pairs, virtually for free. So your autocomplete could already show the time it takes to get you there or when you need to leave.
To be specific that's issue #13