Frequency-based trips don't appear in stoptimesForPatterns query

[ethanpooley]

Expected behavior

Trips defined by frequencies.txt entries will appear in both routing results and GTFS query results such as stoptimesForPatterns

Observed behavior

Frequency-based trips appear in routing results but not in stoptimesForPatterns

Version of OTP used (exact commit hash or JAR name)

otp-2.4.0-shaded.jar

Data sets in use (links to GTFS and OSM PBF files)

GTFS: http://www.ridepatco.org/developers/PortAuthorityTransitCorporation.zip
PBF: https://download.geofabrik.de/north-america/us-northeast-latest.osm.pbf (though only the Philadelphia metro area is needed)

Command line used to start OTP

java -XX:InitialRAMPercentage=90 -XX:MaxRAMPercentage=90 -XX:+AlwaysPreTouch -jar otp-2.4.0-shaded.jar --load /var/otp

Router config and graph build config JSON

otp-config.json

{
  "otpFeatures": {
    "APIBikeRental": false,
    "APIServerInfo": false,
    "APIUpdaterStatus": true,
    "AsyncGraphQLFetchers": true,
    "Co2Emissions": true,
    "FaresV2": false,
    "FlexRouting": true,
    "FloatingBike": true,
    "LegacyRestApi": true,
    "OptimizeTransfers": true,
    "ParallelRouting": true,
    "SandboxAPIParkAndRideApi": true
  }
}

build-config.json

{
  "embedRouterConfig": true,
  "fares": "off",
  "osmCacheDataInMem": false,
  "osmDefaults": {
    "timeZone": "America/New_York"
  },
  "platformEntriesLinking": true,
  "staticBikeParkAndRide": true,
  "staticParkAndRide": true,
  "transitModelTimeZone": "America/New_York",
  "transitServiceStart": "-P3Y",
  "transitServiceEnd": "P1Y"
}

router-config.json

{
  "routingDefaults": {
    "accessEgress": {
      "maxDuration": "PT20M"
    },
    "streetRoutingTimeout": "4s",
    "walk": {
      "BoardCost": 600
    },
    "walkBoardCost": 600
  },
  "transit": {
    "searchThreadPoolSize": 6
  },
  "updaters": []
}

Steps to reproduce the problem

Run this query in the GraphiQL UI:

query Stoptime {
  stop(id: "patco:4") {
    gtfsId
    name
    stoptimesForPatterns(
      startTime: 1738259951
      timeRange: 5000
      numberOfDepartures: 25
      omitNonPickups: true
    ) {
      pattern {
        code
        id
        directionId
        headsign
        name
      }
      stoptimes {
        stopPosition
        scheduledArrival
        realtimeArrival
        arrivalDelay
        scheduledDeparture
        realtimeDeparture
        departureDelay
        timepoint
        realtime
        realtimeState
        pickupType
        dropoffType
        serviceDay
        headsign
        trip {
          gtfsId
          directionId
          route {
            gtfsId
            longName
            shortName
            mode
            type
            color
            textColor
            agency {
              gtfsId
            }
          }
        }
      }
    }
  }
}

You'll get one item for 2:18 PM local time. There should also be a frequency-based item for 1:06 PM local time (and 1:21, 1:36, etc.). GTFS service ID is 87. Trip ID is 10202. Relevant portion of the frequencies.txt file looks like this:

trip_id,start_time,end_time,headway_secs,exact_times
10202,09:00:00,14:00:01,900,1

[ethanpooley]

For comparison, OneBusAway returns the very next instance of the frequency-based trip, but not additional instances. When it returns a frequency-based trip it includes a value like this:

"frequency": {
    "startTime": 1738230248,
    "endTime": 1738274834,
    "headway": 900
}

Presumably so that the consumer can a) identify them properly, and b) extrapolate future instances easily if they choose.

[ethanpooley]

In a gitter.im thread, @miklcct responded:

Yes that's a bug and needs to be reported.
I haven't had time to work on it yet.

[Uranbold]

Same issue +1

[Uranbold]

For comparison, OneBusAway returns the very next instance of the frequency-based trip, but not additional instances. When it returns a frequency-based trip it includes a value like this:

"frequency": {
    "startTime": 1738230248,
    "endTime": 1738274834,
    "headway": 900
}

Presumably so that the consumer can a) identify them properly, and b) extrapolate future instances easily if they choose.

Result only shows 1

[miklcct]

For comparison, OneBusAway returns the very next instance of the frequency-based trip, but not additional instances. When it returns a frequency-based trip it includes a value like this:

"frequency": {
    "startTime": 1738230248,
    "endTime": 1738274834,
    "headway": 900
}

Presumably so that the consumer can a) identify them properly, and b) extrapolate future instances easily if they choose.

Result only shows 1

Is it an exact times frequency trip? If so it should extrapolate, if not it shouldn't.

[miklcct]

My expected behavior:

• For exact frequency trips: extrapolate the times in journey results, stop times and also nextLegs
• For non-exact frequency trips: don't extrapolate, add a field to specify min frequency, max frequency and expected frequency (GTFS only supports the last, but Transmodel supports all 3).