- Therion - speleo.sk

An extended elevation problem
by Eric Madelaine 22 Jan '07

22 Jan '07

Hello guys, I have a problem with a cave on which I would like to have a partial extended elevation. The cave is small, but the centerline has a loop, and when I compole an extended elevation, even with half of the loop flagged with a "extend ignore", Therion thinks that the stations in my extended view are very far, as if it did extend using another branch of the loop... Is there a trick to do a partial extended map ? (well, may be I could do an elevation instead, but this is not what I wanted from the beginning...) How could I do several extended maps for different parts ? Eric.

2 1

Flowstone problems
by Joke Vansweevelt 16 Jan '07

16 Jan '07

I'm working on a topo of a water-cave and I have two questions. - How can I stop a flowstone-feature to be filled with water? (In the water, defined by "area-water", I sometimes have features that I would like to stay clear of the water-filling-stripes. If I try to include the borders of this feature as borderlines of my "area-water", usually my whole image gets distorted (not-water areas suddenly become partly filled with water-filling-stripes etc.). It doesn't work either by defining these features as an area within the area-water (error). Objects defined by rock-border don't have to be specified as area border. Rocks are automatically not filled with water-filling-stripes. However, in the case of flowstone features, I would like to be able to define whether they should or should not be filled with water-filling-stripes. In case it isn't possible so far, a solution could maybe be to define flowstone that doesn't need to be filled with water as "line-rock-subtype flowstone"?!?) - How can I get the borders of "line-flowstone" in my X-Therion drawing to match the borders of my flowstone-feature in the produced pdf-file? (When some of my area borders are defined as "line-flowstone", in the produced pdf-file, the water tends to invade my flowstone (as far as the borders of the "line-flowstone" that I set within X-Therion). The problem here is that the produced drawing of the flowstone lines is larger than the borders one sets in X-Therion (the scale that I work with for the pdf-file is 1 1000). Regards, Joke

3 2

Making map with centreline and scraps mixed
by Wookey 08 Jan '07

08 Jan '07

I wan't to make a large area overview map. We have centreline data for all of it, but only some caves have been drawn in therion. How (is it possible) to show the caves with therion data in outline form (i.e. walls only), but the other caves in centreline-only form. I can get it with them all showing centreline and therion caves showing walls, or walls only, and nothing at all for centreline-only caves, but not what I want. Does the revise command help here? I know select terikanplan(a)terikan.Mulu selects the map terikanplan but I'm not sure what the correct syntax for selecting a centreline is: would it just be terikan.Mulu? or terikan@mulu? Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/

3 3

Moving section of cave aside
by Wookey 08 Jan '07

08 Jan '07

