Calculating one-to-many commute times

[Dan Vanderkam]

I'm trying to calculate commute times from a single origin to several thousand destination points using transit+walking.

I've been able to run OpenTripPlanner and load in several GTFS feeds, an OSM PBF file and a CSV file containing my PointSet.

I've created a Surface via:

curl 'http://localhost:8080/otp/surfaces?batch=true&layers=traveltime&styles=color30&time=10%3A08pm&date=03-13-2017&mode=TRANSIT%2CWALK&maxWalkDistance=804.672&fromPlace=40.687772%2C-73.978498'

I can use the "indicators" API endpoint like so:

curl 'http://localhost:8080/otp/surfaces/4/indicator?targets=myPointset&detail=true'

but this seems to returns some sort of histogram of travel times, rather than a mapping from IDs in the point set to commute times:

{"properties":{"id":"null_0"},"data":{"id":{"sums":[234,1121,2523,1888,3832,10176,13839,13389,16329,18928,19633,23667,25529,37283,59167,81405,100890,134792,139491,147317,186301,212207,241327,280253,306471,312696,345083,386077,410551,426195,447869,472240,480755,520750,570201,551417,525899,536021,513112,512516,522756,490613,455790,434465,406772,360792,312713,298938,275177,253516,224805,223056,235430,234518,219620,213099,198688,202796,216488,196341,178809,176058,165432,157056,147580,135662,131730,134015,128199,116719,104929,105217,111480,111020,105176,105432,99779,92279,88294,82698,68789,63101,69230,76361,66815,52101,44007,37910,29986,29686,32902,29155,26873,34449,35420,25998,20371,15473,11789,14802,21799,22393,15399,12533,13690,13764,11703,8954,11180,14040,11160,8965,6525,4828,5105,3830,2882,2949],"counts":[0,0,0,1,0,2,3,2,3,4,4,5,5,7,11,15,19,26,26,28,36,41,47,55,60,61,68,78,84,89,94,99,100,108,120,118,113,117,117,122,126,123,119,116,107,97,90,90,88,88,84,84,89,90,87,87,84,87,91,83,81,79,76,73,69,63,63,68,65,62,55,52,56,58,55,54,53,49,45,43,36,31,36,41,38,30,25,23,18,17,18,18,19,23,21,16,14,11,11,13,15,14,10,11,12,13,12,9,12,13,10,9,8,5,4,5,3,4]}}}

Is it possible to calculate one-to-many travel times for a pointset using the OTP HTTP API?

Thanks,

  - Dan

[Andrew Byrd]

Hi Dan,

This system was mostly used for accessibility calculations (how many X can be reached in less than M minutes). The results you’re seeing are indeed histograms: the number of points that can be reached in each minute of travel (the counts field) and the number of opportunities that can be reached in each minute, i.e. the sum of the weights of all reached points within that minute (the sums field). These results are of a relatively short fixed length so they are always returned.

If you add the detail=true parameter you will get another array with one travel time per point.

I don’t think you need the &layers=traveltime&styles=color30 parameters, those are for creating map tiles.

I have updated the JavaDoc a bit to reveal this “detail” parameter and will push the change soon.

Regards,

Andrew

--
You received this message because you are subscribed to the Google Groups "OpenTripPlanner Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opentripplanner-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dan Vanderkam]

Thanks for the response, Andrew.

I am setting "detail=true" in the /indicator call (you can see the full curl command in my previous message). But I'm still only getting the histogram. Is there something else I need to be doing to get the array with one travel time per point? My PointSet has ~6,000 points in it and I'm running a build of OTP from near-HEAD (March 2nd).

Best,

  - Dan

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

[Andrew Byrd]

Ah, I didn’t see that. Looking at the code, I see that setting detail=true will store the travel times and the isochrones in the ResultSet object, but then that object is not automatically serialized. It has a custom method org.opentripplanner.analyst.ResultSet#writeJson that is used to convert it to JSON. That method does not check whether there are times or isochrones to serialize, it only does the histograms.

So there’s some missing code there. You should be able to add some code to the effect of:

if (times != null) {
    jgen.writeArrayFieldStart("times");
    for (int t : times) jgen.writeNumber(t);
    jgen.writeEndArray();
}

just after jgen.writeStartObject();

If you get this working please submit a pull request!

Regards,

Andrew

[Dan Vanderkam]

Thanks! That did the trick. Here's the PR: https://github.com/opentripplanner/OpenTripPlanner/pull/2417

Andrew

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

[Dan Vanderkam]

Also, just wanted to clarify: is this sequence the recommended way to generate one-to-many travel times with OTP? It does feel a little strange that I have to create state on the server (POSTing to create a surface) for each origin.

[Andrew Byrd]

> On 15 Mar 2017, at 02:09, Dan Vanderkam <da...@sidewalklabs.com> wrote:
>
> Also, just wanted to clarify: is this sequence the recommended way to generate one-to-many travel times with OTP? It does feel a little strange that I have to create state on the server (POSTing to create a surface) for each origin.

It’s not so much a recommended way, as a prototype created when were were experimenting with accessibility analysis within OTP. I agree that having the search state persist explicitly on the server is an unorthodox way of doing things. Other parts of OTP (e.g. visualizing travel times as map tiles) require the full query parameters for the search to generate each tile, and results are cached opaquely inside the OTP server.

These methods are still present in case anyone wants to use them or take them as examples, because the code is already written. But Conveyal has built a whole separate accessibility analysis system based on these experiments within OTP, including a scenario editor and a separate router specialized for a more statistical approach to travel times over departure time windows, with uncertainties in time tables etc. We almost exclusively use that system for spatial analysis work now.

I think many other people in the OTP community would perform this kind of analysis using the OTPA scripting system, which I’ve never used myself (we tended to use the web APIs), but I’ve seen it put to very interesting uses.

Andrew

[Dan Vanderkam]

I filed a feature request for one-to-many in a single API call. Let me know if this is something that would be reasonable for me to take a crack at implementing.

I assume the new system is conveyal/r5? Are there docs/pointers on how one might do a one-to-many travel time analysis with that?

Thanks,

  - Dan