Is it an entrance ? (was: Re: XML)

[Andy Waddington on Survey stuff]

> The Survex data format at present describes to a data reduction engine how
> to process the data

We've been through this philosophy loop before ... and this is *my*
understanding - YMMV

Survex data was originally meant to describe a survey, by presenting all
the data gathered in a structured and well-defined format. That format
provides facilities for the user to impose a structure on the data which
aims to represent the way in which real surveys are carried out.

It was *not* meant to say "how to process" that data - Survex as a program
(or any other program that someone might write to operate on the same
datasets) was meant to decide what to do with the data, in the light of
its knowledge of how the data are structured, and possibly in the light
of additional "how to" directives which do not form a part of the actual
dataset (currently these are all command-line options).

A third stage was to decide how to represent the results to an end-user -
which bits of the survey to show, what colour, what view, what scale etc.
etc. This was never really Survex's task - Survex merely produced a 3d file
on which CaveRot or some other display program could work, given some other
set of directives saying what output was required. Recent changes to Survex
have defined a better 3d file format to better support such post-processing
steps.

The distinctions inevitably blur a bit in the light of reality, but the
principles are there, nd the main one to note is that the data file does
not say "how to process", just "here are my data".

To my mind, whereabouts a station is within the cave passage or on the
surface is a part of the data. A flag saying that a point is on the roof
doesn't tell the program to do anything different with the centre line, it
is not a directive. However, it is a useful piece of information which
survex should pass on along with the coordinates of the point (typically in
the form of LRUD, for example).

That a point is at a surface/cave interface location (an entrance or exit :-)
is a similarly useful tag. Nothing about that label is a directive to the
program - some other input to Cavern or CaveRot or whatever could say "treat
entrance points in such-and-such a manner", but that directive would be useless
if the point wasn't flagged as an entrance or exit in the first place.

To diverge a little: Survex datasets typically contain a lot of less
structured textual information. Use of the begin/end construct is useful to
make this text apply to a whole survey (typically a set of connected data
collected in a single trip, or, at a higher level when begin/end are nested,
a series of trips). Text on the same line as a survey leg/shot is assumed to
apply to that leg. At present, it is harder to associate text with a
specific station - at least in the Austria dataset all the LRUD data and
station description are contained in a comment and are thus ignored by
Survex (although interpreted by Tunnel, for example). You can also add
comments to things like *equate and *fix, but all are ignored by Survex
itself.

None of this text is carried forwards into the 3d file, where it would
perhaps be useful for a subsequent display program to be able to display not
only the name of a station but its description, or the description of the
leg. It would certainly be nice to click menu over a displayed survey and
have the menu include the name of the nearest point and the nearest leg on
the display, giving you submenu choices to display all the comments
associated with that station or leg in a little pop-up window...

Adding some form of structure to the comments should not affect how Survex
processes the centre line, but should be passed on in a similarly structured
manner for the benefit of subsequent value-added software. This should not
add any significant bloating to Survex (as it not being required to
interpret any of this text), and if you don't put the stuff in your dataset,
won't bloat that either. So there would be very little penalty for those
using Survex on "small" platforms like PDAs.

Hmm, that is a long enough waffle on one point that I'd better change the
subject: line a bit ...

Andy