Network Analyst public transit data model

Available with Network Analyst license.

To model schedule-based public transit service in a network dataset, the network must include a specific set of tables and feature classes, with a particular schema, that define the transit stops and lines as well as the dates and times when transit service is available. These tables and feature classes comprise the Network Analyst public transit data model and are described below.

These tables and feature classes can be used in the network dataset by time-based cost attributes configured to use the Public Transit evaluator, which calculates the travel time along transit lines at a specific time of day based on the public transit schedules defined in the data model.

Note:

A set of valid public transit data model tables and feature classes can be created automatically from General Transit Feed Specification (GTFS) public transit data by running the GTFS To Public Transit Data Model and Connect Public Transit Data Model To Streets geoprocessing tools. The complete workflow for creating such a network dataset is described in Create and use a network dataset with public transit data.

The Network Analyst public transit data model consists of four feature classes that must be located in the feature dataset where the network dataset will be created and seven tables that must be located in that feature dataset's parent geodatabase. The data must be contained in a file geodatabase or an enterprise geodatabase; the public transit data model does not support shapefiles. Additionally, because the data model requires feature classes and tables with specific names, it's not possible to include more than one set of public transit data model feature classes and tables in the same geodatabase. You can include data from more than one public transit agency in the same set of feature classes and tables, but you cannot have more than one separate set of feature classes and tables in the geodatabase.

The following table summarizes the data model feature classes and tables and the relationships between them:

Public transit data model feature classes and tables

Name	Description	Type	Required
Stops	Defines the location and characteristics of public transit stops. The Stops feature class is required by the data model to adequately model a public transit system; however, it's not directly used by the Public Transit evaluator.	Feature class	Y
StopsOnStreets	Defines the locations where passengers would access transit stops from the streets or sidewalks. The primary purpose of this feature class is to ensure proper network connectivity between the streets and transit lines. The StopsOnStreets feature class is not required by the data model and is not used by the Public Transit evaluator, but it's useful for establishing network dataset connectivity.	Feature class	N
StopConnectors	Creates a connection between a stop and its street location as defined by its associated StopsOnStreets feature. The primary purpose of this feature class is to ensure proper network connectivity between the streets and transit lines. The StopConnectors feature class is not required by the data model and is not used by the Public Transit evaluator, but it's useful for establishing network dataset connectivity.	Feature class	N
LineVariantElements	Polyline features defining the public transit lines. Each LineVariantElements feature directly connects a pair of adjacent stops. In the network dataset, the LineVariantElements edge source should use the Public Transit evaluator in cost attributes to model actual public transit travel time according to the scheduled service. The Public Transit evaluator will calculate the travel time along a line variant element at a specific time of day based on the public transit schedules by querying the various public transit data model tables. The length and shape of line variant elements are not used by the Public Transit evaluator, so the feature geometry doesn't matter.	Feature class	Y
Lines	Defines the general characteristics of public transit lines or routes.	Table	Y
LineVariants	Defines variations on lines. For example, a transit line may have two different end stations, with some trips going to one end station and the other trips going to the other end station. Each of these would be a separate line variant. Each line variant is composed of line variant elements.	Table	Y
Schedules	Defines unique patterns of travel times associated with line variants. For example, suppose that during rush hour, it takes five minutes for the bus to drive between each stop along the transit line, but during off-peak hours, it takes only three minutes to drive between each stop. The Schedules table would contain an entry for the five-minute times and another entry for the three-minute times.	Table	Y
ScheduleElements	Defines the travel times for a schedule along each line variant element that is part of the line variant with which the schedule is associated. A sequence of schedule elements defines the travel times for a corresponding sequence of line variant elements for a particular schedule.	Table	Y
Runs	Defines specific start times when a transit trip begins service using the travel time pattern defined by a particular schedule.	Table	Y
Calendars	Defines the days of the week and date ranges when public transit service runs. The Calendars table is required, but it does not have to have any rows if you do not want to define regular transit service. If the table is empty, the CalendarExceptions table must be populated. The tables can also be used together.	Table	Y
CalendarExceptions	Defines exceptions to the regular service, such as specific dates when public transit service is added or removed. The CalendarExceptions table is required, but it does not have to have any rows if you do not want to define any exceptions to the regular transit service. If the table is empty, the Calendars table must be populated. The tables can also be used together.	Table	Y

