GTFS For ParaTransit System?

Short Description: How to use GTFS for describing a Paratransit system?

Description: The aim of GTFS was to create a data format that would enable transit agency to share they data in a format that work for trip planning. The standard was implemented in GoogleMaps in 2006 and adopted by transit agencies across the United States that wanted to provide their users with better access to route and schedule information. So many formal transit agencies had adopted it so their transit routing information could be viewed in Google Maps. But this format is adapted specificaly to formal and structured transport system that respect schedule specification As there's no schedules, fares, standart vehicules, fixed stop and formal agencies in paratransit system, the Digital Matatus Team has worked on modifying the GTFS standart in order to provide a way to integrate paratransit's data and to indicate those différences in the GTFS Format.

Image:

Web Site :

Organisations interested to contribute or already contributing: Digital Matatus Team, GTFS for the rest of Us?

Organisations using or interested to use the resource:

Contributor:

Tags: GTFS, Modified GTFS, Paratransit, Data Processing, Africa

Category: Données

Theme: Données ouvertes, Traces de mobilité et des données associées, Africa

Referent:

Challenge addressed: Augmenter les connaissances partagées en cartographie et usages des véhicules et réseaux de transports

Key persons:

Other common: GTFS-flex, Introduction to the GTFS and Informal Transit System Mapping

Communauty of interest:

Type of common:

Produced in the field of OpenChallenge?

Level of developpment

Chat Space to discuss: [1]

Mailing list:

Task management link:

File management link:

Needs:

Complement:

Next step:

Others informations:

What is a GTFS Feed? - General Information

The GTFS (General Transit Feed Specification) is an open standard used by transit agencies for exchanging data. This static format allows to describe and share transportation schedules, fare information and geographic data such as stops and vehicle routes.
This standardized data format consists of a serie of text files compiled in a ZIP. Each file models a particular aspect of transit information, much of which is relational: stops, shapes, routes, trips, stop times, and other schedule data that describe a transit system and allow to provide trip planning functionality. Six of those files are formally required, composed of primary keys that connect each of the files to another in order to create relationships between records and to send requests to the general feed. Here are those primary keys and the sequence of production that should be followed:

• Agency.txt: List of transit agencies that provide the service (agency_id, agency_name, agency_url_agency_timezone,agency_lang, agency_phone, agency_fare_url, agency_email)
• Stops.txt: Pick up and drop off location (stop_id, stop_code, stop_name, stop_desc, stop_lat, stop_lon, zone_id, stop_url, location_type, stop_timezone, wheelshair_boarding)
• Routes.txt: table that identifies distinct routes (route_id, agency_id, route_short_name, route_long_name, route_type)
• Calendar.txt table defines service patterns that operate recurrently (service_id, monday, tuesday, wednesday, thursday, friday, saturday, sunday, start_date, end_date)
• Trips.txt: .... (route_id, service_id, trip_id)
• Stop_times: ..... (trip_id, arrival_time, departure_time, stop_id, stop_sequences)

Not all those informations are required,[|Follow this link] to see which files compose a standart GTFS feed and which field are formaly necessary.

A modified GTFS for Paratransit Network? GTFS Flex?

This open standard is useful for publishing schedule and geographic data which currently only models fixed-route public transportation systems. It must be adapted to support modeling of flexible public transportation services. For example, a paratransit network doesn't provide fixed schedules or formal stops and routes, which are needed to describe a public transport network with a GTFS Feed. Some files such as routes, trips and stops should be adapted.

GTFS-flex is a proposed extension to the General Transit Feed Specification. For the moment, it's only a prototype and there is no software that currently consumes GTFS-flex data.

Areas models (Demand responsive connector and point deviation)

Paratransit system can operate as demand-response services operating in a specified area. Some routes provide services with a single fixed zone, while others offer flexible services along an otherwise fixed route. The project pushed the area.txt new file that allows to define a polygon regions where flexible routes can occur. The proposal consists in a new file: area.txt (area_id, area_lat, area_long, area_sequence, service_area_id) that will link with the stop_times file. The stop_times file will be more functional and they propose to add some functionality to the stop_times as start service area id / end service area_id that indicates the beginning/ending of service in the specified area.

Request Stops

Many transit systems allow riders to board or alight from a transit vehicle at any location along a route. To describe this trend, the purpose is to add a continuous_stop field in stop_times.txt and routes.txt. In this proposal, a route can be annotated as supported continuous stops. The values would be:

• 0 : Normal stop behavior along the route
• 1 : Continuous stopping behaviour.

GTFS for paratransit

This GTFS Flex format hasn't yet been validated and only universities and cities have begun to use it. It isn't formally used by itinary platforms such as Google Map or Transit. The standard format can be used to describe a Paratransit system even if it doesn't follow formal transport system behavior. This section will focus on the required files (stops, routes, calendar, trips, stop_times and agency) which should be completed in order to provide a functional GTFS Feed:

• Agency.txt: The service in paratransit system is provided by hundreds of operators. Ideally, a neutral institution should be able to provide information such as agency_name or ..... If any government agency of this type doesn't exist, this data may be omitted.
• Stops.txt: In most of the cases, buses and minibuses do not follow any stop plan and they allow passenger to board or alight all along the road. Those are irregular and at the request to the driver. It's possible to identify some major stops like the terminal ones, but the others that composed the line aren't always easy to identify and it's not recommended to consider a fixed interval distance between each stop (as a stop every 400 meters). The best way is to map stops known and generally used by the public, the ones that are identified as stops by the population. Additionally, we will also make sure to map every node between lines and/or corridors.
• Routes.txt: For the route_id, an important phase of identification and constitution of a routes list with numbers for each of them. The stop_time raises incompatibility problem: those systems don't follow any schedule. Operators follow the demand and don't leave the terminal if they are empty. We can generate rough estimates for departure and frequency of trips from the main terminus at peak and off-peak hour and, with the GPS trace record of each line, estimate the arrival time to each stop.