Re: [gtfs-changes] A GTFS offset for intercity [long-distance] services?

[Aaron Antrim]

Hi Carl,

There is a lot to discuss here.  To add to the discussion and thought, I will offer some prior and current discussions.

route_type

There have been numerous prior discussions of route_type on this list.  In general, I think that I would prefer approaches that avoid conflating vehicle types with service types and amenities.  Instead, generally I believe it will be more useful and flexible if GTFS allows producers to specify particular amenities (like baggage) for stops and vehicles.  Also, attributes like frequency and stop spacing can be determined programmatically from the stop_times.txt file.

fares

There is a lot to discuss here.  There is a separate working group that has been discussing fares in GTFS:

https://groups.google.com/forum/#!topic/gtfs-fare-wg/

route / service names

The current scheme of describing services using route_short_name, route_long_name, and trip_headsign does not match up well to some intercity services.  These are a few relevant previous discussions:

1. "Proposal to clarify and extend route_short_name, route_long_name, route_desc" (November 2011): https://groups.google.com/d/topic/gtfs-changes/lTPayxg-PQs/discussion
2. GTFS Style Guide [Discussion of how to organize routes/trips in GTFS for intercity services] (March 2012): https://groups.google.com/d/msg/gtfs-changes/CmEYD1qj4HA/jqZnaUNzwCQJ
   

On Mon, Apr 8, 2013 at 2:55 PM, Carl Fredlund <carleric...@gmail.com> wrote:

Hello All,

I’m relatively new here, bear with me and let me know if I’m totally off on this.

In summary: intercity [long-distance] use of GTFS is growing, and there don’t seem to be many alternative standards. There are a lot of things that long-distance travellers care about that the current GTFS isn’t able to accommodate. What about making a intercity offshoot of GTFS?

I. It seems like there is a lot of potential there. Three main reasons:

I.1.) There seems to be a growing use of GTFS for long-distance / intercity mass transportation. For example:

- Open Data: SNCF, intercity bus and rail in Oregon

- Use Allowed / Tolerated: РЖД, MÁV, CA Shuttle Bus, Hoang Express

- Proprietary Use: DB, Amtrak

I.2.) It doesn’t seem like there is any other wide-spread data format for intercity buses, ferries and trains.

- Hafas for trains in a dozen+ countries in Europe

- ATOC CIT for trains in the UK

These a largely designed for single mode and country. Not necessarily for (smaller) operators to get their data in. What other formats exist.

I.3.) A lot of information that seems likely important for intercity travelers is any of the mentioned formats, including the current standard version on GTFS. Specifically because there are more likely competing services in long-distance markets, passengers are travelling longer and hence care more about amenities, travel time, etc, and dynamic pricing is common.

II. It seems like some of the things that should be included that aren’t in the current GTFS. Including the standard seems like it may make it overly complex for intracity applications. What about an offset that includes these specifics:

II.1.) Basic differentiation between types of buses and trains (route_type)

- Route types vary hugely on on local offerings and culture of what differentiations riders and operators understand.

- A hierarchical system seems to be pretty well understood by travellers.

- Many places in Europe service hierarchy for example S, R, RE, IC... is well understood by the travelling public.

- Americans where multiple service types exist - NE Corridor - also seek this information.

- Elsewhere yet like the UK, you have issues with branding outweighing general train types.

- The current GTFS “a bus is a bus” seems like too little information for most applications. Most people need to know if it’s a local city bus stopping every block or an express coach, same goes for heavy rail. (Subtypes of buses or trains implicitly imply something about the service quality even beyond class of service [1st or 2nd class].)

- A more detailed hierarchy or using the TPEG hierarchy has been suggested here in the past. I didn’t see that this was incorporated in the spec, but I see at least some of the TPEG types have been adopted by some users. (This seems to be the proposal around intercity services that has gotten the furthest so far)

-https://groups.google.com/forum/?fromgroups=#!search/proposal:$20Modify$20route_type$20to$20add$20new$20types$20and$20to$20group$20similar$20types$20together/gtfs-changes/keT5rTPS7Y0/Tuf_pHetlCQ (as well as some specific other requests for integration of TPEG types in Google Transit).