See a larger version of the data model.

Feature classes

The feature classes in the data model can be used as source feature classes in the network dataset. The Stops and StopsOnStreets feature classes will be junction sources, and the LineVariantElements and StopConnectors feature classes will be edge sources. In the network dataset, the LineVariantElements edge source, representing the transit line segments, should use the Public Transit evaluator in time-based cost attributes to model public transit travel time according to the scheduled service. Connectivity groups can be used to control travel between the streets and transit lines by way of stops and connector features.

Stops

The Stops feature class defines the location and characteristics of public transit stops. It's required by the data model to adequately model a public transit system; however, it's not directly used by the Public Transit evaluator.

The Stops feature class is equivalent to the GTFS stops.txt file.

The following table describes the schema of the Stops feature class:

Stops

Field name	Description	Type	Required	Nullable
ObjectID	The ObjectID of the table row.	ObjectID	Y	N
Shape	The point shape defining the location of the stop.	Shape	Y	N
ID	The unique ID of the transit stop.	Long	Y	N
GStopID	The GTFS stop_id of the stop. This field is for informational purposes only.	Text	N	Y
GStopType	Indicates whether this stop represents a regular public transit stop, a parent station containing one or more regular stops, or a station entrance. The possible values are as follows: 0 (or Null)—A regular public transit stop or platform where passengers board or exit the transit vehicle 1—A station that houses one or more regular stops but does not, itself, have any transit service 2—A station entrance that defines the location where passengers can enter the station from the street or sidewalk If a stop is housed inside a station, the ParentID field must be populated with the ID value of another stop that represents the parent station of this stop. The parent station feature must have a GStopType value of 1, and the stop must have a GStopType value of 0 (or Null). Parent stations cannot be parents of other parent stations. If a feature represents a station entrance (GStopType 2), the ParentID field must exist and must be populated with the ID value of another stop that represents the parent station for which this feature is an entrance. A station entrance cannot have a regular stop as its parent. Only parent stations can have station entrances. If the GStopType field is not included in the table, all stops will be treated as regular public transit stops (GStopType 0). In this circumstance, any values in the ParentID field will be ignored. The GStopType field is equivalent to the GTFS location_type field in the stops.txt file.	Short	N	Y
ParentID	The ID value of the current stop or station entrance's parent station. The stop with the referenced ID value should have a GStopType value of 1.	Long	N	Y
GStopParen	The GTFS stop_id of the stop or station entrance's parent station. This field is for informational purposes only.	Text	N	Y
GWheelchairBoarding	Indicates whether the stop, station, or station entrance is wheelchair accessible. The possible values are as follows: 0 (or Null)—No information about whether this stop, station, or station entrance is wheelchair accessible is specified. 1—The stop, station, or station entrance is wheelchair accessible. 2—The stop, station, or station entrance is not wheelchair accessible. If the feature represents a stop (GStopType 0) or station entrance (GStopType 2) and the GWheelchairBoarding value is 0 or Null, the feature inherits its GWheelchairBoarding value from the parent station designated in the ParentID field, if any. The GWheelchairBoarding field is equivalent to the GTFS wheelchair_boarding field in the stops.txt file.	Short	N	Y

StopsOnStreets

The StopsOnStreets feature class defines the locations where passengers can access transit stops from streets or sidewalks. The StopsOnStreets features can represent the locations of station entrances, or they can represent the closest point intersecting a street or sidewalk to the stop's location to ensure network connectivity.

