Depth & Length Measurements - Andy Waddington

Details of UIS definitions on cave size measurements

Producing finished surveys on your computer - Juan Corrin

Example of going from initial skeleton plot to completed survey using !Draw on the Archimedes
(Not included in the Web version yet)

CavePlot Software released - Dave Herron

New Shareware Mac software package

Australian Surveying Commission & CADD Standards - Ken Grimes

The work of the Australian Surveying & Mapping Standards Commission, and discussion of the effects that CADD will have on cave survey record keeping.

Cave Mapping Software - John Fogarty

Discussion of the problem of large survey projects and the software solutions in progress


As you can see from the growing size of this publication there is plenty of interest in surveying matters around the world. I would like to include some actual surveys in the magazine to pretty it up, so anyone who would like to see their work published please send me your surveys.

Coming soon:

More research on how your gear affects your compass

Texas Speleological Society Cave Surveying Workshop

Important developments in the HTO transfer standard.

GPS in cave surveying.


Arthur Butcher Survey Award

This year's award went to Steve Neads for his work producing the Box Mines survey, including his SURVEY cave surveying software. Congratulations are due to him for this excellent survey.

Cave Surveying Mailing List

Olly Betts <>

I've set up a cave surveying mailing list. I intend it to be for discussion of all things to do with cave surveying, not just HTO.

Currently it's unmoderated and not digested (i.e. you get each message separately, rather than in a chunk like the cavers forum). The software running the list has more configuration options than I have time to read the documentation for, so most things can be changed if the need arises. I've chosen unmoderated and not digested as I think this will help speed up discussions. Comments and complaints are welcome, but I reserve the right to do as I damn well please.

Submissions are archived for posterity. If the archives become sizeable, I'll probably start shipping them to gserv1 or somewhere.

Anyway, you'll get subscribed automatically if you send a message to the mailing list. If you wish to subscribe without submitting anything, then send a mail message to:

with a message body containing the line: subscribe

Submissions should be sent to:

cave-surveying-request can also do other weird and wonderful things. Send a message with "help" in the body to find out more. Anyone sending requests to the submission address will be laughed at behind his/her back. Remember, requests go to the -request address.

BCRA Conference - Speleo Computing session


The Speleo Computing Session at this year's BCRA conference was very well attended and lively. The talks that took place were a floor discussion on data archiving, Olly Betts demonstrating SURVEX, Mark Dougherty on Altimeter Surveying, and John Wilcock on the UIS Karst Database project.

Wookey opened the discussion on data archiving, bringing up points about the way that data gets lost over the years as surveyors move on or die. This is a problem for long-term projects in many areas. It is also true that many with an interest in cave surveys, adding new finds to old surveys, or the history of surveying techniques would like to have the original survey data kept as well as the final drawn-up survey. The current work towards defining a survey data transfer standard means that it should soon be possible to keep all the numerical & textual info recorded on a survey trip in a standard format.

He also asked whether today's surveyors were prepared to put their hard-won data in any sort of central repository, and if so what restrictions might be necessary to encourage this, whilst protecting sensitive data.

This discussion was lively and productive, with many people expressing an opinion. An important point made by several people was that there was not much point recording the survey data without the original sketches, and that by far the easiest way to do that was simply to keep the original pieces of paper, or photocopies of them. This led on to the view that this was not really a computing problem, but simply one of archiving and data collection. Most of those represented were of the opinion that setting up some sort of survey data repository was a worthwhile activity, and also that most surveyors would be willing to contribute their work.

It was stated that whilst surveyors would generally be willing to hand over their data, there would tend to be a period after discovering something new when they would want to keep it quiet. And once the survey was drawn up then they might just forget about the whole thing. The difficulty would be getting the data copied and passed to the archive at some point while the project was still active. This was suggested to be a case of advertising the archive's existence, and having a archivist who hassled surveyors for info in a timely manner.

No decisions were made about how to progress from this discussion to actual implementation ideas. Anyone want to be an archivist? This is perhaps a mater of BCRA council to discuss, and certainly a matter for discussion in the pages of this journal.

