Looking beyond GTFS for improving transit in developing cities

[Michael Smith]

Over the last couple of weeks there have been some discussions on this list on trying to use GTFS to deal with the different types of situations encountered in more complicated cities such as Mexico City. In particular, there are issues with respect to microbuses and perhaps BRT. While it is key that GTFS data and trip planning are possible for such cities I am wondering if we need to broaden the scope of the discussion.

In particular I'm wondering if for microbuses whether we also need to tackle real-time GPS based information. My thought is that if microbuses are not fixed route and schedule based that perhaps additional technologies, such as real-time location info, should be investigated. Perhaps static GTFS type data is inherently limited and that for a dynamic system the passengers need dynamic information. And this could be more than telling passengers when and where to find their microbus. Perhaps they would also use their phone to request a ride.

In conjunction with creating GTFS data for developing cities, have others looked at using real-time info to help the passengers? Do others think that it is a topic worth exploring?

Michael

[De La Pena, Benjamin]

>”Perhaps static GTFS type data is inherently limited and that for a dynamic system the passengers need dynamic information.”

 

It is absolutely limited.  Consider that the GTFS originated from cities where a single agency (a transit agency) controls the system. GTFS is a publication feed – it’s designed to publish set routes, stops and schedules controlled by a hierarchical institution.  It’s not going to work for the highly distributed (even atomized) world of paratransit.  – It’s also designed to be one way communication. The agency publishes the feed and the users use the info.

 

I think we need to imagine a new data format that works for the provider (“where are the riders, what route should I take, what roads do I avoid”), the consumer (“how do I get from point A to B? what’s the most efficient route? What’s the cheapest route? Where do I get a ride?”) and the system managers (“What’s happening in the system? Where should we intervene to make it self-optimize?”).  A data format that will allow algorithm based dynamic responses and eschew top-down, hierarchical control.

 

 

 

Regards,

 

 

Benjamin dela Peña

Associate Director, Urban Development

The Rockefeller Foundation

420 5th Avenue

New York, NY 10018

 

bdel...@rockfound.org

t: +1 212.852.8215

c: +1 347.416.4358

 

www.rockfound.org

--
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.
 
 

[Michael Frumin]

Some thoughts:

Among the reasons GTFS has been so successful is that it took a very narrowly but clearly scoped (i.e. "limited") perspective on a particular problem it was trying to solve.  I imagine this was totally intentional.  The death of many/most standards comes when they try to solve too many problems and take forever to approve and get too complicated to be easily used.

Which is to say two things, in my opinion:

1. What's being discussed in this thread is quite outside the scope of GTFS (I believe) and might likely thrive better as its own very focused discussion about...

2. ... how to make the absolutely simplest and most narrowly-defined standard for exchanging data about non-scheduled/structured and demand-responsive services.

Critical to both of these is that they are about 2-way communications which GTFS is not, by design.  2-way communications are always a lot more complicated than unidirectional, so additional careful attention should be paid to managing that complexity and the scope of the proposed design exercise.

Thanks,
Mike

[Kevin Webb]

All,

I want to second what Mike Frumin wrote. 

A couple thoughts:

1) Mike's  correct that the limited nature of GTFS is what's made it successful. All throughout the technology world there are examples where "better," more complete (and complex) standards loosing out to standards that "get the job done." By many measures GTFS is an example of this -- it's being used in hundreds of cities and doing a fantastic job of what it does only because it gets the job done and nothing more.

That said, it doesn't work for a lot of the world because, from my perspective, a fundamental problem: it's overly precise. It assumes a highly specified, stop-based model which doesn't apply in less structured transport environments. These systems are rarely stop based (with the exception of terminal points or other key stops), and almost never have a schedules. 

However, based on our recent experience developing GTFS feeds in Manila and Mexico City (both of which are predominately unstructured), I think there are some simple changes that can address most of this concern. 

In Mexico we moved to use the route shape to define the location for boarding/alighting and interpolate the the stop locations along the shape (e.g. passengers can board/alight every +/- 100 meters). In Manila we did the same thing, but as a preprocessing step where the interpolated stops were included in the feed. The speed/timing was interpolated based on distance along route between the two (or more) specified time point stops. 