The StopsOnStreets feature class is not required by the data model, but it's helpful in establishing proper network dataset connectivity, since stops are unlikely to fall directly on top of streets. If you intend to model travelers walking along the streets and using the public transit system, you need some way to connect the transit lines with the streets in a controlled manner, so use of this feature class is recommended.

The StopsOnStreets feature class doesn't have a required schema. If you create this feature class using the Connect Public Transit Data Model To Streets tool, it will have the same schema as the Stops feature class. However, since this feature class is not used by the Public Transit evaluator, you can use whatever fields are best suited for what you're modeling.

StopConnectors

The StopConnectors feature class defines polyline features to connect stops with streets by way of corresponding StopsOnStreets features. The primary purpose of this feature class is to ensure proper network connectivity between the streets and transit lines. This allows a traveler to walk along the streets, access a transit stop, use the scheduled transit service along a transit line (a LineVariantElements feature), exit the transit line at another stop, and return to the streets to continue walking to the destination.

Transit stops can be connected to street features in the network dataset. Part 1 shows a transit stop (orange circle) along a transit line (blue line). Part 2 shows a vertex (green triangle) added to the closest point of the closest street feature (black line). Part 3 shows a copy of the stop snapped to the street feature (purple circle). Part 4 shows a connector line generated to connect the stop to the street. Pedestrian travel between the streets and the transit line is modeled using these connections and the connectivity policy on the network dataset.

The StopConnectors feature class is not required by the data model and isn't used by the Public Transit evaluator. However, since stops are unlikely to fall directly on top of streets, a connector is recommended to ensure connectivity between the transit lines and streets.

The following table describes the schema of the StopConnectors feature class:

StopConnectors

Field name	Description	Type	Required	Nullable
ObjectID	The ObjectID of the table row.	ObjectID	Y	N
Shape	The polyline shape of the feature. The direction of digitization of the stop connector features should be from the stops toward the streets.	Shape	Y	N
StopID	The ID field value of the stop this StopConnectors feature connects to the streets.	Long	N	Y
ConnectorType	Indicates the type of connection this feature makes between the stop and the streets. The ConnectorType value indicates whether this connector line represents a direct connection between the stop and the street, a connection from the stop to its parent station, or a connection from a parent station to a station entrance. The possible values are as follows: 0—A direct connection between a stop (GStopType 0) or parent station (GStopType 1) and the street 1—A connection from a stop (GStopType 0) to its parent station (GStopType 1) 2—A connection from a parent station (GStopType 1) to a station entrance (GStopType 2) A stop with a parent station is shown. The stop (orange circle) connects to the parent station (blue square) using a connector line (gray line) with ConnectorType 1. The parent station connects to the street using a connector line with ConnectorType 0. A parent station with explicitly defined station entrances is shown. The stops (orange circles) connect to the parent station (blue square) using connector lines (gray lines) with ConnectorType 1. The parent station connects to the streets at the station entrance locations (green squares) using connector lines with ConnectorType 2. This field is not required, but it can be helpful for setting up evaluators on cost or restriction attributes. For example, your cost attribute could add different amounts of walk time depending on the ConnectorType field value.	Short	N	Y
GWheelchairBoarding	Indicates whether the path between the stop and the street represented by this connector line is wheelchair accessible. The possible values are as follows: 0 (or Null)—No information about whether a wheelchair can travel from the street to the stop using this connector line is specified. 1—The path from the stop to the street represented by this connector line is wheelchair accessible. 2—The path from the stop to the street represented by this connector line is not wheelchair accessible. This field is helpful for creating restriction attributes in the network dataset to model passengers traveling with wheelchairs.	Short	N	Y

LineVariantElements

The LineVariantElements feature class defines polylines representing the public transit lines. Each line variant element represents travel along a transit line between two adjacent transit stops.

