Locking module improvements

[SiggyF]

second step

• [ ] Add real world lock notebook to example book, based on student example
  • [ ] Create graph + lock on fis graph
• [ ] review new modules
• [ ] cherry pick existing modules
• [ ] write the abstract lock / core functionality unit tests
• [ ] manual re-merge the changed modules
• [ ] add real world unit test
• [ ] add schematic lock figure (for terminology)
• [ ] refactor most important parts (add lock complex to network, flexible approach to digraph/multidigraph, make log variants consistent, consider use of HasLockInformation, make variable names more consistent (Wlev vs WLev))
• [ ] Rerun previous simulation (check e.g. if leave_opposite_lineup_area directions are correct)
• [ ] Check code that uses things like current_velocity[2] or current_velocity[-1]. That is unreliable without checks.
• [ ] Extend real world lock notebook to example book
  • [ ] Create schematic graph + lock
  • [ ] Create fis graph based lock
  • [ ] Create Weurt + Graven reconstruction
  • [ ] Create Lock + Salt (IJmuiden)
  • [ ] Create Volkerak + Energy + Compare with AIS energy

[SiggyF]

There are some differences between the SALTI core and the current main core. For each of these we have to make a decision on how to deal with it.

• [ ] Sailing over geometry generates multiple events as sub edge steps. Suggested approach: Checked if subedges are needed (could have been needed for energy module). Does not seem to be the case. Suggestion: remove it (compute distance and velocity and time).
• [ ] pass_edge is called before sailing in main. In the SALTI branch the speed and distance are changed while sailing through the lock. In the main branch the move is done with one speed. Suggested possible implementation: add move as a pass_edge function. If you want it to behave different you can remove the default on_pass_edge move function. Discuss in team session for possible implications.. (test concept branch feature/move-inversion)
• [ ] on_pass_edge function in SALTI branch also computes the sailing distance and sailing speed. See suggestion above.
• [ ] In the main branch the distance is computed based on the geometry (using wgs84 geoid). In SALTI it is derived from an edge property. Suggested solution: always use wgs84 geoid.
• [ ] In SALTI branch a vessel traffic service computes the vessel speed and duration. In main branch it is a property of the ship. Suggested solution: You can already use a custom compute_v. You can override that and call the vessel traffic service.
• [ ] The SALTI branch supports geometry length in m and does not expect the coordinates to be in wgs84. This can have performance benefits. I would suggest to document the way that we store the length in m. And, if length is not available, I would suggest to keep using the current implementation based on the spherical length of the geometry. I think the FIS network uses length_m and SALTI uses ['info']['length']. I would prefer length_m. But not a strong opinion.
• [ ] Standardize or at least describe normative graph properties -> Fedor
• [ ] Make logs consistent and support all relevant information types (events, geospatial, timeseries, critical path) -> Fedor in agreement with user community