In short, adding one column ("interpolate_stops") to the routes.txt file allows us to model fairly reasonably the entire microbus system in Manila (and we're working on it now in DF). This is true at least to the extent that the routes are defined (and adhered to), but as we've learned from our conversations with regulatory authorities, routes do exist, they just may not always be mapped (in cases where routes don't exist at all a separate conversation is probably necessary to figure out why).

This could be taken a step further by adding a variance field to the times (e.g. travel times can vary by X minutes). 

2) The other thing that GTFS is bad at is localization. There's been a half-hearted attempt at this via the "translations.txt" extensions (something Google's adopted but isn't formally part of the GTFS spec), and even more poorly with the "hierarchical vehicle type" definitions (again part of Google's implementation but not documented). The reality is that most of the world doesn't speak English as a first language. And the US Federal Transit Administration's list of seven transit modes doesn't cut it (even the poorly documented HVT/TPEG list isn't ideal). GTFS can do better than this, and again with only simple changes (I have an idea for a "localized transit type" field which is dead simple).

3) I agree that the "two-way" interaction stuff doesn't really fit in this discussion. In fact there's a separate dialog going on now among developers working on US para-transit info services (in these cases, para as in mobility impaired). That's likely tracking toward a two-way protocol. And as a result it will be *much* more complex than what's hopefully needed to address the low hanging fruit for transit in many developing cities. 

If folks are interested in the two-way, demand responsive stuff I encourage you all to join that dialog here: https://groups.google.com/forum/#!forum/gtfs-flexible-wg. I think it's interesting and potentially relevant in the long-term but, echoing Mike's concerns, I think it's much more fraught in terms of technical risk. And personally I think it's less likely to evolve robust, generalized standards that can be adapted to new operating contexts in other parts of the world. 

I'm going to follow up with another series of emails outlining some of the specific ideas we came up with based on our experiences in Mexico and Manila and am curious to hear thoughts about value/opportunities on those fronts.

Thanks again for everyone's thoughts -- looking forward to seeing the dialog continue!

Best,

Kevin

 

-----------------------------------

Kevin Webb

p: +1.202.480.9322

e: kw...@conveyal.com

[Nisar Ahmed]

I think Benjamin has his finger on the pulse of the public transportation systems in developing countries. Public transportation information problem in countries like Bangladesh can be summarized with three inherent issues:

1. Absolutely no timetable structure - buses run as and when the operators and helpers feel like and stopping for as long/little as they wish. Only rule they abide by is the minimum number of trips the operator must make within a day's service.
2. Stops are defined but very loosely - bus operators will try to make all the defined stops, and make additional undefined stops as and when necessary to make a few extra buck.
3. Route patterns are defined but not always followed - governing entities define the route paths but bus operators not necessarily follow them strictly.

It is hard to see how these chaotic, but perfectly harmonious with the culture and lifestyle, structure of the public transportation system can be modeled with GTFS. It might be better to look at the problem from perspectives of users (riders), operators (drivers and helpers), owners, and  system managers (often the government) all together and try to develop something that turns this wonderful chaos into a harmony. It may not be fruitful to try to fit the GTFS model to solve a problem that requires a completely different approach.

I don't know what that solution is but I have a feeling that it might needs to digest and process data from multiple stakeholders through modern mobile communication technologies.

--Nisar

[Brian Ferris]

Regarding translations, I have previously documented Google's proposed translations extension at https://support.google.com/transitpartners/answer/2450962?hl=en  I've wanted to get this added to the official spec for a while now, but unfortunately, none of the agencies who are currently using the extension share their feeds publicly, a critical requirement in moving forward with official adoption.  I'm not sure if the translations proposal is of any use to you in its current form (unfortunately, maybe not?) but if it is, and you've got some feeds that are potentially going to be public that can use the feature, that'd go a long way towards helping formal adoption.

Regarding route types, I agree that the current proposals are kind of a mess.  Again, I've documented a bit of it at https://support.google.com/transitpartners/answer/2450962?hl=en but it only slightly helps.  I've promised some other GTFS providers that I would try to make a push to make these extended route types part of the spec and I wonder if we can't make room for some more ad-hoc transportation systems in there as well.

