Ryan Klock, David Owens, and Henry Schwartz 

Glenn Research Center, Cleveland, Ohio

Robert Plencner

Glenn Research Center, Cleveland, Ohio

Integrated Intermodal Passenger

Transportation System

NASA/TM—2012-217286

March 2012
NASA STI Program . . . in Profi le

Since its founding, NASA has been dedicated to the 

advancement of aeronautics and space science. The 

NASA Scientifi c and Technical Information (STI) 

program plays a key part in helping NASA maintain 

this important role.

The NASA STI Program operates under the auspices 

of the Agency Chief Information Offi cer. It collects, 

organizes, provides for archiving, and disseminates 

NASA’s STI. The NASA STI program provides access 

to the NASA Aeronautics and Space Database and 

its public interface, the NASA Technical Reports 

Server, thus providing one of the largest collections 

of aeronautical and space science STI in the world. 

Results are published in both non-NASA channels 

and by NASA in the NASA STI Report Series, which 

includes the following report types:

• TECHNICAL PUBLICATION. Reports of 

completed research or a major signifi cant phase 

of research that present the results of NASA 

programs and include extensive data or theoretical 

analysis. Includes compilations of signifi cant 

scientifi c and technical data and information 

deemed to be of continuing reference value. 

NASA counterpart of peer-reviewed formal 

professional papers but has less stringent 

limitations on manuscript length and extent of 

graphic presentations.

• TECHNICAL MEMORANDUM. Scientifi c 

and technical fi ndings that are preliminary or 

of specialized interest, e.g., quick release 

reports, working papers, and bibliographies that 

contain minimal annotation. Does not contain 

extensive analysis.

• CONTRACTOR REPORT. Scientifi c and 

technical fi ndings by NASA-sponsored 

contractors and grantees.

• CONFERENCE PUBLICATION. Collected 

papers from scientifi c and technical 

conferences, symposia, seminars, or other 

meetings sponsored or cosponsored by NASA.

• SPECIAL PUBLICATION. Scientifi c, 

technical, or historical information from 

NASA programs, projects, and missions, often 

concerned with subjects having substantial 

public interest.

• TECHNICAL TRANSLATION. Englishlanguage translations of foreign scientifi c and 

technical material pertinent to NASA’s mission.

Specialized services also include creating custom 

thesauri, building customized databases, organizing 

and publishing research results.

For more information about the NASA STI 

program, see the following:

• Access the NASA STI program home page at 

http://www.sti.nasa.gov

• E-mail your question via the Internet to help@

sti.nasa.gov

• Fax your question to the NASA STI Help Desk 

at 443–757–5803

• Telephone the NASA STI Help Desk at

 443–757–5802

• Write to:

 NASA Center for AeroSpace Information (CASI)

 7115 Standard Drive

 Hanover, MD 21076–1320
Ryan Klock, David Owens, and Henry Schwartz 

Glenn Research Center, Cleveland, Ohio

Robert Plencner

Glenn Research Center, Cleveland, Ohio

Integrated Intermodal Passenger

Transportation System

NASA/TM—2012-217286

March 2012

National Aeronautics and

Space Administration

Glenn Research Center

Cleveland, Ohio 44135
Acknowledgments

The authors would like to extend their thanks to Dennis Huff for his support and guidance throughout this project. The authors 

would also like to thank Justin Gray for teaching them how to program using Python and for helping them through all their 

code related issues. We appreciate the support of Dr. Ruben DelRosario and the Subsonic Fixed Wing project of

the Fundamental Aeronautics Program.

Available from

NASA Center for Aerospace Information

7115 Standard Drive

Hanover, MD 21076–1320

National Technical Information Service

5301 Shawnee Road

Alexandria, VA 22312

Available electronically at http://www.sti.nasa.gov

Trade names and trademarks are used in this report for identifi cation 

only. Their usage does not constitute an offi cial endorsement, 

either expressed or implied, by the National Aeronautics and 

Space Administration.

This work was sponsored by the Fundamental Aeronautics Program 

at the NASA Glenn Research Center.

Level of Review: This material has been technically reviewed by technical management. 

This report contains preliminary fi ndings, 

subject to revision as analysis proceeds.
NASA/TM—2012-217286 1 

Integrated Intermodal Passenger Transportation System 

Ryan Klock,1 David Owens,2 and Henry Schwartz3

National Aeronautics and Space Administration 

Glenn Research Center 

Cleveland, Ohio 44135 

Robert Plencner 

National Aeronautics and Space Administration 

Glenn Research Center 

Cleveland, Ohio 44135 

Abstract

Modern transportation consists of many unique modes of travel. Each of these modes and their 

respective industries has evolved independently over time, forming a largely incoherent and inefficient 

overall transportation system. Travelers today are forced to spend unnecessary time and efforts planning a 

trip through varying modes of travel each with their own scheduling, pricing, and services; causing many 

travelers to simply rely on their relatively inefficient and expensive personal automobile. This paper 

presents a demonstration program system to not only collect and format many different sources of trip 

planning information, but also combine these independent modes of travel in order to form optimal routes 

and itineraries of travel. The results of this system show a mean decrease in inter-city travel time of 

10 percent and a 25 percent reduction in carbon dioxide emissions over personal automobiles. 

Additionally, a 55 percent reduction in carbon dioxide emissions is observed for intra-city travel. A 

conclusion is that current resources are available, if somewhat hidden, to drastically improve point to 

point transportation in terms of time spent traveling, the cost of travel, and the ecological impact of a trip. 

Finally, future concepts are considered which could dramatically improve the interoperability and 

efficiency of the transportation infrastructure. 

Nomenclature 

API Application Programming Interface 

FAA Federal Aviation Administration 

GUI Graphical User Interface 

GPS Global Positioning System 

Introduction 

