Stovy Bowlin, Shu Liang

Pilot Project Design: The Application of GIS Technology in Groundwater Quality Management

The Barton Springs / Edwards Aquifer Conservation District began GIS operations in July 1994. One of the first orders of business was the development of a comprehensive pilot project to synthesize temporal water quality parameters collected for and reported in the District's Water - Research Study of the Barton Springs Segment of the Edwards Aquifer (September 1994). The project was a complex database management design which helped the District GIS staff to identify and overcome many potential GIS database management problems before moving on to full system integration. Of primary concern was the design of the INFO tables to organize the water quality data and the development of a graphical user interface (GUI) to enable District technical staff to query, graphically display and output the information in an efficient and effective way. With this expanded ability to quantify large amounts of complex temporal site data, District personnel are better able to monitor, analyze, and understand problems affecting groundwater quantity and quality and to evaluate the impact man's activities are having on the Barton Springs segment of the Edwards Aquifer.

	The Barton Springs/Edwards Aquifer Conservation District 
(District) is a Texas groundwater conservation district created through 
Senate Bill 988 of the 70th Texas Legislature with the authority outlined in 
Chapter 52 of the Texas Water Code.  Following a confirmation vote on 
August 8, 1987, the District was created to conserve, protect, and enhance 
the groundwater resources within the Barton Springs segment of the 
Edwards Aquifer (a karst formation), and other groundwater resources 
located within the District's boundaries.  Chapter 52 of the Texas Water 
Code empowers the District with the authority to plan for the most efficient 
use, control, and prevention of the waste of groundwater.
	The Barton Springs segment of the Edwards Aquifer is a major 
groundwater resource.  It provides water to a large and diverse population 
that includes domestic, agricultural, industrial, and commercial users.  A 
portion of the Barton Springs segment includes a number of small cities and 
rural communities that are totally dependent upon groundwater.  In 
recognition, the federal government designated this portion of the Barton 
Springs segment as a Sole Source Aquifer.  Also, Barton Springs discharge 
supplements the City of Austin's drinking water supplies, and is the 
cornerstone of Austin's recreational resources for the city's residents.
	To facilitate the management and planning of these groundwater 
resources, the District took delivery of our GIS (Geographic Information 
System) hardware and software in June 1994, almost a year ago.  This 
system is a stand-alone Sun SPARCstation 20 Model 50 with 64 MB RAM 
and 4 GB total storage running ArcInfo, Network, TIN, COGO, GRID, 
and ArcView2.  The District is in negotiation with computer vendors to 
bring in new IBM graphic workstations and run an inter-office network to 
integrate these new stations.  Currently, the District employees 10 full-time 
staff, has an on-going graduate student internship program, and often 
utilizes the services of volunteers from the general populous.  Each 
employee currently has a small Macintosh at their desk which are not 
networked.  One goal of the new system is to allow non-technical and non-
GIS users the opportunity to run the desktop GIS - ArcView2 - and/or to 
interface with the Sun machine through the GUI developed during this pilot 
project.

	The need to acquire a GIS system was identified by District 
management as the District first began to collect data and identify users.  In 
December 1990, District management contracted a local GIS consulting firm 
to perform a comprehensive Needs Assessment for Development of a 
Geographic Information System.  District Board members, management 
and staff were interviewed to determine and document the GIS needs of the 
District.  A development plan was designed and work on an environmental 
database was initiated based on the responses from these interviews.
	Specific needs for the GIS were identified and include: the need to 
monitor the water quality and the water level of the aquifer; assist in 
education efforts; the identification of pollution sources; and equity in water 
use conservation and funding.  In general the GIS was needed to: provide 
for a greater efficiency in problem-solving; better access to more 
information (e.g., geographic, financial or operational data); remote sensing 
of water quality and quantity trends; to determine water quality impacts; to 
identify aquifer management strategies through data collection and 
interpretation; to more effectively analyze and address natural and artificial 
recharge impacts on aquifer levels and associated water quality results; 
mapping of aquifer boundaries, significant recharge features, and areas 
susceptible to point and non-point sources of pollution; and for the 
development of models, graphics and other management tools for the aquifer.
	Upon taking delivery of the GIS hardware and software in June of 
