Spud stuff: other survey software; and a few other bits.

[Mark Shinwell]

Hi

I have been browsing around various cave surveying web sites and collated
some things which might be of use for Spud design.  This is the first
installment of a summary of these things.

Obviously some of these are specific features which do not have direct
relevance on the fundamental architecture of Spud, but it is useful to
have some inkling of what other developers are up to.

Two prevelent features seem to be
 (a) integrated editors for the data;
 (b) 3D "tunnel" features for visualising passage shapes.


<http://users.skynet.be/avalon/avalonuk/convert.htm>
A page for those "fed up with Survex"...

There are issues raised relating to:
 (a) the lack of an editor tailored to entering svx files;
 (b) no depth colouring or surface grids;
 (c) no support for stereo visualisation;
 (d) no 3D tunnel support;
 (e) lack of features like the ones Chasm has for highlighting
     bits of caves, etc.;
 (f) lack of blunder detection;
 (g) lack of print preview;
 (h) difficulty in organising svx files.

(c) is easy for us to do.  (b), (e) and (g) we certainly already have
the technology to do and I believe (f) is covered to some extent.

(h) is an awkward one -- how can one make it easy to do this?  Can we
maybe produce a short document on it, using examples drawn from large
datasets such as the CUCC Austria one?  (See later about "philosophy").

(a) is in hand for Spud.

(d) is more awkward.  Persuade Julian to port Tunnel to C++?  Dunno :)

There is an interesting comment about a text editor "Aurora" which can
select columns of text, not just normal blocks.  Might be worth
considering... (then there are all the other questions to do with the
editor which need sorting out -- eg are there two editors (plain text
and a more sophisticated one)?).


Compass  <http://fountainware.com/compass>
"...originally written in 1979 and ran on a PDP-10..."

I suggest someone endowed with a machine running Windows has a look at
this... here are a few notes on it anyway.

The main thrust of the program is to allow easy input and easy
visualisation.

Some of the main features, condensed from
  http://fountainware.com/compass/wdetails.htm:

- Ghastly web site.
- Project manager.  Survey files can participate in more than one
  project (wow :)  Whether we need to have something like this I
  don't know; the one thought that occurs to me which might be
  relevant is that we need to figure out an interface to the revision
  control system.
  You can easily arrange and disorganise your survey data by dragging
  and dropping.  There is a serious point here, related to the one
  above, about the philosophy of the software.  With Survex at the
  moment it's up to the user how to structure their dataset;
  presumably we want to preserve this for Spud?  There are of course
  the hierarchies of country/system etc. which Olly was proposing to
  think about.
- It has a built-in editor, which looks nasty and does things like 
  forcing a certain number of decimal places.  It has 12-character
  station name restrictions.
- Blunder detection is incorporated.
- You can assemble 3D passage shapes as with Tunnel.  The whole
  support for this looks quite sophisticated.
- Eye-candy: fancy viewer with all the twiddles, export of
  fly-through videos and some sort of way of exporting to the
  Web (presumably VRML/Java).
- Rose graphs and so on are all implemented.
- Has integration with GIS stuff like ArcView, and can read standard
  DEM (Digital Elevation Map) files for terrain data.  We ought to do
  the latter (I will investigate).
- Context-sensitive help.  We need to think about how we will provide
  help.
- It costs money.

There is also some kind of interface to external database software to
allow the recording of specific features within the cave.  I wonder if
this could be used for CUCC's Austria dataset to record, for example,
the position of cave entrances as marked via GPS.  Something like this
could probably be very easily implemented as a plugin which acts as
an arbiter between the rendering engine and an external database such
as MySQL, for e

Olly might want to look at
  http://fountainware.com/compass/compart2.htm
but I suspect he's already seen it :)

It strikes me that Compass has featuritis, but I can't really make
an informed decision not having tried it out.  Can anyone advise on the
merits or otherwise of this software?  The thing is that it has
hundreds of features in addition to the few I've noted above, and many
of them would be easily implemented via our plugin architecture.

Does anyone know much about the data model in Compass?


<http://www.karst.net/Compass/complin.htm> is a bad joke, but cites the
main problem of Survex as being "poor qualities concerning the
visualization of survey data".


<http://home.europa.com/~gp/winkarst.html> "home of the best software
for the study and mapping of caves".

Looks pretty good.  One point I notice is that it can understand
coordinate systems, GPS, etc. (e.g. it allows export of waypoint data
for entrances).  This could be a really nice feature to have, but again,
it doesn't really affect our underlying architecture (save for the fact
that we need to make the editors understand commands, etc, implemented
by the different plug-ins -- but when one considers that the data
processing engine itself is just a plug-in, this becomes a non-issue).

Has various fancy diagrams like 3D rose diagrams; see the web site.

The tunnel features seem to be given much attention.  I seriously think
we should make sure Spud can do something like this.

It strikes me that WinKarst has the sort of overall features we might
be aiming for and does seem to be targetting specific useful features
rather than having lots of little twiddles.  Does anyone have any
experience with it?


The four major advantages which Spud will have over any of these other
programs is that it will be multi-platform, free, open source and very
easy to extend; from the look of it a Mac port will be plausible
(assuming the GTK+ Mac port keeps going OK).


How are we going to approach Spud design?  We need to think about overall
architecture, data model etc.  Input from surveyors around the place would
be very useful...  Then we can move onto the nitty gritty of specific
features within each plugin (which can probably be designed fairly
independently in some cases and then subjected to peer review).  What do
people think?  Olly's mail has set the ball rolling and I'll reply to
that as soon as I have time.

To be honest I reckon it would be great to organise a meeting in person
between people who have good ideas for the project, as then a lot more
can get done at once...


Anyway, that's all for now.

Mark

-- 
Mark Shinwell -- President, Cambridge University Caving Club
Queens' College, Cambridge, UK
Mail: mrs30@cam.ac.uk   Web: http://mrs30.quns.cam.ac.uk