Toward Developing a Statewide Minnesota
Geographic Information System Infrastructure

 

Robert Maki
GIS Database Coordinator
Minnesota Department of Natural Resources
Governor’s Council on Geographic Information, Standards Committee

1.0 Introduction

Minnesota has a well-deserved national reputation for progressive interagency coordination in the sharing, exchange, documentation, and cooperative development of Geographic Information System (GIS) resources. The best examples of this are the Minnesota GIS Consortium, which organizes and promotes one of the best attended state GIS technical conferences; the Minnesota Governor’s Council on Geographic Information, which serves as the basis for interagency information exchange and cooperative development; and Metro GIS, which is a pioneering effort in regional GIS business integration.

Although much good work has been done in this area, one could argue that the state lacks a well-defined vision of how the various centers for GIS development, education, and application within Minnesota could or should best capitalize on the investments that Minnesota private and public-sector GIS organizations have made. This brief paper suggests a conceptual basis for how we might better organize our efforts, and place our coordination activities into a common framework.

2.0 Looking for the Right Approach

The various Minnesota organizations that develop, distribute, and apply GIS resources can be collectively viewed as an information systems enterprise. Some analysts might object to this term as their minds seize on the familiar enterprise concepts of business object integration, and shared business applications and databases; and dismiss the idea of a state-level enterprise as idealistic or unrealistic. This is understandable. It is a simple fact of life that close integration of large, individually complex business functions and information systems is often not practical in today’s current information technology (IT) environment.

However, one could argue that there exists an opportunity for some level of practical integration amongst Minnesota GIS organizations, and that collectively, the environment could be called an "enterprise." In fact, many information systems-based functions already exist amongst unrelated or marginally related organizations, and the trend is toward increasing integration.

Many organizations have GIS technology resources (especially GIS data, software products, and derived information products) that they are prepared to share or sell, and for which exists a community of users eager to capitalize on the resources. There is a need for some sort of information systems enterprise that is capable of bringing shareable resources to a broader audience. Since true business function integration seems largely unattainable, the best paradigm to adopt for the Minnesota GIS Enterprise is one of a "facilitated technology exchange." The "exchange" paradigm focuses on the development of neutral pathways between organizations that allow participants to discover, contribute, and acquire resources in some organized fashion. This is not a new idea. It is, notably, the principal approach of the National Spatial Data Infrastructure (NSDI), which is being promoted by the Federal Geographic Data Committee (FGDC). While the NSDI represents a valuable contribution to Minnesota’s GIS enterprise environment, there are additional state level approaches available to us that can enhance the technology resource exchange amongst Minnesota GIS sites within the state.

It is probably not sufficient to speak simply about GIS resources and their availability. Developing a cohesive environment requires more concise resource definitions. I suggest that resources be defined as products and that suites of minimalist standards be part of their definition. For example, PCA has a data product that they wish to contribute to the enterprise; therefore, they name and encode the data product according to some specification, they place it on the system in a registered location, they register it within the system, they document it in some standard fashion; and by doing all of the above, it becomes part of the enterprise. Generally speaking, there would be different product categories, based on the characteristics of the product (data, software, or some other classification, perhaps related to administrative controls or licensing). Creating organizational, structural, and content standards for products allows for the development of easy-to-build, generic applications for supporting discovery, documentation, and acquisition.

3.0 Basic Issues and Obstacles Confronting a State-Level GIS Enterprise

If one can accept the idea that there are GIS resources that should be shared more broadly than they currently are, the question of how this can be accomplished presents itself. The Minnesota Governor’s Council on Geographic Information-GIS Standards Committee recently conducted a retreat that incorporated input from a wide cross-section of GIS users (see Bibliography). Reviewing the retreat results, it is clear that users are confronted with an array of technical and administrative obstacles to information resource exchange. The list in Figure 1 attempts to get at some of the basic needs that would require addressing during the creation of a state-level enterprise.

Figure 1: Basic Needs to be Addressed

0. How can I "discover" GIS information resources that are available to me?
1. How can I easily acquire resources that are available to me?
2. How can I improve the regular transfer of information between myself and outside agency business partners?
3. How can I minimize the problems associated with importing external data resources into my organization?
4. How can I streamline the process of integrating my resources with another organization’s resources as need arises?

The technical and administrative obstacles woven amongst the issues listed in Figure 1 are formidable. Figure 2 provides a suggested summary list of these.

Figure 2: Principal Obstacles to Overcome

0. Dissimilar systems result in difficult conversions between data formats, coordinate schemes, and attribution.
1. Data are not well understood with regards to their basic characteristics and suitability for applications.
2. Highly variable distribution and use policies complicate data acquisition and can lead to higher costs.
3. Data are not physically accessible via optimal media or acquisition mechanisms.

4.0 Characteristics of State-Level GIS Enterprise Environment

Based on needs and obstacles, the characteristics of a state-level GIS Enterprise environment can be considered. Implicit in any such venture is the need for physical infrastructure and mechanisms for developing a cohesive identity. Given the technological world in which we live, the internet is assumed to serve as the basis for the enterprise. Figure 3 provides a proposed list of characteristics, which are described in more detail in subsequent sections of this report. The list is limited to technical considerations. Additional administrative considerations are discussed in Section 5 (implementation).