1994, the District immediately imported the ArcInfo data created by the 
previously mentioned consulting firm.  These data sets included USGS 
single-line DLGs - roads, hydrology, railroads; TIGER data - incorporated 
municipalities; and digitized data - aquifer recharge hydrology zones, 
District boundary, creek watersheds; water supply corporations, and surface 
geology (little in the way of attribute information was associated with these 
original graphic coverages).  Additional GIS data has been collected to 
supplement these data sets.  One point worth mentioning here is the fact that 
there is a concerted effort at the state-level of Texas government to develop 
information system cost and data-sharing alliances.  This effort will help to 
ensure that the accuracy and precision of base data sets are the responsibility 
of the respective custodial agencies.  This will facilitate the exchange of 
information between entities and increase the confidence of the registration 
between coverages.  The District will ultimately be responsible for the 
legislatively mandated District boundary, mapping the the hydrogeology 
within these boundaries, and the permitted District wells.

	Our highest priority since taking delivery of the system has been the 
development of a comprehensive pilot project intended to establish the 
baseline for the on-going operations of the system.  With this expanded 
ability to collect, validate and quantify large quantities of complex temporal 
site data, District personnel will better be able to monitor, analyze, and 
understand problems affecting groundwater quantity and quality.  This, in 
turn, will expand the District's capability to design and test remedial 
alternatives and to communicate this information to diverse audiences.  
Likewise, the information generated by the District's GIS will help end-
users to understand the relationships between various site features and 
management practices and to evaluate the impact man's activities are having 
on the Barton Springs segment of the Edwards Aquifer.
	The District GIS pilot project has been designed to organize the 
water quality parameters collected for and reported in the District's Water-
Research Study of the Barton Springs Segment of the Edwards Aquifer 
(September 1994).  The data synthesis for this report was performed 
manually, as the deadline for the final report ran concurrently with the GIS 
system acquisition and the early development of the pilot study.  Although 
the actual report was finished before the utilization of the GIS, the report 
provided the foundation on which to evaluate the methodology developed 
for the pilot study.  Knowing what was required to finish the report without 
the aid of the GIS helped to determine exactly what would be expected of 
the new system in future research efforts.  Foremost was an understanding 
that, ultimately, the GIS will be able to provide not only the necessary 
graphics, but will be able to process and synthesize the raw data to display, 
manage and organize information for such reports.

	This study used for the GIS pilot examined hydrogeologic and 
water-quality data of the Barton Springs segment of the Edwards Aquifer 
collected by the District from 1990 to 1994.  Ten wells are continuously 
monitored by the District for groundwater levels within the Barton Springs 
segment.  One of these stations is a monitor well near Barton Springs which 
is operated and maintained by the USGS.  Additional wells throughout the 
study area were used to obtain periodic water-level information.  The water-
level changes in the ten monitor wells varied in response to recharge and 
drawdown events.  Several wells have shown rapid responses to some 
recharge events, indicating a good hydraulic connection to areas of recharge 
during certain flow conditions.  Others show a very gradual response to 
recharge events, indicating that they are fed by diffuse flow.
	Thirty-seven wells and springs were sampled in this study.  
Twenty-two wells were sampled during drought conditions in May through 
October, 1990.  Twenty of the same wells were resampled during high 
water-level conditions in March 1993.  Two wells and springs were added 
in March 1993, and 13 different wells and springs were sampled in March 
1994.

	This study by the District, builds on previous investigations into the 
hydrogeology and water-quality of the Barton Springs segment.  The 
District collected water level and water-quality information during the course 
of this study in order to:  1)  characterize the existing water quality and 
hydrogeology within the Barton Springs Segment of the Edwards Aquifer;  
2)  measure variations in the water levels and water quality of the aquifer 
between periods of high and low aquifer conditions;  3) identify, document, 
and monitor impairment of the drinking water quality and recreational use of 
the aquifer due to potential contamination sources such as septic tanks, 
hazardous material storage and disposal, construction activities, urban 
runoff, and agricultural operations; and 4)  attempt to define flow paths and 
hydrogeologically separate systems using water-level responses and water-
quality characteristics.

	Several criteria were used in selecting locations for water-level 