Olly's demo of Survex was generally well-received, although there were some mirth at the sluggishness of the software which was later traced to the fact that the copy he was running was a test version generating reams of debugging info. (The joys of demoing something on your development machine). The cave-viewer was liked for its raw speed & ease of control. This short demo led on to a number of questions from the floor generally of the form 'Can it do such & such?', to which the answer was usually a qualified 'Yes'. The author appreciated the feedback on which features people actually wanted to see, and a number of the audience took away copies, having satisfied themselves that it did what they wanted. Olly also demonstrated his experimental software which stretches a bitmapped or vectorized sketch of the cave walls around a set of fixed points (the survey stations) as those stations move (with loop closure, for example).

There were a number of other software packages available for people to try out but unfortunately there was not enough time to look at them.

Dave Irwin gave the background to the UIS Karst database project - a plan that each country should keep its own database of karst sites, in such a way that data can be exchanged between them usefully, even though the regional databases may be different. John Wilcock, who is responsible for the preliminary plans for the UK, went into detail about the desired features of the database. He stressed the content of the database, as opposed to the technicalities of implementation, arguing for a system where all the fields were textual so that it could be implementation independent, and thus used on a wide range of software and hardware. He then went on to describe the vital information, without which an entry could not occur (name, location, etc.), and the extensive secondary information which could be added (history, rigging guide, cave description, etc. ).

The discussion then went out to the floor, where a number of questions were raised about the grand scale of the project, and the issues such as the difficulties of searching on textual data, where, for example, place names can be spelt differently and thus searches to miss entries, where there is no unique identifier corresponding to a particular name. Despite these reservations the audience were impressed by the progress made so far.

Mark Dougherty only just made it after several hours in the dentist's chair that morning. He presented the background to the use of altimeters in cave surveying, and expounded upon some of the difficulties associated with the technique. He will be presenting his results when his experiments are complete. Altimeters have along history of use in caving, and now that small, cheap models are available with automatic temperature and humidity correction it is worth examining what part they can play in cave and surface surveying. There are a number of factors which complicate the basic principle of measuring the change in pressure which occurs with changes in height. Some of these can be corrected for internally (such as the temperature), but others require a second reference instrument for useful results. The most significant are changes in pressure due to the weather which can otherwise swamp the changes you are trying to measure. This 'reference instrument' system works well so long as the two instruments are within the same pressure system. The problem is that for any cave other than simple ones with one entrance then the 'outside' and 'inside' altimeters are not necessarily in the same pressure system. More work needs to be done an the theoretical and practical aspects of this. The talk was clear and informative.

First Caveman(TM) delivered

Chris Stuttle

Following successful trials, Analysis Geotech Ltd have delivered their first Caveman Cavern Surveying System to BLM Mincom of Canada. A second is due shortly for delivery to a Chilean company.

The Caveman System, a laser based 'total station', can be deployed into active or abandoned mine workings either through a borehole of as little as 120mm diameter or by means of a boom extended into the stope. Once inside the workings the system is capable of surveying these areas to centimetre accuracy if desired. Volumes, tonnages sections and 3D views can be generated by computer within minutes of completing the survey.

Whilst the primary use for the system will be monitoring of stop dilution other uses include ore pass wear surveys, vertical retreat stope and face advance volumetric calculations as well as shaft deformation surveys.

(From Caves & Caving, Spring 1994)

The Rapid Cave Survey Notebook - review


This is a handy solution to the perennial problem of taking notes whilst surveying in the cave. It is a 42-page booklet, totally waterproof throughout, designed by Trevor Faulkner. Each page has a staggered grid on the left side for data, and a 'graph-paper' style grid on the right hand side.

The back cover contains most of the common BCRA Recommended symbols for drawing, and the front cover gives instructions for doing a rapid grade 3 survey, as well as somewhere to write your name in case you lose it.

The data page has spaces for Station, Left, Right, Up, Down, and then staggered leg data, Distance, Bearing, Vertical angle, and Vertical range. There are also spaces marked: Cave, Date, and Who. There is enough space for 588 legs in the whole book, although the idea is that you remove pages from the middle and use them individually.

Generally this is a well-thought out tool, but despite this I have not found it as convenient as I had hoped in use. I have used it primarily on expedition in Austria, and also surveying in OFD. Its biggest strength is its total waterproofness, but the downside of this is that the 'paper' is very smooth and it is easy to wash or rub off your data. It may be possible to reduce this problem by using something other than pencil for writing, but sketching with anything that doesn't rub out is almost impossible. Unless you are going to get absolutely soaked as you survey, then I have found that 'rag paper' is a much better compromise between weaterproofness and ease of use. This stuff behaves exactly like paper when taking marks, but is very tough, and can get pretty wet before it starts to suffer. Rag paper is also cheaper, but only comes in plain, lined or gridded.

