On 03/12/2013 07:55 PM, Frisco wrote:
> Hi Andrew, flo
>
> The idea is to "plan routes to efficiently pick up or drop off other
> carpoolers".
If (1) the system's user is a driver who wants to pick up potential
carpoolers, and the locations of potential carpoolers are known, then
this is the Travelling Salesman Problem (TSP), which OTP supports for
non-transit routing.
If (2) the system's user is a rider who wants to know how to reach the
closest point on a fixed driving route via public transit, this is also
doable but would require a relatively simple API extension.
> In my idea, there would be a carpooling web service, where you can
> register, publish trips and get in contact... and OTP would provide the
> search engine : alerting you if there are carsharing opportunities and
> helping you to find the available public transport solutions to finish
> your trip.
This is plausible. Considering case (1) TSP is an "NP-hard" problem,
i.e. really time consuming. You'd probably need to narrow down the list
of candidate riders before planning the route.
In case (2) you just need to do common trip plans.
Optimizing for both driver and rider at once would be a very interesting
problem, but would require significant modifications to OTP and is
beyond its current capabilities.
> I read that OTP could give real-time info (GFTS RT), and I saw that OTP
> was able to plan trips like car + bus or else... so I thought maybe
> there could be an alert telling you that there are carsharing
> opportunities and linking you to the carpooling service for further info
> and contact.
> I hope you understand what I mean.
If all drivers' planned paths are known and fixed, they could be treated
as a temporary routes that allow alighting at any point. OTP does not
currently handle adding arbitrary routes to a running server or
alighting at arbitrary points along the route, but at least the second
feature is on our to-do list because it is a characteristic of many
informal transit systems.
-Andrew