Closed marcusyoung closed 5 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.
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.
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 setnumItineraries
to 1, the returned itinerary is not necessary the best of the four itineraries that would have been returned ifnumItineraries
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.