Single-source, multiple-destination travel duration

[Rehan Abdul Aziz]

Hello,

I am trying to serve a use case that requires travel durations to hundreds of destination points from a single location within a metropolitan city. I have tried achieving that using two methods:

• Simple but slow: Iteratively calling the /routers/{routerId}/plan end-point for all destination nodes from the same source nodes. As expected, this doesn't really scale up and calling the end-point 1000 times takes more than 2 minutes (running the jar on my laptop).
• Complex but fast: This approach uses the /routers/{routerId}/isochrone end-point with the source node:

1. It creates concentric isochrones with 5-minute increments using multiple cutOff arguments (10 mins, 15 mins, ... , 90 mins).
2. Performs post-processing step on the GeoJSON to check the inclusion of destination nodes in the right isochrone in order to work out the travel duration within 5 minutes resolution. 
   
   

For creating isochrones from 10 to 90 minutes with a step size of 5 minutes, the second method takes about 3 seconds which is not too bad. If I go all the way to travel duration of 2 hours (120 minutes), it takes about 15 seconds to complete (just the OPT part, I haven't done the post-processing bit yet).

Ideally, I would like to write an end-point (or know if one exists) for the one-to-many case. Do you guys have any advice on that?

Regards,

Rehan.

[Rehan Abdul Aziz]

[Andrew Byrd]

Hi Rehan,

The two methods you identified are indeed work-arounds. The first is highly inefficient, and the second is internally producing the all the output you need when producing a single 90-minute isochrone but throwing it away after producing the isochrone.

There have been a lot of questions about this use case over the last few months, so I already started writing some new documentation. Yes, there are existing endpoints and Java classes for handling this use case - in fact this has always been my primary use of trip planning software. It’s clear there are a lot of people struggling to get the output they need for planning and research applications, and this is leading to huge amounts of excess computation.

Rather than waiting to perfect that documentation I’ll try to get it up in preliminary form today or tomorrow, and then iteratively improve it based on any questions that come up. I’ll post a message when the documentation is published.

-Andrew

--
You received this message because you are subscribed to the Google Groups "OpenTripPlanner Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opentripplanner...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/opentripplanner-dev/a3295195-e922-42fd-b0f4-1f0e46092bbao%40googlegroups.com.

[Rehan Abdul Aziz]

Thanks Andrew, sounds great. I will look forward to your update.

Rehan.

To unsubscribe from this group and stop receiving emails from it, send an email to opentripplanner-dev+unsub...@googlegroups.com.

[Andrew Byrd]

Hello,

Following a recent series of mailing list questions on the subject, I have posted some draft documentation on calculating one-to-many travel times and accessibility indicators with OTP.

The documentation is visible here: http://docs.opentripplanner.org/en/dev-1.x/Surface/

And the documentation source is here: https://github.com/opentripplanner/OpenTripPlanner/blob/dev-1.x/docs/Surface.md

Hope this helps!

Andrew

To unsubscribe from this group and stop receiving emails from it, send an email to opentripplanner...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/opentripplanner-dev/7c3ea11b-0327-4ccc-97e2-c056b8ee38c0o%40googlegroups.com.

[Marcus Young]

Hi Andrew

Thanks for this, very useful. Does this suffer from the limitation of the isochrone functionality that only works correctly for transit modes (not walk or drive)?

Thanks

Marcus