Interpreting the results from testerrrr

[aitorlape]

Hi, I am trying to figure it out how testerrrr works. For instance, I am using the following feed from Madrid

http://transitfeeds.com/p/emt-madrid/212

I've done several tests but sometimes I see things like the following:

I checked the trip_id FE01100321 that starts on Marques de Viana - Trebol (stop code 5647) and ends on Torrelaguna - Av. Badajoz (697) It departs at 18:23 and arrives at 19:01

The result from the testerrrr tells me to drop off just before the last stop and walk to that stop, the funny thing is that doing that you arrive later (19:01:44) and still you have to walk.

I've seen this several times and sometimes it tells you to drop off even 3 or 4 stops before and walk and still you get to the destination stop later when you just could stay on the bus until you reach your destination, no walk and you get earlier.

For instance trip_id LA13700515, you can take the bus at 18:37 and drop off at the last stop and you arrive at 19:25 testerrr tells me to drop off 4 stops earlier, walk to the last stop and arrive there at 19:26:16

I am trying to integrate a simple route planner within Vasile's simulator. You can check the last example I am talking about here http://www.seetys.com/transport-bus-lines/madrid?simulator=true&date=2014-10-06&hms=18:37:00&vehicle_id=f09ce7017e

And the results from testerrrr for the same trip http://www.seetys.com/static/debug/tripplanner.php?from=5698&to=2691&type=d&date=2014-10-06&time=18:37&city=madrid

Is this behaviour expected?

[koch-t]

It is expected if the bus is very very slow and walking is faster. The fact that we take a straight distance can under-estimate the walk time. On the other hand some operators understate drive-times for punctuality reasons. This combined with the way RRRR works like most transit planners, finding the fastest way from A->B it will says to walk while taking the bus would be more convenient. One way to experiment is with the walk speed, reducing it should let the router give preference to more bus. @skinkie is working on improving this however

/edit re-reading it, you also complain about more walking while it's is slower. Thought @skinkie walked in to this as well, maybe he could give his 2 cents.

[aitorlape]

Thank you very much, Could you please let me know where and how exactly I should experiment with those values?

[koch-t]

https://github.com/bliksemlabs/rrrr/blob/master/tester.c#L24

walk-speed in meters per second walk-slack is the buffer time at each transfer in seconds

[skinkie]

What I have implemented is naive way to consider all stops in the neighborhood for both the departure as well as the arrival location. Currently you are getting snapped to the closest stop for the arrival and departure location, always, no exception. My main problem with sharing this work is that the journey planner itself complains that some anomalies happen, which might be "ok" but not the output I want to show a regular user.

[aitorlape]

According to this, is there any chance that tweaking the values @skywave was refering to I will accomplish better results? (or encounter new ones)

[aitorlape]

Excuse me, I didn't know those values were part of the input parameters. I tried and now with a slow walk-speed the result is what I expected. That is perfect, Thank you!