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

[Wookey]

On Mon 09 Oct, Mark Shinwell wrote:

> <http://users.skynet.be/avalon/avalonuk/convert.htm>
> A page for those "fed up with Survex"...
>  (c) no support for stereo visualisation;

This one has always been somewhat ironic as in fact we did it first (so far
as I know) back in 1991, but never put it in the release version as we didn't
think anyone else would have the same 3D specs as we got from a shreddies
packet.


> 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.

I've reviewed it in the past and kept somewhat uptodate with it over the
years.


> There is also some kind of interface to external database software to
> allow the recording of specific features within the cave.

The compass GIS system is essentially the same as the previous SMAPS v5 GIS
system. Both are remarkably simple in implmentation when you get down to it,
but then databases are powerful like that :-)

They allow you to relate data items to survey stations. That's it, but in
fact this is a powerful tool for some uses. Yes we should certainly consider
including it, or something very like it, as I suspect you can do it almost
'for free'.

> 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.

No, I don't beleive it would be much use for this. It's not a general
database in this way. All you can do is allocate data (e.g temp) to survey
stations. It might be a good way to implmement 'attributes' (being one of my
favourite hobby-horses), and then you get 'GIS-support' for free.

> 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

Indeed.

> 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?

OK. You are right that compass has featuritis, but it's also by far the most
popular cave survey software in the world. It has reached this status for a
combination of reasons. It has always been 'good enough'; Larry Fish is a
very nice bloke and has done a huge amount of work; He is extremely
responsive to user requests, and I suspect this is much of the cause of the
featureitis. e.g if someone asks for a format to be read in he will generally
just add the functionality in the next version.

Perhaps the biggest argument in it's favour is that the documentation has
always been excellent. The underlying data model is actually rather ropey -
or at least it was a few years ago last time I looked. It still had all sorts
of hard-coded size limits and was rather primitive in many ways due to
growing organically according to user requests. However so long as it
basically works and people get told how to use it (such that they won't trip
over it's limitations) users don't care at all. The sort of people who do are
using survex which is rather primitive on the outside but realatively
beatiful on the inside :-)

I get a regular stream of surveyors who say 'I'd like tp use survex but I
couldn't find the file->open button so I had to use Compass instead. When you
fix it I'll change'. _If_ we want to satisfy the majority of surveyors this
is the level you need to consider. Sad but true.

> <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".

Don't forget the rest of the world largely hasn't seen the stuff we've
produced in the last year (chasm, potrot) which significantly improves the
situation.

> <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,

Definately. It's been on my whishlist since it was introduced. Somewhere I
even have some code from Garry Petrie (the author) for how to do it. These
days suvh code/info will be widely available anyway.

> but again, it doesn't really affect our underlying architecture

Agreed. It's just one way of outputting co-ordinates.


> 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?

Some. It's quite good, although it's always (since it progressed to windows
from DOS) suffered from being rather unreliable (prone to GPFs). It doesn't
get the time and devotion that compass has had so the quality is not as good,
but yes it has a range of nice features. I don't really have and details of
the underlying data model, but as it also developed from DOS software in
parallel with compass I suspect it's similar.

The tunnel modelling is quite primitive (passages are made from squares and
triangles), but of course, users find it's a whole lot better than nothing.
Tunnel produces much more realistic models, but of course almost no-one can
actually run that so it's not as much use as it ought to be.

Other software people should consider is Toporobot and Walls, both of which
have many satisfied users. The other 15-odd packages are largely even less
popular than Survex ;-), although a few have innovative ideas.

> 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...

I think you are right. People need to do a bit of work to get some ideas for
discussion written down and then we need a meeting. A CSG meeting is probably
the best way to do this. There should be one this autumn but I don't know if
Anthony actually booked it...

A suggested method of proceeding:
first we need a short presentation on the concepts (from Olly I suggest),
then we sit down and take ideas on 'things people want' from everybody. Then
the nerdier members sit down and work out how to get those with a number of
plug-ins and how it all ties together.

I contend that my previously-posted 'attributes' doc (from a previous CSG
meet) is implementation-independent and a suitable item for consideration.

A set of objectives and restrictins might be in order first. ie the things
that have already been agreed-upon. (C++, plug-ins). We need to disucss a
little more what we want to achieve. I don't know that you can make 'software
for everyone'. If you make it flexible then it's too complicated for many
people. In principle you can make something that is complicated but present
it in a simple way for a subset of typical uses, but so far we have failed to
really achieve that. Are we much more likely to succeed on a second attempt?

The other thing that really concerns me is how long is this all going to
take? We have already been telling people they can't have coloured 3D plots
or select surveys till we do the new 3D format for some 4 years. Now we tell
them we're going to write the whole damn thing again, (but better this time)
which should give them what they want in another couple of years (OK Chasm
largely adresses these two items, but I think you know what I mean). In the
meantime I hink most of our users have defected to Compass. Only the Linux
people and those with huge datasets are left, due to lock-in, ideology or
the fact that there is nothing else for Linux.

Hopefully the increased programmer base and sensible task-splitting should
result in something a great deal better and more future-proof and better
suited to being open software. I suppose I'd better finally work out how C++
works...Unless it needs some device drivers, of course, - I could do that :-)

Bit of a ramble that lot, but I hope it helps direct some thoughts.

Wookey
-- 
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK  Tel (00 44) 1223 811679
work: http://www.aleph1.co.uk/     play: http://www.chaos.org.uk/~wookey/