Project Spud

Back in July 1990 I (Olly) was on my first CUCC Austria expedition. We were using some survey software called Surveyor87 - it was pretty good, but the graphics could at best be described as "sluggish" so I sat around in the potato hut at base camp, knocked back a few beers and hacked together a BBC BASIC and ARM assembler cave viewer, which later evolved into caverot.

A decade later, almost to the day, the plan for a new incarnation of Survex began to gel in that same wooden hut. The other main recent contributors to this plan were Mark Shinwell, Phil Underwood, and Wookey. But over the past decade I've been absorbing ideas and suggestions from more people than I can sensibly list here.

After some beer we came up with the name Visual Survex++ 2000 Professional Platinum Millennium Edition. Bleary eyed the next morning Project Spud seemed a better idea (spud being UK slang for Potato).

The project spud plan is to reinterpret the current Survex ethos and reshape the code in line with that in a series of stages. We'll be leveraging our synergies too of course.

Before getting too deep into technical details I'll list some of the major benefits of project spud for the end-user:

• Seamlessly integrated GUI
• Third party extensions available in plug-in form
• Only modules and extensions you use get loaded, reducing memory usage and start-up time
• Ability to read survey data in a mixture of the native format, interchange formats, and formats of other survey software
• Built in revision history for a data set; ability to look at what the data looked like at any point in the past
• It'll be here in substantially less than a decade this time - and by working in a series of stages users will see the benefits much sooner.

A couple of notable problems with the current version are:

• The lack of a GUI built in from the start. It's not really where my interests or talents lie, so it's been rather neglected. Aven provides a very good viewer, but it would benefit from a closer relationship with the survey data reduction engine (cavern). Phil Underwood's Chasm offers a fully fledged GUI front-end, but behind the scenes it's still clunky and this restricts what it can do. The current architecture makes it hard to integrate seamlessly.
• Much of the code isn't modular enough to be easy to extend in ways we want - e.g. the string of problems after the addition of code to split the survey network at articulation points. Also the code to interpret .svx files is hard to use separately so anyone writing a program which reads .svx files takes the path of least resistance and writes their own. But then their program needs updating when the .svx format is extended.

I know some will argue for Java rather than C++. But we've had that argument before and it didn't achieve much so I don't want to have it again. But I will point out that we have a lot of C and C++ code we can reuse which we couldn't in Java. And I'll also note that those developers who've expressed an interest so far all favour C++.

Mark Shinwell has devised a plug-in architecture that is simple and lightweight (typically one machine instruction overhead). This will allow other people to write extensions which can be supplied separately (in much the same way that you can download a Macromedia Flash plug-in for your Netscape or Microsoft web browser).

The network reduction code will be reimplemented as a library, which makes it a lot more modular, and potentially allows it to be used in other programs (provided of course that they are released under the GPL).

My plan is to store the survey data in a structured file format (possibly a relational database), with a simple (non-branching) version control system providing a revision history and allowing any previous version of the data to be inspected or processed (very useful for a large survey project lasting many years).

Data in other formats would be converted to this format during processing, so input filters for the native formats of Survex 1, Toporobot, Compass, etc could be written (Survex 1.0 can already read Compass data transparently). Similarly exchange formats such as SEF, CDI, etc could be just read in without an explicit import operation.

This new format would also store a textual representation of the survey data, which could be used by the GUI data entry editor to preserve formatting of entered data (so if you enter 3.0 you later see 3.0, not 3 or 3.00). It could also be used to produce a text file for external editing.

The current prefix hierarchy will be replaced with a more structured one - keeping the flexibility where it's actually needed, but tagging levels as "country", "area", "system", "cave", etc.

For ease of coding, we're using the C++ STL. It comes with any ISO conforming C++ compiler; for older compilers there's a portable implementation (STLPort). C++ static object constructors seem to be a portability nightmare so we should avoid using them. Other C++ features which are problematic in some implementations can be judged on a similar cost/benefit basis.

The time required should be much less than for Survex 1.0. We have a good idea of what we want to achieve as we've already written Survex 1.0. There's plenty of code we can reuse or use for inspiration. Instead of just me coding with some help from Wookey, we're likely to have a handful of developers, and the plug-in architecture should allow us to avoid tripping over each other too much. Survex was my first C program, so a lot of time was initally spent learning C. And lastly C++ is higher level so coding time is more productive.

We believe wxWindows is the most suitable GUI toolkit for us. It supports Microsoft Windows, Mac OS, and Unix already. There's also a "universal" port which allows it to run on platforms which provide a framebuffer but have no native GUI (MSDOS is an example). And the really nice thing is that it gives a native look and feel to the application.

Supporting Palmtops would be desirable, but a toolkit isn't enough here I suspect. Palmtops tend to have smaller screens, so GUI modules designed for a larger screen size are likely to be less than ideal. Modern models are improving - Psion series 5 is 640x240 (same width as "real" VGA but half as high); Psion series 7 is 640x480 ("real" VGA); Compaq ipaq is 240x320. Here again, wxWindows may be a good choice as it is starting to tackle the issues of targetting such devices.

Whichever approach we take, we're unlikely to have GUI versions for pre-386 MS-DOS or RISC OS, but command line versions are still possible.

webmaster: Olly Betts