Public transportation around the United States is underutilized compared to other developed parts of 

the world. In Europe, public transportation accounts for over 50 percent of trips within large cities as 

opposed to about 20 percent in the United States (Ref. 1). As shown in Figure 1, westernized, nonEuropean countries often exhibit the largest percentage of personal automotive use. 

Instead the U.S. public utilizes personal automobiles as a primary means of transportation. Data from 

the Federal Highway Administration shows that traffic volumes have steadily increased over the past 

20 years. As traffic volumes increase, the impact on our environment increases as well. The 

Environmental Protection Agency estimates that the average U.S. passenger vehicle emits 5.5 metric 

 

1

NASA Glenn Research Center, summer intern, University of Michigan. 2

NASA Glenn Research Center, summer intern, Virginia Polytechnic Institute and State University. 3

NASA Glenn Research Center, summer intern, Georgia Institute of Technology.
NASA/TM—2012-217286 2 

Figure 1.—Average automotive use by country. Countries such as the United States, 

Australia, and Canada often maintain the highest percentage of personal automobile 

use per trips. European countries that focus more heavily on mass transportation 

maintain a lower percentage of automobile use per trip. Data range from 1994 to 2006.

tons of carbon dioxide annually (Ref. 2). One of the principle reasons for the reliance on the personal 

automobile is that all of the public transportation systems in the US have evolved independently creating 

an inefficient system that is cumbersome for the public to use. This has resulted in a cultural dependence 

on automobile travel. The solution proposed by this report involves developing a real time mobile 

application to bring together all of the dissociated information from the various transportation systems 

into to one easy to use program that will optimize point-to-point travel based on three metrics: the 

duration of the trip, the cost of the trip, and the carbon footprint associated with the trip. 

A demonstration program has been developed for travel between New York City and 

Washington D.C. to illustrate how a system like the one described could work. The demonstration 

program uses public transportation systems that are currently in use to optimize point-to-point travel 

based on three metrics and compared the results to a baseline. The baseline for the program is personal 

automotive travel. A detailed analysis of the results is discussed later in this report. This work points to 

the need for the availability of more travel information including schedules, delays, cost, and other 

variables that can be used by program applications to optimize travel. 

Current Examples 

There are many examples of attempts at a full intermodal journey planner. Some examples include 

Google Transit (Google Inc.), PlymGo (Futurate), and Rome2Rio (Rome2rio Pty Ltd). Google Transit 

uses a variety of modes of transportation, especially within major cities, to plan their journeys (Ref. 3). It 

has coverage throughout the world and since it is in beta testing, they are continually updating their 

information as more cities and services add themselves to the network. PlymGo is a service for the city of 

Plymouth, United Kingdom that compares the cost, time, and environmental impact of various modes of 

transportation from one point in the city to another (Ref. 4). It even includes the calories burned for 

modes such as walking and biking. Rome2Rio is the closest of the three to a complete intermodal journey 

planner in that it compares all modes of public transit; planes as well as limited trains and buses, and 

compares the time and cost between various routes calculated between two points (Ref. 5). 

 

0

10

20

30

40

50

60

70

80

90

100

Percent of Trips 
NASA/TM—2012-217286 3 

These are great services for what they can do, however, they all have limitations. One limitation that 

is common between them and all other journey planners is that people are for the most part unaware of 

these programs. Public awareness for planners such as these is low, especially outside major cities. Also, 

the number of websites, smart phone applications, and other forms of journey planners are growing but is 

nowhere near the level of automobile transportation. Additionally, they each have their own issues that 

prevent them from being complete world-wide intermodal journey planners. 

Google Transit does not have public transportation information for all cities, and is often limited in its 

calculations between major cities. It does not include air travel, nor does it include long distance bus 

routes through companies such as Greyhound (Greyhound Lines Inc.) or MegaBus (Stagecoach Group 

PLC). Also, it only accounts for travel time and does not consider any other metrics. Google Transit does 

not show the cost of the trip (or compare prices between different routes) nor does it show the carbon 

footprint of the various modes of transport. 

PlymGo is great in their metrics for comparison, but is limited to travel within the city of Plymouth. It 

also does not piece together routes, in that it will not tell a passenger to take a bus to a train station to 

finish the trip. Therefore, it is limited in its calculations. Rome2Rio compares flights all around the world; 

however, it does not do the same for ground public transportation. Currently its railway and bus route 

calculations are limited to Europe, China, and India. Like Google Transit, it also does not include a 

passenger’s carbon footprint into the comparisons. 

Another limitation for an intermodal journey planner is that there is an overabundance of information 

to handle. All around the world, flight, bus, train and other forms of transportation schedules are changing 

all the time to meet current demands. This adds an additional toll for journey planners in that they have to 

keep up with these changes in order to be accurate and useful. Another burden is adding real time data, 

such as GPS locations of buses and other similar vehicles. Handling all this information is challenging, 

which is why most intermodal planners are confined, like PlymGo, to a single city or region, where the 

scope is easier to manage. 

Another barrier is found in the airline companies themselves and their protection of flight 

information. Accessing this information tends to be expensive and complicated. This hinders competition 

and prevents new companies and agencies from flourishing. 

Metrics 

In order for an intermodal journey planner to be successful, it must provide the public with a readily 

available and easy to use interface that reports the desired information in a concise logical manner. One 

major complaint about public transportation is that is takes too long and too much time is spent idle. 

Another major factor for all modes of transportation is cost. Despite what people may claim, money will 

always be one of the major driving factors behind any decision, and transportation is no different. If using 

public transportation is not cost effective, people will not use it. 

The demonstration program is designed to optimize the desired travel route based on how long the 

traveler will spend en route to the destination, how much the trip will cost, and the environmental impact 

of the trip. The economic and temporal metrics were chosen because people want to arrive at their 

