XML

XML (extendsible markup language) is a system to describe unstructured data for computers. The main idea is that each item of the data is described right where it shows up instead of somewhere else in the file or even outside it. An XML nodes file would look like

{}
<nodes>
<node id="15" x="123.45" y="678.9" />
...
</nodes>

That is, the information of where the id or the x/y coordinates are is repeated for each entry. This makes for larger files and slower parsing speeds, but the disadvantages are not that big:

• Since this is a standardized method, fast parsers are available.

• The overhead is not more than a factor of two.

• If keywords are repeated often (as they are for our files), compression tools will find that out so that compressed XML files are not much larger than compressed files without XML tags.

In general, parsers of XML files will not break when the input format is extended. For example, when additional keyword-value-pairs are added, they will just be ignored.

The main advantage of XML files is for the description of travelers' plans, where one now does not need all those awkward conventions any more. A route-plans file will for example look like

{}
...
<person id="34">
<trip starttime="8h03" dplink="123" arlink="456" eta="8h33">
<nodes> 23 34 63 62 24 </nodes>
</trip>
</person>
...

This describes a trip from link 123 to link 456, with a starting time at 8h03, and an estimated arrival time at 8h33.

Further information, such as deomgraphic data or activities, can now just be added to the same file structure, e.g.

{}
...
<person id="34" income="10000">
<act type="h" link="123" etime="8h03" />
<trip mode="car" starttime="8h03" dplink="123" arlink="456" eta="8h33" >
<nodes> 23 34 63 62 24 </nodes>
</trip>
<act type="w" link="456" duration="8h" />
<trip mode="car" starttime="16h33" dplink="123" arlink="456" eta="17h00">
<nodes> 24 62 63 34 23 </nodes>
</trip>
<act type="h" link="123" />
</person>
...

This would describe a person with id 34 and an income of 10000, which, at the beginning of the simulation, is doing at ``at-home'' activity, at link 123. At 8h03, the person starts driving to work, where she expects to be at 8h33. The person works for 8 hours, and then drives back home.

This is in principle a very flexible concept. In particular, there are no longer different files for activities, trip requests, (route-)plans, etc; everything is just one file format. For example, the router request (formerly ``trips file'') would just be

{}
...
<person id="34" income="10000">
<act type="h" link="123" etime="8h03" />
<trip mode="car" dplink="123" arlink="456"/>
<act type="w" link="456" duration="8h" />
<trip mode="car" dplink="123" arlink="456"/>
<act type="h" link="123" />
</person>
...

and the router would calculate all trip starting times, estimated arrival times, and sequences of routes.

As an alternative, there could be separate scheduling and routing modules.

The main issue here is that there is absolutely no standardization available yet. It is neither clear which concepts are simple in terms of modeling and simulation, nor which concepts are faithful in terms of human behavior. We will return to some of the latter in Chap. . [[check ... doherty acts scheduling]]