spud threads

[Olly Betts]

[a tardy reply - I'm currently clearing something of a mail backlog]

In message <39E443A0@Survex@pennine.demon.co.uk>, Andy Waddington on Survey stu
ff writes:
>I have always regarded one of the strengths of Survex as being the fact that
>it allowed me to use whatever editor I was comfortable with to enter my
>survey data. I once built a tailored data entry program for SU (on the BBC
>micro) but soon realised that *edit was much more useful and have never liked
>any software that requires me to learn a whole user interface just to type in
>a few figures

Entering centre-line data is a matter of just typing in a few figures, but
once you start to allow more complicated data the benefits of a dedicated
editor grow.  And even for entering a centre-line, a dedicated editor can
do helpful things such as plotting the last few legs entered, which could be
very useful for spotting typos during data entry.  It's much easier to
correct them then when everything is fresh in people's minds.

>learning a file format is usually vastly easier.

Vastly easier to you or me perhaps.  But many users would prefer such a GUI
editor.

>It must be important to provide users with a
>choice of interfaces, especially at the absolutely fundamental
>data-entry/maintenance stage.

This is what I want to do - ideally I'd like the data to be readable from
all sorts of formats, including those of other software.  So if a Compass
user wants to view his data with Spud, he doesn't need to muck around
converting it via some intermediate transfer format which typically loses
information - he can just load it in, and even process it alongside data
from other sources.

>there should be a well-defined data format, and still be a way for those
>users that prefer it to edit that format in their favourite editor on their
>favourite platform

This easily falls out from the goal of reading data from a variety of
sources.

>Survex does not impose much restriction on how you organise your data,
>adapting very well to a number of different preexisting schemes, so in
>effect it assumes that users have the basic competance

You mean "competence" (I can out-pedant Waddington!)

>to organise their own
>data without imposing some inflexible structure. Perhaps it is this very
>lack of guidance that is troubling some users ?

I think a key problem (and one that I have when coming back to the CUCC
Austria dataset after a couple of years' of updates) is that it's very hard
to get an overview of how a dataset is structured at the moment.  I think
this is a problem which a GUI tool could solve best.

I also think we're too flexible in some ways at the moment.  Even just
labelling levels of the hierarchy as "cave", "system", "area", etc would
help I think.

>Mark says:
>> There is an interesting comment about a text editor "Aurora" which
>> can select columns of text, not just normal blocks.
>
>[...] Surely this must now be fairly common [...] ?

Yes, it's a common feature that pretty much any decent editor has.  It's
likely that whatever editor Mark uses actually already allows it, but he's
just not aware of it...

>It may not matter to the program what order the
>tape/compass/clino come in, but it certainly makes it easier for people if
>they are kept the same...
>[...]
>Julian is right - everything in the survey book should go with minimal
>change into the survey program.

I agree data appearing in a form close to the original survey notes is best
(it makes it much easier to check for transcription errors).  But surely
reordering the tape/compass/clino readings works against this?

>The [other users] don't
>want to be able to see inside, and don't mind that commercial secrecy means
>the authors prevent them from doing so. I don't think we are targeting that
>sort of user. At least, I hope not, because surveyors need to understand
>what they are doing !!!

Surveyors need to understand about surveying.  And they should know what
their software is doing on their behalf - for example, how loops are closed
and the implications of this (e.g. you shouldn't go blindly applying least
squares to networks with gross errors).

However they don't need to know details of the file formats, or what matrix
techniques are used to perform the least squares.  If they want to look
inside at such things, they are more than welcome to.  But if they don't
care to, that's fine.

Cheers,
Olly