Handbook for Atlasing
North American Breeding Birds
Edited by Charles R. Smith, Published September 1990
Atlasing Handbook contents page
Computer Guidelines:
Recommendations for North American
Breeding Bird Atlas Projects
Daniel W. Brauning, Pennsylvania Atlas Project and
Linda Ann Payzant and L. Peter M. Payzant, Maritimes Atlas Project
Introduction
Most of the NORAC Working Groups were formed to establish recommendations which, if
adopted, would lead to a degree of uniformity among atlas projects. Although uniformity is
not necessarily our goal, the Working Group on Computers suggests thefollowing guidelines
primarily to assist those projects now in the planning stages.
Some of the terms used may be unfamiliar to you if you do nothave a computer
background. We recommend that a person familiar with computers be persuaded to take part
in the planning stages, at least.
General Guidelines
1. Don't underestimate the time and costs of computerization. If possible, model your
system after another atlas project which meets your needs.
2. Identify technical support people with an interest in birds to help implement your
computer system. Include a "computer person" on your advisory board. Ideally,
this person should be available to help for the life of the project.
3. Atlas personnel should have direct control of the computer system. Be wary of offers
of "free. time on a mainframe. Technical assistance may be lacking and your work may
become low priority. For these resaona, we recommend that you budget for and buy a
microcomputer. They are the moat coat effective (you don't need to pay for time or
communications) and you maintain control.
4. If possible, buy and program your computer system before the first field season.
Your software may influence the format of the field card you use.
5. Ensure careful data processing and backup procedures. Your data are extremely
valuable and represent many hours of volunteer time. Your atlas project should be able to
survive almost any kind of computing disaster with little lose of data.
6. Consider providing data security to limit access to sensitive species.
Hardware Configuration
1. The following minimum configuration is recommended:
- a. A microcomputer equivalent in power to at least an IBM/PC-AT.
- b. 640 kilobytes of RAM.
- c. One diskette drive (5 1/4 or 3 1/2 drives are available).
- d. One 40 megabyte hard disk drive.
2. Some means of backup other than the diskette drive should be provided if possible.
Diskettes are slow and may discourage regular backups. Options which should be
investigated include "Bernoulli. drives, streaming tape cassettes, and aerial links
to mainframe computers with large amounts of storage apace available.
3. Many varieties of plotters are available. An inexpensive plotter can be very
valuable in producing interim maps during the data collection phase of your project, and
should be sought after if your budget permits. Another, more versatile, option is to use a
Laser printer with plotting software.
A plotter capable of producing publication quality maps would be uneconomical to
purchase. Final maps should be prepared on a drafting-quality plotter, i.e. one with a
resolution of better than 0.002 in., and using India ink pens with Mylar or polyester
media. This service can usually be obtained from government agencies or commercial
facilities, and should not be too expensive for a "one-shot" occasion.
Software Design Considerations
1. Software development invariably takes more time and effort than anyone ever expects.
If at all possible, copy a working system from another atlas project.
2. If you must design a system from scratch, try to obtain assistance from someone with
system design (as opposed to simply programming) experience.
3. Design data forms to correspond to database structure. Forms should require minimum
hand transcription of data.
4. Keep data handling and fill structures as simple as possible to reduce errors.
5. Store data efficiently. Disk usage will expand beyond your expectations in any case.
An efficient structure will also speed data retrieval.
6. Minimize repetition. Use codes when possible for species and locations. Numeric
codes are fastest to enter; however, alpha codes are less error-prone and result in more
readable files.
7. Structure data for quick access. However, complicated structures which may prove
difficult to maintain should be avoided.
8. Maintain descriptor files for each set of codes, e.g. to translate species codes to
full species names, etc. Each code should be defined at only one place (one file) in the
system. This makes maintenance simpler and prevents ambiguity.
9. Keep the annual data entry process separate from the multiyear database. Annual data
should be entered, proofed and summarized before incorporation into the multiyear
database. This is faster and safer.
10. Each data record should have a comment field at least two characters wide, and more
if possible. These can be used for flagging records requiring documentation, records which
have been cancelled by your approval committee, and so on.
11. Reports should avoid the use of codes where possible, i.e. use full species names,
block names, etc. This is particularly true for reports being sent outside the atlas
organization.
Typical File Contents
The following list of files is suggested as one way to implement an atlas data base:
New Data File: Contains region, block, species, breeding code, abundance code
(optional), and field card number for one year. Other information may be included in this
file such as atlaser number(a), visit dates and hours, and error/documentation flags.
Master File: (same as New Data File plus year field) for combined years data.
Block File: Information on each block such as code, name, county, coordinator,
map coordinates, etc.
Species File: Contains species code, English (or French) names, scientific
names, taxonomic order number, status designations (e.g. does this species need
documentation when reported?)
Documentation File: List of records currently requiring documentation, including
species, breeding code, block, atlaser, and documentation status (outstanding, received,
approved, etc.). Note: this may not be a separate file, but rather just flagged records in
the Master File.
Address List: Including flags for participants, officials, interested parties
(but not active atlasers), etc.
Data Entry Procedure
A well thought out data entry procedure can speed up the entry of the data, catch
certain errors, and save a lot of problems later in the data manipulation. We recommend
the following features:
1. Use a "friendly" data entry screen.
2. Enter coded information to reduce the number of keystrokes. These should be printed
directly on the field card.
3. Include as much error checking as possible at this stage--is the species code legal,
are the species in the same order as on the field card, are the visit dates and block
numbers reasonable, etc.
4. Data should be entered twice by different persons, and the two raw files compared
and differences resolved before the raw file is added to the Year file. This will
eliminate virtually all keying errors.
5. Before the raw data are appended to the yearly data file, the raw data file should
be rigorously checked by a program designed to flush out errors that the data entry
program couldn't catch.
Reports
The following is a fiat of reports that you may have to develop. Ideally, these should
all be ready to go before the end of your first field season. See pp. 72-73 in the
Proceedings of the Northeastern Breeding Bird Atlas Conference (1981) for additional
suggestions.
1. Raw Data Reportlists data as they exist in Yearly data file. Very useful for
checking other reports.
2. Regional Detail Reportsent to Regional Coordinators. Lists all records for
each block in region, sorted by block.
3. Regional Block Summary Reportfor each block in the region, lists the number of
species reported in each breeding category, the number of visits, total atlaser hours, and
atlaser numbers.
4. Regional Species Summary Reportfor each species in a region, lists the number
of breeding reports in each breeding category, highest breeding code, status of
documentation, etc.
5. Documentation Status Reportlists (by region) atatua of each documentation
request: not received yet, received, sent to committee, final disposition (accepted,
accepted with change, rejected).
6. Species Status Reportlists number of reports of each breeding code for each
species for complete a/ate/province.
7. Mapping Reportlists squares and breeding codes for each species. Useful for
producing interim maps.
8. Statistics Reportlists by year and region: number of species possible
probable, confirmed, and total; total atlaser field time, number of blocks
"completed", number of doc forma outstanding, etc. A good tool for the
management committee.
Interim Mapping
Micro-computer mapping is a rapidly developing technology. Currently several software
packages are available that will produce very nice interim maps on a plotter or laser
printer. Interim maps are highly recommended. They provide significant feedback to
volunteers and are an invaluable management tool. The main components include:
1. Mapping software, available commercially or custom written. ATLAS-GRAPHICS mapping
software (STSC, Inc., Rockville, Maryland) has been successfully used by some states.
2. State/Province and county coordinates (available from software manufacturer).
3. Block coordinates, generated by user.
4. Database management system to produce reports of block coordinates for each species.
5. An output device, either laser printer or plotter. Laser printers, using plotting
software, can produce excellent interim maps more quickly than can a plotter.
Two types of maps can be produced: a coverage map showing the number of birds per block
and species distribution maps. When producing maps, select breeding code symbols in
advance and use them consistently for each species.
Conclusion
Although these guidelines will not answer every question you will have in setting up
your computer system, we hope that it will be of some assistance. A wide range of
approaches has been tried. If you are setting up a new system or modifying an existing
one, find a project of similar adze and hardware availability to use as a model. Contact
that project and obtain as much information as possible before designing your system.
Remember, a well designed computer system will greatly facilitate your atlas project.
Atlasing Handbook contents page