• No results found

Integrating Location-Based Data 72

Chapter 5.  IT Management and Planning 67 

5.4.   Integrating Location-Based Data 72

There are several issues that may arise with data integration involving spatial data. First, having multiple location referencing systems leads to data integration problems if the are no methods for automatically and consistently translating between the systems. WisDOT has three main

referencing systems (link-site, state plane coordinates and log-miles) that cause integration problems. The translation between link-site and photo log-miles is bigger problem but the potential is great for richer datasets if the problem is solved.

The agencies recommend creating a strategic plan specifically for spatial data along with and related to other IT plans. At WisDOT, a strategic planning effort (ISP) in the early 1990’s

created a master plan and enterprise model that lead to the creation of agency’s link-site model to integration linear location referencing methods (mile points, reference points) and cartographic representations. Much of what WisDOT can do now to integrate location data is a result of the time spent in the 90’s through the ISP to create link-site. Currently, they are looking at ways to link the photo-log miles and GPS coordinates to the link-site model.

Other issues arise with the integration of spatial and non-spatial data. Project development staff at the agencies recommends not building applications with the location referencing system embedded in the business data. Otherwise, each update to business data may require an update to the location referencing system. ODOT’s BTRS and GIS are connected in this way. The Division of Planning understands for GIS to be successful they need to work with the IT data warehousing people. The IT staff has to go into the system from time to time to fix the data so that GIS can work with the data and present it. People from both divisions understand the importance of working together.

The agencies also recommend not undertaking the development of a corporate spatial referencing system as a subproject or add-on to the development of a business system. The main reason is that parallel development can be overwhelming to the project team. The likely result is

simplifications to the spatial system that may severely limit its use beyond the immediate application. A rational is that the corporate data model for location referencing and spatial data management should be independent on any particular application. The business system and data would be owned and maintained by business units while location data, location referencing systems, and spatial data are corporate wide. The GIS portion of WisDOT’s WISLR was envisioned to be a corporate data model designed to be the state’s core line work that everyone would use to do overlays. The WISLR project development team concedes that bundling the design and development of the corporate data model for line work with development of the business application for local roads management created a strategic initiative that was too large. In the end, the WISLR application is a success, but the agency did not achieve the corporate data model envisioned. ODOT describes as similar experience in the development of Ellis and the associated BTRS.

Data from map vendors is not a good solution. There are several problems that may arise when agencies use proprietary spatial data sets. Licenses may restrict or prohibit data sharing for more than one application and the proprietary data models impede the ability to update/correct

cartography on the fly. These are only a few of the problems that may occur.

5.4.1 Managing Spatial Data

At each agency, spatial data and metadata are managed centrally within the agency and the IT department has a role in the management. The role of the IT department is in connecting applications to the GIS environment and providing user tools for data integration and

management. At WisDOT, a web interface to the agency’s GIS tools allows centralized development and maintenance for distributed users.

The availability of spatial metadata is not common among state agencies. WisDOT has tools for integrating spatial data but doesn’t have all the metadata needed to support on-the-fly data integration and querying. Geographic Query Language (GQL) is used for queries and reports in ELLIS. The GQL tool has attribute metadata built into it. Attribute definitions are provided (i.e., data dictionary). The use of GQL was considered a success factor. It helped make access through ELLIS easier. The prior system, PMS, relied on project templates and was done in batch mode with no control of output. GQL allows users to work with the data. GQL is an ad-hoc but a user can store standard queries also.

5.4.2 Technical Challenges

Agencies deal with a variety of technical challenges when integrating spatial data and when using the location referencing system and a data integration mechanism. Managing the spatial analysis software platform is part of the agency’s spatial information strategic plan.

Obsolescence of the spatial analysis software platform can lead to mission critical and potentially costly problems. For example, WisDOT’s LCM tools were built to work with a version of ESRI Arc/Info that will not be supported in the future. WisDOT will need to port the LCM tools to new platforms so that some of the agency’s business applications including Meta-Manager can run. If WisDOT’s LCM overlay tools went away, the agency could reprogram Meta-Manager to use a dynamic segmentation approach.

ODOT encountered a technical challenge in connecting the GIS environment to the data warehouse environment-specifically, connecting Intergraph GIS environment to Sybase IQ. ODOT could not find peer agencies that had made the connection. The IT department had to use middleware connectivity software to make the connection.

When WisDOT’s LCM tools were used for developing Meta-Manager, bugs were found in the tool set. Meta-Manager was the first application to use the LCM tools. The agency had to spend resources to fix the bugs. One major flaw was in the tool that converted reference point-based linear events to links. This conversion tool did not appropriately deal with historical reference points and data associated with those reference points (i.e., the tool did not convert historic references).

Chapter 6.

Managing Data Integration Efforts for Systems