Back in 1988 CUCC used a programmable calculator to reduce survey data in Austria, and only on return to the UK did we have access to anything as advanced as real survey software. This was Sean Kelly's 'Surveyor '88' software, written for the "Below Belize" expedition. This was pretty good - you could give it data and it would do the sums, display them in windows, and print out the results, on multiple sheets if necessary. It didn't take us long to find a couple of serious bugs, but as Sean was still in Cambridge we could hassle him until he fixed them. However he wasn't really interested in developing it any further, and the software's deficiencies were beginning to become annoying (you couldn't use tabs to separate data items, or '+' on positive clino readings, and the graphics were very slow and uninterruptible, so if you accidentally pushed a button you were stuck until it finished displaying (in several minutes time for KH on a slow computer).

So, I started to produce a spec for some better software, and Olly Betts soon became interested and we worked together to decide what was needed. Now there was already other software available at the time, but the only other one that was any good which we knew of (SMAPS) was pretty expensive at $99. So we took the same route as others, and decided to write our own. The problem was that most authors had simply looked at their own projects, and knocked together something sufficient for that. Most of these had little or no loops processing as the authors didn't know the maths or how to translate that into algorithms. There seemed no point in repeating this short-sighted approach, so we determined to try and produce something that would be useful to others as well as ourselves. This meant it had to be versatile, and if we wanted it to be used it needed to be free too. The basic spec was:

• Multiple computing platforms supported
• Multiple languages supported
• Data to be entered with as little change as possible from the original notes:
  ie.
  • Free-form text entry
  • Data entry ordering/characters specifiable (eg. . , / or , for decimal separator)
  • Proper mathematically-based network reduction for loops
  • Versatile naming conventions Connections made by either use of existing station names, or saying station X is the same as station Y
• Scalable, so it would work on slow small computers as well as big fast ones.
• No software-imposed limits (eg. number of stations, legs, loops)
• Fast-as-possible cave display
• Source availability so anyone can make changes or additions

Surveyor '88 had many of the above features, and followed basically the same design philosophy. We took the good ideas from that, and discarded the bad ones. We could have worked from the Surveyor '88 source but our multiple platforms requirement made that difficult as Surveyor '88 was written in Pascal, and Pascal compilers were not readily available for all machines. Thus we decided to write in C as it is a very portable language and produces fast software.

A Specification was duly written (which still comprises a large chunk of the documentation, unfortunately) and we started writing, with Olly quickly taking on nearly all the programming work. The first tangible result was the prototype for CaveRot which was written during the 1991 expo in BASIC and ARM code on an A3000.

A trip to the Surveyors' meeting at the 1991 Swiss Caving Conference showed us what was possible when we saw the Mac package 'Toporobot', which was very capable and impressive. We talked to its author Martin Heller, who was most encouraging, telling us that Toporobot was only ever intended for the Mac, and we should go away and write some decent software for all those other machines.

The bones took shape rapidly and Survex became the software of choice finally superseding Surveyor '88 during the 1992 expo. Since then it has grown to several hundred K of source, with versions for DOS, RISCOS & UNIX. A major development was the use of the GNU PC compiler DJGPP which removes the 640K memory limit imposed by DOS. This was necessary as Kaninchenhöhle quickly became sufficiently large & complex that the miserable 640K provided on a DOS PC simply wasn't enough memory to process it in.

Five years on, Survex has become a powerful cave surveying tool with one of the most powerful data engines available. It lacks a great deal of fancy user interface features (help, menus etc.) that can be found on other good cave survey software packages, although the revolutionary mouse-controlled CaveRot interface remains unique.

A great deal of care has gone into designing the way that data is entered, stored and processed. The command structure is neat powerful and extensible. The network processing is done reasonably rigorously. It could be done more rigorously, but a great deal of extra memory would be required for little practical benefit.

