-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Labels
!BugApply to issues describing a bug and PRs witch fixes it.Apply to issues describing a bug and PRs witch fixes it.+Real-TimeThe issue/PR is related to RealTime updatesThe issue/PR is related to RealTime updatesEnturOn Entur RoadmapOn Entur Roadmap
Description
Expected behavior
When a trip is added to OTP using SIRI ET realtime-data (ExtraJourney=true, extrajourney.xml), the added trip should behave like any other trip.
Observed behavior
A trip query on the added trip works a expected:
{
trip(
from: {place: "NSR:Quay:571"}
to: {place: "NSR:Quay:697"}
dateTime: "2025-11-16T14:14:00+01:00"
) {
tripPatterns {
legs {
datedServiceJourney {
id
}
fromEstimatedCall {
quay {
id
}
aimedDepartureTime
}
}
}
}
}
...and returns the added trip:
...
"legs": [
{
"datedServiceJourney": {
"id": "VYX:DatedVehicleJourney:1234"
},
"fromEstimatedCall": {
"quay": {
"id": "NSR:Quay:571"
},
"aimedDepartureTime": "2025-11-16T14:14:00+01:00"
}
}
]
...
...but querying the departure using a quay-query with data provided in the trip-result does not return the expected trip.
{
quay(id: "NSR:Quay:571") {
estimatedCalls(startTime: "2025-11-16T14:14:00+01:00") {
datedServiceJourney {
id
}
}
}
}
returns
{
"data": {
"quay": {
"estimatedCalls": []
}
}
}
Data sets in use (links to GTFS and OSM PBF files)
- Norwegian stops (example-file uses rail-stops)
- At least one dataset (
VYX-dataset for Norway used in example).
Steps to reproduce the problem
- Verify the trip has been added by looking it up by ID
- Verify that a trip-request returns the added trip
- See that a quay-request on the added trip does not return the added trip
Metadata
Metadata
Assignees
Labels
!BugApply to issues describing a bug and PRs witch fixes it.Apply to issues describing a bug and PRs witch fixes it.+Real-TimeThe issue/PR is related to RealTime updatesThe issue/PR is related to RealTime updatesEnturOn Entur RoadmapOn Entur Roadmap