Spud thoughts

[Olly Betts]

Sorry about the slow reply - I've been very busy at work recently, but
that's done now.

Philip Underwood writes:
>I would propose a data structure similar to the following(using STL)...
>Note that this is aimed at being able to use survex files with a minimum of 
>fettling.

I think it's premature to think about data structures.  We need to decide
what needs to be represented before we decide how to represent it -
otherwise we risk reinventing the survex 1.0 data structures and then
struggling to bolt on new requirements as we think of them.

So here are survex 1's ideas of what survey data consists of:

* A survey leg is representable as a vector in cartesian coordinates with a
  symmetric covariance matrix.

* Fixed points are representable in cartesian coordinates with no error
  (fixed points with an error are internally represented as an exact fixed
  point and a zero length leg with the error on).  Alternatively the user
  views a fixed point as representable by set of cartesian coordiantes and a
  covariance matrix (which may be zero).

* Every survey station must be a fixed point or connected to a fixed point
  by survey legs.

* Nested survey structure (named *begin/*end blocks).

* Two or more station names can be marked as refering to the same point.

* Each reading has units and also a linear calibration (zero error and
  scaling factor).  Additionally a magnetic declination correction is
  applied to compass readings.

Here are some potential changes and additions for Spud, in no particular
order (some of these could require a very different internal structure):

* Seperate connectivity horizontally and vertically - allowing for altimeter
  readings, manometers, radiolocations with no depth determination, etc.

* Triangulations - compass and clino measurements from a station to two or
  more other stations (no length measurement).  

* Surveys where the vertical angular difference is measured at a survey
  stations instead of an angle from magnetic north.  E.g. a theodolite
  traverse, or a foresight/backsight compass survey near ferous mineral
  deposits.

* Labelled levels of the survey prefix hierarchy - e.g. area, system, cave,
  survey book.

* Attributes (comments, flags, dates, etc) attached to stations, legs,
  surveys, etc.  Note that it's common for an attribute to apply to many
  stations or legs (common example is an instrument calibration).  Perhaps
  also allow totally arbitrary data - e.g. scanned photos, scientific
  measurements, etc.

* Instrument and person naming so you can examine calibrations, etc by who
  did them, or which instrument they were done with.

* Concept of relocatable stations - many survey stations are inherently
  ephemeral and trying to link another survey to one is clearly a mistake
  (or the station wasn't ephemeral in which case its status is wrong).

* Cross sections (either simple measurements horizontally and vetically, or
  a polygon, or even a scanned profile) attachable to legs (possibly part
  way along) or an pair of legs sharing a common station (note: just
  attaching to the station loses the direction).

* Polygonal meshes for terrain or scanned chambers.

Any other possibilities?  It would be interesting to look at what other cave
surveying software does.

Cheers,
Olly