A number of other groups are now using it - it is particularly popular in Brazil as the only survey software available in Portuguese. It has also been translated to French, German, Italian, Spanish, Catalan, and US English. Various other people have supplied add-ons such as an HTO converter by Bill Purvis (HTO is a standard for the interchange of cave survey data), and a program that combines Survex data, LRUD passage data, and surface data then outputs it all as a DXF file for input into a drafting package. This is being used by Chelsea Speleological Society in their survey of Ogof Draenen. It is also being used for the OFD and Easegill re-surveys, and thus is the software of choice for the 3 longest systems in the UK.

Distinguishing features:

• It's free!
• Multi-platform (from lowly 8088 PCs to UNIX systems)
• Powerful (in terms of survey complexity)
• Versatile (in terms of input data)
• Fast processing of survey data
• Hi-speed mouse and/or keyboard controlled survey viewer
• Good printer/plotter support.
• Source code freely available
• Multiple language support (English, US English, Portuguese, French, German, Catalan, Spanish, Italian)
• PC version uses DPMI and so is compatible with Windows extended memory management.

So where next?

The driving force of development is CUCC's surveying needs, and the requests of users. The time and effort required for producing a survey of a big system like Kaninchenhöhle means that we struggle to produce surveys containing each year's new finds. The reasons why the new bits cannot simply be added to the existing drawing are threefold

1) new bits go off the edge of the page
2) new loops mean that the rest of the survey bends
3) new additions often require redrawing of junctions or low-grade surveys

All of these can be often be bodged round for a year or two but sooner or later you have to re-draw the whole lot. In the case of the elevation it has become so complex that we are simply incapable of drawing anything that makes sense!

Doing the whole thing on computer would help in all of these areas. There is no 'edge of the paper'. Perfect alterations can be made without smear marks from rubbers. Adding the text so that it is all horizontal is easy. The hard bit is bending existing survey sections when the centreline they were originally drawn round has changed. Olly's 1991 computer project explored the mechanisms required to achieve this, working from original work by David McKenzie, and producing algorithms which could be applied to each vector or bitmap cave data. The computer needs to be told how the drawing relates to the centreline so that the whole lot can be stretched and rotated to fit. This a feature that will eventually be implemented in Survex.

In the meantime we have been looking at how to use existing LRUD (Left, Right, Up Down) data to produce an enhanced view with volume, rather than just a line survey. We concluded that the data as it stood was too 'humanistic' to be sensibly interpreted by a computer. Such things as which side are left and right, what to do with all the '?' and '-' entries at junctions and on pitches, etc. are all problematic. Andy Atkinson worked out a compromise scheme where we give the computer some extra information about junctions, chambers, and changes from predominantly horizontal to vertical passage, as well as abandoning LRUD entirely for pitches and using NSEW (North, South, East, West) instead. This new format can be retro-fitted to existing data with the aid of the sketches in order to make it sufficient. Julian Todd's handy experience with a firm that writes CADCAM software gives him the tools and competence to write software that does all the hard sums, hidden line removal, and 3d-drawing relatively easily. Once this scheme is shown to be viable it is likely to become a fully-fledged part of Survex, giving excellent cave visualisation.

On a more mundane level work has been progressing towards fitting a graphical front-end to Survex so that it can become a native application in modern GUI Environments (Windows, RISCOS, X-Windows, MacOS, etc). The main barrier to this is working out sufficiently cross-platform ways of achieving it.

Finally there is a huge list of features people would like. Many of these require a more advanced format for the 3d files that Survex currently outputs. This has been largely worked out and is likely to hit the streets in the next version of Survex. This will allow the cave viewer to know lots of stuff about the cave, like which bit is which survey, and where the loops, junctions and entrances are, so that these things can be displayed on request.

SURVEX can be obtained from:
Wookey, 734 Newmarket Rd, Cambridge, CB5 8RS 01223 504881(H) 01223 811679(W)
Mailto:wookey (at) aleph1.co.uk
Please send a formatted disc and a Stamped Self Addressed Envelope
You can also get it from the UK cavers archive site at ftp://chert.lmu.ac.uk/pub/chert/Survex by anonymous ftp. Also keep an eye out for a Survex Website in the near future.