Components

What the framework's data, technology, operational, and business elements are, and how they work.

The goal of the framework is to improve everyone's operations, reduce costs, and facilitate new analyses and joint decision making by providing a readily available set of basic digital geographic data. The framework consists of commonly needed, used, and produced data brought into a common standard and made widely accessible.

The following are the guiding principles for building the framework:

• The framework should be a preferred data source. It should represent the best available data for an area -- the most current, complete, and accurate data.
• The framework should be widely used and useful. Users must be able to easily integrate framework data with their own and provide feedback and corrections to framework data.
• Access to framework data should be at the lowest possible cost, and without restrictions on use and dissemination. The framework is a public resource.
• Duplication of effort should be minimized. Sharing the development and maintenance of framework data reduces the costs of individual users' data production.
• The framework should be based on cooperation. It is built through the combined efforts of many participants who work together on its design and development and contribute data to it.

The framework has four major components: information content, technical context, operational context, and business context. Information content refers to the data elements in the framework, which consist of seven themes of common geographic data. The technical context of the framework involves the technical factors that are required to build and operate the framework. The operational context describes the framework's operating environment. The business context addresses the conditions required to ensure the usability of framework data.

Information Content

The framework contains the geographic data themes used by most organizations. These are geodetic control, orthoimagery, elevation, transportation, hydrography, governmental units, and cadastral information. Data within these themes are also the most commonly produced. Because such data are either in production or planned in most areas, many organizations involved in GISs are already building potential framework data as part of their GIS efforts.

Although framework data serve as the base data for a great deal of problem solving and many operations, they usually do not provide all the data needed for such tasks. They are not meant to. In practice, framework data will be supplemented with users' specific data -- in both attribute and graphic forms. Framework data provide a base on which users' data can be overlaid, or a frame to which they can be attached. Framework data are intended to provide basic geographic data in a common form that is readily accessible, so that organizations can devote their efforts to their own applications data and activities.

Core Data and Applications Data

Building and using the framework is similar to any multipurpose GIS effort. Common data themes that are needed by most users are identified, created, and shared. Individuals can use the common data as a base to create their own data and then perform their own applications. Thus, the user's model has two parts:

• Core data used by most and shared by eveyone, maintained in a common standard. In the framework model, the framework data form this core.
• Applications-specific data created and used by some participants. These data are not necessarily shared widely, because they do not have widespread common interest. Data that are not to be shared need not conform to common standards, so the producers of these data are free to do what they want.

The framework follows this same model -- there is a core of commonly used data to which applications-specific data can be added.

Multipurpose GIS Figure 3.1a

Framework Approach Figure 3.1b

Geodetic Control

Geodetic control provides a common reference system for establishing the coordinate positions of all geographic data. It provides the means for tying all geographic features to common, nationally used horizontal and vertical coordinate systems. The main features of geodetic control information are geodetic control stations. These monumented points (or in some cases active Global Positioning System control stations) have precisely measured horizontal or vertical locations and are used as a basis for determining the positions of other points. The geodetic control component of the framework consists of geodetic control stations and related information -- the name, feature identification code, latitude and longitude, orthometric height, and ellipsoid height, and metadata for each station. The metadata for each geodetic control point contains descriptive data, positional accuracy, condition, and other pertinent characteristics for that point.

Geodetic control information plays a crucial role in developing all framework data and users' applications data, because it provides the spatial reference source to register all other spatial data. In addition, geodetic control information may be used to plan surveys, assess data quality, plan data collection and conversion, and fit new areas of data into existing coverages.

Orthoimagery

Orthoimagery provides a positionally correct image of the earth. An orthoimage is a georeferenced image prepared from an aerial photograph or other remotely sensed data from which displacements of images caused by sensor orientation and terrain relief have been removed. An orthoimage has the same metric properties as a map and has a uniform scale. Digital orthoimages are composed of an array of georeferenced pixels that encode ground reflectance as a discrete digital value. Many geographic features, including those that are part of the framework, can be interpreted and compiled from an orthoimage. Orthoimages can also serve as a backdrop to reference the results of an application to the landscape.

The framework may include imagery that varies in resolution from submeter to tens of meters. Accurately positioned, high-resolution data (pixels of 1 meter or finer) are presumed to be the most useful for supporting the compilation of framework features, particularly those that support local data needs. In some areas, lower-resolution imagery may be sufficient to support the framework and applications.

