| Age | Commit message (Collapse) | Author |
|---|
|
Separate the functionality a little better by moving the `/batch`
endpoint code into a new class. The goal here is also to lay the
foundation for being able to call `TomTom.batch()` instead of
`TomTom.new.batch()`.
Refs #6095
|
|
Look through the API response from `/batch` and extract the distance &
time values given to us by TomTom. These are inserted in the `WayCost`s
given to use in the argument to `#batch`.
At the end, we get a list of `WayCost`s that are completely filled with
distance & time values.
We need to split up this code a bit to make it more testable, but
already this seems to function correctly.
Refs #6095
|
|
Make the TomTom API key accessible to the application. It gets set in
Docker via an environment variable. Still need to work out how we're
setting it in development. For now I'm just saving it in `secrets.yml`
without committing it.
Refs #6095
|
|
This reverts commit f28a4b2c5b348bc12b455aa0cd76a9513103aea7.
As stated in that commit, I'm going to use the `/batch` endpoint instead
of `/calculateRoute` because I know that's already working.
|
|
A new method to provide access to the `/calculateRoute` endpoint, which
calculates costs for a single route through a bunch of waypoints.
This doesn't work currently because the API requires that I send
`supportingPoints` in the body of the request. Since I'm not too clear
on what those are, I'm going to cut off development of this method here
and just use `#batch` instead for my purposes.
My idea was to use this endpoint instead of `/batch` to allow us to
calculate a single route instead of having the API do `/calculateRoute`
for each of our point pairs. This seemed like it would be more
efficient, and give us our distance and time costs between each waypoint
all in one go, but since I'm not clear on how to use this API and
whether it will give us the correct data, I'm going to stick with
`/batch`. I'll probably be reverting this code. Just committing it now
in case it becomes useful in the future.
Refs #6095
|
|
I had copy-pasted these from the example in the docs
(https://developer.tomtom.com/online-routing/online-routing-documentation/batch-routing),
but I don't think we want some of these. For `maxAlternatives`, it's
already 0 by default according to their docs, and the others don't
really make sense for us because we want a general routing instead of
one based on traffic or time of day.
Refs #6095
|
|
For now, hard-code 'bus' as the travel mode. This feature is currently
only going to be used for Ouibus, so we want to be able to request in
'bus' mode, but for now don't have time to think about how to make it
more extensible to other travel modes and operators.
Refs #6095
|
|
These served during development but are no longer needed.
Refs #6095
|
|
Provides an interface to communicate with the TomTom API. Currently
includes a method `#batch` to make a batch routing request
(https://developer.tomtom.com/online-routing/online-routing-documentation/batch-routing).
Left a bunch of development-related code in just to preserve my
in-progress stages. Originally I was told to use the matrix routing API,
but that turned out to not match what we wanted. Namely, matrix routing
would produce a table with every point routed with every other point. We
instead want routes of each segment in a line, in order (or, just the
diagonal of the matrix). Using the batch API allows us to get the routes
we need without doing unnecessary work.
Update the `WayCost` class to provide `departure` and `arrival` methods
as readers, and make `id` an optional parameter for now. (We still need
to figure out how we're dealing with ID.)
Refs #6095
|
