Authors: Monica Mroz, Kimberley Berger, Richard Becherer, Judith Packman
The U.S. Defense Mapping Agency (DMA) is currently in the process of revising and converting its World Vector Shoreline Plus (WVSPLUS) digital database product. The revisions include the addition of bathymetry data, the generalization of the original 1:250,000 scale product into five additional smaller scale libraries, the implementation of adaptive tiling, as well as other changes. The data conversion portion of this project consists of importing the existing WVSPLUS database into ArcInfo and, on completion of the revision process, exporting the six WVSPLUS libraries into DMA's Vector Product Format (VPF) according to the new WVSPLUS product specification. This paper discusses the procedures developed by DMA for revising and converting WVSPLUS using ArcInfo.
The Defense Mapping Agency's (DMA) Enhanced Product Prototyping Environment (EPPE) Laboratory in St. Louis, Missouri is currently in the process of revising its World Vector Shoreline Plus (WVSPLUS) product. This paper contains a discussion of the Department of Defense's Vector Product Format (VPF), the WVS and WVSPLUS products, and the purpose for the revision of WVSPLUS. It will also overview the revision process and give the details of several fundamental concerns of the revision project.
Much of DMA's development and support for the VPF initiative and subsequent product prototypes came from the EPPE Lab in St. Louis. The EPPE Lab, organizationally in DMA's Acquisition & Technology business unit, is a multi-platform computer lab staffed with highly skilled technical personnel including physical scientists, photogrammetrists, cartographers, geodesists, computer scientists, and computer specialists. Two EPPE sites exist, one at DMA St. Louis and one at DMA Bethesda, each maintaining similar combinations of computer hardware and software. The traditional responsibilities of this group range from the creation of Mapping, Charting and Geodetic (MC&G) data and software prototypes to normal and crisis operations support of MC&G applications. More recently, the lab supports MC&G activities that have emerged from evolving technologies such as Geographic Geospatial Information and Services (GGI&S) and Defense Modeling and Simulation. Because the main focus of the EPPE is to support MC&G product and software development, the lab is regularly upgraded to keep up with MC&G computer technology advances. Relationships have been established with other development laboratories in the DoD and intelligence community and are encouraged in order to promote the interoperability of products and services.
In 1989, in cooperation with Environmental Systems Research Institute (Esri) and military mapping components of the United Kingdom, Australia, and Canada, DMA developed Vector Product Format (VPF) in an effort to standardize the vector-based products created and used by the Department of Defense (DoD). A prototype database, Digital Chart of the World (DCW), was created as part of this developmental effort. VPF is a standard format, structure, and organization for large geographic databases that are based on a georelational data model. Although conversion software exists that allows VPF data to be converted to several commercial Geographic Information System (GIS) internal formats, VPF is not considered a transfer or interchange standard. VPF data is intended for direct use in GIS applications and analysis. It is designed to be used with any vector-based geographic data that can be represented using nodes, edges, and faces. VPF's characteristics include:
VPF provides a flexible framework from which multiple products may be defined. Tiling schemes, if desired, may be defined within product specifications and may vary between libraries in a particular database. VPF provides logically consistent topological relationships even if the data is tiled. Libraries containing tiled coverages are required to have two special untiled reference coverages: Tile Reference (TILEREF) and Library Reference (LIBREF). The TILEREF coverage defines the tiling scheme used in the thematic coverages of a library, whereas the LIBREF coverage contains a thinned version of the major features in the library. Thematic coverages and their features are further defined through product specifications. VPF product feature data may be fully layered into thematic coverages or completely integrated in a single coverage and may contain simple and/or complex features, depending upon the definition in the product specification. VPF also supports various levels of topology. Product specifications will determine these topology levels since they are dependent upon the types of features contained within each coverage. The inherently versatile characteristics of VPF have given DMA the ability to define a wide range of products including Vector Smart Map (VMap Levels 0, 1 and 2), Urban Vector Smart Map (UVMap), Vector Interim Terrain Data (VITD), Digital Nautical Chart (DNC), and Digital Topographic Data (DTOP).
World Vector Shoreline (WVS) is a digital DMA product in ASCII coded Standard Linear Format (SLF) that has been in existence since the late 1980's. It contains shorelines derived from Digital Landmass Blanking (DLMB) data and supplemented by Operational Navigation Charts (ONCs) and Tactical Pilotage Charts (TPCs). It also contains international boundaries and country names derived from paper products including ONCs, TPCs, and Joint Operation Graphics (JOGs). In January of 1995, the first worldwide VPF version of WVS, WVSPLUS, was released. Before conversion to VPF, the original WVS data in SLF was supplemented by DMA's Digital Bathymetric Database (DBDB5), offshore territorial boundary information obtained from the DoD Maritime Claims Reference Manual, and new political boundaries inserted for the countries of the former Soviet Union. With these changes made in SLF, the data was translated to VPF using conversion software developed under contract with Naval Command Control and Ocean Surveillance Center (NRaD). This initial conversion method introduced topologic errors requiring a major revision of the VPF data itself. The revision project began in August of 1995. In addition to topologic error correction, however, DMA had expanded prototype objectives for the revision project. Bathymetric area feature data was to be added to three of the smaller-scale libraries using DBDB5 (see Section 3.4 for further detail). Database design improvements were also introduced including additional thematic indices and the implementation of an adaptive tiling scheme in one library (see Section 3.1 for further detail).
The revised WVSPLUS is one database comprised of six libraries. These libraries, WVS250K, WVS001M, WVS003M, WVS012M, WVS040M, and WVS120M, cover the world at 1:250,000, 1:1,000,000, 1:3,000,000, 1:12,000,000, 1:40,000,000, and 1:120,000,000 scales respectively. Each library contains from four to seven thematic coverages, a TILEREF coverage, and a LIBREF coverage (see Table-1).
| libraries: | WVS250K | WVS001M - WVS120M |
|---|---|---|
| Thematic | Coastlines/Countries/Oceans (COC) | Coastlines/Countries/Oceans (COC) |
| Layers | Maritime Boundaries (MAB) | Bathymetric (BAT)** |
| (Coverage | Maritime Boundaries Supplemental (MBS) | Names Placement (GAZETTE) |
| Names): | Names Placement (GAZETTE) | Tile Reference (TILEREF) |
| Tile Reference (TILEREF ) | Library Reference (LIBREF) | |
| Library Reference (LIBREF) | Data Quality (DQY) | |
| Data Quality (DQY) | ||
As the entity responsible for the revision of the WVSPLUS data, the EPPE Lab offered a wide range of resources. Although the main WVSPLUS team was limited to four people, the diverse knowledge and skills of many lab personnel played an important role in the project's success. The WVSPLUS team consisted of one project leader and three VPF specialists who were responsible for generating and inspecting the WVSPLUS prototype. The team also received valuable quality control support from personnel at the EPPE Lab's Bethesda site. The pertinent experience/background of the team's members included VPF Military Standard development, VPF product prototyping, VPF product generation and product validation, a firm understanding of the concepts of GIS, and GIS software experience.
The EPPE's integrated network of computing workstations and peripherals in St. Louis incorporate IBM-PCs, Macintoshes, SUNs, Hewlett-Packards, and Silicon Graphics. Several SUN workstations were used for the purposes of the WVSPLUS revision project, each having a SUN SPARCserverMP with 120 megabyte memory using two to four CPUs and running SUN-OS version 4.1.3. Productivity was greatly increased due to the introduction later in the project of a SUN SPARCserver1000E with 256 megabyte memory, containing a SuperSPARC chip, and running SUN SOLARIS version 2.4.
Commercial-off-the-Shelf (COTS) software available in the EPPE Lab includes ArcInfo, ERDAS, ADOBE PHOTOSHOP, SPYGLASS, and ORACLE. Because its VPFIMPORT and VPFEXPORT capabilities are proven tools in the creation of VPF products, ArcInfo was chosen as the main software environment for the purposes of the WVSPLUS revision project. In the process of working on the project, ArcInfo versions 7.0.2 through 7.0.4 were used. The cooperative nature of the relationship between DMA's EPPE Lab and Esri has been mutually beneficial in the enhancement and revision of ArcInfo's VPFEXPORT capabilities.
Additional software employed in the WVSPLUS revision project include DMA MC&G Utility Software Environment (DMAMUSE) and ERDAS IMAGINE. DMAMUSE was first used in the project to read the DBDB5 bathymetric data into its internal format and output it in ArcInfo LATTICE version 5.0 format. DMAMUSE was later used in combination with ERDAS IMAGINE to convert DMA Compressed Arc Digitized Raster Graphic (CADRG) data to ArcInfo GRID format. Data converted from CADRG served as a raster backdrop in digitizing the new country boundaries in the area of the former Yugoslavia. Because no capability of reading or converting DBDB5 or CADRG data currently exists within ArcInfo, DMAMUSE served as a valuable tool in these conversion processes.
A brief WVSPLUS description is necessary to fully understand the revision method. WVSPLUS contains six libraries, varying in scale from 1:250,000 to 1:120,000,000, organized by thematic layers (See Table 1). The seamless WVSPLUS database uses the Digital Geographic Information Exchange Standard (DIGEST) Feature and Attribute Coding Catalog (FACC) for feature identification and implements the World Geographic Reference System (GEOREF) for tile identification. GEOREF divides the earth's surface into quadrangles defined by arc lengths of longitude and latitude. Systematic letter codes assigned to each quadrangle assure unique identifications. WVSPLUS contains four tiling schemes ranging from 1° x 1° to 30° x 30° (See Table 2).
| Library | Scale | Tile Size (long x lat) |
|---|---|---|
| WVS250K | 1:250,000 | 5° x 5° or 1° x 1° |
| WVS001M | 1:1,000,000 | 10° x 5° |
| WVS003M | 1:3,000,000 | 10° x 10° |
| WVS012M | 1:12,000,000 | 30° x 30° |
| WVS040M | 1:40,000,000 | 30° x 30° |
| WVS120M | 1:120,000,000 | 30° x 30° |
All six original WVSPLUS libraries contained topology errors along tile boundaries and within the feature data itself. The WVSPLUS team evaluated three possible revision methodologies before beginning the project. The first and most direct approach consisted of importing all six libraries into ArcInfo and subsequently correcting the topology errors in each individual library. A second approach involved correcting the largest scale library (WVS250K) and subsequently generalizing it by appropriate tolerances to derive the remaining five smaller scale libraries. The third approach consisted of correcting the largest scale library first (WVS250K) and successively generalizing to create each succeeding library. For example, a topologically correct WVS250K library generalized by an appropriate value and corrected would create the WVS001M library. The topologically correct WVS001M library generalized by an appropriate value and corrected would create the succeeding WVS003M library. Successive generalizations would continue until reaching the smallest scale library.
The third approach appeared to offer several advantages over the first two approaches. First, redundant topology correction would be avoided since succeeding libraries would be derived from an already topologically correct library. By using the third approach, original topology errors would need correcting only in the WVS250K library. A second advantage was reduction of import time. Manipulating a corrected WVS250K library to derive succeeding library coverages eliminates the need to import the five smaller scale libraries. Importing a world-wide tiled VPF library takes substantial time and eliminating the need to import five libraries saves considerable time. One important element affecting the entire project was the large amount of data being manipulated. This project frequently utilized ArcInfo Macro Languages (AMLs) to automate repetitive steps and to assist in data management.
Both the second and third approaches described above are similar in that both utilize a corrected WVS250K library. The two approaches differ in the method of deriving succeeding libraries. The fact that ArcInfo's generalization tool introduces topology errors influenced the decision to use the third approach over the second approach. By creating each library from the preceding scale library, the time spent on correcting topology errors was minimized. Generalizing a smaller scale library creates fewer errors since smaller scale libraries contain less data.
Revising and processing all WVSPLUS libraries followed the same underlying procedure. The following section describes the overall revision method implemented for the WVS250K library. All six libraries follow the same basic steps but separate descriptions explain additional steps or deviations from the WVS250K when appropriate.
The first objective was to obtain an ArcInfo topologically correct world-wide coverage for every tiled VPF thematic coverage. Tiled thematic coverages contained in the WVS250K library include the following: COC, MAB, MBS, and DQY (See Table-1). Since the original VPF data contained numerous topology errors along tile borders, it was imperative to take advantage of ArcInfo's LIBRARIAN module. LIBRARIAN creates an individual coverage for each tile in a VPF library by using a topologically correct world-wide coverage. Inserting a topologically correct world-wide coverage into an ArcInfo library prevents topology errors along tile boundaries. The following description explains the process followed to create a COC world-wide coverage. The same process applies to the MBS, MAB and the DQY thematic coverages.
Due to the large number of tiles (2952) contained in the WVS250K library, an AML was utilized to import the COC coverage. Two thousand nine hundred fifty-two unprojected (decimal degrees) coverages resulted from the import command. Because some coverages contained errors and some did not, an AML was developed to identify which of the 2592 coverages did contain errors, thus eliminating the need to manually investigate every coverage. Using ARCEDIT, intersect and/or label errors were corrected. At this point, there were 2952 topologically correct ArcInfo coverages containing COC data.
The last step in the creation of a world-wide COC coverage involved edgematching the 2952 topologically correct coverages. For the purpose of data manageability, a systematic edgematching routine consisting of appending and dissolving coverages was applied. Adjacent coverages located on identical 5° latitudinal bands were edgematched one after the other until 36 strips circling the world existed. Five degree latitude bands correspond to the original WVS250K library tiling scheme (See section 3.1 for further details). Every nine adjacent 5° latitudinal strips were appended and dissolved to create four 45° latitudinal strips circling the world. The four 45° latitudinal strips were appended and dissolved to create an entire 1:250,000 scale world-wide COC coverage (See Figure 1). This COC world-wide coverage is the basis for all succeeding library COC data.
The next objective, after acquiring a world-wide coverage, was to create an ArcInfo library and to prepare the data for export. An ArcInfo library produces the desired VPF tiled output and prevents tile boundary topology errors. The ArcInfo-to-VPF Conversion Guide 1993 lists the steps necessary to create an ArcInfo library and to prepare data for export. During data insertion, LIBRARIAN uses an INDEX (grid) coverage formatted to the appropriate VPF library tiling scheme as a template. The INDEX coverage was created and an AML developed to populate such fields as "tile-names" and the VPF database path "location" attributes. Each tiling scheme required a separate AML tailored to accommodate tile names identified by GEOREF.
Inserting the world-wide COC coverage into an ArcInfo library required several actions using the LIBRARIAN module. BUILDTILES created workspaces corresponding to tile-names and locations identified in the INDEX coverage and CREATELIBRARY created the ArcInfo library. The LIBRARY, SETCOVER, and INSERT commands were used to insert the COC world-wide thematic coverage as a layer into the ArcInfo library. At this point, acting as a template, the INDEX coverage divided the COC world-wide coverage into coverages simulating the VPF tiles, thus preventing the occurrence of tile boundary topology errors. Because the VPF TILEREF coverage defines the tiling scheme for each library, it was the first coverage exported along with the VPF database and library level metadata tables. Exporting the ArcInfo INDEX coverage using a conversion control file created the TILEREF VPF coverage and the following tables: Database Header Table, Library Attribute Table, Library Header Table, Coverage Attribute Table, and the Geographic Reference Table. The COC data held in the ArcInfo library was exported using the VPFEXPORT command in conjunction with a conversion control file (See section 3.2 for further conversion control file details). After all tiled thematic coverages were exported into VPF, the VPFTILE command was executed to create cross-tile topology. The WVS250K library's remaining MAB, MBS, and DQY coverages followed the same process just described, up to cross tile topology creation. Cross tile topology was created only after all coverages in a library were exported.
Since the LIBREF and GAZETTE coverages are untiled, the process for exporting these two coverages was a basic VPFEXPORT command. The LIBREF and GAZETTE coverages were inserted into all six WVSPLUS libraries. The following steps summarize the overall methodology implemented during this project: correct original topology errors, create a world-wide coverage, create an ArcInfo library, create an ArcInfo INDEX coverage, export ArcInfo INDEX coverage to create VPF TILEREF and database and library metadata tables, insert coverage as a layer into the ArcInfo library, export all thematic coverages, create cross tile topology, and export the untiled LIBREF and GAZETTE coverages.
Coverages contained in the WVS001M library include the following: COC, GAZETTE, TILEREF, and LIBREF. COC is the only tiled coverage in the WVS001M library. The main difference in processing the WVS001M library and the WVS250K library dealt with deriving and processing a world-wide COC thematic coverage. For data manageability, the 1:250,000 scale world-wide COC coverage was clipped into 20° longitudinal coverages. The 20° longitudinal coverages were projected into the transverse Mercator projection in order to generalize them by a pre-calculated tolerance applicable to obtaining 1:1,000,000 scale data. Polygons (islands) not meeting the area requirement for 1:1,000,000 scale data were deleted. After projecting the 20° longitudinal coverages back into decimal degrees, topology errors created through generalization were corrected. The corrected 20° longitudinal coverages were then systematically edgematched using append and dissolve to create a 1:1,000,000 world-wide COC coverage. Every two adjacent 20° longitudinal coverages were edgematched to create 40° longitudinal coverages, the 40° longitudinal coverages were then edgematched to create 80° longitudinal coverages. The edgematching process continued until a world-wide COC coverage existed. From this point on, the same process as that applied to the WVS250K library applied here.
Coverages contained in the WVS003M library include the following: COC, BAT, GAZETTE, TILEREF, and LIBREF. Tiled coverages in the WVS003M library included COC and BAT. The 1:1,000,000 scale 20° longitudinal coverages were generalized using a pre-calculated tolerance applicable to obtaining 1:3,000,000 scale data. From this point on, the same COC procedures used for the WVS001M library applied to the WVS003M library. Part of the WVS003M revision process included the addition of bathymetric data derived from the Digital Bathymetric Database (DBDB). (See section 3.4 for further details.) The same procedure as that applied to the world-wide 1:250,000 COC coverage applied to the BAT world-wide coverage.
Both the WVS012M and the WVS040M libraries include the following coverages: COC, BAT, TILEREF, LIBREF and GAZETTE. COC and BAT coverages are both tiled in the WVS012M and the WVS040M libraries. The 1:3,000,000 COC 20° longitudinal coverages were generalized by an appropriate tolerance to derive the 1:12,000,000 COC scale data. Generalizing the 1:12,000,000 COC 20° longitudinal coverages by an appropriate tolerance created the 1:40,000,000 COC data. From this point on, the same process applied to WVS003M library COC data applied to both the WVS012M and the WVS040M library COC data.
The 1:3,000,000 world-wide BAT coverage was clipped into 20° longitudinal bands. Generalizing the 20° longitudinal bands by a specified tolerance created the 1:12,000,000 scale BAT data. The same processing technique applied to the 1:1,000,000 scale COC data applied to the 20° BAT longitudinal coverages. Generalizing the 1:12,000,000 scale BAT 20° longitudinal coverages by an appropriate tolerance created the 1:40,000,000 scale BAT data. From this point on, the same process as explained before applied to the WVS012M and the WVS040M libraries.
The WVS120M library contains COC, LIBREF, TILEREF, and GAZETTE coverages. The same COC generalization technique as described for the larger scale libraries applied here. Generalizing the 1:40,000,000 COC 20° longitudinal coverages by an appropriate value yielded the 1:120,000,000 COC data. From this point on, the same process as explained before applied to the WVS120M library.
The following sections give details of several of the fundamental issues and concerns of the revision project: adaptive tiling, conversion control files, generalization, and the creation of bathymetric data. The first three describe concepts or tools and how they related to the WVSPLUS revision process. The discussion of bathymetric data contains a description of the revised WVSPLUS bathymetric data creation procedure.
In dealing with large volumes of data of any kind, it is often desirable that the data be subdivided into smaller, more manageable units. Geographic data is no exception and may be spatially subdivided, or tiled, using any number of different schemes. As mentioned earlier, VPF provides a means, through the TILEREF coverage, for defining the tiling scheme for a library's coverages. TILEREF contains area features, each defining a tile, that when combined cover a library's extent. Coordinates defining the tiles are contained in TILEREF's primitive tables. Although tiling schemes in VPF may be consistent or adaptive, one requirement of VPF is that the same tiling scheme be applied to each tiled coverage within a library. A consistent tiling scheme is one whose tiles remain the same size throughout the geographic extent of a library. Although maintaining a consistent tile size throughout a library may seem logical, it can sometimes cause poor performance when processing the data. If data were consistently dense throughout a library's extent, consistent tiling would indeed be the most logical method. An adaptive tiling scheme increases performance by allowing different tile sizes and/or shapes in an attempt to capture a more consistent or more manageable amount of data in each tile.
Because the spatial extent of degrees of longitude decreases the further one moves from the equator, one common approach to adaptive tiling is to use bands of latitude to define tile size. To counter this decrease in east-to-west distance, the longitudinal dimension of tiles (or both dimensions if desired) is increased by a certain extent. For instance, tiles between 30° north and south of the equator may be 1° of latitude by 1° of longitude, whereas tiles between 30°-45° north and south may be 1° of latitude by 1.25° of longitude. In this example, the east-to-west tile dimension might increase by .25° for every 15° of latitude thereafter. Several existing VPF products currently employ adaptive tiling using latitude banding.
Whereas the adaptive tiling approach described above ensures relatively consistent geographic coverage in each tile, it does not address the issue of feature density within tiles. Because different types of entities are not evenly dispersed throughout the world, an adaptive tiling approach based solely on data density may prove to be more efficient. Which type of adaptive tiling approach works best depends upon the types of features contained in a product. Products whose features are dispersed in a similar pattern across coverages may be more suited to an adaptive tiling scheme based on data density. On the other hand, in products containing many different types of features, a tiling scheme which seems entirely appropriate in one coverage may be wasteful in another . If, collectively, the features in all coverages are well dispersed, however, this difference in efficiency may be overcome by a latitude banding approach to adaptive tiling.
Table-2 shows the tile sizes for each library in the WVSPLUS prototype. The WVS250K library is the only library in which adaptive tiling has been implemented. The original SLF WVS 1:250,000 scale data had been released in 1° x 1° cells. When first converted to VPF, a consistent 5° x 5° tiling scheme was employed. In an effort to enhance processing performance, the revised WVSPLUS library used an adaptive tiling scheme based upon data density in the tiles of COC, its most dense coverage. Using ArcInfo, the number of polygons in each 5° x 5° tile was determined. Tiles containing greater than 1000 polygons were subdivided into 1° x 1° tiles. Later, in an effort to further improve processing performance, tiles with more than 700 polygons were also subdivided. Although a variation of an adaptive tiling scheme based on latitude bands was considered and tested, it was decided against due to the overtiling that would have occurred in areas of low density.
Conversion control files were a major factor to the success of deriving the desired WVSPLUS VPF output. Conversion control files are used to customize VPF default characteristics created during export to match VPF product specifications. Not all VPF products contain like structures. For instance, some VPF products contain libraries dependent upon geographic locations rather than varying scales. Due to conversion control files and the flexibility of VPF, WVSPLUS is only one of many VPF products possibly created through ArcInfo. The fact that VPF is such a flexible format allows varying structures to exist for VPF products. For future production on revision or creation of VPF products, production members can reuse conversion control files to assure data consistency and as a form of quality control. Creation of conversion control files requires an in-depth knowledge of VPF, WVSPLUS product specifications, and ArcInfo in order to derive the desired product specifications. For this project, conversion control files were used to alter table headers, independently create thematic indices, and to selectively edit attribute information without importing a coverage.
Altering a table description is a simple example for using a conversion control file to alter table headers. For example, the WVSPLUS product specification requires the following description for the BAT coverage character value description table "Bathymetric Character Value Description Table". The default description created during export is the name of the table, "char.vdt". By using a conversion control file, the required product specification overwrites the default description. This conversion control file example is one of many and is one of the simplest used during this project. Certain VPF product specifications do not include all ArcInfo items contained in a coverage. Export automatically creates VPF columns and VPF column names corresponding to the items and item names contained in an ArcInfo coverage. Conversion control files were used to omit items not needed and to change item names when not compliant with VPF product column naming conventions.
Conversion control files were used to create thematic indices required in VPF products. Thematic indices tabulate the number and type of features contained in the export coverage and accelerate the querying process in software products such as VPFVIEW. A valuable lesson concerning the creation of thematic indices was learned during the first COC export process. Creating thematic indices while exporting the COC coverage took an inordinate amount of time. The COC export process utilized a conversion control file calling for the creation of thematic indices. The export process updated the indices each time a coverage exported, which was correct, but required considerable time. For future coverage exports, the conversion control file used during export omitted the call for thematic indices. A different method and a different conversion control file were used to acquire the required thematic indices. VPF feature tables created during export were re-imported into ArcInfo and then re-exported with a new conversion control file calling for the creation of thematic indices. Exporting a table to create thematic indices took considerably less time than creating indices when exporting a coverage.
At times it was necessary to update or edit VPF attribute data but not the primitives associated with the feature. For instance, new countries occupying the former Yugoslavia area required only attribute changes in the MBS coverage. Tables needing updates were imported into ArcInfo and attribute values were corrected using the ArcInfo TABLES module. Conversion control files were then used to format the tables into correct VPF WVSPLUS specifications during export. To selectively edit attribute values without re-importing and re-exporting coverages, conversion control files were needed.
The four elements of generalization are (1) simplification - elimination of unwanted detail; (2) classification - grouping of data; (3) symbolization - graphic coding of classes; and (4) induction - application of inference. The element of generalization discussed and referred to in this section is simplification. Simplification is the determination of the important characteristics of the data, the elimination of unwanted detail, and the retention of the important characteristics (Robinson et al, p. 125).
A major portion of the WVSPLUS revision project entailed the correction of topology errors occurring in the COC coverage in all libraries and the BAT coverage in three of the smaller scale libraries. The WVSPLUS team determined that the most efficient method to achieve this goal would be to correct only the largest scale COC and BAT coverages, then create the smaller scale coverages through iterative generalizations. Although this approach had the possible drawback of compounding accuracy problems, it also had the significant advantage of eliminating the need to carry out two time consuming processes: (1) importing all of the smaller scale libraries from VPF into ArcInfo format, and (2) revisiting topology errors in every library.
In order to effectively generalize the WVS250K COC and WVS003M BAT data , the data was required to be projected in an equal area, or near equal area, projection that retained the shape of features. A transverse Mercator (TM) projection was chosen for the generalization portion of the project due, in part, to its conformal, or shape-retaining, characteristic. Since scale exaggeration increases moving away from the central meridian, the TM projection is useful for only a certain zone along either side. In order to maintain an equal area characteristic, ArcInfo's ARCEDIT module suggests the use of bands no greater than 40° wide. For the purposes of generalization, the worldwide WVS250K COC and WVS003M BAT coverages were subdivided into eighteen 20° longitude bands, each of which was then projected to TM. The smaller TM zones not only were more accurate in terms of area, but also provided more manageable units to process.
Three major steps in generalizing the data in the 20° bands were: (1) the deletion of small islands, (2) generalizing arcs, and (3) correcting errors created by the generalization of arcs. Small islands were deleted from each longitude band using a minimum resolvable area based on National Mapping Accuracy Standards. Because an area threshold was used in eliminating these features, the equal area characteristic of the 20° TM bands was especially important in this step. Island features below the threshold area, but split at borders of longitude bands, were not deleted unless it was determined that the entire island fell below the area criteria.
Each polygon in an ArcInfo coverage contains a label point. Generalizing the arcs of a coverage may cause labels to inadvertently fall outside of their polygons in the resultant coverage. In order to reduce this type of error when generalizing the WVSPLUS COC and BAT data, the ArcInfo CENTROIDLABELS command was used with the INSIDE option prior to the coverage being generalized. This command calculated the interior centroid of each polygon and moved the corresponding label point to that location. When the coverage was generalized, therefore, the label points were less likely to fall outside of their corresponding polygons.
ArcInfo utilizes a standard Douglas-Peuker generalizing algorithm with a user-defined weed tolerance. Weed tolerances used for each scale of the WVSPLUS project were based upon comparison of the generalization results with cartographic products of the same scale. The generalizing algorithm runs a straight trend-line between the start and end nodes of each arc. It then calculates the perpendicular distance from that trend-line to each vertex along the arc. Those vertices whose perpendicular distance falls below the weed tolerance are deleted. Two new trend-lines are created from the endpoints to the remaining vertex with the longest perpendicular distance from the original trend-line. Again, vertices are deleted if their distance from the trend-line is below the set tolerance. This iterative process continues until there are no vertices farther than the set tolerance from the trend-line. The Douglas-Peuker generalizing algorithm is considered by many cartographers to be the most accurate simplification algorithm available (Jenks, p. 30).
The two major types of errors caused by generalization are intersection errors and label errors. Although these errors could be detected and fixed in any projection, for the purposes of the revision project, the generalized coverage was projected back to decimal degrees first. Intersection errors in ArcInfo occur when two arcs cross with no node at their intersection, when one arc loops back upon itself, or when two arcs are directly on top of each other. These errors can be detected and listed using the ArcInfo INTERSECTERR command and then corrected in the ARCEDIT module. Label errors occur when polygons exist with no label points or with multiple label points. Label errors may occur even if CENTROIDLABELS was used before generalizing. They may be detected using ArcInfo's LABELERRORS command, and may be corrected in the ARCEDIT module by moving and reattributing, adding, or deleting polygon labels.
Once generalized and edited, the eighteen 20° bands were systematically edgematched and appended to create one combined coverage. Edgematching was accomplished by establishing an editcover and snapcover in ARCEDIT and employing commands such as SNAPFEATURE, SNAPPING, and SNAP. The ArcInfo APPEND command together with DISSOLVE acted to physically join and merge the eighteen separate coverages in both COC and BAT into one world-wide coverage for each.
The WVSPLUS revision project created new bathymetric data even though the original WVS003M, WVS012M, and WVS040M libraries contained bathymetric coverages. There were two main reasons for creating new bathymetric data instead of revising and correcting the existing data. Original WVSPLUS libraries contained only linear feature data with an attribute specifying the depth contour value. New WVSPLUS specifications required the addition of area features with attributes identifying the highest and lowest contour values between depth contours. The addition of area feature data was one reason for creating new data. The second reason for creating new bathymetric data was to eliminate correcting original topology errors. The same type of topology errors existing in the COC, MAB, and MBS coverages existed in the BAT coverage. To avoid correcting the original topology errors, a decision was made to derive a new bathymetric coverage. Bathymetric data was readily available in the EPPE Lab but not in a format ArcInfo was capable of importing. Incorporating new bathymetric data into WVSPLUS presented two problems: (1) finding a way of imorting bathymetric data into ArcInfo; and (2) finding a means of creating bathymetric area features.
Digital Bathymetric Data Base 5 (DBDB5) was available in the EPPE Lab on the DMAMUSE CD-ROM. DBDB5 is a gridded bathymetric database developed by the Naval Oceanographic Office (NOO). Depth values stored in ASCII files are in uncorrected meters for every five minutes of latitude and longitude worldwide. DMAMUSE software has the capability to import DBDB5 into its internal format and to export the DBDB5 to several formats, one format being ArcInfo LATTICE version 5.0. Team members used DMAMUSE to export the world-wide DBDB5 into ArcInfo LATTICE version 5.0. Using DMAMUSE to export the DBDB5 into an ArcInfo format solved the first problem presented by creating new bathymetric data. The second problem to solve was how to create the required bathymetric area features.
A procedure listed in the 15th Annual Esri User Conference Workshop Proceedings presented a method to derive area features from a lattice database. The basic steps for deriving area bathymetric features involved the following: create the linear coverage, build polygon topology for the linear coverage, populate polygon labels with an elevation attribute value interpolated from the lattice, and then add and populate area attributes with values identifying the high and low depths. A linear coverage was created by executing the LATTICECONTOUR command. LATTICECONTOUR uses lattice depth values to create bathymetric contours at specified intervals. Building the bathymetric linear coverage with polygon topology created a coverage containing area features representing the area between bathymetric contours. Polygon label points were added to each polygon and then put into a separate point coverage. The LATTICESPOT command was used to interpolate depth values for every point in the point coverage. The label points, now attributed with interpolated depth values, were put back into the polygon coverage. At this point, the polygon coverage included area features with label points containing an interpolated depth elevation. The last step for processing the bathymetric data required the addition and attribution of highest and lowest contour values. Contour Value High (CVH) and Contour Value Low (CVL) were added as items to the polygon coverage. Using ARCEDIT, the label points were selected dependent upon the depth elevation value being equal to or less than and equal to or greater than two values specified in the WVSPLUS specifications (such as -200 and -400). Appropriate values were then assigned to the CVH and CVL attributes. The same process was applied to every bathymetric elevation range identified in the WVSPLUS specifications. At this point, the bathymetric data was in a topologically correct BAT world-wide coverage and the processing applied from this point on followed the same procedures as those described in section 2.2.
Careful planning is the key to success in projects requiring the generation, editing, and/or processing of large databases. As mentioned earlier, subdividing, or tiling, data into more manageable units is often desirable. This concept of manageable work units was incorporated not only in the design of the WVSPLUS product itself, but also in every aspect of its creation. The sheer size of the WVSPLUS database and its six libraries dictated the approach taken for each process.
The volume of data contained in each of the six libraries played a major role in the decision to use the "edit-once-and generalize" method in the removal of topology errors and additional editing of the WVSPLUS data. It also was a main factor in choosing the method of editing the WVS250K data itself. Editing and appending individual tiles, as opposed to editing world-wide coverages, allowed for better processing times in editing, display, automatic error detection, and the building of topology. Although data volume was also an issue for processes requiring projection, a more basic issue was that of geographic extent. For instance, the equal area characteristic of the projection chosen for generalization, transverse Mercator, has limited accuracy based on the longitudinal geographic extent. For that reason, generalization was performed in work units of 20 longitudinal bands. The division of data into logical work units had different benefits, therefore, depending on the particular operation.
ArcInfo's LIBRARIAN subsystem is a map library management tool designed around this same concept of manageable work units. LIBRARIAN's INDEX coverage is a standard polygon coverage that defines the ArcInfo library's tiling scheme. It is analogous to the TILEREF coverage in VPF products and is actually used to create TILEREF in the exporting process. Once edited, edgematched, and appended, world-wide coverages were inserted into a map library using the INDEX coverage as a template for subdividing the data. LIBRARIAN also assured the later creation of correct cross-tile relationships during the VPFTILE process.
In addition to manageable work/processing units and structured data organization, efficient processing techniques can help in streamlining overall project methodology. After exporting the WVS250K library from ArcInfo to VPF, the WVSPLUS team learned that exporting time could be decreased dramatically by waiting until all tiles had been exported to create thematic indices. Creating thematic indices and feature tables at the same time was inefficient because it caused thematic indices to be updated with each new tile of data added to the feature tables. By waiting to create thematic indices until all tiles had been exported, the thematic indices were created once.
In the process of the WVSPLUS revision project, a great deal has been learned both about ArcInfo's diverse functionalities and about producing and working with large geographic databases. As an added bonus, the project experience also brought to light potential product maintenance issues which will need to be considered. The EPPE Lab is continually looking for new and improved methods of prototype development. Part of what has made the WVSPLUS revision project a success is that the knowledge and insights gained can and will be applied to future EPPE projects.
Although not listed as an author for this paper, the WVSPLUS revision project owes a large portion of its success to Mary Kubik. As an original WVSPLUS team member, Mary played an important role in many of the key decisions in the revision project. Mary is currently working for DMA as a technical liaison.
Environmental Systems Research Institute. 1995. Workshop Proceedings of the 1995 Esri User Conference . Volume 2. USA: Environmental Systems Research Institute, Inc.
Environmental Systems Research Institute. 1996. ArcDoc Version 7.0.
Environmental Systems Research Institute. November 1993. "ArcInfo-to-VPF Conversion: A Step-by-Step Guide".
Jenks, George F. 1989. Geographic Logic in Line Generalization. Cartographica Volume 26 Number I (Spring): p. 27-42.
Robinson, Arthur H., Randall D. Sale, Joel L. Morrison, Phillip C. Muehrcke. 1984. Elements of Cartography, 5th Edition. New York: John Wiley & Sons.
U.S. Defense Mapping Agency. No Date. Digitizing the Future. 4th Edition.
U.S. Department of Defense. 12 October 1993. MIL-STD-2407 Military Standard Vector Product Format .
U.S. Department of Defense. 30 September 1995. MIL-W-89012A Military Specification World Vector Shoreline Plus .