#AutoTranslate
Brief Description
TripRefineRequest can be used to update a trip that was previously found with a TripRequest. The entire trip or just individual legs of the trip can be updated. TripRefineRequest is used in particular to request changing arrival and departure times.
Technical Description
API Explorer
You can customize requests as you wish by trying 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 specified in detail below. Further details on the structure of a TripRefineRequest can be found in the description of the TripRefineRequests at the 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 already correctly assign a trip even with slightly less information. Here’s an example of TripRefineRequest, which is not XSD-compliant but still 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 have been omitted in the second example: All ‘RefineParams,’ the ‘Duration,’ the ‘StartTime,’ the ‘EndTime,’ the ‘Transfers,’ all ‘StopPointName,’ the ‘PublishedServiceName’ and the ‘Mode’ parameter can also be empty. None of these parameters are used to find the correct trip to retrieve the current data.
Description of the parameters
The elements of OJPTripRefineRequestStructure:
| Element | Cardinality | Description | Example |
|---|---|---|---|
siri:RequestTimestamp |
1:1 | Timestamp of the request. Preferably in UTC. |
<siri:RequestTimestamp>2025-02-18T15:41:28.717Z</siri:RequestTimestamp> |
siri:MessageIdentifier |
0:1 | The identifier of the incident. Increasingly 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 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 in question can 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 = only according to the timetable. | <UseRealtimeData>explanatory</UseRealtimeData> |
RefineParams/ IncludePlacesContext |
0:1 | Provides the location context. The default is true, false is 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 | Whether intermediate stops between boarding and alighting stops should be included 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 consider 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 have a restrictive effect on the mode of transport or the route of travel 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 in the TripRequest are extracted, the TripRefineDelivery is largely identical to the TripDelivery.
