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

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 - all the compilers which are in active use support it pretty well now. Use of C++ features which are problematic in some implementations can be judged on a cost/benefit basis.

The effort 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 initially spent learning C. And lastly C++ is higher level so coding time is more productive.

We believe wxWidgets is the most suitable GUI toolkit for us. It supports Microsoft Windows, macOS, 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 mobile devices like palmtops and smart phones is desirable, but a toolkit isn't enough here I suspect. While the resolution of these devices has increased greatly, they're still small compared to modern desktops, so GUI modules designed for a larger screen size are likely to be less than ideal. The lack of a full keyboard is another issue. Here again, wxWidgets may be a good choice as it is attempting to tackle the issues of targetting such devices.

webmaster: Olly Betts