[Therion] Lookup explo-date - avoiding overlying scraps
Pavel I was just experimenting. Yes, my advice was bad. I also have a project of many kilometres and 50 years, and was for a while creating special submaps for the purposes of exporting maps by chronological periods. As exploration and mapping progressed, it became too labour intensive to maintain separate series of maps for both chronology and spatial representations. Maps allow complete renderings of all drawn symbols, but are labour intensive. If lookups could be used it should be trivial to achieve the simple mp-fg blocked out type exports regardless of map structures. Your examples achieved this, just with the shadow of any overlying passages. If Therion could have a special colour definition 'transparent' for map-fg, then the lookup band for dates you don't want to render could be set to transparent. This way they would not leave a shadow on passages that are rendered. There is a hint that this may be conceptually possible in the Therion Book, page 58. • colo[u]r . customize colour for special map items (map-fg, map bg, ... For map-bg, you can use transparent to omit page background completely. So a feature request: Is it possible to add a special colour for use with map-fg along the lines of that for map-bg ie transparent? This would allow flexibility beyond what the current transparency on/off and opacity statements are capable of. ie completely opaque map-fg rendering at the same time as some scrap foregrounds beng completely transparent (invisible). (There may be some oddities of rendering wrt the differences between pdf viewers) Bruce -Original Message- From: Therion On Behalf Of Pavel Herich Sent: Wednesday, 7 August 2024 19:59 To: List for Therion users Subject: Re: [Therion] Lookup explo-date - avoiding overlying scraps Thank You all, I did try this Bruce, with opacity 0 there is just blank page left. I agree, this could be done by customising map structure, but there is need for this for 88 km long cave system gradually discovered during 120 years. I´d like to make a video of discovery progress by each year in Demänovské Caves, so it should contain ~100 variations of the overall map... Pavel Dňa 2024-08-06 21:44 Bruce Mutton napísal(a): > Just a guess. Try... > transparency on > opacity 0 > > This may make the white passage invisible, but may also make > underlying passages appear to be on top. > I used to emulate what Pavel is trying to do using purpose-built map > definitions, but that is labour intensive. > Interested to see if lookups can be made to do this. > Bruce > ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Lookup explo-date - avoiding overlying scraps
Just a guess. Try... transparency on opacity 0 This may make the white passage invisible, but may also make underlying passages appear to be on top. I used to emulate what Pavel is trying to do using purpose-built map definitions, but that is labour intensive. Interested to see if lookups can be made to do this. Bruce -Original Message- From: Therion On Behalf Of Pavel Herich Sent: Tuesday, 6 August 2024 23:59 To: List for Therion users Subject: [Therion] Lookup explo-date - avoiding overlying scraps Hi, do you see a way how to avoid certain scrap representation (by transparent imprint) in pdf as overlaying part of cave while using lookup (explo-date), as can be seen in the middle of map explo-date_1978.pdf? explo-date_2024.pdf represents the whole cave, in blue is a cave passage discovered in 2024, which is overlaying discovery from 1978. My point is to be able to show the cave as it was known before newest discovery, without signs of newer parts... Lookup is following: lookup explo-date -title "Postup objavných prác" [0.1.1 1977.12.31] [0 0 0 100] "známe oddávna" [1978.1.1 1978.12.31] [0 100 100 0] "" [1979.1.1 2024.12.31] [0 0 0 0] "" endlookup Many thanks Pavel ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] group endgroup pairs do not constrain metadata to just the grouped shots
The Therion Book says that group/endgroup pairs enable the user to make temporary changes in almost any setting (calibrate, units, sd, data, flags...) This is not in practice the case for date, team, explo-date, explo-team, and is described in https://github.com/therion/therion/issues/131 What actually happens is that these entries are applied to ALL of the shots within the centreline (as far as any outputs report), so they are not 'temporary changes'. In other words, the effect is the same if the group/endgroup statements are omitted. At least as far as I can tell with limited testing. If the presence of the group/endgroup has no effect for the above, what about calibrate, units, sd, etc? I suggest Therion should throw a warning or error if settings or metadata applied in a group block will effectively apply to all shots in that centreline. Thoughts? Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Looking for TopParser sources
Kia ora I'm just putting together a list of links to suggested Therion ecosystem software. Notice that the link to a TopParser zip file in the Therion wiki seems to have broken https://therion.speleo.sk/wiki/contrib:complimentarycaveapps#topparser I can zip up the files I have, but probably better to link to Andrew's source. Bruce Mutton ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] A wtherion update
> I have an update to share regarding wtherion, which you hopefully remember is my project for a web-based Therion map editor to replace XTherion's map editing capabilities: > https://github.com/daem-on/wtherion > The scope of the project hasn't really changed, but I'd be interested to work on other projects that plan to replace the whole of XTherion, or even replace text based editing. Good to see that this project is continuing. It would be nice to have a more capable editor for Therion drawings. Unfortunately I have not had time to look at this update, but hope to do so at some stage. Just a comment regarding the value or otherwise of text-based data files in relation to Therion. For me a super-power of Therion/XTherion is the ability to support multiple simultaneous people editing a dataset at one time, and the ability to interrogate every saved snapshot for the entire history of a project (for error tracking and recovery, finding bugs). Of course these capabilities are not built into Therion/XTherion, but my understanding is that they are, by way of version control (Git, bzr, Hg) only possible because: * of the text (ascii) based data (.th, .th2) files and * a single edit in the drawing editor results in ONLY a single line changed in the data (.th2) file. The earlier implementation of WTherion had two characteristics that made it unsuitable for the ecosystem that I have built up around my Therion usage: * a .th2 file loaded into WTherion, saved without making any changes and exported back to .th2 resulted in a file that had edits on every line. ie it violated the above requirement that a single entity edit results in a single line change in the data file, making it 'unhelpful' for version control (particularly if some are using XTherion and some are using WTherion), and * the WTherion data files 'live' in a browser cache (I think something like that) so that a project's data is no longer stored as a package in a single location version control. Therefore other users and version control cannot identify when changes have been made to a project, unless all users are always rigorous about carrying out the extra steps required to export WTherion data back to the project folder. I think line point characteristics such as 'altitude .' and possibly others that I have grwn fond of were not possible in WTherion. I appreciate WTherion is just starting out, and am hoping that if multi-user editing and version control compatibility are front of mind during development they can be accommodated. I think that retaining the paradigm where drawing is interactive and compilation of outputs is a batch operation is optimal, so don't see a particular need to move to more efficient non-text data formats. This is right outside of my expertise, and I'm an old dinosaur, so will no doubt stand corrected. An editor where I could cut, paste, rotate and scale drawing entities would be a nice addition to the Therion ecosystem, so keep working on it! Thanks Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Geographical Coordinates on grid
Kia ora Alastair I have not looked at the specifics that you provided, but off the top of my head… When I was new to Therion, over a decade ago, I expected ‘grid-coords border’ to put coordinates on the outermost visible grid intersections around the perimeter of an exported pdf. After some inquiry and experimentation I came up with this understanding – it is not typically practicable to achieve this, but with some compromise it is sometimes possible. Therion generates a grid around the cave passage exported, in your example below, at 250 m intervals in each cardinal direction. Since the ‘bordering’ grid line will be 250 m (at scale) outside of any cave passage it is unlikely it will make it onto the exported pdf, since the displayed map extent around the outside of the cave is only a few tens of millimetres. I have only ever achieved it by having a small grid spacing, and a suitably large ‘overlap’ (assuming you are exporting maps rather than atlas’) specified. Try specifying grid at 10 m and overlap at say 30 cm to verify this concept. It gets even more frustrating if the output is rotated (say using ‘rotate 70’), since your exported pdf will have bordering coordinates only where the edge of the grid is visible. If someone has a solution or can come up with a means of labelling specific grid intersections, I would be appreciative! Ngā mihi nui Bruce From: Therion On Behalf Of A Gott Sent: Saturday, 13 April 2024 22:40 To: List for Therion users Subject: [Therion] Geographical Coordinates on grid HI Therion users, I am really struggling to get coordinates to show on the edges of the Plan pdf when generated. There has to be something I'm missing! Does anyone have any examples where they have implemented coordinates on the border of the PDF so I can take a look? The two models I have tried this on are the Peak speedwell model in Castleton, Derbyshire, UK and also the Agua/Naciemiento Model in Tresviso, Cantabria/Asturias, Spain I really would like to see it on the Peak speedwell model and now realise we tried it on the Agua model but decided against it due to deadlines. We set a deadline for this one, but including the coordinates are a must! Peak speedwell - cave-registry.org.uk/svn/PeakDistrict/Castleton/castleton_model_thconfig <https://www.cave-registry.org.uk/svn/PeakDistrict/Castleton/castleton_model_thconfig> The things I've tried to include in the above which I hoped would help the coordinates to generate, at one point I did get the coordinates to generate only on the west side of the pdf, but now it's failing to show anywhere: page-setup 118.9 84.1 114.9 80.1 1.5 1.5 cm overlap 3 cm #size 110 75 cm size 105 75 cm grid bottom grid-coords border grid-size 250 250 250 m cs OSGB:SK grid-origin 14865.01 82575.16 193.75 m I also tried implementing the full grid, in the hope that this would help, but also didn't. layout custom_grid ##change default cross hair grid to grid code metapost def s_hgrid (expr xpos, ypos, xsize, ysize) = pickup PenD; if ( xpos >= -xsize ) and ( ypos >= -ysize ): draw ( -xsize/2, 0) -- ( xsize/2, 0); draw ( 0, -ysize/2) -- ( 0, ysize/2); fi enddef; endcode endlayout For Ref, the Tresviso model, but we wiped any reference to including a grid on this one. cave-registry.org.uk/svn/Andara/Tresviso/Nacimiento/therion/Nacimiento2020/Nacimiento2020_master.thconfig <https://cave-registry.org.uk/svn/Andara/Tresviso/Nacimiento/therion/Nacimiento2020/Nacimiento2020_master.thconfig> Regards, Alastair Gott. ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Metapost for sump/syphon hazard symbol
Hello I'm looking for a Therion map symbol to emphasize the hazard posed by a localised low roof in passages (typically 2m to 5m in diameter) that are usually inaccessible due to water, but in dry conditions appear innocuous to the unwary. Currently I'm using an empty placeholder symbol, point u:sumphazard, but want to upgrade! I've been using the SBE point danger symbol to identify hazards such as zones of active passage collapse. One approach for sumping hazard would be to use the same symbol, and change the colour to blue, but I would like the distinction to be available for black and white outputs as well as colour outputs. Since I'm not very good at metapost, I'm looking to see if anyone has anything they'd be willing to share, or perhaps write! What I have in mind is something like an exclamation mark over top of some water squiggles. Maybe like one of these? The links behind the images below might have some useful elements. <https://i.pinimg.com/originals/02/4a/bc/024abcc38e0f1601c40650f0795948c7.jp g> <https://static.vecteezy.com/system/resources/previews/000/112/522/original/ flat-water-icon-vector-set.jpg> Thanks in advance. Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Placing labels or symbols over top of labels
Hello everyone Is it possible to draw line arrow (or other symbols) over top of areas clipped by the 'shadow' of labels? Or if not, would it be desirable to be able to draw some symbols over top of labels? One use case would be as below, ensuring the line arrow shown in red below could extend over the area clipped by the label 'shadow' (which I have sketched in green). I could have drawn this example as two labels, thus making the shadow smaller, but then it is more complicated getting appropriate line spacing if the map is exported at a variety of scales. I tried -place top and -place bottom without any luck, then studied how maps are put together (Therion Book pages 45-47) and realised that only grids, surface bitmaps and previews are likely to overwrite labels. Any suggestions? Regards Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Compilation outcome depends on order of source statements
Here is an issue that took me too many days to unravel. The order of source statements in a thconfig affects the outcome of the compilation. I think the problem, or constraint, can be described as: * Multi-line source statements must follow all single line source statements, else not all surveys will not be read correctly, or * Single-line source statements that follow a multi-line source statement will not be read. For example, a thconfig contains: source ./Greenlinkcave/INDEXGreenlink.th source ./swissmaidcave/INDEXSwissMaid.th source #join the two cave surveys without an index file equate 133@jp.SwissM I68@s.Greenlink equate 156@second.SwissM S45@ss.Greenlink equate 144@jp.SwissM H32@h.Greenlink endsource source ./middleearthcave/INDEXMiddleEarth.th source #join the two cave surveys without an index file equate F76@f.MiddleEarth F102@f2.Greenlink endsource This results in a fatal error: reading source files ... done preprocessing database ... done C:\Program Files\Therion\therion.exe: error -- ./middleearthcave/INDEXMiddleEarth.th [24] -- survey does not exist -- 74 Which confused me because each of these would compile alone an in combination via other thconfig files. If I changed the order of the source statements, the 'non-existent' survey would change. I tried 6.2.0 + fd5c1b6 and 6.17 and 6.13 all with similar effect (although I'm not that confident because the latter two being 32-bit and toggling between the 64-bit 6.2.0 variants results in duplicate therion programs on my Windows machine, thus I'm not sure I have 'clean' installs). Too late, I tried putting all the single line sources first, followed by the multi-line sources, and viola, success. So this seems like a bug, in that I understand Therion should read all sources before processing the survey and map input. With sources, this seems not to be happening, and Therion is crashing inappropriately if the sources are not listed in the 'correct' order. Bruce PS: Yes, I know the example above is a rather messy way of treating sources. I would not usually do this - it is a hack to work around an unfortunate decision made early in the project history. ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Flush logfile output (PR #541) - Therion log file truncated prematurely
Thanks Matěj Limited checking suggests therion.log files created with this commit are complete up to the ### end of loop errors ###, although I am expecting scrap distortions and CRS transformations, and there are none. Not sure if this is my oversight or something that should be written and is genuinely missing. Regards Bruce From: Matěj Plch Sent: Wednesday, 10 January 2024 09:10 To: therion/therion Cc: Subscribed Subject: [therion/therion] Flush logfile output (PR #541) Flush logfile output after every write to prevent its truncation. _ You can view, comment on, or merge this pull request online at: https://github.com/therion/therion/pull/541 Commit Summary * 1fe1274 <https://github.com/therion/therion/pull/541/commits/1fe1274586119e104e855523ea00a20b07dbdba9> flush logfile output File Changes (1 <https://github.com/therion/therion/pull/541/files> file) * M thlogfile.h <https://github.com/therion/therion/pull/541/files#diff-e6f85872781d0868ff3e5fe21b73e3a797e3f54f372c11eecf4775433586bd14> (3) Patch Links: * https://github.com/therion/therion/pull/541.patch * https://github.com/therion/therion/pull/541.diff — Reply to this email directly, view it on GitHub <https://github.com/therion/therion/pull/541> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEXIJTGNZVSX5ORRUK5YRI3YNWP2FAVCNFSM6ABBTVPEWOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA3TGMBYGI2TINA> . You are receiving this because you are subscribed to this thread. <https://github.com/notifications/beacon/AEXIJTCBCTBGB2HVSG5MXFTYNWP2FA5CNFSM6ABBTVPEWOWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHHXEF2WA.gif> Message ID: mailto:therion/therion/pull/5...@github.com> > ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Change altitude colours
Try also layout colour-legend #specifies whether the legend colours are presented as a smoothed vertical band or discrete boxes (smooth applies to altitudes and dates only I think) smooth-shading #specifies whether each scrap is rendered as a single colour or smoothed in accordance with the altitude/date value at each survey station) endlayout Bruce -Original Message- From: Therion On Behalf Of Tarquin Wilton-Jones via Therion Sent: Sunday, 31 December 2023 20:26 To: therion@speleo.sk Cc: Tarquin Wilton-Jones Subject: Re: [Therion] Change altitude colours Hi Paul, > /colour map-fg altitude/ Yes indeed, you can use a lookup table. <https://therion.speleo.sk/wiki/examples#colour_palette_scales_-_lookups> https://therion.speleo.sk/wiki/examples#colour_palette_scales_-_lookups <https://www.mail-archive.com/therion@speleo.sk/msg06798.html> https://www.mail-archive.com/therion@speleo.sk/msg06798.html Lookup tables allow you to do specific colouring by maps, or altitude. I have never tried to use it with smooth colouring though, so have no idea how it interacts with that setting. I have only ever used it with: smooth-shading off Enjoy :) Tarquin ___ Therion mailing list <mailto:Therion@speleo.sk> Therion@speleo.sk <https://mailman.speleo.sk/listinfo/therion> https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] scale option for lines
> Does anybody know another situation where line scale option is relevant? My understandings and deductions are here https://therion.speleo.sk/wiki/drawingchecklist Probably you have all the line scale options now, but there maybe something more towards the bottom of the page. Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Setting map border framethickness to zero (off) -layout call order inconsistent
And just noticed this https://github.com/therion/therion/issues/425
Maybe related?
Sent: Sunday, 5 November 2023 18:52
To: 'List for Therion users'
Subject: Setting map border framethickness to zero (off) -layout call order
inconsistent
OK, there is some strange behaviour wrt the order of layout processing, or
at least which layout statement prevails in the case of a conflict.
I took the basic rabbit cave example, and modified the thconfig slightly to
give one of the exports conflicting layout calls:
#CODE TO PUT BORDER AROUND MAP
#-
layout LayoutMapBorder
code tex-map
\framethickness=0.5mm
endcode
endlayout LayoutMapBorder
#CODE TO REMOVE BORDER AROUND MAP
#-
layout LayoutRemoveMapBorder
code tex-map
\framethickness=0mm
endcode
endlayout LayoutRemoveMapBorder
export map -projection extended -output rabbit-xelev.pdf \
-layout water-blue -layout-map-header 0 0 s -layout-map-header 0 110 sw \
-layout LayoutRemoveMapBorder -layout LayoutMapBorder
The above export produces a map with header top-left and no border (green
arguments prevail). If I swap the grey and green layout calls, I get a
header bottom-left and a border (grey arguments prevail).
So why are these layouts treated differently?
Is it that layouts that contain tex are treated differently to layouts that
do not?
Bruce
Sent: Friday, 3 November 2023 08:17
To: 'List for Therion users' mailto:therion@speleo.sk> >
Subject: Setting map border framethickness to zero (off)
I have just now solved this problem. The error status must have been some
combination of setting \framethickness to 0mm and the order in which I was
calling layouts, although I cannot pin down why this would be the case.
Anyway, setting \framethickness to 0mm does now remove a frame that was
previously set in my project.
The key to solving the problem as to why \framethickness was not responsive
to a second call was that I was mistaken in my belief as to the order of
layout calls in export commands.
I always assumed the second layout called would be the second layout
processed. Alas it seems to be the other way around and layouts in export
commands are processed in reverse order.
eg like this:
export map -projection plan \
-layout LayoutProcessedLast \
-layout LayoutProcessedFirst \
-output ../Output/CavePlan.pdf
At least that is what I deduce from the behaviour where there are
conflicting \framethickness statements.
Except I think I have evidence that for some layout content it is the other
way around.
Anyone else have any insights as to the order of layout processing in export
commands?
Bruce
Sent: Monday, 30 October 2023 12:15
To: 'List for Therion users' mailto:therion@speleo.sk> >
Subject: Setting map border framethickness to zero (off)
Good morning
Probably a simple tex question.
I often use this code to create a border around an exported map:
code tex-map
\framethickness=0.5mm
>From time to time (in the same compilation run) I insert one exported map
into another using map-image and usually the inserted map should not have a
border.
To date I have always arranged my layouts so that \framethickness is
undefined while the initial map is exported, THEN set to 0.5 mm for the
second map export.
It occurred to me that with my project arrangment it would be more
convenient to set the border to 0.5 mm (in a global layout) and THEN reset
it to zero or undefined in a layout specific to only one of the exports.
I have tried these two options:
code tex-map
\framethickness={}
code tex-map
\framethickness=0mm
The first causes error (pdftex exit code 1) and the second draws a 0.5 mm
border around both maps.
How should I 'turn off' a map border if \framethickness has already been
set?
Regards
Bruce
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion
[Therion] Setting map border framethickness to zero (off) -layout call order inconsistent
OK, there is some strange behaviour wrt the order of layout processing, or
at least which layout statement prevails in the case of a conflict.
I took the basic rabbit cave example, and modified the thconfig slightly to
give one of the exports conflicting layout calls:
#CODE TO PUT BORDER AROUND MAP
#-
layout LayoutMapBorder
code tex-map
\framethickness=0.5mm
endcode
endlayout LayoutMapBorder
#CODE TO REMOVE BORDER AROUND MAP
#-
layout LayoutRemoveMapBorder
code tex-map
\framethickness=0mm
endcode
endlayout LayoutRemoveMapBorder
export map -projection extended -output rabbit-xelev.pdf \
-layout water-blue -layout-map-header 0 0 s -layout-map-header 0 110 sw \
-layout LayoutRemoveMapBorder -layout LayoutMapBorder
The above export produces a map with header top-left and no border (green
arguments prevail). If I swap the grey and green layout calls, I get a
header bottom-left and a border (grey arguments prevail).
So why are these layouts treated differently?
Is it that layouts that contain tex are treated differently to layouts that
do not?
Bruce
Sent: Friday, 3 November 2023 08:17
To: 'List for Therion users'
Subject: Setting map border framethickness to zero (off)
I have just now solved this problem. The error status must have been some
combination of setting \framethickness to 0mm and the order in which I was
calling layouts, although I cannot pin down why this would be the case.
Anyway, setting \framethickness to 0mm does now remove a frame that was
previously set in my project.
The key to solving the problem as to why \framethickness was not responsive
to a second call was that I was mistaken in my belief as to the order of
layout calls in export commands.
I always assumed the second layout called would be the second layout
processed. Alas it seems to be the other way around and layouts in export
commands are processed in reverse order.
eg like this:
export map -projection plan \
-layout LayoutProcessedLast \
-layout LayoutProcessedFirst \
-output ../Output/CavePlan.pdf
At least that is what I deduce from the behaviour where there are
conflicting \framethickness statements.
Except I think I have evidence that for some layout content it is the other
way around.
Anyone else have any insights as to the order of layout processing in export
commands?
Bruce
Sent: Monday, 30 October 2023 12:15
To: 'List for Therion users' mailto:therion@speleo.sk> >
Subject: Setting map border framethickness to zero (off)
Good morning
Probably a simple tex question.
I often use this code to create a border around an exported map:
code tex-map
\framethickness=0.5mm
>From time to time (in the same compilation run) I insert one exported map
into another using map-image and usually the inserted map should not have a
border.
To date I have always arranged my layouts so that \framethickness is
undefined while the initial map is exported, THEN set to 0.5 mm for the
second map export.
It occurred to me that with my project arrangment it would be more
convenient to set the border to 0.5 mm (in a global layout) and THEN reset
it to zero or undefined in a layout specific to only one of the exports.
I have tried these two options:
code tex-map
\framethickness={}
code tex-map
\framethickness=0mm
The first causes error (pdftex exit code 1) and the second draws a 0.5 mm
border around both maps.
How should I 'turn off' a map border if \framethickness has already been
set?
Regards
Bruce
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion
[Therion] Setting map border framethickness to zero (off)
I have just now solved this problem. The error status must have been some
combination of setting \framethickness to 0mm and the order in which I was
calling layouts, although I cannot pin down why this would be the case.
Anyway, setting \framethickness to 0mm does now remove a frame that was
previously set in my project.
The key to solving the problem as to why \framethickness was not responsive
to a second call was that I was mistaken in my belief as to the order of
layout calls in export commands.
I always assumed the second layout called would be the second layout
processed. Alas it seems to be the other way around and layouts in export
commands are processed in reverse order.
eg like this:
export map -projection plan \
-layout LayoutProcessedLast \
-layout LayoutProcessedFirst \
-output ../Output/CavePlan.pdf
At least that is what I deduce from the behaviour where there are
conflicting \framethickness statements.
Except I think I have evidence that for some layout content it is the other
way around.
Anyone else have any insights as to the order of layout processing in export
commands?
Bruce
From: Bruce Mutton
Sent: Monday, 30 October 2023 12:15
To: 'List for Therion users'
Subject: Setting map border framethickness to zero (off)
Good morning
Probably a simple tex question.
I often use this code to create a border around an exported map:
code tex-map
\framethickness=0.5mm
>From time to time (in the same compilation run) I insert one exported map
into another using map-image and usually the inserted map should not have a
border.
To date I have always arranged my layouts so that \framethickness is
undefined while the initial map is exported, THEN set to 0.5 mm for the
second map export.
It occurred to me that with my project arrangment it would be more
convenient to set the border to 0.5 mm (in a global layout) and THEN reset
it to zero or undefined in a layout specific to only one of the exports.
I have tried these two options:
code tex-map
\framethickness={}
code tex-map
\framethickness=0mm
The first causes error (pdftex exit code 1) and the second draws a 0.5 mm
border around both maps.
How should I 'turn off' a map border if \framethickness has already been
set?
Regards
Bruce
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion
[Therion] Setting map border framethickness to zero (off)
Good morning
Probably a simple tex question.
I often use this code to create a border around an exported map:
code tex-map
\framethickness=0.5mm
>From time to time (in the same compilation run) I insert one exported map
into another using map-image and usually the inserted map should not have a
border.
To date I have always arranged my layouts so that \framethickness is
undefined while the initial map is exported, THEN set to 0.5 mm for the
second map export.
It occurred to me that with my project arrangment it would be more
convenient to set the border to 0.5 mm (in a global layout) and THEN reset
it to zero or undefined in a layout specific to only one of the exports.
I have tried these two options:
code tex-map
\framethickness={}
code tex-map
\framethickness=0mm
The first causes error (pdftex exit code 1) and the second draws a 0.5 mm
border around both maps.
How should I 'turn off' a map border if \framethickness has already been
set?
Regards
Bruce
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion
Re: [Therion] -flip horizontal and line numbering
Not able to test just now, but think I noticed the same thing some time ago.I recall it took me a few attempts to understand what was happening. Would likely stall an inexperienced user. As with Martin, the durable solution I came up with was to name each station to be joined. Inconvenient when it is as plain as start and end. Long term I think changing the behaviour so that flipping does not renumber line points would be desirable. Might break some of my outputs, but then joining flipped and unflipped scraps is not that common. A possibly similar or related issue I assume was already resolved. Search on github for closed issues 'flip'.BruceSent from my Galaxy Original message From: alastair gott Date: 23/10/23 05:09 (GMT+12:00) To: Therion Mailing List Subject: [Therion] -flip horizontal and line numbering Hi Therion people, I've just noticed that flipping an extended elevation scrap using “-flip horizontal” it changes the numbering of the lines points on the th2 file when the file is processed by the config file. I was trying to line join the top line of one elevation survey with the top line of another survey using "join linetop@normal:end linetop@flipped:0" as the “normal:end” line was accidentally drawn clockwise and “flipped:0” was drawn anti-clockwise it makes sense that end and zero were the join points However when the file was run it was necessary to change it to be "join linetop@normal:end linetop@flipped:end" to get the two lines to join, it's not a problem, just something I wasn't aware of. Regards, Alastair. Sent from Outlook for iOS ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] 'Colour by error' is not displayed by Aven if 'flags duplicate' is applied to leg in Therion
Not sure if this is a Survex Aven issue or an issue with the way Therion parses data to a *.3d file, or indeed whether it is because Im using an old version of Aven. I was surveying fore-sight back-sight pairs, first time in a cave for ages... so initially made a naïve oversight: - forgot to make the backsight legs duplicate, thereby almost doubling the calculated cave length. In the entrance area of this (tourist) cave there is a big steel gate and overhead 240 v power wires some 15 20 m away. This led to 10-15 deg errors when outside the cave or some 4 m inside of the gate. We abandoned any hope of a compass survey outside the cave. Interestingly the powered-down cables in the cave seemed to have minimal if any effect on bearings. So I was using Aven to visually characterise the degree of misclosure on each fore-sight back-sight pair. ie Colour by error gave me nice dark blue 1x sd errors inside and lighter blue 3x sd errors near the entrance and outside. So far, so good. Then I realised that I needed to make the back-sight legs duplicate. But now Aven does not display the duplicate legs as being part of a loop, so I lose the very useful ability to quickly visualise all of the loops and their relative quality. In hindsight I have noticed that Aven misses plotting of loop closure sd of isolated legs for years, and I could not figure out why. I wonder if that is also related to a flags issue? And wondering if this is considered a bug? ie display of loop status by Aven should override Therion flags status (duplicate, approximate, surface etc) therion 6.1.8 (2023-06-14) Survex 1.4.1 > Im using this cos the next version broke display of colour by error for Therion exported 3d files (I forget the reason now maybe its been fixed since ) Regards Bruec ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Therion error - a software BUG is present
Oops I attempted to equate a pair of stations to close a large loop in an otherwise well behaved but complex model, and suddenly Therion reports a software BUG. About to post this message, and noticed that I had this same issue 11 years ago https://www.mail-archive.com/therion@speleo.sk/msg03641.html although that time the culprit was thdb1d.cxx:2290. I think it was associated with some 'no-survey' statements, but I am not sure. Any ideas? Bruce >From therion.log . 2024.1.1 22.6293 scanning centreline tree ... done searching for centerline loops ... done calculating station coordinates ... C:\Program Files (x86)\Therion\therion.exe: error -- a software BUG is present (D:/a/therion/therion/thdb1d.cxx:2418) writing xtherion file ... done ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] A puzzle in Loch
> One thing that strikes me is that the spike is not horizontal. It angles > upward by about 20 degrees. Hi Bill If it helps (unlikely), I have had a project where the Loch model has (had) just such a spike, one hundred or so metres long, angling about 20 deg upwards. For more than 10 years the model had this spike, and from time to time I tried to troubleshoot it without luck. I have had other similar cases as well. I looked up some outputs compiled January this year - it seems this spike is no longer present. So there must have been a change in the algorithm in recent years to resolve this. There has been no survey or drawing activity in that part of the cave or model since about 2008-2010, but I concede that edits more than 100 m away (from the spike) in the model could possibly have had some effect. I notice that other Loch rendering artifacts seem to have been resolved also. Are you using a recent version of Therion? I'm using 6.1.8, but unsure what it would have been in January. Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Invalid length reading error reported due to (valid) scrap definition
OK, found it. It was as I suspected a missing endcentreline in the file
called by an input statement immediately preceding the statement 'input
11-DeerPlan.th2'.
So my mistake, I did not check as well as I thought I had.
I wonder if Therion could check for endcentreline statements (where they
might normally be expected) and if not found by the end of a file, then
issue a warning "missing endcentreline in file xxx.th".
Thanks
Bruce
From: Therion On Behalf Of Bruce Mutton
Sent: Monday, 7 August 2023 15:36
To: 'List for Therion users'
Subject: [Therion] Invalid length reading error reported due to (valid)
scrap definition
Hello
I have a perplexing error, this time around after a complicated git merge,
and I have had similar on one occasion a while back.
I think I resolved by omitting the file, which is not really a resolution.
This time I need a better solution!
On compiling a thconfig I get an error:
C:\Program Files (x86)\Therion\therion.exe: error -- 11-DeerPlan.th2 [8] --
invalid length reading -- -projection
The start of file 11-DeerPlan.th2 is like this:
encoding utf-8
##XTHERION## xth_me_area_adjust -160.83 -127.28 965.01 763.65
##XTHERION## xth_me_area_zoom_to 200
##XTHERION## xth_me_image_insert {502.386220472 1 1.0} {626.342677165 11.8}
ptopoDeer/11-Deer_p.xvi 0 {}
scrap 11-DeerPlan-s1 -projection plan -station-names []@11 -author
2023.02.26 "B Mutton" -copyright 2023 NZSS -scale [0 0 787.4 787.4 0 0 10 10
m]
point 10.25 711.5 label -text "Deer Pot" -align l -scale xl
point 186.25 712.5 anchor -align r
This is a well established scrap in a well established file in a well
established project and both of the parent branches compiled without issue
through many editing and versioning iterations. Comparison with both of the
parent git branches do not suggest any changes that should trigger such an
error - at least I have not found it yet.
I have checked this file and all calling it for closed blocks (scrap
endscrap, map endmap, centreline endcentreline, survey end survey etc)
because long ago Therion used to complain in a similar manner if such blocks
were not closed (reporting survey data type error due to a drawing file
error - illogical).
Since this is the second time in a month I've experienced this type of
'illogical' error after nothing like it for years, I'm wondering if anyone
else has, or has a clue as to what might be happening?
Bruce
Using:
therion 6.1.8 (2023-06-14)
Windows 10 Home 22H2
GitHub desktop 3.2.7 (x64)
TortoiseGit 2.14.0
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion
[Therion] Invalid length reading error reported due to (valid) scrap definition
Hello
I have a perplexing error, this time around after a complicated git merge,
and I have had similar on one occasion a while back.
I think I resolved by omitting the file, which is not really a resolution.
This time I need a better solution!
On compiling a thconfig I get an error:
C:\Program Files (x86)\Therion\therion.exe: error -- 11-DeerPlan.th2 [8] --
invalid length reading -- -projection
The start of file 11-DeerPlan.th2 is like this:
encoding utf-8
##XTHERION## xth_me_area_adjust -160.83 -127.28 965.01 763.65
##XTHERION## xth_me_area_zoom_to 200
##XTHERION## xth_me_image_insert {502.386220472 1 1.0} {626.342677165 11.8}
ptopoDeer/11-Deer_p.xvi 0 {}
scrap 11-DeerPlan-s1 -projection plan -station-names []@11 -author
2023.02.26 "B Mutton" -copyright 2023 NZSS -scale [0 0 787.4 787.4 0 0 10 10
m]
point 10.25 711.5 label -text "Deer Pot" -align l -scale xl
point 186.25 712.5 anchor -align r
This is a well established scrap in a well established file in a well
established project and both of the parent branches compiled without issue
through many editing and versioning iterations. Comparison with both of the
parent git branches do not suggest any changes that should trigger such an
error - at least I have not found it yet.
I have checked this file and all calling it for closed blocks (scrap
endscrap, map endmap, centreline endcentreline, survey end survey etc)
because long ago Therion used to complain in a similar manner if such blocks
were not closed (reporting survey data type error due to a drawing file
error - illogical).
Since this is the second time in a month I've experienced this type of
'illogical' error after nothing like it for years, I'm wondering if anyone
else has, or has a clue as to what might be happening?
Bruce
Using:
therion 6.1.8 (2023-06-14)
Windows 10 Home 22H2
GitHub desktop 3.2.7 (x64)
TortoiseGit 2.14.0
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion
[Therion] Big room multiple scraps - How to join
Hi Bill That is generally what I do. Depending on the arrangement of the images you might be able to leave some or most of them visible if you change the stacking order. Experiment with the Top, Up, Down, Bottom buttons. You can also double-right-click an image to allow you to drag it to another location before you start drawing. This can avoid the 'problem' of images overlapping each other. However doing this is likely counter-productive for the work flow we are discussing in this thread. As another aside, if you insert .png format images with a transparent background, the problem of one image obscuring another is greatly reduced. I don't have any experience with how these survive export to .th2 or .xvi, so not sure how relevant this is here. Bruce -Original Message- From: Therion On Behalf Of Bill Gee Sent: Saturday, 5 August 2023 08:44 To: Therion Mail List Subject: Re: [Therion] Big room multiple scraps - How to join Hmmm I think I get it. The xvi file consists of three images. When I set it as the background for a drawing window, there are four entries in the background list. They are the file name and each of the images it contains. The file name holds the centerline and each image holds one drawing. To draw on top, uncheck visibility for all but one of the images. Draw on that, then make it invisible and turn on another image. Add to the drawing, then repeat for the third background. Is that the basic process? Screen shot attached. === Bill Gee On 8/4/23 14:53, Bruce Mutton wrote: > > The problem is the sketches are not transparent enough to use. The > only part of the sketch that has any visible drawing on it is for the > last scrap mentioned in the map statement of the .th file. The other > drawings are not visible. > > Bill > > Select the image, untick visibility > > > ___ > Therion mailing list > Therion@speleo.sk > https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Big room multiple scraps - How to join
> The problem is the sketches are not transparent enough to use. The only part > of the sketch that has any visible drawing on it is for the last scrap > mentioned in the map statement of the .th file. The other drawings are not > visible. Bill Select the image, untick visibility ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] How to add 1.5 x linefeed to a text string
Thanks Tarquin I am able in my bumbling way to work with metapost and tex, but my use case here does not warrant that and feels better suited to using standard features. I'll leave this one for now. Possibly there is a case for a <1.5br> control to compliment the existing etc in some future update. Bruce -Original Message- From: Therion On Behalf Of Tarquin Wilton-Jones via Therion Sent: Friday, 4 August 2023 09:21 To: therion@speleo.sk Cc: Tarquin Wilton-Jones Subject: Re: [Therion] How to add 1.5 x linefeed to a text string > Could not make that work. No errors, Therion just echos what is typed > in the text string. I only ever used it directly in the metapost (it's in my code for creating custom labels). In the .th, Therion turns everything into \char103 escape sequences. In the metapost, you have more control. I don't know of a way to inject tex control characters directly from a .th but I have no doubt someone else on this mailing list will know a lot more than me. You could create custom labels with your own string replacement to add your own control character, like instead of , but that only works for symbols. Not sure how to do that for strings in the cave info. ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] How to add 1.5 x linefeed to a text string
>> I'm wondering if there is a way to add a 1.5x linefeed to text >> strings in Therion? >Not sure if there is a proper way, but you can just put tex into the text input in xtherion, right? If so, you could try foo \thtinysize \thnormalsize bar Could not make that work. No errors, Therion just echos what is typed in the text string. Some examples of what I tried... -text "25 <\thtinysize> P" -scale l -text "25 \thtinysize P" -scale l map-comment "NZVD2016 / New Zealand Vertical Datum 2016 \thtinysize This map represents..." Perhaps there is a way to force interpretation of part of a text string as a tex control? Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] How to add 1.5 x linefeed to a text string
Good evening I'm wondering if there is a way to add a 1.5x linefeed to text strings in Therion? I can make the same effect using the tex parameter \medskip as demonstrated in the Therion \legendcontent routine. But sometimes it would be nice to do it in drawing labels and in strings such as map-comment, were it is not practicable to use tex. As in this example: The text highlighted yellow is a map-comment, like this: map-comment "NZVD2016 / New Zealand Vertical Datum 2016 \ This map represents Deer Pot on the day it was connected to ." . and the vertical 1.5x linefeeds are embedded in the \legendcontent tex. I want to add an extra half space between the two yellow lines. The only way I can think of is a bit of a hack. map-comment "NZVD2016 / New Zealand Vertical Datum 2016 \ This map represents Deer Pot on the day it was connected to." but it does not work! It seems that a and a 'space' does not render as anything other than the highest character on the line, regardless of the 'size' of the break. Any ideas? Regards Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Big room multiple scraps - How to join
Bill As Tarquin points out, looks to me like scraps with openings wider than the scrap is long. The solution is invisible walls along the interior joins. Another thing to check is that all the walls have the correct orientation - all the left-side yellow ticks point to the interior of the passage (if not for pdf outputs, it still helps for models). And that wall -outline is set correctly to out, in or none. Bruce -Original Message- From: Therion On Behalf Of Bill Gee Sent: Thursday, 3 August 2023 03:28 To: Therion Mail List Subject: [Therion] Big room multiple scraps - How to join Hello everyone - I am having a problem getting Therion to understand how to join several scraps to make a large room. The working map is at https://campercaver.net/MiscFiles/StarkCavernsNoCenter.pdf Take a look at the east part of the map in an area called Grand Canyon. This is really one large room, though we did not realize that when we started sketching several years ago. Now I have at least three different pieces of sketch to try and fit together. As you can see, there is a large triangle in the center which Therion thinks is not cave. There are also some part which are outside the cave, but are considered by Therion to be inside. All of the joins in here are using line-to-line. I named the lines, then created "join" statements specifying the two lines and which points on those lines to join. Therion is happy with that, and the wall that it draws is a fair depiction of the area. The problem is that much of the interior is getting lost. I have not tried to use plain joins of the scraps - joins which do not specify the lines. I suspect that would not change much. I have already drawn some of this area three times. It is extraordinarily complicated due to multiple levels, especially along the east side. We thought for a long time that the east side was separate passages, but it is really just a complicated pile of big breakdown blocks. I really REALLY do not want to go back and make one huge sketch of the entire room. That would take several days. What can I do to convince Therion where the cave really is? Can I put in some invisible walls (subtype hidden)? Thanks! -- === Bill Gee ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] map colour usage description in Therion Book
Hello Just now I was having difficulty remembering how to colour a particular map a specific colour, different to the colour scheme applied to most of the maps being output. My first challenge was to figure out that this could only be done via 'select' in a thconfig, and not within the definition of a map. I think that the Therion Book could do with a small edit to clarify usage of 'select map -colour [r g b]'. The Therion book says. 'map' Description: A map is a collection of . Arguments: . . colo[u]r set the map colour; this option overrides the automatic choice when the layout specifies colour map-fg [map]. >From that I had the incorrect impression that specifying a colour when selecting a map for output would always override. What I have found is that this is only sometimes true. Map select colour overrides when. colour map-fg [r g b] colour map-fg scrap colour map-fg map Map select colour does not override when. colour map-fg altitude colour map-fg topo-date colour map-fg explo-date For (sub)maps where there is no date set, the map select colour will be shown, otherwise select map -colour [r g b] has no effect. So I suggest an edit to the Therion Book along the lines of. 'map' Description: A map is a collection of . Arguments: . . colo[u]r set the map colour when selecting a map; this option overrides the specified colour palette when the layout specifies colour map-fg [map], [scrap] or []. It has no effect when the layout specifies colour map-fg [altitude]. It has no effect when the layout specifies colour map-fg [topo-date] or [explo-date], for the scraps whose associated surveys have dates assigned. I have not assessed how this plays out with lookups <https://therion.speleo.sk/wiki/examples#colour_palette_scales_-_lookups> , but I imagine they should not have any different impacts to those described above. Regards Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Statistics on surveys of a network
MS Outlook blocks attachments with extension .py Perhaps you can repost after changing the extension to .txt? Thanks Bruce -Original Message- From: Therion On Behalf Of Philippe Vernant Sent: Wednesday, 10 May 2023 20:54 To: List for Therion users Subject: Re: [Therion] Statistics on surveys of a network Hi guys, Thanks for the answers. I wrote a python script. It is far from being elegant but it does the job. I attach it to this message in case it can be helpful to some of you. Cheers, Phil ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] map-comment
Check in the Therion Book and wiki for quite a lot of other options. Bruce Sent from my Galaxy Original message From: Erik Meitner Date: 4/04/23 11:00 (GMT+12:00) To: therion@speleo.sk Subject: [Therion] map-comment Hi folks,Is there any way to create a multi-line map-comment? An example assuming "\n" does what I want: map-comment "Line one.\nLine two."Would create:Line one.Line two.Thanks!Erik___Therion mailing listTherion@speleo.skhttps://mailman.speleo.sk/listinfo/therion___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] 2 Map-connection issue - Going to four levels - Offset tests SAMD-ITF-IS example
Thanks Martin So we now have confirmation of the same inconsistent map-connection behaviour, relative to offset level, across three different ways of managing surveys and maps: * Separate surveys and maps (Martin's example, Therion best practice) * Maps defined in surveys (My example from 2022, TopParser, Sexy Topo approach) * Maps defined separate to surveys, but then included in next-level surveys (My usual practice) Suggests to me that the inconsistent map-connection behaviour is not related to how surveys and maps are managed, but is rather a built-in characteristic of Therion behaviour. Tarquin mentioned that he could not replicate this inconsistent behaviour. Now that we have teased out the problem some more, can you confirm that you were testing the same issue Tarquin? Bruce From: Therion On Behalf Of Martin Sluka via Therion Sent: Friday, 24 March 2023 08:28 To: List for Therion users Cc: Martin Sluka Subject: Re: [Therion] 2 Map-connection issue - Going to four levels - Offset tests SAMD-ITF-IS example 23. 3. 2023 v 20:13, Bruce Mutton mailto:br...@tomo.co.nz> >: One more question. I presume you have strict separation of surveys and maps in this dataset, as demonstrated here <https://therion.speleo.sk/wiki/faq#how_to_arrange_the_maps> https://therion.speleo.sk/wiki/faq#how_to_arrange_the_maps and <https://therion.speleo.sk/wiki/s_m> https://therion.speleo.sk/wiki/s_m ? I use it as preferred method. Martin ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] 2 Map-connection issue - Going to four levels - Offset tests SAMD-ITF-IS example
Thanks Martin The definition shows just first level offsets. Taken together with the submap naming and the image of the map itself, I deduce that: - map s11-20 contains a second level offset. - map s19-24-25 contains a second and third level offset. This is the one that I am unsure as to whether or not it displays the bug I have proposed. Hopefully I have identified them correctly in the image below. - none of the other maps include an offset. modrovska_s12-21.map seems to include two maps, but they have not been offset from each other. 1. Can you supply the map definitions for modrovska_s19-24-25.map, and any submaps it might contain, down to scrap level? 2. Can you change the offsets for the submaps below modrovska_s19-24-25.map so they do not line up with each other? I am suspicious that the map-connection line that I have highlighted in light blue shows that the bug I describe is present in your example. ie The intermediate offset level (light blue map) map-connection line reverts to originating from the top-level map, and not from its direct parent. But I cannot be sure without the above two bits of information. Also, another variable. I presume from our correspondence over the years that it is likely that this dataset maintains complete separation of maps from surveys. ie There are no survey objects that have map objects defined within them. That will be interesting regardless of whether this dataset manifests this ‘bug’ or not. Thanks for your effort. Bruce From: Therion On Behalf Of Martin Sluka via Therion Sent: Thursday, 16 March 2023 22:33 To: List for Therion users Cc: Martin Sluka Subject: Re: [Therion] 2 Map-connection issue - Going to four levels - Offset tests SAMD-ITF-IS example Definition of that map: map modrovska_plan.map -title "Modrovská jaskyňa" modrovska_s01.map modrovska_s03.map break modrovska_s30.map modrovska_s12-21.map [-18 10 m] below break modrovska_s27.map #Mostová sieň break modrovska_s26.map [10 -5 m] below modrovska_s16.map [25 10 m] below break modrovska_s11-20.map [-7 -5 m] below break modrovska_s19-24-25.map [0 -10 m] below modrovska_s13.map [-10 5 m] below modrovska_s28.map [-2 -9 m] below break modrovska_s14.map [14 -3 m] below break modrovska_s15.map [1 -22 m] below modrovska_s22.map [-20 0 m] below endmap 15. 3. 2023 v 19:56, Bruce Mutton mailto:br...@tomo.co.nz> >: Interesting Martin Your example mostly demonstrates one level of offset, but it goes to two levels bottom-left (to blue to purple), and apparently three levels at the bottom (to green to blue to dark blue). However looking closely it seems that the map-connection line to blue goes directly from yellow (ie not from green). If this is the case there are two scenarios: Scenario 1 - based on the map-connection line I have highlighted, both the green and blue are first-level offsets. I may be mistaken as the image is not sufficiently clear. If it is two levels of offset, then that is not sufficient to trigger the ‘bug’ David and I have described. If it is three levels of offset, then you have somehow managed to avoid the ‘bug’ and the map-connection lines/points are coincidentally on the same alignment. Scenario 2 – is that this example demonstrates the ‘bug’ described, if not particularly clearly. My synopsis of the bug was “the line created by point map-connection is only correctly originating from its parent map at the most deeply nested level of offset and at the 1st level offset. At all other (intermediate) offset levels, the map-connection line reverts to originating from the top-level map, and not from its direct parent.” So Martin, if you could perhaps clarify. I suggest adding a horizontal component to the light blue map in my snip above, and confirming whether the map offsets are two or three level. If it is two level, it does not test the bug. If it is three level and there is no ‘bug’, the map connection line, blue to dark blue, should radiate from blue and not from yellow. Tarquin I’ll respond to your message later – off to work now! Thanks Bruce From: Therion mailto:therion-boun...@speleo.sk> > On Behalf Of Martin Sluka via Therion Sent: Wednesday, 15 March 2023 23:08 To: List for Therion users mailto:therion@speleo.sk> > Cc: Martin Sluka mailto:martinsl...@mac.com> > Subject: Re: [Therion] 2 Map-connection issue - Going to four levels - Offset tests SAMD-ITF-IS example Just a sample. Colorised by altitude. M. ___ Therion mailing list <mailto:Therion@speleo.sk> Therion@speleo.sk <https://mailman.speleo.sk/listinfo/therion> https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] 3 Map-connection issue - effect of map-level
Hi Tarquin Yes, I added a lot of tedious detail to https://github.com/therion/therion/issues/412 some time ago. I suggest ignoring most of the information I posted in there and skipping right to the last post I made on 11 July 2022. The images from that particular example are from a project that is modelled directly on what I understand is the typical UK usage of Therion, as resulting from TopParser and SexyTopo exports - that first level maps are defined directly in the corresponding survey. The images in my earlier posts (Laghu) are from a project modelled on my so far preferred paradigm, where first level maps are defined outside of the corresponding survey, but are subsequently included in the parent (ie whole cave) survey. The behaviour I observe with respect to this matter is identical for both Therion project configurations. I’d probably need to see some actual map definition examples and resulting outputs, Tarquin, each having map-connection points/lines in each sub-map so that I can understand how you have made it work (or not) ;‑) For starters, lets see if Martin S can provide a bit more detail on his example. Bruce -Original Message- From: Therion On Behalf Of Tarquin Wilton-Jones via Therion Sent: Thursday, 16 March 2023 00:51 To: therion@speleo.sk Cc: Tarquin Wilton-Jones Subject: Re: [Therion] Re : 3 Map-connection issue - effect of map-level Hi David > Thks a lot for your answer that seems to confirm thé bug, i saw thé > same Behavior as Bruce discribed with acuracy in my project. > I will remove thé connection point on thé faulty level replaced by an > arrow line. Less clean but more logical. As I said in my previous emails (our different thread "Map connection issue" from 2 years ago), I only ever use 2 levels, and it works perfectly. And it also worked when I tried to expand it into more levels. We discussed what I do there, that made it work correctly: <https://www.mail-archive.com/therion@speleo.sk/msg08912.html> https://www.mail-archive.com/therion@speleo.sk/msg08912.html I thought Bruce prepared some samples that made it go wrong, so that a bug could be filed. Cheers, Tarquin ___ Therion mailing list <mailto:Therion@speleo.sk> Therion@speleo.sk <https://mailman.speleo.sk/listinfo/therion> https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Remove little text in global export & offseted map
David, Tarquin I think we discussed the map-connection offsets last year, without real resolution. I couldn’t find them in the mail-archive just now, so I’ll send my posts again in the hope that they describe the problem and present results of some experimentation that defines somewhat the parameters of the problem. Stand by. Bruce From: Therion On Behalf Of david Le berre via Therion Sent: Tuesday, 14 March 2023 03:12 To: therion@speleo.sk Cc: david Le berre Subject: Re: [Therion] Remove little text in global export & offseted map Dear Tarquin Thanks a lot for your answers min-symbol-scale m => works well eventhough as you mentionned wall disapearred ! fortunatly I have colored surfaces everywhere and except cross-over section that I will re-scale manually the rest is really correct! I try to be more clear on my second topic, the problem is that the connection arrow between offsetted map sometimes skipped the N+1 map to be connected directly to the N+2 map: Exemple: 1 - (level N+2) Global map: MAP 1 2- (level N+1) offsetted network below from MAP1= MAP2 => map connection point arrow of MAP2 goes from its shadow on MAP1 to MAP2 => ok 3- (level N) offsetted network below from MAP2= MAP3 2 cases: 3.1 MAP3 is built by scrap S1 S2 etc => ok map connection point arrow goes from MAP3 to its shadow on MAP2 and then idem from MAP2 to MAP1 => clean 3.2 MAP3 is built by other MAP (level N-1) => Ko map connection point arrow goes directly to shadows on MAP1 skipping its shadow on MAP2 I hope it is more clear, if not I'll send you tonight a better description with picture. the problem is that in case there are several map to offset the rendering at the end is unclear except if you keep all your rmap at the level 1 (ex level of MAP2) but in that case you can not follow easely the real path in your cave. Not sure it is better :) David . Le lundi 13 mars 2023 à 11:56:31 UTC+1, Tarquin Wilton-Jones via Therion mailto:therion@speleo.sk> > a écrit : Hi David, > My survey is quite huge and I need to export different scales > In the biggest I would like to remove all little object and particularly > text from the export to make it more understandable. Yes, but also no: https://therion.speleo.sk/wiki/templates#setup_a_default_standard_layout layoutstandards.txt has some metapost code that can hide small text labels. *BUT* the way it works is to physically measure the size of the text label. So if - for example - you have something like this: point 740.0 918.5 label -scale xl -text [foobar] -align left The linebreak in there makes the rendered text block taller than one line of text would be. The metapost code does not understand that, so it assumes it must be a large text size, and it allows it to render. (Yes, it would be possible to make the code check only the first text character, but that is not as easy as you might think, since the first character can be a linebreak, or formatting.) You can also use this layout option: min-symbol-scale M but that affects all symbols at once, and you need to remember that all lines have a default size, even if you did not explicitly set one! Therion really, really needs to have a setting like this: min-symbol-scale point label M * wishes * > *2- Offseted map:* > > this topic is known but I would like to know if there were some progress? > > Some under-level of offsetted map refers directly to the initial shadow > when using connection map point. Sorry, I do not understand this question, could you perhaps explain in more detail? Cheers, Tarquin ___ Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Mapiah and WTherion
I've been dabbling with WTherion, and while it is progressing well and looking very good in many respects, it is flagged as a sort term interim project (on Matrix <https://app.element.io/#/room/> ) and I see some high-level challenges: * it seems a document must be saved in three places for it to be an enduring part of a mapping project: * a browser cache (required, and visible only to a particular browser on a particular device) * a json file (if you want to store or share the document (presumably) without loss of fidelity) * a th2 file (if you wish to compile the document using Therion) * In a multi-user project, unless everyone uses the workflow [WTherion open json, edit, export th2, compile Therion] there will be loss of fidelity. ie if some users choose [XTherion open th2, edit, compile Therion] then the WTherion users must 'know' to import from th2. This will result in loss of fidelity, especially where there are xvi files in the th2. For me multi-user and version-controlled storage are prerequisites for any mapping projects, and because it seems for most users, (readers of this forum excepted of course) both Therion and version control are significant challenges, any drawing editor should fit seamlessly into the existing Therion environment. Most likely this means it should read and write th2 files natively. Please tell me if I am wrong. As a self-taught dabbler I am only too happy to be shown the error in my thinking. Anyway, I got to thinking about Mapiah. I think the development for Mapiah is here and was last updated in February? https://gitlab.com/rsevero1/mapiah/-/releases I installed 0.0.3 and it looks like it is still in the very early stages. Is it still under consideration for further development? Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] More on showing only some cross-sections
> Is there a list of the predefined contexts and groups? >From the Therion Book (pg 53), group may be one of the following: all, centerline, sections, water, speleothems, passage-fills, ice, sediments, equipment. text, cave-centreline, surface-centreline ...depending on the context. Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] filtering for export continuation-list
Like this https://therion.speleo.sk/wiki/drawingchecklist#points and scroll down to point continuation -text "Description" -attr who "M Name" -attr what climb -attr priority low -attr ref plan # -explored 8.0m 'who' is the person(s) who identified the the item, or the person assigned to resolve the issue. 'what' can be rift|climb|pitch|squeeze|tight|sump|rock-pile or whatever you like. (I'm thinking of using it as a 'to do' list so I could add, for example survey|re-rig) 'priority' can be any number, text phrase or be omitted, 'ref' is intended to indicate where the data entry to this point is made, ie plan|elev|centreline, where = ext for extended elevation, or, say 090 for the direction of a projected elevation, or centreline if it is in the .th file (Therion does not yet report the location of this information, so manually entering it helps down the track when you want to make edits and updates). For more explanation follow the link. Bruce From: Therion On Behalf Of A Gott Sent: Thursday, 25 August 2022 08:11 To: List for Therion users Subject: [Therion] filtering for export continuation-list HI Therion friends, A friend posed an interesting question on a data set we hold in Therion. We have entered a lot of leads (point continuation's) in both elevation and plan th2 files. we have come to export these and have found that they are both coming out together, with neither being an exact copy of each other it's hard to tell them apart. Is there any way you can filter the "export continuation-list" to only output plan continuations? At present for a workaround, I have suggested exporting to .txt and copy and pasting into excel, so that the list can be filtered. is it possible to filter prior to export? (if not, would it be possible to include an extra column on the export to show which projection the continuation was noted in, eg. plan, extended, elevation [90] - so this can then be filtered in excel/a database). I note that even when using a select from the map structure, therion still defaults to looking at the full .th dataset. Regards, Alastair Gott. ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Export centerline and LR (plan) UD (section)
Răzvan Looks like you answered your question. You have an xvi that displays left and right dimensions. If you want these to be visible in other formats, such as pdf, then you need to set a map foreground colour that differs from the background colour. The simplest way to do this is something like this in your layout. colour map-fg [97 86 38] # yellow brown Possibly you can do it directly in the export statement. Maybe something like this (pg 61 of more or less current Therion Book – I’m not certain of the syntax) export map -projection plan \ -layout-colour map-fg [97 86 38] \ -output hhh.pdf Bruce From: Therion On Behalf Of Razvan Dumbrava via Therion Sent: Tuesday, 23 August 2022 00:03 To: therion@speleo.sk Cc: Răzvan Dumbravă Subject: [Therion] Export centerline and LR (plan) UD (section) Hello Is there any possibility to export (in any format) the centreline and the LR (for plan)? The data for centreline is units length meters units compass clino degrees data normal from to length compass clino 0 1 1.21 137.1 -12.8 1 2 8.75 33.3 1.8 and the data for LRUD is separate, like this: units left right up down meters data dimensions station left right up down 25 1.23 16.71 16.71 1.43 10 3.72 6.73 6.73 1.67 5 1.32 4.86 4.86 1.06 When i use export map -projection plan \ -output hhh.xvi It exports someting like this, with 2 LR in every station... Thanks! Răzvan Dumbravă raz...@yahoo.com <mailto:raz...@yahoo.com> ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Label and passage height colours
I’m sorry Paul, I’m still inside a Covid cloud it seems. -context works with symbol-show and symbol-hide but not with symbol-colour, so it is not a solution to your problem. Bruce From: Therion On Behalf Of Paul Rowe Sent: Monday, 1 August 2022 18:41 To: List for Therion users Subject: Re: [Therion] Label and passage height colours Hi Bruce, Yes, I was wanting to change a specific instance. These are great tips. Using the colour of another point type that I'm not using, then changing the context for other specific points, would be a simple hack that I think would cover me. Cheers, Paul On Mon, 1 Aug 2022 at 18:12, Bruce Mutton mailto:br...@tomo.co.nz> > wrote: Hi Paul If you are asking if it is possible to change the colour of a specific instance of a particular type of generic object, I think the answer is no, unless you modify the metapost definition for the generic object to allow attributes such as colours to be parsed. If you want all of a generic object type to be a colour, then use a layout statement something like: symbol-colour point label Easy hacks to mimic the first question include… Use point remark and set its colour to something striking with: symbol-colour point remark You can change the fonts to add or remove emphasis. Or use -context to make the label inherit colour as though it were another type of symbol… point label -text “label text” -context point anastomosis and symbol-colour point anastomosis I suspect not all point types work with -context, so you may have to hunt around to find one that works. Bruce From: Therion mailto:therion-boun...@speleo.sk> > On Behalf Of Paul Rowe Sent: Monday, 1 August 2022 15:30 To: List for Therion users mailto:therion@speleo.sk> > Subject: [Therion] Label and passage height colours Is it possible to change the label and/or passage height colours for specific points? I couldn't see a way of doing this. Thanks, Paul Rowe ___ Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Label and passage height colours
Hi Paul If you are asking if it is possible to change the colour of a specific instance of a particular type of generic object, I think the answer is no, unless you modify the metapost definition for the generic object to allow attributes such as colours to be parsed. If you want all of a generic object type to be a colour, then use a layout statement something like: symbol-colour point label Easy hacks to mimic the first question include… Use point remark and set its colour to something striking with: symbol-colour point remark You can change the fonts to add or remove emphasis. Or use -context to make the label inherit colour as though it were another type of symbol… point label -text “label text” -context point anastomosis and symbol-colour point anastomosis I suspect not all point types work with -context, so you may have to hunt around to find one that works. Bruce From: Therion On Behalf Of Paul Rowe Sent: Monday, 1 August 2022 15:30 To: List for Therion users Subject: [Therion] Label and passage height colours Is it possible to change the label and/or passage height colours for specific points? I couldn't see a way of doing this. Thanks, Paul Rowe ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Map-connection issue
> But I just tested it done with multiple levels, and my offset arrows still > work, so I cannot reproduce the behaviour you described. It is always the > inner-most offset (so to speak) that creates the arrow. At least with my > stuff - you doubtless have much more complex stuff than me. ...mumbles "must be something I'm doing", and "I was trying to keep my data structure simple". Obviously I failed on the simple bit. Clutching at straws - I wonder if it because I define lowest level maps outside of the survey they are associated with? map 5-HawkesPlan -projection plan 5-HawkesPlan-s1 5-HawkesPlan-s2 endmap map 5-HawkesPlanCL -projection plan 5 # a map containing only the survey centreline endmap survey 5 -title "5-Hawkes" centreline #survey data here endcentreline endsurvey 5 A crude attempt at trying to bisect to a possible cause: * I'm guessing Tarquin defines his maps INSIDE lowest level surveys (survey 5 in the above example), rather than outside as I have done above. * David, I wonder which approach you use? Low level maps defined inside or outside of the low level survey? Regardless of the outcome of this quiz it won’t necessarily point to a correct reason, because there are other characteristics of project setup that could affect the answers (relationship of these low level surveys and maps to the surveys and maps that collect together the whole cave). Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Remove symbols from legend
> Can p_u_foo be hidden from the legend? Some examples. Statements need to be in thconfig outside of layouts. #symbols removed from legends text en "point u:foo" "" text en "point station:temporary" "" text en "line wall:bedrock" "" text fr "line wall:bedrock" "" text mi "line wall:bedrock" "" text en "line border:visible" "" text en "line border:temporary" "" text en "line border:presumed" "" text en "line rock-edge" "" text en "area bedrock""" text en "point stalactites" "" text en "point stalagmites" "" Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Extend start control, a possible bug and a feature request
I'm working on an extended elevation for a short cave that has 10 loops and I'm having trouble getting the extended elevation that I would like. I suspect that it would be easier if I placed the extend statements in each of the survey data centrelines where the legs are enumerated, but instead I am trying to put the extend statements in a separate file dedicated to extended development (described in https://therion.speleo.sk/wiki/extend ) So I may be the author of my own torment. Anyway I persist; I may have found a bug and I have a request to augment the 'log extend' feature: The bug - Extend appears to (re)START at the end of splay shots #432 <https://github.com/therion/therion/issues/432> The feature request - Can log extend echo status for legs that have been hidden #433 <https://github.com/therion/therion/issues/433> Thanks Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] new Therion 6.1.0
> Just got around to updating, using the standard "Windows installer" on the Therion download page. In this release, I have been getting this error on Windows 10 when trying to run Loch: > This doesn't sound like something wrong on my machine, but I would have expected someone else to mention it already if it was wrong with the Therion release. Did I miss something? ___ Same, although I only got it twice, and then not again. Mind you I frequently reinstall the therion-setup-msys2 via the GitHub Actions workflow artifacts. I had not associated the error specifically with the download page route and had it pegged as a mystery to watch for... Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Is copying supposed to be done in reverse?
Ha! It was the great Tarquin who provided me with insight one year ago https://www.mail-archive.com/therion@speleo.sk/msg08109.html ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Is copying supposed to be done in reverse?
Hi Tarquin I have occasionally had unexpected behaviours due to conflicting layout calls, and came up with the recipe here for hierarchy and order of calls some time ago https://therion.speleo.sk/wiki/bds#order_of_layout_functions_called As far as I am aware, the last called layout or statement always wins. Certainly since I started using the recipe I have not noticed any problems, and my layouts occasionally have conflicting parameters for a particular setting (which is why I originally had problems - I was not rigorous about call order). Seems to conflict with your experience, maybe mine are simpler? (I don't see an endlayout for your layout third - could that be something) Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] extend start mysteries
Hello again I notice that the extend log sometimes includes many START statements. I can understand why the algorithm needs to reset itself once it gets to the end of a branch, and then backtracks all the way back to the original start, having generated all of the side passages on that branch on its way. At this point it needs to decide where to start again. This suggests to me that the user should be able to influence the subsequent start stations, so long as they study carefully where the first branch development is finally exhausted. However, I notice that if I specify multiple start statements, only one of them is ever used. What is going on here, and can the user influence subsequent start stations? In addition some of the start stations appear to be splay stations. Since in general splay stations are not considered part of the primary survey leg centreline structure, surely this is some kind of bug? Here is an extract from an extend log. START 3.67@3.Hawkes START -@2.Hawkes RIGHT 2.29@2.Hawkes done Thanks Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] looking for code metapost for area Blocks
Hello Gilbert Here is a link to the instructions for extracting the metapost used by your Therion installation. https://therion.speleo.sk/wiki/metapost#how_to_get_therions_metapost_code_an d_tex_code Enjoy Bruce -Original Message- From: Therion On Behalf Of Gilbert (liste) Sent: Tuesday, 31 May 2022 06:13 To: List for Therion users Subject: [Therion] looking for code metapost for area Blocks Hello, I'm looking for the code metapost for area blocks, I want to custumize it in my survey. I found several exemple for area and lines, but not the specific "area blocks". Can you send it to me or send the url web page where we can find it ? Thanks Gilbert ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] New default settings and recent proj changes
Thanks Martin That all makes sense now. Strange how my Windows search could not find the folder even though I was explicitly searching for it. All sorted out now. Bruce From: Therion On Behalf Of Martin Budaj Sent: Thursday, 28 April 2022 08:32 To: List for Therion users Subject: Re: [Therion] New default settings and recent proj changes Hi, it should be in C:\Users\\AppData\Local\proj See also https://proj.org/resource_files.html#user-writable-directory Implementing delete/redownload would be problematic (but proj is smart enough to download again if the remote grid file gets updated;) M. On Wed, Apr 27, 2022, 21:33 Bruce Mutton mailto:br...@tomo.co.nz> > wrote: Hi Martin eaec752 looks like it should provide clarity. I would like to be able to compile a dataset that activates this code (for curiosity and maybe user testing), but it seems now that 'my therion' has downloaded the transformation grid once, it resides somewhere on my machine (I cannot manually find it though). It seems like it has downloaded the entire NZTM grid (as the documentation says it would) and so any locally compiled cave dataset no longer needs to download the grid (which in the normal course of events is good). I have compiled therion datasets for caves in other parts of the world, but none have triggered this code. I presume the grids they use are already built-in by default. So for the sake of curiosity, is it possible to get Therion to delete an existing (previously downloaded) grid and so subsequently trigger the need to download it and test the eaec752 change? Will using cs-def to set a null string for NZTM force it to be downloaded again? Or will it cause proj-missing-grid to behave as though it is set to ignore (even if download is specified)? Asking before trying it in case I end up breaking something that is hard to fix! Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] New default settings and recent proj changes
Hi Martin eaec752 looks like it should provide clarity. I would like to be able to compile a dataset that activates this code (for curiosity and maybe user testing), but it seems now that 'my therion' has downloaded the transformation grid once, it resides somewhere on my machine (I cannot manually find it though). It seems like it has downloaded the entire NZTM grid (as the documentation says it would) and so any locally compiled cave dataset no longer needs to download the grid (which in the normal course of events is good). I have compiled therion datasets for caves in other parts of the world, but none have triggered this code. I presume the grids they use are already built-in by default. So for the sake of curiosity, is it possible to get Therion to delete an existing (previously downloaded) grid and so subsequently trigger the need to download it and test the eaec752 change? Will using cs-def to set a null string for NZTM force it to be downloaded again? Or will it cause proj-missing-grid to behave as though it is set to ignore (even if download is specified)? Asking before trying it in case I end up breaking something that is hard to fix! Bruce -Original Message- From: Therion On Behalf Of Martin Budaj Sent: Wednesday, 27 April 2022 18:23 To: List for Therion users Subject: Re: [Therion] New default settings and recent proj changes Good idea! The latest commit provides additional information about downloads now. Caching is more tricky: we just enable it and Proj then downloads just small parts of grids relevant to your area and stores them in its database without letting you know what exactly got downloaded. Martin On Tue, Apr 26, 2022 at 9:43 PM Bruce Mutton wrote: > > Thanks Martin ... > A suggestion below. > > therion 6.0.6+14fac78 (2022-04-26) > > - using Proj 9.0.0, compiled against 9.0.0 > initialization file: C:\Program Files (x86)\Therion/therion.ini > reading ... done > configuration file: thconfig-GLMESM_System5000Map.thc > reading ... done > reading source files ... downloading the grid > https://cdn.proj.org/nz_linz_nzgd2kgrid0005.tif... done > saved/cached grid file: C:\path\ nz_linz_nzgd2kgrid0005.tif > done > > Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] New default settings and recent proj changes
Thanks Martin That helps a lot. I wonder if therion.log could echo the destination folder for downloaded files? (I could not find it on my machine) A suggestion below. therion 6.0.6+14fac78 (2022-04-26) - using Proj 9.0.0, compiled against 9.0.0 initialization file: C:\Program Files (x86)\Therion/therion.ini reading ... done configuration file: thconfig-GLMESM_System5000Map.thc reading ... done reading source files ... downloading the grid https://cdn.proj.org/nz_linz_nzgd2kgrid0005.tif... done saved/cached grid file: C:\path\ nz_linz_nzgd2kgrid0005.tif done Bruce From: Therion On Behalf Of Martin Budaj Sent: Wednesday, 27 April 2022 05:24 To: List for Therion users Subject: Re: [Therion] Problem with new default settings and recent proj changes On Tue, Apr 26, 2022 at 11:45 AM Bruce Mutton mailto:br...@tomo.co.nz> > wrote: I am a little confused, as Therion automatically downloaded the grid and yet my therion.ini does not have any of the proj-auto or proj-missing-grid settings mentioned in the 14fac78 Therion Book pg 86-87, which raises for me many questions. I assume the functionality of those ini statements is now superseded by the proj.ini that is now present in the install folders (as you described as "use the best transformation and download the grids if needed") and that the Therion Book is yet to be updated? Indeed, thbook needs an update. Now, proj-auto is 'on' by default and proj-missing-grid is 'download'. Or maybe I am not looking I the correct place for the ini files that Therion is actually using? If the setting is missing in therion.ini, therion just uses the defaults. You can always override them in the therion.ini file. Can Therion be run without having internet access (or without first having had internet access for a particular survey dataset at some previous time)? Definitely. With the new defaults, it would attempt to download the grid (only if proj can't find it locally) and end with an error message if there is no internet connection. You can do either of these: * change the proj-missing-grid setting to warn, e.g. (this prints a warning stating which grid you need to download manually, then download it and put somewhere where proj finds it) * set proj-auto off (this is the old behaviour where proj doesn't look for the optimal transformation) * get online, run therion once, and the grids would be reused in the subsequent runs without internet connection In the attached file, do the transformations marked [no] and [yes] relate to whether they are used or not? All listed transformations are used. AoU: [no] or [yes] indicates, whether proj optimised a transformation for your particular area (defined by the fixed stations in your data set) [yes] or not [no]. And presumably the accuracies listed are the estimated accuracies? Yes, estimated by proj. Can I use proj-missing-grid to improve the accuracy of my example further or is 4m accuracy the best I am likely to get for this particular dataset? Sure, the accuracy when using grids should be in centimeters. It's interesting that in your log file the grid is downloaded (twice!) but not actually used by proj, it would be worth investigating why. Anyway, for cases when you think you can do better than proj (including using a grid file), you can use 'cs-trans' to define a custom transformation between two coordinate systems; see an example in thbook. Probably your local GIS community has already defined such transformations; in the case of Slovakia, our cartographic office published such a list for QGIS users, which can be easily adopted for therion. Martin ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Updated XTherion editor side panel adjustment
Tarquin There are a number of size settings listed in the default xtherion.ini: ## size of point # set xth(gui,me,point,psize) 4 ## size of line point # set xth(gui,me,line,psize) 3 ## line width # set xth(gui,me,line,width) 3 ## size of line control point # set xth(gui,me,line,cpsize) 4 Adjusting these did occur to me, but I was being lazy and asking first, rather than experimenting. I was hoping to keep the small size but have a large snap distance. A comment in the ini file says there are many variables that have not been listed in the default ini files. So thought I may as well ask. I will have a play with the settings above next time I have a drawing session. Bruce -Original Message- Cc: Tarquin Wilton-Jones Subject: Re: [Therion] Updated XTherion editor side panel adjustment On 28/02/2022 01:12, Bruce Mutton wrote: > I expect there may be a variable I > could edit in XTherion.ini (or is XTherion.new.ini, there seems to be > one of each) that will increase the snapping distance. It does not appear to be a snapping distance, per se. It appears to snap to the points when your cursor is over the top of whatever point you are trying to snap to. So the "distance" is basically "the point icon's size". That means that to change it, you would need to change the size of the point icon (normally a circle, but a triangle in the case of station points). Though maybe there is some scaling option somewhere for that. ___ Therion mailing list <mailto:Therion@speleo.sk> Therion@speleo.sk <https://mailman.speleo.sk/listinfo/therion> https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Updated XTherion editor side panel adjustment
I’m liking the (slightly) new look XTherion. Just one thing, with the smaller and finer linework and points, and I guess a not so large 4K monitor, shaky hands and poor eyesight, I’m finding it quite hard to reliably get my cursor close enough to existing points for it to snap onto them. I expect there may be a variable I could edit in XTherion.ini (or is XTherion.new.ini, there seems to be one of each) that will increase the snapping distance. If so, what is the variable name? (and how to use?) Bruce From: Therion On Behalf Of Bruce Mutton Sent: Wednesday, 23 February 2022 20:53 Subject: Re: [Therion] Updated XTherion editor side panel adjustment missing OK, therion-setup-msys2-3f54ee7 is good. Thanks ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Ukraine
I am sure there are people on this list that are more than a little affected by the invasion of Ukraine. While lucky enough to be far away, I am shocked and am thinking of you, my friends, and how I might help in some small way. Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Updated XTherion editor side panel adjustment missing
OK, therion-setup-msys2-3f54ee7 is good. Thanks From: Therion On Behalf Of Stacho Mudrak Sent: Wednesday, 23 February 2022 20:33 To: List for Therion users Subject: Re: [Therion] Updated XTherion editor side panel adjustment missing Thanks Bruce for finding out, I have forgotten, there is a menu item for switching panels and I was too lazy to change .ini file to test it. It should be fixed now. S. On Wed, 23 Feb 2022 at 08:08, Bruce Mutton mailto:br...@tomo.co.nz> > wrote: Thanks Stacho That is so so much better. What I have secretly wished for, for many years! But. Both 3f4366c and 683b226 have problems when menu Window.Switch Panels is used to put the control panel on the left-hand side. A screenshot here from the earlier 3f4366c, although 683b226 does the same sort of thing. The adjustable panel moves, and is adjustable, but the controls do not. Same for the text editor, map editor and compiler windows. I am not so worried, as I’m used to it on the right-hand side, but I suppose a fix is the right thing to do! Bruce From: Therion mailto:therion-boun...@speleo.sk> > On Behalf Of Stacho Mudrak Sent: Wednesday, 23 February 2022 07:59 To: List for Therion users mailto:therion@speleo.sk> > Subject: Re: [Therion] Updated XTherion editor side panel adjustment missing Hi Bruce, I have tried a more standard solution (commit <https://github.com/therion/therion/commit/683b226065e092e3b9d38aa292141b5065b07a2d> 683b226) - an adjustment line alongside the whole screen. It should be 1.5mm thick (according to OS-supplied resolution). Does that solve the problem? S. ___ Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Updated XTherion editor side panel adjustment missing
Thanks Stacho That is so so much better. What I have secretly wished for, for many years! But. Both 3f4366c and 683b226 have problems when menu Window.Switch Panels is used to put the control panel on the left-hand side. A screenshot here from the earlier 3f4366c, although 683b226 does the same sort of thing. The adjustable panel moves, and is adjustable, but the controls do not. Same for the text editor, map editor and compiler windows. I am not so worried, as I’m used to it on the right-hand side, but I suppose a fix is the right thing to do! Bruce From: Therion On Behalf Of Stacho Mudrak Sent: Wednesday, 23 February 2022 07:59 To: List for Therion users Subject: Re: [Therion] Updated XTherion editor side panel adjustment missing Hi Bruce, I have tried a more standard solution (commit <https://github.com/therion/therion/commit/683b226065e092e3b9d38aa292141b5065b07a2d> 683b226) - an adjustment line alongside the whole screen. It should be 1.5mm thick (according to OS-supplied resolution). Does that solve the problem? S. ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Updated XTherion editor side panel adjustment missing
The new look (v 6.0.5) XTherion editor seems to be missing the small button control that allows resizing of the side panel. I often like to make it quite large when editing objects with a long options string. Is resizing of the panel still available and I'm just not seeing it, or is it perhaps a bug? Therion 6.0.5 Windows 10 Home v 21H1 9043.1526 ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] new Therion 6.0.5
“Could someone maybe explain what the difference is between 3D and LRUD envelope? I get how 3D probably works based on the rendered 3D view of the cave. But how can the LRUD thing work when I only use splays instead of LRUD? Does it just pick some particular or average splay and use it as a LRUD measurement? The results are so vastly different.” My inference is that if you enter LRUD for a piece of passage, that is used to calculate volume, and if you have splays, those are used. Hence the result just follows the type of data entered. My datasets usually result in one or the other being zero, because they only have either splays or LRUD. Some datasets have only a few LRUD and many kilometres of splays. These naturally (and presumably appropriately) report volumes with orders of magnitude difference. Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Delete documents in Therion wiki Media Manager
Just been doing a little maintenance, and this document is no longer required on the Therion wiki, and is no longer referenced by any wiki pages as far as I can tell. I couldn't figure out how to remove or delete it. If someone has additional privileges, or knows how, feel free to delete it. Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Hide symbols within certain maps/subsurveys
Tarquin This sort of thing can be done, perhaps not completely, with surface and cave centreline component visibility. There is an old conversation about it somewhere, but I cannot find it just now. Something like: symbol-hide group cave-centreline #1. hides all centrelines, incl station-names - clears the canvas symbol-show point cave-station #2. set up for identifying cave-stations to show/hide symbol-show point station:fixed #3. actually show/hide (cave-)stations of mark ... symbol-show point station:painted #3. symbol-show point station:natural #3. symbol-hide point station:temporary #3. #then could carry on to specify surface... symbol-hide group surface-centreline # etc. The lines annotated 1 to 3 work just fine, but I'm not sure I've managed to get that refined control over both surface and cave centrelines at the same time. This is not really what you were asking, but maybe there is a clue. Otherwise perhaps it can be done using custom attributes for the objects? It was suggested to me once, but it seemed labour intensive so I never tried it. Bruce -Original Message- From: Therion On Behalf Of Tarquin Wilton-Jones via Therion Sent: Tuesday, 18 January 2022 21:58 To: Therion Cc: Tarquin Wilton-Jones Subject: [Therion] Hide symbols within certain maps/subsurveys Hi folks, I have a survey of a cave and its surrounding surface area, including all the little caves in the area. So you can basically get an overview of the area, see the surface streams and sinks. Normally, I want the cave survey to be on its own, showing the cave's features, passage names, fill areas, boulders, water flow, etc.. But when I show the area overview, all those features become unimportant, and most labels should be hidden (only the cave names are important). When showing an overview though, I still want to show the surface labels, slopes, cliffs, water flow, arrows, borders, etc. Does anyone have a nice way to hide almost all symbols within one map/subsurvey (the cave), while showing them all within other maps (the surface)? Does Therion have a dedicated way to do this that I missed? Cheers, Tarquin ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Handling of tape and backtape in survey data
I just checked on my little experiment of some years ago, and I misrepresented it. > PocketTopo automatically detects backsights if they are taken immediately after a foresight. So the software handles the station naming, no user intervention required. That much is true. You end up with something like: 1.4 splays 1.4 1.5 shot 1.4 1.5 shot 1.4 1.5 shot 1.5 1.4 shot # for back shots it will recognise 1 or more shots within tolerance as 'back legs', so you can do as many as you want, I think 1.5 1.4 shot 1.5 1.4 shot 1.5 splays 1.5 1.6 shot etc >While I processed the only survey I ever did this way with Therion... Not true. I did not bother parsing the data from PocketTopo, as the passage ends were too far apart to consider digging, and so no point to mapping with Therion (we already have an older map). Never the less, I am almost curious to see what TopParser and Therion does with it. Lots of loops and doubled survey length I expect. Maybe I will process it one day. Tarquin You mention that SexyTopo deals with this by treating the backsight as a splay. Does it detect and label this splay as a backleg if it is within tolerance for the previous leg? I think it should (similarly to PocketTopo). While I don't tend to use backsights as a rule, there is that 1 in 100 occasion where I do consider it, and I expect that the field software should automatically detect this and number the shot/leg accordingly. In a generic sense, rigorous foresight//backsight/splay is a valid survey protocol (along with variations of that). Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Handling of tape and backtape in survey data
> instead Toporobot just generates a new station for the backsite. PocketTopo automatically detects backsights if they are taken immediately after a foresight. So the software handles the station naming, no user intervention required. While I processed the only survey I ever did this way with Therion, it never made it into the main cave dataset and so I didn't get as far as checking the survey length was correct (or doubled). I'm pretty sure it would be correct though. It was only done to find a reasonably precise gap in an 'almost looped' passage. The gap was too big to dig so we lost interest and I haven't drawn the enhanced accuracy map yet. It is at the bottom of my priority list. The exercise was also helpful to gauge the frequency and size of foresight/backsight mismatch with 'three-shot' disto readings. My conclusion: a few instances that may be of interest occur, but not enough to ever bother actually taking all those backsights. Have never done a backsight since. Our disto driven loop closures are typically 0.5% (I like to think) but a bad one will be 1.0%. Compared to our pre-disto loops over a decade ago which were typically 2% and a good one 1%. Although I prefer to think in Survex's standard deviation approach to loop closure, which tells a different story about which loop is good and which not... Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Migovec Github survey data project
Thanks Rhys, good to meet you. Your answer explains the gap I detected. I recall small groups of cavers bent over a large table drawing on film with ink pens. Thirty years ago. We haven’t managed to duplicate the physicality and sociability since, but at least since we found version control just over a decade ago we can have a few people working on the same project, even if it is usually alone and one at a time. And we don’t have to unclog pens. Very interested in your custom point map-connection by the way. Bruce From: Therion On Behalf Of Rhys Tyers Sent: Tuesday, 21 December 2021 12:08 To: List for Therion users Subject: Re: [Therion] Migovec Github survey data project Hey, I work on this repository. Thank you for your kind words. We use github as a convenient means to collaborate amongst ourselves and host data but I guess we differ from an open source software project in that there's not much point in accepting outside contribution as only people who attend our expedition are generally interested in drawing our survey! We generally collaborate by running a meeting via voice chat and drawing survey as a social activity, emulating how we drew before Therion. Theoretically we could use pull requests and issues to work on our data but as we are normally talking to eachother as we draw it is just easier to push what each person does sequentially to master, relying on git to avoid messing anything up. Also most of our contributors are science students and while they have a familiarity with git they normally haven't really used it for collaboration in the same way someone working in software would. As for the broken thconfigs the answer is similar, that the current drawers know which ones work and it's a bit fluid so we haven't bothered documenting it. Half the reason it exists in it's current format is that I do work in software so I tend to maintain all the extraneous git cruft as my armchair caving while other people focus on the _actual_ work of drawing stuff 😁 If you do have any questions about it feel free to email me or Imperial caving. Rhys On Sun, 19 Dec 2021, 11:38 Benedikt Hallinger, mailto:b...@hallinger.org> > wrote: Hi, no specific info on the exact project, but generally you could open a issue ticket there and ask your very question. Each project may have its own rules. But most commonly it works this way: - you clone the repo at github (so its public) - you make a new branch and do your stuff - you then open a pull request against the upstream repo - someone there inspects it and if it is accepted, will merge - done Am 19.12.2021 um 00:43 schrieb Bruce Mutton mailto:br...@tomo.co.nz> >: Not directly a Therion question. I’ve been loosely following the progress of https://github.com/iccaving/migovec-survey-data a couple of years, but only recently started migrating some projects of my own to git. So thought I’d dispense with just admiring the outputs and fork the migovec repository to do a deep dive learn from the apparent masters… The README.md is exemplary, but the section on ‘How to contribute’ seems to be missing a most important thing – how do contributors interact with other contributors and the repository? The lack of issues and forks that similar sized GitHub projects have suggests I’m missing something obvious. I know Therion pretty well, passible on version control but only just cutting my teeth on git and GitHub. I found a simple problem in some thconfigs that causes Therion to crash and exit, and located the cause in the history. I could potentially fix it, make a pull request, but as I have only studied the migovec structure for literally 10 minutes, any ‘fix’ I work on will take me a while and be bound to be error prone. Better for me just to point out the problem. Anyone here know how the iccaving migovec Therion team communicates or would one of them on this list be able to PM me? Bruce ___ Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Migovec Github survey data project
Not directly a Therion question. I've been loosely following the progress of https://github.com/iccaving/migovec-survey-data a couple of years, but only recently started migrating some projects of my own to git. So thought I'd dispense with just admiring the outputs and fork the migovec repository to do a deep dive learn from the apparent masters. The REDME.md is exemplary, but the section on 'How to contribute' seems to be missing a most important thing - how do contributors interact with other contributors and the repository? The lack of issues and forks that similar sized GitHub projects have suggests I'm missing something obvious. I know Therion pretty well, passible on version control but only just cutting my teeth on git and GitHub. I found a simple problem in some thconfigs that causes Therion to crash and exit, and located the cause in the history. I could potentially fix it, make a pull request, but as I have only studied the migovec structure for literally 10 minutes, any 'fix' I work on will take me a while and be bound to be error prone. Better for me just to point out the problem. Anyone here know how the iccaving migovec Therion team communicates or would one of them on this list be able to PM me? Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] A little French in XTherion English language text editor
Answered my questions. Ticking the box makes the data table cycle through the from and to station boxes. Unticking the box makes the data table omit the from and to station boxes from the data entry cycle. Bruce From: Therion On Behalf Of Bruce Mutton Sent: Tuesday, 14 December 2021 19:41 To: 'List for Therion users' Subject: [Therion] A little French in XTherion English language text editor First time I have manually entered survey data into XTherion for years. A mysterious French prompt has appeared - I think it is a toggle forcing XTherion to ask for station names. Except that ticked or unticked there seems to be no difference in behaviour . Is there meant to be a tick box? What should it do? And perhaps an English translation in the next release? Cheers Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] A little French in XTherion English language text editor
First time I have manually entered survey data into XTherion for years. A mysterious French prompt has appeared - I think it is a toggle forcing XTherion to ask for station names. Except that ticked or unticked there seems to be no difference in behaviour . Is there meant to be a tick box? What should it do? And perhaps an English translation in the next release? Cheers Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Therion] Get shortest route
This was discussed in 2008 in Therion circles. https://www.mail-archive.com/therion@speleo.sk/msg02037.html To be really useful, the user should be able to specify multiple stations, with the algorithm finding the shortest centreline distance along the centreline network that passes through all of the specified points. Outputs to list as noted by Benedikt below, pdf and aven/Loch models. Bruce -Original Message- From: Therion On Behalf Of Olly Betts Sent: Sunday, 28 November 2021 07:57 To: Benedikt Hallinger Cc: therion@speleo.sk Subject: Re: [Therion] Get shortest route On Fri, Nov 26, 2021 at 05:10:18PM +0100, Benedikt Hallinger wrote: > i would want to get some advanced statistics regarding lengths in a very big cave (130km/Hirlatz). > > Basicly i want to supply two stations and get the following data for the shortest path: > - length of shots > - cumulated height for shots going upwards > - cumulative depth for shots going downwards > - optionally it would be cool to be able to somehow visualize the > route in aven/loch, or in a therion map output > > Is this possible already? I don't think so. Someone was working on it, but I guess it didn't come to anything as that was 2016: https://lists.survex.com/pipermail/survex/2016-October/002082.html Cheers, Olly ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Rock border not creating boulders with smooth altitude shading
I'm with you Tarquin. See my other message (some reason it has not turned up in https://www.mail-archive.com/therion@speleo.sk/) Seems like it is intentional, but it is more complicated than that. This page describes https://therion.speleo.sk/wiki/contrib:externalviewers#examples_of_rendering _differences_between_pdf_viewers I had always thought double rendered translucent objects where the intention, but seems they are not. I would vote for making it an option (not withstanding what you actually see will depend on the viewer used). Bruce -Original Message- From: Therion On Behalf Of Tarquin Wilton-Jones via Therion Sent: Monday, 15 November 2021 09:19 To: Therion Cc: Tarquin Wilton-Jones Subject: [Therion] Rock border not creating boulders with smooth altitude shading Hi folks, I feel like I must have missed some email about this; surely someone will have noticed before... Boulders. They are made from line rock-border, which will create a shaded boulder when closed. Make an area of water. Create a line rock-border half-way into the water, and half out of the water, but still in the passage. The boulder is the same colour as the background. Translucent, sitting on top of the water. Set this: color map-fg scrap Still works the same. Now set this: color map-fg altitude The boulder loses its colour, and is nothing more than a thick line, so it stops looking like a boulder. Set this, and the boulder returns to being a boulder: smooth-shading off Is this an intentional change, a known limitation, or a bug? Cheers, Tarquin ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Is survey -namespace off and sometimes on possible in same survey project?
>>Em domingo, 14 de novembro de 2021 às 2:10 AM, Bruce Mutton >> escreveu: >> Just a quick question before contemplating the migration of a large (more >> than 70 km and many caves) dataset to Therion. >> >> The dataset has unique station names, so in Therion speak, every survey >> would have -namespace off set. >Sorry for the slightly off topic reply but AFAIU your dataset having station >unique names allows you to set -namespace off which could save some work but >you don't have to and as you already know that some other parts of your >dataset needs -namespace on, why bother with -namespace off? Because the existing dataset that it is proposed to migrate (using a custom script): - is large with many surveys and sub-surveys - Therion implicitly defaults to -namespace on for every single survey - with that setting, survey stations, although unique across surveys, cannot be seen unless a namespace is specified - therefore it will not compile until -namespace off is set in each relevant survey and sub-survey. A decade ago, before I was particularly aware of 'survey -namespace', I migrated this same dataset, and not being aware I could turn it off, had to manually equate stations to join all the surveys, and equate loops where they involved more than one survey. I only did half of it before I got fed up. I realise now that -namespace off is the solution, and that it can be put in the custom script. But in the meantime I have some native Therion sub-projects that I want to merge into the migrated project, that, of course, use and rely on the implicit default of -namespace on because the stations are not unique (each survey has the station sequence 1 2 3 4 ...). I do not have an appetite to manually make these stations unique, even using -station-names to modify them it will be too painful. Hence I am testing the idea of projects where some surveys have -namespace on and some -namespace off. I could modify one of my existing projects to see what happens, but before doing that I am interested to find out if others have experience with this scenario. Regards Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Is survey -namespace off and sometimes on possible in same survey project?
Just a quick question before contemplating the migration of a large (more than 70 km and many caves) dataset to Therion. The dataset has unique station names, so in Therion speak, every survey would have -namespace off set. I have never used this setting, but do not anticipate any problem so long as every survey has -namespace off set. The trick is that there are two caves that have been processed from the very start with Therion (using the default -namespace on, of course) and one of the large caves has a currently 'not-incorporated' section of Therion namespaced data. None of this Therion data is currently incorporated in the large dataset. There will probably be more namespaced data in future. So my question is: Can we have an integrated Therion project where some surveys have -namespace on and some with -namespace off? I imagine this will work, but having never tried it I am cautious about diving into such a large undertaking, in case it is doomed to failure because of a requirement for significant manual intervention (I did that for 30 km of the system, but I have lost enthusiasm for that). Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Minimum symbol scale
> Andrew (or perhaps this is Bruce's originally) has a partial solution in MetaPost: if abs(llcorner txt - ulcorner txt ) > 3pt: I borrowed from Thomas Holder https://therion.speleo.sk/wiki/metapost#scale_dependant_visualization_of_sym bols Good luck with your quest Tarquin. Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Therion Github plan
Oops, a free or paid plan? From: Therion On Behalf Of Bruce Mutton Sent: Thursday, 14 October 2021 08:02 To: 'List for Therion users' Subject: [Therion] Therion Github plan Just curious Is the Therion repository on Github <https://github.com/pricing> supported by a free or a pain plan? Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Therion Github plan
Just curious Is the Therion repository on Github <https://github.com/pricing> supported by a free or a pain plan? Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Selecting map defined with preview only causes error
Thanks Stacho That is a good solution. It is appropriate that previews are ignored when calculating map extents. My experimental use case was to have a generic preview only map that I could then select in tandem with (non-previewed) maps, with the extents determined by the (non-previewed) maps. It was an idea to allow further ‘modularisation’ and standardisation of my datasets. It is easy to arrange map definitions to give the same effect, just have to make sure there is a non-previewed map in each. And as you suggest, a ‘preview’ that contributes to map extent definition can be emulated with map-fg and hiding all symbols. Impressed by the time and effort you are putting in. Much appreciated. Bruce From: Therion On Behalf Of Stacho Mudrak Sent: Tuesday, 5 October 2021 10:16 To: List for Therion users Subject: Re: [Therion] Selecting map defined with preview only causes error Hi Bruce, thanks for pointing it out. I have tried to allow map containing only previews, but there were apparently a lot of subsequent issues with its zero dimensions. Normally, previews are ignored when calculating the extent of a map. So I have modified the error message according to your suggestion. I assume the same map can be generated using a single map-fg color and hiding all symbols. Or am I missing something? S. On Mon, 4 Oct 2021 at 06:54, Bruce Mutton mailto:br...@tomo.co.nz> > wrote: Hello Team I think this may be a bug. Selecting a map with only previews inside of it is causing an error, where possibly it should not. And if it is by design that it triggers an error, then the message it gives is not helpful. A better message would be “map cannot contain only previews” The error message. therion.exe: error -- GreenlinkArea/INDEXGLMESM_System.th [164] -- incompatible map projection -- SwissM_PlanMap@GLMESM_system The map definition. map GLMESMPreviewOnlyMap -projection plan preview below SwissM_PlanMap@GLMESM_system #map preview below DwarfsDoorPlanMap@GLMESM_system #map preview below MiddleEarthPlanMap@GLMESM_system #map endmap GLMESMPreviewOnlyMap The maps all have -projection plan explicitly defined, and the error is unchanged if I remove the projection option from the definition above. The thconfig. select QEII-01GreenLinkPlanCL select QEII-01GreenLinkPlan select GLMESMPreviewOnlyMap I have selected three maps, two contain valid maps, and one contains only previews. If I remove one of the ‘preview below’ statements preceding any of the previewed maps, the project compiles as expected. If I try to type the preview below directly into the thconfig, there is an error also, but I suspect this might be by design. Using 6.0.3, but am not assuming this was introduced recently. I have never tried it before. Regards Bruce ___ Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Selecting map defined with preview only causes error
Hello Team I think this may be a bug. Selecting a map with only previews inside of it is causing an error, where possibly it should not. And if it is by design that it triggers an error, then the message it gives is not helpful. A better message would be "map cannot contain only previews" The error message. therion.exe: error -- GreenlinkArea/INDEXGLMESM_System.th [164] -- incompatible map projection -- SwissM_PlanMap@GLMESM_system The map definition. map GLMESMPreviewOnlyMap -projection plan preview below SwissM_PlanMap@GLMESM_system #map preview below DwarfsDoorPlanMap@GLMESM_system #map preview below MiddleEarthPlanMap@GLMESM_system #map endmap GLMESMPreviewOnlyMap The maps all have -projection plan explicitly defined, and the error is unchanged if I remove the projection option from the definition above. The thconfig. select QEII-01GreenLinkPlanCL select QEII-01GreenLinkPlan select GLMESMPreviewOnlyMap I have selected three maps, two contain valid maps, and one contains only previews. If I remove one of the 'preview below' statements preceding any of the previewed maps, the project compiles as expected. If I try to type the preview below directly into the thconfig, there is an error also, but I suspect this might be by design. Using 6.0.3, but am not assuming this was introduced recently. I have never tried it before. Regards Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Existing xvi background images not visible in XTherion Map Editor, insertion causes error
> thanks a lot for finding out and reporting. Introducing “Rob Davies”. After a quick spin through, it looks like 23b301e is working. Thanks for the speedy turnaround Stacho. Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Elevation scrap distortion with survex 3.d import
> One last question. If I wanted to try a projected elevation (to remove the extra complexity of the extending process) how do I specify the projection angle? > An angle seems to be a parameter in a scrap '-proj elevation' definition, but what determines what angle the _centreline_ is viewed from? > I cannot specify an angle in the top level 'export map' command: > export map -proj elevation -layout local -o "elv.pdf" Wookey All the projected elevation objects (scraps, maps and exports) need to have the projection angle specified. Specifying nothing will result in a projection looking at bearing zero (north). ie export map -proj [elevation 042 deg] -layout local -o "elv.pdf" or export map -proj [elevation 042] -layout local -o "elv.pdf". Therion defaults to degrees I think. In XTherion it is like this. Therefore if using degrees, you have the option of drawing up to 360 unique projected elevations. Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] cannot load thconfig in xtherion
If there is a vote going on extensions, I'd go for .thc rather than .thconfig, but I guess it is not so important. Bruce -Original Message- From: Therion On Behalf Of Tarquin Wilton-Jones via Therion Sent: Monday, 23 August 2021 20:37 To: therion@speleo.sk Cc: Tarquin Wilton-Jones Subject: Re: [Therion] cannot load thconfig in xtherion On 23/08/2021 09:29, Martin Sluka via Therion wrote: > BTW, using for project “foo" name “foo.thconfig" is not a bad idea. Indeed. It makes your code more portable, since Windows doesn't show a "what do you want me to do with this 'thconfig.[nothing]' file that has no mimetype data?" dialog. Grr. ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Therion 6.0.1 colour processing problem
Anton It seems my current version of that file/layout doesn’t use transparent colours – I haven’t updated that wiki post for some years. I vaguely recall some discussion about transparent colours when differing colour models were introduced, but such things are above my knowledge level. A clue on top of page 57 of the Therion book. smooth-shading . set the mode of smooth scrap backgroud shading. By default, altidute and depth colour is interpolated across the scrap the quick way. Some issues are present if transparent symbol colours are used. More precise modes should be added in the future. If off, scrap is filled with single colour. On the other hand, your code is missing a ; What happens if you add one like this? def_transparent_rgb (tr_color_sump_bg, .44, .81, .92); %transparent version Or you could just delete the entire line, assuming you have not used tr_color_sump anywhere. Hope that helps. Bruce From: Therion On Behalf Of A.M. van Rosmalen Sent: Saturday, 21 August 2021 19:53 To: List for Therion users Subject: [Therion] Therion 6.0.1 colour processing problem Hi there, Since I upgraded to the last version of Therion (6.01) on Windows my maps refuse to compile even though they used to compile just fine before and still compile under the previous version (on a Linux machine) Specifically this piece of code in LayoutStandards.thc drafted by Bruce Mutton found here: https://therion.speleo.sk/wiki/_media/templates:layoutstandards.txt code metapost %these colours affect fills, not the linework !color colour_water_bg; %! forces interpretation as metapost colour_water_bg := (0.82,.93,.95); %light blue !color colour_sump_bg; %! forces interpretation as metapost def_transparent_rgb (tr_color_sump_bg, .44, .81, .92) %transparent version colour_sump_bg := (.44,.81,.92);%dark blue %these colours affect the linework !color colour_rope; %! forces interpretation as metapost colour_rope := (0.35,0.75,1.0);%blue endcode Gives the following error message: >> def_transparent_rgb ! Isolated expression. ( l.6979 def_transparent_rgb ( tr_color_sump_bg, .44, .81, .92) %transparent ve... I couldn't find an `=' or `:=' after the expression that is shown above this error message, so I guess I'll just ignore it and carry on. ! Extra tokens will be flushed. ( l.6979 def_transparent_rgb ( tr_color_sump_bg, .44, .81, .92) %transparent ve... I've just read as much of that statement as I could fathom, so a semicolon should have been next. It's very puzzling... but I'll try to get myself back together, by ignoring everything up to the next `;'. Please insert a semicolon now in front of anything that you don't want me to delete. (See Chapter 27 of The METAFONTbook for an example.) I tried adding some := and =, but this just leads to the following error message: >> def_transparent_rgb >> (tr_color_sump_bg,0.44,0.81,0.92) ! Equation cannot be performed (numeric=cmykcolor). colour_sump_bg l.6980 colour_sump_bg := (.44,.81,.92);%dark blue I'm sorry, but I don't know how to make such things equal. (See the two expressions just above the error message.) ! Extra tokens will be flushed. colour_sump_bg l.6980 colour_sump_bg := (.44,.81,.92);%dark blue I've just read as much of that statement as I could fathom, so a semicolon should have been next. It's very puzzling... but I'll try to get myself back together, by ignoring everything up to the next `;'. Please insert a semicolon now in front of anything that you don't want me to delete. (See Chapter 27 of The METAFONTbook for an example.) Any ideas how to fix this? Cheers, Anton ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Plan gridline colour changes unpredictably
Thanks Martin Highlights the dangers of absorbing a language by osmosis. A false sense of understanding! I’ll try that out and see how it works. Out of interest I went back over old maps to check the colour of my gridlines. Until a few weeks ago I only ever used the default rgb colour model, and even now I only specify rgb, but occasionally force Therion to convert by specifying a cmyk colour model. I found that I actually got a random section of the two gridline output colours over previous years. My excuse for not picking it as a Therion behaviour is that I routinely use a number of pdf viewers and printers. They all present line thicknesses and colours slightly differently. Especially Sumatra pdf compared to most others. Bruce From: Therion On Behalf Of Martin Budaj Sent: Wednesday, 11 August 2021 07:23 To: List for Therion users Subject: Re: [Therion] Plan gridline colour changes unpredictably Hi, 0.5white doesn't work in CMYK properly (it's equivalent to 0.5*(0,0,0,0) = (0,0,0,0) = white) 0.1black doesn't work in RGB (it's 0.1*(0,0,0) = (0,0,0) = black) So your formula produces 50% gray in RGB and 10% gray in CMYK. No idea why you got 10% gray in some RGB setups, some test data would be needed. To get 10% grey colour you need to use 0.1[white,black] which works in all RGB, CMYK and Grayscale. Cheers Martin On Tue, Aug 10, 2021 at 11:29 AM Bruce Mutton mailto:br...@tomo.co.nz> > wrote: Curious I have in my layout some metapost code to redefine the plan gridlines, used without apparent problem for perhaps 10 years. It includes a colour specification… withcolor 0.1black+0.5white; Mostly they come out like this, very light grey. This example is exported using colour-model cmyk, but most of the time using colour-model rgb it looks exactly the same, in my current project (only variables are colour map-fg, some map previews on or off and the colour model). For some reason, in my current project, if I use colour-model rgb for a particular output variant, I get a much darker gridline, as below. Other variants with rgb, the colour of the gridline matches the first example. Any hints as to why the difference? I might have expected this to occur with the new cmyk colour model, but it does not. So far it has only happened with in a single specific case when using the rgb colour model. I’ll watch for more cases… Bruce ___ Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Plan gridline colour changes unpredictably
Curious I have in my layout some metapost code to redefine the plan gridlines, used without apparent problem for perhaps 10 years. It includes a colour specification. withcolor 0.1black+0.5white; Mostly they come out like this, very light grey. This example is exported using colour-model cmyk, but most of the time using colour-model rgb it looks exactly the same, in my current project (only variables are colour map-fg, some map previews on or off and the colour model). For some reason, in my current project, if I use colour-model rgb for a particular output variant, I get a much darker gridline, as below. Other variants with rgb, the colour of the gridline matches the first example. Any hints as to why the difference? I might have expected this to occur with the new cmyk colour model, but it does not. So far it has only happened with in a single specific case when using the rgb colour model. I'll watch for more cases. Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Graphic tablet with XTherion
After many many years XTherioning with a mouse, I think I might try a graphic tablet for drawing with XTherion, and maybe soon, Inkscape. Do I need anything fancy, or will the simplest do? One of these? https://www.huion.com/pen_tablet/Inspiroy/H430P.html Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] using revise to set a map colour, and
Hello I'm trying to force the colour of a particular submap, either from a thconfig or from within a layout. The thconfig route gives an error - unknown configuration command The layout route gives an error - unknown option Tried using these two syntax, and variously swapping '-colour' and 'colour' to no avail. revise 97-HectorsWetPlan@MiddleEarth colour [5] endrevise revise 97-HectorsWetPlan@MiddleEarth -colour [5] I see here <https://therion.speleo.sk/wiki/develop?s%5b%5d=revise> that a revise bug was fixed in 5.4.1 that prevented it working outside of a survey context, but maybe something has reverted? More likely I am missing something? I can do this. select 97-HectorsWetPlan@MiddleEarth -colour [100 0 0] #red .and it works in part - the map is exported, but it is not coloured red. Instead it is coloured according to a banded altitude lookup that I have activated. My understanding is that colouring a map explicitly should override 'colour map-fg' specifications, including lookups. I tried changing the order of selects to see if that would place one map over top of the other, but no change. I have previously coloured specific maps successfully (possibly without lookups), although I have not gone back to see exactly how I set those up. So is there a problem with some lookup colour palettes overriding explicit map colour specification? BTW, there is a diagram somewhere that shows the contexts/object model hierarchy of a therion dataset. Can someone point it out to me? (Perhaps it should be in the Therion Book). Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Therion 6.0.0 altitude colour legend feedback
>On Mon, Jul 19, 2021 at 12:08 PM Bruce Mutton <mailto:br...@tomo.co.nz> > wrote: The new colourbar misses out the top colour (red), and generally biases the colours on the colourbar too far up relative to the labelled altitudes (a bug). >Hi, this should be fixed in the latest commit in the master branch. The issue >was present when exporting multiple maps in one thconfig file. Thanks to Bruce >for sending me the problematic data set. >Martin Looking good. I haven’t broken it yet :) Thanks for your hard work Martin. Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] GitHub Windows installer
>You need to get the windows installer from GitHub now, as we no longer build >windows binaries on our server. The new links are in the Downloads section of >the Therion web page >For example start here: >https://github.com/therion/therion/actions/workflows/installer.yaml?query=branch%3Amaster >This page lists all automated jobs run by GitHub Actions for commits in the >master branch. Click on a commit you are interested in (the links are next to >the green check marks). >Then look for a section "Artifacts" at the bottom of the page, containing a >link to a zip package therion-setup-*. The zip archive contains therion >installer (exe) and the thbook in PDF format (the link is clickable only if >you are logged in). >Martin Thanks Martin. That was what I needed :) ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] GitHub Windows installer
> You need to get the windows installer from GitHub now, as we no longer build > windows binaries on our server. The new links are in the Downloads section of > the therion web page. Umm… I’m logged in and on the installer page. Nothing on the help page jumps out at me about building or compiling the code. I’m going to need some pointers please. Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Some metapost symbols defined so they cannot be scaled
> In my actual use case I have a plan and elevation at differing layout
scales exported to the same pdf. I want these symbols to output the same
(unscaled) size and for some reason the size differs by the ratio of the
layout scales (I had thought that layout scales were meant to ensure text
and symbol size were constant irrespective of layout scale, but the text and
symbol sizes in fact differ unless I compensate by symbol scaling).
> I cannot help thinking I am making some illogical brain-fade error in
thinking.
I was forgetting about fonts-setup and the differing default font sizes
Therion has for different scales.
I typically use a layout that sets scales 1:500 and 1:1000 to use the same
(bigger) font values than the Therion defaults. In this particular case I
did not use that custom layout and so the difference surprized me.
Therion's default initialise definition copied below also has differing
values for u:, v: and w: at different scales. This then affects line
thicknesses and symbol sizing, which looks a bit odd when they are side by
side on the same page. So while I am comfortable messing with Therion's
font sizes in my custom layout, I may just leave the symbols alone on the
basis that I may dig a bigger hole for myself.
Bruce
def initialize (expr sc) =
if unknown BaseScale: BaseScale = sc; fi;
optical_zoom := BaseScale/sc;
if BaseScale <= 1: % 1:100
u:=14bp; v:=14bp; w:=12bp;
fonts_setup(8,10,12,16,24);
elseif BaseScale <= 2: % 1:200
u:=12bp; v:=12bp; w:=12bp;
fonts_setup(7,8,10,14,20);
elseif BaseScale <= 5: % 1:500
u:=10bp; v:=10bp; w:=12bp;
fonts_setup(6,7,8,10,14);
else:
u:=7bp; v:=14bp; w:=10bp;
fonts_setup(5,6,7,8,10);
fi;
u := optical_zoom * u;
v := optical_zoom * v;
w := optical_zoom * w;
defaultscale := 0.8 * optical_zoom;
def PenA = pencircle scaled (u/10) enddef;
def PenB = pencircle scaled (0.7*u/10) enddef;
def PenC = pencircle scaled (0.5*u/10) enddef;
def PenD = pencircle scaled (0.35*u/10) enddef;
def PenX = pencircle scaled (1.2*u/10) enddef;
legend_scale := 3.14*u;
enddef;
From: Therion mailto:therion-boun...@speleo.sk>
> On Behalf Of Bruce Mutton
Sent: Monday, 28 June 2021 10:54
To: 'List for Therion users' mailto:therion@speleo.sk> >
Subject: [Therion] Some metapost symbols defined so they cannot be scaled
I've just noticed that some metapost symbols are coded so that they ignore
scaling options xs, s, l, xl.
For example point dig is positioned but not rotated or scaled.
def p_dig_UIS (expr pos,r,s,al) =
U:=(.4u, .5u);
T:=identity aligned al shifted pos;
thfill ((-.075u,-.5u){down} .. {up}(0.075u, -.5u) -- (0.075u, .15u) --
(0.3u, 0.15u) -- (0.3u, 0.5u) --
(-.3u, .5u) -- (-.3u, .15u) -- (-.075u, .15u) -- cycle) rotated 45;
enddef;
Point camp is similar.
I can understand why it is not ideal to allow these to be rotated, and
usually they should be inserted unscaled. However it is possible to have
big, small, major, minor camps and digs that one might want to symbolise
with size.
In my actual use case I have a plan and elevation at differing layout scales
exported to the same pdf. I want these symbols to output the same
(unscaled) size and for some reason the size differs by the ratio of the
layout scales (I had thought that layout scales were meant to ensure text
and symbol size were constant irrespective of layout scale, but the text and
symbol sizes in fact differ unless I compensate by symbol scaling).
I cannot help thinking I am making some illogical brain-fade error in
thinking.
A similar symbol, danger, is coded to enable scaling. It works, in that I
can make them bigger or smaller with for example -scale l, so the solution
appears obvious.
picture SBE_danger_raw;
SBE_danger_raw := image(
fill (331,489)..controls (330,489) and (328,489)..(326,488)
--(291,422)..controls (291,422) and
(291,421)..(291,421)
..controls (291,417) and (294,414)..(297,413)
--(365,413)..controls (369,414) and
(371,417)..(371,421)
..controls (371,422) and (371,422)..(371,423)
--(336,488)..controls (335,489) and
(333,489)..(331,489)
..controls (331,489) and (331,489)..(331,489)
--cycle withcolor red;
fill (336,427)..controls (336,430) and (334,432)..(331,432)
..controls (328,432) and (326,430)..(326,427)
..controls (326,424) and (328,422)..(331,422)
..controls (334,422) and (336,424)..(336,427)
-
[Therion] Minimum symbol scale
Yes, I wouldn't mind some more refinement. Here are my comments from a while back (some of which may have been resolved since). [Therion] min-symbol-scale and fonts-setup https://www.mail-archive.com/therion@speleo.sk/msg06651.html [Therion] scaling line ornamentation - metapost https://www.mail-archive.com/therion@speleo.sk/msg07032.html [Therion] next level therion symbol strategy https://www.mail-archive.com/therion@speleo.sk/msg07860.html Not much help, but hopefully adding something meaningful to the conversation. Bruce -Original Message- From: Therion On Behalf Of Tarquin Wilton-Jones via Therion Sent: Tuesday, 29 June 2021 01:40 To: Therion Subject: [Therion] Minimum symbol scale Hi folks, There is a setting: min-symbol-scale M That allows you to hide all symbols of S or XS scale. That's useful when you want to show only the most important symbols in a low resolution survey. But is there a way to control this differently only for certain symbols? Eg. I want to be able to hide all "point label" symbols of scale M-XS but I don't want all my cave walls or breakdown choke symbols to disappear (which are at the default M scale). Essentially I want something like this: min-symbol-scale point label L min-symbol-scale point anchor:foo M Some of this I can of course do with MetaPost. But labels (the thing I care most about) don't allow you to easily redefine the MetaPost macro ... or at least the syntax is so weird that I don't understand it. Thanks for any advice. Tarquin ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Some metapost symbols defined so they cannot be scaled
I've just noticed that some metapost symbols are coded so that they ignore
scaling options xs, s, l, xl.
For example point dig is positioned but not rotated or scaled.
def p_dig_UIS (expr pos,r,s,al) =
U:=(.4u, .5u);
T:=identity aligned al shifted pos;
thfill ((-.075u,-.5u){down} .. {up}(0.075u, -.5u) -- (0.075u, .15u) --
(0.3u, 0.15u) -- (0.3u, 0.5u) --
(-.3u, .5u) -- (-.3u, .15u) -- (-.075u, .15u) -- cycle) rotated 45;
enddef;
Point camp is similar.
I can understand why it is not ideal to allow these to be rotated, and
usually they should be inserted unscaled. However it is possible to have
big, small, major, minor camps and digs that one might want to symbolise
with size.
In my actual use case I have a plan and elevation at differing layout scales
exported to the same pdf. I want these symbols to output the same
(unscaled) size and for some reason the size differs by the ratio of the
layout scales (I had thought that layout scales were meant to ensure text
and symbol size were constant irrespective of layout scale, but the text and
symbol sizes in fact differ unless I compensate by symbol scaling).
I cannot help thinking I am making some illogical brain-fade error in
thinking.
A similar symbol, danger, is coded to enable scaling. It works, in that I
can make them bigger or smaller with for example -scale l, so the solution
appears obvious.
picture SBE_danger_raw;
SBE_danger_raw := image(
fill (331,489)..controls (330,489) and (328,489)..(326,488)
--(291,422)..controls (291,422) and
(291,421)..(291,421)
..controls (291,417) and (294,414)..(297,413)
--(365,413)..controls (369,414) and
(371,417)..(371,421)
..controls (371,422) and (371,422)..(371,423)
--(336,488)..controls (335,489) and
(333,489)..(331,489)
..controls (331,489) and (331,489)..(331,489)
--cycle withcolor red;
fill (336,427)..controls (336,430) and (334,432)..(331,432)
..controls (328,432) and (326,430)..(326,427)
..controls (326,424) and (328,422)..(331,422)
..controls (334,422) and (336,424)..(336,427)
--cycle withcolor white;
fill (335,464)..controls (336,466) and (332,466)..(331,466)
..controls (330,466) and (327,466)..(327,464)
--(330,436)..controls (330,435) and
(330,435)..(331,435)
..controls (332,435) and (332,435)..(332,436)
--cycle withcolor white;
currentpicture := currentpicture shifted (-(llcorner
currentpicture)-(urcorner currentpicture - llcorner currentpicture)/2)
scaled (u / max((xpart urcorner currentpicture) - (xpart llcorner
currentpicture), (ypart urcorner currentpicture) - (ypart llcorner
currentpicture)));
);
def p_danger_SBE(expr pos, theta, sc, al) =
T := identity rotated theta aligned al scaled sc shifted pos;
thdraw SBE_danger_raw;
enddef;
What do people think of changing the point symbol metapost definitions so
that they can all be scaled?
Bruce
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion
Re: [Therion] xtherion - Multiple background sketches
>> Handling of transparency is probably a feature of the image >> library rather than xTherion. >I don't think the standard JPEG format supports transparency. Correct, jpg does not support transparency, so you must use png to have any hope of achieving a transparent background to an image. Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] xtherion - Multiple background sketches
> 2) Is there a way to make images transparent? Have half a memory that I made the background transparent in a png 'background image' (using an external editor), and XTherion honoured the transparency. Or am I making that up? Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Two extended profiles for same survey
>Can you do this in a thconfig: >source "cave.th" >source "extend1.th" >where cave.th contains the cave survey data, and extend1.th contains the >"extend" commands? >I would imagine that to do it, you would need to re-enter the original survey, >which is not permitted. Multiple source files are fine. I have a project (more than one?) where I do this routinely. It is a nice way to toggle the scope of a compile up or down without having to dig into maps. I have not used it specifically for extended elevations, but there is no reason I can think of that would preclude this use. It might even be a great way of doing it. There is no reason you would need to re-enter survey data for this to work, and as you imply it would be extremely bad form to do so. Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Two extended profiles for same survey
Hi Roger As Tarquin mentioned, it is quite easy, although it may take some work to convert an existing project. I only export one extended profile shape per compiler run, but it might be possible to export multiple profiles per compile - conceptually it should work, maybe there is some detail that complicates things. Full description on the wiki https://therion.speleo.sk/wiki/extend The second option that Tarquin describes is set out towards the bottom of that page. I have one master configuration file that I manually tweak depending on the output and extended profile I want. An alternative would be to have a thconfig for each extended profile (but I think that is harder to manage over the longer term-too much duplication). Bruce -Original Message- From: Therion On Behalf Of Roger Schuster Sent: Thursday, 17 June 2021 05:06 To: therion@speleo.sk Subject: [Therion] Two extended profiles for same survey Hello cavers, assume there are survey shots like this 0-1 1-2 1-3 1-4 (the numbers are the station names) forming a cross-shaped survey. I want to draw two extended profiles along the legs 0-1-2 (hiding stations 3 and 4) and 3-1-4 (hiding stations 0 and 2). This means the station names required for the "extend hide" directives are mutually exclusive. Is it possible to work around this problem? Thanks in advance! Regards, Roger ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Main route through a cave
> I would have thought the easier way would be a "flags" switch that could do > it for you. "flags mainroute". It wouldn't even be an estimate. Maybe some of > the Survex folks on this list could shed some light on how feasible that > would be. Might require a Survex modification though. ___ How about as a concept? route where you can define one or more named routes in the survey network by setting a name then a list of two or more stations that Therion then consecutively finds the cumulative shortest surveyed route between. Maybe it could tack on to the loop detection routine. Therion could then export these as a table in cave-list or survey-list, or it could be its own 'route-list'. Statistics could include total length, altitude gain and loss, altitude range, altitude difference. A debug option could enumerate every survey station along the route Therion has chosen. For visualising would need to highlight the route Therion has chosen in Aven or in Loch. Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Main route through a cave
> I am surveying a cave that could be best described as an insanity of hidden > routes. > When you go through the cave, it feels easy. You follow the obvious route... > This means that the survey is harder to navigate than the cave itself. Welcome to my world. Have not solved the problem yet but it is one I will need to come back to when we finish surveying. Where there are multiple levels it is relatively easy just by having a map per level and offsetting them. Maybe preview above/below the secondary passages to maintain context. Where there is frequent interconnection of say 5 levels, as we have in a few places, it becomes a nightmare. Especially when there are no blank places to offset the passages to. Andrew's suggestion of a 'main route map' is what we have considered, but have not figured out how to do this without either duplicating map structures or rebuilding our entire map structure. Neither sounds like fun. Axel's suggestion of a special line type for plotting the track you take through the cave is a partial solution, where the offsetting is not too complex. I have a least one example where I think our map will still be unintelligible. That perhaps points to my choice of map subdivision being suboptimal I suppose. Bruce ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] sort drawings authors
Yes Phil This functionality was added earlier this year (or was it last year?) Here is a standard layout that I use. The comments should give you a clue as to functionality. layout LayoutStatisticsNormal #--- List all participant statistics in order of contribution but without detail statistics explo all # all/off/number # names of explorers, or 'number' most significant explorers statistics explo-length hide # on/hide/off# on=sort by length and show, hide=and hide, off=alpha-sort statistics topo all# all/off/number # names of survey team members statistics topo-length hide # on/hide/off # on=sort by length and show, hide=and hide, off=alpha-sort statistics carto all # all/off/number # names of scrap authors statistics carto-count hide# on/hide/off# on=sort by count and show, hide=and hide, off=alpha-sort statistics copyright all# all/off/number # names of scrap copyrights statistics copyright-count hide # on/hide/off# on=sort by count and show, hide=and hide, off=alpha-sort endlayout LayoutStatisticsNormal There is information in the Therion Book pages 55 and 56. You may need to update to a more recent version if it is not in your Therion Book. Bruce -Original Message- From: Therion On Behalf Of Philippe Vernant Sent: Sunday, 30 May 2021 09:25 To: List for Therion users Subject: [Therion] sort drawings authors Hello, Is there a way to have the authors of the scraps sorted by the number / length of drawings instead of alphabetical order? I’ve been looking in the thbook but could not find anything on that question. Thanks, Phil ___ Therion mailing list <mailto:Therion@speleo.sk> Therion@speleo.sk <https://mailman.speleo.sk/listinfo/therion> https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] XTherion background image control and bitmap file size question
> Have you tried export of background sketches from therion as .xvi?
> Martin
You mean like this? https://therion.speleo.sk/wiki/outputs#map_th2_therion
Although I put together that wiki page, I had forgotten this possibility, don’t
think I have ever done it with sketches turned on. I think this is what you
were referring to Alistair?
So XTherion can scale, rotate and morph images. It is just an indirect process.
Hopefully I will remember it for next time it comes up.
Thanks
Bruce
12. 5. 2021 v 22:36, Bruce Mutton mailto:br...@tomo.co.nz> >:
Thanks for your replies Paul, Alastair and Axel,
I was hoping to draw out discussion on basic image manipulation functions in
XTherion and maybe to inspire someone to work on developing those. Maybe I
have been successful but it is far too soon to tell.
Paul, yes, scale and rotation control both for XTherion background images and
exported map-images would be great.
Alistair, Paul, my reason for wanting similar sized (scales) images in my th2
file was not so much to join them for the purposes of contiguous scrap drawing,
but to avoid the need to zoom in or out when moving from one scrap to another.
It also allows copying (with a text editor) drawing objects, then using
Xtherion to move one of them from one scrap to another – useful for coincident
lines on adjacent scrap boundaries and other things. Most of the time I avoid
joining up background images, as for me Therion’s superpower is allowing the
user to work on small easily manageable bits of information, then joining them
up at compilation time.
Axel. Yes, the Inkscape Plugin. I was excited about this when Thomas first
posted it. I managed to parse a th2 file to InkScape, but then I was so lost
that I got no further. Could not parse the th2 file back out to Therion, so I
gave up at that point. I recognise the potential, but I am lacking knowledge
and experience in the basics of image manipulation software. Maybe one day I
will learn how to use Inkscape, Illustrator, GIMP, CoralDraw etc…
I managed to enlarge my png image 3.5 x while reducing it from 600 kB to 500 kB
using more or less default export settings in GIMP), so my miserly tendencies
are satiated for now.
I am working on my next question now…
Bruce
From: Therion mailto:therion-boun...@speleo.sk> >
On Behalf Of Bruce Mutton
Sent: Friday, 7 May 2021 08:14
To: 'List for Therion users' mailto:therion@speleo.sk> >
Subject: [Therion] XTherion background image control and bitmap file size
question
Mōrena
I am wondering if XTherion can scale background images, or if anyone has hints
on scanned image settings that generate a larger background image, that is
economical on bytes?
Back story:
I created a multi-level survey (shaft system in cave) with PocketTopo, rather
than creating many small survey files to keep each level separate.
At home I printed the PocketTopo bitmap, then sketched over three of the four
main levels that I now want to draw with Therion.
Then I created an xvi with TopParser (I chose my usual export settings, and of
course maybe I could have chosen better settings).
You can see the xvi and some drawing directly on that xvi in the image below.
You can also see the three 100 dpi png background images that I imported into
XTherion.
The three images are much smaller than the xvi and while it so happens the zoom
range is such in XTherion that I could easily draw my scraps over them, I would
like all four scrap background to be a similar size. It just makes life easier
into the future that way.
I am a novice when it comes to bitmap manipulation, but I managed to use GIMP
to scale up one of the images about 3.5 times. You can also see that in the
image below. It is about the same size as the xvi which is what I am after
My frustration is that the original png images are all about 600 kB and the
enlarged image is about 3000 kB. I am a miser and I would like to minimise
bloat in my project repository.
Can we scale the image in XTherion, using the original smaller file as the
permanent source?
Or are there tricks to enlarging the png image while maintaining a modest file
size?
I am aware that jpg will likely compress to fewer bytes, and will try that
unless it becomes too blurry.
It looks like XTherion th2 file header has some unused controls. I could not
find any documentation on this, so I have deduced the format as follows…
##XTHERION## xth_me_image_insert {x coord visibility[0=off, 1=on] gamma} {y
coord {}} filename and path {<
unknown empty variable >}
Maybe there is scope for scaling and rotation of images by XTherion in here? !!
Sample of th2 file header
##XTHERION## xth_me_image_insert {1386.441811022 1 1.0} {844.524488189
7.14} ptopo/7-Laghu_p.xvi 0 {}
##XTHERION## xth_me_image_insert {1893.842519685 1 1.0} {1306.5748031498001
7.
[Therion] pdftex error introduced after c43b32a (2021-03-08)
Hi Martin
Not sure if this is a problem related to recent code changes, but if it is
not, I am unsure what I did to create it, as I haven't changed anything at
my end as far as I know.
A subset of this project has been compiling fine, but when I try to compile
a larger section I get the error below with f02bd7a, and all the versions I
have saved, until c43b32a (2021-03-08) which is the last good one that will
compile it. It reports itself in logs incorrectly as therion 5.5.7+67fffb0
(2021-02-22).
I have not done any other investigation yet, but expect that you might be
able to track something down based on the above and the snip from my f02bd7a
log file as below.
Bruce
.
[3060] [3061] [3062] [3063] [3064] [3065] [3066] [3067] [3068] [3069] [3070]
[3071] [3072] [3073] [3074] [3075] [3076] [3077] [3078] [3079] [3080] [3081]
[3082] [3083] [3084] [3085] [3086] [3087] )
Here is how much of MetaPost's memory you used:
840264 strings using 21320784 characters
14137540 bytes of node memory
1900 symbolic tokens
11i,82n,36p,1657b,5f stack positions out of 16i,98n,45p,1853b,6f
3104 output files written: data.1 .. data.4017
end of metapost log file
converting scraps ... done
making map ... done
pdftex log file #
This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/W32TeX)
(preloaded format=pdftex 2020.6.19) 25 APR 2021 16:55
entering extended mode
**data.tex
(./data.tex (./th_enc.tex) (./th_texts.tex) (./th_resources.tex
(c:/Program Files (x86)/Therion/texmf/tex/glyphtounicode.tex))
(./th_fontdef.tex{c:/Program Files (x86)/Therion/texmf/fonts/pdftex.map})
(./th_formdef.tex
Normal \count register pool exhausted, switching to extended pool.)
(./th_pagedef.tex (./th_legend.tex)
! Undefined control sequence.
...rr \hbox {\pdfrefxform \THXBaaabdaa
}
\rlap #1->\hbox to\z@ {#1
\hss }
l.6886108 \PBcorr{2560.04}{2665.28}{\THXBaaabdaa}
%
The control sequence at the end of the top line
of your error message was never \def'ed. If you have
misspelled it (e.g., `\hobx'), type `I' and the correct
spelling (e.g., `I\hbox'). Otherwise just continue,
and I'll forget about whatever was undefined.
! Missing number, treated as zero.
}
\rlap #1->\hbox to\z@ {#1
\hss }
l.6886108 \PBcorr{2560.04}{2665.28}{\THXBaaabdaa}
%
A number should have been here; I inserted `0'.
(If you can't figure out why I needed to see a number,
look up `weird error' in the index to The TeXbook.)
! pdfTeX error (ext1): cannot find referenced object.
}
\rlap #1->\hbox to\z@ {#1
\hss }
l.6886108 \PBcorr{2560.04}{2665.28}{\THXBaaabdaa}
%
Here is how much of TeX's memory you used:
5700 strings out of 94623
61269 string characters out of 1150079
1760549 words of memory out of 6587292
7351 multiletter control sequences out of 15000+5
21229 words of font info for 66 fonts, out of 100 for 2000
1416 hyphenation exceptions out of 5000
12i,5n,9p,459b,73s stack positions out of 5000i,500n,1p,20b,5s
! ==> Fatal error occurred, no output PDF file produced!
# end of pdftex log file #
C:\Program Files (x86)\Therion\therion.exe: error -- pdftex exit code -- 1
writing xtherion file ... done
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion
[Therion] XVI output misaligned (rotated) from original TopoDroid sketches
Paul I expect this looks like something that is controlled at the TopoDroid end of the process. Maybe try asking on a TopoDroid forum? Bruce From: Therion On Behalf Of Paul Rowe Sent: Wednesday, 21 April 2021 09:49 To: List for Therion users Subject: Re: [Therion] XVI output misaligned (rotated) from original TopoDroid sketches Hi Bruce, No, it's not magnetic declination. There is a fixed station in the survey for the entrance, and for this lat/long the declination is 20.5 degrees. You can see an example here, with the green splay generated from the TopoDroid sketch and the grey splay coming from the exported XVI layer: The XVI difference is -1.1 degrees. That's about the difference between true north and grid north at this location on the NZGD2000 maps. I have tried exporting using 'north grid' and 'north true' but that hasn't made a difference. Not sure if anyone has tried generating an XVI and putting it under the TopoDroid sketch to compare them? Cheers, Paul On Wed, 21 Apr 2021 at 08:19, Bruce Mutton mailto:br...@tomo.co.nz> > wrote: Hi Paul The misalignment is not matching the magnetic declination by any chance? Or the difference between a manual declination setting in either application and an automatically calculated declination based on a cs setting? I have not used TopoDroid since it was able to export sketches, so not much help, and have forgotten much of what I did know anyway. Bruce From: Therion mailto:therion-boun...@speleo.sk> > On Behalf Of Paul Rowe Sent: Tuesday, 20 April 2021 10:43 To: List for Therion users mailto:therion@speleo.sk> > Subject: [Therion] XVI output misaligned (rotated) from original TopoDroid sketches Hi, I'm just trying out TopoDroid for the first time as the source for scraps in Therion. I can view the th2 scraps in Therion and can see the stations and splays. However, if I then output to XVI and add the XVI as a background image in Therion, the XVI is misaligned. The scale is correct and I just manually move the background XVI image to line up with one of the stations in the scrap. The XVI layer is rotated slightly (1 or 2 degrees) and then doesn't line up across the rest of the sketch imported from TopoDroid. Has anyone run into this? I thought it might be a difference between true north and grid north, but exporting to XVI with north set to true or grid doesn't fix the issue. The XVI layer isn't strictly necessary as the stations and splays are already visible in the TopoDroid sketch output. It does make me worry that there's some underlying problem though that I need to fix. Thanks, Paul Rowe ___ Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