monitor wells.  Monitoring points with a well-documented history were 
generally selected.  Such documentation might include driller well logs, 
geophysical well logs, spring-flow measurements, previous water-quality 
analysis, or water-level measurements.  Some locations were chosen near 
large pumping, recharge, and discharge areas.  The locations of these wells 
are spatially separated to provide representative information across the 
Barton Springs segment.  When possible, some well locations were selected 
near major faults or near suspected flow routes where water-level responses 
are expected to be more dynamic.
	Wells and springs are referred to in this report by a permanent seven 
digit well number assigned by the Texas Water Development Board or by a 
temporary well number assigned by BS/EACD -- this identification number 
also provides the common link between the PAT and the DAT tables in 
ArcInfo.

	Groundwater-quality parameters selected included major and minor 
ions, metals, radioactive isotopes, organics, some common pesticides, 
suspended solids, and indicator bacteria.  Major ions and metals were used 
to characterize the overall water quality of the aquifer, determine leakage 
from adjacent aquifers, to define groundwater flow paths and aquifer 
subsegments, and to identify areas where these parameters exceed drinking 
water standards.  Many of the pesticide types were selected for analysis 
because they had been measured in surface waters over the Barton Springs 
segment of the Edwards Aquifer and listed in the Texas Natural Resource 
Conservation Commission interagency pesticide database.  Total petroleum 
hydrocarbons was selected as a parameter to measure contamination from 
petroleum storage tanks and other hydrocarbon sources.

	In the pilot, ArcInfo attribute tables were linked with the graphics 
file (point coverage) to incorporate the water quality data from the wells and 
springs surveyed for the report and a Graphic User Interface (GUI) has 
been developed to provide a "user friendly" access to the data.  This pilot 
project was quite appropriate to the current stage of development of the 
system.  It was a small enough representation of the wells and springs within 
the District to be able to manage, yet complex enough of a database 
management problem to help the District GIS staff to identify and overcome 
many potential GIS database management problems.  It was designed 
to incorporate a specific data set, have a very narrow focus and to allow for 
periodic evaluation (and corresponding modifications) by District staff who 
will ultimately benefit from the comprehensive nature of the data interface.

	In some ways, however, this project deviates from the historic 
definition of "pilot project".  Many organizations use the pilot study as an 
economically-driven decision-making tool.  The District was committed to 
the implementation of GIS technology prior to the pilot study -- based on 
the practical experience of management and staff, and the understanding of 
the need for data synthesis in routine District activities.  So, in retrospect, 
borrowing a definition from Esri's "Database Design" training notebook, 
what the District may have actually developed is a "prototype":


	"A pilot project is similar to a prototype in terms of objectives.  The 
	primary difference is that a prototype generally involves more 
	iterations between testing, getting user feedback, refining and testing 
	again.  A pilot project is more often a once-through test, which leads 
	to refining the design, and then to full implementation."



In any event, the purpose here is not to debate syntax, rather to identify the 
decision-making criteria the District used in the design of the GIS pilot 
project and the development of the subsequent application software.

	The needs of the District concerning data input, analysis and display 
were considered throughout the design process.  This was a task-oriented 
approach to database design where the application software was customized 
with specific, unique data management problems to address.  Although this 
type of information management can easily be accomplished in theory, 
practical application is considerably more difficult.  Because we are still in a 
data inventory - analysis - verification stage, the final ArcInfo attribute 
tables and the relation between these tables will only be realized through 
practical application and experience.  However, once completed, the 
BS/EACD GIS will serve as a model system for other groundwater or 
special interest water districts pursuing similar technology.

	Water wells in the District are of primary concern.  The District's 
sole source of revenue is generated from the collection of water use fees 
from the permitted wells inside the District boundary.  Although the focus 
of this pilot study is to organize the data for the water quality report, the 
INFO tables design and development has incorporated the nearly 200 
temporal attributes about the wells in the District that are collected 
periodically by the District staff.  Many of these attributes are temporal in 
nature which makes the database design even more complicated.

	The most important question we needed to answer was how to 
organize the data to facilitate more efficient and effective management and 
manipulation of the water quality data.  The first thought we gave to the 
structure of the database was to organize the data in a stereotypical filing 
system - keeping the data of each well in it's own table.  This seemed it 
would allow for uncomplicated tracking of the historical data for every well 
while using the "RELATE" to associate these attribute tables to the wells 
point coverage.  We then experienced the INFO limitation of 100 different 
active relates in the relate environment.

	On the other hand, there is virtually no limitation to the number of 
records within any single table, making it more feasible to have more 
records in less tables.  We found a general consensus among database 
managers that it is generally more efficient to manage fewer tables that 
contain more records, rather than to manage more tables that contain less 
records.  Therefore, we decided to arrange our data categorically rather by 
individual well.  First, we separated the attributes into two general types - 
spatial and temporal.  Spatial attributes are those that will not change with 
time and will require little, if any updating.  Temporal attributes are time-
sensitive and are collected at random intervals.  We then further refined the 
attribute categories according to the characteristics specific to each well.  For 
example, spatial attributes were categorized into location indicators, owner 
information, physical attributes of the wells, and so forth.  The temporally 
spatial attributes were separated into water level data, water quality data, 
annual and monthly pumpage data, etc. (see Appendix 2 for details).  

	Since all the attribute tables in the pilot study concern well 
information, STATE_WELL_# conveniently becomes the attribute node to 
link most of the tables together.  The District database is organized to 
maximize the limited active relates (5) by allowing for the simultaneous 
access of 5 tables with a common attribute link rather than the chained relate 
method which would require a relate for each table in the table chain.  The 
other item used to relate tables is PERMIT_#.  As mentioned before, annual 
and monthly pumpage are critical information for accounting purposes since 
these are the basis for District revenue.

	A brief review of the table descriptions follow:  pilotwell.pat - the 
standard ArcInfo point coverage items with both STATE_WELL_# and 
PERMIT_# (the two links to the other tables); location.dat - fixed spatial 
data; owner.dat - semi-fixed spatial data; admin.dat - fixed spatial data; 
amend_pmg_hist.dat - temporal permitted volume data; well_log.dat - semi-
fixed spatial data; inspect.dat - temporal inspection data; water_level.dat - 
temporal water level data; inlab.dat - temporal in-house water quality testing 
data; outlab.dat - temporal outside lab water quality testing data; and 
annual_pumpage.dat - temporal actual well pumpage.  We have also 
developed several coding schemes for data that we recognized could be 
standardized.  These include: water usage/well types; available well logs; 
well log types; sampling purposes; and lab names.

	ArcInfo is generally a command driven software system.  
Although several packaged tools include a prefabricated GUI developed by 
Esri (such as ArcTools, ArcView), it still requires a GIS literate person 
with some previously developed computer skills to operate ArcInfo.  
Fortunately, AML for ArcInfo and AVENUE for ArcView are there to 
enable the customization of the system to fit special needs.
	To enable District staff to fully utilize ArcInfo without fully 
understanding the command driven interface, we decided to invest the time 
and human resources to develop a GUI to meet the unique needs of the 
District.  Since it would be impractical to design our GUI to rival ArcTools 
or ArcView (which provide many complicated processes to help the end 
user), the primary requirement for our GUI is that it must be simple, easy to 
use rather than complex and comprehensive.  It was designed to not only 
provide the GIS user a quick way to do their work, but also enable the non-
GISer to pick up on it with very little direct supervision.  District staff were 
given individual instruction on the use of the interface and a simple User's 
Manual has been developed to prompt users along when they experiences 
operational difficulties or have simple questions -- of course, District GIS 
staff is available to help resolve any of the more complicated dilemmas (and 
of course there will be some).

	We used common computer syntax as well as task-oriented terms to 
name the items in the menus of the GUI in place of ArcInfo jargon.  For 
examples, we used "Check Information" instead of "Query" for retrieving 
information from the database, and used "Display Maps" instead of "Draw" 
for drawing coverages.  We tried to maintain very low expectations of the 
users to know the functions provided by the buttons on the menus.  In order 
to make the GUI simple, we incorporated virtually all of the routine 
functions the user would be expected to perform, as well as, combining 
several more complicated functions (AML commands) as one item (button) 
on the menu.  We feel the resultant GUI is practical and "user friendly".  
There are "trade-offs", however.  Perhaps the most important is that in this 
interface, the end user looses the flexibility, dynamics, and power which are 
available from ArcInfo's command line because it would not have been 
realistic in our case to include all of ArcInfo's functionality in this GUI.
	Other important functions built into this GUI is the ability to display 
an editcoverage along with any backcoverages simply by making a choice in 
a check box window labeled "Basic Maps".  Users can quickly and easily 
see the maps by checking on a toggle switch in front of each map name.  
We have also automated the process of data entry into the INFO tables.  
Through another window developed in FormEdit, we walk the end user 
through a series of logical, easily understood steps to add items to a table 
and then to populate those items with any relevant record information.  Our 
ultimate goal is one of quality-control -- to ensure the error-free input of 
data, to prompt the user during every step required for the specific GIS 
operation, to notify and keep the user apprised of the status and the progress 
of their work, and finally, to allow any user access to our data (read only) 
through the GUI without any proficiency in ArcInfo. 

District GIS staff exhaustively researched the organization and management of time-sensitive information before the development of the pilot project INFO tables. One thing became readily apparent during this effort -- there are many, diverse database designs being used today to manage temporal information. In fact, the chances are that if you ask a dozen technicians, managers or even vendors, how to organize your data -- you would probably get back a dozen different answers. Each probably special in it's own way, but different nonetheless.

The INFO tables developed for the District GIS pilot project are displayed in Appendix 2 for your review. These are the culmination of months of diligent work. One last thought, database design and data management are complex subjects; however, it is still important to keep your system as simple as possible given the complexity of your database design. As the District has experienced during the development of this pilot project, there is no absolute right or wrong -- only the realization of an adequate solution based on your specific application and unique circumstances.

Good luck in your efforts. The District GIS staff would be happy to share our experiences with any user facing similar database design problems. And remember, for every vision there is an equal and opposite revision.

Appendices

1987
	August 8	Creation Of The BS/EACD

1988
	January		Collection Of Data Began - Realization Of The Need 
				For GIS
	Fall Term	Stovy's First GIS Class On A Super-Fast 286

1990
	December	Development Of GIS Needs Assessment
1991
	August 1	Completion Of Needs Assessment
			Consultant Began Development Of PC ARC/INFO 
				Coverages

1993
	February	Consultant Contract Terminated Due To Extenuating 
				Circumstances

	August		Award Of TWDB GIS Grant
			Development Of District GIS RFP

	October		RFP Let For Bid

	November 30	Bids Closed

	December 3	Proposals Opened

	December 6	Stovy Started Work At The District

1994
	February 4	Esri System Benchtest
	
	February 10	Board Approval To Enter Contract Negotiations With 
				Esri
	
	March		Preparation Of GIS Operating Plan
	
	April 26	Execution Of GIS Contract
	
	May 12		Received Esri GIS Software - No Hardware Yet
	May 22		Esri User Conference 
	June 1		Hardware Arrived
	June 20		1st Esri Training Class - Introduction to 
				ArcInfo
	July		Began GIS Operations - Existing Data Verification
	August 22	2nd Esri Training Class - Database Design
	August 31	Submit Final TWDB GIS Grant Report
	September	Began Pilot Project
	December	Texas GIS Forum
	December 5	3rd Esri Training Class - Customizing with AML

1995
	January		Began District Staff Evaluation of Pilot Project 
			Solicitation of New Inter-Office Computer System
	February	Data Verification - Cross-Referencing Info Tables 
				with Hardcopy Data
	March		Production of GIS Graphics from Pilot Project
	April		Final Revisions to Pilot Project Info Tables / GUI
	May		Esri Users Conference

Item Name:	Input	Output	Data	Decimal

Presentation	Width:	Width:	Type:	Place:


1. Feature Attributes Table for pilotwell.pat 

AREA		8	18	F	5

PERIMETER	8	18	F	5

PILOTWELL#	4	5	B	

