INQUA-COMMISSION FOR THE STUDY OF THE HOLOCENE (ILLUSTRATION NOT INCLUDED) Working Group on Data-Handling Methods Newsletter 11, January 1994 NOTE FROM THE COORDINATOR In the Newsletter this time Joel Guiot provides some thoughtful recommendations for those using biological proxy data. Keith Bennett announces psimpoll version 2.23 that now runs on any machine for which an ANSI C compiler is available. He has put DOS and Mac versions in the INQUA Boutique. Even if you are happy with your present system for drafting pollen diagrams, you owe it to yourself to look at the feature-filled 70-page psimpoll manual to get an inkling of the thorough work he has done. Glen MacDonald continues his frolic through the CDROM world, and he offers advice about the CDROM drive that you should have ordered. Jock McAndrews and Zicheng Yu introduce their fascinating world of RACKs (Random Access Computer Keys) and I discuss how to edit them. Adam Walanus provides a humorous philosophy on using computers as pollen counters. Dana Naldrett tells how to do library searches on the Internet, describing and ranking the assets of 20 colleges in Canada and the U.S. John Birks supplies another of his useful book columns. David Green keeps us up to date with the World Wide Web. I asked Paula Reimer to provide some common questions she gets about CALIB3, the 14C calibration program from the University of Washington. I discuss the Global Positioning System and tell how you can always find where your research sites are even in trackless wastes. And a number of other topics are wedged in where they fit. My sabbatical year continues. My thanks go to colleagues in Europe, Canada, Australia, and New Zealand who made me feel welcome while teaching me about computers and geology. I will be visiting John Birks in Bergen during April and Raymonde Bonnefille in Marseille during May. I ask the readers of the Newsletter to send me information on any of the data-handling techniques that you have used which could be helpful to others. Please check your regular and e-mail addresses for accuracy. Send any corrections/suggestions to: Louis J. Maher, Jr. Department of Geology & Geophysics University of Wisconsin 1215 W. Dayton Street Madison, WI 53706 USA Phone: (608) 262-9595 FAX: (608) 262-0693 E-mail: maher@geology.wisc.edu THE QUANTITATIVE PALEOENVIRONMENTAL RECONSTRUCTIONS USING BIOLOGICAL PROXY DATA: RECOMMENDATIONS J. GUIOT Laboratoire de Botanique Historique and Palynologie Facult‚ des Sciences et Techniques de St-Jer“me Boite 451 13397 Marseille cedex 13 France E-mail: j.guiot@frmop11.cnusc.fr Fauna and flora now respond and have responded in the past to a more or less complex combination of environmental changes. A good knowledge of their modern ecology coupled to adequate mathematical methods permits a quantitative approach for reconstructing these changes from biological proxy data. Such reconstruction methods are often called "transfer functions", but this name must be used only figuratively because they are no longer based on the calibration of a function. These transfer functions may convert two types of proxies into environmental information: either assemblages (i.e. the relative abundance of a great number of species or more simply their presence/absence), or parameters related to the growth of selected individuals of a given species (e.g. tree-ring width, density, isotopic content ...). That type of approach needs a reference dataset containing the same type of proxies as in the fossil data associated with the environmental variables assumed to be the most explicative. I would like to review briefly--as much for the data provider as for the data user (e.g. climate modeller)--problems met in quantification, and to suggest possible solutions. Problems 1. Such a quantitative approach implies that their response has not significantly changed in the past, which limits the time span of such approach. Moreover the use of proxy data requires the existence of modern analogues for these proxies. In some extreme climates, or during rapid transition, there may be no modern analogues. [*p.1 / p.2*] 2. When the reference dataset is too limited, misinterpretations of the relationships between the environment versus the proxy are possible, e.g. an absence of both dry and cold samples in the reference dataset will lead to the systematic reconstruction of dry and warm conditions for glacial periods. More generally, if two climatic parameters are too strongly correlated in the reference dataset, the same correlation will be obtained in the reconstructions. 3. The reference dataset has often been built from various sources by different authors and is heterogeneous. This is the price that must be paid for a sufficiently diversified modern dataset. This heterogeneity can come from the chemical preparation of the samples, from the taxonomic identification (some are not recognized, some are misinterpreted), from the number of individuals counted... 4. In long-settled regions, the distribution of some proxy data has been modified by humans. This can be reflected in a modification of the assemblages or/and a modification of the growth of the individuals. Consequently, the statistical relationship between proxies and environment is disturbed, resulting in spurious recon- structions. 5. Biological data are often influenced by a complex combination of numerous biotic and abiotic variables, making the deconvolution of the different signals of interest extremely difficult. Taking climatic factors as an example, the presence of a species or the efficient growth of individuals will depend on the combined effects of temperature, water availability, and sunlight in a quantitative way; but it may also depend on the occurrence of extremes (frost, drought...). 6. Some species are ubiquitous or have a large environmental tolerance. Frequently, the species is not differentiated by the analyst, so that a taxon covers several species with very different ecological behaviour. All that restricts the potential of the reconstructions. Nevertheless the assemblage itself sometimes permits an indirect access to the species. 7. The low-resolution reconstructions are based on environmental "normals" calculated, for example, on a 30-year period. The variability around these normals is sometimes high, and this illustrates the ability of the biological organisms studied to adapt to a more or less large range. This variability is certainly a lower limit to the error bar associated with these reconstructions.. 8. All the proxies have a more or less high inertia. They usually integrate the environmental conditions of the past. This shows up as statistical autocorrelation in the proxy time-series. Sometimes, that inertia is too great to permit adequate reconstruction during phases of rapid transition. 9. As in all paleodata study, the time scale is crucial. Dating techniques are now rapidly evolving. Results which were presented in a particular time scale (sometimes with no precise indications on the age model used) may be nearly worthless when the time scale itself is revised. Qualitative methods may solve some of these problems, because they are more intuitive and are not constrained to use a predefined shape for the proxy-environment relationship. Such methods can qualitatively manage the problems of thresholds. The counterpart is that non- constrained intuition may not always set reasonable limits and often do not convince the user of the results (e.g. the climate modeller). Quantitative information, even if associated with a large error bar, is much more useful because the large error bar reflects the limits of what can be extracted from the data. In fact, the same limits also affect qualitative results, but they are often hidden for a period of time. Some solutions The recent developments of quantitative techniques enable us to pass beyond the former limits: by combining several signals (in particular by integrating quantitative and qualitative information) and by using more flexible mathematical methods. The regional and global databases which are now emerging are another tool for solving a part of those problems. Problems 1 and 2 are linked to the diversity of the modern dataset. They can be solved by gathering all the modern samples available and then by collaboration between scientists. There still remains the problem of heterogeneity of the dataset (problem 3) which can be solved by carefully checking the data. Some authors prefer to use only their own data or data only analysed using the same protocol. But the consequence can be the loss of diversity. Statistical methods exist to smooth the samples according to the environmental variables to be reconstructed (e.g. response surface [*p.2 / p.3*] method). Perhaps another solution to the heterogeneity problem is that the effort of creating databases results in better collaboration between scientists, which in turn provides the opportunity for technical and taxonomical discussion. Some mathematical methods are more affected by the biases present in the modern data set. These are regression-type methods or extrapolative methods. Coefficients are calibrated on the modern data, and they can be strongly influenced by biases. These kinds of methods generally are practicable for extrapolation back to recent time (the last millennia) and particularly for tree-ring data. When they are applied to older fossil data, possibly in no-analogue situations, the predictions can be completely unrealistic. We prefer interpolative methods, based on the research of analogues (others are neural networks...), which are unable to provide non-existing environmental estimates but in consequence can provide underestimated predictions. The extrapolative methods, amplifying the defects of the reference data, will often be unable to deconvolve signals too strongly correlated (problem 3), while the interpolative ones are able to take profit of the few samples inconsistent with the general trend. The surface samples strongly disturbed by humans (problem 4) are easily recognized and discarded. When this disturbance is weaker, a statistical analysis can be used to smooth out the human action from the modern samples. All calibration on modern data can be then biased by this disturbance: a way to avoid that is to use an inverse step: environmental information present is extracted from the paleodata and interpreted by comparison to the modern data. A major point in all reconstruction ventures is to give a clear idea of the errors associated with the results. For high-resolution data, such as tree-rings, it is often possible to keep a test-sample for independent verification. Jackknife or bootstrap methods are appropriate tools to evaluate the error bars. More recent methods based on "Fuzzy logic" techniques take profit of the uncertainty associated with the data. Nevertheless, this verification is not sufficient for low-resolution data where analogues are frequently taken in distant geographical regions. In this case the environmental history cannot be taken into account. Only a large amount of diversified reconstruction using several types of proxies will definitely validate the results. Therefore, we do need large databases and particularly multi-proxy databases. In the last decades, proxy data have been converted into conventional climatic variables such as temperature or precipitation, to facilitate the comparison with output from models. Now ecological models are available, either at a global scale or even a regional or local scale, to use this output and produce more biological entities. They are the result of a complex combination of environmental variables, and they can be more directly compared to the proxy data. This fairly natural "forward approach" solves the problems of signal deconvolution (problem 5). Examples are comparison of pollen data with the biomes issued from the biome model of Prentice, comparison of the well-dated pollen diagram with the predicted vegetation succession (as predicted by a gap model of Shugart-type), or comparison of tree-ring data with tree-growth predicted by a cambial model (of Vaganov-Fritts type). A great effort must now be done on the most appropriate way to produce proxy data compatible with the biological models output, e.g. to convert pollen data into biomes. The recent use of the forward approach is not a brutal rejection of the former "inverse approach". On the contrary, we have new tools to enhance the environmental signal present in the proxy data. The key to the method is the constraint using a qualitative or quantitative independent variable. The advantage of proxies like pollen, tree-rings or foraminifera is that widespread measurements are available, but it is sometimes difficult to isolate the desired environmental signal. The constraint is, in fact, a decoder. The method is as follows: given a fossil assemblage, all the modern analogues of the fossil assemblage are determined at a certain degree of similarity, but finally only those satisfying a particular condition are kept. The condition can be established by an indicator coming from the same proxy dataset (e.g. rare taxa) or from other proxies (multiproxy approach). Examples are the following: (1) Often modern pollen analogues for glacial periods come from tundra, cool or even warm steppes; if some rare taxon proves the incompatibility of steppes, only tundra analogues are kept. (2) Absolute frequencies showing a low pollen productivity; only analogues with extreme climate can be taken. (3) Modern analogues come from a large variety of loca- tions; we may restrict the choice to those having a close value of a given geochemical parameter (carbon content, delta 18-O...). (4) Lake-level data can be used to select modern pollen analogues indicating precipitation values compatible with those of close lakes. (5) In periods of rapid climatic transition, biological organisms with a rapid response (insects) are useful to correct results [*p.3 / p.4*] coming from slower organisms (vegetation). (6) Discontinuous historical documents can be also used to add precision to the climatic signal driving tree-rings. The rapid evolution of dating systems impose some caution. All the environmental reconstruction techniques based on time-series do not need any precise time scale. It is then possible to obtain the reconstructions as a function of the depth. The conventional 14C time-scale can be associated at the end of the process, permitting a later calibration based on the last improvement of the age scale. The problem is different for time-slice reconstructions, for which it is necessary to adopt a 14C age model but also use the stratigraphical correlation of close sites. However there is the danger of incorporating errors based on reckless hypotheses of synchronism of some minor events over large geographical regions. Conclusions In conclusion, the development of regional and global databases must be based on original data from the authors and must cover all the proxy data useful for our knowledge of past climatic changes. The authors of global paleoclimatic syntheses have to be as transparent as possible concerning the data used, the methods and the errors bars, so that the data user will be able to judge the quality of the recon- structions that he wants to use. In particular, he should have access to the main characteristics of the reference dataset, the chrono- stratigraphy, the age model, the reconstruction method, and the estimation of the error. If the method is based on analogues, he must know what dissimilarity measure of distance was used and the minimum distance for the closest analogue of each fossil sample. If a regression-type method was used, he must know the correlation between observations and estimates both on the calibration data and on the independent verification data. Multi-proxy reconstructions are able to provide solutions to most of the quoted problems. In particular qualitative indicators are useful to improve the precision of some ambiguous reconstructions obtained automatically from large datasets. The multi-proxy approach also is certainly necessary for solving the problem of human action and data inertia. The databases must also be used in a forward way for comparison with biological objects produced by ecological models coupled to climatic models. As an example, we have to develop tools to deduce biomes from pollen. 'psimpoll' VERSION 2.23: A C PROGRAM FOR ANALYSING POLLEN DATA AND PLOTTING POLLEN DIAGRAMS K.D. Bennett Department of Plant Sciences University of Cambridge Downing Street Cambridge CB2 3EA United Kingdom E-mail: kdb2@cus.cam.ac.uk This note describes the new features added to 'psimpoll' since my note discussing the original version (Bennett, 1992). The aims of the program are to: þ produce pollen diagrams of publishable quality; þ enable the transmission of pollen diagrams on electronic media (diskettes, e-mail); þ facilitate the use of numerical, multivariate analyses of pollen data by linking such analyses to the production of diagrammatic output as a matter of routine; þ be highly portable, independent of any particular hardware. The main features of the program remain as before. Significant extensions are outlined below. 1. 'psimpoll' is now written in C, conforming with the ANSI standard in every respect (as far as I can tell). This has certain disadvantages, notably with regard to screen handling, and one major advantage: it can be ported to any computer that has an ANSI C compiler. I have compiled and run the program as is under DOS, UNIX and Macintosh systems. This enables me to run it with the same dataset on different systems depending on the task in hand. For me, normal use is on DOS, but I use UNIX for analyses that are expensive in CPU time (such as time-series). 2. Age-depth modelling has been added, using linear interpolation, weighted curve fitting (by least-squares and singular value decomposition), spline fitting, and Bezier curve fitting. Calculated ages can be used to obtain accumulation rates from concentration data. 3. Confidence intervals are now available for pollen percentages (following Maher, 1972), and pollen concentrations (following Maher, 1981). Additionally, [*p.4 / p.5*] confidence intervals are assessed for age and accumulation rate estimates by simulation. The latter are combined with pollen concentration confidence intervals by error propagation techniques to obtain confidence intervals for pollen accumulation rates. The simulation process involves treating each radiocarbon age that actually was obtained as one estimate of the age from a population with the same mean and standard deviation as the measured one, and then repeatedly drawing "ages" from this distribution. The principle is that any of these randomly drawn "ages" is just as likely to have occurred as the ages that really were obtained. The random "ages" are then used to refit the age-depth model, and obtain confidence intervals for age estimates and sediment accumulation rates. The method works for any age-depth model, and produces results that are similar to exact calculation of confidence intervals in the relatively simple situations where this is possible. The procedure is discussed in more detail by Bennett (1994). 4. Zonation is now included, using least-squares and information content criteria for binary and optimal splitting, and also a version of CONISS (Grimm, 1986). A broken-stick model is used to help identify the maximum number of zones that should be recognised. 5. Other available analyses include rates of change (using any of eight dissimilarity coefficients), rarefaction analysis (Birks and Line, 1992), Fourier analysis by way of the Lomb periodogram for unevenly sampled data (see Press et al., 1992), principal components analysis (which also uses a broken-stick model to identify the usable principal axes: see Jackson, 1993), some basic statistical description of the data, and independent splitting, using the method of Walker and Wilson (1978). 6. Text on the diagrams can include any character from European languages based on Roman script, plus the Greek alphabet. 7. The 'psimpoll' PostScript output file consists of a series of pieces, which I term "boxes", of PostScript code. These "boxes" can be unpicked from the output file and combined with "boxes" from other output files to produce a new output file. This enables the selection and combination of parts of diagrams (scales and zonation schemes, as well as plotted curves), and is achieved through an ancillary program called 'pscomb' (pronunciation should rhyme with "tome", but "scum" will do). 8. There is a detailed manual (about 70 pages) that describes the working of the program and the principles underlying the various approaches and techniques. My comments in the earlier note (Bennett, 1992) on my rationale for writing a program myself rather than using someone else's remain unchanged. It should be noted that the screen-handling is crude (the price of portability). The DOS- and the Macintosh-executable versions of 'psimpoll' are available, free and gratis, from Lou's pollen boutique by ftp. For other computers, you would need the source files (which I can send) and your own ANSI C compiler. References. Bennett, K.D. 1994. Confidence intervals for age estimates and deposition times in late Quaternary sediment sequences. The Holocene, in press. Birks, H.J.B. and Line, J.M. 1992. The use of rarefaction analysis for estimating palynological richness from Quaternary pollen-analytical data. The Holocene 2, 1-10. Grimm, E.C. 1986. CONISS: a FORTRAN 77 program for stratigraphically constrained cluster analysis by the method of incremental sum of squares. Computers & Geosciences 13, 13-35. Jackson, D.A. 1993. Stopping rules in principal components analysis: a comparison of heuristical and statistical approaches. Ecology 74, 2204-2214. Maher, L.J., Jr 1972. Nomograms for computing 0.95 confidence limits of pollen data. Review of Palaeobotany and Palynology 13, 85-93. Maher, L.J., Jr 1981. Statistics for microfossil concentration measurements employing samples spiked with marker grains. Review of Palaeobotany and Palynology 32, 153-191. Press, W.H., Teukolsky, S.A., Vetterling, W.T. and Flannery, B.P. 1992. Numerical recipes in C: the art of scientific computing. 2nd ed. CUP, Cambridge. [*p.5 / p.6*] Walker, D. and Wilson, S.R. 1978. A statistical alternative to the zoning of pollen diagrams. Journal of Biogeography 5, 1-21. OPTIMIZING TAXON CODES IN POLLEN COUNTING Adam Walanus, Institute of Physics, Silesian Technical University, Krzywoustego 2, PL-44-100 Gliwice, POLAND E-mail: polslask@plwrtu11.bitnet There seems to be a rule that whenever a computer keyboard gets too close to the microscope a new program for counting pollen arises. However, many programs "emulate" mechanical counters only, whereas even the oldest XT can do much more (Davis, 1993). In my POLPAL (Walanus, 1991) a kind of optimization of the taxa codes is applied. In the process of counting, two things should be minimized: the number of keystrokes and the amount of human memory occupied by the codes. That is possible under the obvious assumption that some taxa are frequent, some are rare and the rest are very rare. Up to the ten most frequent taxa are coded by the function keys ... The next group (in principle up to 26 x 26 = 676 taxa) is coded by the sequence of two letter keys. The remaining "very rare" taxa are coded by the three-letter codes, which are four keystrokes in fact, because the space bar must be pressed before the letters. How many taxa should be coded with one-, two- or three-keys codes is a matter of which kind of effort is preferred: to search for the key on the keyboard or to remember codes. It must be mentioned that a codes dictionary is available in POLPAL any time by pressing and the first letter of the taxon's name. However, searching for the code on the screen is the most time-consuming task during counting. It is really a personal decision whether it is worth to remember: = Alnus, and use one keystroke per Alnus grain, or to use: = Alnus, easy to remember but with the 100% additional wear to the finger. Only the most frequent taxa should be coded by keys. The less frequent taxa are coded by the two-letter codes. However, like the 's, not all possible pairs of letters must be used. There is no reason to code Corylus avellana by, say, because , and comparable options are already occupied. Certainly, the three-letter is a pretty combination for remembrance. The rareness of a taxon can be estimated automatically. Having to use the dictionary frequently to look up a taxon's code will soon fix the combination in your long-term memory! Reference. Davis, O.K. 1993. Program sources. INQUA - Commission for the Study of the Holocene, Working Group on Data-Handling Methods Newsletter 10:30-33. Ralska-Jasiewiczowa, M. and Walanus, A. 1991. Polish palynolgical database (POLPAL) in course of building. INQUA - Commission for the Study of the Holocene, Working Group on Data-Handling Methods Newsletter 5:1-2. A PROGRAM FOR COUNTING THINGS ON 16 FINGERS Louis J. Maher I was delighted to receive the above contribution from Adam Walanus because I had just been thinking about his POLPAL article (Ralska- Jasiewiczowa and Walanus, 1991) when it arrived. (I remind the readers that POLPAL is available in the INQUA Boutique bundled in a self-extracting file called "POLISH.EXE.") In his earlier article Adam also spoke of efficiency in saving data. Now I agree with everything Adam says, but we all tend to be creatures of habit. I previously mentioned my old pollen counter for a Commodore PET which I adapted for the PC (Maher, 1992). It used the numbers from 00 to 99 to stand for pollen taxa. It generally took just two key strokes because it expected two; therefore you did not need to touch the key. I used the keys to signal I wanted to check the counts and to load and save files. I avoided one- and three-key combinations because I did not want to find--in the middle of a three-key run--that I really was after a single-key combination. You can throw your back out just getting rid of the momentum! [*p.6 / p.7*] To get back to the subject, Adam in his first article mentioned being able to average less than half a byte to store one pollen count. That statement had remained in the back of my mind for two years. It finally occurred to me that in one 8-bit byte one can store all the integer numbers from 0 to 255--256 in all. Further, computer engineers often find it convenient to use the hexadecimal number system when dealing with bits rather than the decimal system. The hexadecimal numbers use the regular digits from 0 to 9, substituting A through F for the decimal values 10 through 15. The next hex number after F is 10 (that is, 1 sixteen and 0 ones). Now if you continue counting in hexadecimal until you reach FF (that is, 15 sixteens and 15 ones = 255 decimal)--counting 00, you can express any of 256 things with no more than two digits. In the old POLCOUNT program, which uses decimal numbers, one could store 100 taxa. In a new version of POLCOUNT, one can store 256 taxa. It is now in the INQUA Boutique in a self-extracting file called POLCNTFF.EXE (Think of it as POLlenCouNTer-FF). You might want to get it to experiment with; if nothing else you can practice two-digit hex numbers. It also comes with several other utility files like those that came with the original POLCOUNT. One most admit that a typewriter keyboard is not all that handy when you are at the microscope. One of the nice aspects of the original POLCOUNT was that you could get by most of the time with an external numeric keypad on a wire from the computer. If I were counting with the FF version, I would take Adam Walanus' advice: use the "regular" numbers for the common grains and the other Hex digits (with the A-F combinations) for the rarer types. References. Maher, L.J. (1992) Turn your expensive old PC into a dumb pollen counter. INQUA - Commission for the Study of the Holocene, Working Group on Data-Handling Methods Newsletter 8:24-27. Ralska-Jasiewiczowa, M. and Walanus, A. 1991. Polish palynolgical database (POLPAL) in course of building. INQUA - Commission for the Study of the Holocene, Working Group on Data-Handling Methods Newsletter 5:1-2. SPORE MARKER TABLETS - HELP! Date: Thu, 2 Dec 1993 13:29 CST From: WARDJER@DUCVAX.AUBURN.EDU Subject: Lycopodium tablets Dear Lou, Do you know where I can obtain Lycopodium marker tablets? I received an email letter from Bjorn Berglund saying that he is no longer making them owing to a problem with the manufacturer. He implied that he had no schedule for further production. I have a few left but will need another batch in about a month. Would you put an ad in the newsletter for me asking anyone who might have some extra tablets to e-mail me? I have received at least a half dozen inquiries during the last few months from people needing a source for spore marker tablets. Back in 1973, I arranged for Jens Stockmarr to produce a batch of Eucalyptus tablets for a group of palynologists here in the U.S. I am down to my last bottle of that batch. I still have a few bottles of Stockmarr's original batch of Lycopodium tablets, and I treat those like gold. This is really a very serious problem to my way of thinking. A well made marker-grain tablet is surely the most efficient way to introduce a marker to a pollen sample. I have heard it said that pipetting markers is just as good, but that ignores the risk that the mean and standard deviation of pipetted stock fluids can change with time and operator. I have also heard palynologists say they do not care about tablets because they use micro-spheres or glass beads as markers. But because these cannot be added until after the chemical processing, the major value of adding a durable spore before processing to negate the effects of processing loss is no longer available. I might add that I find a well-darkened Lycopodium spore to be the best for strength and visibility. Some of the Eucalyptus grains in the batch I had made were a little too faint to be recognized easily. I might also add that it is good not to have too many spores in a tablet. If you need to add several tablets to get enough markers, you automatically decrease the variance of the spike with respect to its mean. Does anyone have an answer? Does anyone know of a friendly academic pharmaceutical engineering department who might like to have a student project? Let me know, and I will try to enlist another spore-buyers' consortium. [*p.7 / p.8*] CD-ROM DATA SETS: PART 2 GLOBAL ECOSYSTEMS DATABASE VERSION 1.0 Glen M. MacDonald Department of Geography McMaster University Hamilton, Ontario Canada L8S 4K1 E-mail: gmmacd@mcmaster.ca After reading my first article on CD-ROMs I expect that all of you Rockers from the l960s are busy accessing data and playing the Jimi Hendrix Greatest Hits CD on your lab computers. However, there may still be some lost souls without the benefit of CD-ROM and I feel obliged to direct a few words to them. Then I will describe the Global Ecosystems Database available from the Environmental Protection Agency (EPA) and the National Oceanographic and Atmospheric Adminis- tration (NOAA) in the United States. Since my last article the price of CD-ROMs has continued to decline. A decent unit can now be had here for less than $350.00 Canadian Dollars. In addition, more and more multimedia systems such as the Dell Dimension or NEC Ready with bundled 486 PC - CD-ROM audiovisual packages are available. Aside from accessing some interesting data sets, why should you lay down your hard earned dollars, pesos, francs, pounds, rubles etc. for a CD-ROM unit? Well, for one thing it is likely that much of the software you will buy in the next few years will be sold on CD-ROM. Microsoft's Windows NT products have already gone to this medium. The reason vendors will make this move is simple; it costs a lot less to produce, package and distribute one CD with up to 680 megabytes of software on it than it costs to produce, package and distribute the equivalent fifty to sixty floppy-disks. There are several benefits for users; software transfer and installation are easier, CDs remain uncorrupted and virus free as they are read-only, and they are easy to store. Will the move to CDs bring software prices down? I doubt it. Perhaps though, there might be a surcharge to get software on 3.5" or 5.25" disks in the near future. Storage space is another inducement to go the CD-ROM route. Once you install DOS 6.0, Windows and few high performance software packages you may find that 100 to 300 megabytes of space on your hard-disk are filled. Keeping data on CD allows you to use the valuable space remaining on your hard-disk for yet more software packages. Storage space is one of the major advantages for acquiring large data-sets on CD-ROM even when the same data might be available through Anonymous FTP. Okay, you're convinced right? So what do you look for in a CD-ROM unit (besides a bargain-basement price)? First, you don't want to spend too much time waiting for data to be read off the CD. You should get the lowest Average Seek Time unit you can afford (350 ms or less). This should be coupled with a high Data Transfer Rate (at least 300 kbs). So called Double Speed or Multi-Spin units should meet these requirements. A buffer can also be useful in data transfer and 64 kb should be sufficient. Finally, for those thinking about the future, I suggest that you get a unit that is compatible with Multimedia Personal Computing and Kodak Photo PC. I can envision a day when we trade or submit for publication palynological reference photos and other imaged material on CD rather than by sending negatives, prints etc. By the way, that Jimi Hendrix CD will sound particularly awesome when you couple your CD-ROM with a 16 bit sound-card! Now, on to the data. The Global Ecosystems Database (GED) is produced through the joint efforts of the EPA and NOAA and is available from the Global Ecosystems Database Project, National Geophysical Data Center, 325 Broadway E/GC1, Boulder, Colorado, 80303, USA; PH 303-497-6125, FAX 303-497-6513, EMAIL info@mail.ngdc._ noaa.gov. The cost for the CD, a copy of IDRIX GIS software, and three manuals is $100.00 (US). I have been using Version 1.0. The database and IDRIX can run in an IBM-PC/DOS environment. The system must have at least 256 K of memory and support EGA graphics. An Intel 80486 based machine with 640 K and a graphics accelerator card with 8514A graphics would be ideal. A Microsoft mouse is required for IDRIX and a math coprocessor is recommended. The GED is an amazing tool for any paleoecologist who requires environmental data with which to calibrate (at least at the level of first approximation) transfer functions based on the modern distributions of environmental variables and pollen, diatoms, beetles, etc. The key word for these data is global. All of the data sets include all of the globe with the exception of the very high latitude polar regions. There are 14 nested raster data sets which provide global estimates/observations of a number of environmental variables. These data sets [*p.8 / p.9*] reflect the very hard work of a number of scientists from different disciplines. The data include the Lee- mans and Cramer IIASA mean monthly temperature, precipitation and cloudiness values; Legates and Willmott average monthly surface air temperatures and precipitation, a seasonal albedo set, several global vegetation and land cover data sets, Holdridge life zones, soil and terrain and topographic characteristic data sets, and information on methane emissions. Some of my favourite data are available from the methane compilations by Lerner, Matthews and Fung. For example, I have long had a belief that one could develop a transfer function to retrodict the number of camels in the Sahara based on the relative abundance of Artemisia, Ficus and Poaceae pollen. The GED provides a data set for a global estimate of camel density per square kilometre that is ideal for this! I am still pondering the possibility of a similar approach using the water buffalo data set! Another interesting feature of the disk is the multi-year data sets of vegetation indices based on AVHRR observations from the NOAA-9 and NOAA-11 satellites. The spatial resolution of most of the data sets range from 10 minutes to 1 degree. In addition to these sets there are an experimental global elevation and bathometry data set and an experimental soil data set with 2 minute resolution. There are also vector data sets to provide information on the location of coastlines, islands, lakes, rivers and political boundaries. For all of you espionage fans, you might be interested to know that the vector data comes by way of the U.S. Central Intelligence Agency! There is extensive documentation on data format, sources, reliability and appropriate references in the scientific literature. This documentation alone provides a wonderful source of information. Data file structure is simple and well described, so that extraction of data for further analysis is straight forward. Although the data provided by the GED is amazing, a particularly attractive inducement for the neophyte data cruncher is the inclusion of a simple Geographic Information Systems (GIS) package with which to display the data, export it and perform some simple manipulations and analysis. The system is IDRIX which is a subset of the IDRISI PC- based GIS developed by Clark University. Two 5.25" floppies are included with the GED. These contain IDRIX and an installation program. The installation is extremely straight forward. After a few minutes the user has available a menu-driven program to display colour maps or orthographic (3d) displays of the GED data - including some time series displays of monthly temperatures, examine files, and export data. In addition, there is on-line help and a copy of the manuals in electronic form. IDRIX allows some simple GIS manipulations such as the ability to: (1) move a cursor across the map and obtain pixel data values and geographic coordinates, (2) use the cursor as a digitizer to trace features on the map and create vector files, (3) overlay raster images with vector files of features such as rivers or vegetation boundaries you have created by digitizing other images, (4) magnify portions of the global maps for detailed analysis of particular regions, and (4) alter colour thresholds and assignments. The danger of all this that there are just so many interesting and colourful data sets it is hard to stay away from the computer after things are up and running! So, the GED provides a massive amount of data, much of which will be of great interest to palaeoecologists trying to calibrate modern plant and animal distributions with environmental conditions. The addition of IDRIX provides an introduction to GIS and relatively easy way to display and extract data. What then are the problems with the GED? First, it runs extremely slowly on our Intel 80386 based machine. It is painful to wait for images to be displayed. Second, the menu for IDRIX is pretty sparse and you often end up guessing about what will get you out of a certain application etc. The IDRIX manual is also pretty brief, being a scant 25 pages. If you have no experience with GIS or IDRISI you could have some frustrations. Third, you have to have a fair amount of memory to run this. With DOS 6.0, Windows and lots of other stuff cluttering up our machine this can be a problem. We found that we had to use the DOS statement COMMAND /E:521 to get things up and running. IDRIX On-Line Help suggested using either COMMAND /E:521 /P or SHELL = COMMAND /E:521 /P. For some reason, neither of these worked properly when we invoked them on our Dell. A final caveat concerns the data themselves. It is pretty appealing to take these data at face value when you see them so elegantly displayed on the screen. The contributing scientists, the EPA and NOAA went to great lengths to ensure, as much as possible, the integrity of the data. However, it should be borne in mind that many of the data sets were put together to satisfy the requirements of GCM modelers and the level of accuracy and detail that they might have called for may not be as fine as what the calibration of a modern pollen data set requires. Read the documentation very carefully before taking as literal values such as the Amount of Silt in Soil Horizon 1 for a particular pixel [*p.9 / p.10*] representing a site in central Siberia. I use the Global Soil Particle Size Properties as an example here only because one of its authors, Robin Webb, so brutally out- skied me last year while we were conducting observations of late- spring snow conditions and discussing the GED in Colorado! RANDOM ACCESS COMPUTER KEYS (RACKs) John H. McAndrews and Zicheng Yu Department of Botany Royal Ontario Museum 100 Queens Park Toronto, Ontario M5S 2C6 Canada E-mail: docjock@utcs.utoronto.ca yuzi@gpu.utcs.utoronto.ca To make visual identifications of objects we resort to comparison with identified specimens, illustrations, descriptions and keys. In biology these keys commonly require choice between sequences of often subtle taxonomic characters. In contrast, random access keys permit selection of taxa using the more obvious characters of the unknown specimen. Random access keys take three forms: determinative tables for identifying minerals and wood, the edge-perforated card key illustrated in Faegri and Iversen (1964, p. 200) for identifying pollen grains, and the Random Access Computer Key (RACK). A RACK is basically a two-dimensional array of characters versus taxa. You work the key by entering the most obvious characters in any order; taxa having these characters are immediately listed on the monitor. Our BASIC program was modified from Ogden and Mitchell (1990) to which Maher added an editor to ease making changes. The type of RACK we describe is handy, easy to use and modify, inexpensive to operate, and it makes an excellent teaching device. Although the European and North American Pollen Databases are organized and available by random access, they are not easy to learn, and they require a user have Paradoxþ. Our first RACK was designed to handle North American Pollen grains and spores, and we call it NAPKEY.BAS. It is a text-based key, and this was done to keep it simple and cheap. We are not competing with The South Pacific Pollen Atlas Project (Hope et al. 1992) or Cushing's (1991) Macintosh HyperStackþ key SARI; both make use of screen graphics and are much more complex to set up and maintain. NAPKEY comes up with a screen that provides information and a few rules. The user then sees a screen like Fig. 1. There are 105 pollen/spore characters or character values grouped into nine menu categories. The main categories are shown in yellow capital letters. You can type a number or the letters N, R, or Q. If the number is between 1 and 105, the corresponding character item changes color, and the number of taxa with that character appears at the screen's upper left. You can see the names of these taxa by pressing the letter N. Normally one has several characters set simultaneously to reduce the number of possible taxa. If setting a character results in 0 taxa with that combination of characters, typing the number again prefixed with a minus sign turns the character off. If you want to reset everything and start again, touch the letter R. Touch Q to quit. While it is not overly helpful to a student to see a list of taxon names, a lot of names indicates more grain characteristics are going to be needed to narrow down the possibilities. Whereas the microscope is best for deciding which taxon matches the unknown grain, RACKS should be used with a paper manual. NAPKEY uses McAndrews et al. (1973); when the taxa names appear, the user is given helpful comments as well as reference to figures showing the grain. [*p.10 / p.11*] We have just completed a RACK for Hardwood (HWKEY.BAS) based on a table in Panshin and de Zeew (1970). Maher made a Rock and Mineral Key (MINKEY.BAS) based on Bowser et al. (1968), as well as one for identifying airplanes (AIRKEY.BAS) which refers to page illustrations in Montgomery and Foster (1984). The main screens of these RACKs are shown in Fig. 2. RACKs for tropical pollen, seeds and minnows are in progress. Because we are sure you are going to want to make a RACK for your own use, we have produced Generic RACK forms. They require no screen mapping to complete, and you can just fill in the blanks. The working screen comes in versions of two, three, four or five columns, together with editors for each type. Fewer columns are simpler and require fewer abbreviations. The group label on the generic RACKs is just another character with a CAPITALIZED name, and thus it is edited as a character. A RACK is most useful when a user can add or delete taxa or change the characters associated with taxon. Lou Maher will discuss his EDITRACK program in the next article. These programs can run using QBASIC that come with DOS 5. You can get them by ftp from the INQUA File Boutique. They occur in the self-extracting file RACKS.EXE in directory: /pub/inqua on geology.wisc.edu (ftp 144.92.137.14). References. Bowser, C. J., Gates, R. M. and Archbald, D. 1968. Quick-Key Guide to Rocks and Minerals, Doubleday & Company, Inc., Garden City, NY. Cushing, E.J. 1991. Sara: a HyperCard stack for describing and identifying spores and pollen grains. INQUA - Commission for the Study of the Holocene, Working Group on Data-Handling Methods Newsletter 6:1-3. Faegri, K. and Iversen, Johs. 1964. Textbook of pollen analysis. Munksgaard, Copenhagen, 237 p. Hope, G., Martinello, C. and Owen, J. 1992. Australian and Southwest Pacific pollen atlas project. INQUA - Commission for the Study of the Holocene, Working Group on Data-Handling Methods Newsletter 8:1-3. McAndrews, J.H., Berti, A.A., and Norris, G. 1973. Key to the Quaternary pollen and spores of the Great Lakes region. Life Sci. Misc. Publ., Royal Ontario Museum, 61 p. Montgomery, M.R. and Foster, G. 1984. A Field Guide to Airplanes, Houghton Mifflin Company, Boston, 212 p. [*p.11 / p.12*] Panshin, A.J. and C. de Zeew. 1970. Textbook of Wood Technology, Vol. 1. 3rd edition. McGrawHill, New York (modified from Table 5-10). Ogden, E.C. and R.S. Mitchel. 1990. Identifications of plants with fleshy fruits. New York State Museum Bulletin No. 467. EDITKEY: FOR WHEN YOU CHANGE YOUR MIND Louis J. Maher When Jock McAndrews first let me see NAPKEY.BAS, I immediately wanted to add the information from my "edge-notched" card key that has lain on my desk for 30 years. Notched cards were so much fun when they were new; you ran a rod through the hole representing a character of the unknown grain, and all those grains with that character hole cut out fell on the desk. If you had put the grain's picture on the card, there would often be a good match. You could add a new card, cut a new slot, or repair a wrong cut, and the key went right back to work. Problems arose when there were more than about 50 cards; notched ones tended to stick in the deck, and they were hard to shuffle back into order. With NAPKEY you could alphabetize the cards and check their pictures against the RACK's suggestions. The algorithm Ogden and Mitchel (1990) use in their key to fleshy fruits is written in BASIC with numbered lines. It is quite efficient, very fast, and all the data are stored right in the program so there are no external files to get lost. Three variable groups are involved; all are "character strings" that BASIC reads from lines pre- fixed with the word DATA. One group includes the words used in the screen menu, the second group is composed of lines with the taxon names, figure references and comments, and the third group is nothing but long lines of 0's and 1's. Each of these "gibberish" lines correspond to one of the key characters, and each position from left to right along the line represents one of the taxa. If the taxon has the character there is a "1"; if it does not there is a "0". The program reads each of these lines as a single string variable and sorts things out using BASIC's excellent string-handling features. One could edit the original BASIC lines, of course, but it is tedious and time-consuming, and there is a high probability something will be messed up and the program will not run at all. My plan for making a program to edit NAPKEY involved the removal of all the line numbers and grouping the parts into a structure with which it is easier to deal. I wanted to divide the program into two pieces: first the part with the algorithm and a second part with all the variables. The part with the variables would be a subroutine to which control is passed when the program starts. If the two parts were separated with a line that could be recognized, the editing program would simply read the BASIC program as lines of text and save them immediately as a file with a name like "ZZZPART1.TXT". That text file will always end with a line like "<<< Do not move this line >>>" because the editing program looks for consecutive ">>>" characters to separate the two parts. Then EDITNAP watches for lines with "MENU =", "TAXA =", and "CHAR =", and it reads the numbers after the "=" sign. The present version of NAPKEY has the lines: MENU = 115 TAXA = 144 CHAR = 105 MENU will contain all the phrases that appear on the menu screen. CHAR refers to the number of characteristics in the key, and the difference between MENU and CHAR (here 10) will be the lines used for group titles. Phrases for the titles will be put on the screen last with a different color. The editing program then looks for lines beginning with "DATA", reads each in as a single string variable, strips off the parts it does not want and interprets the rest as the variables it needs. Once the values are in, their editing can begin. My initial plan had to be altered when I began to deal with the characters and group titles for the screen. The screen labels are strings placed by their starting line (1 to 25) and starting column (1 to 80). One would have to read these locations and try to map out the screen. For example in Fig. 1 of Jock and Zicheng's article, "25 0.88-0.75" starts at line 7, column 16; but to what does that refer? It could be size or range of some other factor; it happens to be the ratio of polar axis to equatorial axis. When a user edits a taxon's characters, [*p.12 / p.13*] it does no good to offer to toggle the presence or absence of "25 0.88-0.75" unless he/she knows what it is. It would probably be possible for the computer to figure out the titles for each character in NAPKEY, but I imagine someone could make a key's screen that would foil any procedure I might produce. So I have put the screen variables before the "cut line." This means there can not be a single Edit-KEY program; rather for NAPKEY there must be EDITNAP, for MINKEY, there must be EDITMIN, etc. To make EDITNAP, the user must read NAPKEY into a text editor and find the part dealing with the screen labels: ... DATA 3, 16,"21 >2.00" DATA 4, 16,"22 2.00-1.33" DATA 5, 16,"23 1.33-1.14" DATA 6, 16,"24 1.14-0.88" DATA 7, 16,"25 0.88-0.75" DATA 8, 16,"26 0.75-0.50" DATA 9, 16,"27 <0.50" DATA 10, 16,"28 heteropolar" DATA 11, 16,"29 rhomboidal" ... The fragment above would be expanded into something like: ... DATA " EQUATOR SHAPE - 21 perprolate " DATA " EQUATOR SHAPE - 22 prolate " DATA " EQUATOR SHAPE - 23 subprolate " DATA " EQUATOR SHAPE - 24 spheroidal " DATA " EQUATOR SHAPE - 25 suboblate " DATA " EQUATOR SHAPE - 26 oblate " DATA " EQUATOR SHAPE - 27 peroblate " DATA " EQUATOR SHAPE - 28 heteropolar " DATA " EQUATOR SHAPE - 29 rhomboidal " ... which would be pasted near the end of EDITNAP.BAS after the lines: ... '---------------other needed items---- REM Data for Screen follows; As new characters REM are added to NAPKEY.BAS, add their names to REM the following list as well. ... Actually this is not too bad. It gives the user the chance to see how the program works and to make the phrases clearer. The Generic RACKs Jock and Zicheng made save time setting up a new key's screen, but one must still see that the categories in, say, EDIT_X conform to those in X_KEY. It is important to remember that EDITNAP expects to find that NAPKEY.BAS is an ASCII text file. If you use a wordprocessor, be sure to save changes as simple ASCII text. When EDITNAP runs it sets aside some space for new taxa you may add, shows you the directory and asks which file to edit. When it is loaded you will see a screen listing the first taxon in the key. A line below begins with the phrase Letter and/or , followed by a flashing cursor. You can step through the taxa by pressing the key (or back up by pressing ). If you type a letter or letters, the program jumps to the first taxon starting with that combination. If you want to add a new taxon to the key, type the taxon name, capitalized the way you wish, and press "&" rather than . The program will place this taxon in alphabetical order and let you indicate its characteristics. Instructions are always at the bottom of the screen. The key deletes the taxon whose name is shown. The key allows you to edit the taxon's name line--never the spelling (see below). The key shows you the taxon's physical characteristics and allows you to step through them quickly with the up/down arrow keys. When you find one you wish to change, press and the characteristic will toggle between "Present" and "0." Pressing drops you back to select another taxon. When you are finished, the will save the results by reconstructing a new addition of NAPKEY.BAS, saving the original version as NAPKEY.BAK. You can delete that later when you are satisfied with the new version. Do NOT edit the spelling of an existing taxon's name. Record a list of the taxon's characteristics, if they are already entered, and use to delete the incorrectly spelled taxon. Then add the correctly- spelled taxon name with "&", remembering to use to annotate its characteristics. It is important to let the program do the alphabetizing. If you edited a taxon name from Ambrosia to Xanthium, for example, and then added Pinus (by typing Pinus&) you would find it placed just before Xanthium somewhere among the taxa beginning with "A". You will be alright if you let the program do the alphabetizing of the taxon names you add appended with &. If you think a student would benefit from constructing his/her own NAP key just from the specimens seen in class, you might want to keep the key structure without its data. You can to that by copying NAPKEY.BAS to NEWKEY.BAS. Search for the line "CHAR = 144" and change the number to 1. Because the screen categories remain the same, you can edit NEWKEY with EDITNAP. When you edit NEWKEY.BAS the first taxon, Abies, will be on the screen. Immediately type Dummy& to add a dummy taxon. Then delete Abies and exit. Your student can start off with a key containing only a single dummy taxon that holds a place until he/she enters the class taxa while learning pollen at the same time. [*p.13 / p.14*] Jock and Zicheng's Generic RACK templates may save time in making new keys, but you may like the challenge of designing your own screen. Get a piece of graph paper and mark out a rectangle 25 spaces high by 80 spaces wide. Use a pencil to place your group titles and characteristics--remembering to stay out of lines 1 and 25; the program uses those. Leave at least 2 spaces at the right too because the characters move right one space when they are selected. If they are moved into column 80, bad things will happen. Is there a limit to the number of taxa you can use in the key? Yes, and it has to do with how QBASIC and QuickBASIC store strings. AIRKEY.BAS lists 306 different airplanes. It will not run under QBASIC, which reports it is "out of string space." You can run it with QuickBASIC because it can put the strings in a far off space by themselves. You cannot compile AIRKEY with QuickBASIC because its compiler cannot reference "far strings." AIRKEY will compile with Microsoft's Professional BASIC, but that introduces other problems and defeats the charm of these Keys. Figure you can get a couple of hundred taxa into a key without too much difficulty. If you really need more, make a key for pollen and another for spores. Or move up to the complex databases. You will probably get more speed and power, but you will not feel the wind in your face. Reference. Ogden, E.C. and R.S. Mitchel. 1990. Identifications of plants with fleshy fruits. New York State Museum Bulletin No. 467. AN INTERNET GUIDE TO QUATERNARY LIBRARY RESOURCES Dana L. Naldrett Dept. Geological Sciences University of Manitoba Winnipeg, Manitoba Canada R3T 2N2 E-mail: naldret@cc.umanitoba.ca The following is the first of what may be several evaluations of library resources available to the average network computer user. For those unfamiliar with network use, I recommend "The Whole Internet User's Guide & Catalog" (Krol, 1992). As a starting point, I have somewhat arbitrarily chosen libraries at what are thought of as "good" universities, and evaluated them for Quaternary subjects which I consider common (you will note the biological and glacial bias I have--your interests may differ). Each topic was rated from 0 (worst) to 5 (best), and the topics were added to produce a cumulative total out of a possible 80 points. Thus, each library can be rated according to either specific personal taste (individual subjects), or comprehensively (all topics). All rating results are shown on Fig. 1. All libraries were accessed by modem or Ethernet connection with our Sun Unix operating system, using either telnet or tn3270 to directly address the host machine. Remember when using Unix that the operating system, unlike others, is case sensitive. If something does not work as it should, first make sure that upper and lower case are used correctly. Although telnet instructions and logon procedures are given here, by far the easiest way to do this is to use your hytelnet facility, usually through the Unix operating system. The hytelnet system I used was developed by Peter Scott, and provides essentially the same service as telnet, but is more sophisticated and easier as it does not require remembering details of the host system. Hytelnet itself is transparent, and allows communication with both the remote (host) and local system if desired. Peter provides frequent updates to the hytelnet system, giving network postings of new or changed library systems, network access facilities and public information services. This may be subscribed to by e-mailing listserv@kentvm.kent.edu and sending the following message: SUBSCRIBE HYTEL-L First Name Last Name To unsubscribe, send the following to the same address: UNSUBSCRIBE HYTEL-L To try hytelnet on your local system, get into the Unix operating system, and type "hytelnet" [return]. This should start hytelnet. If at any time you wish to exit the hytelnet system, type [Ctrl] ] or [Ctrl] C and this should release you to the telnet portion of your Unix operating system. To get out of telnet, type "quit", and this should return you to the Unix operating system you started from. [*p.14 / p.15*] Caution must be used in searches to get good results. Often the same term will not produce results in the title and keyword searches, or there may be differences between different types of keyword searches. Another problem is the Library of Congress keyword selections. For example, till is almost never found- you must search for the antiquated term drift instead. Similarly, diamict(on) is almost never found. I also found this with tephra- it is usually found under volcanic ash. There are many references to glaciomarine and glacio- lacustrine deposits, but the terms glaci(o)marine and glaci(o)lacustrine rarely show up. I assume this is because of the way they have been reviewed by the Library of Congress evaluators. CANADA Carleton University- poor display of holdings, but good holdings telnet libray.carleton.ca or 134.117.1.46 at the first option prompt, type "profile vt100" at the second option prompt, type "help" to see search commands Dalhousie University- telnet novanet.dal.ca or 129.173.1.22 press [Return] to enter the catalog McGill University- tn3270 mvs.mcgill.ca on menu, choose option 2 (MUSE) for library holdings at CICS screen, hit [Return] to exit, type "sto" (for stop) Queen's University- good holdings, and good display, but some tricks getting things to work. Their system uses function keys, which are not recognized as such using telnet. To emulate a function key, use [Escape] followed by the number key for that function (i.e. F3 is [Esc] 3). tn3270 qucdnadm.queensu.ca or 130.15.125.20 once connected, follow instructions as they appear onscreen University of Alberta- telnet or tn3270 (preferred) dra.library.ualberta.ca or 129.128.5.180 for username, type "gate" University of British Columbia- good holdings in most subjects, but frustrating way of listing search findings. telnet library.ubc.ca or 137.82.42.5 at Enter your id: press [Return] at the first menu, choose LIB for library at the second menu, choose CAT for library holdings catalog University of Saskatchewan- telnet sklib.usask.ca or 128.233.1.20 for username, type "sonia" follow instructions that appear after login University of Toronto- the only search system seen that is menu-driven! Unfortunately, the menu also obscures the search results (it cannot be removed from the screen when scrolling through search hits). Generally a badly designed system - inconvenient. telnet vax.library.utoronto.ca or 128.100.95.1 for username, use "utlink" for user id, type [Return]- this limits use to non-commercial services after login, follow instructions to get to holdings catalog UNITED STATES Columbia University- ranked well overall. Has good display of holdings. telnet clio.cul.columbia.edu or 128.59.40.200 when connected, hit [Return] enter terminal type as "vt100" to exit, type "stop" Cornell University- MUST use tn3270 rather than telnet. Using telnet gives garbled screen image. tn3270 cornellc.c.t.cornell.edu or 128.253.1.19 at user ID/password screen, press [Return] at CP Read appears, type "library" to exit, type "x" Duke University- holdings are good, but awkward display of holdings and doesn't show the total number of findings for each search telnet ducatalog.lib.duke.edu or 152.3.7.2 for username, type "library" on main menu, select "1" for catalog searches to exit, enter "q" from main menu Harvard University- overall, one of the best for its holdings, but also one of the worst for searching and displaying results. Display organization is poor; excellent long display for detailed search records, but must browse through badly displayed first list to find a single entry. [*p.15 / p.16*] telnet hollis.harvard.edu or 128.103.60.31 press [Return] when Mitek Server screen appears type "hollis" on the Harvard University/Office for Infor- mation Technology screen to get catalog searches to exit, type [Esc] xx Johns Hopkins University- generally very good, but some bugs. Sometimes difficult to proceed from JHV/HAC login screen. Repeated attempts should eventually get you there- it's worth trying. Display of holdings is good- by chronological order, and either short or long display. telnet jhuvm.hcf.jhu.edu or 128.220.2.2 at "enter terminal" prompt, enter "56" at JHU/HAC logo screen, press [Return] at command prompt type "dial janus" when port assignment appears, press [Return] Kent State University- generally very good. Has good display of holdings. telnet catalyst.kent.edu or 131.123.1.9 when given the control character for telnet, press [return] at "enter terminal", type "vt100" at "select application", type "a" at CICS screen, type "luks" to exit: from inner menu type "stop" from outer menu type [Ctrl] ] [*p.16 / p.17*] Notre Dame University- tn3270 irishmvs.cc.nd.edu. Telnet will not work. at Enter Command or "HELP" type "library" choose database wanted- ND for Notre Dame to exit type [Ctrl] ] Ohio State University- generally a disappointment. Awkward search procedure and display only fairly good. Holdings average to slightly above average. telnet lcs.us.ohio-state.edu or 128.146.15.141 for device or terminal type, enter "vt100" or "mac.ibm" University of Chicago- telnet olorin.uchicago.edu after line saying escape character is ^], press [Return] at enter class prompt, enter "LIB48" at "connected" message press [Return] to exit, type "logout" University of Colorado at Boulder- this is available through the Colorado Alliance of Research Libraries (CARL), a network of libraries. A central number is accessed, and the desired site is chosen from inside CARL. Also available is the Colorado State Uni- versity. telnet pac.carl.org or 192.54.81.128 login as "pac" and follow directions and questions from there to exit, type "//exit" University of Minnesota- telnet lumina.lib.umn.edu or 128.101.92.3 when prompted for terminal type, choose either 8 or 56 to emulate VT100 with echo on or off, as required follow directions on screen to select correct library and search area Yale University- tn3270 orbis.yale.edu choose OPAC- Yale University Catalog Reference. Krol, E. 1992. The Whole Internet User's Guide & Catalog. O'Reilly & Associates, ISBN 1-56592-025-2. NEW BOOKSHELF 8 H.J.B. Birks E-mail: John.Birks@bot.uib.no The following recently published books may be of interest to readers of this Newsletter. Barnett, V. & Turkman, K.F. 1993 Statistics for the Environment. J. Wiley & Sons, Chichester. 427 pp. Berry, W.D. 1993 Understanding Regression Assumptions. Sage, Newbury Park. Paperback. 91 pp. Botkin, D.B. 1993 Forest Dynamics - An Ecological Model. Oxford University Press, Oxford. 309 pp. Chester, D. 1993 Volcanoes and Society. Edward Arnold, London. Paperback. 351 pp. Crawley, M.J. 1993 GLIM for Ecologists. Blackwell, Oxford. Paperback. 379 pp. (with diskette). Demaris, A. 1992 Logit Modelling. Practical Applications. Sage, Newbury Park. Paperback. 87 pp. Diaz, H.F. & Markgraf, V. (Eds.) 1993 El Ni¤o. Historical and Paleoclimatic Aspects of the Southern Oscillation. Cambridge University Press, Cambridge. 476 pp. Eliason, S.R. 1993 Maximum Likelihood Estimation. Logic and Practice. Sage, Newbury Park. Paperbck. 87 pp. Fahrmeir, L. et al. (Eds.) 1992 Advances in GLIM and Statistical Modelling. Springer-Verlag, Berlin. Paperback. 225 pp. Frenzel, B (Ed.) 1993 Oscillations of the Alpine and Polar Tree Limits in the Holocene. European Science Foundation, Strasbourg. Paperback. 234 pp. Fry, J.C. (Ed.) 1993 Biological Data Analysis. A Practical Approach. IRL Press, Oxford. Paperback. 418 pp. Fox, J. 1991 Regression Diagnostics. Sage, Newbury Park. Paperback. 92 pp. [*p.17 / p.18*] Gates, D.M. 1993 Climate Changes and its Biological Consequences. Sinauer Associates, Sunderland, Mass. Paperback. 280 pp. Gibbons, J.D. 1993 Nonparametric Statistics. An Introduction. Sage, Newbury Park. Paperback. 87 pp. Gurney, R.J., Foster, J.L. and Parkinson, C.L. (Eds.) 1993 Atlas of Satellite Observations related to Global Change. Cambridge University Press, Cambridge. 470 pp. Hagenaars, J.A. 1993 Loglinear Models with Latent Variables. Sage, Newbury Park. Paperback. 75 pp. Hair, J.F. et al. 1992 Multivariate Data Analysis with Readings Third edition. Macmillan, New York. 544 pp. Hamilton, L.C. 1992 Regression with Graphics - A Second Course in Applied Statistics. Brooks/Cole Publishing, Pacific Grove, California. 363 pp. Hardy, M.A. 1993 Regression with Dummy Variables. Sage, Newbury Park. Paperback. 90 pp. Jacoby, W.G. 1991 Data Theory and Dimensional Analysis. Sage, Newbury Park. Paperback. 89 pp. Kareiva, P.M. et al. (Eds.) 1993 Biotic Interactions and Global Change. Sinauer, Sunderland, Mass. Paperback. 559 pp. Kirby, K.N. 1993 Advanced Data Analysis with SYSTAT. Van Nostrand Reinhold, New York. 475 pp. Lindsey, J.K. 1992 The Analysis of Stochastic Processes using GLIM. Springer-Verlag, Berlin. Paperback. 294 pp. Mooney, C.Z. & Duval, R.D. 1993 Bootstrapping. A Nonparametric Approach to Statistical Inference. Sage, Newbury Park. Paperback. 73 pp. Press, W.H. et al. 1992 Numerical Recipes - The Art of Scientific Computing. (Second edition). Cambridge University Press, Cambridge. 963 pp. (also available are Example Books and Diskettes of Subroutines in C, FORTRAN, Pascal, and BASIC). Reyment, R.A. & R”reskog, K.G. 1993 Applied Factor Analysis in the Natural Sciences. Cambridge University Press, Cambridge. 371 pp. Roberts, N. (Ed.) 1994 The Changing Global Environment. Blackwell, Oxford. Paperback. 531 pp. Schumm, S.A. 1993 To Interpret the Earth. Ten Ways to be Wrong. Cambridge University Press, Cambridge. 133 pp. Taylor, R.E. et al. (Eds.) 1992 Radiocarbon after four Decades. Springer-Verlag, New York. 596 pp. Van de Geer, J.P. 1993 Multivariate Analysis of Categorical Data: Applications. Sage, Newbury Park. 124 pp. Van de Geer, J.P. 1993 Multivariate Analysis of Categorical Data: Theory. Sage, Newbury Park. 99 pp. Weisberg, H.F. 1992 Central Tendency and Variability. Sage, Newbury Park. Paperback. 89 pp. PC Magazine 12 (9) (May 11 1993) had an interesting comparative review of some of the more popular statistical packages such as BMDP 386, Genstat, Minitab, SPSS, Statgraphics, and Systat that, in some way, are programmable. Readers of this review may be interested in Richard Goldstein's (the Statistical Computing Software Review Editor in American Statis-tician) notes about the PC Magazine review in American Statistician (1993) 47, 216. There is an interesting Special Feature series of papers in Ecology (1993) 74 (6) 1615-167 on Statistical Methods: an Upgrade for Ecologists. Topics covered include distribution-free randomisation procedures, different non-standard regression procedures, ANOVA for unbalanced data, spatial heterogeneity, and spatial autocorrelation. POLPAL-LISTSERVer Several readers have asked me why they could not reach POLPAL-L that was mentioned in the last issue. I e-mailed Peter Kevan to find out, and this is what he said: The system changed here and it is now: POLPAL-L@UOGUELPH.CA. My address is: pkevan@uoguelph.ca (the old one with vm. in it is still working for a little while yet.) [*p.18 / p.19*] You may want to resubscribe by sending to LISTSERV@UOGUELPH.CA the message: SUBSCRIBE POLPAL-L FIRSTNAME LASTNAME and you will be back on. Sorry about inconvenience. It has been a huge effort on my part to deal with all this plus the lightening strike which fried my terminal. Cheers and welcome again. There hasn't been a lot of traffic recently though. If at any time you want to leave the list, send an e-mail message to: LISTSERV@UOGUELPH.CA with the text as follows: UNSUBSCRIBE POLPAL-L DIATOM-L A LISTSERVer FOR DIATOM RESEARCH P. Roger Sweets Department of Biology Indiana University Bloomington, IN 47405 E-mail: sweets@ucs.indiana.edu DIATOM-L is the listserv for researchers interested in the diatom algae. All aspects of diatom science are represented by the members, such as taxonomists, ecologists, and physiologists, but INQUA members might be interested to note that there is a large representation of paleoecologists. We encourage any active researcher in diatoms to sign up. The membership includes researchers in Europe as well as the U.S. We welcome any meeting and job announcements, relevant scientific information, as well as general queries about diatom science that the members can address. For instance, an interest in diatom paleoecology in a particular region might bring a response from a scientist who has done work in that region. Please remember that any message addressed to DIATOM-L will go to nearly 100 diatom researchers, so only serious queries are encouraged. The list address is: DIATOM-L@iubvm.ucs.indiana.edu The address of the operating LISTSERV (for signups, etc.) is: LISTSERV@iubvm.ucs.indiana.edu The operator of DIATOM-L is P. Roger Sweets of Indiana University and further queries can be addressed to him at sweets@ucs.indiana.edu USEFUL ADDRESSES AVAILABLE TO PUBLIC BY TELNET OR ANONYMOUS FTP INQUA File Boutique. ftp geology.wisc.edu (ftp 144.92.137.14) Logon: anonymous; Password: your e-mail address Path: /pub/inqua World Data Center-A (WDC-A), U.S. National Oceanic and Atmospheric Administration (NOAA), National Geophysical Data Center (NGDC) Paleoclimatology Program (Note: Numeric Host Address Subject to Change) ftp ftp.ngdc.noaa.gov (ftp 192.149.148.109) (Other aliases: ngdc1.ngdc.noaa.gov and online.ngdc.noaa.gov) Logon: anonymous; Password: your e-mail address Path: /paleo or /paleo/pollen LIFE at the Australian National University. ftp life.anu.edu.au (ftp 150.203.38.74) Logon: anonymous; Password: your e-mail address Path: /pub and its subdirectories CALIB (Calibration of 14C Dates) ftp ftp.u.washington.edu (ftp 140.142.56.2) Logon: anonymous; Password: your e-mail address Path: /public/calib Weather Information for selected cities in states: telnet madlab.sprl.umich.edu 3000 Logon/Password: None needed. Type ? for help Geographic Names, location, population, ZIP: telnet martini.eecs.umich.edu 3000 Logon/Password: None needed. Type ? for help TIP from Keith Bennett (after Krol.E. 1992. The Whole Internet. O'Reilly and Associates). On some multi-tasking unix systems typing: get filename - or get filename "| more" will let you browse a text file on line at the ftp site. [Filename - scrolls through the document; use key to stop the scrolling. Filename "| more" shows a screen page at a time. Press key to continue. These techniques work from our unix system, but not if I run telnet (DOS version) from my PC, Ed.] [*p.19 / p.20*] THE YEAR OF THE WEB David G. Green Bioinformatics Facility Research School of Biological Sciences Australian National University GPO Box 4 Canberra 2601 AUSTRALIA E-mail: david.green@anu.edu.au The year 1993 could rightly be called the "year of the Web". Starting as a little known Internet protocol, by year's end the World Wide Web (Green, 1993b) was already beginning to change many scientific institutions. Its importance as a medium of scientific communication is growing so rapidly that anyone concerned with methods of data- handling needs to be aware of the implications. Here I summarize recent developments. Growth. The World Wide Web continues to grow at an exponential rate. At the start of 1993 there were only about a dozen Web servers worldwide, but by June the number had topped 100. By September there were 200 servers and by year's end the number had risen to over 650. The growth in numbers of users followed a similar pattern. For instance, at the start of 1993 my own server (URL=http://life.anu.edu.au/) was transferring only 5000 files per month (Web, Gopher and FTP combined) and Web usage was insignificant. By year's end this total had risen to 100,000 files per month, with Web transactions accounting for over half of the total. New browsing software. Two factors account for the phenomenal growth of the Web. First browsing software (all of it "freeware") is now readily available for all major computing platforms, including Macintosh and DOS/Windows. Secondly, having already been exposed to Gopher, a large academic audience is already attuned to use of the Internet. The best-known browser is the program Mosaic (URL = ftp://ftp.ncsa.uiuc.edu/Mosaic/ ), developed by the US National Centre for Supercomputer Applications (NCSA). The document http://life.anu.edu.au/links/_ syslib.html provides a hypertext list of sources for Web clients and browsers. Authoring tools. One of the problems facing potential authors of hypertext documents for the Web is that documents need to be "marked up" using the Hypertext Markup Language (HTML). Various tools are now available to simplify the markup process. For PC users, for instance, there is a very good set of templates and macros for MS Word that make WYSIWYG editing possible. Details, including many of the tools them- selves, can be obtained from the repository: ftp://life.- anu.edu.au/pub/netkit/. Enhancements to HTML. Recent enhancements to the NCSA's software, both for Web servers and X11 browsers, provide extensions to HTML (Hypertext Markup Language). These greatly enhance the Web's ability to act as a network interface for databases and other programs. For instance: þ The ISMAP construct makes it possible to build graphical menus, such as in geographic information systems. For example, a user could retrieve data sets for different sites by "pointing and clicking" at a map showing the sites (Fig. 1). þ The FORMS syntax makes it possible to turn documents into interactive forms (Fig. 2). That is the user can fill in desired details then click a button to send the customized request to the server. The ARCHIE service (for searching FTP sites) is now available as an interactive "ArchiePlexForm". þ Servers can now run pre-defined scripts or programs and return the results to the user. These (and other) recent enhancements mean that HTML documents can be designed to act as network front-ends to virtually any program or database. This [*p.20 / p.21*] raises an important new option for developers of scientific software: instead of developing an elaborate front-end for each program, use the Web as the interface! Web Navigation. The growth in quantity and variety of information available on the Web has kept pace with the growing number of servers and users. New servers include many national and international bodies that provide data and information of interest, such as the US Geological Survey (USGS): (URL= http://info.er.usgs.gov/). Fortunately facilities for finding relevant information on the Web have kept pace with the growth of information. CERN (URL = http://info.cern.ch/) maintains lists of servers classified by site and by subject. NCSA (URL = http://www.ncsa.uiuc.edu/) provides an on-line, daily newsletter called "What's New on the World Wide Web", which lists interesting new services. Ed Krol's book about the Internet (Krol, 1992 ) is now available on-line from O'Reilly publish- ers, who also provide a service known as the Global Network Navigator. A comprehensive list of these and many other "navigational aids" (including hypertext links direct to the documents concerned) is available in the document http://life.anu.edu.au/education/hypermedia.html. Prospects for 1994. During 1994 we can expect that the Web will continue to grow exponentially and will probably overtake Gopher in numbers of users and servers. The enhancements described above should become available for the PC and Mac users when NCSA release new versions of their browsers. References. Green, D.G. (1993a). Databasing the world. INQUA - Commission for the Study of the Holocene, Working Group on Data-Handling Methods 9, 12- 17. Green, D.G. (1993b). Hypermedia and palaeoenvironmental research. INQUA - Commission for the Study of the Holocene, Working Group on Data-Handling Methods 10, 11-14. Krol, E. (1992). The Whole Internet. O'Reilly and Associates. RADIOCARBON CALIBRATION NEWS Paula Reimer Quaternary Isotope Lab University of Washington Seattle, WA 98195 (206) 543-6327; FAX: (206) 543-3836 Email: pjreimer@u.washington.edu Since the release of the updated version of the radiocarbon calibration program CALIB (Stuiver and Reimer, 1986; Stuiver and Reimer, 1993), I have fielded numerous questions about calibrating radiocarbon ages, some of which have been easy to answer and some of which have prompted revisions of program details. In the following paragraphs I have sketched answers to a few frequently asked questions about CALIB. Also there are some announcements concerning minor revisions to the DOS version, availability of a test version for the MAC, and a French translation of the CALIB manual. Question 1: Why don't the sample numbers scroll on the Sample Selection Menu? Answer: Only the sample ID's scroll to allow sample selection with a single keystroke. [*p.21 / p.22*] Question 2: Why are the results for only the last sample saved to file when sample identifications are long? Answer: If sample ID's are not unique, then the CALIB output file is overwritten by the last sample with that ID. Since only the first 8 characters can be used in making up the file name, long sample ID's that differ only in the ninth and tenth character do not generate unique file names. Question 3: How can I save CALIB plots to import into other programs? Answer: A utility called CAPTURE.COM, which comes with Microsoft WORD 5.0, can be used in place of the DOS GRAPHICS command. After a plot is finished you can press Shift-Print Screen and the plot will be stored in a format that WORD can import. Other programs may come with similar utilities, so check your wordprocessor or graphics software manual. [WordPerfect has a utility called GRAB.COM which is similar, Ed.] Question 4: If a laboratory does not supply a lab error multiplier or give an estimate of the added variance to use with their results, what should one use for increasing the error beyond the counting statistics? Answer: It is nearly impossible to make generalized recommendations for increasing the error in a radiocarbon age beyond that of the counting statistics when the necessary data is not supplied by the laboratory. We refer the user to an interlaboratory comparison (Scott et al.,1992a) which tabulates average laboratory error multipliers (there designated as internal error multipliers) by counting technique and quoted error range. However, use of such an average will reduce precision for the best labs and increase precision for the worst labs. A further intercomparison exercise is being undertaken (Scott et al, 1992b). In suggesting values for additional variance (f[superscr 2]) in the CALIB User's Guide Rev 3.0.3, we misquoted Clark (1975) as recommending values of f= 50 and 60 years for radiocarbon dates of less than 2700 years and greater than 2700 years, respectively. From analysis of variance of replicate measurements on treerings in a number of pre-1975 laboratories, Clark recommended increasing the standard error to 50 years and 95 years for radiocarbon dates less than and greater than 2700 years BP, respectively. However, for many radiocarbon dates in the literature, the quoted standard error is already larger than Clark's recommendation, especially for radiocarbon dates on samples older than the 6000 yr wood used in the study. The added variance option can be used by calculating the f value from sigma[sub t] = (sigma[[sub s][super 2]] + f[super 2]) [super 0.5] where sigma[sub s] is the quoted standard error and sigma[sub t] is the total error. Of course, sigma[sub t] / sigma [sub s] equals the error multiplier which can be entered directly. Announcements Gremlins fixed in CALIB 3.0.3A are: 1. If the cal range changed from BC to AD or if the one þ range was AD and the two þ BC, the labels AD or BC were not changed in the printout except in the summary. The ranges were correct on the plots. 2. If using the additional sample variance option the program asks the user to enter the variance f-squared, but the user should really input the value for f in years. (see the Question 4 above for a change in recommended f values) 3. If only the cal BP print option is used, the labels 1 þ and 2 þ do not appear on the printout of the ranges. 4. In the manual in Table 1 the charges on the carbonate and bicarbonate ions should all be negative instead of positive. The following CALIB programs and files are available on Internet at the ftp site ftp.u.washington.edu (or 140.142.56.2): MacCalib -- contains information about the current MAC test version of CALIB including bug reports and specific directions for obtaining a test copy DOSCalib -- contains information about the current DOS version of CALIB including how to uncompress the program and bug reports CALIB3A.EXE -- this is the compressed DOS CALIB program (rev. 3.0.3A) and necessary files CALIB_FR.EXE -- this compressed file contains the French version of the CALIB manual in WORD format and in RTF format translated by Phillipe Fortin of The [*p.22 / p.23*] Centre de Datation de le Radiocarbone; Universite Claude Bernard Lyon 1; Centre des Sciences et de la Terra U.R.A. CNRS 11; 43, Bd du 11 Novembre 1918; Batiment 217; 69622 Villeurbanne Cedex; France. To access these files ftp ftp.u.washington.edu (or ftp 140.142.56.2). Logon as anonymous using your e-mail address as the password. Change to the CALIB sub-directory (cd /public/calib). Use ls or dir to see what files are on the directory. If you are running ftp from a unix machine, you may (or may not) be able to read the text files Macnews and DOSnews by using the command ftp filename - or ftp filename "| more" but if that does not work, you will need to take a copy to your own site. Set the file transfer type to ASCII for text files or binary for the compressed programs and manual (type ascii or binary). Type get filename. Once you have logged out of ftp session (quit or bye), to extract the program and files from the compressed DOS files simply type the name of the executable (CALIB3A or CALIB_FR). For the MAC version please see the file MACnews for specific unpacking instructions. CALIB users are urged to communicate any problems or questions since user input is extremely valuable to keep the program viable. I can be reached at the address at the head of this article. References. Clark, R.M., 1975, A calibration curve for radiocarbon dates: Antiquity, v XLIX, p 251-266. Scott, E.M., Cook, G.T., Harkness, D.D., Miller, B.F., and Baxter, M.S., 1992a, Further analysis of the international intercomparison study (ICS), Radiocarbon, 34, 520-527. Scott, E.M., Harkness, D.D., Miller, B.F., Cook, G.T., and Baxter, M.S., 1992b, Announcement of a further international intercomparison exercise, Radiocarbon, 34, 520- 527. Stuiver, M., and Reimer, P.J., 1986, A computer program for radiocarbon age calibration, Radiocarbon, 28, 1022-1030. Stuiver, M., and Reimer, P.J., 1993, Extended 14C database and revised CALIB radiocarbon calibration program, Radiocarbon, 35, 215-230. USING THE GLOBAL POSITIONING SYSTEM Louis J. Maher Research sites have geographic positions. We normally find the site on a map, read its geographic coordinates, and make them part of our data. But when the weather is bad, or the site's features are not really unique, a map location can be more tentative than we like to admit. Thirty years ago I remember reading that the U.S. Geol. Survey had fitted out a truck with an inertial guidance system so that field parties could better track themselves in remote areas. It cost many thousands of dollars, required constant attention, and was completely out of reach of an individual. The U.S. Department of Defense (DOD) has nearly completed its Satellite Positioning System (SPS) which uses a couple of dozen satellites that broadcast time and position information. Given the proper radio receiver, one can use the satellite data to determine position and elevation automatically by triangulation. Although the system was put up for military use, the radio waves can be picked up by anyone with the proper equipment. For a number of years now the geophysicists in my department have owned several Magellan Global Positioning System (GPS) receivers. Each cost several thousand US dollars, and I have no doubt that field parties doing research in the Antarctic find them very useful. I once borrowed a unit to use in local coring. But after reading the instruction manual, I soon saw I was not going to get any coring done if I had to run the professional- grade receiver as well. When the Satellite Positioning System was being established, its accuracy of about 25 m was even better than expected. And receivers today are capable of a root-mean-square accuracy of 15 m (50 feet). That is better precision than I can read the position of the black square representing my house on the Madison West 7.5 minute topo sheet. I say "capable" rather than "can" because they can not. The Military began to worry that people could locate things too accurately. It would not do if terrorists could guide their missiles at the Pentagon with 15 m uncertainty! As a result the DOD began applying selective availability (SA) by which a random error is introduced to the SPS ephemeris data code. This "fuzzes" the site location. The error varies but is said rarely to exceed 100 m (300 feet). This may not [*p.23 / p.24*] shield the Pentagon, but it makes hitting any particular general officer more difficult. Selective availability does not affect military receivers, but it does muddy the water for civilians not trusted with the corrective code. Our Antarctic researchers have to occupy their stations long enough to average-out the random fluctuations. Locating a site with an accuracy of 100 m really is not too bad; it amounts to an uncertainty in latitude of about 3 seconds of arc in the part of the world where most of us live. Many companies manufacture GPS receivers, and there are commercial magazines devoted to the subject. GPS navigation is getting to be common for private air and water navigation. I have noted receivers made by Garmin, Trimble, and Magellan are starting to appear for use in private planes; they cost about US$1000 but include databases showing the coordinates of every airfield in the hemisphere with a runway ò to 1000 feet. Those sold to boaters list all the harbor facilities. In fact, the use of GPS for these purposes has caused the U.S. Coast Guard to broadcast signals that can be picked up by special commercial radios to remove the DOD's SA. (Apparently it is felt terrorists will not be able to afford an additional US$1000 for such radios.) The U.S. Coast Guard established a Civil GPS Information Center (GPSIC) for the Department of Transportation. The GPSIC runs a 24-hour computer bulletin board at (703) 313-5910 which provides history, information, and answers to questions. (Set your communications protocol for 8 data bits, 1 stop bit, and no parity; the facility handles a wide range of baud rates.) As a geologist I have been chaffing to get my own GPS receiver for several years. I have been hoping the manufacturers would become interested in hikers, hunters, and fishers so the economy of scale could bring prices down. Last summer at a high school reunion, a fellow classmate mentioned that a "third generation" of GPS receivers was about to be released by Magellan Systems Corp. It would be light and compact, and could, in effect, dynamically track up to 12 satellites for fixes. The unit was expected to retail at US$500 and probably would get cheaper with time. My source said the Magellan "GPS Trailblazer"þ would be targeted for land use and the "Meridian GPS"þ would be aimed at boaters, but they were identical inside the case and I should look for the one with the best price. The units were introduced near the end of the year, and--not wanting to appear too interested--I ordered a Magellan Meridian GPS as soon as I found a source. And much to my wife's disgust, I might add, paid the full US$500 retail price. I also put up an additional US$70 for the optional kit that includes a data cable, a coaxial cable to extend the unit's antenna, a suction cup to hold the antenna, a bracket to hold the unit, and a cable to plug into a automobile cigarette lighter for external power. The receiver is 15.5 x 10.5 x 3 cm and weighs 424 g including its 3 AA batteries that provide 4 hours continuous service. It comes with a carrying case that can be worn over the shoulder or attached to a belt. I supply the company's name and address in case you would like to inquire about a nearby source: Magellan Systems Corporation, 960 Overland Court, San Dimas, CA 91773; Tel. (909) 394- 5000, FAX (909)394-7050. I think a lot of us, individually or institutionally, can put GPS receivers to good scientific use. They are self-contained and work anywhere in the world. I do not necessarily recommend Magellan over other makers, but I will describe the Meridian as it is the unit with which I have experience. The Meridian GPS displays geographic coordinates either as UTM or Lat/Lon. North can be true or magnetic. Time (which is read from the satellites' atomic clocks) can be displayed as Universal Coordinated Time (UTC, the old Greenwich Mean Time or Zulu), 24-hour local, or local a.m./p.m. Any of eleven global or regional spheroid datums can be used. Positions (2D or 3D) can be expressed as degrees-minute- second or degrees-decimal minutes with elevation in feet or meters. Distance can be nautical miles/knots, statute miles/mph or kilo- meters/kph. The positions of 100 sites can be stored in memory. A programmable navigation route of up to 15 legs can be set up. One can backtrack over a route, and there is a provision for setting a MOB (Man Overboard) position that can be returned to. If the user is moving more than 2 mph the unit displays speed over the ground, course over the ground, bearing to the next way-point, distance to go, time to go, estimated time of arrival, steering direction, cross-track error, and velocity made good (the component of the velocity along the track to the next way-point). If the receiver is stationary with an established fix, bearing and distance can be shown to the other sites in memory. No matter what make of receiver you choose, be sure it has a connection so that it can be attached to a computer. That way you can record position fixes on a laptop for an extended period and average out the [*p.24 / p.25*] random fuzz the DOD adds to the signal. You can also record your vehicle's position if you are reconnoitering your field area. This is very useful if you are taking photographs from a light plane, especially if you can add a comment to the data file that indicates what you are seeing at the time. GPS receivers generally do not work in metal buildings or vehicles without an external antenna. The Meridian's antenna can be easily removed and attached to the end of the coaxial cable previously mentioned. The receiver will function in a metal airplane if the antenna is placed inside the plane's plastic windshield with a good view of the sky. Fig. 1 (left) illustrates the antenna holder I made which slips over the edge of a glass car window. When the window is closed the antenna should project above the roof-line. The hook for the window can be thin steel or aluminum. The light-weight U-channel rod has several metal "tabs" cut at its upper end. The tabs are bent to support a section of plastic tubing big enough to hold the antenna unit. If the plastic tube is cut longitudinally on the side away from the support rod, it forms a spring-like clamp and also allows exit space for the antenna cable. The wires from the receiver's data cable are very fine and should be treated with care. Lee Powell, the Department's Electrical Engineer, suggested that I get a small box to which the outer insulation of the data, power, and computer wires could be firmly attached. The fragile leads could be then be protected inside the box. I was able to buy an inexpensive 3 x 2 x 1-inch "project case" and a 6-position "dual barrier strip" from Radio Shack, a retail electronics supplier. Powell worked out the connections shown in Fig. 1 (right). The Magellan Trailblazer and Meridian have a socket for NMEA data output (as do receivers from other makers). NMEA is a communications standard for electronic marine navigation equipment, and is often used to control automatic pilots and "moving map" displays. The Magellan units output ASCII data (4800 baud, 7 data bits, 1 stop bit, even parity) in NMEA 0183 format which can be obtained in three versions: 0183A, 0183B, or 0183C. Data are issued as a continuous sequence of text lines that are cycled through every few seconds. The values provide information about time, position, directions and velocity; obviously if you are standing still, you will see many zeros. I wrote a QuickBASIC or QBASIC program (QBASIC comes with DOS ò 5) that allows my computer to record time and position from format 0183C. I call the program GPS.BAS, and the following information is contained in its help page: [*p.25 / p.26*] The GPS satellite receiver must have its data cable attached, and it must have acquired a position fix before being attached to the computer's serial input (COM1|COM2) port. Press the receiver's Aux/Setup key and select Aux Menu. Cycle through the menu with the receiver's up/down keys. Select NMEA. Set the NMEA type to 0183C. That format sends in sequence the data packets GLL, APB, GGA, VTG, and BWC. GPS.BAS searches out and reads the packet GLL which includes a header, latitude, longitude, time (UTC), and a terminal "A" if the data quality is good. Format 0183c example: $GPGLL,ddmm.mmm,N,dddmm.mmm,W,hhmmss.sss,A [Header Lat |S Long |E Time UTC A=quality] i.e. $GPGLL,4305.659,N,08929.313,W,184017.224,A 43 deg 089 deg 18 hours [UTC] 05.659 min 29.313 min 40 min N W 17.224 sec You will be asked for a filename (*.GPS) to record the data, and also the number of minutes you want to elapse between data samples; if you choose "0" the data will be acquired continually (ca. every 3 seconds). If you stop recording and then want to add more data later, use the same filename, and the new data will be appended at the end of the file. To conserve a laptop computer's battery, consider saving the data to a RAM drive; likewise consider not showing data on the screen. This may allow the computer to shut down unused components. If one records the data continuously, more than one thousand lines of numbers will accumulate each hour. That provides more data to average (good), but if the data are recorded faster than the SA fuzz is varied, some of the recorded data will be redundant (bad). I tend to take a record every half minute. That gives me 120 data points per hour during which time many different satellites have passed overhead. When recording is going on, GPS.BAS's screen states that touching the key will allow one to insert a comment line in the data stream. An initial single apostrophe is automatically prefixed to the line, which the program later ignores as a comment. When the key is touched at the end of the comment, data recording continues. At the end of the recording session touching the key closes the file and returns the program to the main menu. The position and time data are converted to decimal hours and degrees before they are recorded. The usual convention is followed that southern hemisphere latitudes and western hemisphere longitudes are considered negative. An example fragment from file HOM16JAN.GPS follows: 'Started in heated van on driveway of '2129 Gateway on 16 Jan 94. 'Interval=0.5 min. Outside temp = -24 C 'Extension cord for heat and power. ' UTC Latitude Longitude Local ' Hours Degrees Degrees Hours 18.005497 +43.093917 -89.488350 12.0055 18.014534 +43.094117 -89.488300 12.0145 18.023460 +43.094183 -89.488417 12.0235 18.032381 +43.094233 -89.488400 12.0324 18.041018 +43.094233 -89.488400 12.0410 ... The main menu has an option for averaging the positional data in a *.GPS file. File HOM16JAN.GPS accumulated about 108 lines per hour. During one interval the receiver reported satellite orientation was causing problems with triangulation, and the 11 lines recorded during that period were later "commented out." Fig. 2 shows the results. The mean position was computed as: 43ø5'48.064" N, 89ø29'18.316" W. But how good is the estimate? The standard deviation of both latitude and longitude in Fig. 2 is about 1 second of arc. At this position on the earth a second of latitude is equal to 30.85 m and a second of longitude equals 22.6 m. (If you want to know how I got these bits of trivia, check the following article about GEODESIC.BAS; you can accurately solve for the number of meters between two adjacent degrees of lat/long anywhere on earth and divide by 3600.) Assuming a normal distribution, multiplying the standard deviation by 2 lets us infer that roughly 95 percent of the recorded positions will fall within a box 123 m north/south by 90 m east/west, centered on the mean posi- tion. [*p.26 / p.27*] To digress for a moment, recall that the Military wants to fuzz the data to keep the limit of resolution at about 100 m. Fig. 3 shows the 6 hours of actual data plotted on a rectangle 200 meters square; that is, the sides are 100 m from the center where I think I am. Most of the data points are within 100 m of the mean; at any one of them there is a reasonable expectation that my driveway is somewhere within 100 m. The variance of the recorded data is in good part controlled by the Military, and can be changed by them. Therefore to get a better handle on the possible variability of the mean, when GPS.BAS reads the data file, each position record is placed randomly into one of four bins, and a separate mean is computed for each bin. These values will differ somewhat each time the program runs because each time different samples will be assigned to the bins. Finally, the mean and standard deviation of the four group means is calculated, and this tends to be more interesting. Note in Fig. 2 that the standard deviation of the 4 latitude means and the 4 longitude means is roughly 0.1 second of arc. Using the same reasoning as before, we may expect most of the means to fit within a box 12 m north/south by 9 m east/west, centered on the mean position. That suggests the latitude estimate is good to ñ 6 m (ñ 20 feet) and the longitude estimate may vary ñ 4.5 m (ñ 15 feet). Now that kind of resolution is not bad for 6 hours of easy work. (In case any would-be terrorists plan to use this location to bomb my house, I remind them that the position was measured on the driveway; I do not report how the house is situated with respect to the drive.) The reader may rightly believe, however, that 6 hours is too long to have to wait to get a fix on every site we might wish to locate. I have gone through the file HOM16JAN.GPS and broken it into six sub-files each one hour in length, several files of two-hour length, and a couple of three-hour length. When the data collection extended over at least one-hour blocks of time (with positions recorded twice a minute), the samples' Mean positions were always within 15 m (50 ft) of the Grand Mean Position established by the 6-hour record. That is to say, about of hour's recording will regain at least the SPS accuracy which would exist without the effect of selective availability. The Meridian can be set to turn on every ten minutes, establish a fix (if left in a position with a good view of the sky), record it, and then turn off. The unit retains the last 15 fixes in its memory, so a user can get 15 fixes over 2.5 hours. I culled two such records from the 6-hour data. Using this method, one averages over a longer time, but on much less data. The means of both synthesized samples happened to fall within 15 m of the grand mean, but I would use the procedure as a last resort. It is generally wise to plot a *.GPS record to see whether it looks as random as you hope. For that reason, I wrote a display program called GPS-PLOT.BAS which lets you set up a map centered on a specified lat/lon position. You also specify the N/S extent of the map (in deg, min, sec) and the E/W extent (in deg, min, sec). In this way, one can vary the latitude and longitude dimensions to plot an area of a specific number of meters (see Fig. 3). GPS-PLOT then reads a *.GPS file and plots the points on an VGA screen. You can keep the points on the screen or remove each shortly after it appears. The points plot as white on a black background. When the data are in, the four group means plot as yellow pixels, and the mean of the four means in shown in red. Finally, the [*p.27 / p.28*] mean of the whole sample is plotted as a green pixel. If the red and green pixels are superimposed, only the green will show. I have used GPS-PLOT to record my route to work. One approximates the center of the Madison West sheet and gives the Lat/Lon breadths as 0,7,30 to show the whole sheet. You can get a feel for stoplights by the spacing of the dots. As might be expected, the sample means will be displaced between home and the office. I have placed GPS.BAS, GPS-PLOT.BAS, and some sample *.GPS data files in a self-extracting file called GPSZ.EXE. It is available for anonymous ftp in the directory /pub/inqua at geology.wisc.edu. Let me know if you find it useful or if you have questions. GEODESICS FOR FUN AND PROFIT Louis J. Maher There is an aphorism that no place of interest ever seems to fall on a single map. When we try to compare sites in distance places we are confronted with the fact a flat map but dimly reflects the spheroidal globe. And for that matter, the spheroidal globe is but a simplification of the earth's lumpy oblate ellipsoidal geoid. About ten years ago, John Schneider, then one of our geophysics graduate students, let me try to translate a geodesics program he had written in FORTRAN. Schneider had built his program on the work of Sodano and Robinson, 1963, and I was delighted when I got it to work in BASIC on small home computers. I ran the program recently when I needed to get some information about a pollen site I was working on in Wisconsin. It seemed like a good time to clean up the old BASIC version with its tangled numbered lines and try to get it into a more structured form that would work with QBASIC (part of DOS ò 5). It is one of those programs that you may very rarely use, but if you need it, it is very useful. GEODESIC.BAS allows you to determine quite accurately the shortest distance (km, statute miles, nautical miles) between any two places on earth that are separated by more then 10 km. It will also tell you the azimuth direction from the first point to the second, as well as the back azimuth from the second to the first. You can choose any one of five first-order ellipsoidal models of the earth as defined by the Major Radius and Flattening, but the one offered as the default will do unless you are working in cm. You can choose whether you want to specify the two sites as Degree/Minute/Second, or Degree/Decimal Minute or as Decimal Degree. The hemisphere designation is N, S, E, or W; upper or lower case is not important. Here is an example of how GEODESIC can help when one has two sites in different countries, and the available maps' scales and projections do not match. I was looking at the pollen at a site at Valders in eastern Wisconsin situated on the Niagara escarpment (44ø 5' N, 87ø 53' W). The sediments apparently are ponded interstadial outwash which contains enough leaves to date (13K BP). While doing the palynology, several grains of Aquilapollenites were noted, apparently derived from Cretaceous sediments the glacier had entrained on its way to Wisconsin. The only Cretaceous sediments reasonably placed north of the site are some patches mapped along the Missinaibi and Abitibi Rivers to the SW of James Bay at the south end of Hudson Bay. The sites from a small scale map of Canada are centered approximately at 50ø 30' N, 82ø 0' W. GEODESIC.BAS computes that this nearest-known Cretaceous sediment lies 840 km from Valders on an azimuth of 29.8 degrees. The Door County peninsula--part of the Niagara escarpment which guides the local flow- -points to it like an arrow: N 30ø E. Many of those getting this newsletter will be going to the next INQUA in Berlin. Here is a trivia question that you can use GEODESIC.BAS to answer. Say you are at Chicago (41ø 50' N, 87ø 40' W) and you wish to point your finger toward Berlin (52ø 30' N, 13ø 25' E). The great- circle route is 7,111 km, and you would point to an azimuth of 41.77ø. (The back azimuth from Berlin is 305.43ø.) Now if you wished to point to London (51ø 30' N, 0ø 7' W) from Chicago, would the azimuth be greater or less than to Berlin? Unless you are an airline pilot you are likely to miss this question. Most of us are conditioned by Mercator maps and know London is located to the left of Berlin. We tend to forget that Berlin is further on around the curvature of the earth so that the great-circle route from Chicago to London lies to the east of that to Berlin. (London is 6377.4 km from Chicago at an azimuth of 47.75ø; back azimuth is 297.70ø). [*p.28 / p.29*] I have put a copy of GEODESIC.BAS in the INQUA boutique at geology.wisc.edu. It is in a self-extracting file called GEODESZ.EXE. I hope you find this program as helpful as I have. But there are a couple of points to remember. Do not use it when the two points are separated by less than, say, 16 km (10 mi). At that range the GEODE- SIC solution will be less than 1 per cent high, and it is much less farther away. If you try to solve distances separated by 3.5 km, the GEODESIC solution will be about 12 per cent greater than the true distance. In fact, if you use the same coordinates for both sites, the program will state they are separated by 2.2 km! This has to do with the accuracy of trig functions at angles approaching zero. Sodano, E.M., and Robinson, T.A. 1963. Direct and Inverse Solutions of Geodesics. Army Map Service Technical Report #7 (Revised), 42 p. The program utilizes the Sodano and Robinson direct solution of geodesics described in Section 3, p. 15. (Terms are given to order eccentricity to the 4th power.) MACPOLLEN A colleague recently left me a note attached to Report No. 3 of the Byrd Polar Research Center at Ohio State University. The report is a manual for using MacPollen (Eisner, 1993; Eisner and Sprague, 1987). I reproduce the abstract in case Macintosh users may be interested: A program is presented that can be run on most Macintosh computers. This program permits the drawing of pollen diagrams in a standard format. Pollen percentage diagrams and pollen concentration options are available within this program. The diagrams can be drawn in PICT format and transferred to various current drawing programs, where they can be enhanced to produce publication-quality pollen diagrams. No price was mentioned, but for further information about obtaining this program, contact Dr. Eisner at the Byrd Polar Research Center, Ohio State University, 1090 Carmack Road, Columbus, Ohio 43210-1398, Tel: (614) 292-6715. Reference. Eisner, W.R. and Sprague, A.P. 1987. Pollen counting on the microcomputer. Pollen et Spores, 24:461-470. Eisner, Wendy R. 1993. Using Macpollen: A Computer Guide. BPRC Report No. 3, Byrd Polar Research Center, The Ohio State University, Columbus, Ohio, 17 p. E-MAIL ADDRESSES (I use the term in the general sense; it includes those on Internet, NSFNet, Janet, Bitnet, etc. A line ending with a trailing low dash [ _ ] indicates the address continues without a space on the line below.) David Adam dadam@mojave.wr.usgs.gov Jim Almendinger jdinger@vz.cis.umn.edu Brigitta Ammann ammann@sgi.unibe.ch David Anderson danderso@sog1.geog.ox.ac.uk Kathy Anderson kathya@brownvm.bitnet Pat Anderson pander@u.washington.edu John Andrews andrews_jt@cubldr.colorado.edu Carlos A. Baied gg_cab@selway.umt.edu Dick Baker dick-baker@uiowa.edu Philip Barker p.a.barker@lut.ac.uk Pat Bartlein bartlein@oregon.uoregon.edu bartlein@oregon.bitnet Rick Battarbee ucfamar@ucl.ac.uk Alwynne Beaudoin userasa5@mts.ucs.ualberta.ca Pat Behling pbehling@vms.macc.wisc.edu [*p.29 / p.30*] Keith Bennett kdb2@cus.cam.ac.uk Bj”rn E. Berglund bjorn.berglund@geol.lu.se John Birks birks@cc.uib.no R. Bonnefille azerty@frmop11.bitnet Richard Bradshaw richard.bradshaw@ess.slu.se Julia Branson jb4@soton.ac.uk John Brew J.Brew@vax.rhbnc.ac.uk Linda Brubaker lbru@u.washington.edu Dave Bulman dbulman@arts.cc.monash.edu.au Ian D. Campbell icampbell@nofc.forestry.ca Don Charles charles@say.acnatsci.org Gail Chmura chmura@mgm.lan.mcgill.ca Malcolm Clark rmc@monu1.cc.monash.edu.au Brian Cumming cummi006@maroon.tc.umn.edu Ed Cushing cushing@vx.cis.umn.edu Les Cwynar cwynar@unb.bitnet Owen Davis palynolo@vms.ccit.arizona.edu Walter Doerfler guf12@rz.uni-kiel.dbp.de Kevin J. Edwards edwardkj@ibm3090.bham.ac.uk Mary E. Edwards ffmee@alaska.bitnet Scott Elias elias_s@cubldr.colorado.edu Dan Engstrom dre@umnacvx.bitnet John Flenley j.flenley@massey.ac.nz Jesse Ford fordj@ucs.orst.edu David R. Foster dfoster@lternet.washington.edu dfoster@lternet.bitnet Marie-Jos Gaillard mjgl@gemini.ldc.lu.se Konrad Gajewski gajewski@acadvm1.uottawa.ca Lisa Graumlich graumlich@ccit.arizona.edu David Green david.green@anu.edu.au Eric Grimm grimm@denr1.igis.uiuc.edu Elisabeth Gr”nlund mg@joyl.joensuu.fi Joel Guiot j.guiot@frmop11.cnusc.fr lbhp@frmrs11.bitnet Margret Hallsdottir mh@rhi.hi.is Sandy Harrison lakes@planteco.lu.se Linda and Cal Heusser heusser@acf1.nyu.edu Sheila Hicks hicks%oygeol@figbox.funet.fi Richard A. Hodkinson umfbco5@vaxa.cc.imperial.ac.uk Geoff Hope gxh411@coombs.anu.edu.au Brian Huntley brian.huntley@durham.ac.uk Tristram C. Hussey io10651@maine.maine.edu George L. Jacobson Jr. and Heather Almquist-Jacobson jacobson@maine.edu Jan A. Janssens janss001@staff.tc.umn.edu Peter J. Jaumann pjjauman@umaxc.weeg.uiowa.edu Devra I. Jarvis djarvis@mukla.gn.apc.org Steve Juggins sjuggins@geog.ucl.ac.uk Peter Kershaw pkershaw@arts.cc.monash.edu.au John C. Kingston johnk@morgan.ucs.mun.ca Warren Kovach warrenk@cix.compulink.co.uk 100016.2265@compuserve.com John Kutzbach jkutzbach@vms.macc.wisc.edu Henry Lamb hfl@aberystwyth.ac.uk Bill Last mlast@ccm.umanitoba.ca [*p.30 / p.31*] Inigo Lentner lentner@rs1.rz.uni-hohenheim.de Dan Livingstone daltuc@tucc.bitnet Andre Lotter lotter@eawag.ch Ruud Lutgerink lutgernk@let.rug.nl Glen MacDonald gmmacd@mcmaster.ca Joyce Macpherson jmacphers@kean.ucs.mun.ca Darrel Maddy d.maddy@mail.soton.ac.uk Louis J. Maher, Jr. maher@geology.wisc.edu Vera Markgraf markgraf_v@cubldr.colorado.edu John V. Matthews matthews@cc2smtp.emr.ca John H. McAndrews docjock@utcs.utoronto.ca Bob McCulloch rdm@geovax.edinburgh.ac.uk Matt McGlone mcglonem@lan.lincoln.cri.nz Peter Minchin minchin@ariel.unimelb.edu.au Fraser Mitchell fmitchll@vax1.tcd.ie Alan Morgan fossil@sciborg.uwaterloo.ca Robert J. Mott rjmott@emr.ca Dave Murray ffdfm@aurora.alaska.edu Dana L. Naldrett naldret@ccu.umanitoba.ca Robert E. Nelson renelson@colby.edu Bent Odgaard bo@dgu1.dgu.min.dk Jonathan Overpeck j.overpeck@omnet.nasa.gov jto@mail.ngdc.noaa.gov Marlow Pellatt mpellatt@sfu.ca Stephen C. Porter scporter@u.washington.edu Colin Prentice colin@planteco.lu.se Paula Reimer pjreimer@u.washington.edu P.J.H. Richard richard@ere.umontreal.ca Jim Ritchie jcr@aberystwyth.ac.uk Charlie Schweger cschwege@gpu.srv.ualberta.ca George Smith smithg@lawrence.edu John Smol smolj@qucdn.queensu.ca Allen Solomon solomon@heart.cor.epa.gov Tony Stevenson tony.stevenson@newcastle.ac.uk Eugene F. Stoermer eugene.f.stoermer@ub.cc.umich.edu Alayne Street-Perrott geog2@oxford.vax1.ac.uk Rachel R. Summers s.r.summers@massey.ac.nz P. Roger Sweets sweets@ucs.indiana.edu Julian Szeicz g8726047@mcmail.cis.mcmaster.ca Robert Thompson rthompso@usgsresv.bitnet W. J. Treloar w.j.treloar@massey.ac.nz Guus van der Geer gvdgeer@postoffice.utas.edu.au Adam Walanus polslask@plwrtu11.bitnet Ian R. Walker iwalker@admin.okanagan.bc.ca Jerome Ward wardjer@ducvax.auburn.edu Robert S. Webb rsw@mail.ngdc.noaa.gov Tom Webb thompson_webb_iii@brown.edu Mina Weinstein-Evron mrect36@haifauvm.bitnet Cathy Whitlock whitlock@oregon.uoregon.edu Kathy Willis kjw11@phx.cam.ac.uk Janet Wilmshurst zool142@csc.canterbury.ac.nz Marge Winkler mwinkler@vms.macc.wisc.edu [*p.31 / p.32*] Sergei B. Yazvenko yazvenko@watserv1.uwaterloo.ca Zicheng Yu yuzi@utcc.utoronto.ca Mingming Zhou zhouming@acf9.nyu.edu If you wish to be added to the directory, or to correct your present entry, please e-mail to: maher@geology.wisc.edu