My other problem with the rapid notebook is that I found myself fighting somewhat against its other main advantage - the pre-set out areas. Obviously this is only an advantage if it fits the way you survey - I found that it didn't really. The station, LRUD & leg areas are fine in themselves, but I found the surrounding areas for filling in other stuff such as calibration, surveyors names, dates, instrument IDs etc. far too small, and was discouraged from just writing it in anywhere by the very bright pink ink, which makes things written over the lines hard to read. lighter printing would fix this. More irritating than that was that I use a small (about a6) aluminium clip-board with a bulldog clip at the top. The pages were slightly too big for this, and the left/right arrangement of the data & grid pages meant that I couldn't easily have a data page and a gridded page as consecutive sheets. You had to have two of one and then two of the other, as the intended other half of the page just opened out off the edge of the clip-pad where it was useless. This problem can easily be dealt with by cutting the sheets in half , but on the instance I tried I didn't have a knife with me, and found the paper to be completely untearable.

I don't mean to imply from the above that I don't think this a worthwhile product, but I personally prefer the rag paper surface, and blank or lightly gridded sheets which I can use for sketching or data as I feel like. I don't feel that the pre-set out page is useful enough to outweigh its inflexibility. If it suits your surveying style then it is a very handy item.

The rapid cave survey notebook is available from Inglesport and Bat Products


A file containing all the survey data for Lechuguilla was posted to the cavers archive. This prompted a discussion as to whether this should be permitted, whether the poster had the right, and whether it was a 'good thing' or not.

Olly Betts

Obviously people have the right to keep data to themselves. I think this is actually not in their best interests in general, but please don't misunderstand me on this point.

From the point of view of writing cave surveying software, having lots of large complicated data sets available is invaluable. It should also help to drive the implementation of data transfer standards and software. I had intended to download the Lech data to play with, and I'm mildly irritated that politics has got in the way again.

The more data you can run through your software, the better the chances of catching bugs and missing features. For example, Iain Miller's OFD resurvey has been a major driving factor in implementing and testing Survex's capabilities to handle large looped survey networks.

This also works the other way: The more people who look at and fiddle with your data, the more likely mistakes are to be spotted.

To show I'm willing to put my data where my mouth is, the data for the caves Kaninchenhohle (somewhat out of data now) and Puffball has been included in Survex releases since very early on. Andy Waddington, Wookey, and I have now managed to link together all the CUCC Austria data which we know the whereabouts of, except for an "invented from the map" link, which I hope to replace with an Austrian theodolite fix if I can find which of the Austrians has the theodolite data :( I'll tidy it up and upload it to the archive sometime soon.

In trying to assemble all the Austria data, we found that some of the older data has either been lost completely, or is kicking about it ex-CUCC people's lofts and garages -- this of course wouldn't be a problem if the data was on an ftp site. We know data of some sort must have existed, as we have drawn up surveys of the caves, but that's not much help.

By not publishing the data you are only making the job of those who want to survey extensions in the future harder. Iain Miller would be grateful to have the original data for the OFD survey. Although it's believed to not be of a very high general quality, it would save him having to resurvey every nook and cranny. But the data disappeared with the original surveyors. I'm sure this is all too common.

This might set an unwanted precedent. (i.e. Mammoth, Wind, or Jewel, caves.)

I have a file on my hard disk called ROTUNDA.3D which is a SURVEX .3d format output file produced by CML. It is part of Mammoth. Seems like that dataset is out already. Mind you, it's only the centre-line, so it conveys less information than a paper survey would.