Orthoimagery provides a useful tool for a variety of applications. Because many land features can be seen on an orthoimage, it can serve as a backdrop for visual reference purposes, saving the expense of creating vector files of features that are needed only for reference. Orthoimagery can be used to compile vector themes photogrammetrically. 

Elevation

Elevation data provide information about terrain. Elevation refers to a spatially referenced vertical position above or below a datum surface. The framework includes the elevations of land surfaces and the depths below water surfaces (bathymetry).

For land surfaces, the framework employs an elevation matrix. Elevation values will be collected at a post-spacing of 2 arc-seconds (approximately 47.4 meters at 40° latitude) or finer. In areas of low relief, a spacing of 1/2 arc-second (approximately 11.8 meters at 40° latitude) or finer will be sought.

For depths, the framework consists of soundings and a gridded bottom model. Water depth is determined relative to a specific vertical reference surface, usually derived from tidal observations. In the future, this vertical reference may be based on a global model of the geoid or the ellipsoid, which is the reference for expressing height measurements in the Global Positioning System.

Elevation data are used in many different applications. Users may want a representation of the terrain, such as a contour map, spot elevations, or a three-dimensional perspective view. Elevation data are also used to build models and perform applications, ranging from line-of-sight calculations, to road planning, to water runoff. Elevation data are often combined with other data themes in applications and mapping.

Transportation

The framework's transportation data include the following major common features of transportation networks and facilities:

• roads -- centerlines, feature identification code (using linear referencing systems where available), functional class, name (including route numbers), and street address ranges;
• trails -- centerlines, feature identification code (using linear referencing systems where available), name, and type;
• railroads -- centerlines, feature identification code (using linear referencing systems where available), and type;
• waterways -- centerlines, feature identification code (using linear referencing systems where available), and name;
• airports and ports -- feature identification code and name; and
• bridges and tunnels -- feature identification code and name.

Transportation information is used in many applications. Some use it only for reference purposes, as an element of base mapping, while many others use it to attach other types of information, such as address-related information or street characteristics. Transportation features and related data are important elements of many planning applications. Geocoding applications use road and related address data for uses ranging from marketing analysis to site identification. Routing applications use street network data for operations such as vehicle dispatch and fleet management.

The Framework is a Starting Point

Are we limited to what is described here? No. The framework represents minimum requirements. Any data producer or consortium can build geographic data that have content beyond that of the framework. Your data production activities will be driven by the businees needs of your geographic data community. It is often more practical and mangeable to start with small or simple data sets and add to them as resources permit. The framework's minimum requirementsprovid a good starting point.

Hydrography

Framework hydrography data include surface water features such as lakes and ponds, streams and rivers, canals, oceans, and shorelines. Each of these features has the attributes of a name and feature identification code. Centerlines and polygons encode the positions of these features. For feature identification code, many federal and state agencies use the Reach scheme developed by the U.S. Environmental Protection Agency.

Many hydrography data users need complete information about connectivity of the hydrography network and the direction in which the water flows encoded in the data. To meet these needs, additional elements representing the flow of water and connections between features may be included in framework data.

A shoreline is the intersection of the water's surface with land. It usually is referenced to some analytically determined stage of the tide for coastal water, or other water level for lakes and rivers. Several shorelines, referenced to different stages of the water such as "mean high water" and "mean lower low water," are included in the framework. These shorelines are included because different users require different shorelines and the complex, nonlinear relationships between various shorelines make it difficult to determine them analytically. Attributes include the description of the tidal reference for the shoreline.

Hydrography is important to many applications. As with other data themes, many users need hydrographic features as reference or base map data. Other applications, particularly environmentally oriented analyses, need the information for analysis and modeling of water supply, pollution, flood hazard, wildlife, development, and land suitability.

Governmental Units

The framework includes the geographic areas of units of government. These units include

• the nation,
• states and statistically equivalent areas,
• counties and statistically equivalent areas,
• incorporated places and consolidated cities,
• functioning and legal minor civil divisions,
• federal- or state-recognized American Indian reservations and trustlands, and
• Alaska Native regional corporations.

Each of these features includes the attributes of name and the applicable Federal Information Processing Standard (FIPS) code. Features boundaries include information about other features (such as roads, railroads, or streams) with which the boundaries are associated and a description of the association (such as coincidence, offset, or corridor).

Governmental unit boundaries are used for a wide variety of applications. Some need the boundaries only for information and orientation; others require the polygons to determine inclusion related to a number of other features. Business GIS is a very active field that uses these boundaries for statistical analysis and decision making.

