windows_time and MonteCarloDraws

[xtimbeau]

Hi guys, thnaks for the fantastic job done with r5r ! I have done a large number accessibility calculation using OTP isochrone capabilities for France and I switched recently to r5r which provides many advantages. I do have a question regarding your default parametrization of r5r and I'd like to know if you agree with my understanding: When time_windowis set to 1L, then all draws are taken for the same departure time. Hence, there are no differences between draws in term of time_travel_matrix. I experimented on some pbf/GTFS and there are none. Hence setting setNumberOfMonteCarloDrawsto 1L brings the same results whith a noticable gain in calculation time. When time_window>1, the number of draws changes the result. The default seems to be set to time_window=1L, setNumberOfMonteCarloDraws(200L) which is not optimal. All the best XT PS : do you have any plans to incorporate more access to r5 API (like accessibility calculation) or access to more parameters of the routing algorithm (OTP has a large number of those, some of them can modify the accessibility calculation a bit) or the possibility to modify the GTFS from the r5 API or to modify speeds on the OSM to take in account congestion ?

[rafapereirabr]

Hi Timbeau. Thanks for the kind words feedback. I'll try to address your points one by one below.

1. The capability of R5 to generate mutilple departure time sampling over a time window is quite new to the field of transport and accessibility modeling. I belive most people are still not familiar with it, and so the average user will probably find this idea confusing and only run queries on single departure times. This is the reason we have set the time_window default to 1L. The package is still very much in early development and this parameter has not been fully implemented yet so we're open to hear other people's opinion and change this defaut if there are good reasons to do so.

2. I see. Setting setNumberOfMonteCarloDraws(200L) with time_window=1L is not efficient and it does not make much sense really, as you said. I'm wondering whether there would be a rule of thumb to define what would be an approriate number of draws depending on the time_window size. The R5 default of of 200 draws is obviously too big for a 1- or 5-minute window, but it is not that high if we're talking about an 8-hour window, is it?

3. We would be very glad to expand r5r to incorporate other capabilities and paramenters from R5. I would be particularly keen in incorporating the capabilities to modify transit netowks in GTFS data and speeds in OSM. We have barely started to scratch the surface of what R5 can do, and we are very much open for contributions to expand r5r.

[xtimbeau]

I'd be happy to contribute. Unfortunatly, I know very little of java !

[rafapereirabr]

I simple rule of thumb here would be to set the number of Monte Carlo draws to be 5 times the size of time_window.

[mvpsaraiva]

Thanks @xtimbeau. As @rafapereirabr said, we are still figuring out the best way of exposing R5's api to R users in a simple and intuitive way. Just to clarify one thing, as discussed in issue #104, the number of Monte Carlo draws affects the results of frequency-based GTFS. In those cases, you can have slightly different results between runs depending on the number of Monte Carlo draws, even if you have a time window of 1 min. Having said that, I agree that 200 is overkill for small time windows, and I think that Rafa's solution of setting its value to 5 times the size of time_window is a good one.

[xtimbeau]

ok good !

Le dim. 4 oct. 2020 à 16:33, Marcus Saraiva notifications@github.com a écrit :

Thanks @xtimbeau https://github.com/xtimbeau. As @rafapereirabr https://github.com/rafapereirabr said, we are still figuring out the best way of exposing R5's api to R users in a simple and intuitive way. Just to clarify one thing, as discussed in issue #104 https://github.com/ipeaGIT/r5r/issues/104, the number of Monte Carlo draws affects the results of frequency-based GTFS. In those cases, you can have slightly different results between runs depending on the number of Monte Carlo draws, even if you have a time window of 1 min.

Having said that, I agree that 200 is overkill for small time windows, and I think that Rafa's solution of setting its value to 5 times the size of time_window is a good one.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ipeaGIT/r5r/issues/118#issuecomment-703264467, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANA2KEOBE4RJ5NAJ4UTLARLSJCBTZANCNFSM4SBOHJJA .

[rafapereirabr]

Hi all. The implemented solution is to use a number of Monte Carlo draws equals to 5 times the size of time_window set by the user. This solution is currenlty implemented in the new version of r5r v0.2.0 published on CRAN today. I'm closing this issue for now.

[dhersz]

As per https://github.com/ipeaGIT/r5r/commit/a79e9692bcf7f81f55ea5c5fecd8258398ace66d, the number of Monte Carlo draws per time window minute is now set via the r5r.montecarlo_draws option. Defaults to 5 - i.e. 300 draws in a 60 minutes time window, for example. Set a custom value using options(r5r.montecarlo_draws = 10L) (in which you substitute 10L by the value you want to set).