MLRS Enterprise Architecture - Intergraph configuration for spatial indexing, work tablespaces...

WH

ITE

PA

PE

R

MLRS Enterprise Architecture Intergraph® Transportation Solution for Managing a Multilevel Linear Referencing System in an Open Enterprise Environment

MLRS Enterprise Architecture

Contents

1. Introduction ................................................................................................................. 1

2. Architecture ................................................................................................................. 2 2.1. MLRS Maintenance Component ..................................................................................................... 2

2.2. Database Component ...................................................................................................................... 3

2.3. Workflow .......................................................................................................................................... 6

3. Functionality ................................................................................................................ 7 3.1. Multiple Linear Referencing Models (LRMs) ................................................................................... 8

3.2. Event Location Stability ................................................................................................................... 8

3.3. Multiple Geometric Representations ............................................................................................... 9

3.4. Multilevel LRS Data Maintenance ................................................................................................. 10

3.5. Temporal Data Maintenance and Analysis .................................................................................... 10

4. Customization Considerations ................................................................................... 11

5. Optional Web Component ......................................................................................... 12

6. Conclusion ................................................................................................................ 13

i


1. Introduction Intergraph® provides geospatially powered solutions that support the management of complex transportation systems. Our transportation solutions focus on satisfying the industry needs for managing, analyzing, and reporting enterprise data through the use of standard development practices and state-of-the-art technologies.

One of the core solutions Intergraph offers for the transportation industry is the Multilevel Linear Referencing System (MLRS). The MLRS serves as a foundation for transportation agencies to collect and manage locationally referenced roadway inventory and condition data.

This document outlines the system architecture and functionality associated with Intergraph’s MLRS.

1


2. Architecture The MLRS Enterprise Architecture is designed to work in an enterprise environment with considerations for other geographic information system (GIS) solutions and generic system access. These design considerations are based on the reality that organizations have adopted many different vendor solutions to meet their diverse business demands. These solutions have evolved to address specific needs in an organization. In parallel, various database technologies and open standards have evolved to provide organizations with a strong platform to meet their architectural needs. Intergraph has embraced these technologies and offers a focused MLRS solution based on industry recognized standards.

The architecture comprises the following primary components:

1. MLRS maintenance component

2. Database component

3. Open standards and Web service components (optional)

2.1. MLRS Maintenance Component The MLRS maintenance components focus on the transportation industry requirements and meet the business requirements associated with MLRS. These tools include:

GeoMedia® Professional 6.1.x – GeoMedia Professional is the foundational software platform for managing spatial data. The software offers a very robust command set for inserting, editing, deleting, querying, and reporting of spatial data. The GeoMedia Professional software also serves as the core platform for a number of add-on products, specialized for a particular workflow.

GeoMedia Transportation Manager 6.1.x – GeoMedia Transportation Manager is Intergraph’s add-on product that provides the tools for managing LRS data. The product supports both single and MLRS models. The product also includes extensions that couple with GeoMedia Transaction Manager for long-term transaction management and GeoMedia Fusion for data conflation workflows.

GeoMedia Transaction Manager 6.1.x – GeoMedia Transaction Manager provides a GUI interface on the GeoMedia desktop for Oracle’s Workspace Manager. You can specify applicable dates during editing and step back in time to view the network as it existed on a specified date.

GeoMedia Fusion 6.1.x – GeoMedia Fusion provides a very robust set of tools for data cleansing and conflation. The product is used in conjunction with GeoMedia Transportation Manager to build conflation rules that support data management workflows.

A description of some of the key functionality associated with the MLRS maintenance components will be provided in later sections of this document.

In addition to the MLRS maintenance components, many clients will have a mix of other GIS, CAD, textual data maintenance tools and websites, as well as advanced reporting tools. Architectural implementation decisions associated with the maintenance components facilitate the widespread use of this data with other vendor solutions.

