Re: [therion] Re: [Therion] Feedback on 0.3.8 - queries

[Wookey]

Stacho Mudrak wrote:

> First of all, I am impressed with your map! It's a great feeling for
> me to know, that someone else is using therion for such a huge cave.
>
> There was no traffic in the mailing list, so I was worried, that all
> the people that tried therion are disappointed with it.


No - just busy doing things :-) I am pretty happy with Therion overall
and will continue to use it now that I have put so much effort into
finding out how it works. One of the best things about it is your and
Martin's responsiveness to queries and suggestions. I am still learning
how to use it and whilst I have done a lot, most of it is very basic.
(There is quite a small subset of possible symbols in that map, and very
few areas, for example, because areas tends to 'go wrong' ).

Having reached this stage there are some issues with speed. xtherion is
slow to move from one .th2 file to another (mostly loading images), and
the pdf rendering is _really_ slow. Therion itself does not take too
long yet, but overall I find many hours are sucked away for not that
much progress, just like drawing on paper! The speed matters because
every time you make a change you have to process and render to check it
is OK, and this is a fundamental feature. Adding some background
rendering might be something to think about for the future (e.g. run
therion every few mins on the data - if a valid result is produced then
display it - if not (because the author is in the middle of a scrap and
things are not yet valid (no stations) then forget the results and
restore the previous version.

I haver another set of queries to ask about splitting large surveys
which would help solve the problem of regenerating a big map - I will
put all that in another thread as it is complicated.

Jenny Black has also done a very nice Therion map of EisluftHoehle in
Austria. Hers is actually finished (the plan at least, and of course now
they have found some more). She has some comments on the problems of
adding a lot of labels, which she will no doubt post about when she gets
back from expo.

> So I left therion developement and started to work on the new 3D
> viewer for therion. And there was a lot of problems to solve -
> especially with unicode OpenGL support and off-screen poster
> rendering. So there was no time for therion developement.

Is it working/useable now? The expedition would like to try this if all
I have to do is add a load of passage-height indicators. (note I am not
going on the expedition, just preparing data and software for it).

Survex-aven also has (finally!) acquired passage dimension rendering in
the last 3 weeks as well, just to keep things interesting.

> Wookey wrote:
>
>> 1) Is there a dripline symbol for the entrance extent? Do I use
>> 'overhang'?
>> I tried using overhang and nothing appears (because it is outside the
>> clipped
>> area?) Should I use overhang and add a -outline out option?
>>
>> 2) How can I represent a surface cliff line between a series of caves?
>> I have a lot of cave entrances with a defined cliffline between them.
>> the
>> survey makes a lot more sense if this surface feature can be seen.
>> How can I
>> draw a line on to represent this?
>
>
> We have been already thinking of some surface specific symbols.
> According to your mail - you would like to have two new line types:
>
> line drip (or dripline)
> line cliff (or cliffline)
>
> Could you plase write us, what syntax makes more sense? We should
> probably make difference also between underground and surface contours.
> Probably also

'cliff' is tricky. It is a small cliff for my particular cave, and for
some others, but often an equivalent line is used on surveys that does
not represent a cliff (especially on elevations, where it represents the
general surface level). A more general name would be better, but it is
tricky to think of a good one. 'line surface-landform' might be best
(just a line), and perhaps a different symbol for 'line cliff' (this is
normally drawn as a series of short dashes perpendicular to the line
direction)

So I'd say 'line dripline', 'line cliff' and 'line landform'

> line surface-contour
>
> is needed. All those lines will have clipping turned off by default.
>
> Another point - using "-outline out" for surface features is probably
> not correct. It will make huge problems when generating clipping paths
> and 3D model. Use instead "-clip off" option, if you do not want that
> line to be clipped.

But for the dripline (which always goes across the entrance) we want the
passage fill to go up to this line (it defines the outline of the cave
just like passage walls do), so I would think that -outline out is
correct here, is it not?

> Another possibility is to add all surface features into specific scrap,
> where no outline will be defined (=> no lines will be clipped).

That may well be useful where there is a lot of surface detail to draw
(e.g buildings, paths, roads overlay). In fact it may well work quite
well for my cliff between many entrances, although in that case I'm not
sure how I would make it line up with the various entrances.

