Possible: support date-range-based OTP Index queries (e.g. getting ‘active’ stops/routes for specific date(s))

[leonardehrenfried]

@fpurcell @miles-grant-ibigroup Could you flesh out the requirements for this a little more?

In particular:

• What does "active" mean? Presumably it means if there are any patterns stopping at a stop on a given day but I would like to confirm.
• Which APIs do you need this for? GraphQL will be relatively easy. Do you also need it for the vector tiles? If the latter, do you specify a date range or do you just want to see stops that serve patterns at the day of the request?

[fpurcell]

What does "active" mean?

At TriMet, the schedule information for the coming week resets on the Sunday service. (Schedule doesn't necessarily change every Sunday, but Sunday is the service day where things may change). So when I think of "active" service, it's what routes and stops are shown on the map today which are active for the entire week thru Saturday's service. So what I'm seeing right now as 'active' may look different on/after the coming Sunday.

NOTE: TriMet's GTFS feed often includes routes and stops (and trips, etc...) that span multiple schedule changes. If we didn't have this 'future' service in our feed when we publish the GTFS, we'd need to republish a new gtfs and reload the trip planner every time the service changes on those Sundays. Having multiple services works fine for the trip planner, since you're always providing a date and time. But where having multiple schedule changes in the feed breaks down with OTP, is the TransitIndex listing the routes and stops, and showing route geometries that may be made up of geometries from multiple service changes. It's this "roll-up" of the schedule that needs to be limited to just what is 'active' right now (e.g., now, and at least until the coming Sunday).

Here are some examples:

1) Line 48 route geometry that has old and new routing being shown on the map:

.

2a) Line 70 has old stops that are no longer in service showing on the map:

2b) and the 70's route geoms are also a problem (like the line 48 mentioned above):

.

3) the route listing can also get dorkd up when the name or direction of a route change, where the list shows both the active line 56 and 94, and past/future names of these routes alongside each other (e.g., routes.txt has both a route_id=94 and route_id=94b entry, with slightly different renames - having these variations show up next to each other is confusing):

.

Which APIs do you need this for? GraphQL will be relatively easy. Do you also need it for the vector tiles? If the latter, do you specify a date range or do you just want to see stops that serve patterns at the day of the request?

The stops are being served by the vector tiles, and the route listing is the api, so yeah both GraphQL and Vector Tiles. I don't know if I like having a date range as a parameter, and would prefer there be a 'current' view that can be queried. On other systems, I run a process each Sunday morning (via cron) that builds a new 'current' view by marking what is 'active' in the next 7 days.

[leonardehrenfried]

The API already returns the service days of each pattern (and therefore route) so either filtering in the frontend or inside OTP will not be very hard.

The vector tiles are a bit more tricky and I will have a think about how to achieve this.

[leonardehrenfried]

And would @miles-grant-ibigroup implement this in otp-ui or would you do it yourself @fpurcell ?

[fpurcell]

At this point, it would be @miles-grant-ibigroup. Future TriMet app, it might folks that work here. But even then, development on a custom app would probably leverage most of the map and route functionality via the OTP-UI library component (e.g., which is more Miles' code).

[leonardehrenfried]

@fpurcell Picking this up again today.

@miles-grant-ibigroup Looking at https://rtp.trimet.org/rtp/#/route/CTRAN:048 the line geometries appear to be drawn based on the routes() -> patterns() GraphQL query chain. So would it therefore be the correct place to add the filter on the patterns() query?

[leonardehrenfried]

@fpurcell Should the actual list of routes also be filtered by date or just the patterns inside of it? Would it be bad to have an element in the list which has zero pattern geometries because all of them are outside the current week?

[leonardehrenfried]

The query would then look like this:

query FilteredRoutePatterns {
  routes {
    shortName
    longName
    patterns(serviceDays: {start: "2024-05-19", end: "2024-05-26"}) {
      name
      patternGeometry {
        points
      }
    }
  }
}

[fpurcell]

@fpurcell Should the actual list of routes also be filtered by date or just the patterns inside of it? Would it be bad to have an element in the list which has zero pattern geometries because all of them are outside the current week?

Hey Leonard, the list of routes presented should filter on date as well, ala only one version of the line 94 is active at a given time:

I guess the front end could look at the 'points' attribute and decide whether to render the route name. But seems better if the api simply filters out such routes.

p.s., in cases like this (where the route or direction name change at some date), TriMet's feed will have a route_id=94 and route_id=94b to differentiate the two versions.

[leonardehrenfried]

@fpurcell All of this filtering could be done in the frontend but we want to make it convenient to do so, that's why we are moving it to the server.

[t2gran]

I am not sure i understod everything here, and there might be som small details to flush out as well. My understanding of active-date and service-dateis:

• First they are two different things.
• The set of service-dates (operating-dates NeTEx) for a trip is all the days a trip is planned/scheduled for. The service-time is used for simplifying trip planning, and can be used by the eco-system of components to identify a particular instance of a trip (DatedTrip(OTP) or DatedServiceJourney(Netex)). The first alighting/boarding may be on the same date, but can also be on the next date if the first time is > 23:59:59.
• An active-date/running-date is all dates a trip is running on. These are the dates witch mean something for the passenger. A given trip on a given serice-date may have one or more active dates.

Examples

• A regular "day" bus will have the same set of active-dates as service-dates.
• A trip that takes 24 hours from start to end and start at 12:00 will have one service-date, but two active-dates. A trip that takes 3 days will have four active-dates.
• If the first alighting/boarding is after 23:59:59 the service-date will be the day before the first active-date.

"active-date" is not a formalized term. "running-date" is also used in OTP. In general it is easier if we choose one, and stick with it. activeDates is used once in the Transmodel API to list all trips(service-journeys) with service-date on the give set of dates. This is confusing, and we should change it. No other usage of active-date or running-date is used in the APIs.

[t2gran]

If we want to list all services(trip/patterns/lines/stoptimes) witch is active/running inside a period of time, I suggest listing all entities with at least one boarding or alighting inside the period.

[t2gran]

Short, service-dates should not be used to list out "running" services in a period. To make a fast and performant API we might have to limit the period resolution (only whole dates) or max lenght (8 days?).

[leonardehrenfried]

@miles-grant-ibigroup @fpurcell I'm going on holiday soon but to give you something to test while I'm gone I have opened https://github.com/opentripplanner/OpenTripPlanner/pull/6003 . This gives you the ability to filter the vector tile stops by the current service week.

If you compile that branch and modify the config like this https://github.com/leonardehrenfried/otp2-setup/blob/main/portland/router-config.json#L42-L49 you can activate the filter.

Please note that it's very likely that the exact config will change as the PR goes through code review. I've chosen this config as it was easy to implement but I expect it not to stay the same.