| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Refs #6259 Only send mails to users from same workgroup after create/…
|
|
|
|
|
|
Make it clearer why we have to use a custom serialiser here.
Refs #6222
|
|
Rails serialises `BigDecimal`s as JSON strings to prevent loss of
precision. The `latitude` and `longitude` columns in `StopArea` are
stored as `BigDecimal`s. The trouble is that TomTom's API requires the
latitude & longitude values to be JSON floats, not strings.
Make a new JSON serialiser that converts the `BigDecimal` coordinates to
float to allow the values to be correctly interpreted by the API.
Refs #6222
|
|
Calculate routes using the TomTom matrix API. Update the spec's HTTP
request stub accordingly (note that the stub is still fake).
Refs #6222
|
|
Already handled this a few commits ago.
Refs #6222
|
|
Using a set ended up not working out. I needed to be able to index into
the list in `#extract_costs_to_way_costs!`, and sets aren't indexable.
This is because they're supposed to be unordered, though modern Ruby
implements `Set` with `Hash` under the hood, which is ordered in Ruby.
I like the idea of having a data structure that automatically eliminates
duplicates, but it wasn't meant to be, because for the extraction to
`WayCost`s, I need an ordered list. Rather than create a new
`OrderedSet` type, I just went the simple route and used an Array,
eliminating the duplicates manually because I know when duplicates are
supposed to occur due to the nature of the data set.
Remove the `#eql?` and `#hash` methods from `TomTom::Matrix::Point`.
Because we're not longer using `Set`, these methods don't need to be
implemented.
Refs #6222
|
|
Change this code to get stop IDs based on the change in
be3e1effcdea87909a181c7e9b12cf6867b1839d. It should use these IDs to
construct new `WayCost`s with the combination of stop IDs from departure
and arrival stops.
This doesn't work currently because the method has code that tries to
index the `points` collection, but it's a `Set`, and sets don't support
indexing and aren't ordered, so this code errors. Need to change the
`Set` to something else that will work here.
Refs #6222
|
|
Rewrite this method to accept `TomTom::Matrix::Point`s instead of plain
`Geokit::LatLng` coordinates. Do this because this method needs to take
the result of `#points_from_way_costs` as input, and that method now
returns a `Set` of `Point`s.
Refs #6222
|
|
Instead of a generic `ids` array, use clearer variable names for these
values.
Refs #6222
|
|
We need to persist stop IDs in order to properly construct `WayCost`
objects from the costs returned from the TomTom matrix API.
In order to persist stop IDs, my idea here is to group together a point
and its corresponding ID into a bucket. When we later
`#extract_costs_to_way_costs!`, we'll be able to grab the correct ID for
a given coordinate to create a `WayCost` from it.
Here, we create a new `TomTom::Matrix::Point` class that encapsulates a
coordinate and an ID, and build a `Set` of those. I needed an `#eql?`
and `#hash` method on `Point` as described in the `Set` documentation
(https://ruby-doc.org/stdlib-1.9.3/libdoc/set/rdoc/Set.html) in order to
properly maintain a unique set.
Refs #6222
|
|
A new component to the `TomTom` module that asks TomTom's Matrix API
endpoint
(https://developer.tomtom.com/online-routing/online-routing-documentation/matrix-routing)
to compute `WayCost`s. The matrix API will give us all costs between
each pair of coordinates. This will enable us to provide costs for any
combination of points in a journey pattern.
Given a list of `WayCost`s, it will send all points from those costs to
the matrix API and return a list of all non-zero `WayCost`s between all
pairs of coordinates.
`points_from_way_costs()` extracts unique coordinates from the
`WayCost`s.
`points_as_params()` builds a list of points in the format expected by
the matrix API.
The response from the matrix API is formatted as a two-dimensional array
consisting of rows and columns that pair each "origin" point with each
"destination" point. We loop through this matrix and construct new
`WayCost` objects for each pair of coordinates.
At the moment, I haven't figured out how I want to save `WayCost` IDs
when creating the new pairs. Leaving that for later.
Refs #6222
|
|
|
|
|
|
|
|
|
|
|
|
6190 fix consistency issue with calendars
|
|
|
|
Refs #6177 Add control attributes to CC#show
|
|
Refs #6303 Fix published journey identifier label
|
|
Refs #6298 Change companies#new breadcrumb
|
|
af83/6292-compliance-control-sets-organisation-filter
Refs #6292 Fix Compliance Control set organisation filter by adding v…
|
|
Refs #6202 Fix Select CCSet typo
|
|
Refs #6241 Fix Compliance Control set affectation labels
|
|
|
|
When a passing time at a border can be extrapolated from other values.
|
|
|
|
|
|
Link exports to referentials. Refs #6218
|
|
|
|
standard). Refs #6047
|
|
|
|
|
|
|
|
|
|
|
|
|
|
6218 UI for exports
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
