survex to therion data conversion

Wookey wookey at
Thu Nov 6 14:06:14 CET 2003

+++ Andy Waddington on Cave Surveying [03-11-06 10:04 +0000]:

>> On Wednesday 2003-11-05 18:27, Wookey typed:
>>> > * (in *team) (survex currently allows anything but therion has a list)
>>> >  "insts" is not recognised and has to be replaced with "compass clino". I
>>> > think "insts" or "instruments" should be a permitted synonym as it's in a
>>> > lot of data files.
>> The instruments being read are not necessarily compass and clino for
>> some surveying styles. They might, for example, be a compass and
>> depth guage. The more general term should be preferred if all
>> instruments are being read by a single surveyor, but it ought to
>> be accpetable to specify individual instruments if, as occasionally
>> happens, different instruments are being read by different people and
>> you need to specify which/who.

There is a huge pile of considerations like this - the tape might be a
disto, the instrument might be an altimeter. Does the *team command serve to
categorise the person responsible for the 'length, depth, gradient, backclino
pictures' measurements in order to know who was respnsible for what in which
case all we care about is which numbers to match them up with, or is it
simply a string that we can use.

I think we want to use this command (as opposed to a comment) to regularise
this data so that it can be understood by the programs for future use (e.g
making charts of who took the most clino readings, or applying personal
calibration offsets (still not clear if this is worth doing)). The problem
is that there are a lot of potentially valid strings if we allow all
instrument names (disto, DLE35, laser, compass, MC-15 etc). These boil down
to a set of measurement names (length, gradient, depth etc) and a set of
accuracy numbers (disto is better than tape). But the accuracy numbers go in
the *SD command anyway so maybe we should limit the synonyms (but allow
'other' and 'unkown').

If we were just going to treat it as a free string then we might as well
stick to using comments.

>>> > (it would be nice if the synonym "centreline" was allowed as well as
>>> > "centerline", then I wouldn't get an error every time I type it in  :-)  On
>>> > the other hand there is a lot to be said for a strict data format).
>> You could have a strict data format whilst still allowing regional
>> variant spellings if you had something like
>> *lingua en-gb
>> ; or
>> *lingua en-us
>> to specify which command set was in use.

This way lies madness.

>> I used to have a browser that understood <centre>
>> as well as <center>, which was nice for viewing web pages which had
>> been built in an ordinary text editor (like Wookey, I always type the
>> familiar spelling), but not much use for testing pages that you were
>> actually going to publish. If the DTD line at the top of the page
>> would allow me to specify en-gb tags, that would make life much
>> easier (but would make browsers more complex)-:

We've had this argument over HTML and we all know what a mess accepting
broken HTML was. We need to be strict about option names and
spellings. In general I'd say that there should only be one spelling of
centerline. The problem is that at the moment this line is aded by hand to a
lot of survex files and all en-gb (or en-fr) spekaing people will get it
wrong most of the time. The question is should therion allow both spellings
until the need for hand-editing as a matter of course is removed?

I suspect the answer is 'no' and we should just fix the conversion problem
so this particular irritation goes away.

(sorry about the repeats for people on both these lists BTW - but I think
it's important for both user communities to agree on this stuff)

Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679
work: play:

More information about the Therion mailing list