PILOTWELL-ID	4	5	B	

STATE_WELL_#	11	11	C		NN-NN-NXXXX

PERMIT_#	10	10	C		NN-NNN-NN



2. Location Attributes for location.dat

STATE_WELL_#	11	11	C		NN-NN-NXXXX

WELL_LOCATION	4	4	C		XN (50' grid ID)

LATITUDE	7	7	B		NNNNNNN

LONGITUDE	7	7	B		NNNNNNN

ELEVATION	7	7	N	2	NNNN.NN

COUNTY		10	10	C		COUNTY NAME

AQUIFER		20	20	C		AQUIFER NAME

ZONE		15	15	C		ZONE NAME

PERMIT_#	10	10	C		NN-NNN-NN



3. Owner Information for owner.dat

STATE_WELL_#	11	11	C		NN-NN-NXXXX

OWNER		40	30	C		Last, First MI or Co Name

PHONE		14	14	C		(NNN)NNN-NNNN

MAILING		90	90	C		Mailing Address

STREET_#	4	7	B		NNNNN

STREET_NAME 	30 	30	C		STREET NAME

SUITE_#		5	5	C		NNNNN

CITY		10	10 	C		CITY

STATE		2	2	C		TX

ZIP CODE	10	10	C		NNNNN-NNNN

PREVIOUS_OWNER	40	30	C		Last, First MI or Co Name



4. Administration Attributes for admin.dat

PERMIT_#	10	10	C		YY-NNN-NN

CONTACT_NAME	40	30	C		LAST, FIRST MI

ONTACT_PHONE	14	14	C		(NNN)NNN-NNNN

EMERG_PHONE	14	14	C		(NNN)NNN-NNNN

PERMIT_PUMPAG	4	9	B		NNNNNNNNN

ANNUAL_PUMPAG	4	9	B		NNNNNNNNN

PERMIT_DATE	8	8	D		YYYYMMDD

#_WELLS		2	2	B		NN



5. Amended Pumpage for amend_pmg_hist.dat (temporal sequence)

PERMIT_#	10	10	C		YY-NNN-NN

AMND_DATE	8	8	D		YY-NNN-NN

AMND_PUMPAGE	4	10	B		NNNNNNNNN



6. Physical Attributes 1 for well_log.dat

STATE_WELL_#	11	11	C		NN-NN-NXXXX

DATE_DRILLED	8	8	D		YYYYMMDD

DRILLER		40	40	C		L, FIRST MI, CO NAME

WELL_DEPTH	7	7	N	2	NNNN.NN (FEET)

UPPER_BORE_DIA	7	7	N	3	NN.N (INCHES)

LOWER_BORE_DI	7	7	N	3	NN.N (INCHES)

UPPER_CASING_D	7	7	N	3	NN.NN (INCHES)

LOWE_CASING_D	7	7	N	3	NN.NN (INCHES)

CASING_HEIGHT	7	7	N	3	N.NN (FEET)

CASING_DEPTH	6	6	N	1	NNN.N (FEET)

PUMP_SETTING	6	6	N	1	NNN.N (FEET)

PUMP_RATE	2	5	B		NNNN (GPM)

OP_PRESSURE	2	5	B		NNN	(PSI)

E-LINE_ACCESS	1	1	C		Y, N

SAMPLING_SPIGO	1	1	C		Y, N

AIRLINE		1	1	C		Y, N

AVAILABLE_LOG	20	20	C		AVAILABLE WELL 						LOGS

PHOTOS		1	1	C		Y, N



7. Physical Attributes 2 for inspect.dat (temporal sequence)

STATE_WELL_#	11	11	C		NN-NN-NXXXX

CLASSIFICATION	20	20	C		SEE: III. CLASSIFICATION

INSPECT_DATE	8	8	D		YYYYMMDD

INSPECTOR	4	3 	C		XXX 	(F,MID,L INITIALS)
WATER_LEVEL	6	6	N	2	NNN.NN (ABOVE MSL)

METER_READING	4	10	B		NNNNNNNNN

SERIAL_#	10	9	C		XXXXXXXXXX



8. Water Level Attributes for water_level.dat (temporal sequence)

STATE_WELL_#	11	11	C		NN-NN-NNN

DATE		8	8	D		YYYYMMDD

WATER_LEVEL	6	6	N	2	NNN.NN (ABOVE MSL)

WATER_DEPTH	7	7	N	2	NNN.NN (FROM TOC)



9. Water Quality Attributes 1 for inlab.dat (temporal sequence)

STATE_WELL_#	11	11	C		NN-NN-NXXXX

SAMPLE_DATE	8	8	D		YYYYMMDD

SAMPLE_TIME	5	5	C		NNNN (MILITARY TIME)

SAMPLED_BY	3	3	C		XXX 	(F,MID,L INITIALS)

SAMPLE_PURPOSE	12	12	C		XXX (SEE: SAMPLE PURPOSE)

TEST_DATE	8	8	D		YYYYMMDD

TESTED_BY	3	3	C		XXX 	(F,MID,L INITIALS)

ALKALINITY	2	3	B		NNN (MG/L)

CHLORIDE	7	7	N	2	NNN.NN (MG/L)

CONDUCTIVITY	2	5	B		NNNNN (MICROSEM/CM)

FECAL_COLIFORM	1	1	C		+, -

FLUORIDE	5	5	N	2	NN.NN (MG/L)

IRON		6	6	N	3	NN.NNN (MG/L)

NITRATE		5	5	N	1	NNN.N  (MG/L)

PH		5	5	N 	2	N.NN

SULFATE		7	7	N	2	NNNN.NN (MG/L)

TOTAL_COLIFORM	1	1	C		+, -

TEMPERATURE	4	4	N	1	NN.N (¡C)

TURBIDITY	2	4	B		NNNN (NTU)



10. Water Quality Attribute 2 for outlab.dat (temporal sequence)

STATE_WELL_#	11	11	C		NN-NN-NXXXX

LAB		6	5	C		XXX (SEE: LAB NAMES)

SAMPLE_DATE	8	8	D		YYYYMMDD

SAMPLED_BY	3	3	C		XXX (F,MID,L INITIALS)

SAMPLE_PURPOS	12	12	C		XXX (SEE: PUR)

AMMONIA_N	7	7	N	2	N.NN (MG/L)

CHLORIDE	6	6	N	1	NNN.N (MG/L)

DIS_CALCIUM	6	6	N	2	NNN.NN (MG/L)

DIS_MAGNESIUM 	6	6	N	1	NN.N (MG/L)

DIS_POTASSIUM	6	6	N	2	NN.NN (MG/L)

DIS_SELENIUM	7	7	N	3	N.NNN (MG/L)

ETHYLBENZENE	6	6	N	2	NNN.NN (MG/L) 

FECAL_COLIFORM	4	6	B		NNNNNN (COL/100ML)

FECAL_STREP	4	6	B		NNNNNN (COL/100ML)

FLUORIDE	6	6	N	2	NN.NN (MG/L)

GROSS_ALPHA	7	7	N	2	N.NN (PCI/L)

KJELDAHL_N	7	7	N	2	N.NN (MG/L)

NITRATE_N	6	6	N	2	NN.NN (MG/L)

NITRITE_N	7	7	N	3	N.NNN (MG/L)

OIL_GREASE 	6	6	N	2	NNN.NN (MG/L) 

ORTHO_PHOS	7	7	N	2	N.NN (MG/L)
SILICA		6	6	N	1	NN.N (MG/L)

SULFATE		6	6	N 	1	N.N (MG/L)

SUSPENDED_SOL	6	6	N	1	NN.N (MG/L)

TOLUENE		6	6	N	2	NNN.NN (MG/L) 

TOTAL_ALUMIN	8	8	N 	4	N.NNNN (MG/L)

TOTAL_ARSENIC	9	9	N	5	N.NNNNN  (MG/L)

TOTAL_BARIUM	7	7	N	2	N.NN (MG/L)

TOTAL_CADMIUM	6	6	N	1	NNNN.N (MG/L)

TOTAL_CHROM	7	7	N	3	N.NNN (MG/L)

TOTAL_COLIFORM	4	6	B		NNNNNN (COL/100ML)

TOTAL_COPPER	7	7	N	3	N.NNN (MG/L)

TOTAL_DIS_SL_C	7	7	N	2	NNN.NN (MG/L)

TOTAL_DIS_SL_RE	7	7	N	2	NNN.NN (MG/L)

TOTAL_HARDNES	6	6	N	1	NNN.N  (MG/L)

TOTAL_IRON	7	7	N	2	N.NN (MG/L)

TOTAL_LEAD	8	8	N	4	N.NNNN (MG/L)

TOTAL_MANGA	7	7	N	2	N.NN (MG/L)

TOTAL_MERCURY	8	8	N	4	N.NNNN (MG/L)

TOTAL_ORGANI_C	6	6	N	2	NN.NN (MG/L)

TOTAL_PETRO_HC	6	6	N	2	NNN.NN (MG/L) 

TOTAL_PHOSPHA	7	7	N	3	N.NNN (MG/L)

TOTAL_SILVER	7	7	N	3	N.NNN (MG/L)

TOTAL_SODIUM	6	6	N	2	NNN.NN (MG/L)

TOTAL_STRONTIU	6	6	N	2	NN.NN (MG/L)

TOTAL_ZINC	7	7	N	3	N.NNN (MG/L)

XYLENE		6	6	N	2	NNN.NN (MG/L) 



11.  Actual Annual Pumpage annual_pumpage.dat (temporal sequence)

PERMIT_#	11	11	C		NN-NN-NXXXX

YEAR		4	4	C		NNNN

ANNUAL		4	11	B		NNNNNNNNNNN

JANUARY		4	9	B		NNNNNNNNNN

FEBRUARY	4	9	B		NNNNNNNNNN

MARCH		4	9	B		NNNNNNNNNN

APRIL		4	9	B		NNNNNNNNNN

MAY		4	9	B		NNNNNNNNNN

JUNE		4	9	B		NNNNNNNNNN

JULY		4	9	B		NNNNNNNNNN

AUGUST		4	9	B		NNNNNNNNNN

SEPTEMBER	4	9	B		NNNNNNNNNN

OCTOBER		4	9	B		NNNNNNNNNN

NOVEMEBER	4	9	B		NNNNNNNNNN

DECEMBER	4	9	B		NNNNNNNNNN


NOTE: 

.PAT, for Point Attribute Table, is an attribute table for the point feature 
coverage, 	such as pilotwell.pat. 
.DAT, for Data Attribute Table, is a regular data table which will be linked 
to the 	.PAT.
DATA TYPE:  C --  Character	D --  Date	B --  Binary	N --  #

Table 1:  Water Usage/Well Types


ABD	ABanDoned well
AGR	AGRicultural water supply
CAV	CAVe
CLP	Closed LooP

COM	COMmercial water supply

CDM	Commercial DoMestic water supply

DOM	DOMestic water supply

EXE	EXEmpt well

IND	INDustrial water supply

IRR	IRRigation water supply

PLG	PLuGged well

PWS	Public Water Supply

SPG	SPRing

UNU	UNUsed well

CMW	Commercial Monitor Well

DMW	District Monitor Well

UMW	USGS Monitor Well



Table 2:  Available Well Logs


Geophysical Logs


GR	Natural Gamma/Gamma Ray

GG	Gamma/Gamma

NU	Neutron Log

RS	Resistivity

SP	Spontaneous Potential

SV	Sonic Velocity

TP	Temperature

CA	Caliper
		

Other Logs


DL	Drillers Log

TV	Downhole Camera

DG	Depth Gauged

PL	Plug Log

MS	Measured Section

CO	Core/Geotechnical Boring

                                                                    
Table 3:  Sampling Purposes


WB	TWDB Grant Samples

WQ	Water Quality Assessment

WI	Well Inspection

GL	Geophysical Logging

BS	Biological Sampling

WL	Water Level Measurement

DT	Dye Trace



Table 4:  Lab Names


LCR	LCRA - Lower Colorado River Authority

EAR	EARDC - Edwards Aquifer Research and Data Center

AMT	AMT - Applied Microbial Technology

NET	NET - National Environmental Testing