Embedded image does not appear in some layouts
Here is a puzzle ... I have set up a thconfig file to create a profiles map, then used the "map-image" layout directive to include it in the output files. It works ... SOMETIMES! Take a look at the thconfig file embedded below. The profiles image appears on the files produced from the MainMap and MainMapNoColor layouts. It does not appear on MainMapPrint. Why? Does it have something to do with the TeX code in MainMapPrint? Thanks! -- =============== Bill Gee encoding utf-8 # Bring in the main configuration file source GeronimoSpringsCave.th # Used for most of the maps select GeronimoSpringsCave # Load the Metapost code for custom symbols input ../TherionMasterFiles/CustomSymbolsCode.txt # Bring in the code for custom scale bar input ../TherionMasterFiles/ScaleBarCode.txt # This layout is for the main 2D map, all on one page layout basics language en_US units imperial scale-bar 50 feet page-numbers on scale 1 200 north true symbol-color area water [0 0 100] map-comment "A DistoX survey of Geronimo Springs Cave (CAM-086), Missouri" statistics explo all legend on map-header 3 60 w symbol-set UIS # Set point height symbols to be enclosed in boxes code metapost p_label_mode_height:=6; endcode # Section for PDF properties doc-author "Bill Gee" doc-title "Map of Geronimo Springs Cave (CAM-086)" doc-subject "Plan map of Geronimo Springs Cave (CAM-086)" # Section for map photos # Add in the elevations maps # Bring in the custom symbols copy CustomSymbols # Bring in the custom scale bar copy CustomScaleBar # Reassign names symbol-assign point gradient AMER symbol-assign point stalagmite AMER symbol-assign point stalactite AMER symbol-assign point pillar AMER symbol-assign point popcorn AMER endlayout # This layout is for profile maps. It turns off the legend and other stuff layout profiles legend off map-header 0 0 off symbol-hide group centerline color map-fg [100 86 66] endlayout layout MainMapPrint copy basics scale 1 200 debug off symbol-hide group centerline color map-fg [100 86 66] # Entrance passage profile map-image 0 0 sw GeronimoSpringsCave-Profiles.pdf # Change the size of the legend code metapost tmpscale=1.3; def draw_legend_box = % Next line controls size of symbol in each symbol table box currentpicture := currentpicture scaled tmpscale; % Next line controls size of symbol table box background clip currentpicture to unitsquare inscale xscaled tmpscale yscaled tmpscale; drawoptions(); pickup PenB; % I think the next line controls the size of each symbol table box draw unitsquare inscale xscaled tmpscale yscaled tmpscale; enddef; %clear the background of the larger legend boxes def clean_legend_box = unfill unitsquare inscale xscaled tmpscale yscaled tmpscale; enddef; %change the value of inscale to fill the legend boxes def inscale = xscaled (legend_scale*tmpscale) yscaled (0.618*legend_scale*tmpscale) enddef; endcode code tex-map \def\maplayout{ \legendbox{3}{85}{W}{ \def\txtsize{16} % Define the default text size \legendwidth=20 cm \legendtextsectionsize={\size[\txtsize]} \legendtextsize={\size[\txtsize]} \legendtextheadersize={\size[40]} \hsize=\legendwidth \the\legendcontent={\size[\txtsize]} \the\legendtextsize\ Map generated at \the\time \the\currentdate\medskip \the\legendtextsize\ Therion version \the\thversion } } endcode #end of TeX code to change legend size endlayout # Layouts to specify colors layout MainMapNoColor copy basics color map-fg [100 86 66] # Entrance passage profile map-image 0 0 sw GeronimoSpringsCave-Profiles.pdf endlayout layout MainMapColorized copy basics color map-fg altitude # Entrance passage profile map-image 0 0 sw GeronimoSpringsCave-Profiles.pdf endlayout # Change the legend callouts input ../TherionMasterFiles/LegendCallouts.txt # Profiles map export map -proj elevation -layout profiles -o GeronimoSpringsCave-Profiles.pdf # Basic plan map, normal colors export map -proj plan -layout MainMapNoColor -o GeronimoSpringsCave.pdf # Map with no centerline export map -proj plan -layout MainMapPrint -o GeronimoSpringsCave-Print.pdf # Basic plan map, colorized for elevations export map -proj plan -layout MainMapColorized -o GeronimoSpringsCaveColored.pdf # 3D map for use with Loch export model -fmt loch -o GeronimoSpringsCave.lox # 3D map for use with Aven export model -fmt 3d -o GeronimoSpringsCave.3d # 3D map for use with ArcGIS export model -fmt esri -o ./GeronimoSpringsCave-ESRI # KML file for overlay in Google Earth - Requires lat-long specified in the survey data file export map -proj plan -fmt kml -o GeronimoSpringsCave.kml # Produce the debug maps system "/usr/local/bin/therion -l therion-Debug.log thconfig-Debug"
Bill I think def\maplayout{ redefines completely what is exported, and so any map-image statements will silently fail. Page 76 of the Therion Book explains somewhat. So if your def\maplayout does not have an equivalent of map-image , then each time it is called your map-image will be ignored. Here is an example where I have done what I think you are after. code tex-map #this snippet intended for a minimal plan pdf with 'map-image' that will later be inserted into an elevation pdf \savepath{mypath1}{"Laghu-kmlSurface-Dec2022.png"} %#save relative path to file to absolute path \def\maplayout{ \legendbox{73}{120}{NW}{\loadpicture{mypath1}} %#equivalent of map-image \ifnortharrow\legendbox{130}{20}{E}{\northarrow}\fi %#now insert a north arrow if appropriate } endcode A slightly less elegant version of this solution is described here https://therion.speleo.sk/wiki/tex?s%5b%5d=tex&s%5b%5d=map#changing_the_look _or_layout_of_a_map_output I hope one day to be completely free of the constraints imposed of 'map-header', and it is possible that the example above is the last missing piece of the puzzle for me. However doing everything by def/maplayout does make it complicated when the boundaries of the cave are extended or multiple outputs at different scales are required. There are a lot of {x}{y}{anchor} parameters to juggle. Bruce -----Original Message----- From: Therion <therion-bounces@speleo.sk> On Behalf Of Bill Gee Sent: Thursday, 13 February 2025 04:49 To: Therion Mail List <therion@speleo.sk> Subject: [Therion] Embedded image does not appear in some layouts Here is a puzzle ... I have set up a thconfig file to create a profiles map, then used the "map-image" layout directive to include it in the output files. It works ... SOMETIMES! Take a look at the thconfig file embedded below. The profiles image appears on the files produced from the MainMap and MainMapNoColor layouts. It does not appear on MainMapPrint. Why? Does it have something to do with the TeX code in MainMapPrint? Thanks! -- =============== Bill Gee ... code tex-map \def\maplayout{ \legendbox{3}{85}{W}{ \def\txtsize{16} % Define the default text size \legendwidth=20 cm \legendtextsectionsize={\size[\txtsize]} \legendtextsize={\size[\txtsize]} \legendtextheadersize={\size[40]} \hsize=\legendwidth \the\legendcontent={\size[\txtsize]} \the\legendtextsize\ Map generated at \the\time \the\currentdate\medskip \the\legendtextsize\ Therion version \the\thversion } } endcode
Hi Bruce - Thanks! I had to fiddle with it a bit, but it works exactly as I want. Here is the TeX code I came up with: ===================== code tex-map \savepath{ProfilesPath1}{"GeronimoSpringsCave-Profiles.pdf"} \def\maplayout{ \legendbox{3}{85}{W}{ \def\txtsize{16} % Define the default text size \legendwidth=20 cm \legendtextsectionsize={\size[\txtsize]} \legendtextsize={\size[\txtsize]} \legendtextheadersize={\size[40]} \hsize=\legendwidth \the\legendcontent={\size[\txtsize]} \the\legendtextsize\ Map generated at \the\time \the\currentdate\medskip \the\legendtextsize\ Therion version \the\thversion } \legendbox{0}{0}{SW}{\loadpicture{ProfilesPath1}} } endcode ===================== You mentioned constant fiddling with the {x}{y}{anchor} parameters as the map changes. That is the reason I save photos and profiles for the very end of a cartography project. I really like Therion, but its handling of profiles leaves a LOT to be desired. I have done several maps where the profiles were treated like cross-sections. In a way they are a cross-section, so that method is not entirely wrong. The main problem with it is when I want to join multiple profile scraps. So far I have drawn only one section of profile for this map. I will have some others. Finding a way to create a different .pdf file for them could be interesting. I suspect I will have to create thconfig/.th files specifically for the profiles, and each different section of profile will have to be defined in a "map" directive. For this map I am already doing that to generate a debug version of the map. A thconfig file can have exactly ONE "select" directive, and that does not work when generating a debug map. =============== Bill Gee On 2/13/25 01:40, Bruce Mutton wrote:
Bill I think def\maplayout{ redefines completely what is exported, and so any map-image statements will silently fail. Page 76 of the Therion Book explains somewhat. So if your def\maplayout does not have an equivalent of map-image , then each time it is called your map-image will be ignored.
Here is an example where I have done what I think you are after.
code tex-map #this snippet intended for a minimal plan pdf with 'map-image' that will later be inserted into an elevation pdf \savepath{mypath1}{"Laghu-kmlSurface-Dec2022.png"} %#save relative path to file to absolute path \def\maplayout{ \legendbox{73}{120}{NW}{\loadpicture{mypath1}} %#equivalent of map-image \ifnortharrow\legendbox{130}{20}{E}{\northarrow}\fi %#now insert a north arrow if appropriate } endcode
A slightly less elegant version of this solution is described here https://therion.speleo.sk/wiki/tex?s%5b%5d=tex&s%5b%5d=map#changing_the_look _or_layout_of_a_map_output
I hope one day to be completely free of the constraints imposed of 'map-header', and it is possible that the example above is the last missing piece of the puzzle for me. However doing everything by def/maplayout does make it complicated when the boundaries of the cave are extended or multiple outputs at different scales are required. There are a lot of {x}{y}{anchor} parameters to juggle. Bruce
-----Original Message----- From: Therion <therion-bounces@speleo.sk> On Behalf Of Bill Gee Sent: Thursday, 13 February 2025 04:49 To: Therion Mail List <therion@speleo.sk> Subject: [Therion] Embedded image does not appear in some layouts
Here is a puzzle ... I have set up a thconfig file to create a profiles map, then used the "map-image" layout directive to include it in the output files. It works ... SOMETIMES!
Take a look at the thconfig file embedded below. The profiles image appears on the files produced from the MainMap and MainMapNoColor layouts. It does not appear on MainMapPrint.
Why? Does it have something to do with the TeX code in MainMapPrint?
Thanks!
-- =============== Bill Gee
... code tex-map \def\maplayout{ \legendbox{3}{85}{W}{ \def\txtsize{16} % Define the default text size \legendwidth=20 cm \legendtextsectionsize={\size[\txtsize]} \legendtextsize={\size[\txtsize]} \legendtextheadersize={\size[40]} \hsize=\legendwidth \the\legendcontent={\size[\txtsize]} \the\legendtextsize\ Map generated at \the\time \the\currentdate\medskip \the\legendtextsize\ Therion version \the\thversion } } endcode
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
The main problem with it is when I want to join multiple profile scraps.
This is no different than plan view. I have plenty of profile scraps. I just make sure to avoid confusion by naming my scraps with their orientation in the scrap names to keep it clear to myself which belong where: fooSE256 Then the parent file has: join fooSE256@entarea barSE256@longbypass and: map elevationME256 -projection [elevation 256] -title "MyCave Elevation" entareaME256@entarea #map of the scraps in entarea longbypassME256@longbypass endmap
So far I have drawn only one section of profile for this map. I will have some others. Finding a way to create a different .pdf file for them could be interesting.
I have a separate .thconfig for each, which selects the relevant map and exports it as a PDF: Elevation256.thconfig Elevation120.thconfig Then I have AllVersions.thconfig which contains this: system """C:\Program Files (x86)\Therion\therion.exe"" Elevation256.thconfig" system """C:\Program Files (x86)\Therion\therion.exe"" Elevation120.thconfig" ... (These commands are a lot more readable if you put Therion in your %PATH%, or if you are using Linux.) Then I combine these into a single survey PDF by embedding the images, or into a PDF with one survey per page (using pdftk or pdfjam). Whichever .thconfig file produces the combined PDF is always the last one that gets run by AllVersions.thconfig
Hi Tarquin - I dislike using extended elevations. The folding that is done to create the perspective really messes with the presentation. Plain unfolded elevations are, I think, much more useful. My comment about joining elevations was related to treating them like cross-sections. I suspect that scraps of "projection none" cannot be joined. If they can be joined, then what is the scrap name to use as parameter to the section point? Keeping track of multiple thconfig files is a pain. As a big-picture item - I think that should not be necessary. The fact that it IS necessary points to some needed improvements. In an ideal world there should never be a need for more than one thconfig file for each map project. I use Linux, so the issues with system path are less of a problem for me. =============== Bill Gee On 2/13/25 08:08, Tarquin Wilton-Jones via Therion wrote:
The main problem with it is when I want to join multiple profile scraps.
This is no different than plan view. I have plenty of profile scraps. I just make sure to avoid confusion by naming my scraps with their orientation in the scrap names to keep it clear to myself which belong where:
fooSE256
Then the parent file has: join fooSE256@entarea barSE256@longbypass and: map elevationME256 -projection [elevation 256] -title "MyCave Elevation" entareaME256@entarea #map of the scraps in entarea longbypassME256@longbypass endmap
So far I have drawn only one section of profile for this map. I will have some others. Finding a way to create a different .pdf file for them could be interesting.
I have a separate .thconfig for each, which selects the relevant map and exports it as a PDF: Elevation256.thconfig Elevation120.thconfig
Then I have AllVersions.thconfig which contains this:
system """C:\Program Files (x86)\Therion\therion.exe"" Elevation256.thconfig" system """C:\Program Files (x86)\Therion\therion.exe"" Elevation120.thconfig" ...
(These commands are a lot more readable if you put Therion in your %PATH%, or if you are using Linux.)
Then I combine these into a single survey PDF by embedding the images, or into a PDF with one survey per page (using pdftk or pdfjam). Whichever .thconfig file produces the combined PDF is always the last one that gets run by AllVersions.thconfig _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
I dislike using extended elevations. The folding that is done to create the perspective really messes with the presentation. Plain unfolded elevations are, I think, much more useful.
I was not talking about extended elevations. I was talking about projected elevations. They are projected on a specific bearing. That is exactly what you are asking for, I think. I export a new .xvi on my chosen bearing: export map -projection [elevation 256] -fmt xvi -output "somesurvey/somesurvey elevation256.xvi" Then I create a new .th2 for that, and draw the passage ceiling and floor as scraps, the same way you would normally draw walls in plan view. Make sure each scrap has "-projection [elevation 256]", and I name my scraps accordingly. Input that in my .th: input "somesurvey elevation256.th2" Add a map with "-projection [elevation 256]" and add all the relevant scraps to it. Extended elevation ("-projection extended") normally for potholes and some caves. Projected elevation ("-projection [elevation 256]") for caves where you want to maintain the horizontal relationship between passages. I use it for metal mines with multiple levels.
My comment about joining elevations was related to treating them like cross-sections. I suspect that scraps of "projection none" cannot be joined.
I don't know if you can. I have never done so. Since it relies on you positioning them at certain coordinates within other scraps of the main projection, it probably would not be possible.
Keeping track of multiple thconfig files is a pain. As a big-picture item - I think that should not be necessary. The fact that it IS necessary points to some needed improvements.
I very much agree. I would dearly love for .thconfig to have something like: selection select map1@mycave ...do things... endselection selection select map2@mycave ...do things... endselection Really hate having to maintain several different .thconfig files and link them together. But until such a thing exists, I use what I use :)
Tarquin, I had confused the meaning of "extended" and "elevation" scraps. What I really want is "elevation" where there is no projection on a specific bearing. I completely agree with your wish about the handling of select/unselect pairs. Maybe in version 7 ??? =============== Bill Gee On 2/13/25 10:14, Tarquin Wilton-Jones via Therion wrote:
I dislike using extended elevations. The folding that is done to create the perspective really messes with the presentation. Plain unfolded elevations are, I think, much more useful.
I was not talking about extended elevations. I was talking about projected elevations. They are projected on a specific bearing. That is exactly what you are asking for, I think.
I export a new .xvi on my chosen bearing: export map -projection [elevation 256] -fmt xvi -output "somesurvey/ somesurvey elevation256.xvi" Then I create a new .th2 for that, and draw the passage ceiling and floor as scraps, the same way you would normally draw walls in plan view. Make sure each scrap has "-projection [elevation 256]", and I name my scraps accordingly. Input that in my .th: input "somesurvey elevation256.th2" Add a map with "-projection [elevation 256]" and add all the relevant scraps to it.
Extended elevation ("-projection extended") normally for potholes and some caves.
Projected elevation ("-projection [elevation 256]") for caves where you want to maintain the horizontal relationship between passages. I use it for metal mines with multiple levels.
My comment about joining elevations was related to treating them like cross-sections. I suspect that scraps of "projection none" cannot be joined.
I don't know if you can. I have never done so. Since it relies on you positioning them at certain coordinates within other scraps of the main projection, it probably would not be possible.
Keeping track of multiple thconfig files is a pain. As a big-picture item - I think that should not be necessary. The fact that it IS necessary points to some needed improvements.
I very much agree. I would dearly love for .thconfig to have something like:
selection select map1@mycave ...do things... endselection selection select map2@mycave ...do things... endselection
Really hate having to maintain several different .thconfig files and link them together. But until such a thing exists, I use what I use :) _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Tarquin, I had confused the meaning of "extended" and "elevation" scraps. What I really want is "elevation" where there is no projection on a specific bearing.
OK, this is only slightly different. Much of the process is the same though. If you have a very simple cave, and you have already drawn a perfect extended elevation while you were in the cave, great, you can skip a bunch of steps. However, I find that in the cave, I have no idea how the extended elevation will end up being drawn, so I don't have anything useful, and need to redraw it all when I get out. Firstly, you need to decide whether you start on the left or right of the survey. You probably decided this while you were in the cave (or maybe not), but you will need to re-decide now that you have enough cave data to work out where nasty overlaps happen, and what direction makes most sense. You add the "extend start" and "extend left" or "right" commands for your survey. Then decide where to fold left and right to make the cave most understandable - this is an art form. Decide if some passages need to be shortened or lengthened. Add the commands to change the extend direction as needed, or to scale legs as needed. Keep exporting it as a PDF so you can see how your design looks. It really helps to do this before you have drawn scraps. If you have already drawn scraps ... well ... I have a map like this: map skeletonMEE thecave # that is the survey *not* a map endmap Then this thconfig: layout local code metapost def l_survey_cave (expr P) = T:=identity; pickup PenC; if ATTR__shotflag_splay: thdraw P withcolor (1,0.5,0.5); else: thdraw P; fi; enddef; endcode endlayout source "thecavearea.th" select skeletonMEE@thecavearea export map -proj extended -layout local -o "thecave-skeleton.pdf" That gives me a PDF to see my design. Now, once you are done, export a new XVI, just like I said for the projected elevation, but this time use "extended" as your -projection. Add a .th2 and add it to your .th in the same way (I call mine "surveyeecustom" to show it is one I have customised), create scraps in it as you would for a plan (I name mine somescrapSEE for Scrap Extended Elevation, and use MEE for the maps). From there on, the instructions are basically the same. However, I find that all too often, the extending algorithm points a leg in completely the wrong direction. It is much better than it used to be, but just randomly, it is nonsense. Or it just scales the splays weird. So I often end up looking at it in Survex Aven, seeing "that one looks wrong", then measuring from station to splay in elevation or plan, to work out where it should have pointed, and how far away. (It really depends how much you care.) You will need to refer to the instructions for extended elevations, to see what the "extend" options are. Some really useful stuff got added relatively recently for scaling legs, so you can shrink a passage to 50% of its natural length. And a tonne of other useful options. If you want more than one variation of the extended elevation, eg. with the leg folded left in one, and right in the other ... you are in for a small nightmare, and I will let Bruce help you out, because he has a way to do it. It is not straightforward, because Therion is really designed to have just one extended elevation.
If you want more than one variation of the extended elevation, eg. with the leg folded left in one, and right in the other ... you are in for a small nightmare, and I will let Bruce help you out, because he has a way to do it. It is not straightforward, because Therion is really designed to have just one extended elevation.
I've been on a journey. In 2018 I decided that extend options in-line with the survey data was inadequate and I experimented with moving all extend controls to a separate extended elevation centreline. The reasons and details of how are in https://therion.speleo.sk/wiki/extend?s[]=extend#extended_elevations Almost immediately I started having problems as loops were added to ongoing survey projects. New loops cause existing extended centrelines and drawings to be broken, requiring careful (often time consuming) extend control edits to resolve. Until a few weeks ago I thought the problems were due to my choice to move extend control to separate centrelines outside of the primary survey data enumeration. With my most recent project I decided to go back to leaving extend statements in-line with survey data, for simplicities sake (so I thought). Then I started adding some loops. What I have found leads me to suspect that the in-line and separate centreline choice makes no difference to the problems caused by use of ignore and addition of loops to existing extended centreline development. The 'extended elevation additional loops breaks previous loops' problem is a Therion problem, not 'the way we use Therion' problem. The 'small (extended elevation) nightmare' is associated with multiple loops, not with multiple extended elevations. Which leads me to thinking that the ultimate solution will be to add to Therion a new extended elevation control set when it comes to 'extend ignore'. Rather than saying 'when there is a choice, don't take this path' we should instead say, 'when there is a choice, TAKE this path'. I feel like this would reduce the uncertainty of implying what we want by specifying only one of the options (at a time) that we don't want. Better to directly specify the ONE option we DO want and not care about the possibly many options we don't want. This is especially the case when there are more than three legs meeting at a station. If such a change would make all existing extended elevations incompatible, then having a 'UseNewExtendControl' control in Therion would seem to be a tolerable mitigation. And Therion continues with two extended elevation control sets. So yes, it's not straight forward! :-) Bruce
Wow, that is a serious deep dive! It looks like far more than I need. I don't like to put every single profile on the map, especially for longer caves. It just gets to be too much. You can't see the cave for the profiles! And the cross-sections! As long as we are dreaming about future features - How about a way to spit out a multi-page PDF file with the plan map on one page. A second page (maybe more) can contain the profiles, cross-sections, photos, legend and perhaps other stuff. It would be nice to have a way to break extended profiles into sections so they can be placed at different points around the map. That can sort of be done with elevation profiles by specifying a different perspective angle for each piece. It's a lot of work, though, to keep track of which angle was specified for each section of profile. Another thing that would be nice - A way to draw a line on the plan map which indicates the path shown in a profile. I think it could be done with either a border or a section line with no arrows. I would also like a way to produce a map which has SOME (not all) cross-sections. Right now it is all or nothing. You either get every cross-section or you get no cross-sections. This might be done by using PDF layers and letting the cross-section scrap specify the layer it goes on. How about a new directive called "layer"? This gives the layer a name and perhaps some other properties. Then the layout section can give a list of layers to include. Scraps would have an option to name the layer they go on. =============== Bill Gee On 2/15/25 16:03, Bruce Mutton wrote:
If you want more than one variation of the extended elevation, eg. with the leg folded left in one, and right in the other ... you are in for a small nightmare, and I will let Bruce help you out, because he has a way to do it. It is not straightforward, because Therion is really designed to have just one extended elevation.
I've been on a journey. In 2018 I decided that extend options in-line with the survey data was inadequate and I experimented with moving all extend controls to a separate extended elevation centreline. The reasons and details of how are in https://therion.speleo.sk/wiki/extend?s[]=extend#extended_elevations
Almost immediately I started having problems as loops were added to ongoing survey projects. New loops cause existing extended centrelines and drawings to be broken, requiring careful (often time consuming) extend control edits to resolve. Until a few weeks ago I thought the problems were due to my choice to move extend control to separate centrelines outside of the primary survey data enumeration.
With my most recent project I decided to go back to leaving extend statements in-line with survey data, for simplicities sake (so I thought). Then I started adding some loops. What I have found leads me to suspect that the in-line and separate centreline choice makes no difference to the problems caused by use of ignore and addition of loops to existing extended centreline development. The 'extended elevation additional loops breaks previous loops' problem is a Therion problem, not 'the way we use Therion' problem. The 'small (extended elevation) nightmare' is associated with multiple loops, not with multiple extended elevations.
Which leads me to thinking that the ultimate solution will be to add to Therion a new extended elevation control set when it comes to 'extend ignore'. Rather than saying 'when there is a choice, don't take this path' we should instead say, 'when there is a choice, TAKE this path'. I feel like this would reduce the uncertainty of implying what we want by specifying only one of the options (at a time) that we don't want. Better to directly specify the ONE option we DO want and not care about the possibly many options we don't want. This is especially the case when there are more than three legs meeting at a station. If such a change would make all existing extended elevations incompatible, then having a 'UseNewExtendControl' control in Therion would seem to be a tolerable mitigation. And Therion continues with two extended elevation control sets. So yes, it's not straight forward! :-) Bruce
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
It would be nice to have a way to break extended profiles into sections so they can be placed at different points around the map.
Sure, easy enough. Create them as maps, just like you would do if you wanted partial plans. map shiningcave -projection extended -title "Shining Cave elevation" entareaMEE@entarea shiningpitchesMEE@shiningpitches ... endmap map beetlecave -projection extended -title "Beetle Cave elevation" crayonsMEE@crayons wetcrawlsMEE@wetcrawls ... endmap In your .thconfig, select whichever map you want to output. Output it as a PDF. Embed it in your main plan view, just like you would embed any other image.
which angle was specified for each section of profile.
Extended elevations have no angle. They are an *extended* side view. Projected elevations have an angle - the cave from a specific direction. With a projected elevation, you need to make sure you always export the same bearing. It's awkward with big caves.
I think it could be done with either a border or a section line with no arrows.
I created a l-u-route for showing routes. It draws dots along the route. You could do something similar. If you just want to draw it as a solid line, then the MetaPost can just pick up a pen, and draw the path with it. (That's the easiest. Dots is a dashed line, but I have done a load of calculations in the MetaPost to avoid drawing half a dot, so the code is quite long.)
I would also like a way to produce a map which has SOME (not all) cross-sections.
Put them in different scraps instead of putting them all in the main plan scraps. Eg. "mainsectionsSP" and "lessersectionsSP". Each scrap you put them in should reuse a few stations so they all get scaled and positioned correctly. Then your map should add the appropriate scrap just like it adds any other scrap.
On 19/02/2025 15:58, Bill Gee wrote:
I would also like a way to produce a map which has SOME (not all) cross- sections. Right now it is all or nothing. You either get every cross- section or you get no cross-sections. This might be done by using PDF layers and letting the cross-section scrap specify the layer it goes on.
You can sort of do this with -attr <name> <value>. <name> Then use this in metapost p36 thbook You can test presence of such a variable using if known ATTR_<name>: ... fi. However, my metapost was not good enough and I kept getting bugs. So I used python to pull them out, then removed the ones I wanted. I thought I had put the code online, but cannot find it! However, the use of attr would work better if symbol-hide worked for it. Unfortunately I do not think that it does. You could abuse the system by abusing the -context option and setting it to a symbol you do not use then turn that off with symbol-hide. Andrew
I really feel, we need a "true" way of specifying how to hide/select things for various outputs. Some kind of optional selector attribute inherent to any symbol, without affecting or misuing the other settings. This cuold also be used to hide/select symbols based on scale (which is currently kind-of-supported by using the symbol size - which I cannot use beause I need that for actual sizing of stuff). A quick Idea could be: 1. untagged elements are always printed 2. tagged elements only if they are selected in the thconfig 3. actual systematic is user-defined, so we have maximum flexibility. For example, I could imagine mixing several systematics, one for desired output scale and another for special purposes: --------- thconfig -------- select tag scale:250 select tag scale:500 select tag remarks select tag crossSections:abc export map .... --------------------------- In the th2's I just tag the items with "-tag scale:500" or "-tag crossSections:abc" (or both). This would completely (and optionally) decouple the show/hide from internal magic and support various usecases out of the box. One just needs to think of a good tagging systematic for his usecases/dataset. Am 2025-02-19 17:29, schrieb Andrew Atkinson:
On 19/02/2025 15:58, Bill Gee wrote:
I would also like a way to produce a map which has SOME (not all) cross- sections. Right now it is all or nothing. You either get every cross- section or you get no cross-sections. This might be done by using PDF layers and letting the cross-section scrap specify the layer it goes on.
You can sort of do this with -attr <name> <value>. <name> Then use this in metapost
p36 thbook You can test presence of such a variable using if known ATTR_<name>: ... fi.
However, my metapost was not good enough and I kept getting bugs. So I used python to pull them out, then removed the ones I wanted. I thought I had put the code online, but cannot find it!
However, the use of attr would work better if symbol-hide worked for it. Unfortunately I do not think that it does.
You could abuse the system by abusing the -context option and setting it to a symbol you do not use then turn that off with symbol-hide.
Andrew _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
To follow up on this "tas" idea; I really want to discuss this and opened an issue ticket for that: https://github.com/therion/therion/issues/640 What is your opinion on such a feature? Am 2025-02-19 18:02, schrieb Benedikt Hallinger via Therion:
I really feel, we need a "true" way of specifying how to hide/select things for various outputs. Some kind of optional selector attribute inherent to any symbol, without affecting or misuing the other settings. This cuold also be used to hide/select symbols based on scale (which is currently kind-of-supported by using the symbol size - which I cannot use beause I need that for actual sizing of stuff).
A quick Idea could be: 1. untagged elements are always printed
2. tagged elements only if they are selected in the thconfig
3. actual systematic is user-defined, so we have maximum flexibility. For example, I could imagine mixing several systematics, one for desired output scale and another for special purposes:
--------- thconfig -------- select tag scale:250 select tag scale:500 select tag remarks select tag crossSections:abc export map .... --------------------------- In the th2's I just tag the items with "-tag scale:500" or "-tag crossSections:abc" (or both). This would completely (and optionally) decouple the show/hide from internal magic and support various usecases out of the box. One just needs to think of a good tagging systematic for his usecases/dataset.
Am 2025-02-19 17:29, schrieb Andrew Atkinson:
On 19/02/2025 15:58, Bill Gee wrote:
I would also like a way to produce a map which has SOME (not all) cross- sections. Right now it is all or nothing. You either get every cross- section or you get no cross-sections. This might be done by using PDF layers and letting the cross-section scrap specify the layer it goes on.
You can sort of do this with -attr <name> <value>. <name> Then use this in metapost
p36 thbook You can test presence of such a variable using if known ATTR_<name>: ... fi.
However, my metapost was not good enough and I kept getting bugs. So I used python to pull them out, then removed the ones I wanted. I thought I had put the code online, but cannot find it!
However, the use of attr would work better if symbol-hide worked for it. Unfortunately I do not think that it does.
You could abuse the system by abusing the -context option and setting it to a symbol you do not use then turn that off with symbol-hide.
Andrew _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Kia ora!
You mentioned constant fiddling with the {x}{y}{anchor} parameters as the map changes. That is the reason I save photos and profiles for the very end of a cartography project.
You have projects that have an end?
A thconfig file can have exactly ONE "select" directive.
Um, I think there is plenty of flexibility with select and thconfig usage. For almost all of my projects I manage one thconfig and multiple select statements within that (perhaps you are counting these select collections as 'one'). Admittedly I usually amalgamate map definitions to reduce these to a single select requirement per projection per run just for convenience. But multiple selects per projection work just fine, at least they did a few versions ago. And selects for each projection in a single thconfig per run are my norm. ie select mapPlan select mapExtended select mapProjection256 (I don't tend to use projected elevations these days - none of my caves are straight) select mapProjection135 etc There is also the possibility to use indexes to manage multiple variants of a single projection in a single thconfig*. select mapPlan select mapPlan:Enlargement * It might be possible to change the projection of plan maps to plan:enlargement on the fly with revise, but I haven't actually pulled this off. Were I try to this, I would currently draw the enlarged passage a second time (tracing over the original drawing, possibly in the same th2, but with an index added to the projection), but that is a bit of a hack. But as Tarquin mentioned, it is not possible to export based on one projection's set of selects and then choose another set of selects for that projection in the same thconfig run (The existence of unselect suggests this might be possible, but I have not had any luck with it and while some have talked of it, I don't recall an example where unselect has been used successfully for any purpose). This is a case where multiple thconfigs can be used with a script to wrap them all together as Tarquin describes. I have chosen a simpler, limited approach without automation and manage a single thconfig, manually commenting and uncommenting lines to get bespoke outputs on a run by run basis. Either approach seems to be fine, and what works best likely depends on preference and objectives. Bruce
LOL! Yes, that is a good point about map projects that end. You never know when someone will turn over a rock and find 20km of cave. I tried using a sequence of select and unselect directives, but it appeared as if the unselects were ignored and only the last select was actually used. I asked a question a few weeks ago about the scope of select, but never got an answer. As near as I can figure, the scope of select is the entire thconfig file regardless of where select appears. Some years ago I created a shell script to string together calls to therion with different thconfig files. It worked and was a bit of a bother to maintain. With my current project I use a system call in thconfig. I agree about projected elevations not being all that useful. It turns out I had confused "elevation" and "extended". What I really want is "extended". It was an easy change to redefine the scraps and the export command. =============== Bill Gee On 2/13/25 13:39, Bruce Mutton wrote:
Kia ora!
You mentioned constant fiddling with the {x}{y}{anchor} parameters as the map changes. That is the reason I save photos and profiles for the very end of a cartography project.
You have projects that have an end?
A thconfig file can have exactly ONE "select" directive.
Um, I think there is plenty of flexibility with select and thconfig usage. For almost all of my projects I manage one thconfig and multiple select statements within that (perhaps you are counting these select collections as 'one'). Admittedly I usually amalgamate map definitions to reduce these to a single select requirement per projection per run just for convenience. But multiple selects per projection work just fine, at least they did a few versions ago.
And selects for each projection in a single thconfig per run are my norm. ie select mapPlan select mapExtended select mapProjection256 (I don't tend to use projected elevations these days - none of my caves are straight) select mapProjection135 etc
There is also the possibility to use indexes to manage multiple variants of a single projection in a single thconfig*. select mapPlan select mapPlan:Enlargement
* It might be possible to change the projection of plan maps to plan:enlargement on the fly with revise, but I haven't actually pulled this off. Were I try to this, I would currently draw the enlarged passage a second time (tracing over the original drawing, possibly in the same th2, but with an index added to the projection), but that is a bit of a hack.
But as Tarquin mentioned, it is not possible to export based on one projection's set of selects and then choose another set of selects for that projection in the same thconfig run (The existence of unselect suggests this might be possible, but I have not had any luck with it and while some have talked of it, I don't recall an example where unselect has been used successfully for any purpose). This is a case where multiple thconfigs can be used with a script to wrap them all together as Tarquin describes. I have chosen a simpler, limited approach without automation and manage a single thconfig, manually commenting and uncommenting lines to get bespoke outputs on a run by run basis. Either approach seems to be fine, and what works best likely depends on preference and objectives.
Bruce
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
participants (5)
-
Andrew Atkinson -
Benedikt Hallinger -
Bill Gee -
Bruce Mutton -
Tarquin Wilton-Jones