A typical architectural requirement in many implementations is to provide support for ESRI’s GIS tools. Figure 1 on the following page provides an example of the Intergraph GeoMedia and ESRI Arc tools working together to address the diverse needs of the users, while capitalizing on the wealth of data stored in a spatially enabled Oracle database.

2


Figure 1: This diagram shows how GeoMedia and ESRI Arc tools work together with a spatially enabled Oracle database.

MLRS maintenance components offer you a rich set of tools to manage transportation data. A database maintains data produced from maintenance activities for widespread use and exploitation.

2.2. Database Component

The database component has become a key hub of an organization’s architecture. Database technology has evolved to support various key components of a solution. These components include:

Standard data types – Spatial and non-spatial, accessible by many vendor solutions

Multiple users – Scalable to handle large data volumes and multiple concurrent users

Advanced data management – Spatial data, temporal data, and materialized views

Performance tuning – Ability to optimize the use of data

Backup and recovery – Provides strong tools to ensure system uptime and reliability

In addition to the standard database components, the widespread adoption of these databases and availability of database administrators (DBAs) provides organizations with a sustainable core to their solution.

The MLRS maintenance components work with various database components, including Oracle. You can configure numerous read-only and read/write databases with the system. The MLRS maintenance components connect directly to the database without the requirement for server-side middleware. The components rely on the database for server-side optimization and data management. This approach allows the maintenance components to maintain a high degree of compatibility with various database versions and file formats. Supported database components include:

Oracle (versions 10g, 11g)

Microsoft® SQL Server (versions 2000, 2005)

Microsoft Access® (versions 2000,XP, 2005)

ESRI ArcView Shapefile (read, export)

ESRI Arc/Info Coverage (read-only)

MapInfo (read-only)

Formatted text files (read-only)

3


ODBC data sources (read-only)

CADD files including MicroStation and AutoCAD (read, export)

The optional addition of Safe Software’s FME solution for Intergraph’s GeoMedia software supports other data formats.

For enterprise MLRS implementations, Intergraph recommends an Oracle database, which offers:

Widespread adoption and usage in the market and support by leading GIS vendors

Native spatial data support

Native long-term transaction management support

Heterogeneous data-source connectivity option (connections to other databases)

Figure 2: The MLRS maintenance components work with various database components, including Oracle.

The MLRS maintenance components, outlined in Figure 2 above, work directly with the Oracle database. This symbiotic environment provides a high degree of native database functionality and support for various versions, minimizing upgrade and support concerns. These components will use the database to provide both primary and secondary spatial filters when accessing feature class data by using native database functionality (i.e., SDO_RELATE).

Oracle database support considerations for the MLRS maintenance components include:

Oracle native data types including SDO_GEOMETRY

Support for 2D and 3D data, including true curve data

Attribute and spatial indexes

Coordinate system support (Spatial Reference Identifier – SRID)

4


Spatial metadata 2D/3D data (USER_SDO_GEOM_METADATA)

Full support for Oracle triggers/procedures/database packages

Table partitioning for large tables

Advanced configuration for spatial indexing, work tablespaces

Although the MLRS supports Oracle’s Spatial database functionality, the MLRS’ maintenance components require only minimum functionality of Oracle’s Locator. The maintenance components provide on-the-fly topology and networking functionality and do not conflict with Oracle’s models or the GIS/spatial platforms that support Oracle. As many implementations use advanced spatial functionality in the Oracle database to model various relationships and perform various analyses, Oracle Spatial licensing is recommended.

Although you can use various implementation strategies, these architectural guidelines provide seamless support for multiple vendor solutions:

Primary key that is a number (38,0)

Single SDO_GEOMETRY column in a feature class table

Assignment of an SRID to provide database coordinate transformation support

User_SDO_GEOM_METADATA tables are populated

Spatial indexing is created to enforce specific geometry type input

Standard geometry types are used (point, line, polygon, and associated multi-part geometries, if required)

