#AutoTranslate
Brief Description
TripRefineRequest can be used to update a trip that was previously found with a TripRequest. The whole trip or individual legs of the trip can be updated. TripRefineRequest is used in particular for querying changing arrival and departure times.
Technical Description
API Explorer
You can customize requests according to your own wishes and try out the templates in the Open API – direct link to API Explorer.
TripRefineRequest
The key information for sending a TripRefineRequest is the trip ID, the TimetabledTime and siri:StopPointRef and a few other fields which are described in detail below. Further details on the structure of a TripRefineRequest can be found in the description of the TripRefineRequests at VDV . Here is an example of an XSD-compliant TripRefineRequest:
<?xml version="1.0" encoding="UTF-8"?>
<OJP xmlns="http://www.vdv.de/ojp" xmlns:siri="http://www.siri.org.uk/siri" version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.vdv.de/ojp OJP_changes_for_v1.1/OJP.xsd">
<OJPRequest>
<siri:ServiceRequest>
<siri:RequestTimestamp>2025-01-16T15:32:24.500Z</siri:RequestTimestamp>
<siri:RequestorRef>SKIPlusRegTests</siri:RequestorRef>
<OJPTripRefineRequest xmlns="http://www.vdv.de/ojp" xmlns:siri="http://www.siri.org.uk/siri" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.vdv.de/ojp OJP_changes_for_v1.1/OJP.xsd">
<siri:RequestTimestamp>2025-01-16T15:32:24.500Z</siri:RequestTimestamp>
<siri:MessageIdentifier>TRR-1</siri:MessageIdentifier>
<RefineParams>
<RefineLegRef/>
<IncludeIntermediateStops>true</IncludeIntermediateStops>
</RefineParams>
<TripResult>
<Id>ID-6F1F1CE3-AD63-44EA-82D7-72B1B5A1A9FA</Id>
<Trip>
<Id>ID-6F1F1CE3-AD63-44EA-82D7-72B1B5A1A9FA</Id>
<Duration>PT55M6S</Duration>
<StartTime>2025-04-15T05:26:30Z</StartTime>
<EndTime>2025-04-15T06:21:36Z</EndTime>
<Transfers>0</Transfers>
<Leg>
<Id>1</Id>
<TimedLeg>
<LegBoard>
<siri:StopPointRef>ch:1:sloid:6208:2:3</siri:StopPointRef>
<StopPointName>
<Text xml:lang="de">Uzwil</Text>
</StopPointName>
<ServiceDeparture>
<TimetabledTime>2025-04-15T05:25:00Z</TimetabledTime>
</ServiceDeparture>
</LegBoard>
<LegAlight>
<siri:StopPointRef>ch:1:sloid:3000:500:32</siri:StopPointRef>
<StopPointName>
<Text xml:lang="de">Zürich</Text>
</StopPointName>
<ServiceArrival>
<TimetabledTime>2025-04-15T06:21:00Z</TimetabledTime>
</ServiceArrival>
</LegAlight>
<Service>
<OperatingDayRef>2025-04-15</OperatingDayRef>
<JourneyRef>ch:1:sjyid:100001:710-001</JourneyRef>
<siri:LineRef>ojp:91001:D</siri:LineRef>
<siri:DirectionRef>H</siri:DirectionRef>
<Mode>
<PtMode>rail</PtMode>
</Mode>
<ProductCategory>
<ProductCategoryRef>23</ProductCategoryRef>
</ProductCategory>
<PublishedServiceName>
<Text>IC1</Text>
</PublishedServiceName>
</Service>
</TimedLeg>
</Leg>
</Trip>
</TripResult>
</OJPTripRefineRequest>
</siri:ServiceRequest>
</OJPRequest>
</OJP>
The system can assign a trip correctly even with a little less information. Here’s an example of TripRefineRequest, which is not XSD-compliant but also works:
<?xml version="1.0" encoding="UTF-8"?>
<OJP xmlns="http://www.vdv.de/ojp" xmlns:siri="http://www.siri.org.uk/siri" version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.vdv.de/ojp OJP_changes_for_v1.1/OJP.xsd">
<OJPRequest>
<siri:ServiceRequest>
<siri:RequestTimestamp>2025-01-16T15:32:24.500Z</siri:RequestTimestamp>
<siri:RequestorRef>SKIPlusRegTests</siri:RequestorRef>
<OJPTripRefineRequest xmlns="http://www.vdv.de/ojp" xmlns:siri="http://www.siri.org.uk/siri" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.vdv.de/ojp OJP_changes_for_v1.1/OJP.xsd">
<siri:RequestTimestamp>2025-01-16T15:32:24.500Z</siri:RequestTimestamp>
<siri:MessageIdentifier>TRR-1</siri:MessageIdentifier>
<TripResult>
<Trip>
<Id>ID-6F1F1CE3-AD63-44EA-82D7-72B1B5A1A9FA</Id>
<Leg>
<Id>1</Id>
<TimedLeg>
<LegBoard>
<siri:StopPointRef>ch:1:sloid:6208:2:3</siri:StopPointRef>
<ServiceDeparture>
<TimetabledTime>2025-04-15T05:25:00Z</TimetabledTime>
</ServiceDeparture>
</LegBoard>
<LegAlight>
<siri:StopPointRef>ch:1:sloid:3000:500:32</siri:StopPointRef>
<ServiceArrival>
<TimetabledTime>2025-04-15T06:21:00Z</TimetabledTime>
</ServiceArrival>
</LegAlight>
<Service>
<OperatingDayRef>2025-04-15</OperatingDayRef>
<JourneyRef>ch:1:sjyid:100001:710-001</JourneyRef>
<siri:LineRef>ojp:91001:D</siri:LineRef>
<siri:DirectionRef>H</siri:DirectionRef>
<Mode/>
<ProductCategory>
<ProductCategoryRef>23</ProductCategoryRef>
</ProductCategory>
</Service>
</TimedLeg>
</Leg>
</Trip>
</TripResult>
</OJPTripRefineRequest>
</siri:ServiceRequest>
</OJPRequest>
</OJP>
The following parameters were omitted in the second example: All ‘RefineParams,’ ‘Duration,’ ‘StartTime,’ ‘EndTime,’ ‘Transfers,’ all ‘StopPointName,’ ‘PublishedServiceName’ and the parameter ‘Mode’ can also be empty. None of these parameters are used to find the correct trip to request the current data.
Description of the parameters
The elements of the OJPTripRefineRequestStructure:
| Item | Cardinality | Description | Example |
|---|---|---|---|
siri:RequestTimestamp |
1:1 | The timestamp of the request. Preferably in UTC time. |
<siri:RequestTimestamp>2025-02-18T15:41:28.717Z</siri:RequestTimestamp> |
siri:MessageIdentifier |
0:1 | The identifier of the message. Increasingly increasing number preferred. |
<siri:MessageIdentifier>SER-1a</siri:MessageIdentifier> |
RefineParams |
0:1 | Options to control the update. |
|
TripResult |
1:1 | The trip to be updated (refined). | Example, see above! |
TripResponseContext |
0:1 | Context that contains objects that are referenced within the response. | |
RefineParams/ RefineLegRef |
0:* | Refers to the legs to be refined by the server. If none are specified, all legs are refined (if the system is able to refine them). | |
RefineParams/ UseRealtimeData |
0:1 | Determines how real-time is taken into account, full = everything; explanatory = also delayed and cancelled connections (most detailed variant); none = according to the timetable only. | <UseRealtimeData>explanatory</UseRealtimeData> |
RefineParams/ IncludePlacesContext |
0:1 | Returns the location context. Default is true, false makes the answer more streamlined. | <IncludePlacesContext>false</InlcudePlacesContext> |
RefineParams/ IncludeLegProjection |
0:1 | Whether the result should include the geographical projection (coordinates) of the individual route segments. | <IncludeLegProjection>true</IncludeLegProjection> |
RefineParams/ IncludeIntermediateStops |
0:1 | Include intermediate stops between the boarding and alighting stops in the result. | <IncludeIntermediateStops>true</IncludeIntermediateStops> |
RefineParams/ IncludeAllRestrictedLines |
0:1 | There could be lines that have special restrictions and are not generally accessible to the public. For example, school buses or company shuttles. If this flag is set, the router will also take into account restricted lines. | <IncludeAllRestrictedLines>true</IncludeAllRestrictedLines> |
RefineParams/ IncludeTurnDescription |
0:1 | A detailed route description with PathGuidance is provided for each walk leg and, if available, also for transfer legs. | <IncludeTurnDescription>true</IncludeTurnDescription> |
Other parameters that restrict the means of transport or the route were not implemented. Only the requested journey is updated. Therefore, other parameters not mentioned here have no effect.
TripRefineResponse
The details of the individual parameters can be found in the descriptions of the TripRequest are withdrawn, which Trip refine delivery is largely identical to the Trip delivery.
