Michael and I have held off venturing into extended elevations for many
years, but it seems that now might be the time. Have been browsing the last
7 years of forum posts on this, and so it is with some trepidation.
We have a cave system that now has a variety of often travelled circuits and
through trips, and so we envisage having perhaps two or three or more
extended elevation projections (maps/scraps) as route guides. ie -proj
extended:1 -proj extended:2 -proj extended:3 etc. A number of the passages
will be included in more than one map, and the nature and location of the
'extend xxx' statements in these common passages will likely be different
for each projection/map. At the very least, we do not want the existence of
an extended drawing for one survey prejudicing the creation of a completely
different extended drawing for the same survey (in keeping with the Therion
principle of do it once, use it many times).
My long time (but untested) idea for this is to keep all the surveys with
the default 'extend right', and then at the time of compiling, include a
file full of revise statements to tweak he various surveys to extend left,
right, ignore etc to suit the particular extended drawing to be compiled.
I have a simple one survey cave that I thought I would test this idea on,
and it seems already my idea is unravelling.
I had hoped to use a revise block for each survey as below to insert the
required extend statements at compile time. Unfortunately I see that I can
amend the survey properties (in this case the title), but not the
stations/shots.
revise hunters@HuntersCave -title "Hunters Cave - Revised title"
#above single line works, but multiline as below causes error. unknown
command - extend
extend left 1.7
extend right 3.17
extend hide 3.21 #3.22
endrevise
Then I thought perhaps I could use one revise statement per station/shot;
revise 1.7(a)hunters.HuntersCave extend left
but this brings up a therion error -- INDEXHunters.th [49] -- object does
not exist -- 1.7(a)hunters.HuntersCave
I can verify the station exists and is named as such, because it is labelled
that way in the pdf output and the aven 3d model
So, is there a trick with the revise syntax for surveys or stations that I
have missed? Or am I trying to stretch it's capabilities too much?
Or is there another way to manage multiple extended survey network shapes
for various extended drawing projections, rather than having the extended
survey shape fixed by the original survey definition?
There are about 170 surveys in the real project and growing, so we would
rather not keep two sets of files or manually edit them each time!
Bruce