destination in the shortest amount of time for the least amount of money. The environmental impact was 

chosen as a third metric because society is becoming increasingly aware of their impact on the Earth and 

the possible long term repercussions that could result from over consumption of fossil fuels. 

The three metrics will be evaluated against a baseline of personal automotive travel within and 

between city centers. The user is able to select which metric is preferable. After the program evaluates the 

various possible transportation options against the baseline, it determines the best route according to the 

user’s preferences. 

The program makes a few assumptions when calculating the output values for each of the metrics. 

The duration of travel for automobiles is determined using Google Maps (Google Inc.) which uses the 

distance, speed limits, and real time traffic updates to estimate the travel time. The travel time while using 

public transportation is determined from the estimates given by the specific transportation agency’s 
NASA/TM—2012-217286 4 

schedule. If air travel is used as one of the modes of transportation, the program assumes that the user will 

arrive at the airport 90 min prior to the scheduled departure (Ref. 6). The program determines the cost of 

the trip based on the economic information provided by the various airline companies and internet sites 

for the different public transportation systems. The cost of driving in a car is based on the government per 

diem rate of 51 cents per mile which is given to employees if they use their own vehicle for travel 

(Ref. 7). This estimate is based on average costs for fuel, maintenance, and other costs associated with 

owning a car. 

The environmental impact of the travel route is measured in pounds of carbon dioxide emitted into 

the atmosphere per passenger mile. Emission data from actual travel routes was used to determine an 

average amount of carbon dioxide emitted per passenger mile. This estimate is then multiplied by the 

travel distance to get the total amount of carbon dioxide emitted. 

Demonstration Code 

The sample code that was developed is intended to demonstrate the functionality of an intermodal 

transportation system. The code only focuses on transportation systems that are currently available to the 

public. Many future transportation concepts are discussed later on in this report; however, the code does 

not utilize any of these concepts because the goal was to demonstrate a fully functioning program for the 

regions that were chosen. Creating the code based on current transportation systems allows the use of 

existing information available on the internet such as routes and schedules for air travel between cities. 

Thus the code is a true representation of a potential final product. 

The cities chosen for the demonstration were New York City and Washington D.C. They were used 

because both have well developed public transportation systems, the distance between them is such that 

either driving or flying could be viable options depending on the user’s preferences, and both have 

significant traffic problems. Another reason for choosing these cities is that their public transportation 

systems have web based applications that allow computer programs to easily access real time information 

such as schedules, costs, and delays. Airlines, on the other hand, are lagging behind other forms of public 

transportation when it comes to openly sharing information over the internet. This could be partly due to 

security concerns. To mitigate this shortcoming, the research team constructed a statistical model of flight 

times, costs, and delays to emulate air travel. The emulator can be easily replaced with a true flight 

module once airlines are willing to make their information available. 

This ease of modification is due to the demonstration code’s object oriented architecture. Object 

oriented programming is a style of thought process where algorithms are arranged into self contained 

modules that each, independently, perform a task resulting in a particular output based on inputs. The user 

of a module does not need to understand how or why the particular module operates, but only how to 

interact with the module. These independent modules are then assembled in sequence to perform a task 

that is much more complex than the tasks performed individually. Additionally, these modules are not 

dedicated to one particular system. They may each be used in other system assemblies that perform 

different functions. 

For the demonstration system, object oriented programming offered the ability to easily integrate 

future classes of modes of transportation as well as update current classes of modes without the need to 

alter the operation of the other classes. To meet these criteria, the programming language of Python 2.6.6

(Python Software Foundation) was used. The object oriented architecture is made more apparent by the 

system architecture shown in Figure 2. 

The three data parsing modules near the right represent the three current modes of transportation 

considered by the system. The flight data parser collects information on available flights between cities 

based on the routing information given by the route caller. Similarly, the automotive data parser collects 

information for driving routes. The public data parser considers resources already available through the 

internet. Namely, a service provided by Jeppesen Land Application Programming Interface (API) 

(Jeppesen Sanderson Inc.) that has taken public busing, light rail, subway, and water ferries into account 

(Ref. 8). Each one of these modules may be exchanged for a different data parser of the same name and 
NASA/TM—2012-217286 5 

Figure 2.—A flowchart of the demonstration code process and modules. Each object in the flowchart relates to an 

independent program. Arrows represent the flow of information between the programs. Note that no global 

variables are used and that all data was exchanged on a one to one basis. Module programs only receive access 

to data necessary for their task. 

interface, without disrupting any of the other modules. Additionally, other modules may be added to the 

existing three to allow expanded functionality for new or updated modes of transportation. The only 

alteration needed would be to the route caller module to reference the new modules. The route caller 

automatically detects a new transit module when it is introduced and requested by the module manager. It 

then prompts the user that the router module may be out of date and require attention. 

The module management provides the basic user interface and general structuring of the class 

instances to perform the route optimization. Currently, the inter-modal demonstration system utilizes a 

simple, text based, input output interface. This may later be replaced by a graphical user interface (GUI) 

to improve user friendliness and appeal to the general public. 

Results 

After a sample set of 108 routes between 16 randomly chosen locations in each city, several trends 

became apparent. All routing information generated by the demonstration system was compared against 

the baseline of traveling along the fastest route, from Google Maps, by personal automobile. When 

performing inter-city travel, by optimizing for time, the sample code most frequently selected a route 

consisting of driving to the nearest airport, purchasing a flight to the destination city, and then renting a 

car or carpooling to the final destination. With this combination, there was a mean time savings of 

10 percent and a mean carbon emissions reduction of 19 percent. As the distance between the destination 

and departure cities increase, these values are expected to increase since the major time and carbon 

emission reduction is experienced during air travel. Therefore increasing the utilization of air travel will 

emphasize its time and emission saving effects. 

