The Texas Speleological Survey karst database was maintained for many years as a Microsoft Access database, with the data residing in a table with about 70 fields. In 2009, the TSS adopted a round-tripping process to more easily manage the data as geographical information. Two TSS-specific programs were developed for transferring data between the Access table and a WallsMap project named TSS_Data. WallsMap could then be used for entering new karst features, visually verifying locations, and adding links to documents and image files. In early 2014, a new general-purpose feature, Compare with Other Layers, made it possible to completely remove Access from the maintenance loop. (See Keeping the Database Current.)
Each record in the database corresponds to a location of interest in Texas, normally that of an entrance to a cave or similar geologic feature. In some cases, however, we don't have a good approximation for location. To represent such features in the TSS_Data project we've reserved a dummy location in the SE corner of New Mexico. Like other features, their attributes can be searched for and their records edited.
When you explore the Texas project you'll find caves without valid coordinates, but with data in other fields that would narrow the location to a ranch, USGS quadrangle, or maybe to within a few kilometers of something with a known location. The database has a field named COORD_ERR that stores a horizontal location uncertainty in meters. As of Oct, 2014 more than half of the records had uncertainty values assigned. About 17% of the more than 13000 features in the database were without approximate coordinates, with another 2% having uncertainties of at least 500 meters.
Since it's our policy not to publish exact cave locations, we obviously have to limit distribution of the TSS database as a complete GIS project. Authorized users will need to access a password-protected website to download setup programs for either the database or this TSS edition of WallsMap. Without having to log in each time to check if their versions are current, they can open the WallsMap About box and click on the displayed link. This will open a page showing the two release dates and a link to the protected download site.
For a summary of the information stored in the database for each karst feature, see Database Field Descriptions.
TSS_Data Project Layers
The TSS_Data project is a mixture of several useful geographical datasets, including the essential karst shapefiles. Its various components (layers) will appear similar to what's shown below when the Layers/properties window is opened:
This layer arrangement is what might be chosen by someone making corrections and additions to the database. This is done by editing just the five shapefile layers named TSS Caves (caves and entrances), TSS Sinks (sinks and cavities), TSS Shelters, TSS Other, and TSS Springs. (See Karst Feature Categories.) Also provided with the release version are three shapefiles having exactly the same information. The only purpose of TSS Maps and TSS TexBio is the convenience (particularly right after an update) of being able to highlight with distinct symbols either the caves with images or the caves with TexBio fauna lists. The TSS All_Types shapefile contains everything, and is useful both as a backup and as a way to explore a table view of the entire database.
Normally the three redundant layers are set read-only (note the vertical bar prefixes) and their visibilities are turned off (boxes unchecked). That way we can't mistakenly update them or select their records in a text search. Although the records in these layers will become outdated as edits are made to the five essential shapefiles, I don't believe the extra effort required to keep them in agreement is justified, especially since one serves as a backup and all three can have their visibilities turned off as shown above. It's trivially easy for the data manager to create the extra layers with TSS-Export, so it makes sense to include them with each new edition of the project.
Note that the bottom layer shown in this example is a georeferenced raster image (NTI file in this case) that users will have to obtain independently of the project download. That's also true for the DEM/DRG image groups. (See Available Background Imagery.) Regional data managers, for example, will likely have some combination of DOQs (aerial photos), DRGs (topo scans), and DEMs (elevation model NTI files) covering their areas of interest.
With the project set up this way, it's easy to add new records and to edit existing records. To add a shelter, for example, just right-click the map view at the approximate location of the shelter and choose the appropriate shapefile target. The possible targets presented will be point shapefiles that are both visible and editable:
The Selected Points dialog will open and from there you can refine the location and enter the appropriate attribute data. You'll notice that the TYPE, COUNTY, and QUADRANGLE fields will already be filled in and will update automatically as you tweak the location. If the location is within the extent of a loaded elevation model image, the ELEV_FT field will also be initialized. (The image doesn't have to be a visible layer.)
Instructions for Entering Data
While table-style editing of attributes is possible, most record revisions are done via the form in the Selected Points dialog. In fact, all record additions and coordinate edits must be done using this dialog. Since the shapefile format limits field names to ten upper-case characters, the TSS shapefiles have custom templates that provide more information about what a field should contain. To access it let the mouse pointer hover over a field's label, either in the Selected Points window (shown here) or in a table view:
The custom templates also cause the automatic filling of fields COUNTY, TYPE, QUADRANGLE, and ELEV_FT. The initial value for TYPE will depend on the shapefile being edited. Filling of the others will depend on location, with elevations being obtained from an appropriate DEM image layer if one is present.
Removing Records
To remove a record from the database, one does not delete the record in the shapefile being edited. The convention we've adopted for scheduling a removal is to simply edit the label field (NAME in this case), inserting an asterisk (*) as the first character. When the edited shapefile is processed by the database manager, the corresponding record in the master database snapshot will be deleted and its TSS ID permanently retired.