MLRS maintenance tools enforce spatial validation rules (could also be enforced via Oracle validation triggers – SDO_VALIDATE)

Normalized data model is de-normalized to provide simplified or materialized views of the data to other clients

For advanced geometry features, the system can maintain additional geometries to meet your needs. These include:

Measured values on a vertex (“M” values)

Advanced curve data stroked for consumption by ESRI clients

The database architectural decision discussed above not only supports the MLRS maintenance tools, but also provides support for additional vendor solutions to access this data and minimizes the threat of vendor lock-in and issues associated with proprietary data formats. ESRI users, for example, can either manually register the data or use auto registration functionality settings in SDE to automatically register these layers due to their conformance with the ESRI data modeling requirements (i.e., manual: sdelayer -0, Autoregister: sdeconfig setting = DISABLEAUTOREG=FALSE).

Data modeling in support of an enterprise implementation is an important consideration when accommodating various vendor solutions and advanced database functionality. The MLRS maintenance tools can be configured to work in the same schema as other GIS vendor data, or in a separate schema or database. The decision as to where to locate the data will depend on your organization’s needs and a common understanding of the rules, constraints, schemas, and implementation requirements. Various supported options include:

Multiple vendor data in the same Oracle schema

Multiple vendor data in separate Oracle schema

Multiple database homes to support different databases

Database modeling and integration of datasets will depend on the particular needs of an organization.

5


2.3. Workflow The MLRS Enterprise Architecture will support various workflows throughout the enterprise. The typical workflow and data configuration includes:

1. MLRS maintenance activities

2. Publishing or exposing MLRS data as distinct single-level linear referencing system (LRS) features

3. Use of LRS data by multiple users with multiple software vendor tools (i.e., ESRI’s ArcGIS)

Figure 3 shows a typical maintenance process flow for a DOT and the incorporation of changes to the network. All the processes contained in the blue box are those involved with the ingestion and verification of the data added using the MLRS maintenance components. The yellow box shows the processes that will prepare the LRM and event tables to be updated in Oracle. The orange box illustrates which data sources will then be used by viewer users (i.e., registered layers in ArcSDE).

LRM Reference

Figure 3: This diagram illustrates a typical maintenance process flow for a DOT and changes incorporated into the network.

The workflow above is just one possible scenario intended to outline the flow of data from maintenance through to general consumption throughout the enterprise. The section below outlines some of the key functionality in the MLRS maintenance components. Note that the functionality available to other enterprise users is limited only by the software functionality of these core products. For example, an ESRI ArcGIS user may choose to dynamically segment data using a single-level LRS provided by the MLRS workflow.

6


3. Functionality The MLRS maintenance components provided by Intergraph’s GeoMedia product suite provides a rich set of tools and functionality not available in other GIS systems on the market. Some of the key functional differentiators available in the MLRS maintenance components are outlined below, along with a more thorough description of the problems they address.

MLRS is an automated approach to managing the components of a linear reference system network and event data regardless of the location method or geometric representation used. MLRS is different from the traditional LRS management practice in that the base network can represent multiple linear referencing methods (LRMs), such as county-route-log mile, street name-address, intersection-offset, etc., and can be displayed on the map using multiple geometric representations. Intergraph’s core data model and software manage the various parts of the LRS independently through database joins and relationships. A temporally stable datum links these component parts to support event location stability and temporal data management and analysis.

Intergraph developed the GeoTrans data model as a practical approach to implementing an MLRS (Figure 4). The GeoTrans data model is a derivative of the NCHRP 20-27 model and focuses on ease of use. This enables Intergraph’s GeoMedia product suite to support MLRS, as well as the traditional single-level linear referencing systems. This data model can seamlessly exist within a DOT’s current IT architecture. The data structure could be created and maintained in a DOT’s production schema within Oracle and subsequently published to the enterprise through publishing schemas. This type of model addresses a wide variety of issues common to most transportation agencies.

Figure 4: This diagram illustrates Intergraph’s GeoTrans data model.

