DRAFT RELEASE 1.00 DRAFT
SAE ATIS Routing GUIDE DOCUMENT
A training document developed to teach the
ATIS message set standards
Society of Automotive Engineers
400 Commonwealth Drive
Warrendale, PA 15096-0001
This Guide is available for download at:
http://serv1.itsware.net/itsschemas/ATIS%20Guide/ATIS-Routes/
The Primary ATIS Users Guide can be found at
http://www.itsware.net/atisworkingdrafts/guide/
Current technical support and information exchange about using the ATIS standards in deployment and with other ITS standards can be obtained at the ITS Standards Forum, a community resource available http://www.ITSstandards.net/bb/index.php
There is a set of forums dedicated to ATIS related issues at
http://www.ITSstandards.net/bb/index.php?c=3
ATIS Routing Guide – Table of Contents
Part I Definition and Usage of Routes 3
An Overview of ATIS Routes 3
Purpose of Routes in ATIS 3
Overview of Route Definition 3
How ATIS Uses Routes 4
Definition of the ATIS Route Element 6
The Basic Route Structure 6
Contents of a Segment Element 9
Maneuver and Instructions 12
Boarding Instructions 14
Other Instruction Components 14
Parking Instructions 15
ATIS Message Structures Using the Route Element 16
The Route – Request Message 16
The Response Message Containing a Route 18
Linking Routes to Incident Events, Weather and other data 19
Customizing ATIS for Local Use 19
Other Supporting Guides 19
Part II Considerations for implementing Routes 20
A Simple Street Network 20
A Detour & Construction Route Example 21
A Park & Ride Van Special Event Example 27
A Turn-by-Turn Driving Example 29
A Transit Example 34
A Multi-Modal Example 37
A Route Request Example 43
A Last Word of Advice 44
Part III Supporting Work 45
The ATIS schema, reduced 45
An Example WSDL system 46
Well formed Routing Messages 48
Part I Definition and Usage of Routes
Part I of this guide covers a number of general but practical topics on the use of the routing messages, building on the content found in the general guide. A general reduced ATIS schema is provided (in Part III) to make routing use easier than using the whole standard. The resulting schema reflects a testable interface by which deployments can judge and manage the content that is exchanged. Part II of the guide uses the principles established here and in the other guides to present working XML examples matching both the reduced and full schemas.
An Overview of ATIS Routes
Purpose of Routes in ATIS
The route structures provided in the ATIS message set standard are used to provide several general types of routes as listed below.
· Individual driver turn-by-turn routing
· Trip and route planning services between a user and a service provider
· Multi-modal trips (typically driving, transit, and walking modes)
· Response vehicle routing for incident dispatch operations
· Routing for specialty vehicles’ needs (oversize loads, etc.)
· Rideshare planning services
· Special event parking and shuttle services
· Detour and construction routing instructions
All of these needs are fulfilled by the same basic route, subroute, and segment data structures. Their proper use is the topic of this guide document.
Overview of Route Definition
A route as defined by ATIS contains an origin, a destination, and a sequence of instructions to proceed from the origin to the destination. The instructions may be where to turn and how far to proceed between maneuvers (typically used by drivers, bicyclists, or pedestrians) or where and when to board or alight from a transit vehicle, or a combination of these. It may have a sense of time (such as needing to connect to and catch a scheduled bus service) or it may be independent of time constraints (for example a standing construction detour). It may be the result of constraints for the allowed vehicle type or person who can use it. It may express the route as a sequence of subroutes and segments (steps) that make up that route.
How ATIS Uses Routes
Five general patterns of message use are discussed which represent the typical ways in which routes (and route requests) are used in the ATIS standard.
1. Route Request Message
In most cases which involve an individual traveler, a specific route is generated in response to a request for a route. A RouteRequest message is used to request a route from an information provider. A minimal RouteRequest consists of a minimal route, specifying the origin and destination. A more complex RouteRequest may specify waypoints as intermediate points, and may specify particular subroutes or modes. In this manner, a route request could specify different travel modes for different portions of the trip (e.g. a request for an itinerary enabling the traveler to drive from A to B, take the ferry from B to C, and take the bus from C to D). Essentially a RouteRequest message functions by submitting a Route with none or some of the details filled in, and by requesting the information provider to supply the remaining details. A subsequent section provides further details on how Constraints and Preferences are used in Route Requests.
2. InformationResponse Message
The response to the RouteRequest message is contained in the InformationResponse message. There is no separate RouteResponse message because the InformationResponse message already provides for it. As described in other guides, the InformationResponse is used to wrap many types of ATIS messages into a container object for sending to the data consumer (the traveler). The response to a RouteRequest message is an InformationResponse message with a ResponseGroup containing one or more Route elements.
Two general types of routes are both transmitted in this way. First are complete routes which have been created independently of an individual traveler (such as construction detours). Second, routes specific to an individual traveler and meeting any restrictions or needs that they have. In the case of a route being iterated between the consumer and the data provider, the Route structure, which may have started as a route fragment contained in the RouteRequest, would now contain the complete route specification.
In the case of routes specific to an individual traveler, if the data provider cannot process a trip guidance request, the response includes an ErrorNotificationCode in the StatusBlock portion of the InformationResponse message. An error message could be generated either because the data server cannot identify the origin or location of a trip, or because the trip cannot be completed within the constraints specified by the data consumer. This dialog process is covered in greater detail in the general guide.
3. AdvisoryInformation Message
A route may also be included in an AdvisoryInformation message. This type of message is broadcast to subscribers and affected parties, not in response to a request. A detour because of construction or road blockage, or a special event is an example of this type of message.
4. References to and from Other Message Components
Since it may have an Id number in its header element, a route may be referenced by other ATIS message components, such as weather reports, incidents, or event messages (typicality providing a detour due to the event). Similarly, those message components may be referenced within a route.[1] This referencing ability allows reflecting real time or predicted traffic, weather, and other events that may affect the traveler during passage along the route.
The ATIS route structure is also imported and used by other message set standards, notably IM and TCIP, whenever there is a need to convey a route.
5. Routes in ATIS Dialogs
As outlined at length in the General Guide and in the Event Guide, the ATIS message set is composed of a basic set of dialogs (WSDL service points) made up of request and response messages defined in the ATIS XSD schema. Routes are used in the RouteRequest/InformationResponse Dialog and in the AdvisoryInformation message. Part III of this guide provides data and links to a WSDL set of services implementing the route message according to the rules of the standard.
Definition of the ATIS Route Element
The Basic Route Structure
The basic structure of the route element itself is made up of three major sections nested as described below. These can be expressed as the need arises to form very complex routes or sets of routes.[2] However, most routes are fairly simple, consisting of one route element and a small number of subroute elements[3], each of which contains a number of segments. A typical route, using a single mode or transport - such as a vehicle detour, would have one subroute and the steps or instructions would be conveyed in the sequence of segments.
The components of routes, subroutes, and segments are covered in more depth in the ATIS General Guide document, but a summary is provided here. Recall that TripPreferences and TripConstraints are found in the RouteRequest message[4] so they need not be present in the resulting route.
A route element contains:
· An origin and a destination, expressed in LRMS profiles[5]
· An optional header element with identifying information
· An optional indicator of the travel mode to be used
· Optional start and stop times, estimated distance and cost, and maps
· From one to 50 subroutes elements
· A flag indicating whether or not the route is also an itinerary
(i.e. specific times may be included and it is intended for an individual traveler)
A subroute element contains the same components as a route element:
· An (optional[6]) origin and a destination, expressed in LRMS profiles
· An optional indicator of the travel mode to be used
· Optional start and stop times, estimated distance and cost, and maps
· Optional weather, traffic, or events elements related to the subroute
· From one to 50 segment elements[7] describing the actual steps of the subroute
· Optional primary mode of travel. If a route involves multiple modes, it is common, though not required, to break instructions pertaining to each mode into separate subroutes.
A segment element contains a single step in a subroute:
· Optional boarding instructions if the instructions call for boarding a transit vehicle
· Optional amenities applicable to transit vehicles as well as airlines
· A set of midpoints for the segment, allowing mapping with waypoints or shapes[8]
· What action is required at that endpoint (up to three actions are permitted)
· An endpoint, expressed in a subset of LRMS profiles. Although it is named <endpoint>, this point should be considered the beginning point of the segment: the point at which the required action occurs. The “length” of the segment is expressed in the <distance> and/or <estimatedTripTime> elements that follows.
· What role the endpoint plays in the overall route
· Optional distance to be traveled before the next segment begins (this is the “length” of the segment in distance)
· Optional estimated time before the next segment begins (this is the “length of the segment in time).
· Optional characterization of equipment class (typically used in transit and planes)
· Optional mode of travel to be used
· Optional start and stop times and estimated cost
Some of the above items are needed only when there is an interactive exchange between the traveler and the route supplier, or between a vehicle requesting a route and its dispatching center (in the case of IEEE IM 1512 use of this message). This is typical for transit uses. If expressing only construction and detour routes for the “general public” (when no such interaction is likely to occur), the resulting messages can made a slightly simpler. Adjust the local schema used to reflect the level of need the deployment has.
The figure at right shows the structure of the complete route element, including ten optional elements that are typically used only with routes developed for individual travelers. Note that many of these deal with issues of time and cost that may have not relevance to the types of static routes found in construction or as a detour.
If we remove these optional elements and expand parts of the diagram to show the content of interest in a typical static construction style of route use, the figure on the next page results. This shows the structure of the route element included in the simplified ATIS subschema provided in Section III, which is suitable for most construction and detour needs. As can be seen, the route consists of a set of subroutes which in turn is made up of a set of segment elements.
Note that any XML message developed for this reduced schema will also validate against the complete schema as well (with slightly more processing time used due to its large size).
Contents of a Segment Element
The segment elements themselves are the actual steps of the route. If you can render your route into a natural language form of instructions or actions (“turn left at XYZ and drive for two miles...”) then these steps will fall naturally into the format supported by the segment data frame.
Like the route, the segment contains several optional elements used in transit and other multi-modal applications which are not used at other times. To better visualize this, two views of the segment element will be given (the 2nd with optional content removed). The complete segment definition is shown on the next page.
Note the presence of many optional items to describe classes and types of service for transit needs. The element BoardingInstructions is also relevant for this.
The following figure presents the major components of a segment element with the optional content used only in transit routing removed. This view is more typical of the data content which creators of construction and detour messages need to convey.
The segment then becomes a simple way to express the action to be taken in the element actionRequired. The endpoint is the “beginning” end of the segment, where the required action is to take place. The midPoints element can optionally be used to relate the shape of the path to be traveled. The segmentDesc can be helpful when free text is needed.