Handbook for Atlasing
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.
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.
1. The following minimum configuration is recommended:
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.
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.
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.
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.
The NORAC website is hosted and maintained by Bird Studies Canada