Which brings me to my last point (I can hear the sighs of relief). If paper surveys are available (as I believe they are for Lech -- I think I've seen a survey of sorts in National Geographic anyway), then what more information does the data contain which needs to be kept secret?

What would happen if the most dangerous and despicable person got the data? Nothing at all.

The 'free access' of this cave's data is a 'good thing'.

Earliest surviving cave survey data

Donald G. Davis

In trying to define parameters for an update of the COMPASS survey program, Larry Fish recently asked me how many years back I thought cave survey data might date. I opined that the earliest caver-done surveys in the U.S. would probably have been from the early NSS in the 1940s. Government and commercial surveys were earlier: copies exist of maps of Cave of the Winds, Colorado, from 1910, and of its sister cave Manitou Grand Caverns from the 1880s. Maps by the Wheeler Survey of Cave Valley Cave, Nevada from 1869, and Fort Stanton Cave, New Mexico from 1877, are known (these are the earliest known caves in the western U.S. to be surveyed). I think there are maps of Mammoth Cave from the first half of the 1800s. There are probably many other maps predating organised caving.

However, I am not aware that the survey data used to generate any of these maps are still in existence. Does anyone know what might be the earliest surviving set of raw survey data?

Length & Depth Measurements Q&A

Andy Waddington

Seamus Decker asks some questions about surveying definitions - Andy Waddington expounds.

Q: Do most record keepers count the surveyed distance or the True Horizontal Distance of a cave as its 'length' ?

Like the computer world, the caving world has sets of defined 'standards' which govern this sort of thing. This particular set of standards is agreed by the Union Internationale de Speleology's Commission on Long and Deep Caves (on which the US representative was, at one time, Peter Sprouse, I believe - but this was some years ago. Anyone know who their national representatives are today ?) Also like the computer world, people had their own ways of doing things before the standards were agreed, and may have seen no reason to change since. The commission ponders such things as whether to quote total length or horizontal length (they chose total length to avoid the absurdity of deep shafts being only a few metres 'long'). They also argue about much more esoteric things like this:

I hope you can see that the dotted lines represent a survey, and that for the passages going north, the measured length starts at the survey point in the centre of the main passage, but for the passages going south, it starts just at the entrance to the passage. So for the north passages, we are counting little bits of passage width in the length of the cave (this is what most people do - it makes surveying straightforward). Should we allow this ?

In the south passages, we are only counting length which is strictly along the passage, obviously more sensible. But is it ? This means that any enlargement in the width of the main passage shortens the cave. Is this sensible ?

This is of such pressing concern to all surveyors, that I can't remember what the decision was. Obviously, those people whose countries or regions have long caves with big trunk passages will favour the solution on the north, whilst those who live in a maze of small twisty passages, all alike, will favour that on the south. Maybe they're still arguing. Just something else to keep you awake at night.

Q: What about spray shots, survey traverses around LARGE rooms and the like? Is there any worldwide consensus about how these measurements are to be counted into the final representative datum for a cave?

Yes. The UIS say that they don't count. This is sensible, because it is easy for every surveyor to understand and implement. There is only one direct line across a chamber, and this is what counts. How many spray shots or bits of wall traverse you believe that you need depends more on the surveyor than on the cave.

I say, if you need to do a spray shot ... these measurements should be counted because it is the distance one must travel in order to visit the entire cave. It would be fun to hear a proponent of an alternative perspective!

I suspect that not everyone has the same sense of fun. I reckon most of the arguments in this UIS commission must be just people winding each other up to see just how esoteric they are prepared to get before they realise that the piss is being taken ...

However, there is a difference between 'UIS Commission length' and the total distance needed to experience the whole cave. Not just wandering round chambers, but also passing either side of huge boulders. In passages like the main route of the Gouffre Berger, where the passage is much wider than the average caving lamp will reach, you need to go up and down by several different routes to experience the whole passage... Maybe Seamus would like to approach the UIS with a proposal for a new statistic: the 'experiential length' of a cave, which defines the total traverse length required to experience all of it, counting both sides of obstacles, visits to distant walls, and multiple routes needed to see a whole passage, based on the penetration distance in various environments of some notional 'standard' caving lamp.

And one more question to keep you awake: which shaft is the deeper ?

The UIS have a standard for this too: the cave on the left is deeper, but the pitch on the right is deeper. The cave depth is supposed to be from the highest closed contour, the pitch length is basically what you would expect, i.e. from takeoff to landing point. There was then much esoteric argument about dolines so big that they were wider than the total depth, and whether it was really at all sensible to count the doline as cave. i.e. they decided a standard, then set about demolishing it, with the conclusion to be decided in the next episode, which it apparently never was. I think the general conclusion was that you could use whatever method you wanted, as long as it was adequately documented, so people knew what the figure you quoted (for depth, length or whatever) actually meant. This works fine, except in the situation where someone is making a "world deep list", and only has the figure, with no survey and no accompanying descriptive article. Since such people are basically the only ones who give a toss about the basis of the figure, the whole thing is essentially a waste of time. Still, it keeps these pedants off the streets, I suppose :-)