7


3.1. Multiple Linear Referencing Models (LRMs)

Most transportation agencies have various sub-departments and external sources that collect data about their transportation networks using a variety of measurement methods and sometimes different road or rail naming conventions. Figure 5 shows a few example LRMs.

The example illustrates a DOT with a need to manage four LRMs: route and true mileage (I-94 at 45.354), route and reference point (I-94 042+01.245), route and legacy mileage, and route and coordinate. The data model would allow cross-discipline analysis of data collected in these different LRMs. The stable datum provides the common base for all of the various LRMs the DOT wishes to deploy. Deployment and consumption of this data would be consistent and provide a single point of truth in the organization.

Figure 5: These diagrams show examples of multiple linear referencing models.

3.2. Event Location Stability

Providing stability for events in the instance of a change in the roadway is critical. These changes can include new names for roads, realignments, recalibrations, and more. In Figure 6, the points represent crash locations along a road, and the linear event represents pavement conditions.

Figure 6: This illustration shows a small section of a road before network changes.

The road segment is realigned and recalibrated. The changes to the network can cause the linearly referenced event data to shift. These are not the correct locations of the events. This is a common problem with a traditional single-level LRS (Figure 7).

8


Figure 7: This illustration shows the same section of the road after network changes.

Registering event data to a stable datum keeps the crash and pavement condition data from drifting. This is the correct behavior (Figure 8).

Figure 8: This illustration shows a section of the road after network changes using the GeoTrans model.

3.3. Multiple Geometric Representations

Transportation agencies often manage more than one geometric representation of a network (Figure 9). The GeoTrans data model supports this by conflating the different geometry representations to the datum. For example, you may use different levels of generalization for different map products or different types of transportation analysis, but still want to see the event data against them.

Another common use of multiple geometric representations is when data comes from a regional or national agency, one or more local agencies, or a commercial data provider. Without MLRS, 100 percent duplication of LRS data and maintenance would occur for each geometric representation. In addition, each individual LRS may not be synchronized. Agencies want to easily switch between geometric representations without worrying if this will affect the validity of their analyses.

Figure 9: A multilevel LRS allows agencies to use data against different geometric representations.

9


3.4. Multilevel LRS Data Maintenance

The maintenance of an MLRS structure involves several key factors. First is the transition from a traditional, single-level LRS to an MLRS. This would be done with a DOT’s primary LRM. A one-command conversion process builds the various tables of an MLRS.

A second significant factor is the ongoing maintenance of the MLRS. This is done through a series of MLRS intelligent editing commands. The commands understand the data model and edit the appropriate levels simultaneously. There are several MLRS conflation commands. These conflation tools understand the complexities of the hierarchical data model. The commands function in a bulk or interactive mode. Functions the conflation command performs include:

Replace existing data with better data

Add data (LRM and/or geometric representations)

Update data (LRM and/or geometric representations)

Delete existing data

3.5. Temporal Data Maintenance and Analysis

Temporal data maintenance and analysis are important components of an MLRS. GeoMedia Transaction Manager works with native Oracle’s Workspace Manager to transparently capture real-world history as you edit. A series of views transparent to the user manages the data. The basic workflow is as follows:

Create a revision set and fill in the edit date (start an editing session)

Edit as usual

Commit or discard your changes and retire your revision set The system can time-stamp data to represent either a real-world change, such as a realignment, or a simple correction that does not represent an actual real-world change. You can review data from either a point in time or a time range.

10


