Enabling Better Decision Making Among DOTs

Integrating enterprise data

For many Departments of Transportation (DOTs) and roadway agencies, the days of rapid highway construction have passed. DOTs now primarily focus on preserving existing investments and maximizing the performance of built infrastructure. Effective decision making with respect to the mix of operational improvements, investments to advance safety, and maintenance spending requires access to a wealth of information to help drive these decisions. And while almost all of this data is available within these larger organizations, few have been successful at bringing that information together in ways that could help foster more intelligent decision making.

The root of this problem stems from the original development of these data and information systems. Each department often developed its specific functional applications (whether for pavement management, structures, or safety) independently and often using different ways of organizing and storing information. As a result, state DOTs commonly find numerous linear measurement and relational database systems being used to capture and manage the various inventory information and data. And for many agencies, this has been the central hurdle preventing them from optimizing their data management practices.

At the same time, geospatial technology has come a long way toward removing this obstacle. GIS now brings together and integrates disparate data from across the enterprise, helping organizations more effectively exploit their vast information stores to carry out their objectives. Because the location of these various assets and roadway information is inherently spatial in nature, GIS provides the foundation for information integration that gives transportation professionals and decision makers unprecedented access to data. With a completely integrated data management infrastructure, they can analyze complex tradeoffs and make more informed decisions.

While many transportation organizations have implemented GIS to help them manage a number of their individual systems, fewer have been successful at using the technology to create enterprise information systems. This remains the central question for information technology professionals and one to which only GIS can provide the answer.

How can enterprise information systems benefit transportation organizations and their constituents?

Terry Bills

About Terry Bills

Terry Bills is the global transportation industry manager at Esri. He has served as a Principal Planner with a regional transportation planning agency, and as President of a transportation-related GIS consulting services company. He has more than 20 years of experience in transportation planning and policy, information technology and GIS.
This entry was posted in Industry Focus and tagged , . Bookmark the permalink.

Leave a Reply