CavePlot 2.0 Demo Release

Dave Herron

Even though CavePlot 2.0 is not quite ready for distribution, I have put together a (partly disabled) demo of the current program.

This Demo is available from the cavers archive and from Wookey at the editorial address. This version will not let you save any data, or use the import features.

The Australian Surveying & Mapping Standard Commission

Ken Grimes

[ The following article was published in "Australian Caver" No. 135, 1993, the journal of the Australian Speleological Federation Inc. Members Manual and Annual Report, Pages 20-21 ]

The ASF Survey and Map Standards Commission was established in 1974, under the convenorship of Edward G Anderson, and grew out of an Ad Hoc committee that was created in 1971.

The terms of reference were and still are:

I took over the commission in 1983, by which time most of the immediate objectives had been achieved, and I was left with the role of providing continuing advice and co-ordination in survey and mapping standards. The main output for the Commission has been the publication of the ASF Survey & Map Standards. The current version was prepared by E.G. Anderson and others in 1978 (ASF Newsletter 79), and reprinted with some addition in the Australian Karst Index (Matthews, 1985 p. 18.1 - 18.20)

The published standards cover:

So there you have yet another reason for buying your own personal copy of the Karst Index.

Related documents which were prepared by the Documentation Commission, and which are also published in the Australian Karst Index, are the Cave and Karst Numbering Code (1984), the Map Numbering Guide (1985), both by Peter Matthews. You really should buy a copy of that Karst Index. Peter has also prepared a paper; on a Modular Method of Surveying and Mapping using standard A4 size sheets which was published in the Proceedings of the 12th ASF Biennial Conference. (WACCON, 1980, p.l00-111).

For the future, the main challenge will probably come from the growing use of Computer Added Design Drafting (CADD) programs.

CADD standards


There was little activity during the last year. At Tas Trog (19th ASF biennial conference, Jan. '93) I raised the subject of CADD based map standards and asked delegates to pass my report to that meeting on to anyone in their club that is using CADD. I have had no response to that, but have continued to evolve some personal standards (biased towards the nature of the program that I use - Generic CADD).

Ideally we should be looking at standards that will allow easy electronic exchange of map and survey files both between persons within a group and between groups. If someone has prepared a computerised drawing of a cave map, and you have just surveyed a new extension, you would prefer to be able to just add your bit to the existing version, rather than redo the whole map from scratch - after all, the reuse and easy modification of prior drawings is the main justification for using CADD.

The likely problems are at several levels. The initial problem is automating the transfer of output from a survey reduction program (such as SMAPS) that processes your measurements, across to the CADD program, where you add the wall and floor detail, cross sections, scale bars, lettering etc. Hewlett Packard Graphics Language, (HPGL) is one standard that could provide a means of making this transfer, I have used it successfully to transfer plots from SMAPS to Generic CADD.

Within the CADD system the basic problem is that of incompatible binary formats used by different CADD programmes. Fortunately, many of them allow you to import / export files in the 'standard' AutoCad DXF format. At a higher level there is the need to standardise and document the details of layer numbers, pen numbers, symbols, fonts, etc. so that subsequent mappers can take over a CADD map started by someone else without wasting time working out what she or he has been doing. At a still higher level, there could be a need to standardise the overall layout, including any club logos etc. that your group creates.

Another problem that will need consideration is the need to update the ASF Map Summary sheets so as to allow for the use of CADD programs: Up till now the master sheet for any given cave map has usually been a paper or film copy held in a club map collection. In the future, the master copy is more likely to be a digital computer drawing or image file. We will need to record the file name, date stamp and its format (Generic CADD, AutoCad etc.) and the location of the file, both the active version and archive version. Also, given the seductive ease with which often trivial changes can be made to CADD drawings, we should consider a version field as well as the existing map number - or else allow the use of an additional trailing letter 'a-z' to indicate minor version changes. Existing fields that will become less meaningful are Scale and Paper Size which could vary with each printing of the file (this is already a problem with the use of enlarging and reducing photocopiers).

I am currently evolving some solutions and standards for my own use, but if I am to do anything in the way of suggesting standards for all ASF members I will need feedback from those of you who are using CADD Programs. Which programs are you using, what personal drafting standards have you evolved, what problems have you met (and solved?), do you even think standards are needed etc.

(Scanned from the journal by Glenn Baddeley, 21 September 1994)

Cave Mapping Software

John Fogarty

I wrote the cave plotting program currently in use by Proyecto Espelologico Purificacion. This was derived in part from the work of David McKenzie, who wrote a program called Ellipse. The current program is called CaveView and is, essentially, a more modern form of the Ellipse program used then. The last version of CaveView was issued in 1990.

In 1981 David had a program for vector (survey shot) relative detail mapping. This was a modified form of Ellipse which was demonstrated with the Kaua maze cave in Mexico. His subsequent article in Compass and Tape inspired me to begin work on Core, which is my solution to the mapping problem. For the last 3 years I have worked on and off on this new set of programs to specifically address the problem of computer generated cave maps. Recently I began collaborating with David McKenzie on this problem. The goal of this project is a program that is capable of directly output of publication quality cave maps for all and/or part of large cave systems. A couple of years ago I had an article in Compass and Tape that detailed the strategy.

The problem of large cave maps is definitely non-trivial. In comparison to the line plot programs of the past, a new order of complexity is presented.


Large caves are ongoing projects. When caves become large, the problem of creating maps begins to overwhelm the project leaders. Exploration proceeds faster than a map can be drafted. This is as a result of three major elements:-

  1. The drafter of a map does not want to have the map invalidated by subsequent discoveries and so resists starting the map until the cave is 'done'.
  2. After the drafter has started work on the map, subsequent surveys and resurveys reveal closure errors that adjust the passage dimensions in subtle ways.
  3. Large caves (just as in land surveys) need more than a single map. Detail maps are needed that show pitches and rigging information. Area maps, camp maps, main route maps, geological detail, etc. are all variations on a theme.


1) Perform surveys in your standard manner. Pay careful attention to surveying to scale (use a protractor or protractor/compass) as a sketcher. Sketch a running profile and cross sections whenever possible. Use a standard key for floor detail. These reduce problems for the drafter when he/she starts data entry of the sketches.

