To all in favor of this proposal.
Tim has extended the proposal with an implementation suggestion, which
looks like option C, the materialisation of the restrictions into one or
more trips per original trip. This is a preprocessing effort that depending
on the number of restrictions and the number of trip has a major
computation requirement happening at every consumer after reading the feed,
making the process more complex than we ever saw in the GTFS realm.
Since we are both a producer (we implemented option C, because in the past
years nobody was capable of doing anything else) of this information and a
consumer of this information as trip planner. I personally quite surprised
that we are the only organisation that see the massive computational impact
of this feature. Without any efficient solutions that could be explained
within the realm of "easy algorithms" for example: how to implement this in
CSA or a graph based algorithm, I don't see this getting implemented. This
is not a simple presentation addition such as a colour on a line.
If we standardise it, a producer will expect that this feature gets
implemented. I don't see this happening under the current conditions. Given
Apple was in favor of this proposal, could we get some expertise from for
example Daniel Delling on this topic?
On Tuesday, April 21, 2020 10:36:23 PM CEST, Tim Millet wrote:
> The vote ended and the proposal did not pass.
> 7 votes for the proposal: Transcollines, Apple, Bileto, CENDIS, Kisio,
> Transit, Trillium.
> 1 vote against the proposal: Bliksem Labs B.V.
> The proposal is not abandoned. I’ll work on addressing the feedback and
> come up with a solution. Thank you for your votes!
> On Wednesday, April 8, 2020 at 8:52:37 PM UTC-4, Tim Millet wrote:
>> Voting period has been opened for the proposal GTFS-TravelRestrictions.
>> It will end on 2020-04-20 at 23:59:59 UTC
>> Please vote here: https://github.com/google/transit/pull/205
>> Thank you!
>> On Thursday, February 20, 2020 at 7:13:43 PM UTC-5, Tim Millet wrote: ...