Don't display a vehicle as invalid if it is a block overload #514
Conversation
Codecov Report
@@ Coverage Diff @@
## master #514 +/- ##
==========================================
+ Coverage 97.47% 97.59% +0.11%
==========================================
Files 170 170
Lines 3805 3818 +13
Branches 523 523
==========================================
+ Hits 3709 3726 +17
+ Misses 92 88 -4
Partials 4 4
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
- What if we have a block overload that really is off course?
- If block overloads are causing trip id discrepancies, could we detect this case directly from the trip ids instead of from the block id? (And if so, could that even be smart enough to detect an off course overload?)
- Will this be fixed by GTFS updates or Swiftly loading new GTFS files? If so, will that be soon enough that we should wait for that instead of merging this fix?
Approved in case this is urgent and needs to go now.
lib/realtime/vehicle.ex
Outdated
| @@ -230,6 +234,9 @@ defmodule Realtime.Vehicle do | |||
| end | |||
| end | |||
|
|
|||
| @spec block_overload?(Block.id()) :: boolean | |||
| def block_overload?(block_id), do: String.match?(block_id, ~r/.+-OL.+/) | |||
|
Oh hold on. I reread the asana task:
We don't care about predictions. Will it also not provide trip assignments? If so, this might not be enough to show these vehicles correctly. Busloc provides a trip assignment but not a stop assignment, so we wouldn't be able to show them on the ladder. |
arkadyan
force-pushed
the
mss-handle-block-overloads
branch
3 times, most recently
from
699b4ee to
b1f83d9
Compare
|
@skyqrose I've updated this substantially now that we are seeing this data come through the pipeline. There are several new commits before the ones that were there. Swiftly is giving us assignments, so we are able to draw the vehicles on the ladder. |
arkadyan
force-pushed
the
mss-handle-block-overloads
branch
from
c39c52f to
d6adafa
Compare
There was a problem hiding this comment.
It's unclear to me how having a block overload will cause a vehicle to show up as off course: If Swiftly is able to still assign a stop and trip to a vehicle, then we should still be able to use that trip to check if a vehicle is on course, so why is checking for an overload needed?
lib/realtime/vehicle.ex
Outdated
| @@ -189,6 +192,7 @@ defmodule Realtime.Vehicle do | |||
| via_variant: via_variant, | |||
| bearing: VehiclePosition.bearing(vehicle_position), | |||
| block_id: block_id, | |||
| block_id_with_overload: block_id_with_overload, | |||
There was a problem hiding this comment.
It looks aside from the off course check, this value isn't used anymore, so we could take the field out of the struct.
There was a problem hiding this comment.
At least for the moment I want to leave it on the client so we can debug the data in the browser without having to add breakpoints in the server or whatever.
There was a problem hiding this comment.
I don't like the idea of adding a field to the vehicle struct just for debugging. What about making a data_discrepancy for block_id? (Then it'd also show up when the debug flag is on.)
There was a problem hiding this comment.
Ok, changed to that.
|
@skyqrose Swiftly is giving us the stop assignment, but not necessarily the right trip or other info, but we can get those from Busloc. |
|
@skyqrose Thanks, made a couple updates. |
arkadyan
force-pushed
the
mss-handle-block-overloads
branch
from
8805b14 to
09fc489
Compare
Asana ticket: Don't display a vehicle as invalid if it is a block overload