>> 3)What to do when entrance line draws scrap end across to the wrong
>> point
>> (e.g. deception entrance?) In the bottom LH corner of the survey
>> above is
>> 'Deception Cave'. If you look at '1st entrance' you will see the
>> problem I
>> mean. Therion has decided to ignore the last bit of wall and just draw a
>> line across the gap between the nearest points. How do I make a wide,
>> flared
>> entrance like this have the 'correct' entrance area? This may be
>> related to
>> question 1.
>
>
> Very simple but quite often problem. Just connect the entrance ends with
>
> line wall -subtype invisible
>
> I know that invisible wall is not very intuitive, but it is very easy to
> use - because you do not need to stop entering line - you just type
> subtype spec to line point options.
>
> If you do not like it - you can use
>
> line border -subtype invisible -outline out
>
> instead. But we are using invisible walls.

OK - right. makes sense. My 'line dripline' serves a very similar
purpose, but has a visible symbol.

>> 4) How is length in legend calculated when data is imported from .3d
>> file?
>> The survey above consists of a lot of scraps round real data and a
>> lot round
>> 'fake' data made from surveys which are nothing but drawings scaled
>> with the
>> scale bar or a few nearby or fake survey stations. The survex .3d
>> file used
>> includes survex data for the whole mountain including another 50km of
>> cave
>> or so. So where is the number in the legend coming from?
>
>
> It should be the total length of all centerline objects, to which scraps
> in the map refers to (surface shots should be excluded). Uff, I am not
> sure whether you understand this explanation.
>
> In the case of import - centerline object is created for each survey
> object and shots are splitted into surveys. So in your case it is the
> sum of lengths of all surveys, you refers to in maps. Or at least it
> should be.

OK. I should check if it is right. (I wonder how it works for fake
surveys which have no 'legs' - only a long list of fixed points?)

> If the number does not make sense - you can redefine it in layout. Use
>
> code tex-map
> \cavelength={1234 m}
> endcode
>
> or something like this. I am not sure.
>
> In the TODO list I already have something like setting survey in layout,
> from which length and depth will be taken. Example:
>
> statistics source-survey somesurvey.topsurvey
>
> Would it make sense for you?

In general, yes, but in this case things are rather complicated - there
are >30 entrances and a rather arbitrary split into caves (according to
discovery history) and some caves are at the top level, others are under
a cave they are part of (within the centreline dataset). A list of a few
surveys (to be added together) would give the correct overall length: 
terikan, bluemoon, menagerie, deception, david. Also useful would be to
have a nuymber of entries of the form 'Cavename: length' for each of
those surveys. I can presumably do that with some code tex-map?

>
>> 5) How do I get rid of the 'dummy' survey surrounding all my data which
>> means the title of the whole thing is 'dummy'. I may have been told this
>> before in which case I apologise for forgetting the answer.
>
>
> Import should work without this dummy survey (outside of survey
> context). Have you tried? If not, there is some bug.

No - I did this back when it was needed and have not dared remove it as
it was always an inconvenient time to break things :-) trying now...
OK, it doesn't 'just work'. But I think all I really need to do is
change the top-level survey to 'benarat' and give a sensible title. ( 
See index.th at the top level of
http://wookware.org/mulu/benarat-therion20050809.zip )
I have to put a  survey round the top-level map and includes and joins.
This used to be 'dummy' which worked but gave the map a silly title. I
just changed this to 'benarat' with a proper title and that works OK,
but I have to put it outside the import benarat.3d otherwise I get
warnings about surveys that could not be imported and then objects which
are needed are not found. This is the clever 'auto-stripping' stuff
working as it should do. I could presumably have it outside and provide
the correct options to import to make it work.

I may want to discuss this further in my  'splitting up the maps' post,
coming in the next couple of days.

>> 6) When is a label under passage and when over?
>> As you can see I have some of both in this survey. Is it to do with the
>> ordering of walls and labels within the scrap? Or maybe there is an
>> 'ontop'
>> option?
>
>
> There is no 'ontop' option. Label is on the top of the scrap - in which
> it is defined. If some other map overlays it - the label will be under
> this passage. 

OK - that sounds sensible. With transparency that should give correct
results. I think an important feature of colouring is that the labels
should be the same colour as the scrap they are in. This is the only way
to tell which bit they refer to in multi-layered systems. I see that my
'Poor Man's Hand' label must be partly-obscured because it is on one of
the lower scraps in that cave section. It shoul probably be attached to
the highest one.


> Would you like to have something like 'ontop' option?

An 'ontop' might well be useful as well, but I will have to experiment a
bit more to see if I think I need.

Wookey (trying new mailer)
_______________________________________________
Therion mailing list
address@hidden
http://www.speleo.cz/mailman/listinfo/therion