Closed mem48 closed 5 years ago
Ok, so if I understand correctly, there would be a function otp_trip_distance()
, for example, which would first call otp_plan_internal()
which would return the json, and then otp_trip_distance()
would do the necessary parsing of the returned json to return the distance in km?
Is your feature request related to a problem? Please describe. The first part of the otpTripDistance and otpTripTime are the same as would any other function that uses the /plan API.
Describe the solution you'd like To avoid code duplication I suggest an internal function that covers just the connecting and retrieving of raw data, and error handling. Then otpTripDistance etc are wrappers that change the output at the R end. The function can then handle all the different variables that the user may wish to pass the OTP API, and that will greatly simplify the writing of all the other functions.
E.g.
otpTripDistance(otpcon, from, to, modes)
Only supports the bare minimum of options, but with an internal function we could have
otpTripDistance(otpcon, from, to, modes, ... )
Where ... is any valid OTP API parameter that the user wishes.
Describe alternatives you've considered None
Additional context
Simple Example: Basically just otpTripTime with some bits stripped out, but we would add all the variables you can think of.