When optimizing a similar route for ecological impact, the mean carbon emissions could be reduced 

up to 25 percent, however a significant time penalty of between –73 and –83 percent was observed. A 

summary of the relevant observations is shown in Table 1. 

Notice that there was no improvement in cost optimization for any metrics. This is because the 

intermodal system almost always determined that driving individually was the least expensive option. As 

previously explained, this was due to the system only considering the cost of travel alone. This also 

means that the poor cost improvement metrics for time and carbon emissions optimization may not 

actually be representative of costly intermodal routes. 
NASA/TM—2012-217286 6 

TABLE 1.—MEAN OBSERVED IMPROVEMENT FOR INTER-CITY TRAVEL 

Optimizing for... Cost, 

percent 

Time, 

percent 

Carbon emission, 

percent 

Minimum travel time –24 10 19 

Minimum trip cost 0 0 0 

Minimum carbon emissions –27 –73 25 

All values listed are percent improvements over the baseline case of driving similar routes purely by 

personal automobile. Negative values are representative of the demonstration system not outputting a 

route that improved upon the baseline. Values of 0 are representative of automotive travel proving optimal 

for the preferred metric. 

TABLE 2.—MEAN OBSERVED IMPROVEMENT FOR INTRA-CITY TRAVEL 

Optimizing for... Cost, 

percent 

Time, 

percent 

Carbon emission, 

percent 

Minimum travel time 0 0 0 

Minimum trip cost 45 –181 55 

Minimum carbon emissions 45 –181 55 

When performing intra-city travel and optimizing for ecological impact, the sample code always 

selected a route consisting of one or more legs of public transportation and displayed a mean carbon 

emission reduction of 55 percent over automotive travel. Also shown in Table 2, the sample code 

predicted a 45 percent reduction in travel cost. While optimizing for time, the sample code revealed that 

personal automotive travel was almost always the best option. 

Assumptions 

During the assembly of the demonstration code several assumptions were made in the interest of time, 

but can be easily modified to improve accuracy. The most relevant assumptions are outlined below. 

There is a flat 90 min wait time whenever the traveler employs air travel. This assumption is based on 

the current Federal Aviation Administration (FAA) recommendation to account for baggage check, ticket 

retrieval, security checks, and baggage claim (Ref. 6). Future iterations of the demonstration code, or an 

updated air data parser module, may provide real time information of wait times at various airports via 

information provided by the FAA delay time watcher located on their website. 

Carbon emissions are based on United States national averages of pounds of carbon dioxide per 

passenger mile for various modes of transportation (Ref. 9). Future revisions on the demonstration 

program could include actual emissions from the user’s vehicle. Additionally, since flights may be placed 

into holding patterns or rerouted due to weather, air travel emissions are based on “as the crow flies” 

distances summed with an additional 30 miles of departure and approach flight distance. Also, the sample 

code may instruct the user to walk if the routing distance does not exceed 1.25 miles (Ref. 10). Carbon 

emissions caused by human respiration are considered negligible compared to mechanized travel and are 

therefore disregarded. 

The sample code relies primarily upon the free information services of Google Maps and Jeppesen 

Land API for travel data collection. Both of these companies publish APIs online to distribute their 

information in a standardized form. However, both of these companies are continually updating and 

refining their information. This may lead to a change in their respective information publishing formats 

sometime in the future. The sample code has built in redundancies to first compensate for any changes in 

the API information formats, and when unable to compensate, alerts the user to the possibility that the 

sample code has fallen out of date and may need alterations or module replacement to continue operation. 

Special deals and travel rates are not considered in the sample code. Items such as promotional 

vouchers, senior or infant discounts, and/or frequent flier mileage are unique and specific to a particular 

traveler. Such items may be entered into the user interface in future iterations of the intermodal system, 

but were not considered. 
NASA/TM—2012-217286 7 

Comparison to Current Systems 

A comparison of the code with current intermodal public transportation journey planners was 

necessary to assess the validity of the results and viability of the demonstration code. 

The demonstration code compares routes based on three metrics; time, cost and environmental impact. 

This is similar to PlymGo; however, the demonstration code has the advantage of including more than one 

city and also compares routes that use a variety of modes of transport. The code could potentially show that 

a route that uses a subway, an airplane, and a metro bus to be the most environmentally friendly trip 

possible. PlymGo is limited to trips by only one method of transportation (Ref. 4).

Airlines tend to restrict access to their flight information until the point of sale. This poses a problem 

for our demonstration intermodal journey system which attempts to query the flight data for free and 

format it in a simple manner. To mitigate this, the code emulates airplane travel between John F. Kennedy 

International Airport in New York City and Dulles International Airport near Washington D.C. based on 

research conducted. Rome2Rio does include flight planning and compares numerous airlines. 

The demonstration code uses Jeppesen Land API to calculate the public transit routes within certain 

cities. As with most public transit journey planners, Jeppesen Land API has a limited data range (Ref. 8). 

It can only handle a few cities, but the number of cities included in its calculation is projected to grow in 

the future. As of now, it also only includes services within a city’s boundaries. For instance, Dulles 

International Airport is outside Jeppesen’s boundary for Washington D.C. Therefore, an emulation 

module was included into the demonstration code to get the passenger from Dulles Airport to 

Washington D.C. and back. This was done by using the time of the trip with the airport shuttle time table. 

As the range of Jeppesen’s calculations expands, this emulation will become unnecessary (Ref. 8).

In order for the demonstration code to become more user friendly, a GUI is desired. The code, as of 

now, runs through a simple command prompt, but future versions and updates could allow it to be 

accessed through a website with buttons, scroll bars and other items that can help future travelers choose 

their routes and destinations easier. With no interface, the demonstration code falls far behind Google 

Transit, PlymGo and Rome2Rio in terms of user friendliness and usability. Other aspects missing from 

