LRUD in Survex

Olly Betts
Wed, 1 Aug 2001 02:22:43 +0100

On Wed, Aug 01, 2001 at 07:01:35PM +1000, Mike Lake wrote:
> On Tue, Jul 31, 2001 at 03:25:23AM +0100, Olly Betts wrote:
> > On Thu, Jul 19, 2001 at 09:46:45PM +0100, Peter Wilton-Jones wrote:
> > > Is there any plans to implement [LRUD data] into survex? It may be that
> > > you intend to try and put it into Spud?? Is this a thaught.
> One problem I see is that there seems to be no concensus on the format of
> LRUD data. Some users have just one set of 4 LRUD data points per station
> others have two sets; one set "looking into the station" and another set
> "looking out of the station". 
> Certainly makes it difficult for programmers.

There are various problems like this, but as Wookey pointed out to me - even
an implementation which only accepted a subset of what people actually
record is better than simply declaring the problem to be too hard.  We can
look at what other packages that allow LRUD can handle, and come up with a
useful model.

> > The database may be the master copy of the raw survey data (entered and
> > modifiable using a dedicated editor) or the master copy of the raw surveys
> > may be elsewhere in another form (e.g. in a .svx file you can edit with a
> > text editor).  Or some mixture of the two - some surveys in .svx files,
> > others only in the database.
> One of the BIG advantages for me is that svx files are ASCII and editable by
> any text editor and because they are text can be edited by utilities such as
> sed. [...]  A dedicated data entry program and binary data is OK so
> long as Survex can still use ASCII files as the master copies.

Just to emphasise what I meant by what I wrote above - when I say "may", I
mean what the software will allow, not what the software might require.

So you can keep the master form as a .svx file if you want.  Or if someone
writes a suitable parser, as any other suitable format.  So if you're
working on a project with someone who uses Compass (say), you can process
their data along with your own without having to convert it as such when
they send an update.  And users of other software can use survex as an
add-on to that software.

But if you prefer, the master form can just be the database itself.

Either way, survex (and any add-on tools people produce) can use the
database as a source of processed data.  It's likely we'll use something
like mysql, so a web front-end to the collated survey data could be written
in PHP (or your prefered dynamic web page technology).  This is something
we're interested in for the CUCC Austria website which at present is all
done in hand-crafted HTML:

Note the dates "1976-1999".  Merging a year's updates in by hand is a major
job and nobody's had time this year.  A lot of this work could be automated.