Disallow transport between some stops in one trip

[Petr Sykora]

Hi,

I don't know how can I develop SW that export data of one agency to GTFS with this situation.

I have one trip with stops A, B, C, D.
- You can pickup or drop off on all these stops.
- You can't pickup on stop B and drop off on C (the agency don't have licence for transport people in one City - they have licence only for regional transportation (cross city) - so you can pickup on B and drop off on stop A or D but not C.


Can you for helping...
Thank you.

[Stefan de Konink]

On Saturday, January 7, 2017 2:39:05 PM CET, Petr Sykora wrote:
> I have one trip with stops A, B, C, D.
> - You can pickup or drop off on all these stops.
> - You can't pickup on stop B and drop off on C (the agency
> don't have licence for transport people in one City - they have
> licence only for regional transportation (cross city) - so you
> can pickup on B and drop off on stop A or D but not C.

It is quite easy. Export multiple overlapping trips. Where per unique
variant only one 'for-boarding' stop is marked as for boarding. You vary
the drop-off by the allowed to be drop off.

trip 1:1;
A = pickup
B = dropoff
C = dropoff
D = dropoff

trip 1:2;
A = can be skipped
B = pickup
C = no dropoff or pickup allowed
D = drop off

trip 1:3;
A = can be skipped
B = can be skipped
C = pickup
D = drop off

Your solution :) We have implemented this for Flixbus in Europe.

--
Stefan

[Aaron Antrim]

Trillium has also used this approach for some feeds.

Does this group think we should formalize practice around this in some way? This approach with multiple overlapping trips will work for trip planners but would pose problems for software generating timetables, real-time prediction software, or other systems.

Some previous discussion of this: "forbidden travel in stop pairs" (October 2011): https://groups.google.com/d/msg/transit-developers/eTeUPDzlV5Q/U8spEkmuj_8J

[Ellis M. Verosub]

+1 for formalizing practice around this in a way that doesn’t require duplicating trips.  While this approach works for routing applications, it creates duplicates in departure board displays and other similar consumer features.  In addition, handling this gracefully would enable consumer applications to explain the pickup/dropoff rules and policies to customers, so that they can have transparency into what is allowed.

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/678a3c1b-8db2-4461-afc9-fd1a74fb1d1f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Petr Sykora]

I think the way is use something like https://developers.google.com/transit/gtfs/reference/gtfs-extensions#TripToTripTransfers Trip - to Trip transfer

in transfers.txt will be trip Id (will be same), stop_id with this limitation and transfer_type = 3 (no transfer is possible)

only what seems to me quite weird is that is't not transfers by foot but by vehicle...

[Josef Petrák]

+1 For proposed approach. (Dis)Embarking should be marked by attribute of stop, not by overlapping trips.

[Aaron Antrim (Trillium)]

Here are two ideas for representing disallowed local travel (or between some stops on a trip):

1. Take the current approach of overlapping virtual trips (as Stefan describes it) but add additional requirements. The times of the overlapping trips must match exactly (though pickup and drop-off types are different). Also require either:

• trips.block_id: The overlapping trips must all share the same block_id. This indicates they all represent the same vehicle trip.
  
• trips.parent_trip_id: Add a new field, parent_trip_id, which allows all the virtual trips to be grouped together.
  

2. Add a new field, stop_times.travel_zone, that identifies local travel zones. Define rules for these zones in a new travel_zones.txt file.

My preference would be for approach #1 because it offers (limited) backward compatibility with the Spec and current practice.

Thoughts?

To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes+unsubscribe@googlegroups.com.

[Dave Barker, MBTA]

I like it, I'm trying to work through some of the details. Do you imagine that the parent trip would have its own entry in trips? Would its stops appear in stop_times? 

Part of the reason I ask is GTFS-realtime. Let's assume the parent trip_id doesn't appear as its own entry in trips and doesn't appear in stop_times. I don't think it would be a problem to have TripDescriptors for both child trips, each of which has the same value for vehicle. But it's less obvious how Vehicle Positions should work. It could list the same vehicle twice, once in relation to each child trip_id, but that would probably break some feed consumer assumptions. It could appear once and arbitrarily reference one child trip or the other and give current_stop_sequence / stop_id according to that trip. It could use the parent trip's trip_id and still include stop_id while omitting current_stop_sequence. If a stop is being visited more than once then information would be lost.  

