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)