Community Transit Hastus Conversion Tool

The following are some notes on the tool that converts Hastus Schedule/Shape data into GTFS for Community Transit.

The Code is starts at HastusGtfsFactory and is invoked as part of the admin bundle building console via HastusTranslateTask though it can be invoked from the command line via CommunityTransitGtfsMain.

HastusGtfsFactory decomposes the translation from Hastus to GTFS via 6 activities:

1. Agency
2. Stops
3. Routes/Stop Sequences
4. Shapes
5. Schedules
6. Calendars

1) Agency

Generates static text for GTFS agency.txt.

2) Stops

Loads shape file CTBusStops.shp, and parses features as stops using these convention labels:

STOP_ID : GTFS stopId
PRIMARY : primary street name becomes first part of stop name
CROSS : cross street (if present) becomes remaining part of stop name
geometry: x/y lon/lat

The StopId convention is kept intact without manipulation

3) Routes/Stop Sequences

Loads shape file CTRouteStopSequences.shp and parses features as routes using these convention labels:

ROUTE: route name
RT_VAR: variation (MUST match to a subset of PublicTimeTable/PttPlaceInfo/Description)
SCHEDULE: schedule type
$sequenceId: ROUTE - RT_VAR - SCHEDULE

The $sequenceId becomes the id of the RouteStopSequence which will later become the shapeId in 4)

Route stop sequences are parsed from the following labels:

SEQARC: sequence arc
SEQARC_ID: sequence arc id
LENGTH: length
RT_DIR: route direction
ROUTE_DIR: route direction alternate
SCHEDULE: schedule type
STOP_ID: stopId
TIME_PT: Time point
geometry: x/y lon/lat multi-line string

4) Shapes

GTFS Shapes are built by iterating through the stop sequences constructed in 3). The shapeId remains the route stop sequence id with agency pre-pended (an OBA convention).

5) Schedules

GTFS Trips are built by iterating through the public time table elements of all the Hastus XML files.

Multiple public time tables elements are assumed to provide the GTFS direction (inbound/output).

PlaceInfo Trips elements correspond to a GTFS Trip via a one-to-one relationship.

The GTFS tripId is constructed from: timetable booking identifer + place info schedule type + place info id + public time table trip sequence

The route is cross-referenced using the timetable, place info, and public time table trip. If it doesn't exist, it is created:

$routeId: public time table trip route id
$shortName: public time table route id
$long name: public time table route description

The serviceId is generated using the timetable and place info:

$serviceId: public time table booking identifier + place info schedule type

$routeVariation is an attempt to coerce the place info description into a trip distinguisher. In order to do so the place info description is assumed to be of the following format:

Variation A: \\b([a-z]{2})\\b"
Variation B: \\b([a-z]{1})/([a-z]{1})\\b
Variation C: \\b\\d+([a-z]{2})\\b

Stop Sequences are generated by:

routeId + $routeVariation + $scheduleTime

or restated

public time table trip route id + routeVariation + $scheduleType

5.1) Trips

The trip itself looks like this:

$tripId: see above
$directionId: count of public time table
$routeId: see above
$serviceId: see above
$shapeId: see above
$tripHeadsign: place info direction name

5.2) Stop Times

For each trip created, we create stops times:

Time points are sorted by the passing time and indexed by position in pattern

Stop Times are created by looping over the route stop sequence items:

$stop: route stop sequence stop id
$stopSequence: count - first stop sequence
$trip: trip
$time: route stop sequence time time point

6) Calendars

The GTFS calendar.txt is created by the arguments $calendarStartDate, $calendarEndDate, and by examining the scheduleType associated with each serviceId. This map is built up while constructing service Ids.