Logical Consistency

Basic issues:

• what relationships INSIDE the database can be checked?
  (all internal evidence; no source of "higher" accuracy or external information)
  (what assumptions/ axioms are there about the data?)
• What relationships HAVE been checked? (and with what results?)

4.4 Logical Consistency

A report on logical consistency shall describe the fidelity of relationships encoded in the data structure of the digital cartographic data. The report shall detail the tests performed and the results of the tests.

4.4.1 Tests of Valid Values

Tests for permissible values can be applied to any data structure. Such a test can detect gross blunders, but it does not ensure all aspects of logical consistency.
Permissible values apply to a field, but also interactions/relationships

4.4.2 General Tests for Graphic Data

A data base containing cartographic lines can be subjected to the following general questions:

• Do lines intersect only where intended?
• Are any lines entered twice?
• Are all areas completely described?
• Are there any overshoots or undershoots?
• Are any polygons too small, or any lines too close?

Different tests can be applied to address these questions, but the quality report shall contain a description of the tests applied or a reference to documentation of the software used. The report shall state whether all inconsistencies were corrected or it shall detail the remaining errors by case.
Certain measurement frameworks imply some of these

4.4.3 Specific Topological Tests

For exhaustive areal coverage data transmitted as chains, or derived from chains, it is permissible to report logical consistency as "Topologically Clean", under the condition that an automated procedure has verified the following conditions:
a. All chains connect at nodes. (Use of exact case or tolerance must be reported.)
b. Cycles of chains and nodes are consistent around polygons. Or alternatively, cycles of chains and polygons are consistent around nodes.
c. Inner rings embed consistently in enclosing polygon. Considering the definition of polygon adopted in Part I, conditions b and c require unique polygon identifiers. The quality report must identify the software (name and version) used to verify these conditions.

An ArcMap shapefile can contain overlapping shapes. There is no easy way to get all the slivers and gaps edited away.

SDE (Spatial Database Engine) does have advanced topological error checking even though it uses something equivalent to a shapefile (and quite different in storage details). SDE can find all shared segments and correct them.

Consistency with OTHER layers

This is a huge issue, and not addressed very well in the SDTS standard.

For example,

• the street center lines should fall inside the pavement area;
• rivers should be inside their floodplain;
• zoning boundaries should follow certain parcel boundaries (most of the time);
• hierarchical relationships should nest (cities inside counties inside states - except Bothell)
• ... too many potential relationships to delineate them all

Can these relationships be considered as a kind of accuracy? Perhaps. But it is the relationship between layers that needs to be understood.

Version of 23 February 2004