Return to Reports page
PDF version (1.44 MB)
Office of Planning
Federal Highway Administration
U.S. Department of Transportation
Organizational Performance Division
John A. Volpe National Transportation Systems Center
Research and Innovative Technology Administration
U.S. Department of Transportation
The U.S. Department of Transportation John A. Volpe National Transportation Systems Center (Volpe Center) in Cambridge, Massachusetts prepared this report for the Federal Highway Administration's (FHWA) Office of Planning. The project team included Alisa Fine and Paige Colton, both of the Volpe Center's Organizational Performance Division, and Jaimye Bartak of Cambridge Systematics.
The Volpe Center project team wishes to thank the staff members from several organizations nationwide, listed in Appendix A, for providing their experiences, insights, and editorial review. The time they kindly provided was vital to preparing the case studies and reviewing this final report.
Public agencies are increasingly turning to cloud technology to help streamline workflows and allow data sharing among a broader audience. In particular, transportation agencies are beginning to use cloud computing to more easily store, manage, manipulate, analyze, and share geospatial data and business information. Cloud technology can replace traditional data-sharing mechanisms such as File Transfer Protocol (FTP) sites by displaying data in an interactive manner. Even modest efforts to use cloud technology have led agencies to ask fundamental questions about how transportation agencies will conduct business in the future.
Great potential exists in using cloud technologies to support GIS applications, but their use is still evolving. To explore this in more depth, the Federal Highway Administration (FHWA) and Volpe National Transportation Systems Center (Volpe Center) interviewed selected agencies and developed case study reports that document these agencies' GIS and cloud computing initiatives. FHWA also sponsored a peer exchange that brought participating agencies together to discuss their experiences in greater detail. The resulting case studies presented here include:
This report is expected to support GIS practitioners and decisionmakers to identify examples of noteworthy practices, consider the pros and cons of using cloud technologies for GIS applications, and determine how cloud technology can be best used to support their own business practices.
The majority of the participating agencies are still in the early stages of determining how they can most effectively use the cloud in their GIS activities; all are planning to expand their use of the cloud to serve additional business needs of their organizations. The agencies have explored a variety of cloud deployment models and have generally come to prefer off-the-shelf or third-party platforms over developing applications with original or customized code.
These initial efforts have yielded significant and sometimes unexpected benefits to the agencies' GIS activities, business operations, and partnerships. The cloud has increased the user base and impact of spatial data and reduced the time and costs associated with managing and displaying GIS data. Agencies have also been able to foster and strengthen multi-agency collaboration and partnerships, and enhance their interactions with the public.
As transportation agencies have begun to encounter challenges with implementing cloud technologies related to data security, procurement policies, and leadership support, they have started reconsidering the role and purpose of information technology systems and security; data storage, maintenance, and collection; and how to add value to geospatial data and visualization. As they experience successes and lessons learned in these areas, and as technology rapidly advances alongside their progress, agencies believe that cloud computing is destined to greatly influence the way that transportation agencies conduct their business in the future in terms of efficiency, transparency, and cost-effectiveness.
For many years, access to databases, networks, web services, and various other computing resources at public transportation agencies was largely limited to transportation agency staff. As computing technologies have evolved, the term “cloud computing,” commonly referred to as “the cloud,” has emerged to describe a way of linking these resources via the Internet to provide information to both internal and external users. More than simply a way to exchange information, the cloud also enables agencies to share processing and visualization tools. This allows agencies to present data in a more interactive manner than with traditional data-sharing mechanisms, presenting opportunities for expanded sharing of geospatial information.
To explore how transportation agencies are using the cloud to support geospatial applications, the Federal Highway Administration (FHWA) and the Volpe National Transportation Systems Center (Volpe Center) interviewed select transportation agencies and developed a series of case studies focusing on their experiences using cloud-based applications. As a follow-up to the case studies, FHWA sponsored a peer exchange in Boise, Idaho, on May 9-10, 2013, which convened case study participants to discuss their experiences in greater detail.1
Participants in both the case study interviews and peer exchange included staff and representatives from the Idaho Transportation Department (ITD), Maryland State Highway Administration (MDSHA), Maryland State Transportation Authority (MDTA), Ohio Department of Transportation (ODOT), Mid-Ohio Regional Planning Commission (MORPC), Utah DOT, and the Washtenaw Area Transportation Study (WATS). Staff from the North Carolina DOT (NCDOT), the Utah State Geographic Information Council, and a consultant from BioWest Inc., currently assisting ITD with the development of its cloud-based application, also participated in the peer exchange. Appendix A includes a complete list of participants.
ITD hosted the peer exchange at its offices in Boise (see agenda in Appendix C). Participants demonstrated their respective agency's current use(s) of the cloud to support geospatial applications and then participated in four roundtable discussions. These roundtables focused on areas of interest identified during the telephone discussions, including: (1) defining the cloud and why its use is important in geospatial applications; (2) deploying the cloud to users and different configurations for cloud technologies; (3) strategies used to implement cloud-based technologies; and (4) overall trends and new areas of opportunity for using the cloud to support geospatial applications. Appendix D provides a list of questions proposed or discussed during the roundtables.
The purpose of developing the case studies and holding a peer exchange was to allow transportation agencies, including State and regional transportation agencies, the opportunity to:
The case studies and peer exchange were conducted as part of FHWA's GIS in Transportation program.2 Through technical support, resources, and capacity-building opportunities, the program aims to assist transportation agencies in more effective uses of GIS and geospatial applications.
Defining the Cloud
The term “cloud” does not describe a new technology but rather a way of purchasing, sharing, and distributing computing resources. There are many definitions of what constitutes the cloud. This report uses the National Institute of Standards and Technology's (NIST) definition, which is endorsed by the General Services Administration (GSA).3 According to NIST, cloud computing “is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.”4
Core characteristics of the cloud include the following:5
There are various implementation models for cloud-based computing services. For example, services may be implemented via computing infrastructure, software, or platforms (see Figure 1).6
A cloud service implemented through computing infrastructure (“infrastructure as a service,” or IaaS) is a complete package of computing functionality, including hardware, software, servers, and networking components. A user accessing an IaaS application needs only a web connection; through this connection, the user has extensive flexibility to design, develop, and manage a variety of cloud-based applications ranging from small-scale websites to large enterprise systems. IaaS is the most robust implementation model because it allows the subscriber maximum flexibility to customize software and operating systems (OS) for sharing, storage, and manipulation of data.
A cloud service can also be implemented through software (“software as a service,” or SaaS). SaaS provides one or more software applications designed for specific purposes as opposed to the complete package of computing functionality of IaaS. SaaS services are typically vendor-managed and vendor-designed “out of the box” applications, with some customization possible by users.
Cloud services implemented through a platform (“platform as a service,” or PaaS) fall in between IaaS and SaaS in terms of functionality. PaaS services provide users with some flexibility to customize applications but these changes are tied to the vendor's specific OS and network environment.
Figure 1. Types of cloud service models.7
In addition to these service models, there are also several different deployment models through which different user groups can manage and access data. Table 1 provides additional detail.8 Agencies typically identify who needs access to the cloud and what information will be shared to identify an appropriate cloud deployment and service model to use when developing an application that uses cloud computing.
Use of the Cloud for Geospatial Applications
The public sector is increasingly adopting cloud technology to streamline workflows and to allow data sharing among a broader audience. Traditionally limited to GIS experts or displayed on static maps, transportation agencies are moving geospatial data to cloud-based formats to adapt to new mobile technologies and an increased general expectation for on-demand and interactive access to information. The cloud offers an opportunity to merge the benefits of mapping with information technology (IT) and supports transportation agencies' drive towards more interdisciplinary practices by serving as a platform for data-sharing and collaboration among different organizations. As society increasingly shares and receives information in a spatial format, the cloud provides a relevant approach for transportation agencies to maintain their role as providers of official geospatial transportation data and information.
Recent Federal initiatives are encouraging the public sector's adoption of the cloud. These include the 2010 U.S. chief information officer's (CIO) “Cloud First” policy, which encourages government agencies to adopt cloud technologies to increase information technology (IT) efficiencies.9 The CIO and NIST also recently published a strategy document, a guide to creating cloud contracts, and a specific cloud “roadmap” to support the adoption of cloud technologies by Federal agencies. These and other initiatives are encouraging use of the cloud as a method to improve efficiencies through sharing computing resources and making information more easily accessible through a single platform.10 The Federal government has also emphasized the importance of data sharing, most notably in the recent Executive Order – Making Open and Machine Readable the New Default for Government Information, which requires the Federal government to “mak[e] information resources easy to find, accessible, and usable.”11
Use of the cloud for geospatial applications is increasing and continues to evolve as the cloud's capabilities and potential benefits become more widely understood.12 In addition to simply storing and sharing geospatial data and business information, cloud computing can support a number of functions that allow users to manage, analyze, and manipulate data, such as through mapping functions. This also provides nontechnical users or organizations, especially those with limited budgets, the capacity to access and manipulate geospatial data.
For the transportation sector, which is traditionally divided into many smaller organizational divisions, cloud computing can help bridge information gaps that exist between agency functions and facilitate collaboration. Cloud-based GIS systems and applications can also compile information from a wider array of sources via the web, encouraging data-sharing among agencies to support the interdisciplinary nature of transportation services. Collaboration through cloud-based applications or systems can increase efficiencies in agency activities by allowing diverse agency divisions to access the same data and eliminate duplicative data collection activities. Access to a wider array of data also enables faster and more effective analysis, leading to better-informed transportation planning and decisionmaking and more coordinated business activities.
Cloud-based systems and applications have been slower to develop in the public sector than the private sector. Public sector agencies often have security and privacy concerns about sharing information via the cloud, particularly if external users have access to the information through a public, community, or hybrid deployment model. To help address these concerns, the U.S. CIO established the Federal Risk Authorization Management Program (FedRAMP). FedRAMP is intended to streamline the security assessment process for third-party cloud providers. Once authorized by FedRAMP, providers are added to an approved list that makes procuring third-party cloud services easier for Federal agencies.13 State agencies could potentially use FedRAMP policies as a model.
Procurement policies at many agencies may not be designed to accommodate cloud services, particularly if contracts with cloud service providers are elastic and based on monthly usage of bandwidth instead of the acquisition of hardware. As the industry is relatively new, cloud service providers have not yet developed long-term pricing models. The Western State Contracting Alliance has emerged as a leader by providing a cloud service contract mechanism that State and local public agencies can join to compare vendor pricing and expedite procurement.14
Most of the agencies participating in this research effort are still in the early stages of determining how to most effectively use the cloud in their activities, but even their modest efforts have led to fundamental questions about how transportation agencies will conduct business in the future. For example, as agencies encounter challenges related to data security, procurement policies, and leadership support, they have begun to reconsider the role and purpose of IT systems and security; data storage, maintenance, and collection; as well as how to add value to geospatial data and visualization. As agencies experience successes and lessons learned in these areas, and as technology rapidly advances alongside their progress, agencies believe that cloud computing is destined to greatly influence the way that transportation agencies conduct their business in terms of efficiency, transparency, and cost-effectiveness.
Table 1. Cloud deployment models.
|Model||Consumer||Computing Infrastructure||Data||Public Sector Example||Graphic Description15|
(e.g., a State DOT)
|Owned, managed, and/or operated by a single organization or third-party provider.||Data in a private cloud typically remain within the subscriber organization's servers.||Los Alamos National Laboratory developed a private cloud to consolidate its numerous data servers; users access an internal portal to obtain information from these servers.16|
|Public||General public||Owned, managed, and/or operated by a vendor or organization interested in distributing information as a public service.||Typically, a public cloud offers access to a broad range of user types. Data may be stored on the host agency's or third-party servers. Selected users may be able to share their data as well.||
GSA developed a public cloud infrastructure for Data.gov, a repository of different datasets generated by the Federal government. Data.gov is accessible to any user from a variety of platforms (e.g., desktops, smartphones) and allows agencies to post their own data directly to the site rather than posting links to where data are hosted on their own servers.17
Case study examples: IPLAN
|Community||Specific community of consumers with shared concerns (e.g., policies, mission, goals); may include several different organizations||Owned, managed, and/or operated by a single organization, third-party provider, or a combination of entities.||Data on a community cloud may be configured similar to a private or public cloud, but access to it is limited to authorized users.||
The Defense Intelligence Agency and the National Geospatial-Intelligence Agency are developing a common, cloud-based desktop for users in the intelligence community. This desktop will allow any user with access rights to obtain information that previously would have been located behind various agency firewalls.18
Case study examples: WATS' use of Google Docs, Fusion Tables, and Drive; MORPC.
|Hybrid||Any combination of the above||Applications are owned, managed, and/or operated by a combination or linkage of entities (e.g., a State DOT may own data that are stored on a third-party provider server and shared via the provider's interface).||
Data are typically stored on a subscriber's servers, but accessed, viewed, and/or processed through cloud-based applications.
Conversely, data may be stored in the cloud while processed using a subscriber or user's server.
The Department of Energy and the National Nuclear Security Administration developed a hybrid cloud that combines a private cloud and commercial cloud services. The cloud will allow designated users to access common datasets to develop different kinds of applications, tools, and dashboards that serve various user communities.19
This section describes overall observations of how the State and regional transportation agencies interviewed are using cloud-based systems to support their GIS activities, as well as the associated benefits, challenges, and lessons learned resulting from these experiences. As most transportation agencies are only just beginning to integrate cloud-based computing into their business processes, the findings below primarily describe recent, self-developed efforts of those interviewed that generally do not rely on outside agency efforts as models.
Most agencies are in the early stages of using cloud configurations for GIS data-sharing and mapping but are not yet using the cloud for GIS analysis. Approaches to using the cloud are varied and still evolving. Some agencies already support a variety of business processes using cloud-based technologies, while other cloud-based tools are pilots or prototypes. GIS activities supported by the cloud mainly provide data-sharing and mapping capabilities; agencies continue to perform complex GIS analysis processes locally. Overall, none of the interviewed agencies has yet fully incorporated cloud-based applications, mapping, or data sharing into their workflows at the agency- or department-wide levels, though all noted that they intended to expand their use of cloud-based systems to support a wider range of activities. For example, MORPC developed its LBRS file in response to the State of Ohio's need for up-to-date road data from its localities for emergency response systems. However, it plans to add other data, such as bicycle paths and sidewalks, to make the file useful for other activities.
Agencies are using a variety of deployment models. A common thread among most agencies is their use of hybrid cloud configurations, which allows the agency to control access to data stored on agency servers, often for security purposes. For example, MDSHA wanted an easy method to connect dig requests with data on nearby utilities without moving utility data onto their software provider's servers, so it developed a hybrid configuration that linked the third-party, cloud-based MUTTS application to MDSHA's servers. Table 2 provides details on the configurations and deployment models used by each agency interviewed:
Table 2. Configuration and deployment models used by interviewed agencies.
|Agency/Application||Deployment Model||Software development||Service Model||Data storage||Data maintenance|
|Community||Off the shelf||Packaged software||On agency server||Agency, partner agencies|
|Hybrid||Customized off-the-shelf||SaaS||On agency server & third-party server||Agency, partner agencies|
|Hybrid||Off-the-shelf||SaaS||On agency & partner agency servers||Agency, partner agencies|
Google Docs, Google Fusion, and Mi Community Remarks
|Hybrid||Off-the-shelf||SaaS||On third-party servers||Agency|
MUTTS, truck routing application, MD iMap Templates, MDTA enterprise GIS system
|Hybrid||Custom and customized off-the-shelf||SaaS/SaaS (self-developed)/SaaS/PaaS||On agency server & on third-party servers||Agency|
Cloud technologies are being used at the interviewed transportation agencies in response to a need for more integrated and accessible GIS data. As the use of geospatial applications and data has expanded over the past few decades, agencies have begun to address the proliferation of disconnected, large, and often redundant datasets. At the same time, as the use of mobile technology increases, transportation agencies are responding to a general expectation for more open, accessible, and interactive data that have been cultivated by the Internet. Furthermore, the use of the cloud reflects transportation agencies' increasingly interdisciplinary activities, such as in asset management and environmental streamlining. For example, information and data once siloed in individual departments is now needed in a centralized format to respond to the asset management reporting requirements of MAP-21. Agencies view the cloud as a way to gain a better understanding of the full scope of their assets and business activities to reduce redundancies and make more efficient and informed decisions.
Off-the-shelf or third-party platforms are preferred over developing custom code for cloud applications. In particular, most agencies are using or have considered using Esri's cloud-based GIS SaaS, called ArcGIS Online,20 in part because of many agencies' existing licenses with Esri. Some agencies have attempted to custom-code their own cloud applications but noted the large time investment needed. For example, UDOT initially wrote its own code for its UPlan application before switching to a customized version of ArcGIS Online due to the staff time required to maintain the code and interface. Based on UDOT experiences, ITD opted to use ArcGIS Online rather than develop custom code for its cloud application, IPLAN.
Cloud-based technologies are accompanied by data standardization and quality control efforts. Agencies that have moved data to the cloud or use cloud-based applications need some level of format and quality standardization in order to display disparate datasets in a web viewer or to make the data compatible for integration into larger datasets. For some agencies, such as MORPC, a cloud-based solution was the outcome of an initial goal to consolidate and centralize data into a common location and format to reduce redundancies and allow locally collected data to be viewed across jurisdictional boundaries. Other agencies are finding that as data are published to the cloud, data stewards are motivated to improve the quality of the data on their own. For that reason, some agencies, such as UDOT, are letting data stewards assume responsibility for quality based on their own needs.
The functionality and design of cloud-based applications influence data standardization and quality control efforts. For example, data quality and standardization may be important at the statewide level to prevent inaccurate data from being incorporated into other agency datasets and analyses. In response, some agencies, such as MDSHA, have initiated proactive data inventory and assessment efforts in order to eliminate redundant datasets and prioritize data as it is fed into its cloud-based system.
Overall, the transportation agencies interviewed believed that their cloud-based applications provided significant and sometimes unexpected benefits to their GIS activities, business operations, and partnerships. Although they have not yet developed quantitative performance measures and assessed the effectiveness of their applications, the benefits of using cloud-based solutions are demonstrated by the interviewed agencies' desires to expand their cloud-based tools and datasets in future years.
The cloud increases the user base and impact of spatial data. GIS can produce powerful results by juxtaposing information that previously was only available in an isolated or nongeographic format (such as public comments). However, until recently, the software and expertise needed to process GIS data was primarily limited to GIS specialists. Cloud-based GIS applications such as UPlan, IPLAN, and WATS' Mi Community Remarks enable those without GIS software or GIS expertise to view and manipulate spatially formatted data in more user-friendly, interactive, and intuitive environments. In addition, this information becomes available to the user instantaneously.
Time and costs associated with managing and displaying GIS data are reduced. Cloud services offer agencies the opportunity to store a large amount of information in one place that otherwise must be stored and maintained in a variety of locations on an agency's servers. Cloud services also enable users to access information stored in several locations through a single portal. Using a cloud configuration to store geospatial data can “free up” space on an agency's servers and eliminate the need for individual users to maintain and store their own version of a data file or software, consolidating resources and making data easier to find. Some noted, however, that storing data on a cloud server can be expensive if the service package charges by the amount of bandwidth used for uploads and downloads.
Both UPlan and IPLAN, for example, were developed to harness the benefits of visualizing data in a spatial format while reducing time spent on managing and processing data. This is accomplished through an application design that links to but does not store data. Even if the cloud application is not used for data storage, time and cost savings are nonetheless realized. The application eliminates the need to search for and combine datasets for regular business activities as all data can be accessed from one interface. Agencies also noted that time savings are realized by IT staff not having to manage disaster recovery systems and software updates for third-party software and platforms, which is especially advantageous for smaller agencies with more limited budgets and IT capacity.
Cloud-based systems foster and strengthen multi-agency collaboration and partnerships. The agencies that currently use cloud systems reported that information sharing is easier, faster, and more effective, and that they have benefited from learning of and using data that other agencies collect and maintain. As an example, Ohio DOT notes that many counties hired a vendor to manage LBRS data through third-party cloud-based services. In collaborating with their municipal and local agency partners to establish LBRS data submittal processes, these counties discovered redundant data collection among jurisdictions or were made aware of useful data maintained by another agencies or departments. Sharing this information effectively reduces the “silo” effect between and within agencies and streamlines data collection and maintenance activities.
As new data from various sources become available in a centralized repository, there will be new opportunities for data analysis. For example, UDOT, ITD, and MORPC all anticipate that their cloud-based applications will lead to more regional cooperation among jurisdictions based on the availability of regional-scale data that will be accessible through the cloud. Agencies also noted that users have increased confidence in the quality of GIS data since a cloud-based system can reflect updates and changes coming from different locations and users in real-time. This is especially important as NextGen-9-1-121 routing systems use GIS and will depend upon up-to-date road network data and address information.
Cloud-based applications can improve agencies' interaction with the public. Cloud-based applications provide an online, easy-to-use forum for exchanging spatial information with the public. For example, WATS reported that it received 99 comments on its long-range transportation plan, much higher than in past iterations, and received informed comments from transportation professionals who may otherwise have been too busy to attend public meetings. Transportation agencies see the cloud as a way to present the interdisciplinary nature of their transportation activities and to place them in the context of a larger government service. Additionally, as third-party, crowd-sourced applications emerge due to a demand for geospatial infrastructural data,22 the cloud offers transportation agencies the opportunity to control how their assets and business activities are presented by providing “official” data.
Since cloud computing is relatively new, most agencies noted several challenges associated with developing and implementing cloud-based applications. Challenges outlined include:
Security concerns can slow or limit cloud deployment. Agencies expressed concerns about maintaining security for data published on the cloud, and experienced challenges in convincing partners to share data on systems where users could access and possibly misinterpret or misuse data. GIS and IT professionals in transportation agencies are also beginning to discuss how much security is necessary for their various datasets as their cloud-based systems and applications are developed. In some cases, GIS or transportation practitioners turned to the cloud due to IT security complications involved in building an application or publishing data behind the agency firewall.
Overall, agencies view IT policies and processes as a potential hurdle to meeting their customer's needs. While GIS practitioners generally believe that often the benefits to sharing information outweigh the risks to releasing it, in many cases IT policies have evolved to focus on securing rather than providing information. Agencies view this as a challenge to remaining nimble and responsive in meeting customer needs when deploying cloud-based applications and data.
Cloud-based services present unfamiliar, and in many cases untested, cost models. Many cloud-based services, particularly those provided by third parties, are based on a “pay-as-you-go” model, which charges for services (such as bandwidth and data storage) as they are used. Agencies therefore find it difficult to meet procurement policy requirements that call for cost-benefit analysis, as estimating future usage levels of cloud services is difficult.
Private providers of GIS-cloud applications are also still piloting various cost models for their services, contributing to the unpredictability of future cost estimates. Agencies had difficulty justifying cloud computing services that by nature are ephemeral and do not conform to traditional cost models based on the longevity of infrastructure or ownership. Cost-benefit analysis models of different cloud scenarios and the assurance of cost stability are needed to assist agencies in demonstrating the value of cloud technologies to their agency.
The level of expectation for data accuracy and quality of cloud-based data is evolving. When data are published to the cloud, agencies noted that data stewards often took care to improve the data's quality. Yet agencies are also finding they need to determine the level of accuracy, quantity, and detail acceptable for cloud-based activities and whether data quality standards must match those held for paper documents. Several reasons exist for these concerns. First, because increased detail in data may increase storage and bandwidth needs, the costs associated with providing cloud services may increase (this concern may be mitigated by the trend towards increasingly inexpensive storage space). Very detailed data may also attract additional security issues that could lead to more limited accessibility, or result in misinterpretation. However, agencies must also maintain certain data standards if they are to be used in the transportation decisionmaking processes. For that reason, agencies developed standards for data to be published on the cloud while leaving enough flexibility in formats so that the data can be used for multiple purposes. For example, UDOT screens uploaded data to meet minimum standards, even though the data are maintained and actually stored on user servers. For other agencies, such as MORPC, the format of the LBRS files creates a standard that the participating jurisdictions must adhere to in order to contribute their data. These efforts are intended to ensure that data is displayed in the manner intended by the data owner to the appropriate audience.
As use of the cloud increases, agencies are mindful that there must be some level of organization and process development behind the scenes in order to prevent various groups from adding redundant datasets. For instance, MDSHA is currently developing a template for MD iMAP partner agencies to outline their data collection and maintenance schedules to inform new applications as they are developed. Identifying and preventing redundant data, as well as making sure data is easily searchable and generally accessible, are also important for minimizing costs if data are stored on third-party servers.
The dynamic nature of the cloud requires new strategies for recordkeeping. The cloud enables users to update geospatial data in a centralized location in real time. While this provides benefits in terms of access to up-to-date data, it presents challenges in regard to maintaining a historical record. In the event that an agency needs to document its decision to justify or explain a certain outcome, data used from cloud-based systems or applications may have since been updated. Agencies have responded to this in various ways. One approach is to “version” the database from which the cloud-based application draws data by storing only changes to the dataset. This works for scenarios where the agency has direct control over all data used within its cloud-based system or application. For scenarios where users maintain data, agencies may have to rely on data owners to record the version and methodology of data that were used on a particular date. But agencies acknowledge that there is a risk in depending on other entities to maintain records.
The interviewed transportation agencies offered the following lessons learned based on their experiences developing cloud-based applications so far:
Remain flexible to adapt to new, unanticipated responsibilities. The ultimate goal of adopting cloud computing is to increase efficiency, but agencies note that doing so can create unexpected responsibilities that might add to or change the nature of staff workload. For example, MORPC found that it had to spend significant time cleaning up initially submitted LBRS data in order to maintain the stability of their LBRS files. MORPC chose not to shift this responsibility to partners in order to encourage participation and buy-in, and the quality of submitted data is improving as users gain experience.
As new uses for publishing data in cloud scenarios are identified, transportation agencies may also find that they spend additional time updating existing or in developing new applications to achieve new efficiencies. After establishing its dig request workflow using MUTTS, for instance, MDSHA is adding a new function that will link construction permits with dig requests. Agencies tended to see the time investments associated with cloud technologies as “time well spent,” and recommended incorporating cloud computing into business processes incrementally in order to remain flexible and able to adjust to new demands. ITD expects that the increased use of IPLAN will also result in increased requests of its GIS staff for GIS analysis, which it views as a positive use of its GIS resources for future problem solving.
Seek input from partners in designing and developing cloud-based tools and systems. Interviewed agencies found that designing their applications and data structures with significant input from internal and external partners helped focus the technology and identify the data they needed to include. Often these partners will be the owners of key data or will be relied upon to maintain the GIS data once the cloud-based system or application is available. Gathering input and creating ownership responsibilities ensures cooperation from partners and also serves to shape the cloud-based tool or system to satisfy the needs and requirements of multiple entities. For example, while MORPC is the primary developer of their LBRS files, it meets monthly with an advisory committee comprised of participating jurisdictions to discuss next steps and to obtain feedback. Agencies recommend including IT representatives in cloud governance bodies but to be mindful of balancing security concerns with an understanding of customer needs. In addition, legacy issues attached to existing data must be considered, and partners must recognize that it may be unrealistic for some agencies to easily modify their data systems and processes to accept and contribute data from the cloud rather than their local servers as originally designed.
Demonstrate benefits to gain support. Some agencies indicated having encountered skepticism or resistance to incorporating cloud computing into existing workflows. This may be due to the disruption of familiar work processes or the perception of additional responsibilities associated with the cloud. Agencies stressed the importance of demonstrating the cloud system or application to both leadership and staff. Proponents should articulate the value the cloud adds to traditional GIS. ITD met with each Idaho Transportation Board (ITB) member, for instance, to describe the purpose of IPlan and also to take the opportunity to listen to what board members hoped to achieve through increased geospatial collaboration.
Regardless, users may still need to pilot the cloud in their regular activities before committing to its long-term use. Cloud-based systems and applications should also be designed for intuitive use, as not all users are familiar with GIS or cloud computing. For example, MORPC did not pursue agreements with its partner agencies—many of which did not have high-level GIS capacity or resources—because it felt the LBRS system would receive more buy-in from users experiencing the tool and its benefits first.
Use the cloud to facilitate and coordinate business interests. Agencies view cloud computing as a collaborative tool among users that may not otherwise have a means to coordinate. Once established, the cloud-based tool or application should reflect and engage the business interests and contribute to the vision of the organization, as well as incorporate user needs, especially as data are added. Agencies regard this process as an opportunity to learn not only what customers find important, but also to help focus the activities and business processes of the organization. For example, after data stewards uploaded data into IPLAN, ITD discussed the purpose of the data with the users. This helped create a better understanding of users' needs and helped users understand the purpose of IPLAN. Such discussions should also occur at the management level to understand program- and department-level needs. This interaction can also help prevent the cloud from becoming too unfocused or cluttered with questionable or redundant data.
Identify risks and develop contingency plans and mitigation strategies to avoid negatively impacting partners. In order to reduce the perception that the cloud will add new, time-consuming responsibilities, agencies recommend developing workarounds and contingency plans. For example, ODOT has developed automated methods to correct common data discrepancies in files submitted to its statewide LRS dataset instead of asking jurisdictions to reformat their data.
Consider the implications of using third-party cloud platforms or data repositories. Third-party cloud-based platforms and software are by nature not under the control of users or the subscriber. Several agencies noted that third-party systems should not be relied on as the sole repository of an agency or program's data and information due to the risk of server failures. For example, in assessing its experience with Mi Community Remarks, WATS identified a need to back up the public comment data it received in case its Google application became unavailable. While agencies felt that third-party cloud vendors have an equal or larger incentive to maintain security as their agency IT departments, they are also aware of the risk of substantial business disruption if a cloud service malfunctions, leaving agency IT staff unable to assist. Some partners may also be wary of sharing information and data on a third-party site for this reason.
Third-party cloud applications also carry different cost implications. Due to outsourcing infrastructure and maintenance costs, third-party cloud scenarios may create the perception of reduced costs among users. Agencies cautioned that any data storage on third-party servers should be strategic, as pricing is often based on file size and bandwidth used during data transfers and geospatial files can be large in size. Hybrid cloud configurations, such as UPlan and IPLAN, were often chosen in part for this reason.
Agencies noted several areas in which they may consider expanding or refining uses of the cloud.
Cost-benefit analyses of cloud applications may be developed as efforts expand. Most agencies have not yet quantitatively evaluated the uses and effectiveness of cloud platforms and applications, although many have anecdotal or qualitative evidence that indicate the benefits of these tools. The development of quantitative measures and metrics to better assess the cost of cloud technologies might be an area of focus on the part of both agencies and vendors.
Cloud applications can provide powerful opportunities for feedback loops. Agencies noted the potential for cloud applications to become locations where agencies can respond to comments, information, and data that users provide through the cloud. For example, WATS envisioned a mechanism where it could follow up on comments received during its long-range planning process and inform participants how their comments were considered and incorporated into their decision making.
The cloud may influence the reconsideration of data classification and maintenance. Some transportation agencies noted that as data used in the cloud is applied to more uses than it was formerly, data may be re-organized and maintained in terms of how they are used rather than their functional or ownership classification. For example, dirt roads are not currently included in most State linear referencing systems, but emergency responders still need to know where these roads are located. If 911 systems continue to increasingly rely on geospatial data to route calls, the cloud could render this type of data hierarchy obsolete and authority over dirt road location data could shift to more relevant data stewards. In this way, the cloud could relieve transportation agencies of some data maintenance responsibilities, freeing them to focus on other activities.
Agencies noted potential areas where FHWA activities could support further advancement of cloud-based geospatial activities, including:
Further develop the national goals related to data sharing. Through documents, standards, best practices, and national guidance, FHWA could assist agencies in pursuing cloud-based technologies by articulating the national importance of linking data from multiple agencies and jurisdictions. For example, cloud-based data sharing of local data could be linked to national initiatives that promote environmental streamlining and ecosystem-scale planning and analysis.
Develop a national model for cloud-based GIS activities. A national-scale cloud-based application that linked multiple Federal agencies could serve as a model to demonstrate the benefits of interagency collaboration and data-sharing to states.
This section presents in-depth case studies on the current activities of the State DOTs and regional transportation agencies that participated in the report interviews and the peer exchange. Each case study includes information on how the agency began using cloud technology to support their geospatial applications, how they developed or are planning on developing these applications, and the challenges, lessons learned, and benefits encountered during the process.
IPLAN is a cloud-based, collaborative tool under development by the Idaho Transportation Department (ITD) that will enable staff, partnering agencies, and the public to visualize GIS datasets via a user-friendly web browser. IPLAN's primary purpose is to improve collaboration, efficiency, transparency, and accountability among ITD's six districts, among ITD and partner agencies, and between ITD and the public through improved data sharing. ITD anticipates that IPLAN will enhance the planning process by allowing users to share critical data, and will be a tool for communicating ITD's progress on MAP-21 goals as well as providing tools for transportation scenario planning by layering system performance measures, long-term system vision, and financial forecasts. IPLAN will also support the streamlining goals of FHWA's Every Day Counts (EDC) initiative.
Figure 2. IPLAN platform design.
ITD was first introduced to the potential benefits of a web-based, data-sharing platform through a GIS consultant aware of a similar initiative. At the time, the Utah Department of Transportation (UDOT) was developing its UPLAN tool. ITD learned of the benefits of UPLAN and decided that ITD might benefit from a similar data-sharing tool. In 2012, UDOT began to help ITD adapt a version of UPLAN for Idaho using ArcGIS Online. ITD is now a member of the American Association of State Highway and Transportation Officials (AASHTO) Technology Implementation Group (TIG), which UDOT created to help States explore how to best build and use cloud-based, collaborative geospatial tools, with a focus on UPlan. The UPlan TIG includes 11 other States in addition to Utah and Idaho.
After conducting an Enterprise Architecture Assessment,23 ITD determined that Esri's ArcGIS Online, a cloud-based, off-the-shelf, Software as a Service (SaaS) package, would be the most effective way to develop IPLAN due to ITD resource constraints and a desire to adopt a usable system relatively quickly. Esri's ArcGIS.com will function as a web portal for users to retrieve, visually display, and analyze geospatial data from within ITD. IPLAN's data and GIS services will be stored on ITD and other agencies' servers (see Figure 2). By giving Esri the responsibility for software maintenance, ITD expects to incur less risk since the need for custom software development and future maintenance requirements is eliminated.
To date, ITD has developed an IPLAN pilot website that provides a test case for ITD to explore, discuss, and refine the tool. ITD has also assessed the agency's GIS needs and goals, developed a project charter and business case for IPLAN, and received approval from the Idaho Transportation Board (ITB)24 to continue developing the application. ITD recently finalized the development of IPLAN's system architecture, which included determining how to tie IPLAN into ITD's internal GIS network. ITD's districts are currently using ArcGIS Online to edit, share, and finalize data for their own use. IPLAN is leveraging ITD's GIS server capabilities to host and publish map services, which do not consume credits. Unless specifically configured to do so, data that are served from ITD cannot be edited through IPLAN.
The next step is to develop and configure the IPLAN tool as well as to establish a long-range vision to identify next steps for enhancing IPLAN's capabilities. ITD has not yet determined a detailed scope and contract cost for later phases but ultimately anticipates that ITD will create more focused maps, demonstrate how IPLAN fits into everyday business solutions, and use it as a tool to communicate Moving Ahead for Progress in the 21st Century (MAP-21) goals for ITD.
ITD anticipates that IPLAN will serve three types of stakeholders: ITD internal staff, partnering agencies, and the public.
The tool's primary internal users will be ITD environmental and transportation planners from ITD's six districts. These staff will use the tool to support environmental planning and project streamlining. Other ITD staff, such as design and construction sections, will take advantage of the existing State enterprise airport, pavement, traffic, and safety data to be displayed by IPLAN. Overall, IPLAN will assist staff at all levels of ITD, from technicians to ITB members, to make data-driven decisions.
ITD anticipates that a number of partner agencies will also share and use data on IPLAN. These partners may include State agencies, Federal resource agencies, and local community planners. For example, resource agencies may share data on endangered species, historic preservation, and wildlife migration. By encouraging partner agencies to share information via IPLAN, ITD anticipates making better transportation investment decisions and streamlining transportation planning activities. ITD has started gathering feedback from a variety of stakeholders, including internal ITD staff, Idaho Department of Fish and Game, Idaho Bureau of Homeland Security, Idaho State Emergency Medical Services Communications Center, FHWA Idaho Division, on the data they would like IPLAN to display.
ITD also foresees that IPLAN will provide the general public an opportunity to more easily access information about transportation projects and assets as part of ITD's larger goal to increase overall agency transparency. In the future, ITD may use IPLAN to gather and display public comments on transportation projects during the yearly Idaho Transportation Improvement Program (ITIP) programming cycle, thus enhancing the public involvement process.
ITD does not plan to collect, store, or maintain data included in IPLAN except for those data ITD already manages. IPLAN will automatically draw these data from ITD's GIS databases. Individual data owners, both internal and external, will be responsible for the compilation and maintenance of other data. ITD intends to sign Memoranda of Agreement with stakeholders to ensure that the information provided is updated regularly. Some agencies, such as Idaho Department of Fish and Game, currently have their own data-mining applications, to which IPLAN may directly link. Smaller agencies with limited GIS resources may be able to work with the Idaho Geospatial Office to spatially enable and store their data, and IPLAN could then link to this information.
ITD is also addressing security concerns regarding sensitive data and its availability to the public. Only those using ITD's internal network or with credentials using the Internet will be able to access sensitive data using IPLAN. For example, certain data, such as historical artifact locations, will be restricted and stored behind ITD's firewalls. Data will also be replicated on a GIS server in a secure area25 outside the firewall, allowing only those with a username/password to access the data from an external network (see Figure 3 for a simplified diagram of ITD's security configuration).
IPLAN will potentially display certain datasets to the public more generically than is displayed internally. For example, ITD's bridge department is concerned that the public may misinterpret the current display of bridge data as evidence of a safety risk, when in fact it is just the manner in which bridge engineers record information. Instead of using the National Bridge Inspection Standards (NBIS) condition ratings of “Not Deficient/Structurally Deficient,” IPLAN could convey this message using a green/red color coding system or ranking the bridges as healthy/not healthy.
Figure 3. ITD's security configuration for IPLAN.
ITD reported the following lessons learned in its experiences using cloud-based technologies:
ITD anticipates IPLAN will provide a number of benefits to the agency itself, partner agencies, and the public, including the following:
In the future, ITD envisions using IPLAN as a platform for providing datasets required by Federal legislation. For example, ITD envisions the ability to use IPLAN to generate data and reports required by MAP-21. This functionality will be developed during a later stage of development.
ITD has recently encountered challenges in developing IPLAN because of staff transitions, but is working with a contractor to assist with development of the application. ITD aims to fully deploy IPLAN in fall 2013.
The Maryland Department of Transportation (MDOT) contains multiple transportation business units (TBUs), including the Maryland State Highway Administration (MDSHA) and the Maryland Transportation Authority (MDTA), which are responsible for maintaining Maryland's roads and Interstate highways. Some of MDOT's business units are currently piloting the use of cloud-based platforms, software, and applications to support various business activities.
This case study examines four cloud-based initiatives at MDSHA and MDTA. The first is a hybrid cloud-based application called Miss Utility Tracking System (MUTTS), which coordinates and tracks responses to requests that construction workers and excavators make to dig holes. MDSHA would like this application to serve as a template for other cloud-based initiatives. The second is a collection of interactive mobile applications that are designed for specific segments of the traveling public, including truck drivers, cyclists, and highway motorists. The applications are also representative of a hybrid cloud configuration.
Third, several of MDSHA's and MDTA's staff members are involved in improving the configuration of MD iMap as part of an interagency technical committee, which is comprised of representatives from MDSHA, the Maryland Transportation Authority (MDTA), MDOT, and other State agencies. Launched in 2009, MD iMap26 is a statewide data and mapping portal that compiles data from various agencies across the State of Maryland. MDSHA is a funding partner for MD iMap. The technical committee's effort includes building templates for web-based applications using Esri's ArcGIS Online, which is a third-party SaaS program.
Finally, MDTA deployed an enterprise GIS system in 2009. This business unit-wide system is currently configured as a private cloud that only MDTA and MDOT staff members can access. The system blends functionality from Esri and Google Earth27, and its data and applications are stored entirely within MDOT's firewall.
Maryland utilizes MUTTS,28 a notification center that informs construction workers and excavators of underground utilities before digging. The notification system is a web-based application; when an excavator submits a dig request via MUTTS, MDSHA receives an automated ticket. To connect MUTTS with MDSHA's utility data, MDSHA's Office of Information Technology developed a cloud-based interface using Salesforce cloud-based software.29 MUTTS therefore represents a hybrid PaaS cloud configuration, as the web interface is located on Salesforce's servers but also links to MDSHA's eGIS (MDSHA's enterprise GIS system) and databases to create a utility location viewer (see Figure 4). MDSHA staff members use the viewer to locate dig requests on a map that shows other nearby utilities.
When requests to dig within MDSHA rights-of-way are entered into MUTTS, the web application populates a database stored on the Salesforce server with the dig request. The request appears as a link to the MDSHA staff member using the web application.
The dig request link is tied to the address for which the dig permit was submitted, allowing it to be geocoded and mapped within MDSHA's eGIS. An MDSHA staff member may then view the request to see the dig location relative to other nearby utilities within a certain buffer on the eGIS map. The staff person reviewing the request can then notify an excavator of the existence of utilities. MUTTS tracks the entire process, from initial request to closeout, to guide and improve response times.
Figure 4: The MUTTS application and utility location viewer in eGIS.
MDSHA is currently exploring ways to use automatic vehicle location (AVL) system data, which transmits the location of vehicles, for the truck routing application. Most trucks are outfitted with AVL technology, and these data could be collected through the application and used to provide more geographically tailored information to the users of the application. Data could also be integrated into other datasets within MD iMAP's cloud-based environment and with the University of Maryland's Regional Integrated Transportation Information System (RITIS)32 to aid in congestion monitoring.
MDSHA is also developing an application for cyclists called “Cycle MD.” The application is configured similarly to the truck routing application, and users to the safest bicycling routes based on their current locations and conditions. The application relies on data collected from two counties by MDSHA's Office of Highway Design that was used to develop metrics for cycling comfort. The application is designed to visualize those metrics and serve as a decision support system to direct cyclists to safe routes (based on traffic, shoulder location, etc.) (see Figure 5). Users can inform MDSHA about cycling-related facilities and infrastructure, such as bicycle shops. Finally, a Points of Interest application will let users view information available on the Maryland Official Highway Map33 in a geospatial format.
Figure 5. Cycle MD mobile application showing how users can choose bicycle routes based on different conditions.
MD iMap, a statewide data and mapping portal, is configured as a hybrid cloud. While data remain on servers from various MDOT business units, applications that display the data reside within ArcGIS Online. Existing applications within the iMap portal vary widely in terms of design, format, and function, and at times users have had difficulty consuming data displayed in inconsistent formats. Additionally, many of the applications currently hosted on MD iMap were built using an Arc GIS API for Flex34 configuration, which is not always entirely compatible with mobile devices. Many of the MD iMap technical committee members believe that having a more standardized appearance and functionality for MD iMap's applications would help meet users' needs and that a cloud-based configuration would better respond to the growing market of mobile devices. For that reason, members of the technical committee are working to develop cloud-based templates for all applications on MD iMap that are accessible in the public domain. The committee is planning to use DoJo,35 open-source code, to build these templates, which will provide the format for the geospatial data accessed by public users through the ArcGIS Online-hosted interface. The templates will serve as standard interface formats for users to access, manipulate, and share MD iMap information (see Figure 6 for a diagram of the cloud configuration for the templates and Figure 7 for an example of a template).
The server that currently supports MD iMap can accommodate increased web traffic during emergency events such as hurricanes. Maintaining this hardware requires staff and financial commitment that most of the time is disproportionate to its normal level of use. Members of MD iMap's technical committee are therefore particularly interested in the elasticity that a cloud environment could provide for its geospatial data.
Figure 6. Relation of the MD iMap templates within the cloud configuration.
Figure 7. Top screenshot showing MD iMAP's StreamHealth application as it currently exists when accessed through MD iMAP's ArcGIS Online portal. Bottom screenshot showing the StreamHealth application in ArcGIS Online when the template is applied.
Prior to 2009, MDTA did not have GIS software. To provide MDTA with GIS capabilities, the business unit's IT department developed a new GIS system using Esri's ArcGIS Server36and Google Earth to serve 1,800 users across MDTA and MDOT. The data the enterprise system uses are stored within MDTA's various departments and analyzed using ArcGIS Server. MDTA's ArcSDE server37 then transfers that data for publication onto Google Earth servers using Google Fusion. In this way, users have responsibility for data maintenance, but the data are accessible to other authorized users within the network via Google Earth Enterprise.38 All data remain within MDTA's firewall. MDTA has also customized the Google Earth application with State-owned background aerial photographs.
MDOT sees value in pursuing its current and future cloud-based applications and configurations for the following reasons:
MDOT is experiencing several challenges as it expands its use of the cloud:
Current procurement policies are not necessarily designed for cloud-based services or software. At the agency level, MDSHA staff found that the deployment of cloud-based solutions is limited by the State's current procurement policies. These policies require that competitive bids include Maryland-based small and local businesses; many existing cloud vendors do not fall within this category. Current procedures also incentivize the procurement of hardware by requiring demonstrated longevity and long-term value; the use of cloud-based technologies is, by its very nature, elastic, and pricing structures are often pay-as-you-go.
In addition, if multiple organizations wish to collaborate on a cloud-based initiative, procurement policies require each organization to individually complete the procurement process. For this reason, current efforts to use the cloud occur on a smaller, case-by-case basis as funding and staff time allow, and there is not yet an agency or statewide coordination effort to use cloud-based technologies for Maryland transportation data. MDSHA does not anticipate a joint statewide contract for shared cloud services to develop anytime soon.
Both the MUTTS application and MD iMAP templates represent efforts to synchronize and link various web-based mapping applications and data sources within the agency and with other State agencies. These efforts will likely serve as models for expanded use of the cloud throughout MDSHA. For example, MUTTS might serve as a model for technologies developed and used to manage and organize customer interactions. Applications could be developed using Salesforce's cloud-based software that are similar in structure to MUTTS but serve different needs, such as providing the public the ability to notify MDSHA about the location of a pothole. MDTA would also like to develop a system similar to MUTTS to link dig requests with data stored on its MDTA servers using a Google Earth software license.
MDHSA's GIS team would like to enhance MUTTS further by using the application to process work permit requests for construction within MDSHA's right-of-way. Currently work permits are granted though another system before dig requests can be submitted into MUTTS; dig requests are entered into eGIS by address rather than by GPS coordinates. By geocoding the work permit within MUTTS directly, MDSHA could more easily pinpoint the dig request and respond more accurately. Similarly, data from other Salesforce-based applications (such as the truck-routing application) could eventually be fed into MD iMAP.
Overall, MDSHA seeks to create a suite of web-based tools to be repurposed and tailored to various audiences and uses. MDSHA staff members are collaborating with colleagues involved with the MD iMAP application standardization effort to share lessons learned. In the meantime, the MD iMAP technical committee continues to discover duplicate datasets that different agencies maintain. In response, the technical committee has created a data-sharing/ownership template to identify the owners and data maintenance schedule so that personnel monitoring MD iMAP applications will be better able to organize and prioritize data as various agencies feed them into MD iMAP applications.
In 2003, the Ohio Geographically Referenced Information Program (OGRIP), a statewide GIS data integration program, launched the Location Based Response System (LBRS) initiative.39 The LBRS program is intended to collect, maintain, and integrate locational information on roads and addresses from Ohio counties in order to reduce redundant data collection among local governments in Ohio. OGRIP maintains LBRS data files that contain street centerline data along with site-specific, field-verified address points. Participation in OGRIP's LBRS program requires county officials to sign a memorandum of agreement (MOA) with OGRIP. As the lead organization in establishing the Franklin County LBRS files, MORPC is a signatory to the MOA. The MOA outlines roles and responsibilities for updating, submitting, and maintaining LBRS data according to OGRIP's standards.
Ohio counties voluntarily partner with OGRIP to contribute their data through the LBRS program. Seventy-six of 89 counties in the state currently participate. Counties may apply to receive up to $100,000 to fund the collection of LBRS data within their jurisdictions from OGRIP.40 The Ohio Department of Transportation (ODOT) then provides technical support and ensures that LBRS data meet quality standards. Once the LBRS data are integrated into OGRIP, they are referenced by local, regional, State, and Federal governments to support emergency response, planning, and other maintenance and service activities such as paving and snowplowing. The LBRS data are also used to help meet the State's Federal transportation safety data reporting requirements.
In 2008, the Mid-Ohio Regional Planning Commission (MORPC) partnered with agencies in Franklin County, a large urban county, and its municipalities to coordinate county-level LBRS data as part of the statewide LBRS program. Other counties in the region participated in OGRIP's LBRS program in partnership with their own county auditor's offices. MORPC's initiative was termed the “Franklin County LBRS project,” and aimed to address the county's need for a single source of county centerline data that is regularly updated, maintained, and available on-demand. Dedicated servers and an Arc Spatial Database Engine (ArcSDE) geodatabase provided by MORPC allow jurisdictions and agencies to access, add to, and manipulate the compiled data.41 MORPC is also currently developing a web-based editing tool that allows organizations without GIS capabilities to provide and update their data as well.
MORPC serves as the metropolitan planning organization for 1.5 million residents, including Franklin County and all of the jurisdictions located within it. When the statewide LBRS program was launched in 2005, MORPC recognized the increased efficiency and collaboration that standardized and centrally accessible centerline and address data presented, as well as the potential to expand the system to accommodate the collection of other datasets.
Franklin County's agencies, departments, and local municipalities previously collected centerline and address data in disparate locations for their own specific purposes. The Franklin County engineering office, for example, originally initiated its collection of countywide road centerline data to assist with snowplowing, but the centerline data format was not entirely compatible with LBRS requirements. From conversations with various county agencies and departments such as the Franklin County 911 office and the Central Ohio Transit Authority (COTA), MORPC determined there was significant demand to access regional data in a central location. This enables the various agencies to engage in regionally focused activities without having to individually host and maintain large data files. For example, many municipalities have municipal aid agreements for safety/emergency services and require access to information about infrastructure and addresses outside of their service areas.
Currently, eight participating “power users” (including the City of Columbus and the county engineer and auditor offices) contribute data to the Franklin County LBRS files. COTA, the 911 office, the Ohio Department of Public Safety, MORPC, and ODOT all contributed funding to the Franklin County LBRS initiative.
The Franklin County LBRS files represent Platform as a Service (PaaS) and a community cloud deployment model that are maintained by a specific group of users and can be expanded based on their individual or collective needs. The data reside in an ArcSDE geodatabase located on a MORPC server that is accessible to multiple agencies (see Figure 8) through ArcServer. Partners access the LBRS files by connecting to MORPC's map and geodata services. After adding this connection to their GIS servers through ArcCatalog, partnering agencies can access the LBRS files. Because each participating agency has different firewall installations, MORPC had to address unique connection requirements associated with each user's network configuration.
Those agencies or departments with access to ArcInfo or ArcEditor42 are considered GIS “power users.” Power users access their own “version” of the LBRS file on the MORPC server through a secure log-in. The “version” acts as an image of the original file—not as a copy—that users then replicate from the SDE geodata service43 to their respective local networks. The replicated version is still connected to the original file stored on MORPC's server through a map service. Power users then make edits to their local “version” and synchronize their changes with the MORPC server. “Synchronization” is a process through which changes to each partner's version are automatically integrated with the master file and each partner's version through a code script. An editor at MORPC reviews the changes to ensure compatibility with the LBRS standards' and file configuration. Quarterly meetings among the Franklin County LBRS power users provide a forum for technical issues to be addressed and also serve as opportunities for MORPC to advocate approaches to make data collection and maintenance more uniform among the LBRS partners.
Figure 8. Configuration of the Franklin County LBRS system.
OGRIP provides standards for data collection and maintenance for all participating counties. The first guidance was issued in 2005 and revised in 2007 to address the modeling of roads, overpasses, and roundabouts, as counties indicated they wanted to include more detail in their LBRS data. OGRIP based its standards on the commonly used National Emergency Number Association (NENA) standards for street names and addresses.44 The benefit to using NENA standards is that the statewide LBRS data can eventually be incorporated into NextGen 9-1-1,45 a cloud-based emergency response system that the State is interested in pursuing.
While other counties across the State have hired consultants to collect centerline and address information, MORPC favored building off of existing datasets from partner organizations to foster a sense of ownership and responsibility to maintain their LBRS data. Because the format and content of the various participating agencies' data were so varied, a consultant was hired to develop a base file of centerline and address data from the existing datasets of the participating organizations. This required manipulating the data to meet OGRIP's standards for the LBRS program.
Configuring the base file was time-consuming and complicated—partners' datasets needed to be linked through common data structure and field names with unique identifications. Moreover, the topology of the line work, or how the features share geometry, needed to be adjusted to assure connectivity. In addition, relationships needed to be built between the line segments and address points. While additional fields can be added locally as needed to accommodate legacy data processes, the structure of the shared LBRS files is based on standards provided by OGRIP and cannot be altered. For example, adding roundabouts, cul-de-sacs, and other features must be drawn according to OGRIP guidelines. Because these requirements added a level of complexity that most partners had not previously encountered when building their own GIS datasets, the consultant developed a manual for data entry. MORPC also held training sessions as the Franklin County LBRS files were launched.
Since the Franklin County LBRS tool was established, several municipal safety services have been using the data for its emergency response activities. Some communities have also used the LBRS files to coordinate snowplowing and paving programs on shared streets. The file can also be used to coordinate street maintenance programs so communities can share costs. MORPC is unsure of the extent that smaller communities currently use the file for their business activities.
At the State level, once the LBRS data are integrated into OGRIP, they can be referenced by local, regional, State, and Federal governments to support emergency response, planning, and other maintenance and service activities such as paving and snowplowing. The LBRS data are also used to help meet the State's Federal transportation safety data reporting requirements. ODOT intends to knit all county-level files into a statewide system in the future. Requiring that the files are maintained and updated by the local communities relieves ODOT of the responsibility of tracking municipal roadway data. Franklin County LBRS data are submitted to OGRIP and are currently available for download through OGRIP's website.46
Some of the participating partners of the Franklin County LBRS system do not have access to the full suite of ArcGIS tools. The Franklin County auditor and engineer collect road and address point data, respectively, from these partners, and edit the LBRS files on their behalf. MORPC is developing a web-based ArcServer application that will allow nonpower-users without ArcGIS to add information through a web application by drawing an overlay onto an image of their file.
MORPC encountered several challenges in developing a community cloud platform for the Franklin County LBRS data:
Building the LBRS base file and editing data took more time than anticipated.While MORPC had institutional capacity to manage and analyze data, building the LBRS files required new expertise and significant staff time. To build trust, all partners were encouraged to participate in selecting a consultant to build the base file. MORPC's IT staff then had to speak with each of their partner agency counterparts to develop a method to connect them to the LBRS file and obtain their data.
Integrating data can require changing institutional practices to implement common fields and data structure. For this reason, MORPC emphasized the benefits of having access to a larger, more comprehensive dataset. Because MORPC wishes to encourage continued partner participation by not overburdening partner staff, the agency took on the responsibility for addressing data discrepancies that often arise as changes are made to the data. For instance, adding alleys to the centerline file may break line segments or be inconsistent with other jurisdictions' data. MORPC frequently must address maintenance issues as the file evolves, which has required more staff time than originally anticipated.
MORPC believes the benefits of using a community cloud configuration for the Franklin County LBRS files include increased opportunity for collaboration and the reduction of redundant services and data collection/maintenance. Use of the cloud enables the maintenance of an accurate, centralized, regularly maintained centerline and address point file that adheres to an agreed-upon set of standards, which encourages users' confidence in the data as it is used as a base map for various business activities.
As many counties around the State prepared to participate in OGRIP's LBRS program, they were able to learn what types of data were being collected within their own jurisdiction. Beforehand, local agencies were often unaware of the data their counterparts in the county were collecting. This process helped them to discover new data resources or areas of redundancy. Many agencies responded to these new opportunities for data collaboration by turning to cloud technologies. Approximately eight different State agencies in Ohio now use LBRS data to support activities such as tax district determinations, business relocation efforts, and others.
OGRIP also noted that its transportation safety data is of higher quality than what is currently mandated by Federal regulations due to the ability to better locate crash locations using LBRS data (90 percent of crashes are currently geolocated on a roadway as compared to 40 percent prior to implementation of the LBRS files). The standards and regular updates made easier by cloud technologies facilitated this improvement in its data quality.
Shortly after MORPC began working with a consultant to build the web-based tool, Esri released ArcGIS Online. MORPC is currently considering whether to continue with its web-based tool development or if ArcGIS Online will meet its needs. MORPC noted potential security concerns, however, about releasing partners' data to a third-party entity as well as cost concerns.
Based on feedback from power user quarterly meetings, MORPC would like to expand the LBRS files to include other data such as bikeways and to make the information available to the public through an online mapping tool. Data such as capital improvement programs, pavement schedules, and other datasets may also be considered. Adding new types of data would require building additional databases, as well as expanding the MORPC server database capacity. MORPC's goal is to work with the power user group every six months to determine priorities for adding new data to the files.
ODOT does not have immediate plans to use the cloud as part of its OGRIP activities but would like to locate all its statewide data, including LBRS data, in a centralized location. A cloud configuration may be considered in the future.
UPlan47is a cloud-based mapping tool that compiles, integrates, and displays a broad range of data from many different sources within the Utah Department of Transportation (UDOT), other Federal, State, and regional agencies, private utility companies, and the Utah Automated Geographic Reference Center.48 Initially, UDOT intended UPlan to primarily support transportation planning activities. Over time, the tool has expanded to support other business functions, including asset management, safety, operations, and maintenance. UPlan now provides a “one-stop shop” for users in UDOT and other agencies to quickly access transportation and related information, assist UDOT staff in performing business tasks more easily, and improve collaboration between UDOT and partners.
In 2007, UDOT staff members began to consider developing a collaborative, interactive geospatial information portal for spatially enabled transportation and environmental data. The portal was intended to make this information, much of which was previously available only in tabular format, more accessible to UDOT staff and partners. UDOT investigated various tools other State DOTs were using that might serve as a model for UDOT's tool, but determined that existing applications did not have the entire range of capabilities that UDOT wanted. Therefore, UDOT decided to create its own tool.
Between 2007 and 2009, UDOT developed the first version of UPlan using custom code built onto an Esri ArcGIS Server platform. Using an ArcGIS Server platform meant that UDOT had to host all of the tool's data on its own servers and manage a web-based interface that used Adobe Flash as its platform. Maintaining the custom code and interface, however, created an unsustainable workload burden on staff. For this reason, UDOT began evaluating a second version of UPlan that used ArcGIS Online,49 an out-of-the-box Software as a Service (SaaS) package. UDOT was introduced to ArcGIS Online at the 2011 Esri Users' Conference and determined that this platform would be the most effective way to support a second version of UPlan.50 UDOT and Esri collaborated to adapt UPlan for ArcGIS Online.
UPlan is an example of a “hybrid cloud.” Nonsensitive information and data that do not need frequent (e.g., daily) updates are stored in Esri's cloud environment. Sensitive data and information that require frequent updating are stored on an internal ArcGIS server behind a UDOT firewall and are only available to UDOT users. UDOT does not provide any formal user training, although it has developed a UPlan training manual and short training videos that are posted on YouTube.51 UDOT also encourages users to access Esri's ArcGIS Online training videos on the company's website.
Per Esri's ArcGIS Online policies, UPlan allows for two general types of users. Any individual with web access can use UPlan for free without logging in. These public users can access and view a subset of the application's data that are public content. Agencies can also establish organizational subscriptions (beginning at $5,000 annually), which allow a limited number of individual users within an agency to access UPlan and manage information, both private and public, in an ArcGIS Online environment. Organizational subscriptions offer users more functionality than public users, and they are able to create and make public a variety of maps, as well as analyze and manipulate data via Esri's cloud environment. Designated UDOT staff and consultants have privileges to publish content and view sensitive data, such as Fatal and Serious Injury crash locations within UPlan, as well as other information viewable only to subsets of registered users.
Users can customize how they view these data, including choosing a desired base map, and can edit data to add their own shapes and features along with descriptions. All data layers are searchable, so a user can type in key words to narrow down the layers visible on the map (see Figure 9). Users can also choose to view presaved maps, which they can overlay with their own customized set of data.
Figure 9. Screenshot of customized topographic base map, with environment and parcel data added.
While UPlan's user group has expanded beyond UDOT staff, UDOT has maintained its role as the lead agency for making strategic decisions about UPlan. However, UDOT intentionally adopted a decentralized management structure for UPlan as it believes individual data owners are best able to ensure data quality. This frees UDOT to focus on increasing access to information instead of maintaining data. Most data owners directly upload information or updates to UPlan using an automated process, though three of UDOT's GIS staff members still act as “gatekeepers” to ensure uploaded data meet minimum requirements. Aside from these responsibilities, UDOT believes that a user-driven approach to data maintenance is the most effective way to encourage information sharing and innovation. A more centralized structure may be adopted in the future.
UPlan records its own usage and quality-control metrics. For example, each data layer is associated with a star rating derived from user rankings and user-submitted comments (see Figure 10). The tool shows the number of views each data layer has received. UDOT's Engineering Technology (ET) staff evaluate how many views UPlan has received, the number of maps developed, and what data are most frequently downloaded. Staff then use this data to evaluate which maps and data to feature on the homepage, to determine if people are using the platform effectively, and to organize data for certain topics.
Figure 10. Screenshot of metrics for the Utah Unified Transportation Plan Map in UPlan.
The cost for UDOT's enterprise ArcGIS Online license is approximately $17,500 annually. UDOT has a credit account set up to use ArcGIS Online; credits are deducted for use of the platform but UDOT does not have to pay for bandwidth associated with uploads or downloads. Since most commonly used data are saved in Esri's cloud environment, UDOT has not encountered any internal challenges related to its own server storage space.
UDOT's approach to internal data collection for UPlan has evolved over time. During UPlan's early phases, staff members supporting the tool would approach others within the agency, explain the purpose of the tool, and collect the desired data from these other staff via flash drive. Some staff members were hesitant to share data because they did not fully understand how the information would be used. Ultimately, UDOT found that it was most effective to demonstrate UPlan to these staff and emphasize how the tool could support business needs. In a few cases, UPlan staff found that some data owners had not previously viewed their data in a geospatial context. Once these data owners saw their information displayed on a map, they recognized how the tool could support new analyses. Generally, when staff saw the tool operate and understood its benefits, they were more comfortable sharing data from their respective disciplines.
UPlan data now include files from UDOT sources, online sources, and numerous agencies. One of the primary sources of internal UDOT data is UGate, which is the agency's enterprise GIS database. UGate links to all of UDOT's business data and provides UPlan with the majority of its enterprise content. UPlan also accesses data available on ArcGIS Online from any number of external agencies, groups, and individuals. Users can access these data via a search feature embedded in the UPlan tool. In addition to this information, Esri maintains its own ArcGIS Online data files, which comprise a large amount of transportation infrastructure and demographic information, as well as 12 different base maps (e.g., imagery, streets, topography, etc.). The first version of UPlan contained several hundred data layers before it was integrated with ArcGIS Online. Now, with full integration complete, the second version of UPlan offers access to thousands of layers from sources that include ArcGIS Online, and GIS servers or files from which data owners have uploaded their own data.
UDOT distinguishes between “static” and “dynamic” data. Static data are updated infrequently (e.g., annually) while dynamic data are updated regularly. Currently, about 75 percent of UPlan's data are static, and the remainder are dynamic. UDOT aims to have a higher percentage of dynamic data in the future. Currently, UDOT's IT staff assists data owners in writing scripts that allow for automated updates, although there is no formal schedule for data updates. Data owners can determine how frequently their data should be updated or modified and can decide how much information they want to share. For example, UDOT's Traffic and Safety Division shared some general accident data through UPlan but restricted access to detailed crash information (currently, only two UDOT staff members can view these data on UPlan). Overall, data owners are responsible for maintaining and updating their information, which includes performing quality control checks.
Since UPlan is configured as a hybrid cloud (e.g., some data are stored on UDOT servers while other information is stored on Esri's cloud), the agency can use Esri's cloud storage capabilities for ad hoc or basic data needs and extra capacity, and dedicate more space on local infrastructure for complex data storage. UDOT has also encountered challenges in using its own internal data storage to distribute draft data content, making cloud use a flexible, attractive option.
UDOT has not created any formal directives requiring the use of UPlan for certain business activities (e.g., long-range planning). UDOT believes that as people experience the benefits of UPlan and grow more comfortable using it, they will naturally develop a sense of ownership and will want to continue using UPlan to support their own business areas. Additionally, UDOT noted that the tool is expanding so quickly—both in terms of available data as well as its user base—that having formal directives might limit users' creativity and ability to collaborate.
As UPlan grows, UDOT is working to ensure UPlan remains useful by keeping tools simple and engaging both management and users in the tool design process. For example, as one result of this collaboration, UDOT GIS specialists are now able to show all Statewide Transportation Improvement Program (STIP) projects through UPlan using its iMap tool. UDOT has updated its databases to spatially define STIP projects based on the State's linear referencing system, and new data associated with those projects are flagged for publication on UPLAN. Anyone within the State, including regional agencies and the public, can now see and interact with planned projects, which helps agencies communicate project priorities. After a tool has been created, UDOT noted that it is important to ensure that people understand what the tool can do and are able to use it for their day-to-day jobs. UDOT also believes it is important to consider the value of off-the-shelf software. UDOT experimented with using custom code for UPlan but found that this created a larger workload due to ongoing maintenance requirements. UDOT found that buying off-the-shelf software and customizing it as necessary helped keep staff-related costs down and thus reduced risk for the agency. Additionally, this approach allowed staff to spend more time on strategic tasks rather than on maintenance and upkeep.
UDOT has informally collected anecdotal evidence, along with a smaller amount of quantitative evidence, to assess UPlan's effectiveness. UDOT anticipates developing formal performance measures in the future, particularly to help evaluate how UPlan has led to time- and cost-savings. Overall, UDOT believes that use of UPlan:
Supports new collaborations and strengthens partnerships both within and outside UDOT.UDOT has many examples of new collaboration that resulted from UPlan. For instance, in the past, there were few opportunities for UDOT and Utah Department of Wildlife Resources (DWR) staff to engage in dialogue and information sharing. UDOT staff members would provide a small paper map of a planned transportation project for DWR staff to provide feedback on potential natural resource impacts. This proved difficult since the map was static and could not contain detailed information. Now, DWR staff members have made wildlife data, such as animal migration paths, available on UPlan. Using UPlan, UDOT staff can easily overlay wildlife data onto a map of a planned transportation project and share it with DWR. The DWR can then manipulate the map to assist with its analysis and provide quicker feedback based on the best information available.
UDOT has also forged better working relationships with several of the State's utility companies as a result of UPlan. Prior to developing the tool, UDOT did not have opportunities to share data with utility companies until a project's construction phase. Conflicts would occur when utility companies would identify issues with a project's alignment that could not be easily resolved at a late stage. Now, using UPlan, UDOT has made information on planned transportation projects available to utility companies. These companies can better understand UDOT's priorities and respond earlier in the project development process, reducing the potential for conflict and streamlining project development. UDOT is currently developing a memorandum of understanding to formalize how data will be shared with utility companies.
Realizes cost- and time-savings.UDOT estimated that its staff used to spend 80 percent of its time collecting and managing information and 20 percent of its time on strategic tasks; this has now been reversed due to UPlan. While UPlan does not eliminate the need for on-site investigations, it minimizes “guesswork,” which saves time. For example, to support analysis of the State's energy development activities, GIS analysts developed an energy map using UPlan that contained information about energy extraction and production across the State.52 Prior to UPlan, conducting this type of analysis would have required more effort and time, as staff would need to investigate where relevant data were stored, contact data owners, determine how to extract the information, and geocode the data. In contrast, the energy map was created within a few days using UPlan and is available for future analyses.
UDOT also developed a Planning and Environment Linkages (PEL) tool for use with UPlan, which assists with streamlining project development and delivery. Specifically, staff can use the PEL tool to better assess how transportation project alternatives might affect natural resources, and to develop categorical exclusions (CE) and related analyses. Previously, CE determinations could take days or weeks, but with UPlan's PEL tool they take only minutes. Developing a CE now costs approximately $1,000 instead of roughly $50,000. Additionally, the reports the tool creates are more accurate and resource agencies have more confidence in the information, strengthening relationships between UDOT and resource agencies.
One challenge faced by UDOT is that even user-added and user-maintained data requires quality control. UDOT GIS specialists use a workflow process that transforms UDOT's business data into GIS data available in UGate and for web-based consumption on UPlan. Specifically, they use a spatial Extract, Transform, Load (ETL) tool to convert tabular data into location data. UDOT believes the ETL process is cumbersome and time-consuming, and the agency is looking for a new strategy of converting its existing data. Generally, UDOT faces the challenge of ensuring the UPlan data and platform are useful to all levels of staff and the public, while avoiding the duplication of data.
UDOT anticipates that UPlan will continue to evolve over time as more information is added, more users become comfortable with the tool, and the agency uses UPlan to support more of its business processes. For example, UDOT might develop public involvement tools that allow the public to comment on projects displayed within UPlan.
Currently, UDOT is developing a UPlan template map that helps the agency respond to the requirements of the Moving Ahead for Progress in the 21st Century Act (MAP-21). A UDOT staff person could use the template to easily build highly detailed, customized maps that display features that respond to a particular MAP-21 requirement. UDOT is working with other States and FHWA to develop a national MAP-21 template.
UDOT is also working with Esri to determine whether there might be a method to develop a national-scale geospatial tool similar to UPlan that could combine information currently available in different State' MAP-21 maps or others (e.g., highway performance monitoring system [HPMS] maps53) to assist States in responding to MAP-21. UDOT would also like to partner with FHWA in this conversation to better determine what information (e.g., roadway functional class, freight flows, and intermodal activity) States would want to appear on the template and what information States would want to customize. UDOT has informally talked with other agencies about this effort, including Washington State DOT, which has expressed interest in working with UDOT to coordinate MAP-21 information. In the past, UDOT has found sharing data with bordering states about traffic, construction, and safety issues useful.
UDOT is also partnering with a number of other States to assist them in developing their own State applications similar to UPlan. Many of these partnerships are being advanced as part of the AASHTO Technology Implementation Group (TIG). The TIGs provide resources to transportation agencies to advance select transportation technologies and innovations. UDOT and the Idaho Transportation Department (ITD) jointly worked with AASHTO to establish a TIG comprising 13 States, including Utah and Idaho.54 This TIG focuses on exploring how to best build and use cloud-based, collaborative geospatial tools such as UPlan in other States beyond Utah through site visits with other States. UDOT is conducting site visits with other TIG States to share UPlan's framework and discuss ways that the TIG States can implement similar tools. Esri and Bio-West, a consulting firm, are providing pro bono technical capabilities to assist the TIG States with tool implementation.
Washtenaw Area Transportation Study (WATS) is a multijurisdictional agency responsible for transportation planning in Washtenaw County, Michigan. WATS serves 325,000 residents in 27 cities, villages, and townships, including the City of Ann Arbor. Recently, WATS began using cloud-based systems to support long-range transportation planning activities. In the past, WATS had difficulty soliciting what it believed to be a meaningful level of public participation in its long-range transportation planning process. In response, during the development of its 2040 long-range transportation plan (LRTP), the agency created transportation deficiency maps using Google Maps and Google Fusion for the public to access online as part of its 2040 long-range transportation plan (LRTP) development. WATS also supplemented their LRTP project maps with an online collaborative tool called Mi Community Remarks, which is used to solicit and record public feedback on the maps. The agency is also using Google Fusion and Google Docs to share data and information both within and outside the agency.
WATS' transportation deficiency maps show transportation facilities, infrastructure, and other elements of the transportation system within the agency's jurisdiction that fail to address the needs of all users, or will likely require improvement within the LRTP timeframe. In the past, WATS produced paper deficiency maps as part of the LRTP development process and sought input from community members.
Since early 2012, several WATS staff members have become familiar with cloud-based tools such as Google Maps and Google Fusion. Google Maps is a free online mapping service that both displays and allows users to display and store spatial information. Google Fusion allows users to store and share tabular data, as well as to easily visualize the data in charts, graphs, and maps. WATS decided these tools could more effectively convey deficiencies in the transportation system to the public, particularly during public meetings where there is a need to quickly and easily share information in an interactive, easy-to-understand format. In previous public meetings, WATS would print paper maps and spreadsheets containing information about deficiencies. By displaying these maps on Google maps with iPads staff brought to public meetings, the public could zoom in and out and click on individual deficiencies to find out more information about each one.
To create its Google-based transportation deficiency maps for the LRTP effort, staff members compiled up-to-date tabular information and shapefiles on deficiencies from a variety of existing sources, including safety data from law enforcement, congestion data from WATS' travel demand model, transit data from transit providers, and bridge data from a State database. Personnel then assembled these data using WATS' GIS program, TransCAD,55 uploaded them into Google Fusion tables, and mapped them using Google Maps (see Figure 11). WATS then displayed these maps on iPads at public meetings in order to gauge the accuracy of deficiencies already listed and identify new ones. WATS also made Keyhole Markup Language (KML) versions of the maps56 available from WATS' website and social media such as Twitter. By providing a deficiency map using Google Maps, WATS allowed the public to both view the entire study area and zoom in to specific deficiencies without ever leaving the webpage.
Figure 11. Transportation deficiency map developed by WATS using Google Fusion and Tables. (www.miwats.org/wats/leftside/prgpln/LRP/2040/2040LRPDeficiencies.html)
After WATS collected feedback on the transportation deficiency maps, local transportation agencies proposed improvements to include in the LRTP. WATS decided to use cloud technology to solicit and accept real-time, public feedback on the resulting proposed project maps. WATS used an application called Community Remarks, a private, Google-based community participation tool. WATS decided to use the tool because its staff currently has limited database programming or Structured Query Language (SQL) expertise available to develop a customized website that could collect feedback. This tool was recently used by the Ann Arbor Transportation Authority (AATA), the region's transit provider, in developing its Countrywide Master Plan.
To customize Community Remarks to best serve the LRTP process, WATS worked with a consultant and with PlaceVision Inc., the Community Remarks developers, to create a custom application called Mi Community Remarks. The customization cost approximately $4,000. Data maintenance and storage for the tool is a third party contractor's responsibility.
Mi Community Remarks, available on WATS' website,57 displays a map of Washtenaw County. Pins on the map, color-coded by project type (e.g. bridge, intersection improvements, non-motorized) indicate the locations of proposed transportation projects in the LRTP (see Figure 12). Users can choose to display one type of proposed transportation project at a time.
Users select a project on the map, add their comments, and suggest new improvements by adding a “new project” as a pin to the map. They can also view others' comments and, similar to some social media applications, reply or “like” or “dislike” these comments. WATS left the tool open for public comment during a 45-day open period and received 100 mostly high-quality comments. The majority of the comments were related to non-motorized projects, and many of the comments were added by transportation professionals. The comments were analyzed according to location and jurisdiction, and will likely be included as additional notes or appendices in the LRTP. The comments may be added to a list of suggested unfunded improvements.
Figure 12. Maps in Mi Community Remarks show proposed projects in the LRTP depicted with colored pins.
In the past, WATS and its partner agencies had difficulty sharing geospatial map files because some of the smaller partner organizations it works with have lacked GIS programs or the technical expertise to create and share large GIS files. Small email server space has also limited WATS' file-sharing abilities.
To address these issues, WATS now uses Google Docs, Fusion Tables, and Drive58 to send data and map requests to partner agencies. Rather than sending large data files, WATS can now send a weblink to a map or table stored in Google Docs or Fusion Tables. WATS also uses Google Drive instead of its own server to store blog posts for the blog it maintains59 to provide the public with updates and information on how to participate in the LRTP process. This has simplified the blog posting and file editing processes, freeing up space on WATS' server. WATS also used Google Docs to write the majority of its LRTP document, which allows collaborative editing outside the office.
WATS reported the following lessons learned in its experiences using cloud-based technologies:
Cloud technology provided numerous benefits to WATS, its partner agencies, and the public. WATS, a relatively small agency with limited budget and staff, was able to enhance and streamline its business processes at a low cost. Using Google Fusion and Google Maps has made it easier to develop and distribute transportation deficiency maps to a broader audience; in addition, cloud-based applications enabled the maps to be more interactive and publicly accessible than previous paper-printed maps. While learning how to use Google Fusion and Google Maps required some staff time, there were no external costs associated with these tools, and WATS did not face costs associated with paying for a custom application.
Partner agencies were able to take advantage of the free storage space offered by Google Docs and Fusion Tables to share data with partner agencies. This helped streamline agency response to requests for feedback on maps and allowed agencies more flexibility in how they share data.
WATS enhanced collaboration with its stakeholders by using cloud-based technologies. The project maps on Mi Community Remarks, for example, provided an interactive platform through which the public could communicate directly with WATS on their own time and develop new and improved ideas for the LRTP. Setting up a map (e.g. transportation deficiency maps) online allows a partner agency and/or the public to interact more easily with the data than would a paper or static PDF map containing the same information. Using Google Docs and Drive to share documents with the public and partner agencies also supported a more dynamic, collaborative environment by allowing users to share comments and data more easily.
WATS has not yet empirically evaluated the effectiveness of the cloud technologies it used but plans to continue to integrate more cloud-based applications into agency business processes moving forward. The agency foresees increasing the use of tools such as Google Drive for data storage and supporting a mobile office environment in which employees working from home or in off-site locations can use an Internet connection to access internal agency information. In addition, WATS would like to share all maps internally, with partner agencies, and with the public using the cloud. For future LRTPs, WATS will most likely use collaborative technology similar to Mi Community Remarks to solicit public feedback.
|Agency||Name||Title||Work Phone||Work Email|
|Utah DOT||Frank Pisani||GIS Manageremail@example.com|
|Bert Granberg||Director, Utah Automated Geographic Reference Center (AGRC)||firstname.lastname@example.org|
|Steve Quinn||Technology Directoremail@example.com|
|John Thomas||Planning Directorfirstname.lastname@example.org|
|Bio-WEST||Andrea Moser||GIS Consultant to UDOT and ITDemail@example.com|
|Idaho Transportation Department||Bill Shaw||Senior Plannerfirstname.lastname@example.org|
|Maranda O'Bray||Transportation Planneremail@example.com|
|Erika Bowen||Planning and Program Management Unit Directorfirstname.lastname@example.org|
|Washtenaw Area Transportation Study||Ryan Buck||Acting Executive Directoremail@example.com|
|Mark Ferrall||Associate Transportation Plannerfirstname.lastname@example.org|
|Mid-Ohio Regional Planning Commission||Nancy Reger||Deputy Director of Transportationemail@example.com|
|Cheri Mansperger||GIS Managerfirstname.lastname@example.org|
|Ohio DOT||David Blackstone||GIS Manager
Office of Technical Services
|Jeff Smith||Spatial Data Infrastructure Manager
|Maryland State Highway Administration/Maryland Transportation Authority||Kaushik Dutta||IT Program Manager
Maryland Transportation Authority
|Mike Sheffer||Assistant Division Chief/GIS Coordinatoremail@example.com|
|Barney Krucoff||State Geographic Information Officerfirstname.lastname@example.org|
|Jason Keppler||Senior GIS Analyst, State Geographic Information Analystemail@example.com|
|North Carolina DOT||John Farley||Manager, GIS Unitfirstname.lastname@example.org|
|U.S. DOT - Federal Highway Administration||Mark Sarmiento||FHWA Office of Planningemail@example.com|
|U.S. DOT - Resource Center||Ben Williams||Metropolitan Planning Specialist||404-562-3671||Ben.Williams@dot.gov|
|U.S. DOT - Volpe Center||Jaimye Bartak||Transportation Analyst|
|Paige Colton||Environmental Protection Specialistfirstname.lastname@example.org|
*Those whose names are bolded participated in the interviews. Those whose names are italicized participated in the peer exchange.
Goal: Share lessons learned, best practices, and challenges in using cloud technology for geospatial applications.
|Thursday, May 9|
|8:30 - 9:15||Welcome, Introductions, and Background||USDOT Volpe Center and Idaho Transportation Department|
|9:15 - 10:30||Demonstrations/Presentations 1||
|10:45 - 12:00||Roundtable 1: Cloud Definitions and Background||All Participants|
|1:00 - 1:45||Overview of FHWA GIS and Cloud Activities||Federal Highway Administration|
|1:45 - 3:00||Demonstrations/Presentations 2||
|3:15 - 3:40||Demonstrations/Presentations 3||
|3:40 - 5:00||Roundtable 2: Cloud Configurations||All Participants|
|5:00 - 5:15||Day 1 Key Points/Wrap-Up||Federal Highway Administration|
|6:00||Informal Dinner||(Location TBD)|
|Friday, May 10|
|8:00 - 8:15||Day 1 Re-cap||Federal Highway Administration|
|8:15 - 9:30||Demonstrations/Presentations 4||
|9:30 - 10:30||Roundtable 3: Implementation and Data Considerations||All Participants|
|10:45 - 11:45||Roundtable 4: Next Steps and Areas of Opportunity|
|11:45 - Noon||Day 2 Key Points/Wrap-Up||FHWA|
November 14, 2012
|Est. Total Savings FY07-11||Description||Est. Savings per year (future)|
|Corridor Inventories||$78k||Collect and Review Data
Conduct Environmental Scan
Develop Inventory Report
|GIS Map Requests||$81k||Simple map requests
Assume 25% per 1 staff member
|ITIP Publication||$127k||Draft STIP and associated public involvement printing costs||$7k|
|Construction Change Orders||$163k||Breakdown in communication and coordination with utilities||$20k|
|DMV Over Legal permit requests||$34k||Routing permit requests
Assume 5% per 6 temporary records specialists
|Environmental Documents||$1.75M||Compiling data for environmental documents
(ITD and consultant costs combined)
|Corridor Inventories||Collect and review data, conduct environmental scan, develop inventory report|
|FY||KN||District||Project Name||Estimated Cost Savings||Work Tasks|
|07||9801||D2||SH-8 Moscow to Troy Corridor||$13,200||
|07||9967||D3||Idaho 55 Access Management Plan||$10,800||
|07||9968||D3||US-95 Access Management Plan||$20,300||
|08||9972||D3||US 20-26 Environmental Scan||$9,800||
|09||9971||D3||Idaho 45 Environmental Scan||$13,600||
|11||12295||D1||SH-53 Access Management Study||$10,000||
|Total Estimated Savings for FY07-11||$77,700|
|All||Every District is annually
expected to create a new
corridor plan or refresh an
Assume $10,000 savings
|SH-53 Access Management Study||$60,000|
|GIS Map Requests||Assume 5% per 1 staff member to perform department-wide simple map requests|
|FY||District||Project Name||Estimated Cost Savings||Work Tasks|
|07-11||HQ||Statewide Planning||$81,250 (total)||
|Estimated Savings per
Future Fiscal Years
|HQ||Assume continued potential savings in
simple map making requests.
|ITIP Publication||Draft ITIP and associated public involvement printing costs|
|Total Estimated Savings for FY07-11||$127,000|
|Estimated Savings per Future Fiscal Years||HQ||Assume future potential savings in ITIP and concurrent public involvement printing costs||$7,000|
|Construction Change Orders||Only captured specific examples where savings could be determined. Sporadic due to data availability.|
|07||8465||1||SMA-7155, HONEYSUCKLE AVE TO MILES AVE, HAYDEN||$6,350||
|08||9509||3||SMA-7803, INT CHICAGO ST & 21ST AVE, CALDWELL||$2,881||
|09||6961||4||US 93, FALLS AVE TO POLELINE RD, TWIN FALLS||$11,000||
|10||8065||1||US 95, WYOMING AVE TO SH 53, HAYDEN||$10,000||
|10||12276||1||STC-7208, FRONTAGE RD for US 95; S of LANCASTER TO BENTZ||$17,000||
|11||9791||1||US 95, GARWOOD TO SAGLE, ATHOL STG||$45,000||
|12||8670||3||SH 55, N FK PAYETTE RV BR, CASCADE||$70,500||
|Total Estimated Savings for FY07-11||$162,731|
|Estimated Savings per Future Fiscal Years||ALL||Assume future potential savings in better earlier communication and coordination with utilities.||$20,000|
|DMV Over Legal Permit Requests||Assume 5% savings per six temporary records specialists|
|07-11||DMV||(6 temps) x (8 month/12) = 4 FTE
(4 FTE) x (2080hrs/yr) = 8,320 hrs
(8,320 hrs) x (5%) = 416 hrs
(416 hrs) x ($16.50/hr) = $6,864
|Estimated Savings per Future Fiscal Years||HQ||Assume future potential savings in ITIP and concurrent public involvement printing costs.||$7,000|
|Environmental Document Preparation||Based on estimated hours spent compiling data on a project.|
|Estimated Savings per Future Fiscal Years||ALL||Assume future potential savings in environmental document preparation for both consultants and District staff.||$350,000|