The other alternative is to create a trip in trips and stop_times for the parent trip. The stop_times would all have to forbid boarding and alighting. I don't know what route_id would be used for the parent trip, or if that information should be considered meaningful. Probably too much trouble to go through just to get current_stop_sequence into Vehicle Positions, but it could be useful for other reasons to have in one place the record of the real order of the stops. 

I think it's a straightforward solution to this problem. I'll see if I can come up with an alternative idea that solves a wider set of problems in this space. 

-Dave Barker, MBTA

To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes...@googlegroups.com.

[Dave Barker, MBTA]

Here's a variation of the parent_trip idea that keeps the relationship but eliminates the vehicle/passenger hierarchy to add flexibility. It uncouples vehicle trips from allowable passenger trips when necessary, and ties them back together at the stop_id level. In so doing it provides a means to address a cluster of connected problems. 

GTFS

• trips.block_id: The overlapping trips must all share the same block_id. This indicates they all represent the same vehicle trip.
  

• trips.trip_representation_type:  Identifies whether trip models the allowable passenger trip, the physical vehicle trip, or both.
• 0 (or empty): Conventional. A normal trip. Represents both the vehicle's trip and all allowable passenger origin-destination pairs on it.
• 1: Passenger. Trip represents a set of allowable passenger origin-destination pairs, not a vehicle's physical path of travel. Every stop_time of such a trip must have a parent_stop_time_id matching a stop_time of at least one vehicle trip. 
• 2: Vehicle. Trip represents vehicle's physical path of travel. A vehicle trip should have stop_times for all the stops it makes. Its stop_times must all have pickup_type and drop_off_type of 1 (not available) since the trip does not represent a set of passenger origin/destinations.  Every revenue stop_time of such a trip should have a parent_stop_time_id matching a stop_time of at least one passenger trip. 
• trips.trip_route_type: allows a trip to override its route's route_type. 
• stop_times.parent_stop_time_id: identifies a stop_time as representing the same instance of a vehicle-trip stop, or the same instance of a passenger-trip stop, as another. For every parent_stop_time_id value that is used, the following must be true of the set of stop_times that use it: 
• Must include trip_id's of 0 conventional trips*, 1 or more passenger trips, and 1 or more vehicle trips. 
• Must include no trip_id more than once. 
• Must include only trip_id's with the same service_id*.
• Must include only stop_id's that are equal, or only stop_id’s that have the same parent_stop. 
• Must not contain arrival_time values, departure_time values, or timepoint values that contradict each other. (An empty value / string is not considered to contradict a not-empty value / string.)
• 
  

GTFS-realtime

• Vehicle Positions: references conventional trips and vehicle trips, but not passenger trips. 
• Trip Updates: should include conventional trips and passenger trips. (Vehicle trips not forbidden but do not substitute for including passenger trips.) 
• Alerts: should use conventional trips and passenger trips. (Vehicle trips not forbidden but do not substitute for including passenger trips.)

Examples

Here's how this would work in practice. In all the following examples except the first one, every stop_time has a parent_stop_time_id common to all trips within the example serving the same stop.  

1. Typical trip: set trip_representation_type to 0 or blank. Leave parent_stop_time_id blank.
   
2. Trip that forbids local travel: create passenger trips to account for all allowable origin-destinations and no other origin-destinations. Create one vehicle trip with all stops. 
   
3. Vehicle trip that serves two routes (1 and 2) in sequence with a common portion during which it is serving both the end of the trip on route 1 and the beginning of a trip on route 2: two passenger trips, one on route 1 including the common stops at the end (drop-off only), one on route 2 including the common stops at the beginning. One vehicle trip including all stops.  In-seat transfers from route 1 to route 2 are modeled in the manner they usually are**. 
   