the demonstration code, such as route calculation for multiple passengers, can be added to update the code 

easily due to the object oriented nature of the code. 

Future Concepts 

Current social trends have led the information technology market to a state of hyper community. That 

is, personal and commercial information has become increasingly available for retrieval without 

significant cost to the searcher. To that end, several future attributes that may be added to the inter-modal 

transportation system have been considered. 

Current and future technologies offer increased access to real-time information while en route along 

an intermodal trip. Services such as Google Transit have already begun to collect information concerning 

traffic conditions, weather, construction, and public transit schedules and publishing them to the web via 

interactive GUIs and online APIs for little to no fee (Ref. 3). This information, coupled with user specific 

information gathered by personal smart phones and accessed portably through cellular service providers, 

could allow users of the inter-modal system to receive updated trip information en route in order to 

further optimize both individual and overall system performance. 

Consider the following hypothetical scenario. An airline flight is approaching its destination. On 

board are several dozen users of the intermodal system who have already searched for and scheduled their 

individual trips which include their current flight. In the destination city is a cab or bus service that has 

access to the arrival times of the intermodal system users. Upon noting that a large number of passengers 

will soon be arriving, the cab or bus service dispatches the appropriate number of vehicles to receive the 

passengers. Having known the proper number of vehicles to dispatch, the cab or bus service is able to 

maximize profit while minimizing losses due to underutilization. Furthermore, the users of the intermodal system experience little to no layover time while waiting for an empty cab or bus to arrive, along 
NASA/TM—2012-217286 8 

with knowing the exact fare that will be required. An automated billing system is could be developed that 

tracks the actual route and submits payment through the smart phone. This reduces a common anxiety for 

travelers using public transportation systems (in terms of knowing how much to pay and the payment 

method). In this situation, the sharing of information played to the benefit of all parties involved and 

maximized the productivity of the system. 

The various aspects of the above scenario have not been overlooked by today’s transit services. Cities 

such as New York, London, and Plymouth have already implemented services to provide open 

information about the current state of public transportation systems in their respective jurisdictions. Open 

information meaning the free and easily accessible release of documentation to the general public. Each 

city has noted an increase in utilization of their public transit services since opening their information to 

the public, for instance London has seen a 65 percent increase in their bus usage alone (Ref. 11). As 

mentioned earlier, airline service providers have not kept pace. That is not to say that it is impossible to 

directly compare flights, but current providers of such services often charge a fee and do not openly 

distribute their information. 

One near term concept not included in the sample code that may be added is the concept of the next 

generation airspace system (NextGen). NextGen is the fundamental restructuring of the national airspace 

system to alleviate costs, delays, and the environmental impact while allowing for significant growth of 

the aviation industry (Ref. 12). Updating the national airspace system is crucial in order to sustain the 

expected growth rate of the aviation industry. Boeing, Airbus, and the FAA all predict the number of 

aircraft to nearly double in the next twenty years (Refs. 13 to 15). Many of the changes involve providing 

greater situational awareness through improved technology as well as streamlining aircraft ground 

operations and traffic patterns. The FAA predicts that by 2018 NextGen will reduce delays by 35 percent 

saving an estimated 1.4 billion gallons of aviation fuel and reduce carbon dioxide emissions by 14 million 

English tons (Ref. 12). 

Another proven technique to develop public transportation is open source information. Many public 

transit companies and agencies believe it is their responsibility to provide their routes and information to 

the public. However, due to lack of funding or bureaucracy, this tends to produce difficult to use 

interfaces and formats. If an agency were to simply provide the information, instead of attempting to 

format it themselves, third party developers could then use and manipulate it to make it easier for the 

public to use, at no cost to the agency. Third party developers can be more efficient and by open sourcing, 

agencies allow many more developers work with the data than they could provide themselves. 

An example case of open sourcing in action is through the Massachusetts Department of 

Transportation. In 2009 they open sourced their information and within days, there were numerous 

websites, applications and phone services. Within weeks, there were just as many different smart phone 

applications and other methods of providing public transit information to the populous (Ref. 16). One of 

these involved electronic signs above stores along bus routes. The signs showed when the bus would 

arrive at the nearest bus stop using real time data. Instead of waiting at the bus stop, a traveler can spend 

their time at a store or someplace more comfortable and still not miss their bus. The end result was better 

for the community. The Massachusetts Department of Transportation got their information out to the 

public at no cost and the public now has a large variety of ways to plan their trips by public 

transportation. 

It has been shown above that there are many benefits to sharing information openly; on the other hand 

there are some serious risks as well. Knowing specific details about the time and location of public 

transportation systems has shown to be quintessential to increasing the public use of intermodal 

transportation. However, releasing this information to the public poses a serious security threat. Terrorist 

organizations could use this information to carry out their attacks more effectively. This is one of the 

major issues the team was not able to explore and is beyond the scope of this study. Security must be 

considered if a wide spread intermodal transportation system is going to be implemented in the future. 

Another difficult aspect will be to encourage cooperation between the various transportation 

companies and agencies. In this competitive market, showing favoritism to one company or another 

would be tempting, but cannot be tolerated in order to achieve optimal routes and modes of travel. An 
NASA/TM—2012-217286 9 

example of a competitive market system like this working together would be Transport for London. 

Transport for London is a government service that contracts with many bus, subway, and other 

transportation mode companies in order to provide one all encompassing service (Ref. 17). This allows 

for Transport for London to issue one ticket that is good for all the different transportation modes within 

the city and allows the passenger to travel from one point to another easily and efficiently. 

Several future modes of transportation were also considered for future implementation into an 

integrated intermodal transportation system. Among these future concepts was the proposed United States 

high speed rail network. This new rail network would include renovating and rating much of the current 

United States rail network for high speed travel as well as creating several new lines between many of the 