Cadastral Information

Cadastral information refers to property interests. Cadastral data represent the geographic extent of the past, current, and future rights and interests in real property. The spatial information necessary to describe the geographic extent and the rights and interests includes surveys, legal description reference systems, and parcel-by-parcel surveys and descriptions.

Two aspects of cadastral information are included in the framework:

• cadastral reference systems, such as the Public Land Survey System (PLSS) and similar systems for areas not covered by the PLSS (for example, the Connecticut Western Reserve in Ohio), and
• publicly administered parcels, such as military reservations, national forests, and state parks.

Features include the survey corner, survey boundary, and parcel. Each instance of a feature has the attributes of name (or other common identifier) and information about data quality. Each instance also should have a permanent feature identification code.

For the PLSS, the minimum content is the boundaries of sections, including deflection points and the positions for quarter corners along section boundaries. Boundaries that have been surveyed are the preferred content for cadastral reference systems.

Cadastral information is the basis of many analysis, decision-making, and operational applications, such as site selection, land use administration, and transportation planning. The reference system can be used to register locally produced information into the framework. Information about publicly owned lands serves both those who administer the lands and those who have interests in them. Framework representation of these lands provides useful information about their location, boundaries, extent, and relationships to other geographic features and phenomena. Because parcels play an important role in many public and private sector activities, and parcel information is a basic ingredient of many applications, there is interest in providing multiple levels of cadastral data. These levels would be based on available data and customer requirements. The framework provides a means to link existing parcel data into the larger cadastral network.

Technical Context

The technical context of the framework is designed to make it easy for people to contribute and use data. Users will be able to incorporate framework updates without disturbing their own data. Attributes and additional graphic data that exist in house will retain their connections to framework data while maintaining their integrity. Participants will be able to contribute data to the framework.

The framework's spatial data model and supporting technical features are designed to allow data holdings to be updated without risking existing investments and to allow attribute information to be added to the spatial data. To facilitate this, a common method for identifying individual features and assigning unique identifiers to these individual features is being developed.

Using Framework Data

Framework data can be a valuable resource for geographic analyses and operations:

• Framework data may be all you need for certain applications. For example, framework data provide all the geographic information necessary for basic reference maps, geocoding, and some statistical analyses.
• Framework data may serve as a base for your own data, enabling you to add or attach additional attribute information. Many types of analyses link attribute values to features or relate locations of new phenomena to existing features. Although the framework may not provide all the data to perform such applications, it can save the considerable cost of producing all data on your own.
• Framework data enable you to register your data, which places them in the correct geographic context for further development and enables incorporation of data from other sources.

Contributing Framework Data

Many organizations create framework data in the course of their daily operations. You may already have created framework-type data, you may be in the process of developing or planning to collect data, or you may be wondering how you can afford to create data for your GIS development. You could benefit from going the extra mile to conform to framework standards so that your data can be contributed to the framework. Participating in the framework, adopting its standards, and contributing data enable you to combine you data with other framework data to make possible extended applications at lower costs.

Encoding Geographic Entities Figure 3.2

Spatial Data Model

For orthoimage and elevation (elevation matrices and gridded bottom models) data the framework employs a raster data model. The locations of observations are represented by an array of cells or points that hold values for an attribute. For an orthoimage, the cells contain values for ground reflectance; for elevation, they contain values for elevations or depths.

For the remaining framework data, the design is a feature-based vector data model. A feature is a description of a geographic entity on the earth -- for example, a road, a lake, a parcel, or a county. A feature can be linked to spatial objects (such as points, nodes, chains, and areas) to identify its location. Different sets of spatial objects exist for different resolutions.

A feature is identified by a unique code -- the permanent feature identification code. Its location characteristics are described by its linkage to the spatial object. A feature may be further described by a set of attributes and relationships. Attributes define the feature's characteristics -- for example, the name of a lake, the type of trail, or the population of a county. Relationships may be defined to express interactions that occur between features, such as flow in a river system or connectivity in a transportation network.

Framework data carry specified spatial descriptions, attributes, and relationships; users may add more of these to meet their own needs. Users' data are linked to framework features by the feature identification code.

The spatial objects used to encode the positions of vector-based features will conform to topological rules. Chains will intersect only at nodes, and all nodes will anchor the ends of chains. "Overshoots" and "undershoots" are not allowed where chains are supposed to meet. When areas are needed, they will be bounded by chains, and chains will identify the areas to the left and right of the chains. "Gaps" and "overlaps" among areas are not allowed.

