--
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.
I think the way is use something like https://developers.google.com/transit/gtfs/reference/gtfs-extensions#TripToTripTransfers Trip - to Trip transfer
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes+unsubscribe@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes...@googlegroups.com.
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
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.
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.
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.
GTFS
* 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.
--
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.
--
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.