east coast cities (Ref. 18). Addition of this improved rail network could be manifested in the 

demonstration code through two unique forms. Firstly, the public transportation API provider, namely 

Jeppesen Land API, may choose to update their data base. In which case, no modification to the 

demonstration code would be required. The code would simply handle the new route of travel as a fast 

train and would process the various route schedules accordingly. Secondly, a new data parser module 

could be introduced to the demonstration code. This would require a third party programmer with 

knowledge of the demonstration code interfacing protocol to create a new module to collect the high 

speed rail information from the internet. This module would then be introduced to the demonstration 

program, at which point the router module would prompt the user that a new mode of transit is attempting 

to integrate into the system and provide instructions on where and how to modify the router module to 

accept this new transit mode. 

Another future mode of travel considered was the notion of a point to point sky taxi (Ref. 19). This 

mode of transportation would consist of an on demand fleet of high lift vehicles that would be approved 

for landing and takeoff nearly everywhere; providing the same function of a traditional taxi service but 

with superior speed and range. As with the addition of a high speed rail network, there are two methods 

with which to incorporate this new mode of travel. Whether the sky taxi mode of travel falls under one of 

the current data parser jurisdictions, or a new data parser module is required, the process is exactly the 

same. Regardless of the technical details of any new method of transportation, only the information 

relating cost, time, and emissions is required by the demonstration code to provide an optimized route for 

the user. 

Consideration of the relative safety of various modes of travel may be implemented in any future 

iteration of the demonstration program. Personal automobiles are the single most fatal mode of 

transportation for the general populous (Ref. 20). A metric of safety could be added to the current travel 

metrics of cost, time, and environmental impact to provide the user with still more options of preference 

when planning their intermodal journey. Furthermore, application of the demonstration program to 

personal mobile devices could warn travelers of upcoming danger or delay, as described in the following 

scenario. 

Once again, consider that several users of the integrated intermodal transportation system are 

traveling along similar routes, each of which directs their respective users along a particular highway. 

Additionally, several of the users are carrying personal mobile devices which are providing turn by turn 

directions. An accident occurs and a traffic jam quickly forms. The mobile device of the intermodal 

system user nearest the accident detects that the user has either stopped or fallen behind the intended 

routing schedule by monitoring their current GPS location. The intermodal system installed on the now 

delayed traveler relays to all other intermodal systems that there is a potential problem at its location and 

that consideration should be made in order to reroute other travelers around the newly formed traffic 

congestion. Additionally, the local police and news reporting agencies may have access to the integrated 

intermodal system information and may now provide the appropriate services to more quickly mitigate 

the dilemma; whether that is to dispatch law enforcement to reroute traffic or report to the general public 

about the current traffic condition. Alternatively, users who witness a traffic accident, backup, or other 

travel delay may enter the information manually to notify other intermodal systems and travelers of the 

potential setback. 
NASA/TM—2012-217286 10 

Conclusion 

The results from the demonstration code show that using public transportation can have a huge impact 

on the amount of carbon dioxide released into the environment during each trip. Also, even with the large 

wait times that go along with them, flights can save a passenger’s time and reduce their environmental 

impact. The only metric that public transit could not overcome was that of cost, but the demonstration 

code written for this study does not explicitly include other costs associated with automobiles, such as 

parking, insurance, and any maintenance. Instead the demonstration code only considers a flat $0.51/mile 

expense, which may not necessarily represent every personal vehicle. Another aspect of the 

demonstration code that is important for future additions and modifications is its object oriented 

architecture. 

There are a variety of ways to improve upon the public transportation system and how to increase 

public awareness. One method is through future public transportation concepts such as sky taxi, high 

speed rail and NextGen (Refs. 12, 18, and 19). These can help to reduce congestion both on the ground 

and in the air and allow for easier transportation from start to finish. Increasing public awareness can be 

done by agencies and companies releasing their bus, train, and airline information to third party 

developers, who can then provide a variety of ways for the public to connect with public transit. 

If future companies and agencies allow for open sourced information, the only remaining challenge is 

to overcome the vast amount of dynamic data available. Future developments will only increase the 

amount of information accessible to the public. Improvements will allow for a single program or series of 

programs to be able to handle any kind of public transportation from one point to another anywhere in the 

world. The demonstration code reveals the promise of faster, cleaner, and potentially cheaper intermodal 

transportation for everyone. 
NASA/TM—2012-217286 11 

Appendix A.—Sample Inter-City Route Output 

========== Welcome to the Integrated Intermodal System ===================== 

Please enter the following information to begin your trip: 

DestinLoc,DepartLoc,DepartDate,DepartTime,Priority (str,str,[dd,mm,yyyy],[hh,mm],str):'21st St NW 

and R St NW, Washington DC','W 109th St and Broadway, New York, NY',[5,8,2011],[10,38],'eco' 

================================================================= 

Please standby while we calculate your solution. 

================================================================= 

Destination Lat: 38.912609 Lon: -77.046624 

Departure Lat: 40.803603 Lon: -73.9672251 

Departure date/time accepted. 

================================================================= 

Baseline Automotive Statistics: 

Cost: 118.64 dollars 

Time: 16283 seconds 

Emissions: 226 pounds 

================================================================= 

Optimum modes: Public-Plane-Public 

Cost: 151.50 dollars 

Time: 42180 seconds 

Emissions: 171 pounds 

Route: 

 1.) Head northwest on W 109th St toward Riverside Dr 

 2.) Turn right onto Riverside Dr 

 3.) Take the 1st right onto W 110th St Cathedral Pkwy 

 4.) Cathedral Pkwy depart at 10:38 -> Times Sq - 42 St arrive at 10:51 13 mins 

 5.) Metro | SOUTH FERRY | Route: 1 Broadway - 7 Avenue Local | Provider: MTA New York City 