- Some types are missing for sure though it is, as discussed in that proposal, hard to create a perfect system including all route types (special cases: guided bus, minibus).  In general it might require some adaptation / addition of types to TPEG.

- In the end, data providers will be required to classify their services based around their own understanding. It’s possible allows for some flexibility through a naming field, though this seem like it can be problematic across languages.

II.2.) Amenities

This matters more for distance service and can be used for comparability of parallel services if including in the data standard.

- service class (Premium, 1st, 2nd, 3rd, Couchette, Sleepers...)

- details of beverage and meal service (offerings/price)

- availability of entertainment systems, wifi or other mobile internet, power supply

- baggage policy: limits/pets/bicycles (though the latter two would also be useful in intracity GTFS, proposals haven’t gone anywhere from what i can see)

II.3.) Pricing

- By far the most complicated issues.

- Buy-it-now pricing

- some discounted advance fares are shearly based on purchase periods

- others based on dynamic yield-management systems

- seems like these could be simplified though to buy-it-now

- Walk-up pricing

- Combining ticket pricing and seat / accommodation (sleeper) reservation fees.

I’d be happy to hear about experiences with using GTFS for intercity, thoughts on this idea, etc.

Cheers,

Carl

about.me/fredlund

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes...@googlegroups.com.
To post to this group, send email to gtfs-c...@googlegroups.com.
Visit this group at http://groups.google.com/group/gtfs-changes?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Carl Fredlund]

Thanks for the response and like, Aaron.

route_types 

You're suggesting adding fields for amenities around route.txt or around the vehicle, (some cases like baggage may also need to be tied to stops)? I am understanding that correctly?

fares

I am aware of the working group, seems like nothing regarding dynamic (yield-managed) pricing, or pricing for classes of travel, has come up yet. These are basically only applicable to long-distance and airport services. I am happy to discuss it there or as part of a possible long-distance specific offset of standard GTFS depending on where interest lies.

[Frédéric Thouin]

Hi everyone,

I also think that there a lot of potential.  We have been working with hundreds of bus companies over the past year and a half to standardize their schedules and they are all using different formats to store their data.  Our project is to display intercity bus schedules in a common format convenient to users.

We would love our standard to be compatible with GTFS, but there a few missing elements.  In addition to those highlights by Carl, we noted two other characteristics which do not seem to be supported, or at least not trivially:

1. The distinction between pickup and dropoff stops.  There are some stops where it's only possible to board the bus whereas there are other where it's only possible to get off.
2. The notion of interline routes where there are multiple agencies that operate different segments of the same route.

Cheers,

Frederic.

[Brian Ferris]

- The distinction between pickup and dropoff stops.  There are some stops where it's only possible to board the bus whereas there are other where it's only possible to get off.

Have you looked at the pickup_type and drop_off_type fields of stop_times.txt?  https://developers.google.com/transit/gtfs/reference#stop_times_fields

- The notion of interline routes where there are multiple agencies that operate different segments of the same route.

Have you looked at using the block_id field in trips.txt to link up interlined routes?  This is how most agencies model this situation.

Brian

[Carl Fredlund]

Thanks for the input Frederic. I am curious about your experience and thoughts on the importance of data on amenities (baggage, wifi...) and the suggestions on how to incorporate them.

- Pick-Up / Drop-Off

The issue with the pick_up_type and drop_off_type comes with cases where travel only between certain intermediate stops is forbidden. Is there a way to get around this?

A simple example is this bus (MFB006) running:

Munich

Friedrichshafen

Meersburg

Konstanz-Allmannsdorf

Konstanz

Zurich

Pick-up (passengers towards Zurich) / drop off (passengers from Munich) is allowed at all intermediate stops, but local travel between intermediate stops is restricted (for instance travel between Friedrichshafen and Meeresburg is forbidden).

- Interline Agencies

AFAIK block_id is confined to agencies in one feed.

I'm not sure exactly what cases are meant. Maybe you can give an example, Frederic?