2) Perform data entry of numerical survey data (distance, inclination, azimuth) using a DATA ENTRY program. The line plot can now be created and displayed using a LINE PLOT DISPLAY program. A CLOSURE program can be used to determine and distribute the error of closure for loops and loop systems within the cave.

3.1) Using a full page or hand scanner, create a bitmapped image of the survey sketches. Each page consists of one or more SKETCH SEGMENTS, each of which represents floor and wall detail for a contiguous section of passage OR a cross section.

3.2) Using the SEGMENT EDITOR display the relevant portion of the line plot. Next, overlay it with the bitmap of a survey page. The aspect ratios (left-right, up-down and diagonals) can be adjusted to get the best fit to the line plot. The best match will occur when sketching to scale has been done. The drafter then uses a combination of AUTOTRACING and mouse/digitising pad directed tracing to convert the bit mapped image into SKETCH SEGMENTS. Each sketch segment is either ABSOLUTE or RELATIVE (scales and transformation matrices are dependent on the vectors imported from the line plot).

4) Using a MAP EDITOR, display the relevant SKETCH SEGMENTS. Apply labels, arrows, scale bars, and dimension indicators. This can be output as a publication quality map or applied to other programs such as CorelDraw, ARTS&LETTERS, PAGEMAKER, VENTURA, QUARKXPRESS, etc.


The implementation that David and I have chosen is a Windows 3.1 model using C++ with an extensive object model for each aspect of the survey and sketch entry. We are currently using both Microsoft's Foundation Classes and Borland's Object Windows Library (OWL). As time goes by this will change. In any case when a program is releasable (don't hold your breath for at least two more years) you will need a big machine to run it on.

My current model is based on Sistema Purificacion; 10,000 stations 9,000 vectors, 500,000+ elements of floor/wall detail. Since each element of floor/wall detail occupies at least 64 bytes:32 Mb will be required for the cave detail. Expect piss-poor performance for systems less than 486 33mhz, 8Mb RAM, local bus, 200Mb plus disk.

Thx. Send comments and suggestions to me : John Fogarty <>