For drawing complex caves it is often useful to move a section of cave to one side so it doesn't obscure the passage below. I can't see an easy way to do this in therion, because everything is always positionned according to stations. Could we have some kind of scrap offset feature that would allow a scrap or map to be drawn in a different place? It would also be nice to have the scrap shown in outline (or shaded, etc) in the correct place, so the survey can be properly understood. e.g. the terikan survey has numerous layers but also plenty of whitespace to move upper layers into so as to draw it all on one sheet but without complex overlapping passage. This is an alternative to the atlas scheme which therion has excllent support for. this alternative is very popular in the UK, and probably other places - it would be gfood if therion could support it. It is useful for a very long thin cave, where you can get much better paper use by drawing the sections side-by-side instead of as a very long thin page. (e.g. this very long thin cave: moon cave: http://mulucaves.org/Pub_surveys/Moon_CaveBCRA.pdf) Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/

2 2

changing page size in atlas
by Wookey 08 Jan '07

08 Jan '07

I tried to make an atlas with A3 sized pages, portrait mode so set size 42 29.7 cm in my layout. This resulted in a lot of errors: Normal \count register pool exhausted, switching to extended pool.) (./th_pagedef.tex) (./th_pages.tex [1] Overfull \vbox (239.1945pt too high) has occurred while \output is active [2] [3] Overfull \vbox (239.1945pt too high) has occurred while \output is active [4] [5] down to [48] (see the transcript file for additional information)</usr/share/texmf-tetex/fon ts/type1/bluesky/cm/cmsy10.pfb></usr/share/texmf-tetex/fonts/type1/bluesky/cm/c mss10.pfb> Output written on data.pdf (48 pages, 2430010 bytes). In the finished atlas every other page is blank, and I get no navigator. Is this a bug, or did I do something wrong? Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/

3 3

Docs and debian packaging
by Wookey 05 Jan '07

05 Jan '07

I have made the 0.4.1~pre20061221 debian packaging of the latest snapshot. This includes the wiki docs and the current source and debs are available at: http://wookware.org/files/therion/ However I have a problem with the packaging. Debian packages normally include the original source tarball plus a debian diff for the changes. However the changes now include all the wiki html and images. The images are not representable in a diff so it doesn't work. The above package has been done without an upstream tarball for the source. I am not sure what to do about this. I see these options: 1) uuencode all the images Pro: farily simple - packagin needs to uudecode them all before normal packaging - no other changes. Cons: Makes source 35% bigger - not totally crazy but still 1Mb extra. Makes packaging more fiddly due to need to convert to/from uuencode whenever there is a wiki export update 2) Make therion a debian native package Pro: can then just use standard mechanisms No wasted space or extra faff Con: therion isn't a debian native package, and it means I can't do a debian update without there being abump in the therion version. This has caused problems with survex so I'm not too keen. This is effectively what has been done with the debs I've currently built. 3) Include wiki export in upstream tarball Pro: Makes things trivial from my POV Con: You may not want to do this as you already have the wiki - do you want docs in source as well? Makes source much bigger: dump is ~3.5MB 4) Split therion source docs and code upstream Pro: has the same effect as 3, but code download is still small. Con: You need to do a bit of work to move thbook sources into docs tarball So, the question for therion authors/admins (who shouldn't really have to worry about debian packaging), is do you think including the wiki docs in either the main source tarball or a different docs one (and move the thbook into that too) is a good idea or not? If you do then I suggest this is the best way to go. If not I will probably go the uuencode route for now, unless/until someone has a better idea. Sorry to bother you with this - I had never realised that debian diffs cannot introduce binary files not in upstream - it's a bit cack really in a situation like this. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/

4 7

Re: [Therion] texlive support in therion
by Wookey 04 Jan '07

04 Jan '07

On 2006-12-19 12:20 +0100, Norbert Preining wrote: > Hi! > > On Die, 19 Dez 2006, Norbert Preining wrote: > > > Although for the purposes of texlive compatibility I think the > > > existing 0.3.10 in debian testing will be just as good. > > > > Ok, can take a look at this, too. > > Hmm, it is quite hard to check for dependencies in the source c++ code. > I have another idea: Can you send me some typical file which should be > compiled with metapost and pdflatex (or whatever)? There is a set of files for a large project here: http://wookware.org/mulu/mulu.tgz common_layout.th has some metapost code in it. The .th2 files are the ones that describe the lines and symbols use to draw each section. the thconfig file sets which files and styles are used for each dir (try benarat/terikan/ as a reasonably complex and complete example). As I said I'm not sure this is really going to help that much as it is too far removed from Tex to be relevant. I think the tex, mpost and (maybe) texenc dirs in the source are the bit that show what tex and metapost functions are used. > I have seen comments on metafun, too, do you use context? I don't understand this question. Martin, Stacho? > As I said, the best option is to send me some medium complicated files > which should be do-able with the dependencies, and I will check them. > Thank Well that Mulu.tbz tarball is an example. Unpack it. and apt-get install therion. Then cd benarat/terikan therion and watch it process. (You can do therion at the top level but that could take a while). I suppose I could try the same thing with texlive and see what happens. But right now I need to produce some output for an expedition leaving just after xmas. I'll try Texlive once that panic is over. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/

3 6

3d file wall models - scrap connections
by Wookey 30 Dec '06

30 Dec '06

I very much like the 3d map output into survex .3d format. However it does seem to have a problem at joins. It all looks lovely in plan view, but as soon as you look sideways you will see that there is often a vertical offset in the lines at the join. I can see that there _might_ be a pitch at the pont of the join, but normally a smooth transition in the vertical as well as horizontal plane is desired. How are the vertical co-ordoinates at the ends of scraps determined, and is it possible to msake sure they 'join' (have the same co-ordinates) both vertically as well as horizontally? The option to say 'add vertical lines to complete join' would be useful for cases where there is a step height change (e.g the connection between menagerie_s4 and terikan.reifticious_s1). But I'm not quite sure how/where this might be done. If it is hard, then joining everything up would be much better than it is now. See http://wookware.org/mulu/MuluWalls.3d, then look at it on a bit of a tilt. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/

10 32

Interface Comments/Suggestions
by Wookey 28 Dec '06

28 Dec '06

OK, after a major drawing session, here are a few general comments on therion/xtherion. I'll send a seaprate mail with things specific to my project: 1) I get very bored of typing '-subtype invisible' after clicking on border. Somekind of shortcut for selecting commonly-used subtypes would be really useful. A dropdown showing available subtypes according to selcted line would be a simple way to do it (and would help when you are not quite sure which ones are available). But having border (invisible) in the main menu next to border would really help. The problem is that people's favourite lines probably vary with person and cave, so being able to configure this might be best. (ctrl-B or ctrl-I to select it would be good for me). This implies a general mechanism for configuring key shortcuts or favoured line-types, which may not be easy. But anything would be better than typing '-subtype invisible' hundreds of times. 2) cross-section drawing. Overall this is still very tedious - there are various things that could be done to make it better. scale: The new update scale button is a big help, but I still find I have to do things like look up the length of a nearby plan line in the .svx file in order to find the LRUD info or otherwise get a scale so I can then set the scale by using the stations (and rotating top right point so line is at approx 45 degrees). This seems such a waste of time when the passage width is right there next to the section, and clearly the scale should match. I can't easily tell if the passage is 2, 5, or 20m wide, but therion already knows. Perhaps the scale for X on an xsect could default to the same as the dist between the walls under the section line (and Y is same as X), and N is up the page? Then the drawer can change that if it is not right. scrap names: I got very bored of creating a scrap then having to select it and change the name to <scrapname>_c1 or whatever. Can x-sects be set to have such a scrapname by default, incrementing the number? Part of the problem is that there is no link between the x-sect scrap and the section line on the plan/elevation. Only the point has a link. It seems to me that xsections are logical entities and making sure all of the line, the scrap and the point are associated is a good thing, which will help with the grouping of sections into boxes when that is implemented. Associated with this is the need to give each section a 'display name' or label like 'E3' or whatever. Have I just missed this facility? 3) xtherion should warn you when you accidentally create lines outside of a scrap. It is easy to do and slow/fiddly to put right. Is there ever a valid reason for creating lines outside a scrap? I can't think of one. Automatically removing null lines might be useful (a line entry that just has one point and does nothing but confuse - are these ever useful)? 4) The xtherion interface needs more work on shortcuts generally as we use it so intensively. More keyboard options for chanigng between common line and point types and moving to next scrap in the scroll list. e.g only showing lines in the current scrap and showing lines from other scraps collapsed or greyed might do the trick? 5) I don't believe the 'right click to select line hidden below' is working. When I have a line at a scrap join on both scraps (because there is an area join here), I can only selectone line. I have to move it out of the way to get the other one. 6) I need a much faster computer and/or more RAM. :-) Large files take forever to load or change scale. pdf rendering takes minutes too, and I can't open a browser and aven and xtherion and a PDF file all at once. xtherion can get left a long way behind (but at least it does do all thing you asked eventually). This part is not your fault, although the tcl of xtherion doesn't help - that is a really big job to fix, although finding someone to re-write it in gtk would be very good 7) General issue of mixing cave- and map- and project-specific layout options. There are layout options that you want to set globally for the project (e.g. symbol types), options you want to set for the cave (name, rotate, author), and options you want to set just for this plot (map-header position, exclude pages). It is currently difficult to set this up so that it works well. The newish 'copy' and 'input' commands ought to provide the right flexibility but I keep finding I am inheriting some inappropriate settings. I'm not sure about this - it probably isn't therion's fault, but I get the feeling it could be made a lot easier for users to separate the various types of layout option. I'll have to think about this. OK, that'll do for now. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/

3 3

Wiki FAQ page broken
by Wookey 28 Dec '06

28 Dec '06

I just edited the last entry on the wiki: "How to access lines or points on top of each other?" in order to tidy up the formatting (it was cut directly from an email). (using the edit button for just that item, not the whole page) But whilst that now looks better - every other entry seems to have lost all the line/para breaks so it looks a mess. I'm not sure what is going on here. I could mess with it a whole load more, but that might just make things worse. Could our wiki-expert take a look? My browser tells me there is one html whinge: HTML warning: line 134, input camp outside <form> but that was there before it went horrid-looking too so is irrelevant to this problem. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/

3 3