In the example above, the center of the image contains the seam between two 1:24,000 quad maps. The actual edge of each quad image is to the left and right of the seam. Therefore, you will still see some sort of neatline, but you will not see the boundary of the images. An exception is if the two quads do not match because of differences in color between them or differences in geo-referencing accuracy. But the idea is that steps are taken to reduce the amount of differences between quads and make them appear as seamless as possible.

The SJRWMD covers 240 USGS 1:24,000 quads. Since we wanted some overlap with the other Water Management Districts, we are also including at least 100 more quads. That means we had at least 340 quads to process. In addition, there are several 1:100,000 and 1:250,000 quads that we also needed to process. This methodology can be applied to any one of these map series. For simplicity, this methodology only referes to the 1:24,000 quads.

The SJRWMD uses the UTM Zone 17 NAD 83 (HPGN) projection and coordinate system. The target projection for the quads was NAD83 without the 90 adjustment. The adjustment accounts for about 40 cm of difference, which is much less than the spatial accuracy of the quad maps.

The District has ARC/INFO and ERDAS Imagine, which are both capable of changing raster data projections using resampling techniques. We have found ERDAS to be at least 100 to 150 times faster at projecting raster data. For example, a 1:24,000 quad may take 5 hours to project in ARC/INFO GRID, but only 2 minutes in ERDAS Imagine.

The problem with ERDAS is that we have not been successfull at automating ERDAS using its EML language. We attempted to automate our Districtwide conversion from State Plane East NAD 27 to UTM NAD 83-90 using EML and it simply did not work right. Tech support from ERDAS tried to help us out, but they finally said "Use the C-Toolkit." We don't have the resources to write custom C code, so that wasn't an option. Manually using ERDAS through the Graphical User Interface was easy, but it was laborious and people become prone to mistakes after doing 10 quads in a row. Even though the project is fast, you still have to import the TIFF file, set-up the projection parameters, do the project, then convert the file back to a LAN or TIFF file.

ARC/INFO is highly automatable through AML. Even though the processing time is orders of magnitude slower, we decided to use GRID and let it run in the background accross multiple CPUs. We developed two AMLs to automate the projection process. The first AML, loop.aml, was a very simple AML that converted the TIFF images to GRID format and projected each file.

Approximately 275 quads were projected over 1 month's time. This was done utilizing a dual processor SPARC Ultra powered Enterprise 3000 server and a SPARC Ultra 1 Model 170. The process was interrupted several times by un-related network configuration changes. However, we were able to run the processes for days on end which helped speed the processing. The key was to keep the computers busy and be patient. Disk space was not an issue, because we had a 14 GB partition available on the server and a 3 GB partition available on the workstation.

An AML named scan24_proc1.aml was created for removing the map collar. The AML used the SJRWMD 1:24,000 quad index coverage to reselect polygons to clip the GRID format DRG.

The basic methodology is as follows:

1. Using cursors, get the 4-digit WMD quad number from the index24 coverage. (the USGS quads use a LAT/LONG and alpha-numeric numbering scheme).
2. Reselect the quad polygon from the index24 coverage (based on NAD27 tiles!)
3. Clip the DRG with the quad
4. Rename the quad to the WMD standard

A separate AML named scan24_proc2.aml was developed for creating the images that became part of the seamless DRG layer.

The basic methodology is as follows:

1. With a simple looping AML, put all of the clipped DRGs that will be needed into a single directory.
   • NOTE: I had problems putting more than 150 GRID format DRGs in one directory. I never resolved what the problem was. GRIDs were randomly becoming corrupted when I copied more into the directory. Therefore, I had to do this whole process in batches.
2. Get the coordinates for the quad box and add a 100-meter buffer
3. Use the coordinates with the generate command to generate a polygon coverage
4. Calculate which quads will be needed
5. Merge all available surrounding quads (up to 8 plus the quad itself) /* and re-clip the grid using the generated polygon coverage
6. Convert the DRG from GRID to TIFF image
7. Clean-up

The image catalog allows you to seamlessly browse the 1:24,000 DRGs without having to know which quad to load into ArcView or Arcplot.

Following are the two ARC/INFO commands necessary to implement the catalog.

1. CREATECATALOG drg24
2. ADDIMAGE drg_list drg24

In ArcView, image catalogs are selected by adding an image theme type and you must go into the INFO directory where the catalog is stored in order to see the catalog.

In ArcPlot, image catalogs are treated like a single image on the command line, e.g. IMAGE drg24

The result is a set of DRG images that are squared off using the surrounding DRGs. The net effect, when used in conjunction with an image catalog, is the appearance of a seamless DRG layer in the GIS.

On-screen, the 1:24,000 DRGs look best at a scale less than 1:24,000. This is because the screen is not as high resolution as the printed map is. The features on the map therefore do not have enough pixels on the screen to properly represent themselves. The 1:100,000 and 1:250,000 maps are similar in this respect.

The TIFF image format using packbits compression is the same format that the USGS uses for the DRGs. The amount of compression varies by quad, depending on the variation in color on the quad. To give you an idea of disk space requirements, 275 quads in compressed TIFF format is taking up 2200 MB of space. File sizes range from around 3 MB to 23 MB. The average appears to be around 8 MB.

The process outlined above is time consuming, but the computer does most of the work and the results are well worth it. The DRGs now serve a major role as a complete base map for use within the SJRWMD's GIS.