In the network dataset, the LineVariantElements edge source should use the Public Transit evaluator in cost attributes to model public transit travel time according to the scheduled service. The Public Transit evaluator calculates the travel time along a line variant element at a specific time of day based on the public transit schedules by querying the various public transit data model tables. The length and shape of line variant elements aren't used by the Public Transit evaluator, so the actual geometry doesn't matter.

The following table describes the schema of the LineVariantElements feature class:

LineVariantElements

Field name	Description	Type	Required	Nullable
ObjectID	The ObjectID of the table row.	ObjectID	Y	N
Shape	The polyline shape of the transit line segment. The length and shape of the line feature aren't used by the Public Transit evaluator to calculate the travel time. Rather, the travel time is derived from the public transit schedules stored in the data model tables. Consequently, although the line variant elements must have shapes to model connectivity in the network dataset, the specific shapes are irrelevant for the travel time calculation. If you create your data model tables from GTFS data using the GTFS To Public Transit Data Model tool, the line variant elements will be simple straight lines connecting adjacent transit stops and will not represent the geographic paths traveled by vehicles in the transit system.	Shape	Y	N
LineVarID	The ID field value of the line variant of which this line variant element is a part. A line variant consists of an ordered sequence of line variant elements that connect a specific sequence of transit stops along a transit line.	Long	Y	N
SqIdx	A line variant consists of an ordered sequence of line variant elements that connect a specific sequence of transit stops along a transit line. The SqIdx field represents the sequence along the transit line where this line variant element falls, starting with 1. For example, if a line variant consists of 10 line variant elements, the SqIdx of the first line variant element will be 1. The SqIdx of the second line variant element in the line variant will be 2, and the SqIdx of the last (tenth) line variant element will be 10. The SqIdx values in the ScheduleElements table must match the SqIdx values defined here for the line variant elements.	Short	Y	N
FromStopID	A line variant element represents travel along a transit line between two adjacent transit stops. The FromStopID field indicates the ID field value of the stop from which the transit service along this line variant element departs. Transit service along this line variant element travels from the FromStopID to the ToStopID.	Long	N	Y
ToStopID	A line variant element feature represents travel along a transit line between two adjacent transit stops. The ToStopID field indicates the ID field value of the stop that the transit service along this line variant element arrives at or travels to. Transit service along this line variant element travels from the FromStopID to the ToStopID.	Long	N	Y

Tables

The tables in the data model define the public transit schedules. These tables are used by the Public Transit evaluator to determine the travel time along a LineVariantElements feature at a specific time of day based on the scheduled transit service.

Lines

The Lines table defines transit lines or routes and their characteristics. A line is equivalent to a GTFS route.

Two transit lines are shown, each with a unique ID value.

The following table describes the schema of the Lines table:

Lines

Field name	Description	Type	Required	Nullable
ObjectID	The ObjectID of the table row.	ObjectID	Y	N
ID	The unique ID of the transit line.	Long	Y	N
GRouteID	The GTFS route_id of the line. This field is for informational purposes only.	Text	N	Y
GRouteType	The mode of public transit that this line represents. The possible values are as follows: 0—A tram, streetcar, light rail, or any other type of transit service that uses tracks at street level 1—A subway, metro, or other underground transit service 2—A long-distance rail service 3—A fixed-route bus or van service that operates on the streets 4—A ferry service 5—A cable car that runs at street level and is pulled by a cable 6—A gondola or suspended cable car 7—A funicular or other rail system on a steep incline 11—A trolleybus powered by overhead electrical wires 12—A monorail service The GRouteType field is equivalent to the GTFS route_type field in the routes.txt file.	Short	N	Y

LineVariants

The LineVariants table defines variations on lines. For example, a transit line may have two different end stations, with some trips going to one end station and the other trips going to the other end station. A line variant consists of an ordered sequence of line variant elements that connect a specific sequence of transit stops along a transit line.

The two line variants in this illustration have the same LineID value, but they are separate line variants, each with their own ID value, because they go to different end stations.

The following table describes the schema of the LineVariants table:

LineVariants

Field name	Description	Type	Required	Nullable
ObjectID	The ObjectID of the table row.	ObjectID	Y	N
ID	The unique ID of the line variant.	Long	Y	N
LineID	The ID field value of the row in Lines to which this line variant belongs. Multiple line variants can have the same LineID, each one representing a different pattern of line variant elements that belongs to a given line.	Long	Y	N
GDirectionID	A numerical code indicating the direction of travel along the line this line variant represents, such as inbound or outbound. This field is purely descriptive and does not impact routing. It corresponds to the GTFS direction_id field. The possible values are as follows: 0—Travel in one direction 1—Travel in the other direction	Short	N	Y
GShapeID	The GTFS shape_id value to which this line variant corresponds. This field is for informational purposes only.	Text	N	Y

Schedules

The Schedules table defines unique patterns of travel times associated with line variants. For example, perhaps during rush hour, it takes five minutes for the bus to drive between each stop along the transit line, but during off-peak hours, it takes only three minutes to drive between each stop. The Schedules table would contain an entry for the five-minute times and another entry for the three-minute times. The individual components of the schedule are defined in the ScheduleElements table. Schedules are specific to line variants.

The following table describes the schema of the Schedules table:

Schedules

Field name	Description	Type	Required	Nullable
ObjectID	The ObjectID of the table row.	ObjectID	Y	N
ID	The unique ID of the schedule.	Long	Y	N
LineVarID	The ID field value of the row in the LineVariants table with which this schedule is associated.	Long	Y	N

ScheduleElements

The ScheduleElements table defines the travel times along each line variant element for a particular schedule. An ordered sequence of schedule elements defines the travel times for a corresponding sequence of line variant elements for a particular schedule. The ScheduleElements table must contain a sequence of rows for each row in the Schedules table.

Each schedule is associated with a line variant and is composed of schedule elements. The schedule elements correspond to the line variant elements of the line variant. In this illustration, two schedules describe the travel times along the same line variant. The travel time along the line variant elements is different, as described by the schedule elements belonging to each schedule.

The following table describes the schema of the ScheduleElements table:

ScheduleElements

Field name	Description	Type	Required	Nullable
ObjectID	The ObjectID of the table row.	ObjectID	Y	N
ScheduleID	The ID field value of the row in the Schedules table to which this schedule element belongs. A schedule consists of an ordered sequence of schedule elements.	Long	Y	N
SqIdx	A schedule consists of an ordered sequence of schedule elements, each of which matches a corresponding line variant element for the line variant referenced by both the Schedules table and the LineVariantElements feature class. The SqIdx field represents the sequence of the line variant element along the transit line to which this schedule element refers, starting with 1. For example, if a line variant consists of 10 line variant elements, the SqIdx of the first line variant element will be 1. The SqIdx of the second line variant element in the line variant will be 2, and the SqIdx of the last (tenth) line variant element will be 10. The corresponding SqIdx values for each schedule element must match the SqIdx values in the LineVariantElements feature class. In the example above, suppose the line variant has a particular schedule associated with it. The first schedule element of that schedule must have a SqIdx value of 1, the second must have a value of 2, and the last (tenth) must have a value of 10, just like the line variant elements. If the aforementioned line variant has an additional schedule associated with it, the ScheduleElements table must contain an additional sequence of rows with the same sequence of SqIdx values defining the travel times associated with the additional schedule.	Short	Y	N
Departure	The number of minutes since 0 that the transit vehicle departs the originating stop of the line variant element with the same LineVarID as the schedule and SqIdx of this schedule element. If the transit trip departs this stop 20 minutes after departing the first stop of the entire line, the Departure value is 20. The Departure value of a schedule element with a SqIdx value of 1 must always be 0.	Double	Y	N
Arrival	The number of minutes since 0 that the transit vehicle arrives at the terminating stop of the line variant element with the same LineVarID as the schedule and SqIdx of this schedule element. If the transit trip arrives at this segment's terminating stop 23 minutes after departing the first stop of the entire line, the Arrival value is 23.	Double	Y	N