Figure 3: Characteristics of a State-Level Enterprise

1. A single root access point to the enterprise environment to provide it with a cohesive identity.
2. Well-defined, robust mechanisms for discovering available resources (data, software, reports)
3. Sound network connectivity between primary participating sites.
4. Standard resource acquisition protocols (data delivery, software download)
5. Common identification and encoding of key land features (e.g. PLS, lakes, rivers, wells, others)-to support integration at user sites.
6. Consistent exchange formats
7. Complete documentation/description of enterprise products
8. Supporting system requirements and specifications

4.1 Establishing a Cohesive Identity

It is essential that an enterprise environment have a cohesive identity on both an infrastructure level and a public level. Cohesiveness does not presume high levels of integration, and is therefore not as demanding a concept as one might think. One of my favorite examples of the power of a cohesive identity can be found at the DNR. The department has organized their GIS resources around a concept called the "Core Database." In reality, the "Core" as it is called, is loose confederation of participating data sets held together by a few tight, well-defined, and strictly adhered to standards. However, the concept of the Core has been very powerful-it serves as a focal point of action that people can operate around. In some ways, the concept of the Core in people’s minds has been more powerful than the underlying technology. The same could be true for the Minnesota enterprise. Some well-defined, minimalist data and infrastructure standards (strictly adhered to) working in conjunction with a well-publicized single entry point (i.e. a web-site) could establish a powerful and cohesive identity for the enterprise.

One of the most important benefits of standards in developing a cohesive identity is the ability to prepared simple applications around them. This is a point that is easily missed: creating structural enterprise standards opens the door for the development of application interfaces (in this case, internet-based), and access mechanisms that operate across the entire domain of the enterprise. Without these types of standards, the cost of developing supporting applications escalates, the cohesiveness of the enterprise is quickly degraded, and the operation’s common identity is lost.

4.2 Discovering Available Resources

Techniques for discovering available resources is a strong point for statewide Minnesota GIS operations. Two sound models exist: 1) the Minnesota Geographic Data Clearinghouse, and 2) the Bridges to Environmental Information. Both probably have their place. The Bridges site covers a more broad domain of information resources (including publications), while the clearinghouse is adept at dealing with geographic metadata. Both technologies could find their way into a unified data discovery environment.

4.3 Sound Network Connectivity

This issue is probably in the process of being resolved. The quality of statewide connectivity is improving all the time. To some extent, the enterprise will follow in the wake of network connectivity development, with more participating sites being added as impediments to communication decrease.

4.4 Standard Resource Acquisition Protocols

Standard methods for acquiring enterprise "products" is essential to creating a streamlined environment. I would even suggest that it would be the defining characteristic of the enterprise, and the most obvious difference between our current environment and the enterprise being suggested here.

The problem seems to be two-fold: technology and administrative. Of these, technology is less problematic, so I will begin there. Product acquisition should rely on internet-based applications for downloading to a local environment. Users should be able to acquire a product without having to navigate a file system to find it. Products should be documented in some standard fashion, including descriptive information, and instructions for importing it from the (currently undefined) exchange format. The acquisition process should be site independent, in that one method is universally applied for each product type, regardless of where it is stored.

Administrative issues to standard product acquisition are more complex and difficult than the technological ones. Three principle concerns come immediately to mind: acquisition fees, product use constraints, and liability. These vary by organization and manifest themselves as policies or formal agreements affecting product costs, use constraints, and liability statements. Costs could be handled in one of two ways: 1) via an electronic commerce mechanism, or 2) through some sort of validated acquisition code that is assigned to a user once payment terms have been arrive at between the parties. The key to making this work is to create a simple, standardized mechanism that fee-based providers can either operate around, or directly integrate with. Both the use and liability issues constitute an agreement between parties and could be handled in one of two ways: 1) create a common liability-use model for all enterprise products that is sufficiently robust (and supports a sufficient range of scenarios) for all enterprise participants, or 2) provide common mechanisms for providers to post liability and use constraint information in conjunction with acquisition processes. More demanding licensing scenarios would probably require some sort of validated acquisition code model, as mentioned above (in the cost discussion). Examples of these would be ones requiring multiple signatories and/or specially negotiated terms.

It should be mentioned in passing that the simple scenario of no cost products, and unsigned ("shrink-wrapped) license agreements is by far the simplest one possible, and could serve as the basis for initial establishment of the enterprise.

4.5 Common Attribute Coding

Bringing data into common attribute coding schemas is not strictly an infrastructure issue in the sense that this characteristic will not control access and distribution. It is however a key user integration issue. Common schemes can be developed without the enterprise, but it could be argued that the existence of a facilitated exchange environment would serve to make the standards more viable. Integrating outside data resources is at least a three-fold process: 1) acquisition, 2) import, and 3) local integration. Streamlining the acquisition process breaks down one barrier and focuses the integration process more clearly on import and physical integration on the client site. It is open for debate as to whether attribute standard compliancy should be a requirement for incorporating a given data set into the enterprise. Attribute coding standards are especially important in that they promote depth in the enterprise environment, and help form a bridge to true business integration between parties. In this sense, they are an important part of the enterprise environment, and the likely basis for next generation business applications that span department boundaries.

