| Age | Commit message (Collapse) | Author |
|---|
|
|
|
changed by java side). Refs #6243
|
|
|
|
|
|
section status fron Chouette::JourneyPattern
|
|
|
|
|
|
|
|
|
|
|
|
|
|
confirmed_at. Refs #6141
|
|
|
|
|
|
The JavaScript validation doesn't pass if we have more than two decimal
places (I think because it uses a number field step value of 0.01).
Round the values to allow them to pass frontend validation.
Refs #6203
|
|
Because we need to pass a Ruby hash to Rabl instead of a JSON string,
get rid of our serialiser and instead turn it into a function that just
converts the distance & time units.
Fix a bug in the test that had the `'1-2'` key as a symbol instead of a
string which was caused by a copy-paste from JSON and not being thorough
enough in search-and-replace.
Refs #6203
|
|
This serialiser will take `Route#costs` and convert the distance and
time fields from meters to kilometres and seconds to minutes
respectively. We need this because the frontend uses kilometre and
minute units while the TomTom API gives us the others (and we store the
data we get from TomTom without treatment).
Unfortunately, due to the way that Rabl works, this doesn't quite work
just yet. The serializer returns a string, and Rabl just puts this
string into the JSON output instead of a real JSON hash. Looks like I'm
going to have to convert my serializer into a generic converter.
Refs #6203
|
|
When editing a `JourneyPattern`, you can edit the distance & time costs
between stops. We want to pre-fill these cost values (in the input
fields) if they haven't already been set by a user. This way, they get
an existing estimate of the cost and don't have to enter a value
manually unless the default doesn't work.
The pre-filled values come from `Route#costs`, which get calculated
ahead of time via the TomTom API.
Add a new `fetchRouteCosts` function that will fetch the costs for the
current route from the API. This function also caches the value on
`actions` so we don't keep making requests since the data isn't going to
change. Put the cached fetch in a `requestAnimationFrame` as a sort of
timeout to prevent a warning from React complaining about doing this
during a `render()` call.
Update `getTimeAndDistanceBetweenStops` to use the cost value from the
route costs instead of the journey pattern costs if it doesn't exist.
The `totalDistance` and `totalTime` we moved into `componentWillUpdate`
instead of `render()` because we thought that might be the cause of the
`render()` warning I mentioned above. Decided to leave this part in even
though it doesn't have anything to do with the goal of the changes here,
because it seemed like an okay change.
The `RECEIVE_ROUTE_COSTS` reducer will update the state with route
costs. We need the default distance:0 time:0 to avoid infinitely
fetching the costs API if a cost with the given key can't be found.
Put the route cost API URL in `window.routeCostsUrl` to allow us to get
it from the Rails URL helper.
Huge thanks to Johan for pairing with me on this code and walking me
through the setup for integrating the route costs JSON response into the
frontend interface.
Refs #6203
|
|
Render the `costs` field of a `Chouette::Route` as JSON. This lives at:
http://stif-boiv.dev:3000/referentials/4/lines/1857/routes/7/costs.json
I want this in order to get the distance & time costs of a route so that
I can merge them with `JourneyPattern#costs` on the frontend on
`JourneyPatternsCollection#show`.
Refs #6203
|
|
|
|
|
|
|
|
costs_in_journey_patterns feature is not present. Refs #6102
|
|
We say `TomTom` is disabled when no API key is present. If this is the
case, the `after_save` callback that uses it shouldn't be executed.
I had to change my `API_KEY` constant to an instance variable to be able
to change it for testing.
Refs #6095
|
|
Johan suggested simplifying this method by changing the `slice` call:
http://api.rubyonrails.org/classes/Hash.html#method-i-slice-21
I had modified this to fix the whitespace while working on the `WayCost`
calculation function for `Chouette::Route`s, so don't really have a
brain cache hit on this code, but the change makes sense and seems to
work.
Refs #6095
|
|
Explain why we need to skip and un-skip the callback.
Refs #6095
|
|
Since this method was run on `after_save` and in it
`RouteWayCostCalculator` calls `#update` on the given route, it caused
an infinite recursive call to the worker. To prevent this, wrap the
`#calculate!` call in methods that unset and reset the callback.
Refs #6095
|
|
Just running `Chouette::Route.find(id)` doesn't give us anything if we
don't have a `Referential` selected. In order to properly get the
correct route, pass the referential ID to the worker and switch to that
referential before trying to select the route.
Refs #6095
|
|
Not efficient to send a request to the TomTom API every time we save a
Route, but I'm banking on developing a cache system soon to avoid having
to make the requests, so hopefully that will stop this from making
expensive remote calls all the time.
Refs #6095
|
|
This method wasn't indented to the same level as the rest of the file.
Refs #6095
|
|
This new method will launch a worker that takes the route's `StopArea`s,
converts them to `WayCost`s, sends them to the TomTom API to calculate
distance and time costs, and saves those costs to the route's `costs`
field.
Refs #6095
|
|
Refs #6095
|
|
This allows us to store `WayCost`s for a route so we can use those
values as pre-filled defaults for a `JourneyPattern`'s costs.
Refs #6095
|
|
A JSON serialiser for a collection of `WayCost`s. This will be used to
store `WayCost`s for a `Chouette::Route` in the `Route#costs` JSON
field.
Refs #6095
|
|
A new class that converts a list of `StopArea`s to `WayCost`s. This will
be called from `Chouette::Route` to get `WayCost`s from its stops, which
will then be JSON serialised and stored in `Route#costs`.
Update `WayCost`:
* Remove comment about calculating the ID automatically. It actually
needs to be the same as the `JourneyPattern#cost` ID (`key`), which is
a string with the IDs of the departure and arrival stops.
* Make `#==` check that `id`s are the same, which necessitates making
`id` a reader.
Refs #6095
|
|
Extract some code from `#batch` to allow us to test the part that takes
distance and time values from the response JSON and put fill them into
`WayCost`s.
In order for the test to work, had to add an `#==` method to `WayCost`
and make `distance` and `time` accessors.
The JSON file fixture is a copy of a response from the TomTom `/batch`
API. The file is pretty big. I'm not sure if maybe I should condense it
for the sake of test performance.
Refs #6095
|
|
Rename to `#convert_way_costs` since this method now lives inside the
`TomTom::Batch` class, so that part of the name became redundant.
Refs #6095
|
|
This change enables us to call `TomTom.batch(...)` instead of
`TomTom.new.batch(...)` a couple commits ago. This is nice because the
initialisation was kind of unnecessary for users of the class.
Refs #6095
|
|
Change the `TomTom::Batch` to `module ... class ...` syntax instead. I
like this better in this case.
Refs #6095
|
|
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
|
|
We don't have these values until after the TomTom API calculation, but
we need to create `WayCost` objects before then. Give these values
defaults so we don't have to set them.
Refs #6095
|
|
A data class to hold the distance and time cost required to go between
departure and arrival points.
Refs #6095
|
