Mandatory SDP XML Schema Elements

The SDP XML Schema is designed to meet many existing and future needs. As a result, the Schema contains both mandatory and optional SDP XML schema elements. The SDP must meet the schedule information requirements of several downstream applications such as Trip Planning, Timetable, and Ad Hoc Schedule Planning[1], as well as support the existing upstream requirements of data providers. To support the diverse requirements of the region, there are many optional elements in the SDP Schema.

The high level mandatory elements that are required by every validated SDP document are included in Figure 2.

Figure 2: SDP Schema of Mandatory Elements Only

Only the mandatory high level elements (and their nested elements) are discussed in the section on High-Level and Nested Element Descriptions.

High-Level Element Descriptions

High level elements are those that are contained in Figure 2 SDP Schema of Mandatory Elements.

SDP Document and Schedule Version

Definition: The time period, described by the start date and time and optionally end date and time, when an agency service provision is valid. Due to the nature of transit schedules, different routes, depots and organizational units may implement various versions that operate during the same time period.

Example: Long Island Bus typically issues a new Schedule Version in March, June, September and January.

The Schedule Version is included as SDP Document header attribute group. Even if values are not available, all elements of the attribute group are mandatory.

Table 1: Schedule Version Attribute Group Elements

Attribute	Description
scheduleVersionID	Mandatory (embedded element scheduleVersionID_id) UNIQUE. Use the General Order (often used by a rail operator), identifier used in the pick, or designation for the schedule. An example of a schedule version is scheduleVersionID=“108”. This scheduleVersionID implies 1^st Quarter in the year 2008.
scheduleVersionDescription	Mandatory (string). A string that is used to describe the schedule version. In the example 108, the scheduleVersionDescription might read: scheduleVersionDescription=“1^st Quarter 2008” or scheduleVersionDescription=“1-2-2008 to 6-26-2008”
pickNo	Mandatory (string). This field is sometimes the same as the scheduleVersionID. Although the attribute tag must be inserted into the SDP document, you may leave this element blank if no pickNo is needed or if it repeats the scheduleVersionID. Example: pickNo= “” (for a null value)
activationDate	Mandatory (date). Format [yyyy-mm-dd] The date the schedule version begins operating. Example: activationDate=”2008-01-02”
deactivationDate	Mandatory (date). Format [yyyy-mm-dd] The date the schedule version ends operating. Use a default value of 9999-12-31 if the end date is unknown. This rule applies to all fields that include a deactivationDate. Example: deactivationDate= “2008-06-26”
placementDate	Mandatory (date). Format [yyyy-mm-dd] Date on which schedule was generated or developed (use date compiled into SDP format if no date is available). Example: placementDate= “2007-12-31”

Agency

Definition: A transit agency is an organization that provides transportation services by bus, rail, or other conveyance to the general public or special services on a regular, continuous basis.

Table 2: Agency Element Descriptions

Element	Description
agencyID	Mandatory (agencyID_id) UNIQUE. This designator is assigned by SDP/TSDEA registration. (use agencyAcronym if not available.)
agencyAcronym	Mandatory (string). Agency acronym that is known by the public, for example MNR or MTA MNR for the Metro-North Railroad.
agencyName	Optional (string). Full name of agency, for example “Metropolitan Transportation Authority New York City Transit” or “MTA New York City Transit”.
webAddress	Optional (string). The universal resource link or home page web address of the agency.
headquarterAddress	Optional. (nested element AddressStructure). See address structure guidance in AddressStructure
headquarterTelephone	Optional (TELEPHONE type) Format: this field has a maximum length of 10 numbers [aaa-ttt-tttt] (where aaa refers to the area code followed by seven digits). The general information number or a general customer information telephone number.
serviceAreaDescription	Optional (string). A description of service area. The description is used to present to the public. As such the description should avoid abbreviations and excessive capitalization. Example XML Fragment: <serviceAreaDescription> “The LIRR system is comprised of over 700 miles of track on 11 different branches, stretching from Montauk -- on the eastern tip of Long Island -- to the refurbished Penn Station in the heart of Manhattan, approximately 120 miles away. Along the way, the LIRR serves 124 stations in Nassau, Suffolk, Queens, Brooklyn and Manhattan.” </serviceAreaDescription>
hrsOfOperations	Optional (string). A basic description of the hours of operation, for example: “5:30 am to 10 pm” or “24 hours”. Example XML Fragment: <hrsOfOperations>5:30 am to 10 pm</hrsOfOperations>

An example XML fragment of Agency may appear as follows:

<agencyName>New York City Transit Bus</agencyName>

<webAddress>http://www.mta.nyc.ny.us/nyct/bus/index.html</webAddress>

<streetName>Broadway</streetName>

<completeName>2 Broadway</completeName>

</headquarterAddress>

</Agency>

Schedule Revision

Definition: Records the state and manages the changes to the designated schedule version. A schedule revision is a submission of one or more parts of a schedule version.

The schedule version is the umbrella that groups all the service and changes to the service to a schedule period or operator selection period. The revision element provides a means of tracking updates of all or parts of a schedule on a permanent or temporary basis.

Table 3: Schedule Revision Element Descriptions

