Accuracy
How Is Accuracy Measured?
Because there are so many ways to measure it, accuracy is probably one of the most important and yet most widely misunderstood aspects of any mapping project. A map accurate for one purpose is often inaccurate for others since accuracy is determined by the needs of the project as much as it is by the map itself.
Some measurements of a map’s accuracy are discussed below.
The absolute accuracy of a map refers to the relationship between a geographic position on a map (a street corner, for instance) and its real-world position measured on the surface of the earth. Absolute accuracy is primarily important for complex data requirements such as those for surveying and engineering-based applications.
Relative accuracy refers to the displacement between two points on a map (both distance and angle), compared to the displacement of those same points in the real world. Relative accuracy is often more important and easier to obtain than absolute accuracy because users rarely need to know absolute positions. More often, they need to find a position relative to some known landmark, which is what relative accuracy provides. Users with simple data requirements generally need only relative accuracy.
Attribute accuracy refers to the precision of the attribute database linked to the map’s features. For example, if the map shows road classifications, are they correct? If it shows street addresses, how accurate are they? Attribute accuracy is most important to users with complex data requirements.
A map’s currency refers to how up-to-date it is. Currency is usually expressed in terms of a revision date, but this information is not always easy to find.
A map is complete if it includes all the features a user would expect it to contain. For example, does a street map contain all the streets? Completeness and currency usually are related because a map becomes less complete as it gets older.
The most important issue to remember about map accuracy is that the more accurate the map, the more it costs in time and money to develop. For example, digital maps with coordinate accuracy of about 100 feet can be purchased inexpensively. If 1-foot accuracy is required, a custom survey is often the only way to get it, which drives up data-acquisition costs by many orders of magnitude and can significantly delay project implementation by months or even years.
Therefore, too much accuracy can be as detrimental to the success of a GIS project as too little. Rather than focusing on the project’s benefits, a sponsoring organization may focus on the costs that result from a level of accuracy not justified for the project. Project support inevitably erodes when its original objectives are forgotten in a flurry of cost analyses.
A far better strategy is to start the project with whatever data is readily available and sufficient to support initial objectives. Once the GIS is up and running, producing useful results, project scope can be expanded. The quality of its data can be improved as required.
Back to Top
United States National Map Accuracy Standards
With a view to the utmost economy and expedition in producing maps which fulfill not only the broad needs for standard or principal maps, but also the reasonable particular needs of individual agencies, standards of accuracy for published maps are defined as follows:
1. Horizontal Accuracy:
For maps on publication scales larger than 1:20,000, not more than 10 percent of the points tested shall be in error by more than 1/30 inch, measured on the publication scale; for maps on publication scales of 1:20,000 or smaller, 1/50 inch. These limits of accuracy shall apply in all cases to positions of well-defined points only.
Well-defined points are those that are easily visible or recoverable on the ground, such as the following: monuments or markers, such as bench marks, property boundary monuments, intersections of roads, railroads, etc.; corners of large buildings or structures (or center points of small buildings); etc.
In general, what is well defined will also be determined by what is plottable on the scale of the map with 1/100 inch. Thus while the intersection of two road or property lines meeting at right angles would come within a sensible interpretation, identification of the intersection of such lines meeting at an acute angle would obviously not be practicable within 1/100 inch.
Similarly, features not identifiable upon the ground within close limits are not to be considered as test points within the limits quoted, even though their positions may be scaled closely upon the map. In this class would come timber lines, soil boundaries, etc.
2. Vertical Accuracy:
As applied to contour maps on all publication scales, vertical accuracy shall be such that not more than 10 percent of the elevations tested shall be in error more than one-half the contour interval. In checking elevations taken from the map, the apparent vertical error may be decreased by assuming a horizontal displacement within the permissible horizontal error for a map of that scale.
3. The accuracy of any map may be tested by comparing the positions of points whose locations or elevations are shown upon it with corresponding positions as determined by surveys of a higher accuracy. Tests shall be made by the producing agency, which shall also determine which of its maps are to be tested, and the extent of such testing.
4. Published maps meeting these accuracy requirements shall note this fact on their legends, as follows: "This map complies with National Map Accuracy Standards."
5. Published maps whose errors exceed those afore stated shall omit from their legends all mention of standard accuracy.
6. When a published map is a considerable enlargement of a map drawing (manuscript) or of a published map, that fact shall be stated in the legend. For example, "This map is an enlargement of a 1:20,000-scale map drawing," or "This map is an enlargement of a 1:24,000-scale published map."
7. To facilitate ready interchange and use of basic information for map construction among all federal map making agencies, manuscript maps and published maps, wherever economically feasible and consistent with the uses to which the map is to be put, shall conform to latitude and longitude boundaries, being 15 minutes of latitude and longitude, or 7.5 minutes or 3-3/4 minutes in size.
Back to Top
Spatial Data Transfer Standards
The Spatial Data Transfer Standard (SDTS) is a Federal Information
Processing Standard (FIPS 173) and Federal Geographic Data Committee
(FGDC) standard for the nonproprietary, vendor-neutral distribution
and archive of geo-spatial data and for the exchange of geo-spatial
data between dissimilar digital geographic information systems
(NIST, 1992). The organizers and designers of SDTS represent
more than just the federal sector and include individuals from
academic, commercial, and research organizations. The implementation,
acceptance, and use of a common exchange and archive standard
such as SDTS is one component of the National Spatial Data Infrastructure.
Parts 1, 2, and 3 of the SDTS document constitute the base specification
of SDTS. These base specifications provide data standards at
conceptual, logical, and physical or format levels. The SDTS
base specification is intentionally very flexible so that it
can accommodate all models of geo-spatial data. This flexibility
is possible because SDTS has so many options.
At the conceptual
level there are several dozen types of zero-, one-, two-, and
three-dimensional spatial objects to accommodate raster, vector,
topological, planar, spaghetti, and other models of geo-spatial
data. There are also options for projections, coordinate systems,
datums, quality information, attribute structure, and feature
content.
At the logical level there are many possibilities for
structuring, naming, and placing information into modules and
fields. At the physical or format level, using ISO 8211, there
are additional options, which can be restricted if required.
Purpose of Profiles
Profiles of SDTS currently have three primary purposes. The main purpose
is to be a clearly defined subset of SDTS, related to just one
data model, and thus limit the available options so that translation
software is much less complicated. The second purpose is to allow
extensions and profile-specific changes to the base standard.
The third purpose for an SDTS profile is as a mechanism for the
harmonization of SDTS with other spatial data exchange and archive
standards. Any single profile can serve more than one of these
purposes.
The development of translation software that accommodates all of
the possible spatial objects and options in the SDTS base standard
would be very difficult. For example, the developers of software
to translate or decode from all-encompassing SDTS to a specific
planar-vector-topological GIS format would need software that
could detect and react to all possible SDTS objects including
objects from raster and non-topological vector data models.
This "full SDTS to topological GIS" decoder would also need
the capability to do raster-to-vector conversions, to enforce
planar graph structure, and to derive correct topological relationships,
because the incoming SDTS data could be of any type. The translation
software needed to accomplish all this would be very complicated.
To make the development of translation and application software
feasible, SDTS options are grouped into a limited number of subsets
based on specific data models. For example, a raster profile
is limited to only elements of a raster model (i.e., pixels or
grid cells) and does not allow vector chains or strings or polygons.
In general, a profile identifies types of SDTS spatial objects
and related SDTS modules that are (1) always required, (2) allowed,
and (3) prohibited in the profile. A profile can also restrict
options by specifying module and file naming and ordering conventions,
by specifying ISO 8211 encoding methods, and by specifying feature
and attribute content requirements.
These restrictions further
reduce the complexity of SDTS decoder software, while not going
to the extreme of being limited for use with just one product.
For example, the Raster Profile is not so restrictive as to be
used just for the USGS DEM product, but it can be used for a
variety of raster and image products from USGS, NIMA, NASA, and
others.
This strategy also allows vendors and users to implement only those
portions of SDTS that are applicable to their system and data
structure. By using profiles of SDTS, the software for encoding
and decoding can be designed to handle just the options needed
by the specific system or data type.
A second purpose for profiles to SDTS is to allow profile-specific
extensions and changes to the base SDTS standard (Parts 1 - 3)
which may or may not become permanent changes to the base standard.
For example, the newest version of the Raster Profile includes
an extension to the SDTS base standard that accommodates multi-dimensional
data necessary for some National Aeronautics and Space Administration
(NASA) products. The third identified purpose for a profile to
SDTS is to serve as a mechanism for the harmonization of another
data exchange standard with SDTS.
As noted earlier, SDTS has
many options that support a variety of spatial data models. Because
of this, SDTS is a very configurable standard, and a profile
of SDTS can be designed to match all or part of another standard
such asthe Digital Geographic Exchange Standard (DIGEST), the
Vector Product Format (VPF), the Graphic Data File (GDF) standard,
or the Basic Image Interchange Format (BIIF).
Additional information on the purpose and development of SDTS profiles is
found in articles by Szemraj, Fegeas, and Tolar (1994) and by
Szemraj and Tolar (1993) (ftp://sdts.er.usgs.gov/pub/sdts/articles/).
Development of Profiles
Because of the large variety of options within SDTS, some numbers of
profiles are needed to make the implementation of translators
easier. However, a large number of uncoordinated and unrelated
SDTS profiles would defeat the goal of having a common exchange
standard that improves overall data sharing. The wish to keep
the number of SDTS profiles to a minimum must be balanced against
the need to accommodate required data characteristics that are
not supported in existing profiles.
The development of a potential
new profile to SDTS begins with a group of geo-spatial data producers
or users who act as the sponsors or "champions" for
the new profile. This group may be one of the FGDC's thematic
subcommittees or working groups as was the case with the Transportation
Network Profile from the FGDC Ground Transportation Subcommittee,
or it could be a group of agencies such as USGS and Census for
the Topological Vector Profile, or some combination such as the
National Oceanic and Atmospheric Administration and the FGDC
Federal Geodetic Control Subcommittee for the Point Profile.
The FGDC Standards Working Group (http://www.fgdc.gov/SWG/swg.html)
provides SDTS profile development assistance and coordination
as part of their "FGDC Standards Reference Model" for
all types of standards development. The model defines the expectations
of FGDC standards, describes different types of geo-spatial standards,
and documents the FGDC's 12-step standards development and approval
process.
Typically, the data associated with this sponsoring group has some characteristics
that do not appear to be supported by current profiles. Before
this sponsoring group begins the development of a new profile,
other SDTS options for supporting the desired data characteristics
should be explored. A group who is seeking to use SDTS and who
is considering a new profile should go through the following
steps.
(1) Study existing profiles in an effort to find one that will accommodate
their requirements.
(2) If no current profiles can be used "as is," then consider
modifications, additions, or clarifications to the most similar
current profile. Additions may be in the form of an annex which
specifies extra options that are allowed in profile. A valid
profile data set (called a "transfer") is allowed to
accommodate these annex options, but valid profile translators
are not required to decode this information. Clarification about
the use of a profile may be provided by a product-to-profile
mapping document as described later.
(3) If a new profile is indeed required, then the developers of the
new profile document should follow the example of the most similar
existing profile. This allows similar profiles to be grouped
into families that share many common elements and that can lead
to easier implementations based on using functions and software
designed for earlier profiles.
(4) As a further effort to keep the number of profiles low, developers
of a new profile should try to identify and include other groups
of data users and producers that may have requirements for a
similar new profile.
(5) Ultimate implementation and success of a profile will then include
the creation of product mapping documents, the production of
lots of data using the profile, the development of translation
software by GIS vendors, the approval of the profile to be an
FGDC, ANSI, ISO, or similar standard, and the availability of
official tools to test both data and software for compliance
to the profile.
As noted earlier, the development of new SDTS profiles can be justified
for several reasons. The primary reasons are a need to support
a different spatial data model or variation of a model that is
not supported by any current profiles, the need to harmonize
with other geo-spatial data transfer standards, and the need
to provide an extension to the SDTS base standard. The Transportation
Network Profile was developed in large part because the other
vector profiles did not adequately support the data model needed
for the direct representation of over-passing roadway segments
using primitive non-planar graph elements.
There are also a number of less valid reasons for new profile development
that should be mentioned. Differences in application area or
feature content, by themselves, should not justify different
profiles. For example, the justifications for a railway profile,
a pipeline profile, and transmission line profile because of
different content is questionable. The Transportation Network
Profile is designed for transportation content, but its justification
is due to a data model difference and not specific content.
The DIGEST Vector Profile does mandate the use of the Feature and
Attribute Coding Catalog (FACC) content specification, but this
content requirement by itself does not accomplish harmonization
between SDTS and DIGEST and would not justify a separate profile.
The transfer of specific content is not primarily an issue for
profiles, but should be addressed through possible volumes of
SDTS Part 2, feature registers, or master data dictionaries related
to thematic areas and guided by the Thematic Subcommittees of
FGDC.
The Army, Corps of Engineers, Tri-Service CADD/GIS Technology
Center (http://mr2.wes.army.mil/) is currently working with FGDC
on the development of a common thematic feature registry which
is based on the SDTS model of features, attributes, and value
domains.
Differences in data products and GIS formats are also not good reasons to
develop new profiles. For example, the need for a DLG-3 profile,
a TIGER profile, an Arc/INFO profile, an MGE profile, a SmallWorld
profile, a MapInfo profile, a wetland profile, an elevation profile,
an EPA River Reach profile, a GDT profile, and an ETAK profile
is doubtful. This type of profile proliferation defeats the goal
of SDTS to make data exchange easier, and should be avoided.
Families of Profiles
The grouping of profiles into families is one way to help organize
and emphasize the relationships between profiles. Once a new
profile is justified, developers should seek to maximize the
similarities with other profiles, particularly with similar profiles
in the same family.
A family of profiles is an informal set of profiles that have many
common characteristics and that have translators with many identical
functions, usually because they are based on similar high-level
data models. For example, the Topological Vector Profile, the
DIGEST Vector Profile, the Transportation Network Profile, the
AUSLIG Vector Profile, and the Non-topological Vector Profile
may be in the same family of vector profiles.
The translators for profiles within the vector family of profiles should have
more functions in common than functions, which are different.
In general, the grouping of profiles into families can foster
software reusability, and in particular, will increase the reuse
of translator functions and testing functions.
There may also be a type of multiple inheritance among profile families.
For example, the DIGEST Vector Profile may be a member of the
large vector family, the smaller topological vector family, and
the DIGEST family, which could include possible DIGEST Raster
and DIGEST Spaghetti profiles.
Multiple Data Products Sharing One Profile
As noted earlier, a profile should not be so specific that it is
related to just one native format, one product, or one theme.
A profile should be flexible enough to be shared by multiple
data formats and data structures that have a similar data model.
The relationship, or mapping, between a specific product and
an SDTS profile should be clearly described in a product-mapping
document.
There can be several product-mapping documents for
each profile, e.g., DLG-3 to TVP, TIGER to TVP, National Hydrography
Data to TVP. Figure 1 shows the relationships between the SDTS
base standard, profiles of SDTS, and specific products that are
mapped to profiles. Some product mapping documents are available
on-line through the SDTS site as noted below in the specific
profile status descriptions.
Status of Profiles
The following is a list of the profiles discussed in this section.
Many of these are only suggestions and may not become actual
profiles. Additional profiles may also be planned by other groups
but are not know to the author at this time. Information in this
section is subject to additions and corrections. Additional information
is sought by the SDTS task force (sdts@usgs.gov).
1. Topological Vector Profile, SDTS Part 4
2. Raster Profile with BIIF Extensions, SDTS Part 5
3. Point Profile, SDTS Part 6
4. CADD Profile
5. Transportation Profiles
6. Cadastral Data Transfer Standard (Profile)
7. Primitive, Non-topological Vector Profile
8. Non-US Profiles and Versions of SDTS
9. DIGEST and VPF Profiles
10. Harmonized ISO/DIGEST/S-57/GDF/NTF/SDTS/IHO Profile.
11. Object-Based Profile for Transactions, Multiple Representations,
Dynamic Content, etc.
12. Other Profiles: Graphic, Local Government, Mining, Utility,
S-57, Boundaries, etc.
Back to Top
Data Resolution
Strictly speaking, a digital data file does not have scale, only x-y coordinates
and tabular listings. However, the scale of the source maps from
which digital data is derived does affect the resolution of data
in a GIS. In general terms, resolution is the ability to resolve,
or separate, a particular object from other objects on a map.
When used to describe vector data, resolution is the size of the smallest
geographic entity that can be mapped at a given scale and still
effectively communicate the entity's location and shape. For
example, at a scale of 1:63,360 (in which 1 inch on the map equals
1 mile on the earth's surface), arial features with a dimension
of less than 1/8 mile cannot be represented realistically on
a map because of the difficulty in perceiving the shape of such
small areas.
When used to describe raster data, resolution typically
refers to the size of the grid cell, or pixel; an object smaller
than the pixel size cannot be resolved, or identified by the
sensor as being separate from the object's surroundings.
During map compilation, rules are established based on the map's intended
scale and resolution, determining minimum sizes and dimensions
called minimum mapping units. For example, compilation of a 1:63,360-scale
map might call for any areal geographic entity with a dimension
of less than 1/8 mile to be symbolized as a point or line rather
than a polygon. Consequently, an entity such as a forest stand
mapped as a point at one scale may be represented as an area
on a map at larger scale.
Representation of geographic entities
on a particular map is not absolute, but rather a factor of map
scale, data resolution, and cartographic conventions such as
minimum mapping units used in preparing the map. Users of maps
(and of digital data derived from maps) need to be aware that
these issues play a vital role in determining data content, significantly
affecting data reliability and the fitness of data for use in
a specific application.
Back to Top
