I've been writing an article about Therion for Compass points, which includes a complete tutorial on using therion to draw a simple survey. This process has generated a few queries, one of which needs answering for me to finish the article - others are mostly suggestions for improvements and a few bugs. I'm using 0.2.17 urgent queries: How do I control overlap at joins? I have drawn a couple of scraps and at the place where they join there are contour lines on one scrap and ceilinglines on another that sort of intermingle. When drawn up therion put one scrap on top of the other and invents a 'join line' that covers quite a lot of the neighboring scrap. I need transparency, or a complex 'join line'. What is the best way to deal with this? Do scraps have to have perfect joins? Can I draw a join line? Also I tried to control the join in more detail by specifying that the ends of lines join but the syntax didn't work. What's wrong with this: join farsidewest:0@farside2.river farsidewest2:end@farside.river (farsidewest are farsidewest2 are 'wall' lines). bugs: In .th files - if you use data normal ignore ignore ignore ignore newline tape compass clino then every LRUD line must be followed by a data line, including the last one If you s/ignore ignore ignore ignore/left right up down/ then it ignores absence of TCC part in the last line, but not in lines in the middle of a run. This is inconsistnet with survex behaviour (which will let you give LRUD info for a station and then stop - without subsequent TCC info) In the test editor, using above: data normal left right up down newline tape compass clino and then 'scan format' to get data table to have correct boxes is OK but when you enter data it appears as tape compass clino station left right up down which is the wrong order. When a created file is re-read every blank line gets a 'text' entry in the file commands section, and when saved ends up as 3 blank lines - whitespace text entries shouldn't appear. If I try to zoom in to 200% therion just crashes (64MB machine, 3.8Mb pnm file) Is this expected? It certainly makes it hard to draw boulders properly as I can;'t do stations very close together. The keys list suggets that I can hold down shift to create a station close to another station, but I have not suceeded - how exactly does it work? wishlist items: It would be _really_ good to have png support in Xtherion? GIFs are a pain for free software and pnm and ppm are huge. What needs to be done? Shortcuts for moving things between scraps would be helpful, otherwise it's 'move down' about 100 times. Is there a better way? Entering stations - ther is a space for 'id' but not name, which you need to enter for every station. Indeed why is the id not the name? It's very tedious if you need to change a number of entries - need shortcuts to move between boxes in RH-side or to scroll up and down items in the file summary. e.g if you need to change all the station ids to names. Need to be able to navigate file commands with keys. graphical stuff Air drafts need to be able to specify number of ticks - this is used to indicate wind strength The QMs ('continuation point) come out really small on my survey. Where do I control the size? The debris area symbol looks terrible. I want a quick way to fill in areas of rocks - needs randomised rocks of some sort with controls over size and density. Tunnel (java) has good code for this, with an arrow that control desity gradient. Borrow code? Areas need some way of working out if they are 'connected' or not. The current scheme is hopeless - very cryptic messages which give no clue which area is at fault. Editing them is a real pain as you find the text in the file (takes a while, especially with all the blank ones) but then as soon as you click on a line to adjust it you lose the text again. An entry method that lets you 'group' some lines into an area might be best - especially if it auto-allocated the names. There is a real problem with editing a file and using xtherion at the same time - even F1 and F2 type editing. Therion just saves the map version over any other version you might have created. It needs to check for 'newer on disk' or something. Until the map interface is better there is a real need to edit the file by hand too. This is a tricky problem but it definately needs work before many people will use it. Ticks are too close together on pitches. How do I change the default for contour lines to al have 'none' (no downside tick mark)? I don't want to add -tick none on every contour - I want to set a default. How does the slope line symbol work? It just seemst od raw a lot of overlapping lines for me. How does it differ from the contour line? Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
I'm sorry, currently I'm short of time, but I'll try to write down at least some comments.
How do I control overlap at joins? I have drawn a couple of scraps and at the place where they join there are contour lines on one scrap and ceilinglines on another that sort of intermingle. When drawn up therion put one scrap on top of the other and invents a 'join line' that covers quite a lot of the neighboring scrap. I need transparency, or a complex 'join line'. What is the best way to deal with this? Do scraps have to have perfect joins? Can I draw a join line?
I'm sorry, but this I do not understand :((( Could you please draw me exactly what you have in your mind? Joining two scraps together covers only joining the walls - not the lines inside. They can be joined only by detail specification, you mentioned below.
Also I tried to control the join in more detail by specifying that the ends of lines join but the syntax didn't work. What's wrong with this: join farsidewest:0@farside2.river farsidewest2:end@farside.river (farsidewest are farsidewest2 are 'wall' lines).
Nothing - it should work. If it does not - it's certainly a bug. Does therion generates an error or it simply does not join the lines? Did you tried this without :point specification (just farsidewest@farside2.river farsidewest2@farside.river)? This should work also.
bugs:
In .th files - if you use data normal ignore ignore ignore ignore newline tape compass clino then every LRUD line must be followed by a data line, including the last one If you s/ignore ignore ignore ignore/left right up down/ then it ignores absence of TCC part in the last line, but not in lines in the middle of a run. This is inconsistnet with survex behaviour (which will let you give LRUD info for a station and then stop - without subsequent TCC info)
OK. This is a bug. I'll write it down.
In the test editor, using above: data normal left right up down newline tape compass clino and then 'scan format' to get data table to have correct boxes is OK but when you enter data it appears as tape compass clino station left right up down which is the wrong order.
This is not a bug. I just thought, that putting interleaved (or how you call this style) data, is more natural when TO station is inserted and not FROM station. So I enter empty cells for TAPE, COMPASS, CLINO, enter the first STATION and it's LRUD data. Then I enter TCC data and TO station and it's LRUD. This can be changed or I can add there a check box, which style you like.
When a created file is re-read every blank line gets a 'text' entry in the file commands section, and when saved ends up as 3 blank lines - whitespace text entries shouldn't appear.
I thought, I've removed all such bugs. But do not have this experience. Do you have a "text" item before each point, line? If yes, this has probably something to do EOLN characters. Do you have the same experience on each operating system?
If I try to zoom in to 200% therion just crashes (64MB machine, 3.8Mb pnm file) Is this expected?
200% of 3.8Mb = 4Mb original image + 16Mb scaled image + 20Mb canvas RGBA buffer = 40MB = 60% of RAM. This may be a problem, especially on some operating systems.
It certainly makes it hard to draw boulders properly as I can;'t do stations very close together. The keys list suggets that I can hold down shift to create a station close to another station, but I have not suceeded - how exactly does it work?
The keys list is wrong - it's Control key :) Thanks.
wishlist items:
It would be _really_ good to have png support in Xtherion? GIFs are a pain for free software and pnm and ppm are huge. What needs to be done?
Tcl/Tk supports only these file types. But: Install Img plug-in into your Tcl installation. On Win32 ActiveTcl it's included. Add "package require Img" into your xtherion.ini file - and you'll be able to use all image files :))) (I've tryied it now and it worked - I was just too lazy before) Please let me know, if you will find out the linux version of this plug-in - it would be very usefull also for us :) OK, I'll add these two things to xtherion and if Img plug-in will be detected, all image file types will be supported also in the image open window.
Shortcuts for moving things between scraps would be helpful, otherwise it's 'move down' about 100 times. Is there a better way?
Right. No way right now. I'll think about it (adding a button move to scrap).
Entering stations - ther is a space for 'id' but not name, which you need to enter for every station. Indeed why is the id not the name?
This is hard to explain, may be later.
It's very tedious if you need to change a number of entries - need shortcuts to move between boxes in RH-side or to scroll up and down items in the file summary. e.g if you need to change all the station ids to names. Need to be able to navigate file commands with keys.
We have in our minds building much more intuitive user interface, but... Anyway, you can use text editor and regular expressions find and replace...
graphical stuff
Air drafts need to be able to specify number of ticks - this is used to indicate wind strength
The QMs ('continuation point) come out really small on my survey. Where do I control the size?
Can be done via changing the metapost codes (and using scale option - may be, scale option works already now (I'm not sure - you can try) for the wind ticks). We will write something to this later.
The debris area symbol looks terrible. I want a quick way to fill in areas of rocks - needs randomised rocks of some sort with controls over size and density. Tunnel (java) has good code for this, with an arrow that control desity gradient. Borrow code?
Firstly, we had randomized symbols in therion. Than we've removed them and we're using only symbols (in most cases, it's enought). In the last time, we're again on a way to put them back to therion - so any ideas in this field are welcome.
Areas need some way of working out if they are 'connected' or not. The current scheme is hopeless - very cryptic messages which give no clue which area is at fault. Editing them is a real pain as you find the text in the file (takes a while, especially with all the blank ones) but then as soon as you click on a line to adjust it you lose the text again. An entry method that lets you 'group' some lines into an area might be best - especially if it auto-allocated the names.
This is already in TODO list.
There is a real problem with editing a file and using xtherion at the same time - even F1 and F2 type editing. Therion just saves the map version over any other version you might have created. It needs to check for 'newer on disk' or something. Until the map interface is better there is a real need to edit the file by hand too. This is a tricky problem but it definately needs work before many people will use it.
Right.
Ticks are too close together on pitches.
How do I change the default for contour lines to al have 'none' (no downside tick mark)? I don't want to add -tick none on every contour - I want to set a default.
Again, you have to edit metapost code, and than in the layout use symbol-set CUCC :)
How does the slope line symbol work? It just seemst od raw a lot of overlapping lines for me. How does it differ from the contour line?
This is complicated, and there are also some bugs in metapost code. We will write about this later. Last thing: thanks a lot for your feedback. We'll think about it a lot... S.
Answers to your questions part II:
When a created file is re-read every blank line gets a 'text' entry in the file commands section, and when saved ends up as 3 blank lines - whitespace text entries shouldn't appear.
??? I've been trying this, but without success. No blank lines converted to text appeared? Could you please send me one th2 file, where there is a lot of text entries?
Entering stations - ther is a space for 'id' but not name, which you need to enter for every station. Indeed why is the id not the name?
-id identifies the object it self (joins for example refer to id's). -name is a reference to survey station - it can not be ID, bacause you can not have two objects with the same ID in the same survey.
Air drafts need to be able to specify number of ticks - this is used to indicate wind strength
OK, the -scale does not work now. But the symbol can be easily redefined to change the number of ticks and not the size.
The debris area symbol looks terrible. I want a quick way to fill in areas of rocks - needs randomised rocks of some sort with controls over size and density. Tunnel (java) has good code for this, with an arrow that control desity gradient. Borrow code?
We will start working on this in the next release.
How does the slope line symbol work? It just seemst od raw a lot of overlapping lines for me. How does it differ from the contour line?
Click the l-size switch for one line point (optionally also orientation) and set the size to the desired slope width. This symbol generates gradient lines perpendicular (or in orientation) to main line with given size. S.
+++ Stacho Mudrak [04-02-11 09:47 +0100]:
I'm sorry, currently I'm short of time, but I'll try to write down at least some comments.
How do I control overlap at joins? I have drawn a couple of scraps and at the place where they join there are contour lines on one scrap and ceilinglines on another that sort of intermingle. When drawn up therion put one scrap on top of the other and invents a 'join line' that covers quite a lot of the neighboring scrap. I need transparency, or a complex 'join line'. What is the best way to deal with this? Do scraps have to have perfect joins? Can I draw a join line?
I'm sorry, but this I do not understand :((( Could you please draw me exactly what you have in your mind?
I have put a picture of a screen shot of the scrap join and the resulting PDF image online to illustrate how one scrap cuts off parts of the other at the join - how should this be done to produce a satisfactory effect? see http://www.chaos.org.uk/~wookey/stacho/
Joining two scraps together covers only joining the walls - not the lines inside. They can be joined only by detail specification, you mentioned below.
OK - I hadn't appreciated that - this is important if there are features in the passage at the joins. Is it a requirment that there must be no passage features at the join that could be misaligned? If a whole cave has rocks or sand on the floor this could be a problem.
Also I tried to control the join in more detail by specifying that the ends of lines join but the syntax didn't work. What's wrong with this: join farsidewest:0@farside2.river farsidewest2:end@farside.river (farsidewest are farsidewest2 are 'wall' lines).
Nothing - it should work. If it does not - it's certainly a bug. Does therion generates an error or it simply does not join the lines? Did you tried this without :point specification (just farsidewest@farside2.river farsidewest2@farside.river)? This should work also.
Therion generates an error. 'invalid object name', but some more research on the various options shows that I get: join farside@river farside2@river works OK (except that it joins one (the south) wall of farside2 to a nearby column (the nearest wall) which is just wrong. join farsidewest1@farside.river farsidewest2.farside2@river Gives 'survey farside.river does not exist' - which is right but I mean scrap farside within survey river - have I got the syntax wrong? join [fsceil1:0]@farside.river [farsidewest3:8]@farside2.river 'invalid object name' - but mnaybe this is the same problem as the line above The best reuslt is obtained with no 'join' at all but then the walls don't quite join up (which is odd because the scraps are drawn on a survex plot and thus acurately scaled - the walls should join up almost exactly anyway...)
In the test editor, using above: data normal left right up down newline tape compass clino and then 'scan format' to get data table to have correct boxes is OK but when you enter data it appears as tape compass clino station left right up down which is the wrong order.
This is not a bug.
OK. I'll think about that a bit more - it not important.
When a created file is re-read every blank line gets a 'text' entry in the file commands section, and when saved ends up as 3 blank lines - whitespace text entries shouldn't appear.
I thought, I've removed all such bugs. But do not have this experience. Do you have a "text" item before each point, line? If yes, this has probably something to do EOLN characters. Do you have the same experience on each operating system?
I only tried it on Linux. I just tried again loading the fale and saving, but making no changes with 0.2.18 and the problem did not recurr. Maybe I have to make changes - maybe it is fixed - I'll send you an example if I can reproduce it. The file has LF only throughout.
If I try to zoom in to 200% therion just crashes (64MB machine, 3.8Mb pnm file) Is this expected?
200% of 3.8Mb = 4Mb original image + 16Mb scaled image + 20Mb canvas RGBA buffer = 40MB = 60% of RAM. This may be a problem, especially on some operating systems.
OK. So there is a need for original scans to be quite small, or lower colour depth (I have to scan greyscale because my scanner/software does not work properly in b/w). Now I'll reduce the colour depth of all the images and maybe chop them up for therion editing, because zoom is important and it's _very_ slow to load. I also just bought 128MB more ram, which should help. Presumably the software could be made to manage larger images better (like photo-editing software can load file _much_ bigger than the available memory). a 4MB scan shouldn't be 'too large to zoom' - it will catch users out. Perhaps the zoom should only attemtp to zoom the visible part of the image, not the whole thing. That would be sensible use of resources. Is this a TCL feature that it will be hard to change?
Tcl/Tk supports only these file types. But:
Install Img plug-in into your Tcl installation.
OK - I'll try and find it. It's not obviously part of Debian, but it may well be there somewhere.
Shortcuts for moving things between scraps would be helpful, otherwise it's 'move down' about 100 times. Is there a better way?
Right. No way right now. I'll think about it (adding a button move to scrap).
And a key! there are nothing like enough keyboard shortcuts. Mice are nasty and give you RSI :-)
It's very tedious if you need to change a number of entries - need shortcuts to move between boxes in RH-side or to scroll up and down items in the file summary. e.g if you need to change all the station ids to names. Need to be able to navigate file commands with keys.
We have in our minds building much more intuitive user interface, but...
Anyway, you can use text editor and regular expressions find and replace...
Except for the fact that you have to unload the map editor first otherwise it will overwrite them, and then you can't remember which objects to edit... And because it takes 2-3mins to load again I don't like unloading and loading it each time to make an edit. Smaller scans will help, as will more memory, but there does need to be a better way if drawing a survey is to take less than 100 years :-)
graphical stuff
Last thing: thanks a lot for your feedback. We'll think about it a lot...
thanx for taking it all seriously. I think we are getting to something that is useful, but various things are still too difficult or too slow. I'll send you the article text so far by the way, so you can check I didn't say anything wrong. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
I have put a picture of a screen shot of the scrap join and the resulting PDF image online to illustrate how one scrap cuts off parts of the other at the join - how should this be done to produce a satisfactory effect?
You may use `-clip off' option for all objects which shouldn't be clipped by the scrap border. However, it would be best to choose places for scrap joins where the passage is as simple as possible -- this saves a lot of work on defining IDs and joins for each object lying on the scrap join line.
Therion generates an error. 'invalid object name', but some more research on the various options shows that I get: join farside@river farside2@river works OK (except that it joins one (the south) wall of farside2 to a nearby column (the nearest wall) which is just wrong. join farsidewest1@farside.river farsidewest2.farside2@river Gives 'survey farside.river does not exist' - which is right but I mean scrap farside within survey river - have I got the syntax wrong?
Scraps don't create own namespace -- only surveys do. So join farside@river farside2@river is a variant of join which joins two scraps, and join farsidewest1@farside.river farsidewest2.farside2@river should be join farsidewest1@river farsidewest2@river
If I try to zoom in to 200% therion just crashes (64MB machine, 3.8Mb pnm >file) Is this expected? 200% of 3.8Mb = 4Mb original image + 16Mb scaled image + 20Mb canvas RGBA buffer = 40MB = 60% of RAM. This may be a problem, especially on some operating systems.
OK. So there is a need for original scans to be quite small, or lower colour depth (I have to scan greyscale because my scanner/software does not work properly in b/w). Now I'll reduce the colour depth of all the images and maybe chop them up for therion editing, because zoom is important and it's _very_ slow to load. I also just bought 128MB more ram, which should help.
I'm afraid TclTk uses RGB model internally, so it converts even b/w images into RGB anyway. I've been using XTherion on Athlon 2000 with 512 MB RAM. It works quite well and fast with more 100 dpi scans in one file (about 1000*500 pixels each) @ 200% zoom.
And because it takes 2-3mins to load again I don't like unloading and loading it each time to make an edit. Smaller scans will help, as will more memory, but there does need to be a better way if drawing a survey is to take less than 100 years :-)
We are fully aware of the fact, that XTherion and espacially TclTk language is not ideal. It would be nice to make a completely new interface (which may be devoloped parallel with therion and xtherion), but it would require a lot of help from other programmers, too. We've put some ideas on http://labyrinth.speleo.sk Martin
Presumably the software could be made to manage larger images better (like photo-editing software can load file _much_ bigger than the available memory). a 4MB scan shouldn't be 'too large to zoom' - it will catch users out.
I'm afraid, reducing memory usage would increase the processor usage. The only way how to solve this problem is hardware update. We've been programming therion with 150MHz and 48MB RAM. But when we started to enter real data - we were forced to upgrade. Now it looks, that 2GHz and 512MB ram is OK for A4 scans at 100dpi.
Perhaps the zoom should only attemtp to zoom the visible part of the image, not the whole thing. That would be sensible use of resources. Is this a TCL feature that it will be hard to change?
This would take too much effort... Handling bitmap images in TCL is very limited. Anyway, you can spit images by your self in Photoshop or Gimp and turn on/off selected pictures visibility (last check box in the [Background images]). We've done it this way and it helped us a lot. In the file menu, there is also option Open XP (Excluding pictures). This is also very usefull for debugging.
And a key! there are nothing like enough keyboard shortcuts. Mice are nasty and give you RSI :-)
Could you please write down all the key-bindings (with exact keys) you would like to have in xtherion. Than I can add them in the next release. S.
The QMs ('continuation point) come out really small on my survey. Where do I control the size?
Ticks are too close together on pitches.
I've noticed (in the file soundriverpln.pdf), that you're using scale 1:200 even if it's really a huge cave (you've probably been mapping in 1:500 or even smaller scale). When exporting such a large caves, you should use the scale, you've been mapping in (1:500) or if you want to have bigger symbols in the 1:200 scale, specify -layout-base-scale 1 500 - than each symbol will be 2.5x bigger (including QM and pitch ticks). Another point - in the layout: scale and base-scale is specified like: scale 1 500 I believe, the number "1" is not needed there, and probably scales should be specified just by number 500 (I've never seen on any map scale 2:1000 or something like that). What do you think?
How do I change the default for contour lines to al have 'none' (no downside tick mark)? I don't want to add -tick none on every contour - I want to set a default.
In the new version of therion, this will be default. So you can forget about this. I know changing default behaviour is not standard way, but in this case, I believe it will help. Regards, S.
+++ Stacho Mudrak [04-02-23 09:57 +0100]:
The QMs ('continuation point) come out really small on my survey. Where do I control the size?
Ticks are too close together on pitches.
I've noticed (in the file soundriverpln.pdf), that you're using scale 1:200 even if it's really a huge cave (you've probably been mapping in 1:500 or even smaller scale). When exporting such a large caves, you should use the scale, you've been mapping in (1:500) or if you want to have bigger symbols in the 1:200 scale, specify -layout-base-scale 1 500 - than each symbol will be 2.5x bigger (including QM and pitch ticks).
OK - yes 1:200 must be a default? I normally use 1:500. For this system 1:1000 or 1:2000 will be appropriate. Well spotted.
Another point - in the layout: scale and base-scale is specified like:
scale 1 500
I believe, the number "1" is not needed there, and probably scales should be specified just by number 500 (I've never seen on any map scale 2:1000 or something like that). What do you think?
I have never seen 2:<anything> either, so I suppose you are right, but "scale 1 500" is perhaps more obvious than "scale 500" to a surveyor so maybe just leave it even though it is not very satisfactory from a computer-science point of view? I am not sure.
How do I change the default for contour lines to al have 'none' (no downside tick mark)? I don't want to add -tick none on every contour - I want to set a default.
In the new version of therion, this will be default. So you can forget about this. I know changing default behaviour is not standard way, but in this case, I believe it will help.
Except now people who _do_ want a tick on every contour will need to add -tick each time. This doesn't really address the problem of setting defaults for things like this. Does the UIS symbol set have ticks on contours? I know defaults should be set by specifying a symbol set, but that is going to be difficult for 'most users' who don't want to get into writing MetaPost. Once we have a wide choice of symbol sets than most people should be happy I suppose, but I think many surveyors like to have a few little 'artisitic differences' in their surveys and not always use _all_ the standard symbols. Something to think about. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
OK - yes 1:200 must be a default? I normally use 1:500. For this system 1:1000 or 1:2000 will be appropriate. Well spotted.
Well, we're surveying caves where passage is in average 2m width, so we've set up this scale as default. Anyway, I'll think how to set up default layout (including symbols and all other stuff) in therion.ini. This should be the solution I believe.
Except now people who _do_ want a tick on every contour will need to add -tick each time. This doesn't really address the problem of setting defaults for things like this. Does the UIS symbol set have ticks on contours?
I know defaults should be set by specifying a symbol set, but that is going to be difficult for 'most users' who don't want to get into writing MetaPost. Once we have a wide choice of symbol sets than most people should be happy I suppose, but I think many surveyors like to have a few little 'artisitic differences' in their surveys and not always use _all_ the standard symbols. Something to think about.
Yes, you're right. Martin also pointed me this problem, so we've left behaviour on the macro. Now it decides, whether to put tick or not, if no user wish is present. Now two macros exists: l_contour_SKBB (with tick by default) and l_contour_UIS (without tick by default). I think, we will be able to live for a while with this state. So if you will use -layout-symbol-set UIS, no contour ticks should be present (I believe, this afternoon we will put on the server new developement release). S.
bugs:
In .th files - if you use data normal ignore ignore ignore ignore newline tape compass clino then every LRUD line must be followed by a data line, including the last one If you s/ignore ignore ignore ignore/left right up down/ then it ignores absence of TCC part in the last line, but not in lines in the middle of a run. This is inconsistnet with survex behaviour (which will let you give LRUD info for a station and then stop - without subsequent TCC info)
I've started work on 3D on weekend, and I do not understand what you've written. I've tried centreline data normal station up down left right newline compass clino tape 0 2 3 4 5 100 -10 10 1 1 2 3 4 endcentreline and it works (in therion). Probably, I've not understood what is inconsistent behaviour. Could you please send me some examples? I would be also interested in, how should "data dimenstions" work. Regards, S.
participants (4)
-
Martin Budaj -
Martin Sluka -
Stacho Mudrak -
Wookey