Transit 

 6.) Times Sq - 42 St -> 42 St - Port Authority Bus Terminal Walk 5 mins 

 7.) 42 St - Port Authority Bus Terminal depart at 10:57 -> Euclid Av arrive at 11:30 33 mins 

 8.) Metro | OZONE PARK - LEFFERTS BLVD | Route: A 8 Avenue Express | Provider: MTA New 

York City Transit 

 9.) Head south on Euclid Ave toward Pitkin Ave 

 Destination will be on the right 

 10.) EUCLID AV - PITKIN AV depart at 11:36 -> BROOKLYN - GENERAL P.O. arrive at 11:46 

10 mins 

 11.) Bus | B13 SPRING CREEK GATEWAY MALL | Route: B13 CRESCENT STREET | Provider: 

MTA New York City Transit 

 12.) BROOKLYN - GENERAL P.O. depart at 11:57 -> INNER TERM - STOP 4C INTL ARRIVAL 

arrive at 12:16 19 mins 

 13.) Bus | B15 JFK AIRPORT via POSTAL FAC | Route: B15 NEW LOTS AV - JFK AIRPOR | 

Provider: MTA New York City Transit 

 14.) Head northeast toward Van Wyck Expy 

 15.) Slight left 

 16.) Take the ramp 

 17.) Slight left 

 Destination will be on the right 

 18.) Board flight 16546 departing at 14:29 
NASA/TM—2012-217286 12 

 19.) Arrive at 16:0 

 20.) Dulles Airport depart at 5:50 -> SW D ST & SW 7TH ST arrive at 6:37 0 hours and 47 mins 

 21.) Head east on D St SW toward 7th St SW 

 Destination will be on the left 

 22.) L'ENFANT PLAZA METRO STATION depart at 17:19 -> METRO CENTER METRO 

STATION arrive at 17:24 5 mins 

 23.) Metro | FRANCONIA METRO | Route: Blue Metrorail Blue Line | Provider: METRO 

 24.) METRO CENTER METRO STATION depart at 17:29 -> DUPONT CIRCLE METRO 

STATION arrive at 17:34 5 mins 

 25.) Metro | GROSVENOR | Route: Red Metrorail Red Line | Provider: METRO 

 26.) Head southeast on Connecticut Ave NW 

 27.) At the traffic circle, take the 1st exit onto Massachusetts Ave NW 

 28.) Turn right onto Florida Ave NW 

 29.) Sharp right onto 21st St NW 

 30.) Head east on D St SW toward 7th St SW 

 Destination will be on the left 

 31.) L'ENFANT PLAZA METRO STATION depart at 10:41 -> METRO CENTER METRO 

STATION arrive at 10:46 5 mins 

 32.) Metro | VIENNA | Route: Orange Metrorail Orange Line | Provider: METRO 

 33.) METRO CENTER METRO STATION depart at 10:55 -> DUPONT CIRCLE METRO 

STATION arrive at 10:57 2 mins 

 34.) Metro | SHADY GROVE | Route: Red Metrorail Red Line | Provider: METRO 

 35.) Head southeast on Connecticut Ave NW 

 36.) At the traffic circle, take the 1st exit onto Massachusetts Ave NW 

 37.) Turn right onto Florida Ave NW 

 38.) Sharp right onto 21st St NW 
NASA/TM—2012-217286 13 

Appendix B.—Sample Intra-City Route Output 

========== Welcome to the Integrated Intermodal System ====================== 

Please enter the following information to begin your trip: 

DestinLoc,DepartLoc,DepartDate,DepartTime,Priority (str,str,[dd,mm,yyyy],[hh,mm],str):'H St NW 

and 20th St NW, Washington DC','4th St NW and Jefferson Dr SW, Washington 

DC',[5,8,2011],[10,37],'eco' 

================================================================= 

Please standby while we calculate your solution. 

================================================================= 

Destination Lat: 38.8995739 Lon: -77.0448869 

Departure Lat: 38.888793 Lon: -77.0175553 

Departure date/time accepted. 

================================================================= 

Baseline Automotive Statistics: 

Cost: 1.16 dollars 

Time: 659 seconds 

Emissions: 2 pounds 

================================================================= 

Optimum modes: Public 

Cost: 2.50 dollars 

Time: 1620 seconds 

Emissions: 1 pounds 

Route: 

 1.) Head south on 4th St SW toward Independence Ave SW 

 2.) Take the 3rd left onto D St SW 

 Destination will be on the right 

 3.) FEDERAL CENTER METRO STATION depart at 10:45 -> FARRAGUT WEST METRO 

STATION arrive at 10:53 8 mins 

 4.) Metro | FRANCONIA METRO | Route: Blue Metrorail Blue Line | Provider: METRO 

 5.) Head south on 17th St NW toward I St NW 

 6.) Turn right onto Pennsylvania Ave NW 

 7.) Turn left onto 19th St NW 

 8.) Take the 1st right onto H St NW 

 9.) Take the 1st right onto 20th St NW 

 Destination will be on the left 
NASA/TM—2012-217286 14 

References 

1. European Metropolitan Transportation Authorities, “EMTA Barometer of Public Transport in the 

European Metropolitan Areas,” EMTA, Paris, France, Dec. 2004. 

2. U.S. Environmental Protection Agency, “Emission Facts: Greenhouse Gas Emissions from a 

Typical Passenger Vehicle,” Office of Transportation and Air Quality, EPA420-F-05-004, 

Washington, D.C., 2005. 

3. Google Transit, Beta, Google Corporation, Mountain View, California, 2011. 

4. PlymGo.com, Plymouth City Council, Plymouth, Devon, United Kingdom, 2011. 

5. Cameron, M., and Tschirren, B., Rome2Rio.com, Beta, Melbourne, Australia, Apr. 2011. 

