Having been using Therion to try and draw up some caves I have become somewhat frustrated by the survex/therion data incompatibilities.
I think there is room for improvement here and will make some observations, which I hope will promote discussion. The therion centreline data format is pretty-much the same as Survex's - however it's not exactly the same so there is a need for converting data between the two packages. Ultimately I think we need a scheme where the one dataset can be used by both packages as otherwise you end up maintaining two almost identical datasets, which has to be a bad thing. This could be accomplished with conversion tools, but the two formats are so nearly identical that we ought to be able to simply 'include' survex files in therion, or have both packages understand both dialects. In the meantime I need to be able to automate conversion for the hundreds of survex data files I have. Here are the differences I have found so far: First the simple ones: * In therion commands do not have a "*" prefix (lines starting with reserved words that are not actually commands have a "!" prefix) * therion does not understand "export" this is not a big deal, but it would probably be a good idea if it did * therion uses # for comments, survex uses ; (by default) this is just tiresome - especially for hand-editing conversion * Survex uses "begin <surveyname>", therion uses "survey <surveyname>" * Survex uses "end <surveyname>", therion uses "endsurvey" * (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. therion has no eqivalent of "dog" on the surveying team (general checking-out of leads) . I think 'dog' is a colloquial UK term but there should probably be something in *data "ignore" is not supported by therion. - neither is left/right/up/down (survex doesn't support these either, but should - I even did a patch for it somewhere) This construct is needed for entry of LRUD info into files that will one day be processed usefully (at least for interleaved style data). If both bits of software allowed it to be labelled 'left', 'right', 'up', down' then that solves the problem. There are two more fundamental changes: *therion surrounds centreline (ie survex) data (inside the 'survey' construct) with centerline .... endcenterline this makes sense - it is effectively implicit in survex, but therion has other forms of data so the centreline stuff needs to be indicated. (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). * equates need to live inside centerline/endcenterline this one is tricky as it seems to change the scoping rules survex uses and seems to make it difficult to directly (simply) translate data. typical survex data goes: *begin part1 <survey data> *end part1 *equate part1.36 part2.0 *begin part2 <survey data> *end part2 How do I translate this to therion? will: survey part1 centerline <survey data> endcenterline endsurvey survey part2 centerline equate part1.36 part2.0 endceterline endsurvey work? (It is good practice in survex not to include equates in the survey like this as they don't really belong to the scope of either survey). Recommendations welcome. So - I can probably write some perl to do this conversion reasonably well, but it'd be useful to have agreement on what to do about some of these cases and if we agreed it was better to modify the programs rather than write a converter then I could spend the time doing that instead. Discuss. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