4.6 Consistent Data Exchange Formats

Data format standards exist to support standard methods for decoding data. They can exist at multiple levels, ranging from standard feature encoding and internal documentation (e.g. the Federal Spatial Data Transfer Standard (SDTS)), to physical media encoding compliancy (e.g. ISO9660), to standard character sets (e.g. ASCII), to constraints imposed by file systems (e.g. end of line characters in ASCII-encoded NT files), to file compression standards (e.g. PKZIP) to vendor exchange file formats (e.g. ARC/INFO export files), to application standard formats (e.g. the Federal Vector Product Format (VPF)). Some level of standardization seems appropriate for the distribution of data via the enterprise.

Assuming that the enterprise is based on a "facilitated exchange" paradigm, and given that the expected distribution vehicle is the internet, we should seek an encapsulated file format to serve as the basis for data exchange. By "encapsulation", I refer to a property whereas data are "bundled" into more concise packages to reduce the number of data components transferred and thereby facilitate the exchange process. ARC/INFO export files are a good example of an encapsulated format where perhaps 30 or more individual files existing in separate directories are combined into a single ASCII file to facilitate exchange. It should be noted that there exists a Federal solution to this problem in the form of SDTS (noted above), but that the format is not in common use in Minnesota.

This is a issue that requires some study, but for purposes of discussion, I would suggest that we not impose any vendor-specific solution on this problem unless it can be done at no cost or minimal cost. It hardly seems fair (for example) to suggest ARC/INFO export files as a standard exchange format, when some users will not be able to support it. On the other hand, the designation of the PKZIP compression standard (perhaps without specifying an actual GIS exchange file format standard) may be quite viable given the ready availability of shareware that are capable of encoding and decoding data in that format.

4.7 Product Documentation

Perhaps the most essential and onerous element to the enterprise is user documentation. I would argue strongly for product documentation standards for data (the MGMG), software (undefined), and other types that might be defined. I also suggest that documentation be a prerequisite to including any product in the enterprise.

4.8 Supporting System Specifications

The diversity of the potential enterprise user and contributor base argues for as few constraints as possible be placed on supported hardware and software environments. Fortunately, as a medium, the internet crosses many environments on both the client and server sides and eliminates some of the network integration issues that enterprise environments face. At a minimum, there would need to be minimum configurations for browsers with regard to version numbers, and support for advanced capabilities that come with Java-based applications. The server environment would likely be more constrained in that internet server applications frequently interact with file systems on the host machines, and tend to be platform-specific. Certain network protocol standards would need to be defined and supported as well (e.g. TCP/IP network specifications, routers open to standard ports for internet and FTP access, and others).

5.0 Implementation

This document describes what might be termed a "cooperative" enterprise, where individual sites decide to participate in the environment and then voluntarily organize their resources according to a particular set of specifications and standards which allow their product resources to be discovered, reviewed, and acquired. Although the work associated with assembling the resources falls on the individual contributor, there still exists an essential coordinating role in the enterprise. Initial design tasks could be delegated to a variety of staff working in concert with the Governor’s Council. However, long term administration; and maintenance of standards, interface software, and supporting data structures, will require some dedicated staff. Two options exist for staffing the enterprise. First, develop a legislative proposal to fund some positions to oversee the operations of the enterprise, or second, use existing staff resources to accomplish the task. Regardless of the approach taken, the Land Management Information Center (LMIC) seems best positioned to function in this capacity, although some elements, especially those associated with the physical infrastructure, might fall within the domain of the Office of Technology (OT).

The enterprise would require a strengthening of interagency coordinating functions, particularly in the areas of data and systems standards, and in the administrative treatment of product licensing and distribution. I suggest that this represents a natural evolutionary path for the Governor’s Council from an ad hoc group to a structured support organization. Several committees could be tasked with maintaining the standards and interagency agreements which comprise the technical and administrative framework of the enterprise. This may require a cultural metamorphosis of the committee structures, as greater and more pressing demands are placed on them, and success or failure of a larger purpose confronts them.

We should also not ignore the commercial opportunities that the enterprise represents. It could function as the backbone for the regional distribution of data and software products by for-profit companies. All commercial product providers face distribution problems that could be overcome with this effort. Making the private sector an integral partner in the enterprise could bring additional revenue streams into its development and increased political clout when seeking state-funded financial support.

6.0 Wrap-Up

The purpose of this document is to stimulate discussion and to take the first steps toward the development of a holistic view of the various activities that seem to arise at Governor’s Council Meetings. Nothing in this document is sacred-everything is on the table. It is important that we develop some sort of overarching context within which to operate. Doing so will help to stimulate participation, focus our energies, increase the efficiency of meetings, promote the council to the public, and become generally more effective.

References Cited

Minnesota Governor’s Council on Geographic Information, GIS Standards Committee Strategic Planning Retreat Turn-Around Document, 16 February, 1999. Available at: http://www.lmic.state.mn.us/press/1999/lmic/retreat9.htm