problem importing .3d file

Wookey wookey at
Tue Feb 8 16:39:21 CET 2005

+++ Stacho Mudrak [05-02-08 08:53 +0100]:

>> Wookey wrote:
>>> >However - whilst it now processes a 'null' set of data as in the example,
>>> >as
>>> >soon as I put back any data it goes wrong again:
>>> >input goon.th2
>>> >(inside the terikan survey) and I get:
>>> >therion: error -- terikan/goon.th2 [10] -- survey does not exist -- goon --
>>> >invalid station reference -- 69 at goon
>> Well - I expected that you will report this error  :)

You could have mentionned it so I didn't spend two hours trying to work out
if I was just being dumb... :-/

>> OK - the problem is - when stations are imported, they are inserted into
>> subsurveys _if and only if this subsurvey exists_. In your example - you
>> have no survey goon defined, therefore terikan.goon.69 is interpreted
>> like goon.69 at terikan.
>> If therion would have import command before - you would probably
>> reference stations like goon.69 and you would not create any survey
>> structure. So this problem is probably only in the case - when somebody
>> converted his surveys first and then he tries to use import command instead.

True. Although it might be useful if it was possible to use the same dataset
with either an import command or a set of converted svx->therion data. In
this case the station references in the scrpas need to be consistent, and
probably need to be 69 at goon, not goon.69@  This makes the scraps modular so
they can be put together in different ways without too much knowledge of the
surrounding structure. Modularity in data is something we should strive for
as much as possible.

This discussion brings up another point I wanted to raise. The fact that I
have to add a fake top-level survey in order to include a .3d file seems to
me to be very naff. There must be a better solution.

If I have a therion dataset inside
 survey terikan
 endsurvey terikan
And a survex dataset which has terikan as the top level then it ought to be
possible to put them together without having to makew the structure be
survey dummy
 import terikan.3d
  survey terikan
  endsurvey terikan
endsurvey dummy

Maybe we need a concept like the -p1 in patch to tell it how many levels to
strip off the input dataset in order to import it correctly?

This is particularly an issue if I have a big dataset for the area
containing several caves (Which I do:)
We actually have
top level: mulu  (whole area)
 2nd level:  benarat - mountain
             api  - another mountain
  3rd level:   terikan - cave
               bluemoon - cave
	       cobweb  - cave
So ideally I would want to import the top-level .3d file that included all
the GPS fixes, surface surveys, surface loop closures etc - i.e the best
possible relative fit of all the cave positions.

Then use this at various places in the therion dataset for therion to draw
separate surveys with. I can do this with the current version of therion by adding
lots of empty surveys to match this structure, although still with the extra
top-level 'dummy' which I don't like. It would definately be better to be
able to say 'import ignoring the top 2 levels'.

Ideal would be for Therion to look at the imported structure and try to
match a level to the current survey level (this won't work if there are two
surveys with the same name at different levels, but I don't think that
happens often in real datasets?). It is obvious to a person that if a
dataset contains terikan which contains goon, and the therion dataset has
survey terikan and load of references to goon below then it matches up. It
would be good if the computer could do that too, although I realise this is
not trivial in practice.

>> You can solve your problem three ways:
>> 1. Define empty surveys at the beginning of the file
>> import terikan.3d
>> survey terikan
>> survey goon
>> endsurvey
>> ... the same for each used survey
>> endsurvey terikan
>> ... and it should work. This is easiest solution.

but it is naff  :-)

>> 2. Convert everything XX at YY into YY.XX using regexp replace. A little
>> bit more work - but very clean solution.

Except that it means I can't go back to using a full-therion dataset without
changing all the structure round. I shouldn't have to decide before starting
all the drawing whether I am going to get the station positions from a
therion dataset or a survex dataset - it should be possible to do both with
the same set of scraps.

>> 3. Persuade us to modify therion in a way - that subsurveys will be
>> created (may be into some - "user specified" - level). It is a litle bit
>> more work on our side, but if you will have good arguments for it - no
>> problem.

OK- right, I am understanding the problem now. With a full therion dataset
we have each survey explicitly created. With an imported survex dataset this
does not happen. I think the importing of the dataset should implicitly
create the hierarchy, at least so that references in .th2 files can 'just
work' without us having to explicitly re-specify it in .th files. I think
there is enough data in the .3d file to do this?

At the very least we need a detailed explanation of this for the time being
as it's not at all obvious  :-)

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

More information about the Therion mailing list