search

marcusyoung / opentripplanner

An API wrapper for OpenTripPlanner (OTP) as an R package
11 stars 5 forks source link

Dealing with multiple itineraries #10

Closed marcusyoung closed 5 years ago

marcusyoung commented 6 years ago

Just wanted to flag this one up.

By default, if I remember correctly, a trip request will return, if possible, 4 itineraries. These will be ordered with the best itinerary the first and so on. There is an API parameter called numItineraries which allows you to specify how many itineraries you want returned. However in my tests, if you set numItineraries to 1, the returned itinerary is not necessary the best of the four itineraries that would have been returned if numItineraries was not specified.

It may therefore be better to not expose numItineraries, but allow the user of Open Trip Planner for R to specify how many itineraries they require (4 max). The function(s) would then select the required number of itineraries from those returned by OTP.

This does require further investigation. It is possible that this issue was a bug that has been fixed in later releases of OTP.

Robinlovelace commented 6 years ago

Worth flagging and I think num_itineraries (to use the rOpenSci style!) would be a neat way around this. Malcolm and I noticed multiple itineraries coming back from TransportAPI and it will be great to have a way to deal with them.

mem48 commented 6 years ago

At the moment my approach has been to return all, but a num_itineraries is a good and simple idea.

On a style question, although I agree we should keep to the rOpen Sci style, I think there should be an exception for parameters that match names in the OTP API. This would allow users to clearly match our functions to OTP concepts and make documenting easier.