Either way, I definitely look forward to seeing some of your recommendations for updating the spec to better support unstructured transit systems.  Any progress on that?

Brian

[Brian Ferris]

I agree with the comments so far that GTFS, in its current form, is definitely not ideal for modeling the typically ad-hoc nature of unstructured transportation systems.  However, I'm also optimistic that with some simple changes, GTFS could go a long way towards doing better.

However, while I'm interested in the specifics of GTFS and other standards, I'm also interested to hear what your ideal transit app would look like for unstructured transit systems.  When there are no structured timetables, loosely defined stops, and flexible routes, what would you ideally tell a first-time transit rider when they start your app?  I'm curious because the nuts and bolts of GTFS were largely the result of Google and transit agencies wanting to build a transit routing application for structured transit systems.  I think whatever data format you decide on will largely be driven by the applications you want to build.  Knowing more about the specific use-cases you wish to enable might drive the conversation about how we can get the data to make it happen.

Brian 

[De La Pena, Benjamin]

It would depend on the mode, right?

 

Are you looking for the right place to wait for a Matatu or Trotro, or a jeepney to get to a particular place? (Routes –and route changes: where do you get off? Where do you connect?)

 

Are you hailing an auto-rickshaw?  

 

Are you an autorickshaw driver and you want to know where the demand is? Or are you waiting for a hail?

 

Even more advanced (put on your futures hat): are you a city transport manager and you want a system that dynamically adjusts fares depending on demand OR a system that “bids out” the routes or roads at particular times, dynamically adjusting supply and demand without central control.

 

