Need stopPosition in Pattern in GraphQL

[miklcct]

Is your feature request related to a problem? Please describe. I need a stopPosition field in the Pattern object GTFS GraphQL API such that the stopPosition in Stoptime can be matched to the pattern.

Goal / high level use-case I need to identify where exactly the Stoptime is in the Pattern for the results returned in the Stop.stoptimesForPattern field. This is currently impossible to do accurately because the pattern object does not include the stopPosition, so stop times on trips with repeated stops can't be matched to the pattern without ambiguity.

Describe the solution you'd like I would like a stopPosition field to be present in the Pattern object

Describe alternatives you've considered I have tried to get the trip in the returned stopTime, and all the stopTimes in the trip to do the matching. However, if the trip has been modified by realtime data, the trip.stoptimes field does not represent the realtime changes, and the use of trip.stoptimesForDate requires the service day to be known in advance, which means it is impossible to get the whole stop time list of the trip on the specific date of the stoptime.

Additional context

[optionsome]

Do you have any suggestion for what the schema should look like (i.e. where you have this information per stop)? I took a quick look at this and ideally it should be paired with the stop information but unfortunately the stops are listed for the patters in a list without a wrapper.

[miklcct]

I am not sure if it can be added in a sane way without a breaking change.

29 Aug 2024 15:32:25 Joel Lappalainen @.***>:

Do you have any suggestion for what the schema should look like (i.e. where you have this information per stop)? I took a quick look at this and ideally it should be paired with the stop information but unfortunately the stops are listed for the patters in a list without a wrapper.

— Reply to this email directly, view it on GitHub[https://github.com/opentripplanner/OpenTripPlanner/issues/6026#issuecomment-2317888385], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AAVSIAFF5SRJHFXPFOKQ57TZT4WHTAVCNFSM6AAAAABNHGLR72VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJXHA4DQMZYGU]. You are receiving this because you authored the thread. [Tracking image][https://github.com/notifications/beacon/AAVSIAETU6DPP3GPHN4A2MLZT4WHTA5CNFSM6AAAAABNHGLR72WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUKFAVYC.gif]

[miklcct]

I am currently working around the issue using a query similar to the below:

fragment StoptimeSummary on Stoptime {
  stop {
    gtfsId
    name
  }
  stopPosition
  scheduledArrival
  realtimeArrival
  scheduledDeparture
  realtimeDeparture
  stopPosition
  realtime
  realtimeState
  pickupType
  dropoffType
  serviceDay
  headsign
}

query Query($yesterday: string!, $today: string!, $tomorrow: string!) {
  stop(id: "exampleId") {
    stoptimesForPatterns(omitNonPickups: true, timeRange: 10800, numberOfDepartures: 5) {
      stoptimes {
        serviceDay
        trip {
          yesterdayStoptimes: stoptimesForDate(serviceDate: $yesterday) {
            ...StoptimeSummary
          }
          todayStoptimes: stoptimesForDate(serviceDate: $today) {
            ...StoptimeSummary
          }
          tomorrowStoptimes: stoptimesForDate(serviceDate: $tomorrow) {
            ...StoptimeSummary
          }
        }
        ...StoptimeSummary
      }
    }
  }
}

assuming that the query is for now, and pass the dates from the client side in order to match the serviceDay in the stopTime itself and the stopTime list in the trip such that the stopPosition can be matched.

[miklcct]

I think that the pick up / drop off type should also be exposed in the API as well. Internally, the same stops but with different pick up / drop off values are different patterns as required for routing purpose, but it is not possible to display this in the UI (to tell the user if drop off is not possible) when trips are grouped by patterns because of the lack of the field in the API.