The case I have in mind was a bus that ran intercity from Munich to Reutlingen and continued as a regional transit service under contract of the local RTA to Tuebingen. Traveling Munich to Tuebingen required two tickets but no change of vehicle.
The transit service would be in the corresponding RTA's feed and the long-distance service in the operator's own feed. (This route has since been changed.)

Similar issues exist with contract operators that contract with two RTAs, who have separate feeds, interdependently. The same vehicle runs back-to-back routes in RTA A and RTA B.

Carl

[PS Sorry about the formatting on the initial post.]

[Frédéric Thouin]

Good comments Carl.

Here are a few precisions:

• Amenities: These are definitely important features.  Wifi, fees and maximum baggage allowance, fees for transporting a bike are the ones that come up the most often.  There's also the issue of seat classes, e.g., if a bus has fully reclinable seats for overnight buses.  Although these details might be more suitable in the fare description?
  
• Pick-up and Drop-off: We've seen the scenario you're describing quite a bit.  Operators seem to address that by setting the price to null in the price matrix, but there's no explicit mention in the schedule description.
• Interline: It's not yet clear what the exact requirements about interline connections are; we could not get a clear explanation from operators yet.  But generally, I think the idea is to have something like "operated by".

Frederic.

You received this message because you are subscribed to a topic in the Google Groups "General Transit Feed Spec Changes" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gtfs-changes/6G7M1RJkXd8/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to gtfs-changes...@googlegroups.com.

[Andrew Jawitz]

Hello All,

   I'm a long time listener and first-time poster as I'm just now getting into the nuts and bolts of GTFS.  As Aaron is aware, my main area of expertise is in small cities/rural regions where data standards need to be very flexible.  This particular issue is of special relevance because I am working with a data set that intersects with two intercity bus services, two intercity rail services and another local "flex" bus service. The provider itself is considered a "flex" system because it has certain times in the schedule when it functions as demand response and others when it follows a fixed route.

   Thus far I have been working off of RITA's Intermodal Passenger Connectivity Database where they use a station code system akin to airport codes (E.G.-BRK=Brunswick, Maine)-  http://www.transtats.bts.gov/Fields.asp?Table_ID=1180 

 They have a category for "Code-Share Bus" where operators working as Amtrak Thruway can be identified as a connecting service. Is it already common practice for stop_ids to conform to station codes?  For example, the service I'm working with, the Brunswick Explorer, in Maine stops at the Brunswick Amtrak station which is also served by Concord Trailways.  Would it make sense to add "BRK" into the stop_id field?  

   

[Brian Ferris]

Andrew, I think it's totally reasonable to use station codes for GTFS stop_ids.  While it's true that there is currently no cross-feed identify system in GTFS (so your stop_id wouldn't explicitly match a hypothetical Amtrak feed that used BRK for Brunswick, Maine as well), using station codes in this way certainly improves the legibility of the feed and makes it easier to understand.  And who knows... maybe someday the US will have a global registry of all transit stops across the country with globally unique ids.  Mabye ; )

[Andrew Jawitz]

It would appear that RITA made an attempt to define a "FacilityID" field for facilities serving at least two different passenger transportation modes. 

  Comparing notes from my own experiences to the entries I'm familiar with it would appear that their method of measuring intermodal connectivity is quite accurate.  Some notable omissions would be Grand Central and Penn Station and other larger rail hubs where services may include NYC Subway, various bus services, Commuter Rail and Intercity Rail but its possible I missed it. I'm guessing the criteria for measuring how many "Brunswick Explorer" passengers are getting off at the BRK stop in order to use the train differs from transfers between the "A-Train" and NJ Transit at NYP.  The overview explains the metrics they used in some detail.-http://www.rita.dot.gov/bts/sites/rita.dot.gov.bts/files/publications/bts_technical_report/april_2009/html/entire.html

   There is also a sample table which can be found at- http://www.rita.dot.gov/bts/sites/rita.dot.gov.bts/files/publications/bts_technical_report/april_2009/html/box_c.html