(check out how some technologies are already improving informal transit: http://www.rockefellerfoundation.org/blog/innovations-transforming-urban)

[aaron]

Continuing in the free-form discussion, I'd add to Nisar's brief survey transit service operating features in developing countries.

I've had the opportunity to see some transit systems in China recently.  These transit systems are sophisticated.  The network is well-defined, but there is not a fixed schedule.  Vehicle headways may be adjusted dynamically at a dispatcher’s discretion, according to the current operating environment.  The operations of a given day are determined through processes beginning months in advance and continuing to the day of.  The steps of this process are:

1. One or more months in advance of a service day: An overall profile that defines route structure and approximate frequencies is determined one to several months in advance.  This follows the process of many U.S.-based transit agencies that expect to update their schedule about once every quarter, for example.  Based on their update cycle, many large-scale GTFS applications are appear built around the assumption that changes to the planned schedule will be known at least two weeks in advance (specifically, Google Maps, Walk Score, others).

2. 1-3 days in advance of a service day: A more precise frequency profile will be developed for each route.  This frequency profile determines how  headway shall incrementally change throughout the day.  This profile will be based on factors such as expected construction projects, congestion, weather, and ridership. 

3. On the day of service: Using the frequency profile developed a few days before as a guide, dispatchers will send buses out on routes.  Frequency of service may be further affected by all factors including passenger demand, traffic conditions, and equipment and bus operator availability.

So, these services can be modeled within the current GTFS.  But they could be better represented if there were ways to specify that:

1. The service doesn't have scheduled stop times

2. Travel time is approximate (add in another level, and I could imagine systems and data to specify a range of variability)

--
Aaron Antrim
www.trilliumtransit.com
Portland, Oregon

To unsubscribe from this group and stop receiving emails from it, send an email to making-gtfs-work-for-the-rest-of-the-world+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
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-rest-of-the-world+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
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-rest-of-the-world+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

-----------------------------------

Kevin Webb

p: +1.202.480.9322

e: kw...@conveyal.com

--
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-rest-of-the-world+unsubscribe@googlegroups.com.

[Michael Frumin]

Aaron, thanks for that info.  It would be very interesting to learn more about how a true frequency-based operation works (from an operating perspective that considers actual physical resources, namely vehicles and drivers).

In the context of your 2nd recommendation (find ways to represent that travel time is approximate), I'd just like to add that this really exposes what I see as the elephant in the room regarding GTFS, trip planners, etc. in the parts of the world currently using them.  Even in a highly scheduled transit operation/service (outside of the swiss national railway), travel times are approximate, random, and dynamic.  Especially for buses but also for subways/metros.  The fact that we take these GTFS schedules for urban transit services and have a trip planner tell someone to arrive at their bus stop tomorrow at 3:23pm on the dot and then ride the bus for 17 minutes to their destination is crazy.

Hopefully this discussion and line of work will result in both data standards and rider-facing tools that present information in a more realistic manner the world over.  For example, "show up at this bus stop around 3:20pm, you should have to wait up to 5 minutes, and the ride to your destination will take about 20 minutes but could be as long as 30."

Thanks,
Mike

To unsubscribe from this group and stop receiving emails from it, send an email to making-gtfs-work-for-the-re...@googlegroups.com.

[Brian Ferris]

I'd focus on the Matatu / Trotro / jeepney case for a second.  How would a Matatu app look different than a typical transit routing app?  How would you communicate where to get on and where to get of?  Can you say anything about frequency of service?

[De La Pena, Benjamin]

Your app could tell you where you are and warn you where to get off and catch the next Matatu (“get off after the next 2 intersections, catch Matatu heading north” or “ There are two matatu routes that operate on this road. Ask if they are going to the Hill Country before getting on”)

 

Your app could tell you how many Matatus run along the corridor at a given moment in time? (“at 1pm, Matatus may come every 15 minutes”  or “at 6pm, Matatus will come every half minute”)

[Adam White]

Hi Everyone,

This is Adam from the Matatu team in Nairobi~I can think of dozens of opportunities for technology to serve lots of different users. In addition to lots of the commuter focused services, some like Benji has proposed above which, I would think that there are also some interesting use cases for this type of data that serve lots of other actors as well. For example:

-Operators (drivers/conducters) could identify alternate routes, or even begin to understand demand more dynamically.

-Traffic Data can be linked to route information to warn about bunching or delays in planning and "dispatching".

-Insurance companies can better understand the route safety of a vehicle (or even monitor)

-Planning(or not planning but just starting) a routes can identify service gaps and linkage points into the system

-Planners can begin to approximate some transit usage or demand information or cross reference transit demand surveys

-Operators can identify routes which would be easier to upgrade to higher capacity vehicles.

Just some ideas to start, but clearly a few would be built on more than just the basic data--

-Adam

--

Adam White

Adam.E...@gmail.com

int'l: +1 310-893-0793

@AdamERWhite

[jmklopp]

Hi all, 

In Nairobi there are already some apps being developed.

Here is MatNavi from Kichitaro Shiojiri a former MA student at the University of Nairobi which gives you a sense of how a basic navigation tool might work. 

http://www.youtube.com/watch?v=4xfEs-HJRDY

Here is an andriod app that is already on the market. We are working with its creator Laban Okune who is now improving it using our  modified GTFS data for paratransit

https://vc4africa.biz/ventures/ma3route/

www.ma3route.com/‎

Our team is trying to work with app developers as we build the data set to get feedback from them on workign with it.

Jackie

To unsubscribe from this group and stop receiving emails from it, send an email to making-gtfs-work-for-the-rest-of-the-world+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
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-rest-of-the-world+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
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-rest-of-the-world+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

-----------------------------------

Kevin Webb

p: +1.202.480.9322

e: kw...@conveyal.com

 

--
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-rest-of-the-world+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
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-rest-of-the-world+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
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-rest-of-the-world+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
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-rest-of-the-world+unsubscribe@googlegroups.com.

[Kevin Webb]

Brian,

That's great news about potentially improving the documentation on
localization and route types. If it's useful we might be able to
incorporate these features into some of the feeds we're helping with
(which are open) and help move the conversation forward. I'd also
love to discuss how we can further expand on the route type
definitions. My sense is there's a gap between what's happening with
the localization and HVT types that still needs to be address,
however, I may just not fully understand what's already being done.

Re. your question on how a non-stop-based app might differ from what's
currently available:

From my perspective I don't think this necessarily requires a huge change.

In the cases where you can identify the path of a given route you can
use the map to identify the nearest opportunity for boarding.

For the experiments we've been doing with preprocessing data (adding
interpolated stops to the GTFS), the road names from the base map were
used to label interpolated stops. But if you do it on the fly
(interpolate board/alight locations from the trip shape when importing
GTFS) the trip planner could pull in any available info in the map,
including points of interest, intersections, etc. to describe the
boarding/alighting location.

