Fare gates cannot be be bidirectional

49 views
Skip to first unread message

Stefan de Konink

unread,
May 25, 2021, 12:27:10 PMMay 25
to GTFS Changes
Hello,

Someone thought it was a nifty idea to add a "Fare gates (pathway_mode=6)
and exit gates (pathway_mode=7) cannot be bidirectional."

What if technology is so advanced that it is in fact bidirectional because
the direction of walking determines the type? Sure I could make a hack, but
some clarification is appreciated :)

--
Stefan

scott

unread,
May 27, 2021, 8:57:04 AMMay 27
to GTFS Changes
Hi Stefan,

Thanks for flagging this. With clarifications proposed in #274, fare gates (pathway_mode=6) are defined as pathways where proof of payment is required to cross, and exit gates (pathway_mode=7) are defined as pathways that exit a paid area where proof of payment is not required to cross.

By that, it seems logical that fare gates should indeed be corrected to bidirectional (think of tap-in tap-out systems like WMATA, where the action of proving payment is the same in both directions). However, I think exit gates should be kept unidirectional because of their implication of leaving a paid area into an unpaid area without requiring proof of payment to cross. If that was bidirectional, it would imply that you can cross from an unpaid area into a paid area without providing proof of payment (i.e., fare evasion?). Note that a single physical "gate" can be modelled twice both as a fare gate (tap-in required) and an exit gate (no action required to leave).

Did you have a use case or example that would make this otherwise?

Thanks!
Scott

Stefan de Konink

unread,
May 27, 2021, 12:14:08 PMMay 27
to gtfs-c...@googlegroups.com
Within The Netherlands we have fare gates that technically can be entered
from both sides, and depending on configuration allow so. A perfect example
is the wheelchair one, which can always be entered from two directions.
They just open towards the opposite direction of the "tap-in" or "tap-out"
event. Hence you have to go through them to enter or exit. So I have a
generic node towards a generic node.

So this could be modelled as
from_stop_id,to_stop_id,pathway_mode,is_bidirectional,length,wheelchair_accessible
0,1,6,0,2,2
1,0,7,0,2,2


or, when bidirectional would be allowed:

0,1,6,1,2,1


I am inclined to not explicitly state that there is an exit, when such
thing does not physically exists. I agree an exit gate should end up in a
single direction.

...and if you noticed that I just defined another feature,
"wheelchair_accessible" that is correct ;)

--
Stefan

Gavriel Fleischer

unread,
May 27, 2021, 3:49:29 PMMay 27
to gtfs-c...@googlegroups.com
There are systems where you cross a gate on exit without tapping.
And there are systems where you have to tap on exit to stop the payment (if you don't then they assume the longest/most expensive possible trip)
So I don't know if the definition of exit gate should have "where proof of payment is not required to cross".
Or would you model this case as a fare gate? Fare gate + exit gate?

Also there can be a gate where I exit zone 1 and enter zone 2. How would you model this? I think 1 fare gate should be enough.

--
You received this message because you are subscribed to the Google Groups "GTFS 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/4c9069e2-0667-470e-aace-2405e0d42fben%40googlegroups.com.


--
Gavriel Fleischer - Server Developer

scott

unread,
Jun 3, 2021, 12:15:23 PMJun 3
to GTFS Changes
Please see PR #276 that seeks the clarifications discussed here.

scott

unread,
Sep 7, 2021, 1:07:11 PMSep 7
to GTFS Changes
Hi all,

To repeat here:

PR #276 to allow `pathway_mode=6` (fare gates) to be bidirectional is now open for voting. 

Voting ends on 2021-09-14 at 23:59:59 UTC.

Any remaining feedback is welcomed and encouraged, particularly from consumers. Thanks!

Scott
Reply all
Reply to author
Forward
0 new messages