Runs

The Runs table defines specific start times when a transit trip begins service along a sequence of line variant elements using travel times defined by a particular schedule. A run is equivalent to a GTFS trip. The Runs table also defines whether wheelchairs and bicycles can be accommodated on the particular transit vehicle servicing the route at this time of day.

The line variant shown here has a schedule element associated with it (the purple numbers). Each run designates a time of day when the schedule's pattern of travel times is used, and this in turn determines the times of day when transit service travels along each line variant element of the line variant.

The following table describes the schema of the Runs table:

Runs

Field name	Description	Type	Required	Nullable
ObjectID	The ObjectID of the table row.	ObjectID	Y	N
ID	The unique ID of the run.	Long	Y	N
ScheduleID	The ID field value of the row in the Schedules table to which this run belongs. This defines the pattern of travel times that this run will follow.	Long	Y	N
StartRun	The number of minutes since midnight that the transit vehicle departs from the first stop. For example, if the run begins at 8:00 a.m., the StartRun value should be 480, since 8:00 a.m. is 8 hours, or 480 minutes, since midnight.	Double	Y	N
GTripID	The GTFS trip_id with which this run is associated. This field is for informational purposes only.	Text	N	Y
CalendarID	The ID field value of the row in the Calendars table and the corresponding CalendarID field value in the CalendarExceptions table that defines the weekdays or dates when this run is in service.	Long	Y	N
GWheelchairAccessible	Indicates whether the run is wheelchair accessible. The possible values are as follows: 0 (or Null)—No information about whether this run is wheelchair accessible is specified. The Public Transit evaluator will treat runs with this value as usable when the Traveling with a wheelchair attribute parameter is set to True. 1—The run is wheelchair accessible. The Public Transit evaluator treats runs with this value as usable when the Traveling with a wheelchair parameter is set to True. 2—The run is not wheelchair accessible. The Public Transit evaluator treats runs with this value as restricted when the Traveling with a wheelchair parameter is set to True. This field is optional. If the field is not present, the Public Transit evaluator treats all runs as usable by travelers with wheelchairs. The GWheelchairAccessible field is equivalent to the GTFS wheelchair_accessible field in the trips.txt file.	Short	N	Y
GBikesAllowed	Indicates whether bicycles are allowed on this run. The possible values are as follows: 0 (or Null)—No information about whether this run allows bicycles is specified. The Public Transit evaluator treats runs with this value as usable when the Traveling with a bicycle parameter is set to True. 1—The run allows bicycles. The Public Transit evaluator treats runs with this value as usable when the Traveling with a bicycle parameter is set to True. 2—The run does not allow bicycles. The Public Transit evaluator treats runs with this value as restricted when the Traveling with a bicycle parameter is set to True. This field is optional. If the field is not present, the Public Transit evaluator treats all runs as usable by travelers with bicycles. The GBikesAllowed field is equivalent to the GTFS bikes_allowed field in the trips.txt file.	Short	N	Y

Calendars

The Calendars table defines the days of the week and date ranges when public transit service runs.

When solving network analyses with specific dates, the Public Transit evaluator considers the date range defined by the StartDate and EndDate fields in the Calendars table. When solving network analyses with a generic weekday, the StartDate and EndDate fields are ignored, and only the weekday fields, such as Monday, are used to define the transit service operating on the day of the analysis.

This table is required by the data model, but it does not have to have any rows if you do not want to define regular transit service. However, either Calendars or CalendarExceptions must be populated with rows. If both Calendars and CalendarExceptions are populated, CalendarExceptions modifies the regular service defined in Calendars.

The following table describes the schema of the Calendars table:

Calendars

