Fare gates cannot be be bidirectional

[Stefan de Konink]

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]

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]

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]

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

+972-52-4232064

[scott]

Please see PR #276 that seeks the clarifications discussed here.

[scott]

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