-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
core, editoast, python: stop train on next signal instead of OP #10200
base: dev
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## dev #10200 +/- ##
==========================================
- Coverage 81.60% 81.54% -0.07%
==========================================
Files 1067 1049 -18
Lines 105535 104711 -824
Branches 727 727
==========================================
- Hits 86126 85388 -738
+ Misses 19368 19282 -86
Partials 41 41
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
03bbd62
to
101da24
Compare
5a5ff11
to
18a57e2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We keep this flag to true
for review purpose, but before merging, we need to set it to false
#[derivative(Default(value = "true"))] | ||
#[serde(default = "default_stop_at_next_signal")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#[derivative(Default(value = "true"))] | |
#[serde(default = "default_stop_at_next_signal")] | |
#[derivative(Default(value = "false"))] |
fn default_stop_at_next_signal() -> bool { | ||
true | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fn default_stop_at_next_signal() -> bool { | |
true | |
} |
@@ -149,6 +149,7 @@ const useSetupItineraryForTrainUpdate = (trainIdToEdit: number) => { | |||
rolling_stock_supported_signaling_systems: rollingStock.supported_signaling_systems, | |||
rolling_stock_maximum_speed: rollingStock.max_speed, | |||
rolling_stock_length: rollingStock.length, | |||
stop_at_next_signal: true, // TODO: change to false and set to true elsewhere if needed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
stop_at_next_signal: true, // TODO: change to false and set to true elsewhere if needed | |
stop_at_next_signal: false, |
@@ -79,6 +79,7 @@ export const getPathfindingQuery = ({ | |||
rolling_stock_supported_signaling_systems: rollingStock.supported_signaling_systems, | |||
rolling_stock_maximum_speed: rollingStock.max_speed, | |||
rolling_stock_length: rollingStock.length, | |||
stop_at_next_signal: true, // TODO: change to false and set to true elsewhere if needed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
stop_at_next_signal: true, // TODO: change to false and set to true elsewhere if needed | |
stop_at_next_signal: false, |
Questions :
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's the right approach, good job 👍
core/src/main/kotlin/fr/sncf/osrd/api/api_v2/pathfinding/PathfindingBlocksEndpointV2.kt
Outdated
Show resolved
Hide resolved
70217a1
to
bac5a63
Compare
Question : is the type of signalisation (here Because here, the waypoint is moved AFTER the signal, which is not correct (but I only see that behaviour on Could it be also related to the current bug that breaks the projection of intermediary waypoints on the map ? Edit: looks like I was right, but difficult to be sure (the position here is now correct for the end pathstep) |
bac5a63
to
03012e2
Compare
Signed-off-by: Louis Greiner <[email protected]>
Signed-off-by: Louis Greiner <[email protected]>
…serializer Signed-off-by: Louis Greiner <[email protected]>
Signed-off-by: Louis Greiner <[email protected]>
Signed-off-by: Louis Greiner <[email protected]>
Signed-off-by: Louis Greiner <[email protected]>
Signed-off-by: Louis Greiner <[email protected]>
Signed-off-by: Louis Greiner <[email protected]>
Signed-off-by: Louis Greiner <[email protected]>
Signed-off-by: Louis Greiner <[email protected]>
Signed-off-by: Louis Greiner <[email protected]>
Signed-off-by: Louis Greiner <[email protected]>
03012e2
to
9f36ef1
Compare
Closes https://github.com/osrd-project/osrd-confidential/issues/892
Closes https://github.com/osrd-project/osrd-confidential/issues/830
Depends on https://gitlab-repo-res.apps.eul.sncf.fr/dsir/groupedxs-dsir/04735/etl_basic/-/merge_requests/145 for internal use
Analysis of the solution, compared to the default behavior can be seen here
Description
Note : the following screenshots are for review visualization only, nothing will be output in the front-end at the end
The train stops are now shifted the least possible to the next signal position, with a minimal value that would put the tail of the train on the operational point.
Examples
With a
TGV2N2
, 400m trainWith a
83500
, 109m train