mirror of
https://expo.survex.com/repositories/expoweb/.git/
synced 2024-11-30 05:41:56 +00:00
333 lines
16 KiB
HTML
333 lines
16 KiB
HTML
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
|
|
<title>Cambridge Underground 1996: History of Survex</title>
|
|
<link rel="stylesheet" type="text/css" href="../css/main2.css" />
|
|
</head>
|
|
<body>
|
|
<h2 id="tophead">CUCC Expedition Handbook - History of Survex</h2>
|
|
<h1>History of Survex as of 1996</h1>
|
|
|
|
<p align="center"><em>Cambridge Underground 1996, pp 63-6</em></p>
|
|
|
|
<p>[This article was published in CU 1996, shortly after the site was put
|
|
on the web. The text is reproduced without change.]
|
|
|
|
|
|
<h2>History of Survex</h2>
|
|
|
|
<p><b><i>by Wookey</i></b></center>
|
|
|
|
<p>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).
|
|
|
|
<p>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:
|
|
|
|
<ul>
|
|
<li>Multiple computing platforms supported
|
|
<li>Multiple languages supported
|
|
<li>Data to be entered with as little change as possible from the original
|
|
notes:<br>ie.
|
|
<ul>
|
|
<li>Free-form text entry
|
|
<li>Data entry ordering/characters specifiable (eg. . , / or ,
|
|
for decimal separator)
|
|
<li>Proper mathematically-based network reduction for loops
|
|
<li>Versatile naming conventions Connections made by either use of
|
|
existing station names, or saying station X is the same as station Y
|
|
</ul>
|
|
<li>Scalable, so it would work on slow small computers as well as big fast
|
|
ones.
|
|
<li>No software-imposed limits (eg. number of stations, legs, loops)
|
|
<li>Fast-as-possible cave display
|
|
<li>Source availability so anyone can make changes or additions
|
|
</ul>
|
|
|
|
<p>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.
|
|
|
|
<p>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.
|
|
|
|
<p>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.
|
|
|
|
<p>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
|
|
<span lang=de>Kaninchenhöhle</span> quickly became sufficiently large
|
|
& complex that the miserable 640K provided on a DOS PC simply wasn't
|
|
enough memory to process it in.
|
|
|
|
<p>Five years on [1996], 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.
|
|
|
|
<p>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.
|
|
|
|
<p>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 <span lang=cy>Ogof Draenen.</span> 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.
|
|
|
|
|
|
<p><b>Distinguishing features:</b>
|
|
<ul>
|
|
<li>It's free!
|
|
<li>Multi-platform (from lowly 8088 PCs to UNIX systems)
|
|
<li>Powerful (in terms of survey complexity)
|
|
<li>Versatile (in terms of input data)
|
|
<li>Fast processing of survey data
|
|
<li>Hi-speed mouse and/or keyboard controlled survey viewer
|
|
<li>Good printer/plotter support.
|
|
<li>Source code freely available
|
|
<li>Multiple language support (English, US English, Portuguese, French,
|
|
German, Catalan, Spanish, Italian)
|
|
<li>PC version uses DPMI and so is compatible with Windows extended memory
|
|
management.
|
|
</ul>
|
|
<p><b>Data processing:</b>
|
|
<ul>
|
|
<li>Survey complexity limited only by available memory (on a 386 or better
|
|
PC you get up 128Mb of virtual disk memory as well as the memory in the
|
|
machine)
|
|
<li>Versatile system for hierarchical survey station naming, so station 36
|
|
in Stomping in cave number 161 is referred to in full as
|
|
'161.Stomping.36', but within 161 it is just 'Stomping.36', and within
|
|
Stomping it is just '36'.
|
|
<li>When specifying the data format you can use IGNORE and IGNOREALL to
|
|
allow direct reading of basic data from many other survey software
|
|
packages, e.g. Toporobot, CMAP, Compass, Karst, SMAPS(SEF), Survey,
|
|
!Survey (batch). Also any lines it doesn t understand at all will simply be
|
|
ignored.
|
|
<li>Multiple caves can be processed just as easily as one
|
|
<li>Data can be stored in single files, many files, or in directories, as
|
|
you see fit. Files can be included for processing within other files.
|
|
<li>Command files listing a set of Survex commands can be created for
|
|
complex tasks
|
|
<li>Surface topography can be included as contours or mesh
|
|
<li>Separate treatment of plumbed and horizontal (water-surface) legs (not
|
|
adjusted by clino adjustment)
|
|
<li>Free-text input with user-definable symbols, so you can choose the
|
|
separator, decimal point, command prefix etc. This aids import from other
|
|
programs, spreadsheet data, foreign languages etc.
|
|
<li>If no fixed points are given then the highest one is fixed at 0,0,0
|
|
automatically
|
|
<li>Network reduction by least squares. Standard errors calculated, and
|
|
recorded for each leg in vertical & horizontal
|
|
<li>The survey network is split at articulation points when doing network
|
|
reduction, to increase speed and reduce memory requirements.
|
|
<li>Omitted clino readings give a vertical SD of tape/sqrt(10). This
|
|
basically means that clino-less data (eg. collected with a theodolite, or
|
|
by pacing), will stretch vertically, if attached to other data, allowing
|
|
for the fact that the height change is very unlikely to be more than the
|
|
length of the leg.
|
|
<li>Expected error/Standard deviations specifiable for all measurements
|
|
<li>Suitable BCRA Grade files supplied to set appropriate standard
|
|
deviations.
|
|
<li>Diving-style data understood, ie. Depth readings instead of Clino.
|
|
<li>Optional sequential loop closure, so new loops can leave old loops
|
|
unaffected.
|
|
<li>Output is binary (for speed) or ASCII (for people) 3d cave plot file,
|
|
text co-ordinate data, summary info, and error details.
|
|
<li>Summary statistics - Cave N/S, E/W, and Up/Down extents, total length,
|
|
adjusted length, number of legs, stations, time taken to process.
|
|
<li>BEGIN and END commands allow sections (usually surveys) to be defined,
|
|
and changed settings will not affect other data.
|
|
<li>Errors and warnings highlight the area of the line which Survex isn't
|
|
happy about (where appropriate).
|
|
<li>Warnings given for many common errors: The idea it to alert the user
|
|
to possible cock-ups, but to still try and process the data if possible.
|
|
<br>'Hanging' stations listed
|
|
<br>Compass given on plumbed leg
|
|
<br>Survey leg with same station at both ends - typo?
|
|
<br>Tape negative, or adjustment makes reading negative
|
|
<br>Compass reading not in range 0-360
|
|
<br>Clino reading over 90 degrees
|
|
<br>Length of tape measurement is less that change in depth (for diving
|
|
data)
|
|
<br>Same station fixed twice (Error if co-ordinates do not match)
|
|
<li>There are also comprehensive messages given for syntactical errors.
|
|
</ul>
|
|
<p><b>Printer support:</b>
|
|
<ul>
|
|
<li>Multi-page printouts (for big plots on small printers)
|
|
<li>8, 9 and 24 pin dot matrix (Epson, IBM Proprinter, and compatibles) -
|
|
specifiable printer codes
|
|
<li>PCL - i.e. all deskjets, laserjets and compatibles - specifiable
|
|
resolution
|
|
<li>Postscript - specifiable fonts and line widths
|
|
<li>HPGL driver - for various pen plotters - can use centre or corner
|
|
origin
|
|
<li>Canon BJ series special driver to come
|
|
<li>All drivers allow:
|
|
<ul>
|
|
<li>Any view printable - plan, elevation on any plane and angle of tilt.
|
|
<li>specifiable scale
|
|
<li>specifiable paper size
|
|
</ul>
|
|
<li>number of pages required, and arrangement (eg 3x2), is reported.
|
|
<li>Any arbitrary list of pages can be printed.
|
|
<li>Any of border, legs, station and labels can be printed/left out
|
|
<li>Dotted borders and corner alignment marks are included for accurate
|
|
cutting & assembly of multiple sheets
|
|
<li>Names of processed surveys, and time of processing printed on all
|
|
plots.
|
|
</ul>
|
|
<p><b>Graphics:</b>
|
|
<ul>
|
|
<li>DOS graphics support for VGA, EGA, CGA, Hercules, 8514a, et al
|
|
<li>Acorn RISC OS at various resolutions
|
|
<li>X-Windows support
|
|
<li>Intuitive mouse-controlled cave control (zoom, pan and plan/elevation
|
|
swap), with choice of mouse moving viewpoint or object
|
|
<li>Automated rotation
|
|
<li>Direction of view, scale & tilt indicators
|
|
<li>Even extremely large areas (hundreds of kilometres across) can be
|
|
smoothly viewed, but you can still zoom in to a few centimetres.
|
|
<li>Constant rotation speed (so small caves on fast computers don't spin
|
|
ridiculously fast)
|
|
<li>Multiple data files can be read & displayed in different colours
|
|
(eg. cave & surface colours)
|
|
<li>Labels plotted so they don t overlap and can be read
|
|
<li>Labels automatically removed while moving the plot
|
|
<li>Completely flat caves (i.e. Extended Elevations) are automatically
|
|
recognised and locked side-on
|
|
</ul>
|
|
<p><b>Other Utilities:</b>
|
|
<ul>
|
|
<li>DIFFPOS: utility for comparing two .pos files included
|
|
<li>SVX2HTO and HTO2SVX: for converting from & to HTO data transfer
|
|
format
|
|
<li>EXTEND: for flattening the survey to create an extended elevation.
|
|
<li>SVX2DXF: converter now included for moving cave plots into CAD or
|
|
drawing packages in 3D.
|
|
</ul>
|
|
|
|
|
|
<p><b>So where next?</b>
|
|
|
|
<p>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 <span lang=de>Kaninchenhöhle</span> 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
|
|
|
|
<p>1) new bits go off the edge of the page
|
|
<br>2) new loops mean that the rest of the survey bends
|
|
<br>3) new additions often require redrawing of junctions or low-grade
|
|
surveys
|
|
|
|
<p>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!
|
|
|
|
<p>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.
|
|
|
|
<p>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.
|
|
|
|
<p>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.
|
|
|
|
<p>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.
|
|
|
|
<p>SURVEX can be obtained from:
|
|
<br>Wookey, 734 Newmarket Rd, Cambridge, CB5 8RS 01223 504881(H) 01223
|
|
811679(W)
|
|
<br>Mailto:wookey (at) aleph1.co.uk
|
|
<br>Please send a formatted disc and a Stamped Self Addressed Envelope
|
|
<br>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.
|
|
|
|
<p><em>[These days, get survex from <a href="https://survex.com/">https://survex.com/</a> ]</em>
|
|
<p><hr>
|
|
|
|
</body>
|
|
</html>
|