Add plan query that follows the relay connection specification

[optionsome]

Summary

Adds a new plan query that follows the relay connection specification and some new features/enhancements compared to the old plan query in the LegacyGraphQLAPI.

Example query:

{
  planConnection(
     dateTime: {
      earliestDeparture: "2023-06-13T14:30+03:00"
    }
    searchWindow: "PT2H30M"
    numberOfItineraries: 5
    origin: {
      location: {
        coordinate: {
          latitude: 10.0
          longitude: 20.0
        }
      }
      label: "Home"
    }
    destination: {
      location: {
        coordinate: {
          latitude: 15.0
          longitude: 25.0
        }
      }
      label: "Work"
    }
    modes: {
      directOnly: false
      transitOnly: false
      direct: [CAR_PARKING]
      transit: {
        access: [CAR_PARKING]
        transfer: [WALK]
        egress: [BICYCLE_RENTAL, WALK]
        transit: [
          {
            mode: TRAM
            cost: {
              reluctance: 1.3
            }
          },
          {
            mode: BUS
          }
        ]
      }
    }
    preferences: {
      accessibility: {
        wheelchair: {
          enabled: true
        }
      }
      street: {
        car: {
          reluctance: 6.5
          rental: {
            allowedNetworks: ["foo", "bar"]
            bannedNetworks: ["foobar"]
          }
          parking: {
            unpreferredCost: 200
            preferred: [{
              select: [{
                tags: ["best-park"]
              }]
            }]
            filters: [{
              not: [{
                tags: ["worst-park"]
              }]
            }]
          }
        }
        bicycle: {
          reluctance: 3.0
          speed: 7.4
          optimization: {
            type: SAFEST_STREETS
          }
          boardCost: 200
          walk: {
            speed: 1.3
            cost: {
              mountDismountCost: 100
              reluctance: 3.5
            }
            mountDismountTime: "PT5S"
          }
          rental: {
            destinationBicyclePolicy: {
              allowKeeping: true
              keepingCost: 300
            }
            allowedNetworks: ["foo", "bar"]
            bannedNetworks: ["foobar"]
          }
          parking: {
            unpreferredCost: 200
            preferred: [{
              select: [{
                tags: ["best-park"]
              }]
            }]
            filters: [{
              not: [{
                tags: ["worst-park"]
              }]
            }]
          }
        }
        walk: {
          speed: 2.4
          reluctance: 1.5
          walkSafetyFactor: 0.5
          boardCost: 200
        }
      }
      transit: {
        board: {
          waitReluctance: 3.2
          slack: "PT1M30S"
        }
        alight: {
          slack: "PT0S"
        }
        transfer: {
          cost: 200
          slack: "PT2M"
          maximumAdditionalTransfers: 2
          maximumTransfers: 5
        }
        timetable: {
          excludeRealTimeUpdates: false
          includePlannedCancellations: false
          includeRealTimeCancellations: true
        }
      }
    }
    locale: "en"
    after: ""
    first: 3
  ) {
    searchDateTime
    routingErrors {
      code
      description
      inputField
    }
    pageInfo {
      hasNextPage
      hasPreviousPage
      startCursor
      endCursor
    }
    edges {
      cursor
      node {
        legs {
          startTime
        }
      }
    }
  }
}

A simple "minimal" query:

{
  planConnection(
    dateTime: {
      earliestDeparture: "2023-06-13T14:30+03:00"
    }
    origin: {
      location: {
        coordinate: {
          latitude: 10.0
          longitude: 20.0
        }
      }
    }
    destination: {
      location: {
        coordinate: {
          latitude: 15.0
          longitude: 25.0
        }
      }
    }
    modes: {
      direct: [CAR_PARKING]
      transit: {
        access: [CAR_PARKING]
        transfer: [WALK]
        egress: [BICYCLE_RENTAL, WALK]
        transit: [
          {
            mode: TRAM
          },
          {
            mode: BUS
          }
        ]
      }
    }
  ) {
    edges {
      node {
        legs {
          startTime
        }
      }
    }
  }
}

Issue

closes #4803

Unit tests

Added

Documentation

Not needed yet

Changelog

Will add for sandbox

[optionsome]

This is still WIP but wanted to open the pr so it's easier for people to make comments about the schema. I will start implementing some things that are less controversial first within this pr.

[t2gran]

Some comments

[leonardehrenfried]

Are you putting that in just for good measure? I don't think we have that implemented at the moment, isn't it?

[optionsome]

I added this for two reasons: so it's more clear what settings should be defined when you want to adjust scooter travel and so we can in the future support defining different parameters for cycling/scooter. However, on the downside, what should happen now if both cycling and scooter settings are included.

[leonardehrenfried]

We should probably have a think how to integrate Bartosz's filter API here.

[optionsome]

True. I'm going to check at some point if I'm missing some other latest features from this API in this new draft or any cool features from the transmodel API.

[leonardehrenfried]

what is the current thinking about this?

[optionsome]

I haven't really studied the filter API closely but unless it has major issues, we can port it to this API as is.

[leonardehrenfried]

I've made lots of comments but I think this is good step in the right direction. Thanks for working on this.

[t2gran]

This looks good, my last comments are nit-picking and I am happy to approve without fixing them - let me know what you prefere.

[t2gran]

We should probably have split the transit search(T) and street search(S) in two queries.

• T is time dependent and has a search-window, S is most of the time time-shiftable
• The S result is always first
• The S is excluded when paging
• The only reason to have it together is to use the S to prune the T - but we could probably find other ways to do that.

[optionsome]

Do you mean two graphql queries or queries within OTP? Rerunning the street routing is indeed unnecessary when paging. We have thought about some caching solutions for this previously.

Is this comment related to @leonardehrenfried 's question about where the penalty should belong to?

[leonardehrenfried]

The one remaining question I had was where accessEgressPenalty should live. After a bit of deliberation, we decided in today's meeting that we will leave the structure as it is and find a place should we need to add the penalties.

[optionsome]

Thanks for spending time on reviewing this. We need to decide when we deprecate the old query and remove the deprecation from this one but I think we can wait some weeks at least.

[arnoclr]

Hello, I can't find any mention of this, but where are the old options of plan to ban certain stops or routes in this new planConnection ? https://docs.opentripplanner.org/api/dev-2.x/graphql-gtfs/types/InputBanned

[optionsome]

Hello, I can't find any mention of this, but where are the old options of plan to ban certain stops or routes in this new planConnection ? https://docs.opentripplanner.org/api/dev-2.x/graphql-gtfs/types/InputBanned

If I remember correctly, it isn't implemented yet because we wanted to limit the scope of this pr and we didn't necessarily want to implement it in the same way as it was implemented before. Instead, we want to have some sort of a bit more sophisticated filter structure. You are the second person to ask for this feature in the last couple of weeks. I'll bring this topic up in a developer meeting within a week or two. You can also show up in a meeting if you want and we can discuss this.