Spatial Data Model Development

Detailed data models are required for the framework. The data models for the seven themes will be integrated to form a model for the entire framework. Processes have been developed for creating common data models for the framework, and data model development for themes is progressing. The resultant models will provide templates for using and contributing framework data and developing local extensions to these data models. While local data models will be driven by local operating needs, framework models can provide useful starting points.

Permanent Feature Identification Codes

Each occurrence of a feature is assigned a unique, permanent feature identification code. This code provides a key through which users can associate framework data with their own data, serves as a tracking mechanism for transactional updates, and links representations of a feature at different resolutions and across different areal extents. Once assigned, the permanent feature identification code does not change unless the feature undergoes a substantial change -- for example, a road is destroyed or a river becomes a reservoir. The feature identification code provides a consistent method of identifying units of framework data.

Multiple Resolutions and Generalization

Different users require geographic data with different amounts of detail. For example, a local government may require detailed data over a small geographic area. A state agency may need consistent, less detailed data that cover a large area, including the area for which the local government has more detailed data.

Currently, these needs often are met through independent data collection efforts. A goal of the framework is to change this approach. More detailed, accurate, current, and complete data available for an area will form the basis for the framework, and efforts to update geographic data will focus on these detailed data. Needs for less detailed data will be met by generalizing the detailed data. The result will be a common base of data from which multiple, generalized views can be created. The community is seeking ways to overcome the technical and operational barriers to achieving this goal.

Coordinate Referencing System

A common referencing system for coordinate positions allows framework contributions to be joined and integrated. The use of longitude and latitude is encouraged for the framework. This system offers a seamless coordinate system for most of the United States and can be readily converted to map projection and grid coordinate systems. Horizontal coordinate information is referenced to the North American Datum of 1983 (NAD 83) and vertical coordinate information is referenced to the North American Vertical Datum of 1988 (NAVD 88).

Consistency Across Space

Framework data are seamless across collection areas; for example, a road that crosses a county line should not have a gap at the line. As a general principle, the positions of contributed data are not modified when they are incorporated into the framework. Therefore, it is preferred that features that cross data collection areas be reconciled positionally before they are contributed to the framework. This is accomplished through the coordinated efforts of data contributors working together in their geographic areas. This approach assumes that organizations integrating data would not have better information than those that contributed the data and thus would have little basis for "repairing" the data. Data producers are encouraged to work with those in adjoining jurisdictions to align their data and eliminate ambiguities. Technical procedures, called "horizontal integration," will be needed to create seamless coverages for data that don't fit together.

Consistency Among Themes

Framework data are consistent among themes. Relevant relationships among features in different themes are maintained. Coincident alignments of features, such as where a boundary follows a stream, are matched. More challenging integration addresses issues such as ensuring consistency between the alignment of hydrography and elevation data. The process of reconciling ambiguities among themes is referred to as "vertical integration." Here again, the general principle is that the positions of contributed data are not modified when the data are incorporated into the framework. Therefore, features should be vertically integrated before they are contributed to the framework. Technical procedures to vertically integrate data that don't fit together also will be needed.

Historical Data

The framework retains past versions of data so that information is available for historical or process studies. Access to past versions is necessary to support historical thematic data that are registered to the framework and time-based studies essential in many applications. Research and policy studies often seek a time series roll-forward/roll-back capability for geographic base data.

Metadata

The framework contains metadata detailing the characteristics and quality of framework data, including positional and attribute accuracy, completeness, logical consistency, and lineage. Metadata help users find suitable framework data, evaluate them for their needs, and use the data appropriately.

Vertical Integration Approaches

Vertical integration can be approached in different ways. Data may just be aligned, or positionally adjusted, with no actual linkage. Relationships or links may be establlished among relevant features in different themes. Although studies are being conducted to determine the type of approach that meets the needs of the general community, the needs of localized communities must also be considered. This is another reason partnerships are important -- they are necessary for resolving issues, such as ahich data integration approach is most suitable for those involved.

Operational Context

The operational environment of the framework stresses accessibility and ease of use.

Transactional Updates Figure 3.3

Operational Characteristics

The framework provides the following operational characteristics:

• The framework supports transactional updates. Data producers provide only change files, and users need to process only changes. This approach reduces the impact of changes on users' existing operational environments.
• The framework process ensures access to an official version of framework data (current and past versions) by information networks and digital media.
• Framework data can be found through the National Geospatial Data Clearinghouse.

