xsd.2.0.OJP.OJP_Trips.xsd Maven / Gradle / Ivy
Go to download
Show more of this group Show more artifacts with this name
Show all versions of ojp-java-model Show documentation
Show all versions of ojp-java-model Show documentation
Generates Java model from OJP xsds using jaxb.
The newest version!
OJP/OJP_Trips.xsd - Request and response definitions for trip requests and distributed journey planning
========================================== TripRequest definitions ==========================================
Trip request structure.
Specifies the origin situation from where the user wants to start.
Specifies the destination situation where the user is heading to.
Ordered series of points where the journey must pass through. If more than one via point is given all of them must be obeyed - in the correct order. The server is allowed to replace a via stop by equivalent stops.
Note: Systems may support only one.
With this parameter a distributing system is asked to build a trip using a given System to pass through. This helps in selecting Exchange Points for this trip. ViaSystem is also used in sequence.
Note: Systems may support only one.
Not-via restrictions for a TRIP, i.e. SCHEDULED STOP POINTs or STOP PLACEs that the TRIP is not allowed to pass through. If more than one not via point is given all of them must be obeyed.
no-change-at restrictions for a TRIP, i.e. SCHEDULED STOP POINTs or STOP PLACEs at which no TRANSFER is allowed within a TRIP.
Options to control the search behaviour and response contents.
Trip request parameter structure.
Parameters for fare calculation. Only used if IncludeFare is set (TripContentFilterGroup).
Data to be included/excluded from search, e.g., modes, operators (Transmodel: TRIP REQUEST FILTER).
MODEs and MODEs OF OPERATION to be considered in trip calculation. If only MODE is used, then it is for all MODE OF OPERATION. If combinations of MODE and MODE OF OPERATION are used (multiples), then all combinations are to be considered.
Lines/Directions to include/exclude.
Transport operators to include/exclude.
Filter for VEHICLE and TRAIN NUMBERs.
Filter for trips using only specific tariff zones.
Policies that control the trip search behaviour.
The MotorisedMainTravelMode defines whether the trip planner works in PT mode (or pure IT mode) or includes carTransportRail and the like. If set to true (e.g., because one travels by car, truck or motorcycle), then carTransportRail, ferry are used together with roads.
For each MODE or MODE OF OPERATION combination in this list a separate monomodal trip shall be found - in addition to inter-modal solutions.
Whether alternative options should be presented as well. Mainly important for dominated journeys or in the case of ContinuousLegs the second-best route. Should be optimised for user expectations (see. e.g https://theses.hal.science/tel-01848737). However, what the alternative options are may vary widely depending on the optimisation methods and filters.
Parameters the user can set to restrict the mobility options - particularly for interchanging.
The user wants to carry a bike on public transport (could be extended in future to transporting big luggage / animals / etc.).
Deviation from average walking speed in percent. 100% percent is average speed. Less than 100 % slower, Greater than 150% faster.
Additional time added to all transfers (also to transfers between individual to public transport, not modelled in Transmodel).
Users hiking profile. The main element to control general walking behaviour is WalkSpeed (together with accessibility constraints). Note: explanations in German can be found here: https://akademie.alpinewelten.com/bergwandern/klassifizierung-von-wanderwegen
Regular hiking/walking in valleys and plains and easy mountain trails e.g., yellow hiking signs in Switzerland or blue in Germany.
Medium difficulty mountain trails. E.g. white-red-white hiking signs in Switzerland or red in Germany.
Difficult mountain trails. E.g. white-blue-white hiking signs in Switzerland or black in Germany.
Cycling profile of the user (especially for sportive activities).
Fastest cycle route
Greenest cycle route
Family friendly and leisurely route
Parameters that control the level of detail of the trip results.
Whether the result should include intermediate stops (between the passenger's board and alight stops).
Whether the result should include fare information.
Whether the result should include operating day information - as encoded bit string and in natural language.
If true, then the response will contain only summaries of the found trips. Default is false.
The types of algorithms that can be used for planning a journey (fastest, least walking, etc.). Only one method can be used. Each one really is a whole set of a policy, which is defined below. E.g., "fastest" also includes "least transfers" as a second criteria, some modes are excluded usually by default. Implementations might differ (slightly). Also, some strategies might not be implemented. The most important strategies are marked.
Shortest duration somewhere in the future. This may present a shorter trip than the next earliest arrival (with latest departure). Expected strategy.
Minimise the number of interchanges as the first criterion. Expected strategy.
Shortest walking distance in meters, summed over all legs.
Cheapest fare, considering the applicable reductions. Might not be based on actual cost, but an estimation. Expected strategy.
Least distance in metres. Mostly used for ALTERNATIVE MODE OF OPERATION and for ItModesToCover.
Earliest possible arrival time respecting the time constraints (forward search).
Latest departure time for a given arrival time (backward search).
Combines earliestArrival and latestDeparture, allowing to compress the departure time (forward-backward-forward search).
The user wants to minimize non-level entrances on the trip. this is useful for PRM who still can use some non-level entrances.
The user wants to minimize stairs and steps on the trip. This is useful for PRM who still can use some steps/stairs.
The user wants to avoid transfers without tactile guidance, as well as platforms and vehicles without auditory signals.
The user wants to avoid transfers without guidance for people with auditory impairment, as well as platforms and vehicles without visual signs.
If set, favour "green" modes/lines such as bike sharing and (electric) trains, avoid or restrict modes/lines known for higher CO2 emissions such as (conventional) taxi, ride-hailing or coach.
High level of safety (referring to crime, hazards or prone to accidents). If used, certain modes, lines or zones/districts known for lower safety, i.e. higher risk of accidents and crime, may be avoided, others may be preferred. This may depend on the actual, local or time of day situation. E.g. bike or scooter may be considered unsafe in some cities/districts while safe in others.
Low probability of delays, cancellations etc. If used, modes known for their (un)reliability may be avoided/preferred, and extra time added for transfers. This may depend on the actual, local or time of day situation, based on punctuality statics, traffic jam statistics or rush hours. E.g. taxis in a given city might be known to be unreliable during at 8-10 and 16-19 hours, otherwise reliable.
Scenic (or touristic) travel. Different by modes or by the surrounding.
E.g. first class or quiet compartments preferred. Journeys that are with low occupancy.
Not-via restrictions for a TRIP, i.e. SCHEDULED STOP POINTs or STOP PLACEs that the TRIP is not allowed to pass through
Reference to a not-via stop point.
Reference to a not-via stop place.
No-change-at restrictions for a TRIP, i.e. SCHEDULED STOP POINTs or STOP PLACEs at which no TRANSFER is allowed within a TRIP.
Reference to a no-change stop point.
Reference to a no-change stop place.
Whether to include or exclude given tariff zones in the list from the search. Default is to include.
List of fare zones to include or exclude.
========================================== TripResponse definitions ==========================================
Trip response structure.
Context to hold trip response objects that occur frequently.
The trip results found by the server.
Type for identifier of a NeTEx Object.
Structure for a single trip result and associated problems.
Id of this trip result for referencing purposes. Unique within trip response.
Problems related to this Trip result.
Detailed information on trip.
Summary on trip. Only if requestor set TripSummaryOnly in request.
Fare and fare product information for this trip as a whole or parts of it.
When the result is an alternative option from IncludeAlternativeOptions, then the flag should be set to true. If it is an alternative option this means that the server decided to add this result for its own reasons: e.g., to push a certain trip leg, because it believes that it might better suit at least some possible customers. Such options are not an optimal fit to the criteria that were in the request. The client may therefore disregard such results depending on the use case.
Structure for trip overview information (only implementation related and therefore not modelled in Transmodel).
Id of this trip for referencing purposes. Unique within trip response.
Describes the origin situation of this trip.
Describes the arrival situation of this trip.
Overall duration of the trip (TRIP attribute, not detailed in Transmodel, available from constituting LEGs).
Departure time at origin (TRIP attribute, not detailed in Transmodel, available from constituting LEGs).
Arrival time at destination (TRIP attribute, not detailed in Transmodel, available from constituting LEGs).
Number of public transport legs.
Trip distance (TRIP attribute, not detailed in Transmodel, available from constituting LEGs).
Information about the feasibility of the TRIP, in particular with respect to the access features used.
A list of references to SITUATIONs.
Type for identifier of a TRIP Object.
[an extended form of PT TRIP in TM and NeTEx as it also includes the initial and final access legs to and from public transport] whole journey from passenger origin to passenger destination in one or more LEGs
Id of this trip for referencing purposes. Unique within trip response.
Overall duration of the trip (TRIP attribute, not detailed in Transmodel, available from constituting LEGs).
Departure time at origin (TRIP attribute, not detailed in Transmodel, available from constituting LEGs).
Arrival time at destination (TRIP attribute, not detailed in Transmodel, available from constituting LEGs).
Number of interchanges.
Trip distance (TRIP attribute, not detailed in Transmodel, available from constituting LEGs).
Legs of the trip (Transmodel: LEG or MONITORED LEG). Note: There is always a TransferLeg between two TimedLegs. There can be a TransferLeg between two ContinuousLegs (e.g., because some special time-consuming action is necessary like a car hire). There can be a TransferLeg between a ContinuousLeg and a TimedLeg for the same reason. There aren't two consecutive TransferLegs.
Information about the feasibility of the TRIP, in particular with respect to the access features used.
A list of references to SITUATIONs.
Type for identifier of a NeTEx Object.
A single stage of a TRIP that is made without change of MODE or service (e.g., between each interchange). Implements LEG from TM 6.2.
Id of this leg. Unique within trip result.
[equivalent of PARTICIPANT in SIRI] IT system that is participating in a communication with other participant(s)
The duration of the LEG (e.g., from Transmodel PT RIDE LEG.Duration).
Corresponds to a RIDE or PT RIDE LEG in TM 6.2 with the attribute Timed (with related information). Passenger LEG with timetabled schedule.
TRANSFER LEG or CONNECTION LEG according to TM 6.2. Description of a LEG which links other LEGs where a TRANSFER or CONNECTION between different LOCATIONs is required.
A specialised type of RIDE LEG in with Timed=false, a PERSONAL LEG or an ACCESS LEG TM 6 and NeTEx. LEG of a TRIP that is not bound to a timetable.
TRUE if leg got changed by TripChange-Request.
Corresponds to a RIDE or PT RIDE LEG in TM 6.2 with the attribute Timed (with related information). Passenger LEG with timetabled schedule.
Stop/Station where boarding is done
Information about the intermediate passed stop points.
Stop/Station to alight
Service that is used for this leg.
Attributes that are not valid on the whole service, but only on parts of the journey leg.
Geographic embedding of this leg.
Services running combined with at least parts of this journey, e.g., wing trains. The contained stop sequence interval refers to the original journey.
TRANSFER LEG or CONNECTION LEG according to TM 6.2. Description of a LEG which links other LEGs where a TRANSFER or CONNECTION between different LOCATIONs is required.
TYPE that is used for this interchange between public services (TYPE OF TRANSFER, but also ACCESS MODE and PERSONAL MODE as far as a TRANSFER is concerned). In some constellations multiple TransferType are possible.
Stop/Station/Place where boarding is done (can be a PLACE, SCHEDULED STOP POINT or a VEHICLE MEETING POINT)
Stop/Station/Place to alight (can be a PLACE, SCHEDULED STOP POINT or a VEHICLE MEETING POINT).
Text that describes this interchange.
Length of this interchange path.
Note or service attribute.
Structured model further describing this interchange, its geographic embedding and accessibility (LEG.PATH GUIDANCE).
Information about the feasibility of the TransferLeg, in particular with respect to the access features used.
A list of references to SITUATIONs.
[relates to a specific type of RIDE LEG with Timed=false or an ACCESS LEG in TM and NeTEx] leg of a journey that is not bound to a timetable.
PLACE where the leg starts (can be a PLACE, SCHEDULED STOP POINT or a VEHICLE MEETING POINT) with time information.
PLACE to alight (can be a SCHEDULED STOP POINT or a VEHICLE MEETING POINT) with time information.
Service of this leg.
Duration of this leg according to user preferences like walking speed.
Title or summary of this leg for overview.
Length of the leg.
Detailed description of each element of this leg including geometric projection.
Structured model further describing this interchange, its geographic embedding and accessibility (LEG.PATH GUIDANCE).
Information about the feasibility of the ContinuousLeg, in particular with respect to the access features used.
A list of references to SITUATIONs.
Describes the situation at a stop or station at which the passenger boards a Leg of a trip including time-related information.
Contains ARRIVAL times (timetable, recorded, estimated, timing bands estimated) and the ARRIVAL formation.
Contains DEPARTURE times (timetable, recorded, estimated, timing bands estimated) and the DEPARTURE formation.
Interchange identifier of the distributing line/service at its boarding. This is not a reference. This identifier is used to recognize in a distributed environment (e.g., EU-Spirit), that two systems refer to the same line (or service) while using their own internal references. In EU-Spirit this is used to decide whether an interchange is in fact a stay-seated scenario (aka "line ID"). See https://eu-spirit.eu/
This stop fulfils one of the via requirements stated in the request data.
Describes the situation at a stop or station at which the passenger alights from a Leg of a trip including time-related information
describes the arrival situation at the leg alight stop point (group of attributes of TIMETABLED PASSING TIME, ESTIMATED PASSING TIME, OBSERVED PASSING TIME)
describes the departure situation at this leg alight stop point (empty for last leg) (group of attributes of TIMETABLED PASSING TIME, ESTIMATED PASSING TIME, OBSERVED PASSING TIME)
Interchange identifier of the feeding line/service at its alighting. This is not a reference. This identifier is used to recognize in a distributed environment (e.g., EU-Spirit), that two systems refer to the same line (or service) while using their own internal references. In EU-Spirit this is used to decide whether an interchange is in fact a stay-seated scenario (aka "line id"). See https://eu-spirit.eu/
This stop fulfils one of the via requirements stated in the request data.
Describes the situation at a stop or station that lies between the LegBoard and LegAlight stop or station including time-related information.
describes the arrival situation at this leg board stop point (empty for first leg) (group of attributes of TIMETABLED PASSING TIME, ESTIMATED PASSING TIME, OBSERVED PASSING TIME)
describes the departure situation at this leg board stop point (group of attributes of TIMETABLED PASSING TIME, ESTIMATED PASSING TIME, OBSERVED PASSING TIME)
This stop fulfils one of the via requirements stated in the request data.
Description of a piece of a TRIP. May include geographic information, turn instructions and accessibility information.
A view of LEG TRACK including PATH JUNCTION information, PATH LINK information and PATH GUIDANCE. One or more path guidance sections that form the LEG. For a good PATH GUIDANCE, a fine granularity of the sections may be needed. This may also depend on the MODE and the type of guidance required.
An extended definition of a NAVIGATION PATH in TMv6 and PATH GUIDANCE to include the textual navigation instructions. Description of a part of a TRIP. May include geographic information, turn instructions and accessibility information.
An aggregate of information that may be leaning on LEG TRACK together with duration and length that can be used for representing the leg on a map. The points may be STOP PLACE, SCHEDULED STOP POINT, coordinates, or ADDRESSes.
Textual description of a traveller manoeuvre. Contains information from manoeuvre, TurnAction, and TrackSection.RoadName.
Several types of guidance advice given to traveller (according to Transmodel a view of a LEG TRACK and PATH GUIDANCE).
The range of possible turns that can be described (according to Transmodel a view of a LEG TRACK and PATH GUIDANCE).
Road name
Signs, roads, POI to follow.
Textual direction hint for better understanding, e.g., "follow signs to Hamburg" (according to Transmodel a view of a LEG TRACK and PATH GUIDANCE).
Absolute bearing (sky direction) after the described manoeuvre.
Description of the type of accessibility on this navigation section. This view is simplified in comparison to the NeTEx PathLink structure.
A list of references to SITUATIONs.
Follow a sign.
Follow a road/route.
Follow a direction.
Follow an exit.
Several types of guidance advice given to traveller. Suitable values may differ by MODE (e.g., a car driver needs different advice than a person walking for a transfer.
Defining origin.
Defining a destination.
Continue on the same street/road/path.
Keep going on the same street/road/path.
When this value is used, you always must consider the value in TurnAction as well. There must be a TurnAction present if "turn" is used.
Can be something like an elevator or a vehicle.
Can be something like an elevator or a vehicle.
Entering a roundabout.
Staying in the roundabout.
Leave the roundabout.
Entering a built-up area / community.
Leave the built-up area / community.
Access lane to highway or the like.
If it is unclear which lane to choose.
If there are more than 2 lanes, then TurnAction half_left, left, sharp_left may help decide.
If there are more than 3 lanes, then Turnaction straight defines the middle one.
If there are more than 2 lanes, then TurnAction half_right, right, sharp_right may help decide.
The range of possible turns that can be described.
338-21 degrees
22-67 degrees
68-111 degrees
112-157 degrees
158-201 degrees
202-247 degrees
248-291 degrees
292-337 degrees
Upwards, the target level is in the PathLink structure.
Downwards, the target level is in the PathLink structure.
[an attribute of a CONNECTION (not INTERCHANGE) in TMv6] calculated duration in a response taking into account the request parameters. TransferDuration plus waiting time is the minimum interval between arrival and departure time.
Overall duration of this interchange (Transmodel: PT CONNECTION LEG.MEAN INTERCHANGE TIME).
Walk time as part of the overall interchange duration (in Transmodel might be modelled as TRANSFER.CONNECTION.DefaultDuration).
Buffer time as part of the overall interchange duration. Buffer times, e.g., check in/out times, sometimes are mandatory for using certain services as e.g., airplanes, ferries or highspeed trains.
Adding interchange elements from SIRI to a transfer leg.
Reference of an INTERCHANGE.
Whether this interchange is an addition to the plan. Can only be used when both participants recognise the same schedule version. If omitted, defaults to 'false': the interchange is not an addition. (since SIRI 2.1)
Whether this interchange is a cancellation of a previously announced interchange (or planned according to the long-term timetable.
Can only be used when both participants recognise the same schedule version. If omitted, defaults to 'false': the interchange is not cancelled. (since SIRI 2.1)
Allowed values for a AccessFeature.
Transition types for interchanges.
Allowed values for status of the access feature.
If partiallyAvailable is used, then some note should be provided in one of the descriptive elements of the containing PathLink
Allowed values for the feasibility of a TRIP or part of a TRIP.
Allowed values for AccessibilityFeature (for mobility and sensory impairments, assistance and crucial elements to pay attention to).
[TMv6] a link within a PLACE of or between two PLACEs (that is STOP PLACEs, ACCESS SPACEs or QUAYs, BOARDING POSITIONs, POINTs OF INTEREST etc. or PATH JUNCTIONs) that represents a step in a possible route for pedestrians, cyclists, or other out-of-vehicle passengers within or between a PLACE. Here we use a reduced form of a PATH LINK containing the description of the type of accessibility on this navigation section.
Whether path is up, down, or level.
Type of physical feature of PATH LINK.
Number indicating how often the access feature occurs in this PathLink
Whether the access feature is available or out of service.
Textual information about reduced availability of the access feature, in particular if AccessFeatureStatus is partiallyAvailable.
Presence of an accessibility feature on the PathLink.
Reference to a situation that affects the availability of the access feature.
Designations of level and place where this PathLink starts.
Designations of level and place where this PathLink ends.
Designations of a floor/level.
Public identifier of the level as found on elevators and signs.
Official name of the level.
Id of the element at this end of the PathLink (typically a PLACE, e.g., where the elevator is located).
========================================== Multi-point trip request ==========================================
Multi-point trip request structure.
Specifies the origin situation from where the user wants to start.
Specifies the destination situation where the user is heading to.
Ordered series of points where the journey must pass through. If more than one via point is given all of them must be obeyed - in the correct order. The server is allowed to replace a via stop by equivalent stops (in Transmodel modelled as TRIP REQUEST PLACE.TRIP VIA PLACE.GoVia).
Not-via restrictions for a TRIP, i.e. SCHEDULED STOP POINTs or STOP PLACEs that the TRIP is not allowed to pass through. If more than one not via point is given all of them must be obeyed.
no-change-at restrictions for a TRIP, i.e. SCHEDULED STOP POINTs or STOP PLACEs at which no TRANSFER is allowed within a TRIP (in Transmodel this would be an extension to TRIP MOBILITY FILTER).
Options to control the search behaviour and response contents.
Multi-point trip request parameter structure.
Parameters for fare calculation. Only used if IncludeFare is set (TripContentFilterGroup).
Policies that control the multipoint trip search behaviour.
Defines how the router should handle requests with multiple origins and destinations. As it is important for the strategy of the distributed trip planning the MultiPointType should be set. If the type is not supported a TRIP_MULTIPOINT_TYPE_NOT_SUPPORTED warning or error must be returned. Default is anyPoint.
Defines how the router should handle requests with multiple origins and destinations. MultiPointType is more important than NumberOfResults in the sense that if 10 results are needed to fulfill the MultiPointType, then it is 10, even when NumberOfResults was set to 1.
Returning results for a single origin and destination (hopefully the best ones). As this element was not sufficiently defined in the past, some implementations may behave differently.
At least a distinct solution for each of the origin points must be delivered.
At least a distinct solution for each of the destination points must be delivered.
At least one result for each origin/destination pair must be delivered.
Clarifies that some (probably the "best") origin-destination pairs should be returned. How many are to be used is not defined.
========================================== Multi-point trip response ==========================================
Multi-point trip response structure.
The MultiPointType should be returned because it may differ from the one asked. Many systems will support only a subset of the MultiPointTypes, and it is important to know what the result is based on.
Context to hold trip response objects that occur frequently.
The trip results found by the server.
Type for identifier of a NeTEx Object.
Structure for a multipoint trip result and associated problems
Id of this trip result for referencing purposes. Unique within multipoint-trip response.
Problems related to this trip result.
Information on the trip.
Summary on trip. Only if requestor set TripSummaryOnly in request.
Fare and fare product information for this trip as a whole or parts of it.
Group for wait times at origin/destination.
Additional wait time at origin of this trip.
Additional wait time at destination of this trip.
Parameters which describe the status of a TRIP (will be added to MONITORED TRIP in Transmodel).
Whether this trip is an additional one that has not been planned. Default is false.
Whether this trip is cancelled and will not be run. Default is false.
Whether this trip deviates from the planned service pattern. Default is false.
Whether this trip is delayed. Default is false.
Whether this trip cannot be used, due to operational delays and impossible transfers. Default is false.
========================================== TripRefineRequest definitions ==========================================
Trip refinement request structure.
Options to control the refine
The trip result to be refined by the server.
Context to hold objects, which are referenced within the response.
Trip refinement request parameter structure.
If true, then the request may contain object references from another system. Default is FALSE.
Refers to the legs to be refined by the server. If none is specified, all legs are open for refinement (depending on whether the system in question can refine them).
System reference to use for the refinement. If not specified, the origin systems of each leg are used for the refinement.
Parameters for fare calculation. Only used if IncludeFare is set (TripContentFilterGroup).
========================================== TripRefineResponse definitions ==========================================
Trip refinement response structure.
Context to hold trip response objects that occur frequently.
Refers to a leg that was not found in the data of the server. If the to be refined TripResult could not be found or unequivocally determined, all RefineLegRefs are returned as UnknownLegRefs.
The trip results refined by the server.
========================================== Problems ==========================================
Types of problems that may be returned in responses to Trip requests.
No trip plan could be found that meets all the parameters as they have been set by the user (start and end locations, departure/arrival time and further options possibly set by the user).
The start location (address, stop place, …) for the requested trip is unknown.
The end location (address, stop place, …) for the requested trip is unknown.
One of the via points is unknown.
One of the not-via points is unknown.
One of the no-change-at stations is unknown.
No start location has been defined for the trip.
No end location has been defined for the trip.
Start and end of the trip are identical.
The requested date and/or time do not make sense.
The requested time window is too large.
The requested departure time at each origin is after the requested arrival time at any destination.
There is no timetable data available for the requested date.
The requested origin stop place has been replaced by an equivalent stop place.
The requested destination stop place has been replaced by an equivalent stop place.
One of the requested via stop places has been replaced by an equivalent stop place.
There is no real-time information available for at least one of the services within this trip result.
The maximum time allowed for using modes of individual transport (mostly walking or cycling) has been extended by the system because otherwise no trip could be found.
The mode of individual transport specified by the user has been replaced by the system because otherwise no trip could be found. Usually, this means taking a taxi instead of walking.
The trip plan in this trip result contains a long waiting time.
Used for warnings, when possible/better results were dropped, because of the criteria were not used (e.g., private services, offer only available for seniors).
No trip solution was found covering each of the requested points.
Too many points have been requested as departure or arrival.
The indicated multipoint type is not supported.
Indicated legs do not exist.
The object to be refined could not be found in the database of the responding system or could not be found unequivocally.
Refinement does not support the hiking or cycling profile.
A problem has occurred that does not have a specific problem type.
========================================== TripChangeRequest definitions ==========================================
Trip change request structure.
Options to control the change.
The trip result to be changed by the server.
Context to hold objects, which are referenced within the response.
Trip change request parameter structure.
Refers to the leg to be adapted by the server. Typical usage: either a transfer leg representing an interchange that is considered too short or a sharing leg for which the exact times shall be retrieved for a specific operator.
System reference to use for the refinement. If not specified, the origin systems of each leg are used for the refinement.
Whether to extend the initial time interval of the ChangeLeg towards the front or the back of the trip (earlier respectively later times).
Absolute time in minutes the passenger wants additionally to make the interchange. If another TransferLeg is needed (e.g., since another quay is used for the found arrival/departure) this is taken into account. If not passed, the next best arrival/departure is requested.
Options to control the search behaviour and response contents. They should be largely the same as used as in the initial OJPTripRequest.
Prefer earlier or later times.
========================================== TripChangeResponse definitions ==========================================
Trip change response structure.
Context to hold trip response objects that occur frequently.
The trip results refined by the server.
========================================== Problems ==========================================
Types of problems that may be returned in responses to TRIPCHANGE requests.
No later option for the requested part of the TRIP could be found.
No earlier option for the requested part of the TRIP could be found.
Requested leg ref is invalid.
Requested operator is invalid.
No vehicle is available for the requested leg.
A problem has occurred that does not have a specific problem type.
© 2015 - 2025 Weber Informatics LLC | Privacy Policy