Development of Transactional Data Specifications for Demand-Responsive Transportation (2020) / Chapter Skim
Currently Skimming:
Pages 43-58
The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.
From page 43... ...
43 This chapter presents an overview of the recommended transactional data specification. The objectives of the specification are to (1)
|
From page 44... ...
44 Development of Transactional Data Specifications for Demand-Responsive Transportation • Data communication approach -- The specific mechanism by which system-to-system (machine-to-machine) data communication occurs so that messages are reliably transmitted from requestor to recipient(s)
|
From page 45... ...
Summary of the Specification 45 • Service scheduling entity -- Service provider or an organization that handles vehicle scheduling and routing for one or more service providers and instructs them on how to deliver service. • Service provider and/or vehicle performing the trip order -- With a specific focus on the trip delivery information.
|
From page 46... ...
46 Development of Transactional Data Specifications for Demand-Responsive Transportation From this perspective, there is no requirement to transmit customer-identifying information, simply functional requirements and a set of tasks to be performed on behalf of customer requests. (Basic customer-identifying data such as name will eventually be included in the data messages, but such data is not essential to advance the transactions prior to actual service execution.)
|
From page 47... ...
Summary of the Specification 47 regarding special needs and mobility aids to send the appropriate vehicle and driver for a customer. In addition, the entity booking the trip typically wants to know the time of the medical appointment, as arriving too early imposes inconvenience on the customer and arriving late may cause the appointment to be canceled by the healthcare provider.
|
From page 48... ...
48 Development of Transactional Data Specifications for Demand-Responsive Transportation All 11 telegrams are needed to encompass the full set of core functional needs for a demandresponsive transportation transaction. Over time, additional telegrams can be added as participants wish to add more detail for certain aspects of transactions.
|
From page 49... ...
Summary of the Specification 49 services. The public agency trip-booking software was commonly distinct and separate from the software used by taxi companies that handled their vehicle operations and customer interface.
|
From page 50... ...
50 Development of Transactional Data Specifications for Demand-Responsive Transportation in this chapter, a YES or NO in the "Mandatory" column indicates whether this is one of the minimum required data elements needed to conduct a transaction. Some entities may require one or more of the additional, nonmandatory data elements in the telegram for it to be valid to transact with their specific service/clients.
|
From page 51... ...
Summary of the Specification 51 Telegram 3:A REQUISITION - Route/trip task From: Provider To: Vehicle Purpose: Control Vehicle XSD Complex Type Name trip Task Data Element Explanation Mandatory Field Type Trip ticket Unique ID from ordering client YES String Trip/route task ticket Unique ID from provider YES String Rider pickup location in vehicle performance sequence YES Numeric Pickup node address/geocode YES Address Pickup node scheduled time YES Time Pickup location detailed description NO Long text Rider drop-off location in vehicle performance sequence YES Numeric Drop-off node address/geocode YES Address Drop-off node scheduled time NO Time Drop-off location detailed description NO Long text Rider mobile phone NO Numeric Rider name YES String Other (free field) Rider: Service Needs NO Long text for driver Special attribute List of special attributes of passenger trip NO List Number of other reserved passengers YES Numeric Fare type Cash, credit card, fare card NO List Fare amount Fare to collect from passenger YES Numeric Table 4-4.
|
From page 52... ...
52 Development of Transactional Data Specifications for Demand-Responsive Transportation the provider's scheduling and dispatching systems will almost always send a data message from the vehicle to the central system when a passenger is picked up. As it is not clear that other systems need the pickup information in real time, the proposed specification does not make this a required telegram.
|
From page 53... ...
Summary of the Specification 53 It then interfaces with an internal data translator that transforms the data messages and their elements into the common data protocol. In essence, this is an internal API (application programming interface)
|
From page 54... ...
54 Development of Transactional Data Specifications for Demand-Responsive Transportation and translate the data into the common protocols used for communication. There is also a comparable amount of technical work for the external technology systems; they must translate data between the agreed upon common specification -- the language that the broker speaks -- and their respective internal data schemes.
|
From page 55... ...
Summary of the Specification 55 Disadvantages -- The disadvantage is the converse: all systems must use a similar internal representation of data -- or in essence have an internal translation capability -- and all changes in the specification must be adopted by all parties before interoperability can be assured across the entire ecosystem of participants. The latter is the disadvantage of this approach to achieving specification lock-in.
|
From page 56... ...
56 Development of Transactional Data Specifications for Demand-Responsive Transportation Disadvantages -- The primary disadvantage of the control module approach is that it requires an additional element compared to the point-to-point approaches, but does not eliminate the need for a syntax-checking step compared to the translation broker approach. At the same time, while syntax checking is a necessary step in the message data flow, it can be handled by the control module, which will determine whether the syntax is acceptable -- in which case the message can be processed successfully.
|
From page 57... ...
Summary of the Specification 57 attributes. Some of these describe the mobility aid that the rider may be using (and bringing onto the vehicle)
|
From page 58... ...
58 Development of Transactional Data Specifications for Demand-Responsive Transportation from the transmitting computer program. The JSON approach has become more widely used in recent years and is probably the most appropriate way of handling the actual data transmission.
|
Key Terms
This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More
information on Chapter Skim is available.