BostonInRoutingFareCalculator and BogotaInRoutingFareCalculator don't apply locale-specific dominance logic #595
Comments
mattwigway
added a commit
to mattwigway/r5
that referenced
this issue
Apr 13, 2020
…yal#593) and use boston-specific logic in dominance (addresses conveyal#595)
mattwigway
added a commit
to mattwigway/r5
that referenced
this issue
Apr 13, 2020
…yal#593) and use boston-specific logic in dominance (addresses conveyal#595)
mattwigway
added a commit
to mattwigway/r5
that referenced
this issue
May 11, 2020
…n called in superclass, adresses conveyal#595.
mattwigway
added a commit
to mattwigway/r5
that referenced
this issue
Nov 13, 2020
…yal#593) and use boston-specific logic in dominance (addresses conveyal#595)
mattwigway
added a commit
to mattwigway/r5
that referenced
this issue
Nov 13, 2020
…n called in superclass, adresses conveyal#595.
mattwigway
added a commit
to mattwigway/r5
that referenced
this issue
Nov 24, 2020
…yal#593) and use boston-specific logic in dominance (addresses conveyal#595)
mattwigway
added a commit
to mattwigway/r5
that referenced
this issue
Nov 24, 2020
…n called in superclass, adresses conveyal#595.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Both the Boston and Bogotá InRoutingFareCalculators call
transferAllowance.tightenExpiration, which returns a regular transfer allowance, not a Boston/Bogotá transfer allowance, meaning that any Boston or Bogotá-specific logic implemented inatLeastAsGoodForAllFutureRedemptionsis not actually executed.The text was updated successfully, but these errors were encountered: