Still a ways to go before I have all the business rules in place, but I've been working on a code based solution for those who don't want to use the REST API (or rather, need more than 1 request per minute): https://github.com/Shalmezad/tsocgp/tree/master/tsocgp/validation
In Example 9 there is for example a connection with id=2408_18825, the section marker of the section requirement is ZUE_Halt and the onto section marker ZLOE_Halt.
My interpretation of this is now that there must be a "connection" (as defined bythe time constraints) between the chosen path of [15]2408 and the chosen path of 18825 so that the "connected" sections have the section marker ZUE_Halt for the [15]2408 and ZLOE_Halt for the 18825 section.
Is this correct?
Typically, the section_marker of the train "giving" the connection is identical to the section_marker of the train "receiving" it, which corresponds to the fact that a connection typically takes place in one station. However, this is not always so, as this example shows. In this case "ZLOE" is actually a station that is geographically very close to "ZUE", so defining a connection still makes sense.
thanks guys, indeed the hash seems to be wrong. This must be the reason the instance 07 is treated as "not submitted" in the sample submissions.
We'll update the sample submission
By the way, the grader has been updated. You'll now also get a plot like above detailing which instances incurred how much penalties... Give it a try ;)
It is for example stated that for a particular station the minimum stopping time is 24s and also that the resources occupied at that station have a minimum running time of 30 seconds. Now does that mean the train can leave the station after max(24s, 30s) or 54s?
@jordiju @rapsli is the second an exit event takes place exclusive or inclusive in regards to a resource occupation that stops with the exit event? So if (ignoring release times) ServiceIntention A stops using a resource at 08:30:00 can ServiceIntention B start using it at 08:30:00 ?
@manuel-hegner : As business rule #104 states: The time for the entry-event for ServiceIntetion B must be larger or equal to the exit-event for SI A plus the release time. So, if SI A exits the relevant TrainRunSection at 08:30:00 and the release time of the relevant resource were 0, then indeed 08:30:00 would be a valid time for the entry-event for SI B.
Similarly, if the release-time were 17 seconds, then 08:30:17 would be a valid time for entry of SI B. Anythin before 08:30:17 would not be valid.
@DanielLSM : No, the route_section sequence numbers are only unique within a specific route.
@jordiju But again, I am a bit confused, on the worked example, each train has a different route_id, but they are considered as they are in the same DAG. so there is only one DAG per problem instance or there are more? Each route is a subset of the big DAG, is my statement correct?
@DanielLSM Ah, sorry, I understand. In the worked example, they wording "they are the same" is really just short for "they both have their individual DAGs which happen to look exactly the same". There is one DAG per service_intention, not per problem instance.
Yes, you may collect all individual graph for the service intentions into one big DAG for the problem instance, such that each route is a subgraph of the big DAG. However, our routing_graph utility script does not do that (you would then need to encode also the service_intention.id into the ID of the graph nodes, so that nodes belonging to different service intentions can be distinguished).
