output_data_model.md

Output data model

This document describes the data model in which the solutions to the problem instances are expected.

What is a 'solution'?

A solution to a problem instance must contain the following information for each service_intention in the problem instance:

• A choice of exactly one of all possible routes for this train trough its route graph, and
• assigning a time to each event (entry into and exit from route_sections)

For example, a full solution to the sample instance looks as follows:

The data model is much easier than the one for the problem instances. Basically, all one has to specify is a list of route_sections one would like to take and give an entry and exit time for each of them. Let's make this precise:

Data Model of a solution

We keep using this sample solution to the sample instance, pictured above, as an example.

A solution to a problem_instance has the following elements:

• problem_instance_label
• problem_instance_hash
• hash
• train_runs

Let's go through them.

problem_instance_label

The label of the problem_instance that this solution is intended for.

problem_instance_hash

The hash of the problem_instance that this solution is intended for. This is the actual identifier that the grader script will use to check if your solution is valid and compute its score. It is imperative that this field is filled correctly, otherwise the grader will not be able to match your solution to a problem instance.

hash

This field can be used to provide a hash-value for the solution. However, while the field is technically required, its value is not really used in the context of this Challenge. You may enter any fixed integer, e.g. 42, for every solution you submit.

train_runs

This is the actual 'meat' of the solution. Namely, it contains for each service_intention an ordered list of train_run_sections that describe a simple path through the route graph for this train. For each train_run_section it provides a time-of-day for the entry_time and the exit_time.

Our sample solution looks like this:

Translating this into the route-graph picture, we see that the solution picks the following routes for the two service_intentions:

This results in the following train_run_sections for the service_intentions:

• each arc is a train_run_section
• black numbers are the sequence_number of the referred route_section
• the times at the nodes are the event times that the solver assigned to the events

Let's look at the formal model for train_run_sections

train_run_section

A train_run_section is built as follows

Field	Format	Description
entry_time	time of day in HH24:MM:SS	event time for the entry_event into this train_run_section. Note: This time must always be equal to the exit_time of the previous train_run_section
exit_time	time of day in HH24:MM:SS	event time for the exit_event from this train_run_section. Note: This time must always be equal to the entry_time into the next train_run_section
route	text	reference to the id of the route for this service_intention
route_path	text	reference to the id of the route_path in which the route_section represented by this train_run_section is located
route_section_id	text	reference to the particular route_section that this train_run_section represents. It is built by the pattern 'route.id#route_section.sequence_number'. Recall Axiom 4 states that this combination is indeed a primary key for the route sections. For example, in the sample solution above, the first train_run_section for service_intention 111 references route_section 3 in the route 111. Therefore the route_section_id is '111#3' .
sequence_number	positive Integer	an ordering for the train_run_sections. Necessary because the JSON specification does not guarantee that the order in the file is respected when it is deserialized.
section_requirement	text	must be set to the corresponding section_requirement of the service intention if this requirement is to be satisfied on this particular train_run_section. Note: We guarantee (see Axiom 3) that the route graphs in our problem instances are such that whatever route you happen to choose (from any source to any sink node), you will pass each required section_marker exactly once. Actually, we even guarantee, that you will pass them in the same sequence as required by the service_intention. So once you have picked your route, you can just check if the route_section referenced by this train_run_section has a section_marker that also occurs in the service_intention. If so, put this section_marker in this field.