Framework Coverage

The goal is to have nationwide framework data coverage composed of the pieces produced for smaller areal extents. There is no set size of geographic area for each contributed piece. Experiments are being conducted to evaluate various sizes, such as watersheds, regions, states, and smaller areas. The results of these trials will provide information on the size of coverage that is manageable and sustainable. It is assumed, however, that the viable geographic coverage of each contributed piece will depend on the economics of processing the contribution.

Integration

The framework is based on data created by many organizations. For a data theme covering a geographic area, there may be many, sometimes overlapping, data sources that can contribute to the framework. In addition, there will be different organizations that collect and maintain different themes of data for a geographic area.

Users, however, need data that are consistent across their area of geographic interest and among different themes. For example, hydrographic features and boundary features that coincide on the earth should coincide in the framework. Horizontal and vertical integration of data to create a coherent set of data for a geographic area is an important framework function. When contributed data are not integrated, the initial collections of data must be integrated, as must the continuing streams of updated information.

Location of Framework Data

Framework data are distributed across the country. Sites are connected electronically so that users can access data from anywhere. The pattern of the physical distribution varies. There are several alternative data configurations within any area:

• Data may reside at each producer's site.
• One organization may provide access to data generated by many producers. This access may be passive or active -- a site may be provided at which data can be accessed, or data may be sent out to users.
• A variety of organizations may take framework data and redistribute them.

Therefore, framework data may physically reside anywhere, depending on the theme, geography, and time frame.

Business Context

To achieve the framework's goal of being widely used and useful, its data are openly available; include information about data limitations; exist in public, nonproprietary formats; conform to approved standards; and are certified. A basic premise of the framework's business context is to avoid restrictive practices. This is in keeping with the information access policy of the federal government and similar policies of many state and local governments. The basic elements of compliance with this goal are to provide timely and equitable data dissemination; provide unrestricted data access, use, and distribution; and set data access charges at no more than the cost of providing that access. (See appendix G for relevant parts of the federal policy.)

Data Charges

While framework data must be widely accessible, a framework operation must be able to recoup some or all costs of providing access to its data. Charges for access to framework data are limited to the costs of providing access and dissemination. For each framework operation, a unit of charging must be determined. For example, should the units be based on volume of data accessed, number of elements accessed, number of themes or layers accessed, size of area accessed, or the access time? The other side of the equation involves directing funds to appropriate parties. This determination can be very complicated when users access data elements that originate with various producers.

Future Challenges and Technical Development

Some aspects of the framework present technical challenges. As the necessary technological tools and processes are developed, they will be integrated into framework operations. Technical issues include the following:

• developing rules for integrating data;
• establishing rules for permanent feature identification codes;
• providing standard tests of data accuracy and methods for data certification;
• developing methods to generalize and incorporate locally held high-resolution datainto regional and national data holdings;
• developing methods for processing data transactions; and
• developing means for managing historical, or past, versions of framework data.

These issues are being worked on by a number of means:

• developing pilot projects,
• working with the vendor community,
• funding research and development efforts,
• developing standards and guidelines, and
• encouraging discussion in the geographic data handling community.

Data Access

Framework data must be widely accessible, so practices and arrangements that restrict accessibility must be avoided. Proprietary formats, exclusive arrangements, restrictions on use, and charges beyond those of data provision are not acceptable. Users must be provided with current information in a timely and equitable manner. Operational, institutional, and technical capabilities and procedures must ensure unrestricted access, which requires that the community work together to establish procedures and capabilities.

Information About Data Limitations

The framework includes information about limitations of data, such as suggested or optimal uses of data, data quality assessments, disclaimers, and liability clauses.

Format

Framework data are available in public, nonproprietary formats.

Standards

Framework data conform to approved standards so that users know data characteristics and can expect consistency. Conformance to minimum standards such as the FGDC's metadata and cadastral data standards will be required and subject to verification. Additional standards and guidelines are being developed to support the framework, including standards for geographic referencing, data quality, data integration, and data transfer. (See appendix D for details regarding applicable technical standards.)

Data Certification

Framework data must meet the minimal framework criteria. Data certification involves review of contributed framework data to ensure that they adhere to framework standards. This process ensures reliable baseline data and integrity. Data certification procedures and specific responsibilities are being developed. Primary issues include determining who will be authorized to provide certification, what the requirements will be and who will determine them, and how documentation of certification will be issued.