4. Customization Considerations While MLRS maintenance components provide the core functionality needs of most organizations, you may require customization to address unique business or data issues within the enterprise. You can customize the maintenance components using industry-standard development tools, such as Microsoft .NET (C# and VB.NET), as well as other COM compliant development languages (Visual Basic, Delphi and PowerBuilder). The data model can be customized using standard database compliant tools, such as PL/SQL or Microsoft.NET.

MLRS maintenance components offer a high degree of customization. This customization includes:

1. Custom commands 2. Third-party custom functionality (DLL) 3. Custom standalone applications

Custom commands are software functionality modules embedded in the main application framework. These commands run within the GeoMedia application framework and supplement existing functionality. An example of this type of command would be one that automates several steps in a given workflow.

Third-party custom functionality consists of software components developed using the MLRS maintenance component API’s to augment other applications. An example of this type of command would be to embed transportation functionality, such as an MLRS query, into a third-party GIS software solution, such as ArcGIS.

Custom standalone applications are developed using the rich API available in the product to develop a tailored solution that meets specific needs. An example of a custom application would be a standalone map viewer that would allow you to visualize all of the MLRS data and associated event data in a rich desktop environment.

You can customize the database that supports the MLRS maintenance components to meet the demands of the organization. For additional information on this topic, refer to the “Database Component” section of this document.

The recommended development technology for the MLRS enterprise environment is:

Microsoft C# .NET (client side customization)

Oracle PL/SQL (server side database code development)

11


5. Optional Web Component In addition to the key architectural choices defined in this document, no modern MLRS enterprise environment is complete without spatially enabled Web-based components. Due to the open nature of the architecture, the system can use various vendor software to publish LRS feature data.

Intergraph also has advanced spatial Web mapping software capabilities targeted at the transportation industry. This software can exploit many of the key MLRS data elements and provide more dynamic response to multiple vendor solutions by using open standards and Web services.

Client software required to deploy transportation-related Web applications includes:

Intergraph’s GeoMedia WebMap Professional 6.1.x

Built-in API to read and expose LRS data

Publication of data to OGC-compliant formats (i.e., WMS, WFS)

Support for various Web services (dynamic segmentation Web service, LRS precision location Web service, routing Web service)

The recommended Web development approach is based on Microsoft’s best practices and technologies. The developer may choose to develop based on corporate standards and approaches; however, a multi-tier development approach is preferred. The recommended development environments for the Web environment include:

ASP .NET/JavaScript/AJAX (interface development)

Microsoft C# .NET (back-end code development and Web services)

ODP .NET (Oracle data provided for database connectivity)

12


13

6. Conclusion The Intergraph MLRS Enterprise Architecture is based on proven core software and implementation experience. Organizations can make various detailed architectural decisions to streamline their processes. In summary, the below architectural recommendations include:

Software required:

Client software

1. Oracle’s database client software (10g or 11g)

2. Intergraph’s GeoMedia Professional 6.1.x

3. Intergraph’s GeoMedia Transportation Manager 6.1.x

4. Intergraph’s GeoMedia Transaction Manager 6.1.x

5. Intergraph’s GeoMedia Fusion 6.1.x

Database server software

1. Oracle database 10g release 2 or 11g

Implementation

1. Use an existing or create a new Oracle 10g or 11g database instance

2. Load the GeoTrans data model and relevant user data into an existing or new database schema

3. Secure the data for long-term transaction management and business data event stability (optional)

4. Determine what data and structure of data to expose to other users, respecting the database considerations above.

5. Perform edits and ensure multi-vendor users (i.e., ArcGIS) have access to data.

For more information about Intergraph, visit our website at www.intergraph.com.

Intergraph, the Intergraph logo, and GeoMedia are registered trademarks of Intergraph Corporation. Microsoft and Access are registered trademarks of the Microsoft Corporation. Other brands and product names are trademarks of their respective owners. Intergraph believes that the information in this publication is accurate as of its publication date. Such information is subject to change without notice. Intergraph is not responsible for inadvertent errors. ©2010 Intergraph Corporation. All Rights Reserved. 9/10 TRN-US-0018A-ENG

http://www.intergraph.com/

MLRS Enterprise Architecture - Intergraph configuration for spatial indexing, work tablespaces...

Documents

Transcript of MLRS Enterprise Architecture - Intergraph configuration for spatial indexing, work tablespaces...