DeploymentPlanner

This is a short description of how the deployment planner works.

It loops through all of the unsuperseded feeds for a given metro and determines whether they overlap the deployment window. If they do and are not disabled or failed to parse, it adds them to the deployment plan if they're not already there. If they don't cover the whole window, it looks backwards to try to find older feeds for this agency, to handle schedule changes. It will also schedule graph rebuilds after GTFS feeds expire, to keep graph size down.

It handles correctly the case of parallel feeds (for example, SEPTA and New Jersey Transit both release separate feeds for bus and rail), as long as they are not stored in the database as superseding each other.

Feeds are automatically expired and cut short when a new feed from the same agency that supersedes the original feed becomes active. This is because many agencies release GTFS without knowing when their next schedule change will be and simply put in a date several years down the line. When they release new GTFS, we cut their old GTFS short on the day before the new starts, and load both into a graph. This way, we can plan trips across a pick change. At 00:30 on the first day of a new schedule, there are some trips already running on the new schedule, while some trips are still running from the previous day's old schedule. All the math is done in agency-local time (as specified in agency.txt); theoretically the cases of a schedule change on a daylight-savings change day and a change in the timezone of an agency are handled correctly (however, OTP/OBA may not handle the first case).

The deployment planner has fairly good test coverage in DeploymentPlanTest.java