Proceed to GeoCommunity Home Page

SpatialNewsGIS Data DepotGeoImaging ChannelGIS and MappingSoftwareGIS JobsGeoBids-RFPsGeoCommunity MarketplaceGIS Event Listings
HomeLoginAccountsAboutContactAdvertiseSearchFAQsForumsCartFree Newsletter

Sponsored by:

Download Data





FEMA Flood Data





Index Grids

About Data


SpatialNews Daily Newswire!
Subscribe now!

Latest Industry Headlines
Blue Marble Releases Geographic Calculator 2017 with New Quality Control Tool for Seismic Survey Data
OGC Seeks Comment on Candidate InfraGML Part 7 Land Division Standard

Latest GeoBids-RFPs
Cartography Training-VA
A & E Services-OR
Remote Sensing-UT
Surveying and Mapping-WA
GPS Locators-MN

Recent Job Opportunities

Recent Discussions
DEM to DTM in Inroads
GZ File
LiDAR-derived DEM
space syntax
DEM data for Israel
GISDataDepot - Accuracy Considerations

GISDataDepot > HelpDesk > 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) (

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 ( 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 ( 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 (

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

Sponsored by:

For information
advertising rates
Click Here!

Copyright© 1995-2014 MindSites Group / Privacy Policy

GeoCommunity™, Wireless Developer Network™, GIS Data Depot®, and Spatial News™
including all logos and other service marks
are registered trademarks and trade communities of
MindSites Group