maxWalkDistance (seems to not work, v2.1)

[Stoyan Kuklev]

Good day and congratulations with the new update of OTP

Checked the boards for this question but I didn't find it.

I started a new local OTP server for the Netherlands with the latest OTP version. 

There is a suspicious activity with the "maxWalkDistance" query parameter and the returned itineraries.

It seems that the OTP engine returns itineraries with legs with greater length than it.

Scenario screenshotted:

here maxWalkDistance=300 (meters) but 1.2 mile leg itinerary is returned

localhost link if you want to extract the query (Netherlands coverage required): 

https://tinyurl.com/maxWalkDist

The same itineraries are returned if maxWalkDistance is default (4800) or very short; maxWalkDistance seems to have no effect on the output (even though it's the first leg that is to be walked 1.2miles).

Docs reference for maxWalkDistance:

-maxWalkDistance
-query
-The maximum distance (in meters) the user is willing to walk. Defaults to unlimited.

Any idea on how is maxWalkDistance applied / why do we have it? Can it be used if a user wants to limit their walking (instead / in conjunction with walkReluctance)

Thanks in advance, 

Stoyan

[t2g...@gmail.com]

'makWalkDistance' is not supported any more, use 'walkReluctance' instead, if you want to limit the walking. You may also find the migration guide useful:  http://docs.opentripplanner.org/en/latest/OTP2-MigrationGuide.

Thomas

[Stoyan Kuklev]

Thank you Thomas

Regars,

Stoyan

[t2g...@gmail.com]

Also you might find these parameter heopfull, try configure them in the router-config:


/**
* This is the maximum duration in seconds for a direct street search. This is a performance
* limit and should therefore be set high. Results close to the limit are not guaranteed to be
* optimal. Use filters to limit what is presented to the client.
*
* @see ItineraryListFilter
*/
public double maxDirectStreetDurationSeconds = Duration.ofHours(4).toSeconds();

/**
* This is the maximum duration in seconds for access/egress street searches. This is a
* performance limit and should therefore be set high. Results close to the limit are not
* guaranteed to be optimal. Use filters to limit what is presented to the client.
*
* @see ItineraryListFilter
*/
public double maxAccessEgressDurationSeconds = Duration.ofMinutes(45).toSeconds();

/**
* Override the settings in maxAccessEgressDurationSeconds for specific street modes. This is
* done because some street modes searches are much more resource intensive than others.
*/
public Map<StreetMode, Double> maxAccessEgressDurationSecondsForMode = new HashMap<>();

 
(from https://github.com/opentripplanner/OpenTripPlanner/blob/v2.1.0/src/main/java/org/opentripplanner/routing/api/request/RoutingRequest.java)

[Stoyan Kuklev]

Thank you for the resource pointer also @Thomas,

One more question with the same scenario: Any chance you know about why walkReluctance=15-showing itineraries do not show in the default query, even if they get better arrival time ?

That has to do with the way the engine prioritizes which one is best.

Ref screenshots:

walkReluctance=15 (not showing in the default even if result is comparable)

DEFAULT PARAMS (less walk & comparable itinerary missing, "worse" showing)
 

Thanks anyway, maybe this additional question is for separate conversation.

Best regards,

Stoyan

[t2g...@gmail.com]

You should turn on the "Show filtered itineraries", my guess is that the post filter process pick the itineraries with the lowest cost, and with walkReluctance to 15 you say that you would ride a bus for an hour to avoid 4 minutes of walking.

Thomas

[t2g...@gmail.com]

One thing I forgot, if you do not want to walk, also remember to set the 'walkSpeed'. In scenarios were walking is unwanted, usually the walk speed is slower as well.