Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
76 : Conclusions and Future Considerations This research focused on developing an implementable transactional data specification for demand responsive transportation. The proposed specificationâset forth in its entirety in Appendix 5âis intended to be an initial step in enabling efficient data inter-operability among the software systems used by DRT service providers. This enables coordination for organizations that want to share resources, carry more passengers and be more cost-effective. But data inter-operability is only likely to be feasible on a widespread basis if a common set of data specificationsâsuch as those developed in this researchâare available to be used by the interacting systems. Specifications- based transactional data interactions are commonplace in other transportation industries such as airlines, and have been well-established for many years for DRT services in Sweden and Denmark. This concluding chapter has two purposes. First, a summary of the most important elements of this research is presented, highlighting the key findings and conclusions from the prior chapters. Second, we discuss the way forwardâor more accurately, the possible ways forwardâto actually implement a transactional data specification for the DRT industry so that the potential benefits of standardized data exchanges can actually be realized. 5.1 What We Learned from the DRT Industry Advisory Panel In this project, a panel of 22 industry experts was formed to advise the development of the specification. This group, which included all of the key types of stakeholders discussed in Chapter 2, is referred to as the âindustry Advisory Panelâ. The research team engaged the advisory panel for two primary purposes. First, in the early stages of the research, team members conducted semi- structured telephone interviews with industry Advisory Panel members to determine their perspectives about the importance of data specifications and how such specifications might come into being and be governed. Second, throughout the project, the industry Advisory Panel members took part in regular virtual meetings (via conference call/web meeting), a total of 6 such meetings, to provide input on the specification approach and the specifications themselves as they were developed. The detailed results of these two activities are presented in Appendix 2. A list of the industry Advisory Panel members can be found in Appendix 1. The industry Advisory Panel process resulted in 4 key findings. 1. There is general agreement with the objectives of a transactional data specification. 2. This is coupled with a high level of awareness of the multiple challenges that must be worked through if such a specification is to come into being on an industry scale. 3. There appears to be an absence of strong advocates within the DRT industry prepared to assume a leadership role in getting an adoption process underwayâpanel members liked the concept of specifications, but few seemed interested in taking a direct role in making specification implementation occur. 4. The development of a governance structure that can take ownership of the proposed specification is perceived to be a critically important need.
77 5.2 Key Lessons from Transportation-Related Examples of Data Specifications The case studies of the transportation-related data specifications revealed four very important lessons vis-Ã -vis the objective of actual implementation of DRT specifications. First, data specifications can produce game changing results. Transactional data specifications make possible not just data inter-operability, but also âbusinessâ inter-operabilityâorganizations can readily concert their activities in ways that are mutually beneficial. The airline industry started down this pathway many decades ago with less than elegant technical approaches, but an evolutionary process involving specification-based data exchange for mutual business advantage was set in motion that continues to this day. The SUTI standards are a major factor in the remarkable success of the FlexDanmark system. The FlexDanmark technology platform connects to several hundred organizations who sponsor and fund trips and over 500 transportation service providers using many diverse technologiesâbut all of which are SUTI- compliantâthat exchange data with that platform that enables it to manage DRT vehicle operations that collectively deliver up to 24,000 trips per day. Second, and equally important, the ability to achieve specification implementation is strongly tied to key stakeholders perceiving either financial benefits or other direct, concrete benefits from specification adoption. The actual implementation of the specification in organizationsâ software systems requires the expenditure of resources, possibly significant resources. There is also substantial effort needed to enhance or simply maintain the specification. There must be a business reason for a specification in order for organizations to voluntarily agree to make such resource commitments. âNice to haveâ will almost certainly not be adequate to convince organizations to adopt a specification. A business reason is clearly seen in the airline industry example, where the financial benefits of inter-lined ticketing were clear to all participants and resulted in the Passenger Name Record specification for data exchange. Similarly, in the case of the initial development of the SUTI standards there was also a strong business reasonâbased on financial considerationsâfor the Swedish government to mandate a specification approach. The national transport ministry wished to ensure that the local public sector organizations to whom it distributed transportation funds would be able to procure technology systems that by design worked well together and hence were not subject to needing expensive custom integrations that would also result in vendor lock-in and lack of future competition. While business reasons do exist for a DRT transactional data specification, they have not been clear to agencies funding a significant amount of DRT. Also, individual agencies that may understand the business reasons for using a specification do not have the power to affect change for the industry as a whole for what is actually a national issue.
78 Third, the pace of specification development and adoption by an industry or sector is strongly influenced by the resources under the control of the proponents of a specification. The contrast between how quickly the GTFS was adopted and disseminated and came into widespread use once Google put its resources behind the specification, and the many year process of developing GTFS-flex to a point where it might soon be adopted is very telling. Google could devote substantial resources to an ambitious specifications development undertaking that in a relatively short period of time fundamentally changed how public transit data was structured and exchanged. In contrast, the developers of GTFS-flex have had limited and only episodic access to financial resources for developing specifications and promoting their adoption. Similarly, it has taken 9 years to move the Denver trip exchangeâwhich includes DRT transactional data specificationsâfrom concept to what is still only a partial reality, with comprehensive operations probably not occurring until 2020. In both the GTFS-flex and Denver trip exchange cases the concepts for standardized data approaches made sense, but the proponents lacked the authority and financial resources to induce other key actors to make commitments that could have led to adoption in a more typical time frame of a few years. Fourth, authoritative actors, whether they are the government or private companies who are major players in an industry or sector, make all the difference in achieving specification implementation. While a voluntary, industry-initiated process is the most typical approach to specification development, an alternative pathway is for an organization with authority over industry participants to mandate that specifications be adoptedâas occurred with the Swedish government and the SUTI standards. Market leaders do not have the same formal authority as governmental entities, but their ability to influence outcomes is similarâif an industry leader proposes technical specifications for how software systems inter-operate, smaller competitors are likely to feel compelled to follow suit for fear of losing business otherwise. When FlexDanmark required all service providers to adhere to the SUTI standards, its status as both a quasi-governmental actor and as the gateway to public sector funding of DRT services in Denmark meant that technology companies and service providers had no alternative to specification adherence if they wanted to be part of the DRT sector. In a somewhat different way, Googleâs promulgation of the GTFS specification and the fact that Google Transitâavailable only via Google Mapsâwould only work with this data meant that transit agencies were essentially forced to publish their data in this format if they wanted information about their services to be widely available. 5.3 Considerations in Developing the Specification The research team focused the core technical elements of the DRT transactional data specification on supporting the âtrip lifecycle.â As described in Chapter 4, the trip lifecycle includes the following steps: 1. Trip Reservation Request. This step focuses on customer logistics, such as pickup and drop-off locations and requested pickup/drop-off times and any relevant information about a passengerâs ambulatory status. 2. Trip Scheduling. This step pertains to the assignment of a service provider and vehicle (or vehicle run) to the trip and determination of estimated pickup and drop-off times.
79 3. Trip Cancellation. This optional step occurs in the event that the passenger cancels the trip request, including un-assigning transportation resources allocated to the trip. 4. Trip Execution (delivery). This step includes the actual deployment of the vehicle/driver to service the trip and the pickup and drop-off of the passenger to the destination, including fare payment when appropriate. 5. Trip Reporting. This last step provides a full record of the trip from the request through trip delivery for data reporting and possible financial purposes. At this initial stage of specification development, sufficiency and simplicity are the key to meeting the foundational needs of DRT services for transactional purposes. The recommended specification ensures full coverage of the trip lifecycle, with a concise set of mandatory data elements and a much larger set of optional data elements. This ensures that relevant service and technology providers will be capable of interoperating across the entire range of data and technology boundaries relevant to a DRT trip. The level of detail necessary for transactional purposes for any set of business relationships can be determined by those which are party to the transaction; the specifications support both basic and detailed data exchanges. 5.4 Key Elements of the DRT Transactional Data Specification Two key elements of the proposed DRT transactional data specification are highlighted here. First, in recognition of the proven capabilities of the SUTI approach to DRT data specifications to achieve positive impacts in Sweden and Denmark, this research has borrowed heavily from technical aspects of the SUTI standard. Most fundamentally, the proposed specification is based on the concept of âtelegramsâ, which is at the core of the SUTI approach. Telegrams consist of a specific message type that includes certain standard mandatory and optional data elements. The 11 telegrams proposed are intended to provide the essential data exchanges among software systems needed to support a DRT trip from end to end. Second, given the many potential participants in DRT transactions from an industry-scale perspective, the data communication approach underlying transactional data exchanges should also be standardized to ensure reliability. In particular, given the importance of specification validation during data exchanges, the research team concluded that an âinternal translation with external validationâ approach was most likely to be successful. â¢ Recommended approach: The recommended approach uses a control module that enables organizations sending and receiving messages to test their telegrams and ensure their mutual validity. In this approach, each technology provider is responsible for the implementation effort needed for its software system to produce specification-compliant telegrams. They are also responsible for ensuring that the messages sent and received are validâthe control module provides them with the ability to do that, but they must develop the software that interfaces with the control module for that purpose. To support this approach, the research team developed a basic software tool that can be used as an initial working version of the control module for validating that data are nominally compliant with the transactional data specification. This can be used by any software system
80 needing to verify that its telegrams are syntactically correct. A description of this validator tool can be found in Appendix 6. â¢ Alternate approach: If sufficient resources could be assembled, a âtranslation brokerâ approach would be preferred, in which the broker software is responsible for ensuring that each message (telegram) is specification compliant. After successful verification, the broker then transmits the message onward to its recipient, which can be assured that it will be processing a specification-compliant message. This reduces the amount of work each DRT software system must do for ensuring that transactional messages are specification compliant. Unfortunately, the translation broker is a relatively substantial software application that is likely to cost many tens of thousands of dollars (or more) to develop. It is not prudent to construct a specification approach on the assumption that the resources to develop this software will be available in the same time frame as specification implementation. If resources can be obtained to create the translation broker, this would be the recommended approach to data communication of the telegrams. 5.5 ImplementationâPotential Scenarios Developments in the DRT industry and advances in technologyâwith particular emphasis on the heightened importance of technology platformsâhave created opportunities for improved DRT service outcomes if the software systems controlling these services can routinely inter-operate. The experiences in Sweden and Denmark offer evidence that such potential benefits are achievable, and transactional data specifications are a key element in making this possible. At the same time, it is also clear from this research that developing a set of recommended specifications is necessary but not sufficient for achieving the desired objective. Successful implementations elsewhere have had consciously guided and organizationally supported implementation processes with incentives to induce technology organizations in the DRT industry to adopt and use those specifications. In Sweden, the government was an authoritative advocate for SUTI transactional data specifications. In Denmark, FlexDanmark was a motivated market leader. Similarly, Google was motivated to develop GTFS because of potential business prospects. For DRT, a core industry need does not exist such as in the airline industry. While a transactional data specification would definitively produce benefits for some organizations who organize and fund DRT servicesâas the example of FlexDanmark makes clearâit is likely to be of limited value to others. Moreover, the Industry Advisory Panel indicated no immediate prospects for leadership to arise from within the DRT industry. This means that another way forward is necessary if the benefits of transactional data specifications are to be brought to the DRT industry participants in the near term. Rather than the typical top down approach to specification development and implementation, bottoms up approaches are likely to be more promising given current conditions. Multiple possible scenarios exist for advancing DRT transactional data specifications at the local or regional or sub-industry level.
81 In particular, local or regional initiatives may provide opportunities, as may well-funded pilot projects using federal, state, or regional funds The Denver trip exchange is an example of how this could occur. The initial data specifications developed for that initiative have some similarities to those developed in this project and it is conceivable that within the next year they could be superseded by the ones set forth in this report. The recommended data specifications and other technical outputs of the research presented in this report represent critically important technical and business resources that can be put to immediate use by those who perceive the importance of transactional inter-operability among DRT technology systems. The specifications now exist, and are accompanied by a technically viable approach for data communication and specification validation. If the involved parties want to engage in inter-operable/coordinated DRT transactions and choose to use the specifications developed in this project as part of making that possible, they can do so by following the process set forth in Table 5-1 below. The approach presented can be quickly put in place if organizations are motivated to act. With the publication of this report and the access to the materials included in it such as the specification XML and the specification validation software tool to which there is a link in Appendix 6, interested organizations now have the tools needed to make DRT service inter- operability possible. What the tools cannot do is provide either the motivation to act or the institutional resources necessary to implement a process that results in transportation service providers and technology providers working together to actually implement and use the specifications for transactional purposes. Table 5-1: Steps to Implementing the DRT Specification Step Description 1 Organizations wishing to interchange data for transactional purposes determine which optional data elements need to be present in the messages that will be transmitted 2 Each partyâs technology provider makes changes to its software system so that it can generate specification-compliant data messages to an external location 3 Each technology provider establishes a connection to the external validator software and adds a protocol in its own system so that outbound and inbound transactional messages to/from other entities are validated before being transmitted or consumed 4 The two (or more) organizationsâand their technology systemsâtest transactional messages to determine if their data inter-change is working properly. If problems are detected, they are fixed by the technology providers 5 Organizations begin exchanging transactional messages and new approaches to delivering service become feasible
82 As a means of assisting motivated parties in addressing the institutional aspects of the way forward in the near-term, the research team has developed communications-related items that may be useful for encouraging adoption and implementation of the proposed specification. To help facilitate possible implementation strategies, two documents were created and included as appendices to this report: â¢ Appendix 7 is a short (one-page) marketing document that can be given to managers at transit agencies and/or other DRT service providers. Written in non-technical language, it explains (1) what a DRT data specification is and (2) why DRT providers should adopt it. â¢ Appendix 8 includes a sample language that a transit agency or DRT service provider can include in a Request for Proposals (RFP) requiring use of the transactional data specification. Over time, this bottoms up approach can lead to a wider adoption across the transit industry and other DRT providers as other agencies take their lead from the early adopters. However, in the longer term, a more formal approach to governance to manage and adapt the specification is needed; this critical item is discussed in more detail in the next section. 5.6 Towards a Formal Governance Approach Numerous potential organizing models for implementing and managing the transactional data specification were identified during the research. It is clear from the interviews and research that the advocacy of the specification by one or more large organizations in this sector is important in catalyzing movement in towards widespread formal specification adoption. Table 5-3 sets forth eight governance models for the DRT specification and Table 5-3 summarizes the strengths and weaknesses of each. Table 5-2: Potential Models for Governance of the Specification Number Description Model 1 Federal Government Mandates Specification Model 2 International Organization Manages Specification Model 3 One or More Large Local Agencies Agree On Specification Model 4 Large Company Puts Forth Specification Model 5 Professional Organization Manages Specification Model 6 University Research Center Manages Specification Model 7 Consortium of Private Sector Players Agree on Specification Model 8 Develop and Manage Specification as Open Source Project â¢ Model #1: Federal Government Mandates Specification Some interviewees suggested that the federal government might need to mandate a specification for it to be widely adopted. The specific agency that was mentioned by numerous interviewees was the Federal Transit Administration (FTA).
83 â¢ Model #2: International Organization Manages Specification Another model that was suggested was having an international organization or collaboration manage the data specification. One technology provider noted that many of its clients are international, and there would be benefits of coordinating this effort beyond the U.S.. â¢ Model #3: One or More Large Local Agencies Agree On Specification Collaboration among a few large public agencies could result in a means of managing a future specification for DRT transactional data. A few large public agencies (e.g., New York, Los Angeles, and Chicago) could come together to make a standard happen; they could then release RFPs requiring that vendors use the standard. Or a few innovative transit agencies could work together and agree on a specification. â¢ Model #4: Large Company Puts Forth Specification The noteworthy example is Google and GTFS, which was a case in which a large company worked with a public agency to create a de facto standard. It is an open question, however, whether there is a company that is sufficiently large in the demand responsive transportation industry to develop a standard and convince a large part of the market to adopt it. â¢ Model #5: Professional Organization Manages Specification Either the American Public Transportation Association (APTA) or the Community Transportation Association of America (CTAA) could be appropriate forums for managing a specification for transactional data. There is an issue, however, as to whether either APTA or CTAA has sufficient technical expertise to play such a role. â¢ Model #6: University Research Center Manages Specification A university research center might be able to play a central role in the process of developing and maintaining a DRT data specification. The Center for Urban Transportation Research (CUTR) at the University of South Florida was cited as a possibility. However, this would likely require a dedicated funding source. â¢ Model #7: Consortium of Private Sector Players Agree on Specification A possible model mentioned by several Industry Advisory Panel members was a consortium comprised of predominantly private sector players. This could follow the model of the GTFS Best Practices Working Group that was recently convened; this effort was funded by the Rocky Mountain Institute, which is encouraging interoperable data standards. â¢ Model #8: Develop and Manage Specification as Open Source Project A final potential model was for the specification to become the focus of an open source project. This could be in combination with another model or as a stand-alone initiative.
84 Table 5-3: Governance Models with Key Strengths and Weaknesses Number Description Strength Potential Weakness Model 1 Federal Government Mandates Specification + Helps to encourage wide adoption of specification - Concerns about government mandate Model 2 International Organization Manages Specification + Many software developers and operators are not U.S.-based - Difficult to oversee and manage Model 3 One or More Large Local Agencies Agree On Specification + Specification based on actual needs and experience of local agencies - Difficult to coordinate across independent cities and agencies Model 4 Large Company Puts Forth Specification + Based on GTFS model for fixed route service - Difficult to identify analogous company in DRT Model 5 Professional/Industry Organization Manages Specification + Known organizations that have created other industry specifications - May not have needed technical expertise Model 6 University Research Center Manages Specification + Non-partisan and have technical expertise - Would likely need ongoing funding source Model 7 Consortium of Private Sector Players Agree on Specification + Based on successful model of the GTFS Best Practices Working Group - Would require high degree of initial and ongoing coordination among multiple parties Model 8 Develop and Manage Specification as Open Source Project + Technical advancements open to all able and interested groups - Lack of coordination may lead to multiple specifications While authoritative government involvement in the specifications situationâModel 1âwould almost certainly result in specification adoption, as was the case in Sweden, it is unlikely to occur in the U.S. Rather, industry associations and the leading organizations in these industries are typically the key to successful development of technical specifications. These organizations can be private sector, public sector, research focused (including academic), or some combination. A key challenge is to find mechanisms and opportunities to engage these entities to help catalyze the development of a governance structure for the specification. Such a governance structure is likely to be the key to widespread adoption of transactional data specifications for DRT and ongoing evolution of such specifications, as has occurred in Europe with the SUTI standards. While this is clearly the desired end state of this specification development process, there are multiple challenges to its achievement. In the immediate term, a more productive focus may be on maximizing discrete opportunities to implement theseâor similarâspecifications in as many situations as possible when conditions are favorable. Nothing will be more important in building momentum for an industry-level approach to adoption and governance of specifications than a number of successful examples of their deployment and utilization in situations of a more limited scope.
85 Reference List Craig, T. âAlpha releaseâ of the Flexible Trip Planner, https://trilliumtransit.com/2017/09/01/alpha-release-of-the-flexible-trip-planner/, Accessed December 13, 2018. Federal Transit Administration. Mobility Services for All Americans (MSAA): Case Studies in Advancing Universal Mobility. https://www.its.dot.gov/presentations/2018/MSAA_KTT_3_CaseStudy.pdf. Accessed December 13, 2018. Federal Transit Administration. Demand Response Fact Sheet, 2013. https://www.transit.dot.gov/sites/fta.dot.gov/files/docs/Demand_Response_Fact_Sheet_Final_wi th_NEZ_edits_02-13-13.pptx. Accessed December 13, 2018. FlexDanmark. FlexDanmark SUTI Selvdeklaration, 2015. https://www.flexdanmark.dk/web/om- os/publikationer/download/1547/2198/16. Accessed December 13, 2018. Github. gtfs-flex. https://github.com/CUTR-at-USF/gtfs-flex. Accessed December 13, 2018. Goodwill and Carapella. Creative Ways to Manage Paratransit Costs. Report No. BD 549 RPWO 28. USF Center for Urban Transportation Research, 2008. Google. GTFS Static Overview. https://developers.google.com/transit/gtfs. Accessed December 13, 2018. Google. GTFS Flexible Transit Working Group. https://groups.google.com/forum/#!forum/gtfs- flexible-wg/. Accessed December 13, 2018. Hillsman and Barbeau. Enabling Cost-Effective Multimodal Trip Planners through Open Transit Data. Report No. USF 21177926, 2011. International Air Transport Association. Reservations Interline Message ProceduresâPassenger (AIRIMP), 36th Edition, 2012. Larsen, Teal, King and Brakewood. Development of a Transactional Data Standard for Demand Responsive Transportation: A Case Study of Sweden. Proceedings of the 97th Annual Meeting of the Transportation Research Board, Washington, D.C., 2018. Lave, Teal, and Piras. A Handbook for Acquiring Demand-Responsive Transit Software. Transit Cooperative Research Program (TCRP) Report 18, published by Transportation Research Board, Washington, 1996. Metro. Request for Proposals No. 303911. General Transit Feed Specification for Real-Time (GTFS-RT) Data System. Issued July 26, 2018. Austin, Texas. Needleman. Who owns transit data? cnet.com. August 24, 2009. https://www.cnet.com/news/who-owns-transit-data/. Accessed December 13, 2018. OâNeil and Teal. TCRP Web-only Document 63: Standardizing Data for Mobility Management. Transit Cooperative Research Program of the Transportation Research Board, 2016.
86 Rojas. Transit Transparency: Effective Disclosure through Open Data. Transparency Policy Project, Ash Center for Democratic Governance, Harvard University, 2012. Schmidt, C. Best Practices for Technical Standard Creation: Guidelines for the Design, Socialization, Formalization, and Adoption of New Technical Standards, MITRE Corporation, April 2017. SUTI. About us. http://u3545014.fsdata.se/blogg/about-us/. Accessed December 13, 2018. SUTI. Description of SUTI-Messages, 2017. http://u3545014.fsdata.se/blogg/?media_dl=325. Accessed December 13, 2018. SUTI. Document Relations in SUTI Standard, 2017. http://u3545014.fsdata.se/blogg/?media_dl=324. Accessed December 13, 2018. SUTI. Standard Protocol for Demand-Responsive Transport Services. Welcome to SUTI. http://u3545014.fsdata.se/blogg/. Accessed December 13, 2018. SUTI. SUTI 2017 In Progress Message Flow, 2017. http://u3545014.fsdata.se/blogg/?media_dl=326. Accessed December 13, 2018. Teal, R. First Mile/Last Mile Shared Ride Services: Technology Enables New Business Models. Presentation at the 2015 TransITech Conference, 2015. https://www.apta.com/mc/revenue/program/Documents/First%20Mile%20Last%20Mile%20Sha red%20Ride%20Service%20Technology%20Enables%20New%20Business%20Models%20- %20Roger%20Teal.pdf. Accessed December 13, 2018. Wong, Reed, Watkins, and Hammond. Open transit data: state of the practice and experiences from participating agencies in the United States. Proceedings of the 92nd Annual Meeting of the Transportation Research Board, Washington, D.C., 2013.
88 Glossary American Public Transportation Association (APTA) The American Public Transportation Association (APTA) is an industry trade association that serves as an advocate for the advancement of public transportation in the United States. APTA membership includes public and private organizations in the areas of bus, paratransit, light rail, commuter rail, subways, waterborne passenger services, and high- speed rail. Americans with Disabilities Act (ADA) The Americans with Disabilities Act gives civil rights protections to individuals with disabilities. ADA guarantees equal opportunity for individuals with disabilities in public transportation, employment, public accommodations, state and local government services, and telecommunications. The Federal Transit Administration is responsible for regulations pertaining to the implementation of ADA in public transportation. Application Programming Interface (API) APIs are software intermediaries that allow two applications to talk to one another. Booking In this document, booking refers to a formal reservation (date and pickup time) for a demand responsive transportation (DRT) trip that will be fulfilled by a DRT provider. The terms booking and reservation are essentially synonymous for DRT. Broker In this document, a broker refers to a piece of software that receives a DRT trip order and then passes that trip request along to a DRT provider. This piece of software has the capability to translate the initial trip request into a specified message format before passing it along to providers. The software is capable of determining which providers to send it to. Client In this document, a client is an organization that has the travel demand information, which includes trip requests from customers on the demand-responsive transportation system. To fulfill these demands, the client has contracted one or several âproviders.â The provider (or operator) has access to vehicles and drivers that will actually fulfill the trips. Community Transportation Association of America (CTAA) The Community Transportation Association of American is national organization that advocates for local transportation service organizers and providers in the United States. Many of CTAAâs member organizations are from small and/or rural communities. Council of Governments (COG) The Council of Governments (COG) refers to regional governing or coordinating bodies in the United States. COGs are typically controlled by their member local governments.
89 Data Elements A data element is a unit of data with a precise meaning. It typically has a name, definition, and one or more representations. Demand Responsive Transportation (DRT) Transportation services in which a rider requests (orders) a trip through an automated or human-based system that schedules each ride onto a vehicle controlled by that system. Vehicles are scheduled and routed in accordance with the demand, including specified origin, destination, desired pickup time, and/or desired arrival time. Demand Responsive Transportation â Shared Vehicle DRT services (see previous definition) in which the vehicle is shared with one or more unrelated passenger trips. Denver Regional Transportation District (RTD) The Denver Regional Transportation District (RTD) is a government agency that provides bus, rail, and demand responsive public transit in the metropolitan Denver, CO region. This organization is a partner in the trip exchange discussed in Chapter 3. Discovery Data In this document, discovery data refers to datasets that describe potentially available transportation services to passengers. This differs from transactional data because it does not include all of the information necessary for a trip maker or a transportation service provider to book and schedule a specific trip. An example of discovery data for fixed route transit is General Transit Feed Specification (GTFS); an example for DRT services is GTFS-Flexible Transit (GTFS-flex). Dispatch In demand responsive transportation services, dispatch is the control process (human or virtual) that sends a vehicle to fulfill a trip and monitors vehicle operations. Extensible Markup Language (XML) The eXtensible Markup Language (XML) is textual data format that defines a set of rules for encoding documents in a format that is both machine- and human-readable. It is one of two commonly used formats (along with JSON) for exchanging data among applications. Extensible Markup Language Schema Definition (XSD) The eXtensible Markup Language Schema Definition (XSD) specifies how to formally describe elements in an XML document. In this document, the proposed transactional data specification uses XSD. Federal Transit Administration (FTA) The Federal Transit Administration (FTA) is an agency in the United States Department of Transportation (U.S. DOT) that provides technical and financial assistance to local public transportation systems. One of FTAâs responsibilities is to oversee the transit agenciesâ implementation of the U.S. DOT ADA regulations that require public transit agencies with fixed route transit service to provide ADA complementary paratransit service (a form of
91 resources to improve mobility services. In this Chapter 3 of this report, an MSAA project in the Denver region is discussed as an example. National Transit Database (NTD) The National Transit Database (NTD) is a federal reporting system in which transit agencies provide data on different aspects of transit operations to the FTA on a regular basis. Non-Emergency Medical Transportation (NEMT) Non-Emergency Medical Transportation (NEMT) refers to transportation service for individuals seeking medical care who are not in an emergency situation. The Medicaid program provides funding for NEMT services for eligible persons enrolled in Medicaid, and such services can include demand responsive services such as taxi trips and transportation provided by organizations operating wheelchair-accessible vehicles. Open Trip Planner (OTP) Open Trip Planner (OTP) is open source software project that provides passenger information and transportation analysis services. The core component provides trip itineraries combining transit, pedestrian, bicycle, and car segments and is built from OpenStreetMap and GTFS data. Paratransit Paratransit originally referred to all shared, flexible transportation services: intermediate between the private automobile and fixed route public transportation, including DRT services. In the United States, paratransit now commonly refers to DRT services for individuals with disabilities, elderly, and other riders with special needs. Passenger Name Record (PNR) Used by the airlines, the Passenger Name Record (PNR) refers to a data specification describing an airline passenger and their flight itinerary, including items such as the passengerâs name, flight number, and airline. Point-to-Point Data Communications In this document, point-to-point refers to data communications in which different parties (and their respective software systems) communicate directly with one another via an agreed upon protocol for data exchange. Provider (Transportation Provider) The provider refers to the operator of transportation services. This could be a taxi company, transportation network company, public agency, or other private or government-funded entity that provides demand responsive transportation services. Request for Proposals (RFP) A Request for Proposals (RFP) is a document set forth by an agency or company interested in procuring services or items. Potential service providers or suppliers can then respond to the solicitation with a business proposal.
92 Specification A specification is documented technical requirements generally considered working or business documents. Standard In this report, a standard refers to technical specifications that have been agreed upon by consensus or established by a neutral third party via a formal process or organizing body. SUTI Specification SUTI is a Swedish acronym that stands for âStandardiserat Utbyte av Trafik Information.â SUTI is a transactional data standard for demand-responsive transportation that is widely used in Scandinavia. Taxicab, Limousine & Paratransit Association (TLPA) The Taxicab, Limousine & Paratransit Association (TLPA) is a trade organization for providers of on-demand private passenger transportation services. This includes taxis, limousine services, airport shuttles, non-emergency medical transportation companies, ADA paratransit services, and other demand responsive services. Telegram For this transactional data specification, a telegram refers to a message that transmits data with a specific structure and wording (data elements). Transactional Data Transactional data are shared among two or more organizations in order to conduct some form of transaction. In the context of demand responsive transportation (DRT) services, transactional data include all of the information necessary for a transportation service provider to schedule and complete a specific DRT trip. Transportation Network Company (TNC) Transportation Network Companies (TNCs) are providers of ride-hailing (or ridesourcing) services. They typically arrange rides for customers via a smartphone application and a technology platform that connects riders and vehicle drivers. Use Case Use cases are commonly identified in software and systems engineering to define and organize system requirements. A use case is typically made up of a sequence or set of interactions to a particular goal. Validator For this transactional data specification, the term validator refers to a software tool that allows interested parties, such as DRT service providers, to test transactional data messages in the format of the proposed data specification to verify that the data messages are correctly formatted and to identify any issues associated with the data messageâs specification or implementation.
93 Vermont Agency of Transportation (VTrans) The Vermont Agency of Transportation (VTrans) is a government organization in the state of Vermont that is responsible for planning, constructing, and maintaining transportation infrastructure. VTrans is discussed in Chapter 3 of this report in an example of GTFS-flex.