6. Transportation Safety Administration, U.S. Department of Homeland Security, 

www.tsa.gov/travelers/airtravel/assistant/arrival.shtm, 4 Aug. 2011. 

7. U.S. General Services Administration, www.gsa.gov/portal/content/100715, 4 Aug. 2011. 

8. Jeppesen, A Boeing Company, www.jeppesen.com/land/journey-planning/, 4 Aug. 2011. 

9. M.J. Bradley & Associates, “Comparison of Energy Use & CO2 Emissions From Different 

Transportation Modes,” Manchester, New Hampshire, May 2007. 

10. Jeppesen, “Jeppesen Journey Planner Interface Overview – REST Protocol,” Perth, Australia, Jun. 

2011. 

11. Edwards, T., British Broadcasting Corporation, “Public transport in London: A decade in numbers,” 

BBC News London, www.bbc.co.uk/blogs/mindthegap/2011/01/public_transport 

_in_london_a_d.html, 4 Aug. 2011. 

12. Federal Aviation Administration, “FAA’s NextGen Implementation Plan,” U.S. Department of 

Transportation, Mar. 2011. 

13. Boeing Management Company, “Current Market Outlook 2011-2030,” Boeing, Jun. 2011. 

14. Leahy, J., “Airbus Global Market Forecast 2010-2029,” Airbus, Toulouse, France, 13 Dec. 2010. 

15. Federal Aviation Administration, “FAA Aerospace Forecast Fiscal Years 2011-2031,” U.S. 

Department of Transportation, Apr. 2011. 

16. Chernoff, M., “Where’s my bus? Open data enables real-time route info for Boston riders,” 

OpenSource.com, Red Hat Inc., opensource.com/government/10/6/wheres-my-bus-open-dataenables-real-time-route-info-boston-riders, 3 Jun. 2010. 

17. Transport for London, United Kingdom Government, www.tfl.gov.uk, 4 Aug. 2011. 

18. U.S. High Speed Rail Association, “US High Speed Rail Network Map,” US HSR, 

www.ushsr.com/ushsrmap.html, 10 Aug. 2011. 

19. BlueSkyTaxi.com, BlueSky Taxi, Inc. blueskytaxi.com, 10 Aug. 2011. 

20. Halperin. K., “A Comparative Analysis of Six Methods for Calculating Travel Fatality Risk,” 

Franklin Pierce Law Center, law.unh.edu/risk/winter/halperin.htm, 10 Aug. 2011. 
REPORT DOCUMENTATION PAGE Form Approved 

OMB No. 0704-0188 

The public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the 

data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this 

burden, to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports (0704-0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302. 

Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB 

control number. 

PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS. 

1. REPORT DATE (DD-MM-YYYY)

01-03-2012 

2. REPORT TYPE

Technical Memorandum 

3. DATES COVERED (From - To)

4. TITLE AND SUBTITLE

Integrated Intermodal Passenger Transportation System 

5a. CONTRACT NUMBER

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S)

Klock, Ryan; Owens, David; Schwartz, Henry; Plencner, Robert 

5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

WBS 561581.02.08.03.11.01 

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

National Aeronautics and Space Administration 

John H. Glenn Research Center at Lewis Field 

Cleveland, Ohio 44135-3191 

8. PERFORMING ORGANIZATION

 REPORT NUMBER

E-18041 

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)

National Aeronautics and Space Administration 

Washington, DC 20546-0001 

10. SPONSORING/MONITOR'S

 ACRONYM(S)

NASA 

11. SPONSORING/MONITORING

 REPORT NUMBER

NASA/TM-2012-217286 

12. DISTRIBUTION/AVAILABILITY STATEMENT

Unclassified-Unlimited 

Subject Categories: 85 and 03 

Available electronically at http://www.sti.nasa.gov 

This publication is available from the NASA Center for AeroSpace Information, 443-757-5802

13. SUPPLEMENTARY NOTES

Ryan Klock, University of Michigan; David Owens, Virginia Polytechnic Institute and State University; and Henry Schwartz, Georgia 

Institute of Technology, summer interns. 

14. ABSTRACT

Modern transportation consists of many unique modes of travel. Each of these modes and their respective industries has evolved 

independently over time, forming a largely incoherent and inefficient overall transportation system. Travelers today are forced to spend 

unnecessary time and efforts planning a trip through varying modes of travel each with their own scheduling, pricing, and services; causing 

many travelers to simply rely on their relatively inefficient and expensive personal automobile. This paper presents a demonstration program 

system to not only collect and format many different sources of trip planning information, but also combine these independent modes of 

travel in order to form optimal routes and itineraries of travel. The results of this system show a mean decrease in inter-city travel time of 10 

percent and a 25 percent reduction in carbon dioxide emissions over personal automobiles. Additionally, a 55 percent reduction in carbon 

dioxide emissions is observed for intra-city travel. A conclusion is that current resources are available, if somewhat hidden, to drastically 

improve point to point transportation in terms of time spent traveling, the cost of travel, and the ecological impact of a trip. Finally, future 

concepts are considered which could dramatically improve the interoperability and efficiency of the transportation infrastructure.

15. SUBJECT TERMS

Transportation; Transportation networks; Air transportation; Urban transportation; Information systems; Traffic; Costs; Carbon 

dioxide; Interoperability; Economic impact; Efficiency; Routes 

16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF

 ABSTRACT

UU 

18. NUMBER

 OF 

 PAGES

20 

19a. NAME OF RESPONSIBLE PERSON

STI Help Desk (email:help@sti.nasa.gov) 

a. REPORT

U 

b. ABSTRACT

U 

c. THIS 

PAGE

U 

19b. TELEPHONE NUMBER (include area code)

443-757-5802 

Standard Form 298 (Rev. 8-98)

Prescribed by ANSI Std. Z39-18