Field name	Description	Type	Required	Nullable
ObjectID	The ObjectID of the table row.	ObjectID	Y	N
ID	The unique ID of the calendar.	Long	Y	N
GServiceID	The GTFS service_id with which this calendar is associated. This field is for informational purposes only.	Text	N	Y
Monday	Indicates whether runs with this CalendarID value operate on Mondays. The possible values are as follows: 0—There is no service on this day of the week. 1—There is service on this day of the week.	Short	Y	N
Tuesday	Indicates whether runs with this CalendarID value operate on Tuesdays. The possible values are as follows: 0—There is no service on this day of the week. 1—There is service on this day of the week.	Short	Y	N
Wednesday	Indicates whether runs with this CalendarID value operate on Wednesdays. The possible values are as follows: 0—There is no service on this day of the week. 1— There is service on this day of the week.	Short	Y	N
Thursday	Indicates whether runs with this CalendarID value operate on Thursdays. The possible values are as follows: 0—There is no service on this day of the week. 1—There is service on this day of the week.	Short	Y	N
Friday	Indicates whether runs with this CalendarID value operate on Fridays. The possible values are as follows: 0—There is no service on this day of the week. 1—There is service on this day of the week.	Short	Y	N
Saturday	Indicates whether runs with this CalendarID value operate on Saturdays. The possible values are as follows: 0—There is no service on this day of the week. 1—There is service on this day of the week.	Short	Y	N
Sunday	Indicates whether runs with this CalendarID value operate on Sundays. The possible values are as follows: 0—There is no service on this day of the week. 1—There is service on this day of the week.	Short	Y	N
StartDate	The beginning of the date range when public transit service described by this dataset operates. When solving network analyses with specific dates, the Public Transit evaluator only uses runs with this CalendarID value if the analysis date falls within the StartDate and EndDate date range. The StartDate and EndDate date range is ignored when solving network analyses with a generic weekday, and only the weekday fields, such as Monday, are used.	Date	N	N
EndDate	The end of the date range when public transit service described by this dataset operates. The date described by EndDate is included in the date range. When solving network analyses with specific dates, the Public Transit evaluator only uses runs with this CalendarID value if the analysis date falls within the StartDate and EndDate date range. The StartDate and EndDate date range is ignored when solving network analyses with a generic weekday, and only the weekday fields, such as Monday, are used.	Date	N	N

CalendarExceptions

The CalendarExceptions table defines exceptions to the regular public transit service, such as specific dates when public transit service is added or removed. The Public Transit evaluator only uses the exception dates in this table if the network analysis is configured to use specific dates instead of generic weekdays.

This table is required by the data model, but it does not have to have any rows if you do not want to define any exceptions to the regular public transit service. However, either Calendars or CalendarExceptions must be populated with rows. If both Calendars and CalendarExceptions are populated, CalendarExceptions modifies the regular service defined in Calendars. If the Calendars table is empty, all public transit service is defined in CalendarExceptions by explicitly adding service on specific dates. In this situation, a specific date must be used in network analysis instead of a generic weekday.

The following table describes the schema of the CalendarExceptions table:

CalendarExceptions

Field name	Description	Type	Required	Nullable
ObjectID	The ObjectID of the table row.	ObjectID	Y	N
CalendarID	The ID of the exception that may or may not correspond to a value in the ID field in the Calendars table. If the value appears in Calendars, the exception modifies the regular service defined there. The values in this field don't have to be unique, but each unique combination of CalendarID and ExceptionDate should appear only once.	Long	Y	N
GServiceID	The GTFS service_id with which this CalendarException is associated. This field is for informational purposes only.	Text	N	Y
ExceptionDate	The date the transit service described by this exception is added or removed.	Date	Y	N
GExceptionType	Indicates whether transit service is added or removed on the date described by the ExceptionDate field. The possible values are as follows: 1—Service is added for the specified date. 2—Service is removed for the specified date. The GExceptionType field is equivalent to the GTFS exception_type field in the calendar_dates.txt file.	Short	Y	N