Element	Description
revisionNumber	Mandatory (revisionNumber_id) UNIQUE. The revisionNumber is a unique, potentially sequential, number within a scheduleVersionID. The original schedule may be set to "0" and incremented whenever a change is made.
activationDate	Mandatory (date). Format [yyyy-mm-dd] The date of service activation. An original schedule revision will be assigned the same date as the Schedule Version activationDate. When the revision is either permanent or temporary (for example a long term detour routing), then start date of revised schedule is used. Example: for a permanent or temporary revision, the activation date may be 2008-01-20.
deactivationDate	Mandatory (date). Format [yyyy-mm-dd] The date of service deactivation. An original schedule will be assigned the same date as the Schedule Version deactivationDate. When the revision is permanent the deactivationDate will be assigned the same as the Schedule Version deactivationDate. When the revision is temporary, then the deactivationDate is assigned the date the service changes ends. Example: for a temporary revision, such as a detour, the service deactivationDate may be 2008-01-27.
placementDate	Mandatory (date). Format [yyyy-mm-dd] Date schedule revision was generated or placed. When the actual date is not known then use the date for which the SDP document was generated.
scheduleVersionType	Mandatory (scheduleVersionType_cd). A classification for the type of schedule that is included in this SDP document. Codes include [original, rev-permanent, rev-temporary, suspended]. The type value should be assigned as follows: “original” is assigned to an original schedule. “rev-permanent” is used when the revision replaces the last revision until the end of the schedule version operating period. “rev-temporary” is a temporary replacement to the last revision. When the deactivation date is reached, the schedule version reverts to the last permanent revision. “suspended” implies that there is no replacement for the schedule. It is no longer in operation (until a new schedule is registered). See Complete Guidance Document, Chapter 4 for discussion on schedule revision precedence when using these values (see http://www.consystec.com/tsdea/rstwg/docs.html)
history	Mandatory (string). History is a list of the changes to the schedule since the last revision. Use a standard convention for generating the history, for example “1- original; 2-updated routes 2, 10, 12;” etc.

An example XML fragment of ScheduleRevision may appear as follows:

<scheduleVersionType>original</scheduleVersionType>

<history>1-original</history>

</ScheduleRevision>

Route

Definition: A collection of patterns and associated trips in revenue service with a common identifier or name. Railroad operators may use the term line or branch by which to group service.

Table 4: Route Element Descriptions

Element	Description
routeID	Mandatory (routeID_id) UNIQUE. A unique designation for route. This designator should be used for routeID throughout the rest of the document. It will be used to aggregate the service related components (i.e., trips and physical paths/patterns) with the route. Example: M01
routeName	Optional (string). A route may refer to an internal name or designator by one or more stakeholders or applications within an organization. The value of this field refers to an alternate name used to reference a route. Examaple: “M 0001 FIFTH-MADISON-PARK AV S”
mode	Mandatory (mode_cd). A transit service classification characterized by specific right of way, technological and operational features. Mode codes are listed in mode_cd; e.g., MB for bus, CR for commuter rail, HR for subway (heavy rail), FR for ferry, etc.
publicRouteName	Mandatory (string). A name recognized for the route by the public for the route. Example: “M1 Fifth-Madison Park Av S”
publicRouteNumber	Mandatory (string). A route number recognized for the route by the public. Example: M1
routeDescription	Optional (string). A description for the route. This field is not needed if it is redundant with publicRouteName. The field may be used to describe the physical path of the route, or if it contains abbreviations for other internal or machine-to-machine data transfer.
adaCompliance	Optional (adaCompliance_cd). The adaCompliance describes the nature of the vehicle types and stop facilities that serve this route. The code values include: notCompliant fullyCompliant mobilityChallengedAccess visuallyImpairedAccess hearingImpairedAccess mobility-VisuallyImpairedAccess visually-HearingImpairedAccess mobility-HearingImpairedAccess The designation implies that the route inclusive of vehicles and stops provide services that accommodate persons with specific impairments.
routeBeginDate	Optional (date). Format [yyyy-mm-dd] The date on which the route is placed into service with respect to the schedule version or revision.
routeEndDate	Optional (date). Format [yyyy-mm-dd] The last day of service on this route with respect to the schedule version or revision. If no end date is present in a native route record, then use a default value such as the schedule deactivationDate or the default end date 9999-12-31.
routeDirectionList	Mandatory (RouteDirection). The routeDirectionList is a nested element. In most cases there are two nested elements, first and second directions. The nested elements are used to customize public route direction names for each route. Complete RouteDirection record for the number of route directions that are listed by the patterns in this route. (See next section for more on Route Direction).

An example XML fragment of Route may appear as follows:

<Route>

<publicRouteName>M1 FIFTH-MADISON-PARK AV S</publicRouteName>

<routeDescription>FIFTH-MADISON-PARK AV S</routeDescription>

<routeDirection>first</routeDirection>

<publicRouteDirection>North</publicRouteDirection>

</routeDirectionList>

<routeDirection>second</routeDirection>

<publicRouteDirection>South</publicRouteDirection>

</routeDirectionList>

</Route>

Route Direction

Definition: The direction of travel of a transit conveyance along the physical path. The element allows for public facing information.

Note: The RouteDirection element is nested under Route, as such it inherits the routeID from the Route element.

Table 5: RouteDirection Element Descriptions

Element	Description
routeDirection	Mandatory (routeDirection_cd). Enumerated index used to match routeDirection in Pattern element. [first, second]
routeDirectionDescription	Optional (string). The name or code used in the native data. Content is determined by the user, and may be used to support downstream applications.
publicRouteDirection	Mandatory (string). The route direction name known and viewed by the public Note: The public route direction name may be the destination or origin of the route, for example, “New York City” or “Port Washington” in the case of Long Island Rail Road.

An example XML fragment of RouteDirection may appear as follows:

<routeDirection>second</routeDirection>

<publicRouteDirection>South</publicRouteDirection>

</routeDirectionList>

Another example XML fragment of RouteDirection that uses the destination location as the direction is as follows:

<routeDirection>first</routeDirection>

<routeDirectionDescription> New York City (Penn Station) </routeDirectionDescription>

<publicRouteDirection>Penn Station</publicRouteDirection>

</routeDirectionList>

<routeDirection>second</routeDirection>

<routeDirectionDescription>Port Washinton via Shea Stadium</routeDirectionDescription>

</routeDirectionList>

Trip

Definition: A one way scheduled movement of a transit vehicle between starting and ending locations. Each trip is an instance of a pattern where service is provided for a route in a given direction. The railroad alias for this term is “train”.

Table 6: Trip Element Descriptions

Element	Description
tripID	Mandatory (tripID_id) UNIQUE. A unique designation for a trip. The value for this element need only be unique within this SDP document. It will be used to relate to elements from other elements. Example: 1024
routeID	Mandatory (routeID_id). The routeID should match the convention of the associated routeID in the Route element.
patternID	Mandatory (patternID_id). The patternID should match the convention of the associated patternID in the Pattern element.
dayType	Mandatory (list of dayType_cd). A dayType is the type of service generally assigned to the type of day. For example, weekday, Saturday, Sunday services. Multiple elements may be included for dayType. For example, if the trip is used for multiple special days: 3rd and 4th Sunday before Christmas, and Veteran's Day, then three dayTypes may be included in the Trip structure. The dayType must cover all the nested elements (noteList and tripTimeList) in the Trip structure. The code includes over 50 general and special day types (including holidays such as Thanksgiving, New Year’s Eve Day, New Year’s Day, and more). The Guidance document includes special rules for assigning dayTypes in order to mitigate overlap and confusion when generating timetables. These may be found at Day Type Codes.
tripName	Optional (string). A name or number for trip or train that is recognized by the public. For example, The "Overnighter".
tripType	Optional (tripType_cd). A classification for a type of trip. Enumerated values include [revenue, pullIn, pullOut, extra, deadhead]. Only revenue trips are needed for regional applications.
timeBegin	Mandatory (signed integer). The field timeBegin is the time when a trip begins. (timeBegin should match the first nested tripTimeList (Trip Time structure) element tripTime value.) Units are in seconds past midnight. Negative values imply time before midnight, and positive values may exceed 24 hours. Example: 23340 [6:29:00 AM]; -60 [day before at 11:59:00 PM]
timeEnd	Mandatory (signed integer) The field timeEnd is the time when the trip ends. (timeEnd should match the last nested tripTimeList (TripTime structure) element tripTime value.) See timeBegin for example and unit guidance.
locationBegin	Mandatory (locationID_id). The field locationBegin is the place where a trip begins. (locationBegin should match the first nested tripTimeList (Trip Time structure) element locationID value.) locationID should match a Location element with the same locationID. Example: 100546 is an example of a locationID.
locationEnd	Mandatory (locationID_id). The field locationEnd is the place where a trip ends. (locationEnd should match the last nested tripTimeList (Trip Time structure) element locationID value.) locationID should match a Location element with the same locationID.
noteList	Optional (list of noteID_id). The noteList is a set of nested elements with a single element noteID. The noteID should match a Note structure element with the same identifier.
tripTimeList	Mandatory (ordered list of TripTime). The tripTimeList is a set of nested elements of a sequence of times where the transit vehicle passes (arrives/departs) during its traversal of the trip. Typically the elements of the list are stored in sequential order, first time to last time of the trip. See Trip Times section for details of the tripTimeList structure.

An example XML fragment of Trip may appear as follows:

<Trip>

<tripType>revenue</tripType>

<tripEventType>AlightBoard</tripEventType>

<timeType>departure</timeType>

</tripTimeList>

--- More tripTimeList elements here --

<tripEventType>AlightBoard</tripEventType>

<timeType>arrival</timeType>

</tripTimeList>

</Trip>

Note: this example includes two day types. Although multiple instances of the trip are typically documented, some agencies may decide to include multiple day types in a trip in order to avoid complex day type definitions when trips operate on non-typical schedules (e.g., tues through thurs).

Trip Times

Definition: The time along a trip when a vehicle is scheduled to pass (arrives at/departs from). The trip time may be published or unpublished, coordinated or uncoordinated with trip times of other trips.

Note: The TripTime element is nested under the Trip element. As such it inherits the tripID and routeID from Trip.

Table 7: TripTime Element Descriptions

Element	Description
tripTime	Mandatory (integer). Similar to timeBegin and timeEnd in the Trip element, tripTime is a time when a transit vehicle delivers service to a specific location along a trip. Units are in seconds past midnight. Negative values imply time before midnight, and positive values may exceed 24 hours. Example: 23340 [6:29:00 AM]; -60 [day before at 11:59:00 PM]
timeEventType	Optional (timeEventType). A classification for a trip event to which this element is associated. For example, the event may include a fare set change, headsign change, route change, and other events that may not be covered by a trip on a single route or associated with a route/pattern. Business rules define the coding standards for the Time Event Type. See Guidance Document for additional information on enumeration values.
timeType	Mandatory (timeType_cd). A classification of the trip time as a first or last timing point, arrival or departure timing point. timeType enumeration values include: arrival --Time the transit vehicle arrives at a place departure -- Time the transit vehicle departs a place firsttime -- The first timing point along the trip. This point is always a departure point. lasttime -- The last timing point along the trip. This point is always an arrival point. This field must be included in a list of points associated with a trip. Typically, if the tripTime is the first, then the default field is departing. If the field is the last, then the default is arrival. The default for all other occurrences depends on scheduling policy.
locationID	Mandatory (locationID_id). The locationID identifies the place where the trip time occurs. This field must match a locationID in a Location element.
platformNo	Optional (string). The place where boarding or alighting occurs. A platform is also known as a bus stop, berth or platform. The number may be associated with a stopID from a TransitStop element.
seqNo	Optional (unsigned integer -- unsignedInt). The order of this tripTime in the trip sequence. This field is not Mandatory since the tripTime may be used to order the events.
notes	Optional (list of noteID_id). A note identifier (noteID) that corresponds to a note element in the Note library. A note might indicate that the event occurs during certain conditions, for example, school is in session.

An example XML fragment of TripTime may appear as follows:

<tripEventType>AlightBoard</tripEventType>

<timeType>departure</timeType>

</tripTimeList>

Pattern

Definition: A unique, non-branching, ordered sequence of transit paths, time points, or transit stops to be followed by a transit vehicle in scheduled service for a route in a given direction.

Table 8: Pattern Element Descriptions

Element	Description
patternID	Mandatory (patternID_id) UNIQUE. A pattern identifier (patternID) that designates a unique path traversed by a transit vehicle in revenue service. For example: M01_0010 is an example of a patternID.
patternName	Optional (string). A name given to a Pattern and used by either a downstream application or known to the public. For example, “Route 1 East Express”.
description	Optional (string). A description of the pattern. The field may not be needed for most downstream applications.
routeID	Mandatory (routeID_id). The route identifier associated with the pattern. This field must match a routeID in one of the Route elements.
routeDirection	Mandatory (routeDirection_cd). One of the routeDirection elements contained in the Route element. The standard enumerations use 'first' or 'second'. The direction name may be looked up in the nested routeDirection element in the Route element under the publicRouteDirection field.
origin	Mandatory (locationID_id). The originating location of the pattern. This field should match the first entry in the TransitPointEvent.location element. The locationID should exist in a Location element.
destination	Mandatory (locationID_id). The destination location of the pattern. This field should match the last entry in the TransitPointEvent.location element. The locationID should exist in a Location element.
patternType	Optional (patternType_cd). A classification for a pattern. Acceptable values include [revenue, non-revenue]. Current downstream applications do not need non-revenue patterns or trips.
eventList	Mandatory (Choice of ordered list of TransitPointEvent or TransitPathEvent). The elements in this entry are the events that occur along the pattern. A commuter rail system needs only one pattern for each origin-destination pair.

An example XML fragment of Pattern may appear as follows:

<routeDirection>first</routeDirection>

<headsignDesc>HARLEM 147 ST via MADISON</headsignDesc>

</transitPointEvent>

--- More transitPointEvent elements here --

<headsignDesc>HARLEM 147 ST via MADISON</headsignDesc>

</transitPointEvent>

</eventList>

</Pattern>

TransitPointEvent

Definition: A place where transit service is delivered along the transit network.

Note: The TransitPointEvent element is nested under the Pattern element. As such it inherits routeID and patternID from Pattern.

Table 9: TransitPointEvent Element Descriptions

Element	Description
locationID	Mandatory (locationID_id). A reference to the location where the event occurs. The point may be any type of transit feature, physical point, timepoint, transit stop or facility, or other event (e.g., change headsign, trigger location). The locationID should exist in the same SDP document, under the Location element.
seqNo	Mandatory (seqNo_id). The sequence number of the event in the pattern eventList. This number may be derived if the distanceFromOrigin is defined. Note: the data type is assigned an IDENTIFIER type so that it may be validated as unique within each route pattern.
trackNo	Optional (trackNo_id). For trains, the trackNo on which the event occurs.
stopID	Optional (stopID_id). If appropriate, the stop identifier or platform number associated with the event.
distanceFromOrigin	Optional (distanceType). The distance from the Pattern origin. Although this information is not universally collected, it is needed to reduce ambiguity by many downstream applications, and thus is a key field for the SDP. Also includes optional attribute unit which accepts the enumerated values [feet or meters]. Default when no attribute is present is feet. Example XML format: <distanceFromOrigin units="feet">3.14159</distanceFromOrigin>
ptEventType	Optional (eventType_cd). A classification for an event. More than one event may occur at a single point, for example, exiting a bus stop zone and “checking out” of a Transit Signal Priority zone may be co-located. Enumeration values include:[timing, other] Additional values may be added when needed by downstream applications.
headsignDesc	Optional (string). Although this field may be included multiple times, the field may also contain additional fields to be used throughout the pattern, for example, headsign information such as "via Brooklyn/Flatbush" or "Go Mets".

An example XML fragment of transitPointEvent may appear as follows:

<headsignDesc>HARLEM 147 ST via MADISON</headsignDesc>

</transitPointEvent>

Location

Definition: This entity represents a place in the Transit Gazetteer. It contains the location description for a point used to describe or associated with a transit network over which transit service is provided. (Note: the featureType element enables the user to specialize the location so that different features may be aggregated along a single polyline feature. This also alleviates the need to describe each facility or stop when only a location is required.)

Table 10: Location Element Descriptions

Element	Description
locationID	Mandatory (locationID_id) UNIQUE. An identifier for each feature or physical point needed to associate a schedule component to the transportation network (map database) or location in space.
featureType	Mandatory (featureType_cd). A classification for a place characterized by its location reference. Enumerated values include: [transitFacility, timepoint, transitStop, transferCluster, portal, amenity, passengerAccessComponent, physicalPoint, event, poi, other]
locationDesc	Mandatory (string). A description of the location. This field may be redundant with intersection or publicLocationDescription.
intersection	Mandatory (string). The full name of an intersection. For easier parsing, the accepted convention is "on street" @ "at street". Avoid using "&" symbol and other html characters.
geometry	Optional (PolygonType). The geometry or “closed region of space”. The PolygonType is a box with at least five points. The polygon, by definition may contain as many points as needed to define the region. The major requirement is that the points are ordered and the first and last points are the same. Use coordinates of the WGS ’84 datum. SDP XML fragment: <geometry>0,0 100,0 100,100 0,100 0,0 </geometry>
streetDirection	Optional (streetDirection_cd). The general orientation of the street. Enumerated values include [northSouth, eastWest, north, south, east, west]. Note: northSouth and eastWest are typically used to describe the direction of rail alignments where trains may travel in both directions.
relativeLocation	Optional (RelativeLocation). RelativeLocation is a nested element (see detailed description in the section below). The nested element is used when linear referencing methods are used to describe location (e.g., nearside, off street, distance from intersection).
longitude	Mandatory (double). Location of a place on the earth East of the Greenwich meridian. The datum for all latitude and longitude measurements shall be NAD 83. Latitude and longitude will be represented in geographic coordinates, using decimal degrees. Note longitude error varies by latitude, however, a minimum of five decimal places (-73.58391) should be included. The preferred number of decimal places is six (see example below). Example: <longitude>-73.583913</longitude>
latitude	Mandatory (double). Location of a place on the Earth North of the equator. The datum for all latitude and longitude measurements shall be NAD 83. Latitude and longitude will be represented in geographic coordinates, using decimal degrees. Note a minimum of five decimal places (44.12345) should be used in order to provide an accuracy of 1.11 meters or 43 inches. Six decimal places are recommended as documented in the example below. Example: <latitude>40.680051</latitude>
x_coord	Optional (double). State Plane coordinates such as Easting/Northing. For the New York/New Jersey area, the UTM zone is 18.
y_coord	Optional (double). State Plane coordinates such as Easting/Northing. For the New York/New Jersey area, the UTM zone is 18.
county	Optional (string). A standard name for county
city	Optional (string). A standard name for a city.
state	Optional (postalState_cd). The state field should be populated from ANSI/FIPS codes [NY, NJ, CT]
zip	Optional (string). A postal code or zip +4 USPS zip code.
communityName	Optional (string). A local community name in which the location is known.
serviceArea	Optional (string). A description of the service area. This description may define a fare zone, for example.
publicLocationDescription	Mandatory (string). This is the field that is used to describe the location to the public. The field should not contain abbreviations or codes, and it should use proper punctuation and capitalization.
isGeneralized	Mandatory (boolean). If this location is contained in, is part of, or has a "many" relationship to another location, then isGeneralized in 'false'. For example, a timepoint location may be associated with one or more bus stop locations. In the timepoint/bus stop case, the timepoint is true and the bus stops are false.
generalizeLocation	Optional (locationID_id). When isGeneralized is false, and the feature points to another location, then the specific record to which it points is included in this field. For example, WWM01 and WWM02 point to WWM locationID. The WWM location may be considered the timepoint location while the WWM01 and WWM02 locations may refer to bus stop locations.

An example XML fragment of Location may appear as follows:

<featureType>timepoint</featureType>

<locationDesc>PARK AVE nearest bus stop RVPA and Phys Pt RVPA0</locationDesc>

<intersection>PARK AVE @ NEWTON PL</intersection>

<atStreet>NEWTON PL</atStreet>

</relativeLocation>

<publicLocationDescription>PARK AVE at NEWTON PL</publicLocationDescription>

<isGeneralized>false</isGeneralized>

</Location>

Nested Element Descriptions

Nested elements are data concepts that are included as elements within other elements. Although they are not depicted in Figure 1 or Figure 2, they are complex types that are incorporated in the SDP mandatory elements.

Relative Location

Definition: A linear reference or attribute related to a Location. Fields include position relative to intersection, off or on transportation network, etc.

Table 11: RelativeLocation Element Description

Element	Description
onStreet	Mandatory (string). The name of the street on which the feature is located; if the relative location is not on the street, then this is the nearest street location.
atStreet	Mandatory (string). The name of the cross street nearest the location.
distanceFromIntersection	Optional (distanceType). The distance in feet of the feature from the intersection. An attribute may be designated for either feet or meters. [See example in Transit Point Event distanceFromOrigin field.]
placementRelIntersection	Optional (placementRelIntersection_cd). The relative location of the location from the intersection. Enumerated type values include: [nearside; farside; midBlock; at; between; farsideMidBlock; nearsideMidBlock; opposite]
busPositionBay	Optional (integer). This is a number that designates the platform, bus bay, ferry berth or other access area that may not be defined in a TransitStop element.
alongLocation	Optional (alongLocation_cd). The location along a boarding area where passengers board or alight the transit vehicle. Valid enumerated values refer to the position based on the direction of travel: [right, left, both]
isOffStreet	Optional (boolean). The isOffStreet describes if the location is off the street. “true” implies that the location is not on a public road link; “false” assumes the location is along the street.

An example XML fragment of relativeLocation may appear as follows:

<atStreet>NEWTON PL</atStreet>

</relativeLocation>

AddressStructure

Definition: A description of the postal address of a place. Most of the elements in the address reference the US Post Office (USPS) Addressing Standard, USPS Publication 28, Postal Addressing Standards, August 1995 (updated 2006) which may be found at: http://pe.usps.gov/text/pub28/welcome.htm. Additional guidance on addressing guidance may be found at the USPS site.

Table 12: AddressStructure Element Descriptions

Element	Description
addressID	Optional (identifier) UNIQUE. An internal index that references the address.
recordDate	Optional (date). The date of record insertion in the file or database.
addressNumber	Mandatory (string). The address number. This is a part of the complete address. See recommendation in USPS Publication 28.
directionPrefix	Optional (string) The direction prefix for an address. Use one of the codes included in USPS. See Appendix C for list of Postal Service Standard Suffix Abbreviation. Example: North as in East 5^th Avenue
typePrefix	Optional (string). The address prefix (other then direction prefix) for an address. Use one of the codes included in USPS. See Appendix C for list of Postal Service Standard Suffix Abbreviation.
streetName	Mandatory (string). name of the street only (the prefix and suffix fields are designated by other fields
typeSuffix	Mandatory (string). The address type suffix. Use one of the codes included in USPS. See Appendix C for list of Postal Service Standard Suffix Abbreviation.
directionSuffix	Optional (string). The direction suffix for an address. Use one of the codes included in USPS. See Appendix C for list of Postal Service Standard Suffix Abbreviation.
completeName	Mandatory (string). Complete post office address.
unitType	Optional (string). A unit, office or apartment.
unitDesignation	Optional (string). The number of the unit, office or apartment
secondLine	Optional (string). The 2nd line of an address if applicable.
postalCommunity	Mandatory (string). The city or community (e.g., Flatbush).
postalState	Mandatory (string). The state. The USPS Pub. 28 includes a complete list of FIPS codes.
postalCode	Mandatory (string). The postal code as designated by the USPS. See USPS zip+4 lookup site: http://zip4.usps.com/zip4/welcome.jsp
addressSegStatus	Optional (string). A classification for the status of the segment. Specific enumerated values are not designated in the SDP.

A typical SDP XML fragment for the NYSDOT headquarter address might look like --

<completeName>50 Wolf Road, Albany, NY 12205</completeName>

<postalCommunity>Albany</postalCommunity>

</headquarterAddress>

Unique Identifiers

The identifiers listed in Table 13 should be unique within their primary or identifying element. The primary and related elements are included in the table.

Table 13: Unique Identifiers, Primary and Referencing Keys

Primary Key	Identifying Element	Referencing Element
addressed_id	AddressStructure	· headquarterAddres in AgencyStructure · address in TransitStopStructure
agencyID_id	AgencyStructure	· agencyID in Portal, DayType,
locationID_id	LocationStructure	· origin, destination (in PatternStructure) · beginLocation, endLocation (in TripStructure) · locationID (in TransitPointEventStructure and TripTimeStructure) · generalizedLocation (in LocationStructure)
noteID_id	NoteStructure	· noteList in TripStructure · notes in TripTimeStructure
patternID_id	PatternStructure	· patternID in RouteGrouping.patternSet · patternID in TripStructure
pickNo_id	ScheduleVersion attribute structure	Not applicable
revisionNumber	ScheduleRevisionStructure	· revisionNo in ScheduleCalendarDate.xsd
routeDepotVersionID	RouteDepotVersionStructure	· routeDepotVersionID in ScheduleCalendar Date.xsd
routeID_id	RouteStructure	· routeID in RouteDepotVersionStructure · routeGroupingID in RouteGroupingStructure · routeID in RouteGroupingStructure.tripSet and RouteGroupingStructure.patternSet · routeID in PatternStructure · routeID in TripStructure · fromRouteID and toRouteID in EventConnectionStructure
scheduleVersionID_id	SDP Document	· scheduleVersionID in ScheduleCalendarDate.xsd
seqNo_id	TransitPointEventStructure	Unique within a element list per SDP Document (element is not used to reference elements outside of structure)
stopID_id	TransitStopStructure	· stopID in TransitPointEventStructure · stopID in PlantComponentStructure
trackNo_id	TrackStructure	· trackNo in TransitPointEventStructure · trackNo in TransitPathEventStructure · trackNo in PlantComponentStructure · trackNo in TrackAssociationStructure
tripID_id	TripStructure	· blockTripList in BlockStructure · tripID in BlockTimeStructure · fromTripID and toTripID in EventConnectionStructure · tripID in RouteGrouping.tripSet

Data Type Descriptions

There are several data types (simple or complex types) that are described in the SDP Schema. The IDENTIFIER, Telephone and distanceType, found in the mandatory high level elements are described in Table 14.

Table 14: Data Type Descriptions

Type	Description
IDENTIFIER	(string) Identifying nested elements. See Table 1 for list of identifiers. A special notation of _id is used to describe a type referencing the data type IDENTIFIER. For example, agencyID_id. The XML Schema includes KEY and KEYREF declarations to manage referential integrity.
TELEPHONE	(string with a minimum of 10 characters) May be used to list the characters of a telephone number. A minimum of ten (10) characters should be included in the value.
distanceType	(float with attribute of units) The measure of distance and type of units used by the distance value. The units value is optional and if not included is assumed to be feet. The simple type units_cd enumerated values consist of [feet, meters].

Schedule Calendar XML Schema

Definition: The schedule calendar is a calendar of dates (scheduleCalendarDate) on which a transit agency assigns the type of service scheduled to be delivered (within its schedule day).

The scheduleCalendarDate is assigned a type of service using a code called a day type (dayType_cd). A day type enumeration includes most general service type codes as well as special days such as Veterans Day, Martin Luther King Day, Thanksgiving, Day After Thanksgiving, New Years Eve Day, and more. Altogether there are 56 values for dayType_cd. When a special day type value is not included in the list, you should complete a high level element called DayType. More details on how to use the DayType element are included in the Guidance document set (see http://www.consystec.com/tsdea/rstwg/docs.html).

Table 15: Schedule CalendarDateElement Descriptions

Element	Description
calendarDate	Mandatory. (date) A calendar date. If each dayType is associated with one and only one calendarDate, then this field is unique throughout the document. If there are trips in routes where a dayType will differ on the same date, then the routeDepotVersionID must be completed to distinguish the particular routes that provide the dayType service on that date. The combination of the calendarDate, revisionNumber and scheduleVersionID must be unique.
dayType	Mandatory (dayType_cd) A dayType_cd that is assigned to operate on the calendar date. See enumeration list for complete set of enumeration values.
placementDate	Mandatory (date) [yyyy-mm-dd] The date when this record was placed or generated.
activationDate	Optional. (date) [yyyy-mm-dd] The date when this dayType is valid
deactivationDate	Optional. (date) [yyyy-mm-dd] The date when this dayType becomes deactivated. If unknown, use 9999-12-31.
routeDepotVersionID	Optional. (routeDepotVersionID) When the day type differs for various routes, this field is included to reference the routeID that is valid.
revisionNo	Mandatory. (revisionNumber_id) The revisionNumber_id (from ScheduleRevision) of the route schedule assigned to this date. The identifier should match one in a registered SDP Document.
scheduleVersionID	Mandatory. (scheduleVersionID) The scheduleVersionID of the route schedule assigned to this date. The identifier should match one in a registered SDP Document.
agencyID	Optional. (agencyID_id) The agency name associated with this schedule date. The identifier should match a registered agency that submitted an SDP Document.

An example XML fragment of ScheduleCalendarDate may appear as follows:

….Add more scheduleCalendarDate elements here

</scheduleCalendarDate>

</ScheduleCalendar>

Day Type Codes

Abbreviation	Code	Value	Description
sun	<xsd:enumeration value="sun"/>	1	Sunday
mon	<xsd:enumeration value="mon"/>	2	Monday
tue	<xsd:enumeration value="tue"/>	3	Tuesday
wed	<xsd:enumeration value="wed"/>	4	Wednesday
thu	<xsd:enumeration value="thu"/>	5	Thursday
fri	<xsd:enumeration value="fri"/>	6	Friday
sat	<xsd:enumeration value="sat"/>	7	Saturday
holiday	<xsd:enumeration value="holiday"/>	8	Holiday
weekday	<xsd:enumeration value="weekday"/>	9	Weekday (assume school open)
weekend	<xsd:enumeration value="weekend"/>	10	Weekend
weekday-closed	<xsd:enumeration value="weekday-closed"/>	11	Weekday,school closed
mon-wed	<xsd:enumeration value="mon-wed"/>	12	Monday, Tues, Wednesday
tu-th	<xsd:enumeration value="tu-th"/>	13	Tuesday to Thursday
mon-sat	<xsd:enumeration value="mon-sat"/>	14	Monday to Saturday
mon-thu	<xsd:enumeration value="mon-thu"/>	15	Monday to Thursday
daily	<xsd:enumeration value="daily"/>	16	Daily
sat-sun-hol	<xsd:enumeration value="sat-sun-hol"/>	17	Sat/Sun/Holiday
new-year-day	<xsd:enumeration value="new-year-day"/>	26	New Year's Day
president-day	<xsd:enumeration value="president-day"/>	27	President's Day
st-pat-day	<xsd:enumeration value="st-pat-day"/>	28	St. Patrick's Day
good-fri	<xsd:enumeration value="good-fri"/>	29	Good Friday
mem-day	<xsd:enumeration value="mem-day"/>	30	Memorial Day
ind-day	<xsd:enumeration value="ind-day"/>	31	Independence Day
lab-day	<xsd:enumeration value="lab-day"/>	32	Labor Day
col-day	<xsd:enumeration value="col-day"/>	33	Columbus Day
thanks	<xsd:enumeration value="thanks"/>	34	Thanksgiving
chris	<xsd:enumeration value="xmas"/>	35	Christmas
mlk-day	<xsd:enumeration value="mlk-day"/>	36	Martin Luther King Day
lincoln-day	<xsd:enumeration value="lincoln-day"/>	37	Lincoln's Birthday
washington-day	<xsd:enumeration value="washington-day"/>	38	Washington's Birthday
fri-before-Mem-day	<xsd:enumeration value="fri-before-Mem-day"/>	39	Friday Before Memorial Day
day-before-Ind-day	<xsd:enumeration value="day-before-Ind-day"/>	40	Day before July 4
fri-before-Labor	<xsd:enumeration value="fri-before-Labor"/>	41	Friday before Labor Day
election-day	<xsd:enumeration value="election-day"/>	42	Election Day
vets-day	<xsd:enumeration value="vets-day"/>	43	Veteran's Day
day-before-thanks	<xsd:enumeration value="day-before-thanks"/>	44	Day before Thanksgiving
day-after-thanks	<xsd:enumeration value="day-after-thanks"/>	45	Day after Thanksgiving
4-sat-before-chris	<xsd:enumeration value="4-sat-before-xmas"/>	46	4th Saturday before Christmas
4-sun-before-chris	<xsd:enumeration value="4-sun-before-xmas"/>	47	4th Sunday before Christmas
3-sat-before-chris	<xsd:enumeration value="3-sat-before-xmas"/>	48	3rd Saturday before Christmas
3-sun-before-chris	<xsd:enumeration value="3-sun-before-xmas"/>	49	3rd Sunday before Christmas
2-sat-before-chris	<xsd:enumeration value="2-sat-before-xmas"/>	50	2nd Saturday before Christmas
2-sun-before-chris	<xsd:enumeration value="2-sun-before-xmas"/>	51	2nd Sunday before Christmas
1-sat-before-chris	<xsd:enumeration value="1-sat-before-xmas"/>	52	Saturday before Christmas
1-sun-before-chris	<xsd:enumeration value="1-sun-before-xmas"/>	53	Sunday before Christmas
mon-before-chris	<xsd:enumeration value="mon-before-xmas"/>	54	Monday before Christmas
chris-eve	<xsd:enumeration value="xmas-eve"/>	55	Christmas Eve
new-year-eve	<xsd:enumeration value="new-year-eve"/>	56	New Year's Eve
wed-before-chris	<xsd:enumeration value="wed-before-xmas"/>	57	Wednesday before Christmas
thu-before-chris	<xsd:enumeration value="thu-before-xmas"/>	58	Thursday before Christmas
fri-before-chris	<xsd:enumeration value="fri-before-xmas"/>	59	Friday before Christmas
erev-yomtov-fa-sp	<xsd:enumeration value="erev-yomtov-fa-sp"/>	60	Shabbat / Jewish Holiday Eve (fall/spring)
erev-yomtov-su	<xsd:enumeration value="erev-yomtov-su"/>	61	Shabbat / Jewish Holiday Eve (summer)
erev-yomtov-wi	<xsd:enumeration value="erev-yomtov-wi"/>	62	shabbat / Jewish Holiday Eve (winter)
motzei-fa-sp	<xsd:enumeration value="motzei-fa-sp"/>	63	Motzei Shabbat / Jewish Holiday (fall/spring)
motzei-su	<xsd:enumeration value="motzei-su"/>	64	Motzei shabbat / Jewish Holiday (summer)
motzei-wi	<xsd:enumeration value="motzei-wi"/>	65	Motzei shabbat / Jewish Holiday (winter)


Additional Types
sp-sun	sp-sun	18	Special Sundays
sp-mon	sp-mon	19	Special Mondays
sp-tue	sp-tue	20	Special Tuesdays
sp-wed	sp-wed	21	Special Wednesdays
sp-thu	sp-thu	22	Special Thursdays
sp-fri	sp-fri	23	Special Fridays
sp-sat	sp-sat	24	Special Saturdays
sp-daily	sp-daily	25	Special Daily

Sample SDP Document

For sample SDP Documents see http://www.consystec.com/tsdea/rstwg/datasets.html.

[1]The high level requirements for these processes may be found in the Appendices of the TSDEA Concept of Operations document.

Term	Definition
Branch	A complex type element that classifies a set of nested elements in the XML Schema.
Element	A data concept that is included in an XML Schema. An element description may be defined as a simple type element which describes a field or record in the XML schema, or a complex type which includes multiple simple or complex type elements.
Nested Element	A complex type element that is embedded in another complex type element.
SDP	Schedule Data Profile
Valid Submission	Checking of a registered document to ensure that conforms to the requirements of the SDP XML Schema and other business rules outlined in the SDP Functional Requirements document. XML validation checks for correct data type conformance, data organization and mandatory elements as defined by the SDP XML Schema. The SDP business rules checks for identifier uniqueness, matching identifier references, dates within range, and other key rules.

Terms and Acronyms

Purpose of this Document

SDP XML Schema and Branch Level Elements

Agency Registration

Service

Transit Network

Transit Gazetteer

Transit Facilities

Mandatory SDP XML Schema Elements

High-Level Element Descriptions

SDP Document and Schedule Version

Agency

Schedule Revision

Route

Route Direction

Trip

Trip Times

Pattern

TransitPointEvent

Location

Nested Element Descriptions

Relative Location

AddressStructure

Unique Identifiers

Data Type Descriptions

Schedule Calendar XML Schema

Day Type Codes

Sample SDP Document