4. Vehicle trip that serves a hybrid version of two routes (i.e. MBTA “route 62/76," a bus trip that follows a path serving portions of route 62 and portions of route 76): create one passenger trip for each route, and one vehicle trip to combine them. Include the same stops on all three trips.
   
5. Vehicle trip that serves one route “via” another (i.e. MBTA train 221, which leaves the downtown hub, serves stops on the Lowell Line, then travels over a connector to serve stops on the Haverhill Line): Create one vehicle trip and two passenger trips. Vehicle trip includes all stops. Both passenger trips include the downtown hub (common to both lines), one includes the Lowell Line stations, and the other includes the Haverhill Line stations. The fact that customers are allowed to ride from a Lowell Line station to a Haverhill Line station is represented by an in-seat transfer**.
   
6. Commuter rail trip that is presented as one trip but actually requires a transfer to bus to reach the last stop: One passenger trip representing the trip from end to end. Two vehicle trips, one containing all but the last stop, one containing the last two stops and a trip_route_type of 3. At the stop_time where they meet the passenger trip stop_time includes an arrival and a departure, the train stop_time has an empty departure time, and the bus stop_time has an empty arrival time. Each vehicle would be tracked in Vehicle Positions.
   
7. A bus that leaves from San Francisco to let customers transfer to an Amtrak train in Emeryville, in which customers can only use the bus if they've bought a ticket for the train: similar to the previous example, one passenger trip and two vehicle trips, with the modification that the passenger trip has a drop_off_type of 1 (not available) at Emeryville. 
   
8. Train that splits, i.e. four-car train that goes from station A to B to C where it splits into one two-car train that goes to D and E and another two-car train that goes to F and G: create an A-B-C-D-E passenger trip, A-B-C-D-E vehicle trip, A-B-C-F-G passenger trip, and A-B-C-F-G vehicle trip. Group each station's stop_times into a parent, except for C which is grouped into an E-bound parent and a G-bound parent. (A and B each have 4 stop_times and one stop_time_parent_id; C has 4 stop_times and two stop_time_parent_ids; D, E,F, G each have two stop_times and one stop_time_parent_id.) In this way the stops at stations A and B is registered as one train stopping, C is represented as two trains (since at that point there are two options to board), and then D-E / F-G each get their own trains. Each vehicle would be tracked in Vehicle Positions (as two vehicles when the train is coupled.)

The distinction between 6/7 and 8 may be a weak spot. In both cases there are two vehicles that are acting in strict coordination with each other, but in 8 they’re actually coupled together, they can be shown as a single arrival of one vehicle serving two routes on a countdown display. That’s represented through the fact that in 6 and 7 the vehicles share a parent_stop_time_id but within that parent_stop_time_id one has an arrival_time and the other has a departure_time. Hence in case 8 the coupled vehicles literally share an arrival at the station and share a departure from the station, while in cases 6 and 7 they share a stop_time but do not share an arrival or a departure. This may be sufficient if it’s documented explicitly. 

But overall this provides a means to address several related problems with predictable GTFS and GTFS-realtime representation. 

-Dave Barker, MBTA

* For simplicity's sake I'm forbidding a couple of things in this description that are harmless but would have no effect under the current scope.

** This can work with the current block_id approach or with the proposed "transfer rules for routes and trips, and in-seat transfers."  If the current block_id approach then block_id must be omitted from the passenger trips in example 2, trip that forbids local travel, or it would be implied that local transfer was allowed via in-seat transfer. If the proposed “transfer rules” approach then best practice would be to omit block_id from passenger trips, since block_id is specific to vehicle movement. 

[Petr Sykora]

I think all these suggestions are too difficult to implement. (For data provider also for data consumer). 

We need one trip of vehicle to be one trip in trips.txt. (Because it is reality...)

Only information have to be add is information about disable transport between pair of stops.

I think the easiest way for implementation is use something like https://developers.google.com/transit/gtfs/reference/gtfs-extensions#TripToTripTransfers Trip - to Trip transfer

in transfers.txt will be trip Id (will be same), stop_id with this limitation and transfer_type = 3 (no transfer is possible)

or add a new file, where this transfers limitations of trips have been located.

[Stefan de Konink]

On maandag 29 mei 2017 10:29:34 CEST, Petr Sykora wrote:
> I think all these suggestions are too difficult to implement.

I'm sorry, but these suggestions are already implemented at both consumer
as producer level in multiple implementations. Don't spread fear,
uncertainty and doubt.

> I think the easiest way for implementation is use something
> like https://developers.google.com/transit/gtfs/reference/gtfs-extensions#TripToTripTransfers Trip
> - to Trip transfer

If you suggest that, you don't have an idea what should be implemented at
consumer level to filter. All the work is now done at the producer level,
with no room for reinterpretration.

--
Stefan

[Petr Sykora]

Dne pondělí 29. května 2017 10:35:18 UTC+2 Stefan de Konink napsal(a):

On maandag 29 mei 2017 10:29:34 CEST, Petr Sykora wrote:
> I think all these suggestions are too difficult to implement.

I'm sorry, but these suggestions are already implemented at both consumer
as producer level in multiple implementations. Don't spread fear,
uncertainty and doubt.

I'm not happy about this implementation  - in reality there is only one bus that made one trip and block_id has another mean (

"A block consists of two or more sequential trips made using the same vehicle, where a passenger can transfer from one trip to the next just by staying in the vehicle."

(https://developers.google.com/transit/gtfs/reference/trips-file) but there is no transfer between these trips. It's not the same...

> I think the easiest way for implementation is use something
> like https://developers.google.com/transit/gtfs/reference/gtfs-extensions#TripToTripTransfers Trip
> - to Trip transfer

If you suggest that, you don't have an idea what should be implemented at
consumer level to filter. All the work is now done at the producer level,
with no room for reinterpretration.

Perhaps not all, it doesn't matter for trip planner, but for example if you wanna show timetable from this data, you have to create deduplication of this trips. Also there is question what about realtime data...

[Stefan de Konink]

On maandag 29 mei 2017 11:01:07 CEST, Petr Sykora wrote:
> Perhaps not all, it doesn't matter for trip planner, but for
> example if you wanna show timetable from this data, you have to
> create deduplication of this trips. Also there is question what
> about realtime data...

Doesn't parent_trip_id solve that?

--
Stefan

[Dave Barker, MBTA]

Thinking about this after a few days away from it, pushing the aggregation down to the stop_time level with parent_stop_time_id gives the most flexibility, but more flexibility does bring complexity with it. Almost all of the same problems can be solved using a parent_trip_id instead, provided that that parent is used to aggregate passenger trips and vehicle trips together without making either one the parent of the other. There's actually a way for it to handle "two trips with a common portion" quite well. The only case that it doesn't handle at all is that of a train that splits, which is much less common than some of the other challenges. 

I adopted my earlier write-up to apply the parent at the trip level instead of the stop_time level. I've pasted it below. The main differences are in trips.trip_representation_type, stop_times.parent_stop_time [removed], trips.parent_trip [added], the examples intro, and examples 2, 6 and 8. 

---

GTFS

trips.block_id: The overlapping vehicle trips must all share the same block_id. This indicates they all represent the same vehicle trip.

• trips.trip_representation_type:  Identifies whether trip models the allowable passenger trip, the physical vehicle trip, or both.

• 0 (or empty): Conventional. A normal trip. Represents both the vehicle's trip and all allowable passenger origin-destination pairs on it.

• 1: Passenger. Trip represents a set of allowable passenger origin-destination pairs, not a vehicle's physical path of travel.  Must have a parent_trip.
• 2: Vehicle. Trip represents vehicle's physical path of travel. A vehicle trip should have stop_times for all the stops it makes. Its stop_times must all have pickup_type and drop_off_type of 1 (not available) since the trip does not represent a set of passenger origin/destinations.  Must have a parent_trip. 
• 3: Parent. This trip listing ties one or more passenger trips together with one or more vehicle trips. It has no stop_times of its own. See trips.parent_trip below. 

• trips.trip_route_type: allows a trip to override its route's route_type. 

• trips.parent_trip: identifies a trip as being part of a larger conceptual trip. All trips with the same parent_trip must: 
• Include trip_id's of 0 conventional trips*, 1 or more passenger trips, and 1 or more vehicle trips. 
• All have the same service_id*.
  

• Must not contain arrival_time values, departure_time values, or timepoint values that contradict each other. (An empty value / string is not considered to contradict a not-empty value / string.)

• Best practice: should have the same headsign_text. 

GTFS-realtime

• Vehicle Positions: references conventional trips and vehicle trips, but not passenger trips or parent trips. 

• Trip Updates: should include conventional trips and passenger trips. (Vehicle trips not forbidden but do not substitute for including passenger trips.) 
• Alerts: should use conventional trips and passenger trips. (Vehicle trips not forbidden but do not substitute for including passenger trips.)
  

Examples

Here's how this would work in practice. Except where noted all trips listed in an example would share the same trip_id.  

1. Typical trip: No change. set trip_representation_type to 0 or blank. Leave parent_trip_id blank.
   

1. Trip that forbids local travel: create passenger trips to account for all allowable origin-destinations and no other origin-destinations. Create one vehicle trip with all stops. 
   

1. Vehicle trip that serves two routes (1 and 2) in sequence with a common portion during which it is serving both the end of the trip on route 1 and the beginning of a trip on route 2: create a route 1 passenger trip and route 1 vehicle trip with the same parent_trip_id, and a route 2 passenger trip and route 2 vehicle trip with the same parent_trip_id. Route 1's passenger trip includes the common-portion stops (drop-off only), while the vehicle trip does not. In-seat transfers from route 1 to route 2 are modeled in the manner they usually are**. When the vehicle reaches the common portion, VehiclePositions begin uses route 2's vehicle trip_id. 
   

1. Vehicle trip that serves a hybrid version of two routes (i.e. MBTA “route 62/76," a bus trip that follows a path serving portions of route 62 and portions of route 76): create one passenger trip for each route, and one vehicle trip to combine them. Include the same stops on all three trips.
   
2. Vehicle trip that serves one route “via” another (i.e. MBTA train 221, which leaves the downtown hub, serves stops on the Lowell Line, then travels over a connector to serve stops on the Haverhill Line): Create one vehicle trip and two passenger trips. Vehicle trip includes all stops. Both passenger trips include the downtown hub (common to both lines), one includes the Lowell Line stations, and the other includes the Haverhill Line stations. The fact that customers are allowed to ride from a Lowell Line station to a Haverhill Line station is represented by an in-seat transfer**.
   

1. Commuter rail trip that is presented as one trip but actually requires a transfer to bus to reach the last stop: One passenger trip representing the trip from end to end. Two vehicle trips, one containing all but the last stop, one containing the last two stops and a trip_route_type of 3 to indicate that it is a bus. Each vehicle would be tracked in Vehicle Positions.
   

1. A bus that leaves from San Francisco to let customers transfer to an Amtrak train in Emeryville, in which customers can only use the bus if they've bought a ticket for the train: similar to the previous example, one passenger trip and two vehicle trips, with the modification that the passenger trip has a drop_off_type of 1 (not available) at Emeryville. 
   

1. Train that splits, i.e. four-car train that goes from station A to B to C where it splits into one two-car train that goes to D and E and another two-car train that goes to F and G: Do not use parent_trip_id. Solve as you otherwise would, either with one a A-B-C-D-E trip and one C-F-G with a transfer available between them, or A-B-C  C-D-E and C-F-G with either transfer available. 

---

Better? Worse? 

-dave barker, mbta

* For simplicity's sake I'm forbidding a couple of things in this description that are harmless but would have no effect under the current scope.

** This probably works much better with "transfer rules for routes and trips, and in-seat transfers."  If the current block_id approach then block_id must be omitted from the passenger trips in example 2, trip that forbids local travel, or it would be implied that local transfer was allowed via in-seat transfer. If the proposed “transfer rules” approach then best practice would be to omit block_id from passenger trips, since block_id is specific to vehicle movement. 

[Andrew Byrd]

Hello,

It’s interesting to see how much interest there is in this concept of forbidden travel. I’ve heard this cited repeatedly as the primary example of a “specifically French” characteristic that makes it impossible to feed French trip planners with only GTFS. But the situation in France is basically the same described elsewhere: for regulatory reasons you’re not allowed to use long-distance trains for local travel. If a mechanism is added to GTFS to forbid travel shorter than a certain distance, or between certain stop pairs, this would be a major step toward making it possible to properly feed data into French trip planners using standard GTFS.

However, while I’m sure this “overlapping trips” approach can be made to work, it feels overly complex to me. It seems like a stopgap measure that models the situation only for trip planning, while not really following the semantics of the GTFS objects being used. 

How much flexibility to we really need? Don’t all real-world use cases just consist of banning travel between certain stop pairs on certain routes or trips?

Andrew

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/baad1f15-6505-48b6-9433-e0bc1b69d21a%40googlegroups.com.

[Stefan de Konink]

On dinsdag 6 juni 2017 07:02:50 CEST, Andrew Byrd wrote:
> How much flexibility to we really need? Don’t all real-world
> use cases just consist of banning travel between certain stop
> pairs on certain routes or trips?

Do you agree that every trip planner using the data has to expand those
banned pairs to new trips?

--
Stefan

[Andrew Byrd]

No, implementation should be kept separate from the data exchange specification. Software developers would be free to implement any way they want. Specific graph-based algorithms might require that expansion, but that detail should not leak through to the GTFS representation.

Andrew

[Stefan de Konink]

Great to establish that. Now lets work from that, can you give the business
rules a planner has to implement for banning travel between certain stops?

The fundamental different approach for banning is, that banning is "a
normalised model for the event" and the expansion is "delevering the
results".

You wrote:

> It seems like a stopgap measure that models the situation only for trip planning, while not really following the semantics of the GTFS objects being used.

I feel the expansion is actually following the denormalised GTFS semantics.

--
Stefan

[Andrew Byrd]

> On 6 Jun 2017, at 13:22, Stefan de Konink <ste...@konink.de> wrote:
> The fundamental different approach for banning is, that banning is "a normalised model for the event" and the expansion is "delevering the results".

I am suggesting that if this is common enough, we may want to provide what you call a “normalized model for the event” rather than one denormalized expansion of that event that is based on certain journey planning algorithms (and therefore privileges journey planning GTFS consumers).

>> It seems like a stopgap measure that models the situation only for trip planning, while not really following the semantics of the GTFS objects being used.
>
> I feel the expansion is actually following the denormalised GTFS semantics.

I just mean that a trip in GTFS is usually understood to be a single vehicle visiting a series of stops in order. As a GTFS consumer I’d rather not have multiple logical trips bundled together to represent a single physical trip. I would like the more semantically rich information that this is a single vehicle trip, with certain passenger actions forbidden. The implementation (which may involve expansion into multiple logical trips) is then left up to the consumer.

How large are these expansions we’re talking about? For example, for Flixbus, how many logical trips do you generate from how many physical trips?

Andrew

[Stefan de Konink]

On dinsdag 6 juni 2017 07:40:41 CEST, Andrew Byrd wrote:
> How large are these expansions we’re talking about? For
> example, for Flixbus, how many logical trips do you generate
> from how many physical trips?

For every ban origin, appearing in a trip, a trip is forked. Where the
pickup type for the original, and all other forked trips are set to false.

--
Stefan

[Josef Petrák]

Hello Petr,

I guess you specifically target so-called paragrafs limiting licence-wise transportation between designated stops.

At Bileto, we have a proprietary extension for this. A file named stop_time_limitations.txt contains following rows:

trip_id (required)

stop_id (required)

group_id (required)

Two or more stops from given trip are grouped using group_id.

One group defines, between which stop times of the trip you cannot travel.

1 : N group : stop_time relation is necessary because single limitation may include more than two stops.

Groups must be defined on trip, and not on the route, because there are real-world scenarios in which licencing-body limit transportation in such group on each odd or even trip, not on every one.

This also copies model from Czechia-specific timetable format (JDF) used by all bus operators to exchange timetables.

Josef Petrak

[Stefan de Konink]

I would like to bring back life into this discussion. The proposal of Aaron
was to add a parent_trip_id. That should then be used to couple information
to GTFS-RT, shouldn't it?

--
Stefan

[Aaron Antrim]

Hi Stephan,

There is a new proposal to serve this need, GTFS-BoardingRestrictions (http://bit.ly/gtfs-boarding-restrictions).

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/709baa27-df2f-40f0-a4dc-afddd01a3fda%40konink.de.