Hi folks, With either extended or projected elevations, we end up with a few passages overlapping each other. This is intentional (so displacing some of them is not a desired solution). However, it would be nice to be able to colour them differently, to make it easier to see which parts belong to which passage. Colouring by altitude doesn't help in elevations, because they are all at the same altitude when they are overlapping. "Colour by distance from the viewer" is better. This could be coloured by colouring the individual scraps, but that is messy, and hard to maintain. The desired output would be "colour by break". Meaning; each time there is a "break" in the map, change the fg colour. Does anyone have any tips on how best to colour extended/projected elevations? Is "colour by break" possible in some way? Or do you prefer a different approach? Cheers, Tarquin
Hi Tarquin There is no difference between colouring of plan or elevation projections. If I am being pedantic, I make sure that scrap joins in plan and elevation are all made in the same passage location, and then colour both plan and elevation by altitude, unless I don't colour them at all. If I am colouring for presentation I usually colour by altitude, but I also make use of all of the other automated colouring options, and white is a good choice too. Automated colouring options are listed here, along with user definable overrides. https://therion.speleo.sk/wiki/examples?s[]=lookup#colour_scales_-_lookups Usually I am not so pedantic, and my scrap joins in elevation do not match those in the plan. To compensate I just make sure scraps are short, and joins are placed near a change in gradient or altitude. In the situation you describe I would probably define a new elevation map between each of your 'breaks'. Then in your layout include... colour map-fg map Then if you also wish to manually specify the actual colours or labels, in your th-config include... lookup map -title "Map colour legend" map1@some_survey [colour] "passage in front" map2 [colour] "passage in between" map3 [colour] "passage behind" endlookup The colours are optional I think, you should be able to replace them with empty square brackets if you also want labels in the legend. You can omit specifying the colours and the labels. When this feature was first introduced I played with it quite a bit, but I may not have used the exact variant shown above. I did have some trouble with colouring maps directly using select statements, as hinted at in the web page above, so it may not work perfectly. Strategic use of transparency and opacity in your layout can also minimise the need to apply fancy colouring to your outputs, and in any case will enhance them. Here are the statements and comments I put in my 'standard' layout to remind me of what might be good settings. The opacity setting that works best for white passage fill is different to that which works best with colour fills. It also differs for on-screen or printed output viewing. transparency on # see thru passages opacity 50 # degree of transparency: transparent = 0 <= opacity <= 100 = opaque #00 = transparent #40 = subtle, 60 - 70 = apparent: overwritten text still visible #80 = good passage definition but overwritten text barely visible #100 = block out passage underneath Bruce -----Original Message----- From: Therion <therion-bounces@speleo.sk> On Behalf Of Tarquin Wilton-Jones via Therion Sent: Tuesday, 30 April 2019 03:03 To: therion@speleo.sk Cc: Tarquin Wilton-Jones <tarquin.wilton-jones@ntlworld.com> Subject: [Therion] Best approach for colouring elevations Hi folks, With either extended or projected elevations, we end up with a few passages overlapping each other. This is intentional (so displacing some of them is not a desired solution). However, it would be nice to be able to colour them differently, to make it easier to see which parts belong to which passage. Colouring by altitude doesn't help in elevations, because they are all at the same altitude when they are overlapping. "Colour by distance from the viewer" is better. This could be coloured by colouring the individual scraps, but that is messy, and hard to maintain. The desired output would be "colour by break". Meaning; each time there is a "break" in the map, change the fg colour. Does anyone have any tips on how best to colour extended/projected elevations? Is "colour by break" possible in some way? Or do you prefer a different approach? Cheers, Tarquin _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
In the situation you describe I would probably define a new elevation map between each of your 'breaks'. Then in your layout include... colour map-fg map
Oh ... How obvious. Yes, I can just put them in separately coloured maps, and break between maps. I had tried "colour map-fg map" before, but it seems to treat my entire system as the same map, instead of colouring per sub-map. Presumably because I have: select overallElevationMap@caveArea If I wanted to automatically colour per sub map, would I have to instead switch to selecting each submap separately like this? select sectionMap1@cave1.caveArea select sectionMap2@cave1.caveArea select sectionMap1@cave2.caveArea ... Or am I just missing something obvious? Cheers, Tarquin
I had tried "colour map-fg map" before, but it seems to treat my entire system as the same map, instead of colouring per sub-map. Presumably because I have:
select overallElevationMap@caveArea
If I wanted to automatically colour per sub map, would I have to instead switch to selecting each submap separately like this? select sectionMap1@cave1.caveArea select sectionMap2@cave1.caveArea select sectionMap1@cave2.caveArea ...
Or am I just missing something obvious?
Never mind, I will answer myself. select overallElevationMap@caveArea -map-level 3 Thanks again folks.
Or you could avoid selecting any maps or surveys. That way every map will be exported. But I think your two solutions are better. Bruce -----Original Message----- From: Therion <therion-bounces@speleo.sk> On Behalf Of Tarquin Wilton-Jones via Therion Sent: Tuesday, 30 April 2019 20:41 To: therion@speleo.sk Cc: Tarquin Wilton-Jones <tarquin.wilton-jones@ntlworld.com> Subject: Re: [Therion] Best approach for colouring elevations
I had tried "colour map-fg map" before, but it seems to treat my entire system as the same map, instead of colouring per sub-map. Presumably because I have:
select overallElevationMap@caveArea
If I wanted to automatically colour per sub map, would I have to instead switch to selecting each submap separately like this? select sectionMap1@cave1.caveArea select sectionMap2@cave1.caveArea select sectionMap1@cave2.caveArea ...
Or am I just missing something obvious?
Never mind, I will answer myself. select overallElevationMap@caveArea -map-level 3 Thanks again folks. _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Or you could avoid selecting any maps or surveys.
Take care, than it that case Therion will export EVERYTHING it is able to find to export. What is probably not what you want.
Indeed. I have a couple of different versions of each master map at each orientation. Such as a simple plan view, and a plan view with levels displaced so that you can see what is underneath them. If I let Therion select everything, it will try to layer them all on the same PDF, which wouldn't work. So I only select the master map I am interested in.
lookup map -title "Map colour legend" map1@some_survey [colour] "passage in front" map2 [colour] "passage in between" map3 [colour] "passage behind" endlookup
This is pretty much exactly what I had in mind, and it works great :) Sadly it is not documented anywhere (except the mail and wiki page you already pointed to), so I can't see if it has any other useful features. Just wondering; is there is any way to group them together, when you have multiple maps sharing a value? Eg. lookup map:mainset segment1@cave1 [100 40 40] segmenta@cave2 [100 40 40] segmenti@cave3 [100 40 40] segment2@cave1 [100 70 0] segment4@cave1 [100 70 0] segmentii@cave3 [100 70 0] segment3@cave1 [100 100 0] segmentb@cave2 [100 100 0] segmentiii@cave3 [100 100 0] endlookup it would be nicer if these could be grouped so that you only need to specify the colour just once per group (makes it easier to change them if you reorder things, or a new segment gets added). I can see ways to group dates or altitudes, but not scraps or maps. Hoping I missed something.
30. 4. 2019 v 19:00, Tarquin Wilton-Jones via Therion <therion@speleo.sk>:
segment1@cave1 [100 40 40] segmenta@cave2 [100 40 40] segmenti@cave3 [100 40 40]
segment2@cave1 [100 70 0] segment4@cave1 [100 70 0] segmentii@cave3 [100 70 0]
segment3@cave1 [100 100 0] segmentb@cave2 [100 100 0] segmentiii@cave3
And what is the problem define another maps from segments and colour them? map 100_40_40 segment1@cave1 segmenta@cave2 segmenti@cave3 endmap etc lookup map:mainset 100_40_40 [100 40 40] … endlookup Martin
segment1@cave1 [100 40 40] segmenta@cave2 [100 40 40] segmenti@cave3 [100 40 40]
segment2@cave1 [100 70 0] segment4@cave1 [100 70 0] segmentii@cave3 [100 70 0]
segment3@cave1 [100 100 0] segmentb@cave2 [100 100 0] segmentiii@cave3
And what is the problem define another maps from segments and colour them?
In the simple case I showed above, there would be no problem. But in my actual case, I am doing this: select profilemap1@area ... lookup map:xyz #map within survey, grouping scraps that are in the same plane: scrapGroupingMap1@survey.cave.area #whole survey, since the whole cave is in the same plane: wholecave@cave.area endlookup I have already split the surveys up into separate maps to show each aligned group. Having to split my overall map up into yet another series of submaps, each of which covers an arbitrary group of maps from several unrelated subsections, is getting really close to spaghetti code. Meanwhile grouping within the lookup would be comparatively clean and easier to understand.
And what is the problem define another maps from segments and colour them?
Having to split my overall map up into yet another series of submaps, each of which covers an arbitrary group of maps from several unrelated subsections, is getting really close to spaghetti code.
I withdraw my request. You were right, using maps I can make this very logical and "clean" (for some value of "clean"). Each survey exports one map for each "plane" of the elevation view. (Optionally, it can also export a combined map, in case I want to render it separately from the other caves/surveys, such as in an atlas.) Each parent survey exports a map for each plane used by any of its children, containing the relevant maps from the children. At the top level, I have the overall map which combines the plane maps. The lookup then only needs to match those. Or they can have the colours hardcoded. Thanks for the hints :) Tarquin
1. 5. 2019 v 1:14, Tarquin Wilton-Jones via Therion <therion@speleo.sk>:
is getting really close to spaghetti code.
Tarquin, you may use input index file with map or maps definition to survey in th file, something as this input map_plan_lookup.thc input map_plan_default.thc The same with all joins and all equates, … So the code in one file could be quite simple at the end. Just another hint Martin
Fun fact; You don't even have to select the map for map lookups to find the scraps inside it. mycave.th: survey mycave map foo myscrap endmap map bar myscrap endmap ... endsurvey thconfig: source "mycave.th" select bar@mycave lookup map foo@mycave [100 0 0] endlookup layout elevation265 color map-fg map endlayout export map -proj plan -layout local -o "mycave.pdf" myscrap will be red, because it is in foo, even though bar is selected. Needless to say, this is a little unpredictable (is it a feature or a bug?), and means things get coloured even when you didn't expect them to be.
Tarquin Chances are you are forging new ground here. It is a new feature, so bugs might be expected. I have not really used 'lookup map', I just played a little so that I could write the wiki page :) Of the variants, I probably used 'lookup altitude' the most. It could be that red is the first colour in the default map colour list, so it may be coincidental that it matches the colour you chose, and not at all responding to your foo colour definition. It could be that if the map exported does not have an explicitly defined colour when others do, Therion gets buggy (or helpful) as you suggest. What if you add to the below sequence a lookup colour specification for bar@mycave that differs from foo's colour? Bruce -----Original Message----- From: Therion <therion-bounces@speleo.sk> On Behalf Of Tarquin Wilton-Jones via Therion Sent: Wednesday, 1 May 2019 20:47 To: therion@speleo.sk Cc: Tarquin Wilton-Jones <tarquin.wilton-jones@ntlworld.com> Subject: Re: [Therion] Best approach for colouring elevations Fun fact; You don't even have to select the map for map lookups to find the scraps inside it. mycave.th: survey mycave map foo myscrap endmap map bar myscrap endmap ... endsurvey thconfig: source "mycave.th" select bar@mycave lookup map foo@mycave [100 0 0] endlookup layout elevation265 color map-fg map endlayout export map -proj plan -layout local -o "mycave.pdf" myscrap will be red, because it is in foo, even though bar is selected. Needless to say, this is a little unpredictable (is it a feature or a bug?), and means things get coloured even when you didn't expect them to be. _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
It could be that red is the first colour in the default map colour list
Nope, tested that. Software tester (and pseudo-developer) by trade ;) It did a full paint of the entire cave using a map that I had not selected. Made me think I had got my map structures wrong or selected the wrong map.
What if you add to the below sequence a lookup colour specification for bar@mycave that differs from foo's colour?
It takes the last one - whichever is specified last - that contains the scrap. It does not take the one you select, unless that one happens to be specified last. Definitely feels like I have stepped off the edge of stable features here. I will file a bug report.
Definitely feels like I have stepped off the edge of stable features here. I will file a bug report.
Looking at the example in your bug report... https://github.com/therion/therion/issues/133 You have created two lookups for the same parameter (map), but no index has been specified. i would guess that is why the last lookup overwrites. Try using an index as described in https://therion.speleo.sk/wiki/examples#colour_scales_-_lookups ie, similar to... You may specify multiple lookup tables for same criterion using an index, ie “:” separator in label lookup altitude:scale1 600 800 endlookup and lookup altitude:scale2 800 750 700 endlookup and use then color map-fg altitude:scale1 or color map-fg altitude:scale2 Bruce
You have created two lookups for the same parameter (map), but no index has been specified. i would guess that is why the last lookup overwrites.
Agreed. Ideally, it should warn me that I have overridden my lookup, and that it is only using the last one. Right now, it silently tramples over it, which is not a desirable response.
:) A software tester is a valuable addition to the team. -----Original Message----- From: Therion <therion-bounces@speleo.sk> On Behalf Of Tarquin Wilton-Jones via Therion Sent: Thursday, 2 May 2019 07:33 To: therion@speleo.sk Cc: Tarquin Wilton-Jones <tarquin.wilton-jones@ntlworld.com> Subject: Re: [Therion] Best approach for colouring elevations
You have created two lookups for the same parameter (map), but no index has been specified. i would guess that is why the last lookup overwrites.
Agreed. Ideally, it should warn me that I have overridden my lookup, and that it is only using the last one. Right now, it silently tramples over it, which is not a desirable response. _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
participants (3)
-
Bruce Mutton -
Martin Sluka -
Tarquin Wilton-Jones