| Age | Commit message (Collapse) | Author |
|
#6226
|
|
6226 Add a button to automatically create opposite routes
|
|
|
|
|
|
We no longer return a redirect, but a JSON message instead
|
|
|
|
|
|
|
|
|
|
|
|
As well as an helper to render them in a partial
|
|
af83/6222-route-way-costs--use-TomTom-matrix-API-instead-of-batch
Route way costs use tom tom matrix api instead of batch. Refs #6222
|
|
New uniqueness validation for ccblocks
|
|
Remove `current_functional_scope`. Refs #4658
|
|
Refs #6258 @1
|
|
Refs #6258 associate calendars with current organisation
|
|
begin_of_association_chain in controller
|
|
|
|
set_defaults method
|
|
|
|
|
|
|
|
Refs #6259 Only send mails to users from same workgroup after create/…
|
|
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
|
|
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
|
|
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
|
|
|
|
|
|
standard). Refs #6047
|
|
|
|
|
|
of shared calendars
|
|
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
|
|
af83/6095-route--calculate-distance-and-time-cost-between-stops
Calculate distance and time cost between Route stops. Refs #6095
|
|
6146 Line state update
|
|
|
|
|
|
|