[GTFS-Flex] Should pickup_type=3 remain forbidden for Flex zones/stop groups?
Closed this issue · 3 comments
Currently, the GTFS-Flex spec reads for stop_times.pickup_type "- pickup_type=3 forbidden for stop_areas.area_id or locations.geojson."
Should this be removed, given the possibility of modeling with Flex a hail-and-ride/on-demand/taxi-like service where vehicles roam a service area and are flagged down for zonal transportation?
Currently both start_pickup_drop_off_window and end_pickup_drop_off_window are required for stop_areas.area_id(grouping of points) or id from locations.geojson, and we don't have any realtime component in Flex extension such as vehicle position. I am curious how the window cooperate with the taxi-like services. For example, is it possible that:
- Riders search a journey within the time window, so trip planners provide a taxi-like service
- Riders go out and wait for the service but cannot get it, because no vehicle nearby (worse case they wait until the end of time window)
Perhaps it's simpler than I thought, but I feel it may need broader discussion if we want to cover the taxi-like services in Flex extension...
If we remain the limitation now (booking services only) and remove it in the future, it will be breaking change only for data consumers but not for data producers. We already have some precedents like this.
I think if we keep with the view that Flex is a discoverability extension, then this could be within scope. A Flex trip result does not communicate "this trip is going to happen" but rather, "this trip is possible based on the service's business rules." Given the nature of a taxi-like service, which typically roams in a smaller, denser area than other demand-responsive services, I think it's a reasonable expectation that one could stand at the side of the road and eventually encounter a vehicle to flag. You could also structure the route to have multiple zones with different pickup/drop-off types, e.g., the wider area where ability to flag is not likely vs the urban area where vehicles roam.
We also do have the message field which can help manage expectations and clarify ride availability, or, if the service allows, include instructions to alternatively call for a ride if allowed.
After a discussion with @tzujenchanmbd, I am closing this issue because it has been included in #433.