At that point it works the same as current journey planners, at least
in concept. Seems like there's still lots of room for innovation on
UI, particularly with emphasis on SMS and non-map based interfaces.

I have a couple related questions:

1) Are there different/useful ways do define where boarding/alighting
occur? At the moment we're just using distance (every so many meters)
or at intersections, but this is largely for our convenience. I'm
curious if there are conventions that are useful to encode or
encourage (e.g. board at the middle of blocks, far sides of
intersections, etc.)? Are there rules about this, followed or
otherwise, in different cities?

2) How can we begin to address the time variance problem? That's not
something we've explored yet but it seems critical, and potentially
easy.

At the most basic level, if there was just a place to keep track of
how much journey times/headways can vary that could be incorporated
into the UI. The interface show the time ranges on different routes
(expected wait time: ~10-20 minutes) which seems useful if the journey
planners didn't fully incorporate the range into consideration, though
that's also possible. There are lot of different ways this could be
implemented in the current GTFS but I don't know what's most realistic
or useful.

3) Can we think about a real-time layer (leveraging GTFS-RT) that
allows headway updates in the the kind of dispatch operation like
Aaron described? That could be as simple as adding a headway field to
the TripDescriptor messages in GTFS-RT, and could address a good chunk
the challenge he described.

Similarly are there ways that this could be useful in updating changes
in schedule variation per 2)? For example, would it be useful to say,
"buses are arriving every 20-30 minutes today because of rain" and be
able to update that on the fly? This might also address Mike's NYCT
needs too if it offers a generalized way to fudge schedules based on
real-time variation updates. Again there are probably simple and
complex ways to implement, but I'm not sure what's best.


Kevin

>> Cc: making-gtfs-work-for-...@googlegroups.com

>> making-gtfs-work-for-the-re...@googlegroups.com.

>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>> --
>> 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.
>>
>>
>>
>>
>>
>> --
>> 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.
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> -----------------------------------
>>
>> Kevin Webb
>>
>> p: +1.202.480.9322
>>
>> e: kw...@conveyal.com
>>
>>
>>
>> --
>> 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.
>>
>>
>>
>>
>>
>> --
>> 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.
>>
>>
>>
>>
>>
>> --
>> 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.
>>
>>
>>
>> --
>> 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.
>>
>>
>>
>>
>
> --
> 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.

[Kevin Webb]

Also, +1 on Benji's comment about basing service frequency on the
number of vehicles operating on a given route!

It's easy arithmetic to figure out headways if you know average speed,
distance, and vehicle counts and it seems that's often what's known
(or can at least be estimated). It seems better to encode the
assumptions rather than the derived values. That way at a later stage
it might be possible to vary one of the values based on real-time info
(e.g. slower average speed, or more/less vehicles) and update both the
headways and journey times automatically.

And I think there are ways that this could be encoded GTFS that
wouldn't break existing apps. You could include the additional data as
supplemental, along with the derived values so they could be used to
override assumptions if conditions change...

kpw

[Michael Smith]

One situation I've run into working with many agencies is that last-second changes are often made. Mistakes with data are fixed, detours are included, sudden changes to service are made, etc, all at the very last second. This means that Aaron's descriptions are for how structured agencies *should* operate (as opposed to how they actually do operate). All systems using such data also need to be flexible enough to handle the real-world situations that most agencies are too embarrassed to talk about. You would be surprised how often GTFS data is not accurate. I such flexibility is a very important consideration for any transit application. 

Mike

To unsubscribe from this group and stop receiving emails from it, send an email to making-gtfs-work-for-the-re...@googlegroups.com.

[tay...@itpworld.net]

+1 on the point that Benji made and Kevin reiterated regarding basing service frequency on the number of vehicles operating on a route.  Our experience in Manila was that this is the approach being used on the MRT and LRT fixed line routes, and was equally applicable to the Jeepney routes - although we would have needed to estimate the number of Jeepneys operating along each route at different times of day.

Kevin's point about encoding the assumptions rather than the derived units is therefore key, since it would provide a degree of flexibility needed to model in GTFS the inherent flexibility associated with these kinds of services.