Mexico City's team proposal

[Mariana CS]

Hello, 

 

Related to Emily Eros' message regarding the upcoming workshop I'm writing on behalf of the team that is working in Mexico City’s GTFS project, to share a series of technical proposals for adapting GTFS to work with non-stop based transport networks. 

 

You can read a draft of our proposals here:

 

https://github.com/conveyal/gtfs-internationalization/

 

These ideas come from our work over the last year to create a comprehensive data feed for the Mexico City transport network, including the city's microbuses system. The project, supported by the World Bank, has undertaken an extensive GPS-based ground truthing effort carried out by CTS EMBARQ Mexico, to map the over 1100 lines in the non-stop based system. The data collection work is on-going but we have already mapped several hundred microbus lines, as well as developed a complete GTFS feed for the city's scheduled transport services.

 

As part of the project the team has produced an example GTFS feed that incorporates a subset of the above modifications. Additionally we've made corresponding modifications to OpenTripPlanner, an open source transit routing system, to consume the adapted feed. These were an experimental undertaking, however, they may be useful as a reference implementation for others interested in making similar modifications. 

 

We're sharing the proposal here in hopes of soliciting feedback and ideas for improvement. Based on our experience we believe that the above changes are an appropriate solution to Mexico City's transit data needs. However we want to share our work in hope of finding common ground with those undertaking similar efforts in other cities. 

 

In light of the upcoming workshop it appears as though there's real potential to develop a solution that addresses the needs of large number of the world's transit users.

 

Regards,

 

Mariana

Department of Transportation in DF

[Jackie Klopp]

Thanks so much Mariana for this overview of your important work in Mexico City!

I look forward to hearing more about it at the workshop and learning more from your team. The Nairobi team has written up its experiences collecting data on the paratransit system into a draft paper. If anyone is curious to start reading about it the link is here. The Dhaka team also has some write ups we may be able to share soon. Everyone should feel free to circulate notes or thoughts in advance. 

I think we will have a very lively and helpful discussion!

Cheers,

Jackie 

--
You received this message because you are subscribed to the Google Groups "Making GTFS Work for the Rest of the World" group.
To unsubscribe from this group and stop receiving emails from it, send an email to making-gtfs-work-for-the-re...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Jacqueline Klopp
Associate Research Scholar
Center for Sustainable Urban Development
Earth Institute, Columbia University
475 Riverside Dr.
Suite 520
New York, NY 10115
(tel) 212-851-2979
(fax) 212-851-1780
skype jmklopp

[Nisar Ahmed]

Thanks to Mexico City and Nairobi teams for their wonderful insights into the workings of the informal transit systems in those two cities. The paper on the Nairobi system brought back memories from my experience of similar transit system in Dhaka. Mexico City and Nairobi teams have worked very diligently to make transit data from those cities fit into the GTFS and suggested a few necessary modifications to the GTFS schema.

As I understand, the purpose of the GTFS is to provide a simple mechanism for sharing structured transit data for greater public benefit. GTFS has very successfully modeled the configuration and timetables of a formal transit system in a simplified, easily consumable manner - thereby satisfying a broader public information need.

From Nairobi and Mexico City efforts two distinct use cases of informal transit data have emerged – 1) public information for journey planning, and 2) better transit planning and management. Both studies identify some limitations of GTFS in modeling informal transit data and have suggested data generalization in conjunction with certain GTFS schema enhancements. One suggestion is to introduce a mechanism to interpolate ad-hoc stops by the data consumer based on a parameter set by the data provider. This parameter assumes ad-hoc stops at a given distance interval between two consecutive formal stops. My experience in Dhaka suggests that the interval and number of these ad-hoc stops depend on various unpredictable factors including, but not limited to, the time of the day, crowding in the bus, and other financial motivation of the bus operator. Journey planning based on interpolated stops using a fixed distance interval has the potential for significant error – hence reducing the effectiveness of the information delivered.

Another suggestion was to use frequency based timetable based on empirical analysis of trip frequency in a route.  GTFS allows frequency based timetable under the assumption that vehicle departures from the trip origin will happen at a set frequency. This assumption does not hold true for informal transit. Vehicles depart as and when operators are ready to leave. Again, in my Dhaka experience I have seen buses on the same route leave very close to each other due to high passenger load while at other times buses may leave with a much wider headway due to low passenger count. Some of those buses departing origin stop with a much narrower headway may skip some ad-hoc stops while the ones with wider headway may make too many ad-hoc stoppage. When buses are not guaranteed to depart at a predictable frequency, setting a frequency based timetable in GTFS can create inaccurate trips that might generate erroneous transfers for journey planning.

For effective public information of informal transit system we may need to consider skipping over structured data and look into the potential for crowd-sourced real-time data captured and disseminated through mobile apps. On the other hand, a data schema that incorporates passenger counts, fare variations, route deviations, travel times, etc. and populated over time with crowd-sourced data can provide a strong information platform for service planning, operations, and management.

In the attached I tried to capture my random thoughts about informal transit data. These thoughts are the result of my experience working with GTFS and first-hand knowledge of informal transit system of Dhaka. Hope you will find it useful. Looking forward to an engaging discussion on November 12.

--Nisar Ahmed

[Nisar Ahmed]

In my earlier email I suggested that we consider using crowd-sourced real-time data for more effective information delivery for informal transit. Crowd-sourced real-time data can be built on top of a very basic GTFS data. This basic GTFS data may capture the fixed elements of informal transit and leave the unpredictable parts as optional. The basic GTFS would have the following characteristics.

1. Provide agency.txt file as per GTFS specs.
2. Provide stops.txt file as per GTFS specs, but only for the formal (fixed) stops.
3. Provide routes.txt file with expanded route_type.
4. Consider trips.txt, stop_times.txt, and calendar.txt as optional.
   

This basic GTFS will help capture the route configuration. I have proposed to make timetable related files as optional under the assumption that departure schedule is not important to informal transit riders. Timetable and ad-hoc stop data becomes critical when vehicle departure information is included in journey planning. A planned journey that includes only the trip path (route segments with transfer locations) calculated from route alignments and stop locations may provide just enough information satisfying informal transit riders need. The time element of a journey may not be necessary because of the fact that buses run frequently.

In addition to simplified journey planning, which will require enhancement to traditional trip planners, a bare-bone route and stop GTFS can be used for visual presentation (maps) of the transit system and for transit planning exercises. It will help reduce the amount of effort otherwise would be necessary to map informal transit to the standard GTFS.

--Nisar

[Brian Ferris]

Since we are all sitting in the room and talking about the mailing list ;) , I went back and I realized that I wrote a response to Mariana's proposal back in October that I ONLY sent to Mariana, so let me send my original reply to the whole list.

---

Very cool proposal!  A couple of comments:

For "interpolate_stops", it seems a bit weird that "0" indicates that stops SHOULD be interpolated, as the normal GTFS convention is "0" = disabled.  I understand that you did it in order to allow the interpolation distance to be specified within the column as well, but maybe it would be clearer if "interpolate_stops" mean the following: "0" = Do not interpolate and "1" = interpolate stops.  You could then introduce a "interpolate_stops_dist" column that could allow the feed producer to optional specify the interpolation interval (in meters) if they so desired.  I'm curious how often you think providers would specify the distance field in practice? (versus just allowing boarding at any point along the route).

For "route_type", would GTFS producers be allow to pick arbitrary values for "route_type" and it would just serve as a key into routes_types.txt?

What are your thoughts on keep "route_type" in routes.txt as is and introducing an additional "extended_route_type_id" (or maybe just "route_type_id" or "extended_route_type") that would be the key into route_types.txt.  You would then drop the "gtfs_route_type" field from route_types.txt (note that there is a typo in the gtfs_route_type" column name at the moment).  Feed producers would still have to pick the closest matching value for "route_type" from the existing GTFS vehicle types but they could then provide as much additional info in route_types.txt as needed.  I think the advantage of this approach is that it maintains backwards compatibility for existing GTFS feed consumers.  Even if they don't support route_types.txt, the results they produce using the not-localized-route-type is still better than nothing.

Thoughts?

Thanks,

Brian

On Sat, Sep 28, 2013 at 5:26 PM, Mariana CS <camposs...@gmail.com> wrote:

--

[do...@uonbi.ac.ke]

Thanks Brian, it was great to have the insights into the efforts being
made to ensure that GTFS meets the ever changing transit needs. I believe
that he joint efforts being made will go a long way in meeting the
challenges we have experienced with informal transit systems.

Regards

Dan Orwa
Nairobi Mobility Team

>> the city's *microbuses* system. The project, supported by the World