GTFS on polish railway (disruptions, express trips and fares)

99 views
Skip to first unread message

pawajoro

unread,
Mar 25, 2019, 9:42:24 AM3/25/19
to General Transit Feed Spec Changes
Hi, GTFS geeks,

I'm changing our GTFS feed in railway company in Poland and face some limitations:
1) We time-to-time have disruption with bus replacement service. I don't find any ability to mark such a service. In our internal materials they are treated as the same route as "core" services. For me the best option is to connect core and replacement with block and somehow mark replacement park as disruption with additional column
2) We have some services marked in paper as "express" ones. Is there any woy to mark it in GTFS? Maybe there can be "service_type" column with enum to cover both mentioned cases.
3) I would appreciate adding air-conditioning in trips
4) There was a suggestion to add kilometer-based fare in GTFS. I think there is a lot of companies (especially suburban) using that type. The best solution to us would be "interval-based": for example there will be fare_kilometres.txt file, and there:
fare_id,from_km,to_km,price
1,0,5,4.00
1,6,10,5.00
1,11,15,6.00
5) And that-s more a question: can I add custom column in GTFS? I take into account, that it won't be readed by most of the software, but is there any further consequences?

Sorry for posting more like a question, not a change. And also - thank you in advance! :)

Leo Frachet (MobilityData)

unread,
Mar 25, 2019, 9:47:49 AM3/25/19
to General Transit Feed Spec Changes
Hi Pawajoro,

1) There is no official field for "replacement service". Google has a private extension on trips: trips.exceptional, but it is not part of the core spec. The documentation is here:


2) There is no way to describe "Express" service. If it's the whole route, maybe it's part of the route_long_name. If it's only some trip, maybe it's part of the trip_headsign.

3) There is currently no official way to describe AC on vehicles. There is a proposal on the table which is currently on hold. If you are interested please let me know. It's the GTFS-Vehicles proposal, which would add a vehicle_categories.txt file describing a type of vehicle with AC and some other (optional) features. Proposal is here:


4) How would you process the km fare? Is it based on the shape distance provided in shapes.txt and stop_times.txt ?

5) Yes you can add custom column in GTFS, indeed it won't be read by most of the software. But this is what most GTFS producer do. You can check MBTA (Boston) GTFS or TriMet (Portland) GTFS, they both have extra column.

Best,
Leo

Stefan de Konink

unread,
Mar 25, 2019, 9:51:46 AM3/25/19
to gtfs-c...@googlegroups.com
On maandag 25 maart 2019 14:47:48 CET, Leo Frachet (MobilityData) wrote:
> 4) How would you process the km fare? Is it based on the shape
> distance provided in shapes.txt and stop_times.txt ?

In The Netherlands we are using fare_rules.txt with origin_id en
destination_id to describe these 'units'.

--
Stefan

pawajoro

unread,
Mar 28, 2019, 5:46:44 AM3/28/19
to General Transit Feed Spec Changes
Hi, Leo,

thanks for your feedback :)

1) I'll use it. Thanks.

2) It's important to mark it because of planned timetable software. But I'll use custom column then.

Although: it might be useful to override the route type with trip type? Using extended types: (https://developers.google.com/transit/gtfs/reference/extended-route-types) it will be:
 - route_type is 106, as the majority of services on that line
 - express services are overriden with trip_type = 103
 - replacement overriden with 110 or 205

3) That proposal is awesome! It will also reduce work with marking trips, as we will put vehicle only, parameters will be described in vehicles_categories. I'll write my marks to it.

4) If there is column "fare_kilometers" or something like that, it is used. Otherwise stop_time distance_travelled is used. If it will be more flexible we can define fare to every amount of kilometers (1 = 4.00, 2 = 4.00, 3 = 4.00, ..., 5 = 4.00, 6 = 5.00, ... , 10 = 5.00, 11 = 6.00 and so on), it still will be really more convenient, than defining 40 000 rules.

In response do Stefan - I had that thought, but it will require about 200x200 = 40 000 rules (as each distance is calculated individually). So I would prefer some systematic solution.

5) Thanks, I will use it :)

Once more - thank you!

Orest
Reply all
Reply to author
Forward
0 new messages