Error in otp_plan_batch

[kauebraga]

Describe the bug Hi Marcus. I'm having a hard time in finding the right format I should pass to fromPlace in otp_plan_batch. I've tried two options:

When I use a matrix like this one below, I get the following error:

> origens_matrix[1:2,2:3]
      latitude longitude
[1,] -3.791038 -38.51982
[2,] -3.798004 -38.51396

>Error: Argument 1 must have names
>In addition: Warning messages:
>1: In otp_plan(otpcon = otpcon, fromPlace = fromPlace[x, ], toPlace = toPlace[x,  :
 > A routing error has occured, returing error message
>2: In otp_plan(otpcon = otpcon, fromPlace = fromPlace[x, ], toPlace = toPlace[x,  :
 > A routing error has occured, returing error message
>Timing stopped at: 0 0 0.03

When try this other matrix, I get another error:

> origens_matrix[1:2,]
     id_hex  latitude longitude
[1,]      1 -3.791038 -38.51982
[2,]      2 -3.798004 -38.51396

>fromPlace is not a valid matrix of latitude, longitude pairs
>Error in otp_plan_batch(otpcon = otp_for, fromPlace = origens_matrix[1:2,  : 

Timing stopped at: 0.05 0 0.05

Could you please give me hand?

[marcusyoung]

Hi @kauebraga

The second error is because the matrix must only have 2 columns.

I've asked @mem48 if he can get back to you about the "Argument 1 must have names" error has he wrote the otp_plan_batch() function.

Marcus

[marcusyoung]

@kauebraga

After some digging it looks like the error Error: Argument 1 must have names is a bug with handling the error message returned by OTP when it can't find a route. I've been able to replicate the error messge you got if there is no route returned by OTP.

Best wishes

Marcus

[mem48]

@kauebraga

I can't reproduce your error because there is not enough information in the question. What are your fromPlace and toPlace values? What happens in you just do the routes one at a time with otp_plan?

However, I've done a lot of additional work on this function in my fork https://github.com/ITSLeeds/opentripplanner so this bug may have already been fixed. Could you test your problem with my version of the package and let me know if it works or not?

[kauebraga]

@mem48

Thanks for the fork! It has the get_geometry argument that I've been hoping for.

I have more than 300 points that I wanted to build a time matrix. So I generated a matrix with all the combinations, where I first get the first origin to all the destinations, and so on. Code below.

# Same origin (first one)
> head(fromPlacematrix)
     lon.origem lat.origem
[1,]  -38.51982  -3.791038
[2,]  -38.51982  -3.791038
[3,]  -38.51982  -3.791038
[4,]  -38.51982  -3.791038
[5,]  -38.51982  -3.791038
[6,]  -38.51982  -3.791038

# Different Destinations
> head(toPlacematrix)
     lon.destino lat.destino
[1,]   -38.51982   -3.791038
[2,]   -38.51396   -3.798004
[3,]   -38.51086   -3.789455
[4,]   -38.51672   -3.782489
[5,]   -38.52568   -3.784072
[6,]   -38.52878   -3.792621

otp_plan_teste_batch <- otp_plan(otpcon = otp_for, 
                          # Get the first 100 observations
                           fromPlace = fromPlacematrix[1:100,], 
                           toPlace = toPlacematrix[1:100,],
                           date_time = as.POSIXct("2018-11-05 07:00:00"),
                           mode = "TRANSIT",
                           get_geometry = FALSE)

However, I can't get any valid itineraries. All iterations return "Error: ... to ... No trip found. There may be no transit service within the maximum specified distance or at the specified time, or your start or end point might not be safely accessible." and get NULL as result. But it seems to be making the right request to the server.

Testing with the same coordinates in the web browser I can get valid itineraries with mode=TRANSIT,WALK. I can't pass this argument to the otp_plan function because it only accepts one mode.

Given the issue and the results It seems that it's not a issue with the opentripplanner package per se, but with my graph and GTFS files. But it would be nice to be possible to pass more than one mode to the mode argument in the plan function. Thanks!

[marcusyoung]

Hi @kauebraga

You can send multiple modes as a vector:

Mode = c("TRANSIT", "WALK")

Marcus

[mem48]

Could it be that the max walk distance is too low? Have you copied the exact coordinates into the web interface? OTP is quite strict on start and end points being too far from the road network or having to walk far to the transit stop.

Can you confirm that the routes are possible (e.g. by car), and the date and time are valid for your GTFS file?

[kauebraga]

@marcusyoung

That works! Thanks.

@mem48

Yeah, everything is correct. I double checked the routes and date and time. I used Mode = c("TRANSIT", "WALK") as @marcusyoung suggested and I'm getting the expected results. Next week I'll run it with other GTFS and graph file and I'll see how it goes.

I'm getting other issue with the time though. I try to set my date time with date_time = as.POSIXct("2018-11-05 08:00:00") and I get the right day, but the time in the results always return trips starting at 11:00:00. I suspected it was a locale issue, and indeed it was. My locale (Brazil) doesn't support a.m/p.m times, and that was messing up the time conversion to character:

> Sys.getlocale()
[1] "LC_COLLATE=Portuguese_Brazil.1252;LC_CTYPE=Portuguese_Brazil.1252;LC_MONETARY=Portuguese_Brazil.1252;LC_NUMERIC=C;LC_TIME=Portuguese_Brazil.1252"
> date_time <- as.POSIXct("2018-11-05 08:00:00")
> time <- tolower(format(date_time, '%I:%M%p'))
> time
[1] "08:00"
> 

When I set up with US locale:

> # With US locale
> Sys.setlocale("LC_ALL","English")
[1] "LC_COLLATE=English_United States.1252;LC_CTYPE=English_United States.1252;LC_MONETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252"
> date_time <- as.POSIXct("2018-11-05 08:00:00")
> time <- tolower(format(date_time, '%I:%M%p'))
> time
[1] "08:00am"

Setting Sys.setlocale("LC_ALL","English") doesn't affect the results of my routing though. It keeps returning trips starting at 11:00:00.

[mem48]

This is a problem with OTP not accepting dates and times in a standard format, I'm not sure it can be fixed in the package. Although why "08:00" is interpreted as 11:00 is a bit of a mystery.