Transportation Infrastructure Overlay

The transportation infrastructure overlay consists of a demand model, a route graph, vehicle model, and environmental factors.

Demand Model

As an exercise, let us consider some of the data elements we would want a schema to include that would lend themselves to a good schedule optimizer. Each value of interest might need to be expressed and measured in different forms, to indicate whether its value has been projected from previous data, predicted based on current known conditions, or is actually measured after the fact. Uncertainties need to be attached to projections and predictions so that data elements can be used for contingency planning.

A good starting point for the demand model formulation is to list out the information a passenger or piece of cargo wishing to traverse the system would want to convey to us. The simplest schema would consist of a source location, a destination, and a desired time of arrival or departure. But much other information could also be of use:

1. Unique identifier: every database needs to refer to its elements by some unique ID at some point. Many privacy rights activists cringe every time a system forces them to assume one that is traceable back to them. It's beyond the scope of this paper to address the requirements of what can or cannot be gleaned or pieced together by data mining this information. But suffice it to say that privacy and security concerns could be met by currently existing encryption, digital signature, and authentication technology. As an example, suppose that after payment, a unique system identifier was associated with an encrypted, one-time signature generated by the passenger's private key. Only that passenger would be able to decrypt the digital fingerprint that associated their personal identity information with the unique ID stored in the passenger roster. They would be able to prove that it was they who generated that unique signature ID at a later time, say, if they needed an alibi. However, government or private entities that somehow got a hold of the passenger roster wouldn't be able to run searches, such as ``give me a list of all the people who traveled to this shopping mall'' or ``list all the places John has traveled to lately.'' For more restrictive governments or law enforcement / monitoring agencies, all or part of this data could be exposed through a key escrow system. The point is that all of this framework exists and should be set up from the inception of the system, since the security and authentication model will likely be deeply ingrained into how the rest of the software systems operate. The main problem that most privacy advocates see is that the minimum basic anonymity and data privacy safeguards are simply not being deployed into the systems of today.

2. Schedule constraints / flexibility : optimization thrives on having some slack or flexibility in its constraints. We could achieve more optimal schedules if only passengers had a way to more adequately express constraints like:

• What range of times could they be expected to arrive at their destination? e.g. Not later than 9:00?
• How much extra would passengers be willing to pay to reduce their time in transit, say be giving them preferential treatment in the schedule optimization algorithm? In the same vein, would any of them be interested in paying less to reduce their ``pull'' on the scheduling algorithm, such that their scheduling might form by economically ``hitchhiking'' around on the empty seats left over in schedules generated to serve passengers paying for higher priority routing?
• What kind of safety factors or time buffers are passengers comfortable with? Would they be willing to run through an airport to make a tighter connection?

3. Accessibility needs : handicapped passengers could make special requests to suit their situation. This could help budget transfer time and resources better. For example, instead of equipping all of the vehicles in a fleet with minimal accessibility features at great expense, a bus system could have 5% of their fleet be fully equipped and serve handicapped passengers as their first priority.

Cargo would have much of the same properties as passengers, perhaps a few more to encode other special handling instructions, hazmat designations, and so forth. As cargo might spend significantly longer stretches of time in the system between warehouses and transfer stations, they might have more stringent tracking and tagging requirements, as well as more flexibility in routing preferences, especially between low priority bulk and high priority overnight shipments.

Security is an important concern in a system that can be misused for malicious purposes. While we could easily set up detection stations at central transfer nodes to screen for explosive and hazardous materials and other contraband, we'd want to take another step to ensure that the sender can be traced and held accountable for the contents of a package. The system should require some form of digital signature and authentication from the sender in order to enter a package into the system.

Having all this passenger and cargo data pretty much takes care of knowing the transportation system demand inputs.

Route Graph

The next set of standardized data should describe how the transit network itself is set up to handle the demands placed on it. Every transit system could be expressed as a network, so we will liberally apply terms from the networking field to describe some of these concepts. The first assumption we'll have to make is that any transit system could be expressed and modeled as a collection of nodes and connector links. They might vary significantly in complexity and level of detail between transit systems, but they all need to be able to ``plug in'' to each other for inter-modal optimization to work properly.

A simple light rail or tram network might consist of a few dozen stations connected by a single track. On the other end of the spectrum, a metropolitan road network modeled in detail would have thousands of connective paths, links to probably all of the other nodes of transit, relatively few fixed source and destination nodes, and likely not enough user planning data will ever be made available to predict traffic congestion resulting from construction, weather, accident, or just plain rush hour delays.

Minimal Transport Network Representation. The minimal elements needed to represent this transportation network would include:

• A unique node identifier
• A geographic node location, represented in a standard reference frame such as the WGS-84 latitude, longitude, and altitude used by GPS.
• A connectivity matrix, minimally of transit times between node pairs. A special value would indicate that certain node pairs (probably most of them) are not connected at all. This might even be digested from much more complicated routing algorithms, such as street navigation systems. The connectivity matrix will need adjustments over time, to schedule in planned closures for maintenance, or new routes opening up at particular times.
• Buffer and storage nodes, such as maintenance bays or taxiway queues. These might have special properties with regards to what activities or states can and cannot take place.

Vehicle Model

In order to actually traverse this network, a transit system ultimately needs vehicles. Each vehicle would have associated with it:

• A physical location within the network, whether a geographic location in transit, or a position in a queue waiting for arrival at a station node, or occupying a storage or a maintenance bay.
• A passenger or cargo capacity
• A set of rules governing how fast it can navigate across its network, how long it takes to load and unload, etc.
• Various maintenance details, such as fuel supply, crew refresh schedules, and at least some indicator of the probability that it will reach its destination without breaking down along the way or running late for some other reason.

The system would need a way to introduce its own arbitrarily fixed schedule or other constraints. This could be required merely as a way to allow legacy timetable-based systems to nominally interact with an optimized scheduling system. While we could squeeze a more optimal solution by imposing fewer constraints, for various reasons (suppose a communications equipment failure prevented us from giving a last-minute reroute to a vehicle), we need some way of communicating and enforcing pre-existing or immutable schedule constraints. This mechanism probably would be similar to one we'd use for introducing planned or unscheduled maintenance stops.

Environmental Factors

The last major category that would affect the performance of the system might include ``environmental'' factors. These factors could either be predicted in advance with some degree of certainty, or suddenly evolving events such as accidents or breakdowns that require a reformulation of the optimization problem to mitigate.

Weather conditions can have a predictable effect on a system. Updates on rain or snowstorms should be able to make their way into the system so it can plan on having some degree of constrained capacity in advance. Airports can plan to shut down for a few hours while ``convective weather cells'' (thunderstorms) pass by overhead. As better forecast data has become available, air traffic control centers have actually been able to institute ground delay programs for aircraft all the way at their points of departure, so they don't end up circling in holding patterns near the destination airport, waiting for the inclement weather to abate. Such techniques for contingency planning based on externally available data could make their way into streamlining other forms of transportation such as road and rail, albeit less dramatically.

These types of entries could manifest themselves as time-dependent changes to the network connectivity matrices and node constraints. Each cell would have a probable new value for transit time on that link, accompanied by probable start and end times of that effect.