10 Comments

  1. The main goal is to understand that we do not want the keys to your “Castle” only a view from the “balcony”.
    Today we are using ArcGIS.com to share that data from the “Castle” and in fact from many data sources both within the DOT and from outside sources such as cities, counties, transit, rail, etc., The Geo-spatial landscape is bountiful with results that serve many of the communities mentioned above as well as the traveling public. In short, the more information that is available gives one the opportunity to make better decisions.

  2. Bryant Coon says:

    Our enterprise systems have made it possible to pull information from previously disconnected sources in order to more efficiently utilize our limited resources. By combining our traditional survey and ROW data with enterprise environmental, infrastructure and demographic layers we gain the huge advantage of placing our current knowledge into context with additional internal and external influences. While these influences were partially considered in the past, as our transportation systems become increasingly crowded the importance of being able to accurately evaluate the cumulative impacts of these “external” factors is becoming exponentially more important.

  3. Connie Gurchiek says:

    The 25th annual GIS-T Symposium will be held next month (April) in Loveland, CO. As a part of the planning this conference, several of conference coordinators put together a calendar that commemorated the progress made by transportation agencies in the field of GIS. We searched the Web and through past symposium proceedings to remind ourselves of the challenges and hot topics that were discussed through the years. While much of what has been accomplished in transportation GIS is impressive, some of the challenges of more than twenty years ago are still with us today.

    In 1991, one of the first commercially-available dynamic segmentation tools was released. Dynamic segmentation allowed agencies to overlay tabular data from sources that referred to the same linear network, but did not necessarily share the same linear referencing method and whose attributes “broke” at different locations along the network. This advance in technology meant that DOTs no longer had to “pre-segment” their data by creating new route segments any time one attribute along a route changed. This release was announced at my second GIS-T conference, and I naively believed that the biggest hurdle to sharing data had been overcome. In the following 5 years, NCHRP and others developed LRS data models that addressed many of the outstanding issues with the initial LRS and dynamic segmentation models; and while some DOTs implemented concepts of these models, the profession as a whole never fully embraced any one standard.

    So, why are we still struggling with this issue more than twenty years later? I believe that it’s partly because the number and complexity of the data sources at the typical DOT was underestimated. While all DOTs have to annually report a large amount of data in the same format to the Federal Highway Administration (FHWA), many still have to jump through numerous hoops to create these reports. This is because there are no standard collection mechanisms, data storage models, linear referencing systems, or network geometry formats. In addition, each DOT has nuances and anomalies in its data, and no two are completely alike in their approach to GIS and location-referenced information.

    Why not create a standard that all DOTs can follow in each of these areas? In my opinion, that ship has sailed. Too much legacy exists at the DOTs to try to completely change, at least all at once, data collection practices, investments in technology and training, and maybe most importantly, the large number of operational systems that depend on current technical environments and data formats.

  4. I have had the luxury and headache of being the sole creator of linear referenced (LR) data in my department. This has allowed me to make all of the data I gather reference the same network. This definitely improves my ability to intergrate the data. However, I doubt my data would intergrate well into a statewide system, since I had no guidelines to follow and no real reference materials that I was aware of that would have guided my choices on how to design my LR system. So I am sure my design is quite unique. At this point it would be difficult to change to a new configuration if a statewide standard was adopted.

    Nonetheless, I am not against modifying my data design or creating automated derivatives that would facilitate statewide sharing of data. I find it frustrating that Excel is used as the principal means of sharing data with the state, because that format does not communicate or promote any standards in data design. I think it would be nice if a true database template were provided (in Access or dBase) in addition to the Excel format for those who are more oriented to sharing information through databases. This simple step might even promote a discussion on standards or help local jurisdictions gravitate toward a basic state data configuration, without directly and immediately imposing a standard.

    Working at the local level I have invested a significant amount of time in developing tools that help me fairly quickly translate human understandable limits (LIMONITE AVE from 900 FT W VAN BUREN BLVD to 700 FT E VAN BUREN BLVD) to LR limits. County/City road systems rarely have mile post markers in the field for field crews to reference, so such limit descriptions are vastly more common where I work. The tools to support this kind of translation should be more widely available and understood, but it seems everyone has a proprietary way of handling this part of their model or they do not have anyone who can automate and maintain such translations.

    At this point, my biggest challenge is to get my own users to better integrate their external data designs with my data. It has been difficult to get them to preparse their limit descriptions and even more difficult to convince them to validate the street names they use against the recognized spellings in my network. Given that such integration is difficult to achieve within a single agency, it should not be surprising that integration remains a challenge wherever multiple agencies need to share their data.

  5. Jonas Baile says:

    an enterprise information system that allows the community to participate in decision making especially in maintaining the infrastructure assets is worth a challenge.

  6. Dave Loukes says:

    There are numerous reasons why transportation agencies worldwide (this is not a problem unique to North America) have not been more successful in integrating their various engineering information systems (administrative / financial systems have been successfully integrated). I would argue that these data integration difficulties involve both technological and organizational issues. Let’s examine these issues within the context of GIS as an enabling technology in support of enterprise data management for engineering systems.

    Firstly, from an organizational perspective:

    • While central IT has traditionally been responsible for enterprise data standards, it is only recently that many organizations have included enterprise level location standards within this umbrella;

    • GIS support units in many agencies have not been (or have only recently been) incorporated into the corporate IT support structure – this has impeded the development of data integration strategies based upon location;

    • Many engineering data collection and information systems were developed at the business unit level many years ago without consideration for corporate data integration requirements – this has led to the development of multiple location referencing systems / methods (and in particular multiple linear referencing methods) to support field data collection missions by staff based upon business specific sectioning of the highway;

    • There is a substantive amount of legacy data within these disparate systems; and

    • The above systems often adopted different methods to manage asset location changes over time.

    These issues are being addressed – but comprehensive commercial software solutions to fully support them have lagged, in part due to the complexity of the asset network location problem:

    • Support for multiple linear referencing methods, and translation among them, is required;

    • With the widespread adoption of GPS for field data collection, translation between coordinate and linear network asset locations is needed;

    • Temporal translations among all location methods are needed;

    • There is a need to keep changes to the spatial and logical road network data models synchronized;

    • Rigorous life cycle asset management requires extensive data mining and maintenance of asset history – if assets are integrated based upon linear location, this becomes complex as changes to the road network occur over time; and

    • While a central spatially enabled network management system incorporating GIS technologies is best positioned to store and manage asset locations, most asset business data will continue to reside within specific asset management systems (bridge, pavement, safety, etc.) – this implies a need to interface with, and integrate data across, these systems through open system protocols.

    Commercial software solutions are now available. However, in many cases procurement cycles are long. A substantive investment is required to transition to these systems due to the requirement to migrate large amounts of legacy data and (in many cases) implement and institutionalize substantive business process changes required to support them. As a result, executive level support for the investment is needed – and this takes time. In many cases, the business driver is support for life cycle asset management, which often requires buy-in from the political level.

    In summary: we’re getting there, but it takes time. There’s no quick fix to the problem.

  7. Connie Gurchiek says:

    Another, and perhaps bigger, challenge is that even within a single DOT, institutional and political barriers often create unneeded complexity. This issue is further complicated by some personnel’s reluctance to share data, personal technical beliefs and turf concerns, or feelings they must collect their own data to ensure it is correct. In addition, there is increasing demand for sharing data outside the DOTs, particularly with other government agencies and the general public. While there have been excellent advances in the technical aspects of sharing data, many organizational issues still inhibit timely and efficient implementation of the technology.

    Finally, GIS has in the past been mainly a tool used by DOT planning and IT departments. As more and more transportation professionals realize the integrating power of GIS, geospatial tools and applications are making their way into the DOT mainstream. That brings with it the excitement of much more advanced data sharing, but it also brings the challenges to integrate even more types of data. Operations data from Intelligent Transportation Systems, ERP Systems, maintenance management systems, and Engineering/CADD would all be exceptional candidates that would add to decision support at DOTs, but each of these systems bring new challenges to data integration.

    Next month, I will be attending my 22nd GIS-T. I am hoping to be lying by the pool eating bonbons before I have the chance to attend 22 more. However, I truly expect that 22 years from now that those in attendance at GIS-T 2034 will still be solving their data sharing challenges; whether it be temporal data issues, 3D integration challenges, real-time data integration, or data collection and maintenance barriers.

  8. Tom Ries says:

    As we look back, I think many of us had the vision of an enterprise GIS-T implementation for our own organizations. For some of us, it remained a dream. It was all we could do to get enough budget or staff to get something in place, perhaps focused on safety or roadway inventory. Others pursued the enterprise vision by evolution – growing and expanding as opportunities allowed. A few others pursued the enterprise vision by revolution: taking a step back, creating a formal plan, and re-engineering from the ground up. While technology influenced our implementations, I think organizational readiness was key to the chosen approach. So going forward, more successful enterprise implementations will include accomplishing a balance of organizational and technology objectives.

    From the organizational perspective, I recommend objectives that go back to the basics. These are relevant whether one re-engineers or evolves. First, get yourself one of those executive-level, business-perspective, visionary champions. I know this is easy to say, but never give up and make it happen. Consider a mentorship program. Most important, realize and plan that you may need to do this more than once. Second, seek out and show explicit business value: reduced effort and turn-around, or improved measurable quality. The GIS-T community now has case examples to help. Also, you’ll have that champion to help you, right? Third, plan for the enterprise, but implement in pieces. Finally, partner; this includes local or regional governments. Note, partnering in this context is characterized by mutual cooperation and responsibility.

    From the technology perspective, I think the primary emphasis should be services-oriented architectures that are scalable and extensible. First, we must continue to make it easier for our stakeholders to “tap” into the GIS-T band-wagon. This includes more easily consumable services and less on exposing raw GIS-T systems and data. This may be especially true on data update/exchange services due to influences of partnering, mobile technologies, and internal/external crowd sourcing trends. Second, continue to support more diverse and “dynamic” location reference method services. Some linear reference examples include on-the-fly milepoints based on user-defined termini (e.g. across the state or between two street intersections), or reference-offset methods that let business areas directly apply their own features as reference (e.g, sign bridges). Finally, these services must include temporally-aware usage services such as method transformations, overlays, and aggregations (e.g., across carriage ways of divided routes, within carriage ways (lane level), and along carriage ways).

  9. John Farley says:

    A core focus and responsibility of my unit is the Linear Referencing System (LRS) for the North Carolina Department of Transportation. It is a critical piece of our enterprise business process. The LRS has helped to reduce our labor costs, reduce production cycle time, and has significantly improved data quality.

    It has only been within the last few years that our LRS has been mature enough to provide the value and effectiveness it does today. I believe there are two main reasons it took so long for us get where we are, and perhaps why it is still not more wide-spread among DOT’s (at least on an enterprise level).

    First, it is not easy! Developing and implementing an enterprise LRS and the impact that it has on all the incumbent workflows is difficult and complex. On paper, and LRS can seem quite simple and straightforward. In practice it is anything but. The events or features that are being modeled or represented cover a wide range of issues and topics, many of which are constantly in flux (some daily!). Add to that the underlying network and/or datum which is also dynamic. When you put these factors together and begin to analyze them, you start to see the complexity.

    The second main reason, I believe, has to do with the fact that it was a little lonely out there. There were very, few successful DOT enterprise LRS implementations. To be sure, a lot of good work and research has been done on linear referencing, but enterprise implementations at DOTs were few and far between. Add to that the fact that there were few software tools or products to support LRS on an enterprise level. This meant you were pretty much on your own. Fortunately, this is changing as LRS management products are hitting the market today.

  10. Adrien Litton says:

    One key challenge with any attempt to integrate business information across at transport agency’s enterprise is access to the data itself. Datasets are not only stored and managed using multiple linear referencing methods (LRM), they are often maintained as part of proprietary systems having locked schemas and data access security roadblocks that make it difficult to share data.

    Some vendors have promoted a possible solution by requiring that all data be managed in a common solution suite for pavement, asset, maintenance, etc. There are certain advantages to this approach. DOTs have a single vendor to resolve any issues, there only one data management pattern across the enterprise, and business systems require less up front configuration to inter-operate with one another.

    There are some major drawbacks to the “one system” approach, however, that could make it a deal breaker for many DOTs:

    • Limited choice – While the selected highway data management software may have an excellent offering of one or two modules, others within the same suite may be less than stellar. By implementing a single solution suite, highway departments are limiting themselves from selecting the best of breed highway data management solutions.

    • Enforced lateral change – Change is always met with resistance in any large organization. When the change comes with no perceptible benefits to individual users, such resistance tends to become entrenched.

    • Disenfranchised business units – Groups who are unable to adapt their business rules to the enterprise solution are unable to realize the benefits of that solution. Data cannot inter-operate across systems, at which point it ceases to be an enterprise-level solution.

    GIS can help with this problem by providing a pivot point for all business systems. By temporarily turning business data into spatial data, GIS can let all business units realize the benefits of each others’ data through spatial integration. This approach provides the most flexibility to highway departments and forces the developers of business data management systems to compete more directly with each other on a system by system basis, providing more choice to the users and benefiting the industry overall.