Re: [Therion] Subtypes can't have numbers?

[Martin Budaj]

Hi, this is a MetaPost limitation; s41p actually means s[41].p in MetaPost,
not a simple variable name.

M.


On Sun, Jan 14, 2024, 20:54 Rodrigo Severo via Therion 
wrote:

> Hi,
>
>
> Just trying to set a "line u:s41p" symbol on latest Therion and getting
> strange metapost errors:
>
> ! Missing `=' has been inserted.
> 
>51
> l.6846 let l_u_s51
>   p = l_u;
> You should have said `let symbol = something'.
> But don't worry; I'll pretend that an equals sign
> was present. The next token I read will be `something'.
>
> ! Missing symbolic token inserted.
> 
>  INACCESSIBLE
> l.6846 let l_u_s51
>   p = l_u;
> Sorry: You can't redefine a number, string, or expr.
> I've inserted an inaccessible symbol so that your
> definition will be completed without mixing me up too badly.
>
> ! Extra tokens will be flushed.
> 
>p
> l.6846 let l_u_s51p
> = l_u;
> 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.)
>
> ! Missing `=' has been inserted.
> 
>51
> l.6847 def l_u_s51
>   p_legend = l_u_s51p(((-.3,0.5) .. (.3,.3) .. (.7,.7) ..
> (1...
> The next thing in this `def' should have been `=',
> because I've already looked at the definition heading.
> But don't worry; I'll pretend that an equals sign
> was present. Everything from here to `enddef'
> will be the replacement text of this macro.
>
> I believe that subtypes aren´t supporting all chars allowed by 
> as defined in THBook page 13 (Data types).
>
> Is it a bug or am I misreading something?
>
>
> Regards,
>
> Rodrigo
>
> ___
> 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] Turning LIDAR point clouds into cave maps

[Martin Budaj]

On Wed, Nov 29, 2023 at 4:47 PM Bill Gee  wrote:

> Looking at the sample files, it looks like he extracts some images from
> the point cloud.  One of them is an overhead view and others are cross
> sections and profiles.  He then uses these JPG images as the drawing
> background to produce a traditional cave map.  The LiDAR scan
> essentially replaces the in-cave sketching.  I suspect there is some
> custom software to extract the images from the point cloud.

Indeed, the scans (combined with videogrammetry as in iPhone or iPad)
preserve a lot of details and can be used to draw 2D maps. However,
they can't completely replace the sketches or notes, as there is much
information that can't be captured in the scans (air droughts, lake
bottom etc.)

> I remember some years ago hearing about some mapping projects where the
> survey stations were marked with small balls in a specific color.  The
> processing software recognized that color and provided a way to connect
> those points to known x,y,z locations - a centerline.  It was
> fantastically expensive in both money and computer resources.
>
> In a way, we do sort of the same thing with Therion.  The centerline
> data is processed to produce a set of x,y,z coordinates.  The survey
> stations are flagged in that data set.  Then when the sketch is drawn
> out, we insert points of type "survey station" which are also flagged.
> The sketch can be considered as a sort of two dimensional point cloud.
> Therion knows how to match up the survey station points in the sketch
> with the survey stations in the x,y,z coordinate set.  From there it can
> morph everything around.

This is exactly the plan how to implement it in Therion, when time permits:

1) you scan a fragment of a cave (a 3D scrap) with some survey
stations visually marked
2) you assign station names as used in Therion centreline to local 3D
coordinates in the 3D scrap
3) Therion warps the 3D scrap and aligns it with the centreline
4) ideally, Therion smoothly joins adjacent 3D scraps

The result would be a 3D model which could combine the walls captured
from scans with those generated from the 2D scraps and LRUD data. This
way you could progressively improve the 3D model as your LiDAR
scanning progresses.

There is a preliminary issue for this here:
https://github.com/therion/therion/issues/475

Martin

P.S. Here is a 50-metres dig scanned by an Apple LiDAR in around 30
minutes: https://photos.app.goo.gl/Cvs8mej2RCqpGoj9A
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion-cs] JTSK

[Martin Budaj]

Ahoj,

On Mon, Sep 18, 2023 at 10:11 PM Lubomir Sliva  wrote:

> downloading the grid sk_gku_JTSK03_to_JTSK.tif from  into
> C:\Users\Lubo\AppData\Local/proj...
> done
>
> C:\Program Files (x86)\Therion\therion.exe: error -- PROJ library: 1029
> (File not found or invalid): +proj=pipeline +step +inv +proj=krovak
> +lat_0=49.5 +lon_0=24.8 +alpha=30.2881397527778 +k=0.
> +x_0=0 +y_0=0 +ellps=bessel +step +inv +proj=hgridshift
> +grids=sk_gku_JTSK03_to_JTSK.tif +step +proj=krovak +lat_0=49.5
> +lon_0=24.8 +alpha=30.2881397527778 +k=0. +x_0=0 +y_0=0
> +ellps=bessel +step +inv +proj=krovak +lat_0=49.5 +lon_0=24.8
> +alpha=30.2881397527778 +k=0. +x_0=0 +y_0=0 +ellps=bessel +step
> +proj=push +v_3 +step +proj=cart +ellps=bessel +step +proj=helmert
> +x=485.021 +y=169.465 +z=483.839 +rx=-7.786342 +ry=-4.397554 +rz=-4.102655
> +s=0 +convention=coordinate_frame +step +inv +proj=cart +ellps=WGS84 +step
> +proj=pop +v_3
> writing xtherion file ... done
>

chyba znamená, že Therion nevie stiahnuť grid počas behu (nie je vypnutý
internet? neblokuje ho firewall?)


> Skúšal som všeličo, ale neúspešne, zatiaľ jediná možnosť bola neudávať cs
> iJTSK a ručne zadať deklináciu (+ ako som následne zistil mal by som k tomu
> pripočítať meridiánovú konvergenciu). Neviem či je chyba vo vstupných
> dátach, lebo s Therionom moc skúseností nemám, alebo je chyba v Therione
> alebo u mňa v PC. Pozeral som sa do adresáru
> "C:\Users\Lubo\AppData\Local/proj..." ktorý bol v chybovej hláške, nie je
> to síce kompletná cesta, ale žiadny súbor/adresár s názvom proj??? tam
> nezapísalo. Grid sk_gku_JTSK03_to_JTSK.tif som stiahol ručne, ale netuším,
> kde by som ho mal vložiť, aby ho Therion našiel,
>

Ručne stiahnutý súbor treba nahrať práve do adresára
C:\Users\Lubo\AppData\Local\proj


> i keď  nerozumiem, načo ho v mojom prípade Therion potrebuje, keď nerobím
> transformácie medzi dvomi CRS. V počítači mám naištalovaný QGIS aj
> ArcGISpro, je možné že by to mohlo mať na to vplyv?
>

Therion robí vždy transformáciu do zemepisných súradníc v systéme WGS84
kvôli numerickému výpočtu meridiánovej konvergencie na danom mieste.

Martin
___
Therion-cs mailing list
Therion-cs@speleo.sk
https://mailman.speleo.sk/listinfo/therion-cs

Re: [Therion] Background map-header

[Martin Budaj]

Hi,

the header background colour is hard-coded to be the same as the map
background so it can't be changed without modifying the program. What's
your use case to have a different colour?

Martin

On Fri, Sep 8, 2023 at 8:05 PM Yann Gardère  wrote:

>
> Hello therion users
>
> On Therion I would like to apply a particular background color for the
> "map-header" different from the background color of the map, does anyone
> have a tex-map or metapost code to send me to do this?
>
> I don't find this in therion's wiki
>
> Thanks [image: ]
>
> Yann
>
>
>
>
> ___
> 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] Change default PDF output font

[Martin Budaj]

On Tue, Sep 5, 2023 at 3:17 PM Wookey  wrote:

> On 2023-09-05 23:15 +1200, Paul Rowe wrote:
> >This will be really handy as our Māori alphabet includes accented
> >characters unavailable in the default non-Unicode set.
>
> Maybe the default therion font should be set to a unicode one so it
> works for more people/languages/countries? That seems sensible at this
> point.  Pretty-much everyone should have unicode fonts avaiable and
> working, shouldn't they?
>

We would need to ship such a font with therion to ensure that the default
font is found.

But the real issue is that using TTF or OTF fonts is much slower, as
therion converts them on the fly to a set of PFB fonts (each font
containing at most 256 characters) because MetaPost can't use unicode fonts.

Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Bug with "copyright" symbol ?

[Martin Budaj]

Hi,

the easiest way is to use unicode fonts (set "pdf-fonts" in the ini file),
directly with the © character instead of \copyright macro.
It would be much more work to redefine the \copyright macro (and other
similar plain TeX macros which construct some complex characters from more
simple ones) to properly adapt to font scaling.

Martin



On Thu, Aug 31, 2023 at 6:58 PM Torsten Schnitter via Therion <
therion@speleo.sk> wrote:

> Hello
>
> I'm using a redefined legend and within this there is a line:
> ...{\size[\thsizem]\si\the\cartotitle:
> \ss\the\cartoteam\quad\size[\thsizem]{\copyright\thinspace\si\the\cartodate\par}}...
>
>
> The variable \thsizem is defined within the layout:
> ... code-tex ...
> \def\thsizem{36}
> ... endcode ...
>
> The output is like this:
>
> As you can see the circle around the letter "c" is not correct and is not
> changed in size as the letter itself.
>
> Does anyone have a solution to correct this?
>
> Thanks in advance,
> Torsten
> ___
> 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] Change default PDF output font

[Martin Budaj]

Hi,

to change the font family, use the "pdf-fonts" setting in the ini file (see
the thbook, page 89). The easiest way to change the default style of all
texts to e.g. italics, just use the same italic font five times in the
"pdf-fonts" specification.

Martin


On Wed, Aug 2, 2023 at 2:09 AM Paul Rowe 
wrote:

> Is there a way to override the default output font through 'code tex-map'?
>
> I can see there are ConTeXt macros to change basic styles (e.g. serif font
> = \rm) but can't find any examples of how that is used to change the
> default font style for the whole PDF map output. I ideally want to change
> the font family as well.
>
> Thanks,
> Paul Rowe
> ___
> 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] Can't change default l_wall style with metapost

[Martin Budaj]

Hi,

define l_wall_bedrock instead of l_wall

M.

On Tue, Jul 25, 2023 at 2:03 AM Paul Rowe 
wrote:

> Hi,
> I have changed wall subtypes before in my layout. e.g. Using Bruce
> Mutton's
>
> code metapost
> def l_wall_unsurveyed (expr P) =
>   T:=identity;
>   pickup PenC;
>   thdraw P dashed evenly scaled (2*optical_zoom);
> enddef;
> endcode
>
> However, I can't get this working on the default l_wall type. Any changes,
> including using the same style as in the above l_wall_unsurveyed example
> get ignored. e.g.
> code metapost
> def l_wall (expr P) =
>   T:=identity;
>   pickup PenC;
>   thdraw P dashed evenly scaled (2*optical_zoom);
> enddef;
> endcode
>
> I'm not sure what I'm missing. I'm first trying to prove I can override
> this, and then working on a wall style with a shadow or external
> cross-hatching.
>
> Thanks,
> Paul
>
> ___
> 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] mailing list issues

[Martin Budaj]

Hi,

there was an issue with rejected posts to this list:
https://github.com/therion/therion/issues/515

We did some modifications in the mailing system configuration; it should be
fixed now.

Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Text size of the scale-bar

[Martin Budaj]

Check https://github.com/therion/therion/issues/125#issuecomment-639324177

Best regards
Martin

On Sat, Apr 22, 2023 at 4:39 PM david Le berre via Therion <
therion@speleo.sk> wrote:

> Dear all.
>
> Little issue: I can change all text size in the header except the scale
> bar one's.
> After a few hours of digging in Tex and exemple I can not find the way.
>
> [image: Image en ligne]
>
> Any solution?
> Thanks in advance.
>
> David
> ___
> 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] Base-Scale produces numbers in front of point:abel

[Martin Budaj]

Should be fixed in the recent commits, see also
https://github.com/therion/therion/issues/428

Martin


On Thu, Nov 24, 2022, 16:17 Axel  wrote:

> Hi,
>
> got some weired problem which might be a bug or me being stupid:
> If scale and base-scale are used (just want to get all symbols a bit
> smaller) I get some scaleing-numbers in front of point:label (if base-scale
> is 1/2 it is indeed 0.5 in front of the text).
> Wondered if I am doing something wrong and made a test with a very(!)
> rudimentary survey and 5 labels in all scales with the scale as text. The
> layout just contains scale and base-scale (in pdf: scale 1 250/base-scale 1
> 100) and that reproduces my problem (pdf attached). Am using Xtherion 6.1.2
> (22-07-11)
>
> any help would be appreciated
>
> thx,
> Axel
>
> ___
> 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] Upgrade to Fedora 37 - Problems with proj packages

[Martin Budaj]

On Wed, Nov 16, 2022 at 10:00 PM James Begley 
wrote:

> I'm aware of this issue - I'm currently struggling to build therion under
> fedora 37 (which has proj v9 installed). I had hoped that it would be a
> simple task to rebuild therion to pick up the new proj libraries, but that
> doesnt appear to be the case.
>

Hi,
switching to cmake-based build should help. Make-based build uses
"pkg-config proj --libs --static" to get the required libraries and for
Proj9 it returns a lot of weird dependencies which are not installed by
default when you install Proj 9. Cmake build uses dynamic linking and
avoids this problem.
Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Translation of therion book to Greek

[Martin Budaj]

Hi,

great to hear about your plan! Perhaps the best way would be to start in a
separate repo. If it works well, maybe we could integrate it into the main
repo later.

I suggest to use thbook/translations/gr as a base directory and adopt the
paths to files included from thbook/etc, thbook/mp and thbook/pic, so that
we could accommodate more translations in the future with one shared set of
pictures and other assets.

But let us know if you have a different idea about how to proceed.

Thanks
Martin

On Thu, Nov 17, 2022 at 3:42 PM Panagiotis Papadakos 
wrote:

> Thank you Martin,
>
> so I should keep the translation in another repo I guess, right?
>
> On Thu, Nov 17, 2022 at 4:39 PM Martin Sluka via Therion <
> therion@speleo.sk> wrote:
>
>> Download source from Github.
>>
>> Then in folder thbook you should find:
>>
>>
>> Martin
>>
>> 17. 11. 2022 v 11:04, Panagiotis Papadakos :
>>
>> Dear all,
>>
>> I would like to translate the therion book to greek, but I am not able to
>> find the tex sources online.
>> Can anyone point me to those and also describe what is the translating
>> process?
>>
>> Best regards
>> Panagiotis
>>
>> P.S. I am sorry for any duplicates (I have just subscribed to the list)
>> ___
>> 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 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

[Martin Budaj]

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  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
>
> -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 mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] New default settings and recent proj changes

[Martin Budaj]

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
>
> 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  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 mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Problem with new default settings and recent proj changes

[Martin Budaj]

On Tue, Apr 26, 2022 at 11:45 AM Bruce Mutton  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

Re: [Therion] Problem with new default settings and recent proj changes

[Martin Budaj]

They all come from 'pkg-config proj --libs --static' (which takes them
from 'pkg-config libcurl --libs --static'). I agree it's excessive.
For historical reasons, make uses static linking, you can use cmake
which links dynamically.

Martin

On Tue, Apr 26, 2022 at 3:10 PM Benedikt Hallinger  wrote:
>
> Yes, seems excessive. Why ldap?
>
> > Am 26.04.2022 um 14:40 schrieb Wookey :
> >
> > On 2022-04-26 12:40 +0200, Benedikt Hallinger wrote:
> >> Besides that, I cant compile due to missing deps.
> >> Does someone already have info on what debian packages i need to install?
> >
> > The list in
> > https://sources.debian.org/src/therion/6.0.6-1/debian/control/ should
> > be sufficient, unless some new dependency has been introduced by 6.06
> >
> > Build-Depends: dpkg (>=1.16.2), debhelper, debhelper-compat (=13), perl (>= 
> > 5.5), tcl,
> >  libvtk9-dev, libwxgtk3.0-gtk3-dev, libfreetype6-dev, libjpeg-dev, 
> > libpng-dev,
> >  pkg-config, texlive-base, libproj-dev, libsqlite3-tcl, python3,
> >  libshp-dev, catch2, cmake, ninja-build, libfmt-dev
> > Build-Depends-Indep: texlive-metapost, imagemagick, ghostscript
> >
> >
> >> -L/usr/lib/x86_64-linux-gnu/mit-krb5 -lproj -lpthread -lstdc++ -lm 
> >> -lsqlite3
> >> -lm -ldl -lz -lpthread -ltiff -lwebp -lzstd -llzma -ljbig -ljpeg -ldeflate
> >> -lz -lm -lcurl -lnghttp2 -lidn2 -lrtmp -lssh2 -lpsl -lssl -lcrypto -lssl
> >> -lcrypto -lgssapi_krb5 -llber -lldap -llber -lzstd -lbrotlidec -lz -pthread
> >> /usr/bin/ld: cannot find -lnghttp2: Datei oder Verzeichnis nicht gefunden
> >> /usr/bin/ld: cannot find -lidn2: Datei oder Verzeichnis nicht gefunden
> >> /usr/bin/ld: cannot find -lrtmp: Datei oder Verzeichnis nicht gefunden
> >> /usr/bin/ld: cannot find -lssh2: Datei oder Verzeichnis nicht gefunden
> >> /usr/bin/ld: cannot find -lpsl: Datei oder Verzeichnis nicht gefunden
> >> /usr/bin/ld: cannot find -lgssapi_krb5: Datei oder Verzeichnis nicht
> >> gefunden
> >> /usr/bin/ld: cannot find -llber: Datei oder Verzeichnis nicht gefunden
> >> /usr/bin/ld: cannot find -lldap: Datei oder Verzeichnis nicht gefunden
> >> /usr/bin/ld: cannot find -llber: Datei oder Verzeichnis nicht gefunden
> >
> > This does seem to be a pile of new dependencies:
> > libnghttp2-dev, libidn2-dev, librtmp-dev, libssh2-1-dev, libpsl-dev, 
> > libkrb5-dev, libldb-dev, lidldap-dev.
> >
> > Put that lot in and it should build.
> >
> > Is that all from libproj's online download facility? ssh, kerberos,
> > ldap, real-time streaming? Seems excessive.
> >
> > Wookey
> > --
> > Principal hats:  Debian, Wookware, ARM
> > http://wookware.org/
> > ___
> > 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 mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Problem with new default settings and recent proj changes

[Martin Budaj]

On Mon, Apr 25, 2022 at 9:38 PM Martin Budaj  wrote:
>
> On Mon, Apr 25, 2022 at 11:27 AM Bruce Mutton  wrote:
> > Before reporting this I thought I'd better at least try 6.0.6+3bc6556
> >
> > I get a crash right away as the therion.log transcript below indicates.
>
> OK, I could reproduce it and will fix it soon.

Should be fixed in 14fac78.
Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Problem with new default settings and recent proj changes

[Martin Budaj]

On Mon, Apr 25, 2022 at 11:27 AM Bruce Mutton  wrote:
> Something bad happened between 6.0.0 and 6.0.5 that we only just noticed 
> today (because for day to day work we only compile small sections of the 
> cave).

We started to use Proj 9 in 6.0.5 (msys2 build). In mxe builds Proj 5
is still used. There were probably no other (internal) changes in
Therion between 6.0.0 and 6.0.5 which should cause the displacement.

> Therion 6.05 has moved some of our fixed stations about 100 m north (those 
> specified with cs lat-long and cs EPSG:2193 NZTM) and others (specified with 
> cs EPSG:27200 NZMG) stayed in their correct locations, severely distorting 
> our cave.  No errors reported, just outputs with large loop errors and 
> distorted cave.
>
> Interestingly, it is the old archaic format NZMG that performs correctly and 
> the modern and lat-long are relocated.

Could you send me some examples of correct and incorrect transformations?

> Before reporting this I thought I'd better at least try 6.0.6+3bc6556
>
> I get a crash right away as the therion.log transcript below indicates.

OK, I could reproduce it and will fix it soon.

Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Custom Metapost label can't display newlines or accents

[Martin Budaj]

On Sat, Apr 23, 2022 at 9:56 PM Rhys Tyers  wrote:

> Just in case a simplification makes the question/answer clearer, I'll
> retry my question from above:
>
> I define a user label:
>
> def p_u_label (expr P,R,S,A)=
> lab:=thelabel(ATTR_text, P)
> process_label(P, R)
> enddef;
> initsymbol("p_u_label");
>
> This for example will not print a Č character, but the standard Therion
> label will.
>
> How do I make this display text the same way that a normal Therion label
> does?
>
> I’ve read through a lot of the Therion source trying to find out where
> this happens but in the relevant bit
>  there
> seems to be no extra magic happening.
>
Hi, sorry for a late answer -- there was some issue with our mailing list
and the posts from the last few weeks were sent in a batch last Saturday.

Regarding ATTR_text, therion doesn't do any special processing of special
sequences like  or accented characters. Maybe it should (the same way
as it does for standard -text attributes), I'll think about it.

Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] new default settings

[Martin Budaj]

Hi all,

Therion has been supporting the advanced features of the Proj library
for some time now. (Proj's purpose is to do transformations between
coordinate systems.) This functionality was disabled by default and
you could enable it using 'proj-auto' and 'proj-missing-grid' options
in the initialization file.

'proj-auto' lets Proj choose the best transformation and you can set
'proj-missing-grid' to download a grid file (see
https://proj.org/usage/transformation.html#grid-based-datum-adjustments)
if the transformation needs it; see the therion book for details. The
log file lists all the transformations chosen and used at the end.

The latest commit (3bc6556) enables this "use the best transformation
and download the grids if needed" functionality. We know that
automatic downloads are a sensitive issue, but in this case we can
trust the Proj library not to do any harm
(https://proj.org/usage/network.html) and the user experience is much
better.

Could you check if this version works well with your data sets? The
windows installer is available here:
https://github.com/therion/therion/actions/runs/2203811478 (use the
msys2 version which uses up-to-date Proj library; you need to be
logged in to github to download it).

M.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Delete documents in Therion wiki Media Manager

[Martin Budaj]

OK, deleted. There is a Media Manager in the menu next to the search
field in the upper-right corner; not sure if some special permissions
are required.

Martin

On Sat, Feb 19, 2022 at 3:10 AM Bruce Mutton  wrote:
>
> 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
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Tex-map code for passing variables

[Martin Budaj]

Hi,

I think the following should work:

1) use \loadpicture{\pathvar} in the shared thconfig file
2) define \pathvar macro in the 'code tex-map' section of the
customised thconfig file: \def\pathvar{yourfile.pdf}

Martin

On Tue, Feb 8, 2022 at 11:03 AM Nigel Cooke  wrote:
>
> Good evening all,
>
>
>
> I am trying to pass a variable to the \loadpicture function in a tex-map code 
> block. As part of a \def\maplayout{ } block, I am using this line of code :
>
> \legendbox{100}{-3}{NE}{\loadpicture{output/ShadesOfDeath_HallOfTheMountainKingLocation-p.pdf}}
>  to place a picture in the map header. This works fine but I need to pass in 
> the file path as a variable.
>
>
>
> To put it in context, I have a suite of maps, each of which has a small inset 
> map as part of the header. The inset map gives an overview/location 
> reference, much the same as the navigation panel in an atlas. The maps share 
> a common layout block in a shared thconfig file. Parameters in the shared 
> layout are populated with map specific information via Therion data and some 
> variables (eg \cavename) that I set in a thconfig file customised for the 
> specific map. I want to keep the common layout generic in case I need to 
> change it in the future and to avoid having to update it in numerous files. 
> What I'm trying to do with \loadpicture is select the picture that is the 
> location overview for the specific map. I can do it using a hardcoded file 
> path but I need it to work with a variable that contains the file path. I 
> would then set the variable in the thconfig for a specific map. The layout 
> command ‘map-image’ doesn't work because I have redefined the \maplayout 
> macro in a tex-map code block.
>
>
>
> Is it possible to pass a file path in a variable to the \loadpicture 
> function? If so, can anyone show me some code that would to do it? I’ve tried 
> reusing an existing variable like \the\comment but that only produces a 
> compile error. My Tex knowledge is limited so I am struggling with working 
> out how to set this up. Also, if anyone knows of a better way to achieve the 
> same result I’d be eternally grateful if you would share that knowledge.
>
>
>
> Thanks
>
>
>
> Nigel
>
>
>
>
>
> ___
> 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] My take on a new Therion map editor

[Martin Budaj]

Wow, the demo is really impressive! It would be great if you could
join our next developers' online meeting (not scheduled yet).

Cheers,
Martin

On Sat, Jan 15, 2022 at 3:40 PM Csongor Zih  wrote:
>
> Hi everyone!
>
>
> I'm a university student and I decided to try and make an XTherion 
> replacement as a short term project. I have seen the activity here around 
> making a new version of XTherion that would overhaul the current workflow of 
> Therion projects. These proposals look exciting and great, but what I focused 
> on was just creating an editor for TH2 files, that only replaces the map 
> editor part of XTherion, and otherwise affects nothing about how you use 
> Therion. It is most similar to the TH2 importer and exporter for Inkscape.
>
>
> Demo video: https://www.youtube.com/watch?v=kpogxtt_4TI
>
> This is only a feature showcase, the app is not ready to use yet, but you can 
> try it out.
>
>
> The editor was built from the base of a regular vector graphics editing app, 
> similarly to the Inkscape plugin. The whole app runs in a web browser, it's 
> written in JavaScript and TypeScript, and it should run on all modern 
> browsers.
>
> I have tried to set a very small scope for this project, this is why I didn't 
> try to create a complete vector graphics editor and used an existing one. 
> There is also no WYSIWYG editing, which would be hard to achieve without 
> reimplementing the whole of Therion (obviously outside the plans for this 
> project). The scope and functionality is significantly smaller than the 
> QTherion or Mapiah projects, and I would expect that this editor would not be 
> useful once these projects are in a usable state. The editor also has less 
> functionality than XTherion itself, which I see as a trade-off between 
> speed/friendliness and having complete control. One of these is that in this 
> editor all area objects are tied one-to-one with line objects. This may not 
> be how all people use areas, but it is easier to understand and to show on 
> screen, and it's how TopoDroid handles it.
>
>
> I think while this app is not everything you might want from an editor, it 
> has clear advantages over XTherion and is more streamlined than the Inkscape 
> plugins, and a lot closer to being complete than the Qt projects currently in 
> development.
>
>
> The project's name is currently wtherion (because it's web-based and because 
> of the other project names), but this may change. It's on GitHub here: 
> https://github.com/daem-on/wtherion
>
>
> Hope that this will be useful in the future and I look forward to your 
> feedback,
>
> Csongor
>
> ___
> 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] Presenting Mapiah, a multi-platform, more friendly, modern and performant graphical interface for Therion

[Martin Budaj]

On Sun, Dec 5, 2021 at 1:38 PM Martin Budaj  wrote:
>
> On Wed, Dec 1, 2021 at 11:01 AM Rodrigo Severo via Therion
>  wrote:
> > Maybe we schedule a live meeting to talk about both approaches together and 
> > decide which way to go?
>
> So here is a poll to find the best meeting time:
>
> https://doodle.com/poll/dhhz9mhk7vaizmis?utm_source=poll_medium=link

Tuesday December 14 at 8 PM CET (= 7 PM GMT) is good for all. We'll
send the meeting link via email.

Looking forward to meeting you all
Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Presenting Mapiah, a multi-platform, more friendly, modern and performant graphical interface for Therion

[Martin Budaj]

On Wed, Dec 1, 2021 at 11:01 AM Rodrigo Severo via Therion
 wrote:
> Maybe we schedule a live meeting to talk about both approaches together and 
> decide which way to go?

So here is a poll to find the best meeting time:

https://doodle.com/poll/dhhz9mhk7vaizmis?utm_source=poll_medium=link


Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Fwd: PDF output: layers nested?

[Martin Budaj]

On Tue, Nov 23, 2021 at 4:42 PM Andrew Atkinson  wrote:
> On 23/11/2021 15:08, Benedikt Hallinger wrote:
>
> > I don't know PDF specifics, but it would be very handy to have "nested" 
> > layers, i.e. submaps as separate layers in the main layer.
>
> That would be very useful, don't know if it is possible

There is some support for a tree-like hierarchy of the optional
content layers in the PDF specification, but you can't select/unselect
a group of sublayers at once. See the attached picture for an
illustration: you can change the visibility of the lowest-level maps
(the "leafs") only, not the higher-level maps or groups (the
"branches"). So it's not very helpful in this case except for having
some labels indicating the hierarchical structure of maps.
If all the tree was interactive, we could simply expand it to all
sub-maps to have complete and easy control of the displayed content.

Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Presenting Mapiah, a multi-platform, more friendly, modern and performant graphical interface for Therion

[Martin Budaj]

Hi, Rodrigo.

Your PoC app looks very promising and we are happy that you've made
this first step. C++/Qt seems to be a good choice as well.

What might be a bit surprising for most of the users hoping for a
better UI, there is also one other project to create a Qt replacement
for XTherion (started by Michal Plch and available in the qtherion
branch of our git repo ;)

There are some differences in the scope and technology, though:
* the idea was to provide a UI which would be simple enough for new
users, not necessarily mimicking XTherion's approach
* as a result, it doesn't expect user to know internals of *.th or
*.th2 files (and even doesn't support them directly – in this branch
therion was extended to use a JSON-based data package to communicate
with qtherion UI)
* it's based on C++/Qt, too, but heavily using QML to define the UI

It's also a PoC in a very early stage and as such hasn't been
advertised on the list yet. But it's clear that time is ripe for a new
UI.

How about some brainstorming with Rodrigo, Michal and perhaps some
others on possible synergies and the best way forward?

Cheers
Martin


On Mon, Nov 15, 2021 at 12:42 AM Rodrigo Severo via Therion
 wrote:
>
> Presenting Mapiah.
>
> Mapiah is my take on a multi-platform, more friendly, modern and performant 
> graphical interface for Therion. It's written in C++/Qt. It aims to be as 
> compatible as practical and possible with XTherion.
>
> This is the "proof-of-concept" release.
>
> It's source code and it's releases files can be found at the projects home at 
> SourceForge: https://sourceforge.net/projects/mapiah/
>
> Please let me know what you think about it, if it has any future, if you want 
> to help.
>
>
> *The name*
>
> Mapiah is a international friendly version of the portuguese word "mapear" on 
> the sentence "vamos mapear?" - "let's go surveying?" or "let's go mapping?" - 
> which is usually pronounced [vʌmu mapi'a].
>
>
> *Multi-platform*
>
> Right now we have both Linux and Windows releases as these are the OSs I have 
> access and minimal experience with. Until some Mac user steps up, that's the 
> way it's gonna be.
>
> Having said that, the idea is to follow best practices during Mapiah's 
> development to ease the release process on all target platforms: Linux, 
> Windows and Mac.
>
>
> *The C++/Qt choices*
>
> Going backwards, the Qt framework was chosen as it has an open source 
> compatible version. It's mature, powerful and seems to take multi-platform 
> support seriously.
>
> The first idea was to use Qt Python as the "friendly" requirement could also 
> be applied to the language chosen but in the end I decided to go with C++ 
> because I believe that a C++ application might be more easily distributable 
> across all platforms.
>
>
> *The "proof-of-concept" release*
>
> The basic reading and writing functionality supposely is th concept being 
> proved in this release. Supposely because the actual concept I am trying to 
> prove myself with this release is that I can write functional and decent 
> C++/Qt code which, for the time being, is kinda proved.
>
>
> *Functionality*
>
> This 0.0.1 release can read a TH2 file, present it on the screen and save it.
>
> With an open file you can change the zoom level and write the file again.
>
> You should be able to see your TH2 file on screen correctly and the saved 
> file should be functionally identical to the original one.
>
> All point, line, area, scrap and XTHERION options should be properly read and 
> saved even if most aren't actually understood/acted upon.
>
>
> *License*
>
> This software is licensed under GPL 3 or later.
>
>
> *WARNINGS*
>
> PLEASE TEST!
>
> DON'T OVERRIDE YOUR ORIGINAL FILE WITH THE ONE WRITTEN BY MAPIAH!!
>
> THIS IS A PRE-ALPHA VERSION!!!
>
>
> Regards,
>
> Rodrigo Severo
> ___
> 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] Export centerline and/or stations to SHP without th2 files

[Martin Budaj]

‪On Thu, Nov 18, 2021 at 12:09 PM ‫עמרי גסטר‬‎  wrote:‬
> When I try to export to SHP or kml I get empty layers because I don't use th2 
> files.
> What I don't understand is why the centerline / splayes / stations layers are 
> empty as well.

Hi,

there is a bug in the embedded shapefile library if it's used under
Windows. The latest commit contains a local fix, so it should work
well now.

Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] thfill with page background colour?

[Martin Budaj]

On Tue, Nov 23, 2021 at 4:34 PM Tarquin Wilton-Jones via Therion
 wrote:
>
> > In which variable do i access the page's background color (the one set
> > wit the layout option "map-bg")?
>
> Fun fact ... you can't access that. Or at least, it didn't seem to be
> available back when I was trying to do that in version 5. And I still
> can't see any useful variable in version 6.

Hi,

it's now set as MapBackground in the latest commit.

M.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Therion Github plan

[Martin Budaj]

Free plan ;)

Martin

On Wed, Oct 13, 2021 at 9:08 PM Bruce Mutton  wrote:
>
> 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 supported by a free or a pain plan?
>
> Bruce
>
> ___
> 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] Metapost exit code in therion 6.0.1 and 6.0.2

[Martin Budaj]

Hi, this has been fixed in 6.0.3.

Cheers
Martin

On Wed, Sep 22, 2021 at 11:01 PM A Gott  wrote:
>
> HI Everyone,
>
> A friend messaged me while I was lucky enough to escape the UK and get to 
> spain for some caving, which was great!
>
> I've got back and tonight I tried to look at the problem he was having 
> outputting in Therion 6.0.1
>  I ran his survey in 5.5.3 with no issues whatsoever, I thought he could be 
> getting a bug from 6.0.1 so i updated my software, and now i'm bugged in 
> 6.0.2 with the metapost exit code on his survey.
>
> ### metapost log file 
> This is MetaPost, version 2.00 (TeX Live 2020/W32TeX) (kpathsea version 
> 6.3.2)  22 SEP 2021 21:44
> **data.mp
> (c:/Program Files (x86)/Therion/texmf/mpost/mpost.mp
> (c:/Program Files (x86)/Therion/texmf/mpost/plain.mp
> Preloading the plain mem file, version 1.005) ) (./data.mp
> {randomseed:=42}
>  [1] [2] [3] [4]
> [5] [6] [7] [8] [9] [10] [11] [12] [13] [14]
> [1]
> [Warning: scrap outline intersects itself in scrap 
> loper-p@inglorious.CusseyMas
> ter] [2] [3] [4] [5]
> [Warning: scrap outline intersects itself in scrap indy-1p@Indy.CusseyMaster]
> [6] [7] [8] [9] [10] [11] [12]
> [Warning: scrap outline intersects itself in scrap 
> timewarp-3p@Timewarp.CusseyM
> aster] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26]
> [27]
> [Warning: scrap outline intersects itself in scrap 
> inglorious...@inglorious.cus
> seyMaster] [28] [29] [30] [31]
> [Warning: scrap outline intersects itself in scrap 
> mine1@inglorious.CusseyMaste
> r] [32] [33] [34] [35] [36] [37] [38]
> [Warning: scrap outline intersects itself in scrap 
> shattered_dreams-2p@shattere
> d_dreams.CusseyMaster] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49]
> [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] (./mptextmp.mp) [61]
> ! Logarithm of -64.77 has been replaced by 0.
> log->begingroup(if(EXPR2)=0:0else:mlog((EXPR2))/
> mlog(10)fi)endgroup
> 
>;
> s_altitudebar->...d:=(EXPR1)-(EXPR0);dlog:=log(d);
>   
> if.dlog.mod1<0.301:dv:=2;e...
> l.10965 ...,(0.0,0.75000,0.75000,0.0))("")
>   ;
> Since I don't take logs of non-positive numbers,
> I'm zeroing this one. Proceed, with fingers crossed.
>
> (./mptextmp.mp) (./mptextmp.mp) [62] )
>
> Here is how much of MetaPost's memory you used:
>  18042 strings using 388328 characters
>  2412656 bytes of node memory
>  1681 symbolic tokens
>  11i,82n,19p,452b,5f stack positions out of 16i,98n,20p,487b,6f
> 76 output files written: data-patt.1 .. data.62
>
>
>  end of metapost log file 
> C:\Program Files (x86)\Therion\therion.exe: error -- metapost exit code -- 2
> writing xtherion file ... done
>
>
> I don't know whether its a bug or whether there is an error with the config 
> file which only presents in 6.0.1/2
>  but I thought I would send it to the list for thoughts?
>
> Alastair.
>
> please find below config file which ran fine in 5.5.3
>
>
> source CusseyMaster.th
>
>
> export model -fmt survex -o CusseyMaster.3d
>
> export map -proj [elevation 0]  -layout localside -o CusseyElevation.pdf
> export map -proj plan -layout LayoutMapBorder -layout sidesurvey -layout 
> localplan -layout-map-image 5 20 sw "./arrow.png" -layout-map-header 0 0 off 
> -o CusseyMaster.pdf
> #export map -proj plan -layout LayoutMapBorder -layout sidesurvey -layout 
> localplan -layout-map-image 17 20 sw "./arrow.png" -o CusseyMaster.pdf
> export map -proj plan -layout LayoutMapBorder -layout localplan -o 
> CusseyPlan.pdf
>
>
> layout sidesurvey
> map-image 55 100 s CusseyElevation.pdf
> endlayout
>
>
> layout localside
> symbol-set BCRA
> symbol-hide group cave-centreline
> scale-bar 25 m
> map-header 98 97 n
> map-comment "Discovered and Explored by Eldon Pothole Club 2020 - 
> 2021Surveyed By: Luke Cafferty, Rob Eavis, Jon Pemberton, Jeff 
> WadeSurvey Drawn By: Rob EavisElevation, facing NorthEntrance: SK 
> 21545 76524Altitude: 244m"
> legend on
>   grid bottom
>   grid-coords border
>   grid-size 10 10 10 m
>   #grid-origin 0  0  0 m
>
> colour map-fg [80 89 94]
> #colour map-bg [20 39 14]
>
> code metapost
> def s_scalebar (expr l, units, txt) =
>   begingroup
> interim warningcheck:=0;
> tmpl:=l / Scale * cm * units / 2;
> tmpx:=l / Scale * cm * units / 5;
> tmph:=5bp; % bar height
>   endgroup;
>   pickup PenC;
>   draw (-tmpl,0)--(tmpl,0)--(tmpl,-tmph)--(-tmpl,-tmph)--cycle;
>   p:=(0,0)--(tmpx,0)--(tmpx,-tmph)--(0,-tmph)--cycle;
>   for i:=-2.5 step 2 until 2:
> fill p shifted (i * tmpx,0);
>   endfor;
>   begingroup
> interim labeloffset:=3.5bp;
> for i:=0 step (l/5) until (l-1):
>   tmpx:=tmpl * (i * 2 / l - 1);
>   label.top(thTEX(decimal (i)),(tmpx,0));
> endfor;
> label.top(thTEX(decimal (l) & 

Re: [Therion] new Therion 6.0.3

[Martin Budaj]

On Mon, Oct 4, 2021 at 5:10 AM Wookey  wrote:
> This builds, but doesn't install, on debian unstable.

Hi, I'm attaching modified build files which should work.

I couldn't find a more elegant way to specify --prefix in
'override_dh_auto_install-indep'; could you look into it? For some
reason cmake --install doesn't use the right destination and we can't
use ninja to install at this place, as it doesn't support --component
option.

> I also noticed the source incudes extern/img.patch. I think that's 
> superfluous - it's been applied.
> That should presumably just be removed.

We keep it in the sources ready to apply it again when img.c gets updated ;)

Cheers
Martin


debian.tar.gz
Description: application/gzip
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Metapost exit code in therion 6.0.1 and 6.0.2

[Martin Budaj]

Hi,

this is related to a new continuously-coloured altitude legend introduced
in 6.0.0.

Could you send me the problematic dataset to investigate the issue?

In the meantime you can avoid the problem using
   colour-legend discrete
in the layout.

Cheers
Martin


On Wed, Sep 22, 2021, 23:01 A Gott  wrote:

> HI Everyone,
>
> A friend messaged me while I was lucky enough to escape the UK and get to
> spain for some caving, which was great!
>
> I've got back and tonight I tried to look at the problem he was having
> outputting in Therion 6.0.1
>  I ran his survey in 5.5.3 with no issues whatsoever, I thought he could
> be getting a bug from 6.0.1 so i updated my software, and now i'm bugged in
> 6.0.2 with the metapost exit code on his survey.
>
> ### metapost log file 
> This is MetaPost, version 2.00 (TeX Live 2020/W32TeX) (kpathsea version
> 6.3.2)  22 SEP 2021 21:44
> **data.mp
> (c:/Program Files (x86)/Therion/texmf/mpost/mpost.mp
> (c:/Program Files (x86)/Therion/texmf/mpost/plain.mp
> Preloading the plain mem file, version 1.005) ) (./data.mp
> {randomseed:=42}
>  [1] [2] [3] [4]
> [5] [6] [7] [8] [9] [10] [11] [12] [13] [14]
> [1]
> [Warning: scrap outline intersects itself in scrap
> loper-p@inglorious.CusseyMas
> ter] [2] [3] [4] [5]
> [Warning: scrap outline intersects itself in scrap
> indy-1p@Indy.CusseyMaster]
> [6] [7] [8] [9] [10] [11] [12]
> [Warning: scrap outline intersects itself in scrap
> timewarp-3p@Timewarp.CusseyM
> aster] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25]
> [26]
> [27]
> [Warning: scrap outline intersects itself in scrap
> inglorious...@inglorious.cus
> seyMaster] [28] [29] [30] [31]
> [Warning: scrap outline intersects itself in scrap
> mine1@inglorious.CusseyMaste
> r] [32] [33] [34] [35] [36] [37] [38]
> [Warning: scrap outline intersects itself in scrap
> shattered_dreams-2p@shattere
> d_dreams.CusseyMaster] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48]
> [49]
> [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] (./mptextmp.mp)
> [61]
> ! Logarithm of -64.77 has been replaced by 0.
> log->begingroup(if(EXPR2)=0:0else:mlog((EXPR2))/
> mlog(10)fi)endgroup
> 
>;
> s_altitudebar->...d:=(EXPR1)-(EXPR0);dlog:=log(d);
>
> if.dlog.mod1<0.301:dv:=2;e...
> l.10965 ...,(0.0,0.75000,0.75000,0.0))("")
>   ;
> Since I don't take logs of non-positive numbers,
> I'm zeroing this one. Proceed, with fingers crossed.
>
> (./mptextmp.mp) (./mptextmp.mp) [62] )
>
> Here is how much of MetaPost's memory you used:
>  18042 strings using 388328 characters
>  2412656 bytes of node memory
>  1681 symbolic tokens
>  11i,82n,19p,452b,5f stack positions out of 16i,98n,20p,487b,6f
> 76 output files written: data-patt.1 .. data.62
>
>
>  end of metapost log file 
> C:\Program Files (x86)\Therion\therion.exe: error -- metapost exit code --
> 2
> writing xtherion file ... done
>
>
> I don't know whether its a bug or whether there is an error with the
> config file which only presents in 6.0.1/2
>  but I thought I would send it to the list for thoughts?
>
> Alastair.
>
> please find below config file which ran fine in 5.5.3
>
>
> source CusseyMaster.th
>
>
> export model -fmt survex -o CusseyMaster.3d
>
> export map -proj [elevation 0]  -layout localside -o CusseyElevation.pdf
> export map -proj plan -layout LayoutMapBorder -layout sidesurvey -layout
> localplan -layout-map-image 5 20 sw "./arrow.png" -layout-map-header 0 0
> off -o CusseyMaster.pdf
> #export map -proj plan -layout LayoutMapBorder -layout sidesurvey -layout
> localplan -layout-map-image 17 20 sw "./arrow.png" -o CusseyMaster.pdf
> export map -proj plan -layout LayoutMapBorder -layout localplan -o
> CusseyPlan.pdf
>
>
> layout sidesurvey
> map-image 55 100 s CusseyElevation.pdf
> endlayout
>
>
> layout localside
> symbol-set BCRA
> symbol-hide group cave-centreline
> scale-bar 25 m
> map-header 98 97 n
> map-comment "Discovered and Explored by Eldon Pothole Club 2020 -
> 2021Surveyed By: Luke Cafferty, Rob Eavis, Jon Pemberton, Jeff
> WadeSurvey Drawn By: Rob EavisElevation, facing NorthEntrance:
> SK 21545 76524Altitude: 244m"
> legend on
>   grid bottom
>   grid-coords border
>   grid-size 10 10 10 m
>   #grid-origin 0  0  0 m
>
> colour map-fg [80 89 94]
> #colour map-bg [20 39 14]
>
> code metapost
> def s_scalebar (expr l, units, txt) =
>   begingroup
> interim warningcheck:=0;
> tmpl:=l / Scale * cm * units / 2;
> tmpx:=l / Scale * cm * units / 5;
> tmph:=5bp; % bar height
>   endgroup;
>   pickup PenC;
>   draw (-tmpl,0)--(tmpl,0)--(tmpl,-tmph)--(-tmpl,-tmph)--cycle;
>   p:=(0,0)--(tmpx,0)--(tmpx,-tmph)--(0,-tmph)--cycle;
>   for i:=-2.5 step 2 until 2:
> fill p shifted (i * tmpx,0);
>   endfor;
>   begingroup
> interim labeloffset:=3.5bp;
> for i:=0 step (l/5) 

Re: [Therion] Survex splays flag in Therion

[Martin Budaj]

On Wed, Sep 22, 2021 at 9:40 AM Rodrigo Severo via Therion <
therion@speleo.sk> wrote:

> Dear developers, please consider including it in Therion source.
>

Sure, included.
Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Therion 6.0.1 colour processing problem

[Martin Budaj]

Hi,

the latest commit to Master adds compatibility macros so that the old-style
transparency definitions are supported again.

M.

On Mon, Aug 23, 2021 at 9:10 PM Martin Budaj  wrote:

> Hi,
>
> if really needed, windows installer for 5.5.7 could be compiled (we don't
> store old installers on the server; installers for releases starting with
> 6.0.0 are stored on Github). But I suggest that it's better to fix the data
> than to stick with an old version of the software which won't get any fixes
> in the future.
>
> The required changes to symbol definitions are simple:
>
> - delete all occurences of 'def_transparent_rgb' macro with its argument,
> e.g.
> def_transparent_rgb(tr_lgrey, 0.73, 0.71, 0.75);
>
> - replace all occurences of 'withtransparentcolor' and its argument with
> 'withalpha' + color and alpha values, e.g.
>thfill P withtransparentcolor tr_lgrey;
>should be changed to
>thfill P withcolor (0.73, 0.71, 0.75) withalpha 0.7;
>
> If there is still a problem processing your data, please send me (or to
> the list) an example and the corresponding log file.
>
> Cheers
> Martin
>
>
>
>
> On Sun, Aug 22, 2021 at 10:44 PM A.M. van Rosmalen <
> a.m.vanrosma...@gmx.net> wrote:
>
>> Thank you for your answer Martin!
>>
>> Where can I find the installer of a previous version of Therion?
>>
>> The latest version undoubtedly is absolutely awesome, but it also messes
>> up my maps and two days of trying just convinced me I'm simply too
>> uninterested in new features or too stupid to fix something that wasn't
>> broken to begin with.
>>
>> Cheers,
>>
>> Anton
>>
>>
>> Op za 21 aug. 2021 om 18:37 schreef Martin Budaj 
>>
>>> Hi,
>>>
>>> the problem is caused by an incompatible change in transparent colours
>>> handling introduced in 6.0.0 (see
>>> https://github.com/therion/therion/blob/master/CHANGES):
>>>
>>> incompatible changes: the drawing option 'withtransparentcolor',
>>> macro 'def_transparent_rgb' and predefined transparent colors tr_bg,
>>> tr_white, tr_black were removed;
>>> use the drawing option 'withcolor  withalpha ' instead
>>>
>>> This allows you to use transparency without defining transparent colours
>>> in advance, but you need to rewrite your metapost definitions.
>>>
>>> The issue on page 57 mentioned by Bruce is not related to this change
>>> (I'll add a clarification to the thbook).
>>>
>>> Martin
>>>
>>> On Sat, Aug 21, 2021 at 10:57 AM Bruce Mutton  wrote:
>>>
>>>> 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

Re: [Therion] Linux xtherion will not load thconfig

[Martin Budaj]

On Wed, Aug 25, 2021 at 6:05 PM Wookey  wrote:

> There is a bug in xtherion 5.5.7, at least in the debian build I am
> using (therion 5.5.7ds1-2).
>
> If you try to open a thconfig file, you get an error:
>
> "thconfig.thcfg does not exist".
>
> Fortunately you can run 'xtherion thconfig' and that works, otherwise
> xtherion would be completely broken unless you renamed all your thconfig
> files.


There is a workaround, though. If you change 'Files of type:' to 'All files
(*)' in the Open dialog, opening the 'thconfig' file works.


> This seems a fairly fundamental bug - I'm surprised it's not come
> up before.


I'm quite sure it used to work some time ago and there was no change in
xtherion source in this respect, so I guess something had to change in the
tcl/tk library in Debian. The version of tcl/tk used for the windows
installer doesn't have this bug.


> This is now in the version in Debian stable, so people will
> be getting it for the next 2 years, which is somewhat embarassing.
> Hopefully we can declare it bad enough to get a fix in.
>

Or backport 6.0.2+ ;)


> I've not looked into the code yet for a fix, but can someone confirm
> this is not just me?
>

 Confirmed. Stacho has already fixed it in the master branch.

M.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Therion 6.0.1 colour processing problem

[Martin Budaj]

Hi,

if really needed, windows installer for 5.5.7 could be compiled (we don't
store old installers on the server; installers for releases starting with
6.0.0 are stored on Github). But I suggest that it's better to fix the data
than to stick with an old version of the software which won't get any fixes
in the future.

The required changes to symbol definitions are simple:

- delete all occurences of 'def_transparent_rgb' macro with its argument,
e.g.
def_transparent_rgb(tr_lgrey, 0.73, 0.71, 0.75);

- replace all occurences of 'withtransparentcolor' and its argument with
'withalpha' + color and alpha values, e.g.
   thfill P withtransparentcolor tr_lgrey;
   should be changed to
   thfill P withcolor (0.73, 0.71, 0.75) withalpha 0.7;

If there is still a problem processing your data, please send me (or to the
list) an example and the corresponding log file.

Cheers
Martin




On Sun, Aug 22, 2021 at 10:44 PM A.M. van Rosmalen 
wrote:

> Thank you for your answer Martin!
>
> Where can I find the installer of a previous version of Therion?
>
> The latest version undoubtedly is absolutely awesome, but it also messes
> up my maps and two days of trying just convinced me I'm simply too
> uninterested in new features or too stupid to fix something that wasn't
> broken to begin with.
>
> Cheers,
>
> Anton
>
>
> Op za 21 aug. 2021 om 18:37 schreef Martin Budaj 
>
>> Hi,
>>
>> the problem is caused by an incompatible change in transparent colours
>> handling introduced in 6.0.0 (see
>> https://github.com/therion/therion/blob/master/CHANGES):
>>
>> incompatible changes: the drawing option 'withtransparentcolor',
>> macro 'def_transparent_rgb' and predefined transparent colors tr_bg,
>> tr_white, tr_black were removed;
>> use the drawing option 'withcolor  withalpha ' instead
>>
>> This allows you to use transparency without defining transparent colours
>> in advance, but you need to rewrite your metapost definitions.
>>
>> The issue on page 57 mentioned by Bruce is not related to this change
>> (I'll add a clarification to the thbook).
>>
>> Martin
>>
>> On Sat, Aug 21, 2021 at 10:57 AM Bruce Mutton  wrote:
>>
>>> 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

Re: [Therion] Therion 6.0.1 colour processing problem

[Martin Budaj]

Hi,

the problem is caused by an incompatible change in transparent colours
handling introduced in 6.0.0 (see
https://github.com/therion/therion/blob/master/CHANGES):

incompatible changes: the drawing option 'withtransparentcolor',
macro 'def_transparent_rgb' and predefined transparent colors tr_bg,
tr_white, tr_black were removed;
use the drawing option 'withcolor  withalpha ' instead

This allows you to use transparency without defining transparent colours in
advance, but you need to rewrite your metapost definitions.

The issue on page 57 mentioned by Bruce is not related to this change (I'll
add a clarification to the thbook).

Martin

On Sat, Aug 21, 2021 at 10:57 AM Bruce Mutton  wrote:

> 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] Colour legend labels poorly aligned if more than single line

[Martin Budaj]

On Sat, Aug 21, 2021 at 12:50 AM Bruce Mutton  wrote:

> *map header title*
>
> The text over writes the north arrow, although that is consistent with
> what happened before (possible that this is an artifact of my customisation
> however).
>
>
Thanks Bruce for testing the modifications.  Collision with the north arrow
was present all the time; it's fixed in the latest commit.


> Something that is happening with map header title that does not happen
> with automatic line breaks elsewhere is a heavy black | character.  I
> recall something like this was an issue long ago.  Is it a newline
> character rendering inappropriately?
>

This is a TeX way to mark overfull lines. It can be switched off, but it's
good to have it activated to point you to problematic line breaks. But now
it should show up much more rarely, as the recent commit uses left instead
of block justification for the map title, which allows for more
flexible line breaks.

M.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Colour legend labels poorly aligned if more than single line

[Martin Budaj]

On Thu, Aug 19, 2021 at 10:59 AM Bruce Mutton  wrote:

> The relative position of map header title is changed relative to the north
> arrow – probably not ideal as it will change existing projects.
>

Hi, this should be fixed in af88db0
.
But there was another bug in the map header title, where line spacing of a
long title broken to multiple lines (without using ) was too tight.
I've fixed that, too, but this will definitely change the appearance of
long map titles.


> Forcing the symbol legend to fit in too narrow a space gives an acceptable
> result.
>
> I have not tried an explicit newline  but expect it would give a
> similar result.
>

Not really, any text containing  is converted to a TeX table and thus
processed very differently.

Cheers
Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Plan gridline colour changes unpredictably

[Martin Budaj]

If you can reproduce random colours with a new or old therion build you can
send me some testing data. Otherwise you can send me some old PDF files
with good and wrong colours.

M.

On Wed, Aug 11, 2021 at 9:16 PM Bruce Mutton  wrote:

> 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  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
> https://mailman.speleo.sk/listinfo/therion
>
> ___
> 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] Install on Mac OS 11.4

[Martin Budaj]

On Wed, Aug 11, 2021 at 7:46 PM Andrea Corna via Therion 
wrote:

> Thank you Martin,
> Following the link I compiled correctly. Therion and Lock are working.
> But I can’t find xtherion..
> What I have missed?
>

Ah, xtherion is omitted in macOS build. You can run
   cmake --build build -t xtherion/xtherion
to generate it.

Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Install on Mac OS 11.4

[Martin Budaj]

Hi,

could you follow the macOS part of
https://github.com/therion/therion/blob/master/.github/workflows/cmake.yml
and if there is a problem include a more detailed log file?

Basically you need to run the following in the therion source directory:

mkdir build && cd build && cmake -G Ninja -DCMAKE_CXX_FLAGS="-Werror"
-DOPENGL_gl_LIBRARY:FILEPATH=/opt/X11/lib/libGL.dylib
-DOPENGL_glu_LIBRARY:FILEPATH=/opt/X11/lib/libGLU.dylib -DBUILD_THBOOK=OFF
..
cmake --build build -t therion loch utest

We use macOS 11.5 and 10.15.7 to build therion while testing.

Cheers
Martin


On Thu, Aug 5, 2021 at 8:42 AM Andrea Corna via Therion 
wrote:

> Hi Phil,
> Is an intel version.
>
> Andrea da iPhone
>
> Il giorno 4 ago 2021, alle ore 23:58, Philippe Vernant <
> phil.vern...@gmail.com> ha scritto:
>
> Hi Andrea,
>
> Do you have a new Mac with the M1 chip ? If so you might want to install
> Rosetta first.
>
> Best,
> Phil
>
>
> On 4 Aug 2021, at 22:20, Andrea Corna via Therion 
> wrote:
>
> Hi Guys,
> I’m trying ti install on Mac OS 11.4 but I’m failing.
> Following this https://therion.speleo.sk/wiki/os-tips:osx it fail
> Compiling fron GitHub also fail:
>
> ld: symbol(s) not found for architecture x86_64
> clang: *error: *linker command failed with exit code 1 (use -v to see
> invocation)
> make[1]: *** [loch] Error 1
> make: *** [loch/loch] Error 2
>
> Anyone is able to install?
>
> Thanks for help
>
> Andrea
> ___
> 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 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] Plan gridline colour changes unpredictably

[Martin Budaj]

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  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
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Therion 6.0.0 altitude colour legend feedback

[Martin Budaj]

On Mon, Jul 19, 2021 at 12:08 PM Bruce Mutton  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
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Therion 6.0.0 altitude colour legend feedback

[Martin Budaj]

On Mon, Jul 19, 2021 at 12:08 PM Bruce Mutton  wrote:

> >Is it possible to scale the length of the bar based on the number of
> altitudes so that it fits the standard variable module length used for
> other colour legends?
>
> >>this has been implemented in 9a30b34
> .
>
>
> This is working I think – yet to test with all projects.
>
> > I tried using the ‘smooth-shading off’ option in the hope that the
> altitude legend format would revert to the old style, but there is no
> difference; it comes out the same as if ‘smooth-shading quick’ is set.
>
> >>This is intended, because even if you don't use smooth shading for
> scraps, most of the scraps colored by altitude get colors which are not
> found on the old-style discrete color legend. So a smooth color legend
> should be useful. Do you see a use case for having a discrete legend in
> this case?
>
>
>
> I’m not sure.  I am undecided as to whether I would prefer independent
> control of the colour-legend style (user specifies smoothed if Therion can
> do it, or specifies discrete regardless of whether Therion can do smoothed
> or not).  The current implementation seems to decide automatically,
> depending on the type of lookup (for example banded gives discrete,
> otherwise it is smoothed).  Probably I would prefer independent control.
> Especially as the discrete style is used for all only most altitude map-fg
> / lookups and for all other map-fg / lookups.
>

Agree, independent control offers the best control. The color-legend
keyword will be expanded to support on/off/smooth/discrete (on = auto).


> My tentative comments:
>
>
>1. 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).
>
> It indeed looks like a bug. Could you send me the data to reproduce it?


>
>1. The old version (5.5.7) works better with banded colours as 6.0.0
>did not shade it as I would like.  It will probably be OK with smooth
>shading off – didn’t get around to checking that yet.
>
> Maybe the effect you don't like is that only a part of any scrap within
the bounds of the band is coloured (not the whole scrap) when smooth
shading is used.
For highlighting particular passages probably a special area symbol filled
with a colour (or different colours based on the ATTR__scrap value) is
better suited than altitude bands.

Cheers
Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] GitHub Windows installer

[Martin Budaj]

On Thu, Jul 15, 2021 at 9:31 PM Bruce Mutton  wrote:

> > 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.
>

OK, let's 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
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Problem when compiling on MacOS

[Martin Budaj]

Hi,
using cmake instead of make for compilation should help with the issues
related to linking to the external libraries.
M.


On Tue, Jun 22, 2021, 19:30 Philippe Vernant  wrote:

> Hi Martin,
>
> It worked ok for xtherion with the latest commit in the master branch. I
> just have to deal with a vtkHybrid library that doesn’t seems to exist for
> VTK8 or VTK9 releases and I will also have loch.
>
> Thanks a lot for your help !
> Phil
>
>
> > On 18 Jun 2021, at 18:33, Martin Budaj  wrote:
> >
> > Hi,
> >
> > try to compile the latest commit in the master branch, which contains
> > the updated Catch2 library – not sure if the issue has been fixed,
> > though.
> > You can also use cmake to link to the system Catch2 library (details
> > on cmake compilation are in the thbook).
> >
> > Martin
> >
> > On Thu, Jun 17, 2021 at 10:51 PM Philippe Vernant
> >  wrote:
> >>
> >> Hi guys,
> >>
> >> Has anyone been successful compiling xtherion on a Mac with the M1 chip
> and Big Sur ? I can compile and run therion but I have the following error
> message and fail to compile xtherion :
> >>
> >> extern/catch2/catch.hpp:8205:13: error: unrecognized instruction
> mnemonic, did you mean: bit, cnt, hint, ins, not?
> >>CATCH_BREAK_INTO_DEBUGGER();
> >>^
> >> extern/catch2/catch.hpp:7916:83: note: expanded from macro
> 'CATCH_BREAK_INTO_DEBUGGER'
> >>#define CATCH_BREAK_INTO_DEBUGGER() []{ if(
> Catch::isDebuggerActive() ) { CATCH_TRAP(); } }()
> >>
>   ^
> >> extern/catch2/catch.hpp:7881:34: note: expanded from macro 'CATCH_TRAP'
> >>#define CATCH_TRAP() __asm__("int $3\n" : : ) /* NOLINT */
> >> ^
> >> :1:2: note: instantiated into assembly here
> >>int $3
> >>^
> >> 1 error generated.
> >> make: *** [utest-main.o] Error 1
> >>
> >> Thanks,
> >> Phil
> >>
> >> ___
> >> 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 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] Adding a creative common image to each page of an atlas

[Martin Budaj]

Hi,
I'm afraid this is hardcoded in therion's c++ code which generates
auxiliary tex files.
As a workaround, you could perhaps add \formattedlegend at the
beginning of the \insertmaps macro. (You would get the legend twice:
before and after the maps.)
M.

On Thu, Jun 17, 2021 at 11:52 AM Philippe Vernant
 wrote:
>
> Hi Martin,
>
> Thanks, that helped me a lot, I now have the image on each page of the atlas. 
> I have also been able to find the \def\atlastitlepages in the therion.tex 
> file and modify it to get the title and the survey team etc. on the same 
> page. But the TeX learning curve is steep and I cannot find a way to have the 
> legend with the symbol on the same first page rather than at the end of the 
> atlas. Any clue on which part I should play with to have the legend before 
> the maps ?
>
> Thanks,
> Phil
>
>
> > On 16 Jun 2021, at 21:35, Martin Budaj  wrote:
> >
> > Hi,
> >
> > you need to use
> >
> >\hbox to 0pt{\hss\the\topoteam\qquad}
> >
> > In your example you assign a new value "Name" to \topoteam, as
> > \topoteam{Name} is equivalent to \topoteam={Name}.
> > In addition, \the is needed to display the value of this register.
> >
> > M.
> >
> > On Wed, Jun 16, 2021 at 12:02 AM Philippe Vernant
> >  wrote:
> >>
> >> Thanks Martin it works like a charm. I have the 5.5.7 thbook but there was 
> >> nothing on \loadpicture.
> >>
> >> Trying to add a few things, I added the following line in your block :
> >>\hbox to 0pt{\hss\topoteam{Name}\qquad}
> >>
> >> But I don’t see “Name” on the atlas pages, what am I missing?
> >>
> >> Phil
> >>
> >>
> >>> On 15 Jun 2021, at 17:44, Martin Budaj  wrote:
> >>>
> >>> Hi,
> >>>
> >>> you can e.g. modify this part of the macro:
> >>>
> >>>   \vbox to \ht\navbox{
> >>> \ifnortharrow\hbox to 0pt{\hss\northarrow\qquad}\fi
> >>> \vss
> >>> \ifscalebar\hbox to 0pt{\hss\scalebar\qquad}\fi
> >>>   }
> >>>
> >>> to
> >>>
> >>>   \vbox to \ht\navbox{
> >>> \ifnortharrow\hbox to 0pt{\hss\northarrow\qquad}\fi
> >>> \vss
> >>> \ifscalebar\hbox to 0pt{\hss\scalebar\qquad}\fi
> >>> \vss
> >>> \hbox to 0pt{\hss\loadpicture{picture.pdf}\qquad}
> >>>   }
> >>>
> >>> which will put the picture.pdf below the scale bar. Currently
> >>> \loadpicture doesn't support scaling images, so you need to prepare it
> >>> in the right size beforehand.
> >>>
> >>> You also need to use a development version of therion if you want to
> >>> use relative paths to pictures. See also the description of
> >>> \loadpicture in https://therion.speleo.sk/downloads/thbook.pdf, page
> >>> 73.
> >>>
> >>> Cheers
> >>> Martin
> >>>
> >>>
> >>> On Tue, Jun 15, 2021 at 2:59 PM Philippe Vernant  
> >>> wrote:
> >>>>
> >>>> Hi Martin,
> >>>>
> >>>> I’ve tried, but could not figure it out where I should add a command in 
> >>>> the “dopage” macro and which command I should add to include a figure. 
> >>>> Any example that I could work on an modify would be greatly appreciated.
> >>>>
> >>>> Thanks,
> >>>> Phil
> >>>>
> >>>>
> >>>> On 12 Jun 2021, at 19:39, Martin Budaj  wrote:
> >>>>
> >>>> Hi,
> >>>> you need to redefine the '\dopage' macro; check the pages 70 and 71 in 
> >>>> the thbook. Let me know if more specific advice is needed.
> >>>> M.
> >>>>
> >>>> On Fri, Jun 11, 2021 at 3:27 PM Philippe Vernant 
> >>>>  wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I tried several lines of code, but couldn’t success in adding a 
> >>>>> creative common image on each page of an atlas. I guess this is 
> >>>>> possible and I’m just too bad at metapost code to be successful. Has 
> >>>>> anyone a recipe to make it work ? I’ve managed to make it on a map, but 
> >>>>> not on an atlas.
> >>>>>
> >>>>> Thanks,
> >>>>> Phil
> >>>>>
> >>>>> ___
> >>>>> 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 mailing list
> >>>> Therion@speleo.sk
> >>>> https://mailman.speleo.sk/listinfo/therion
> >>> ___
> >>> 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 mailing list
> > Therion@speleo.sk
> > https://mailman.speleo.sk/listinfo/therion
>
> ___
> 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] Problem when compiling on MacOS

[Martin Budaj]

Hi,

try to compile the latest commit in the master branch, which contains
the updated Catch2 library – not sure if the issue has been fixed,
though.
You can also use cmake to link to the system Catch2 library (details
on cmake compilation are in the thbook).

Martin

On Thu, Jun 17, 2021 at 10:51 PM Philippe Vernant
 wrote:
>
> Hi guys,
>
> Has anyone been successful compiling xtherion on a Mac with the M1 chip and 
> Big Sur ? I can compile and run therion but I have the following error 
> message and fail to compile xtherion :
>
> extern/catch2/catch.hpp:8205:13: error: unrecognized instruction mnemonic, 
> did you mean: bit, cnt, hint, ins, not?
> CATCH_BREAK_INTO_DEBUGGER();
> ^
> extern/catch2/catch.hpp:7916:83: note: expanded from macro 
> 'CATCH_BREAK_INTO_DEBUGGER'
> #define CATCH_BREAK_INTO_DEBUGGER() []{ if( Catch::isDebuggerActive() 
> ) { CATCH_TRAP(); } }()
>   
> ^
> extern/catch2/catch.hpp:7881:34: note: expanded from macro 'CATCH_TRAP'
> #define CATCH_TRAP() __asm__("int $3\n" : : ) /* NOLINT */
>  ^
> :1:2: note: instantiated into assembly here
> int $3
> ^
> 1 error generated.
> make: *** [utest-main.o] Error 1
>
> Thanks,
> Phil
>
> ___
> 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] Adding a creative common image to each page of an atlas

[Martin Budaj]

Hi,

you need to use

\hbox to 0pt{\hss\the\topoteam\qquad}

In your example you assign a new value "Name" to \topoteam, as
\topoteam{Name} is equivalent to \topoteam={Name}.
In addition, \the is needed to display the value of this register.

M.

On Wed, Jun 16, 2021 at 12:02 AM Philippe Vernant
 wrote:
>
> Thanks Martin it works like a charm. I have the 5.5.7 thbook but there was 
> nothing on \loadpicture.
>
> Trying to add a few things, I added the following line in your block :
> \hbox to 0pt{\hss\topoteam{Name}\qquad}
>
> But I don’t see “Name” on the atlas pages, what am I missing?
>
> Phil
>
>
> > On 15 Jun 2021, at 17:44, Martin Budaj  wrote:
> >
> > Hi,
> >
> > you can e.g. modify this part of the macro:
> >
> >\vbox to \ht\navbox{
> >  \ifnortharrow\hbox to 0pt{\hss\northarrow\qquad}\fi
> >  \vss
> >  \ifscalebar\hbox to 0pt{\hss\scalebar\qquad}\fi
> >}
> >
> > to
> >
> >\vbox to \ht\navbox{
> >  \ifnortharrow\hbox to 0pt{\hss\northarrow\qquad}\fi
> >  \vss
> >  \ifscalebar\hbox to 0pt{\hss\scalebar\qquad}\fi
> >  \vss
> >  \hbox to 0pt{\hss\loadpicture{picture.pdf}\qquad}
> >}
> >
> > which will put the picture.pdf below the scale bar. Currently
> > \loadpicture doesn't support scaling images, so you need to prepare it
> > in the right size beforehand.
> >
> > You also need to use a development version of therion if you want to
> > use relative paths to pictures. See also the description of
> > \loadpicture in https://therion.speleo.sk/downloads/thbook.pdf, page
> > 73.
> >
> > Cheers
> > Martin
> >
> >
> > On Tue, Jun 15, 2021 at 2:59 PM Philippe Vernant  
> > wrote:
> >>
> >> Hi Martin,
> >>
> >> I’ve tried, but could not figure it out where I should add a command in 
> >> the “dopage” macro and which command I should add to include a figure. Any 
> >> example that I could work on an modify would be greatly appreciated.
> >>
> >> Thanks,
> >> Phil
> >>
> >>
> >> On 12 Jun 2021, at 19:39, Martin Budaj  wrote:
> >>
> >> Hi,
> >> you need to redefine the '\dopage' macro; check the pages 70 and 71 in the 
> >> thbook. Let me know if more specific advice is needed.
> >> M.
> >>
> >> On Fri, Jun 11, 2021 at 3:27 PM Philippe Vernant  
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I tried several lines of code, but couldn’t success in adding a creative 
> >>> common image on each page of an atlas. I guess this is possible and I’m 
> >>> just too bad at metapost code to be successful. Has anyone a recipe to 
> >>> make it work ? I’ve managed to make it on a map, but not on an atlas.
> >>>
> >>> Thanks,
> >>> Phil
> >>>
> >>> ___
> >>> 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 mailing list
> >> Therion@speleo.sk
> >> https://mailman.speleo.sk/listinfo/therion
> > ___
> > 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 mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Adding a creative common image to each page of an atlas

[Martin Budaj]

Hi,

you can e.g. modify this part of the macro:

\vbox to \ht\navbox{
  \ifnortharrow\hbox to 0pt{\hss\northarrow\qquad}\fi
  \vss
  \ifscalebar\hbox to 0pt{\hss\scalebar\qquad}\fi
}

to

\vbox to \ht\navbox{
  \ifnortharrow\hbox to 0pt{\hss\northarrow\qquad}\fi
  \vss
  \ifscalebar\hbox to 0pt{\hss\scalebar\qquad}\fi
  \vss
  \hbox to 0pt{\hss\loadpicture{picture.pdf}\qquad}
}

which will put the picture.pdf below the scale bar. Currently
\loadpicture doesn't support scaling images, so you need to prepare it
in the right size beforehand.

You also need to use a development version of therion if you want to
use relative paths to pictures. See also the description of
\loadpicture in https://therion.speleo.sk/downloads/thbook.pdf, page
73.

Cheers
Martin


On Tue, Jun 15, 2021 at 2:59 PM Philippe Vernant  wrote:
>
> Hi Martin,
>
> I’ve tried, but could not figure it out where I should add a command in the 
> “dopage” macro and which command I should add to include a figure. Any 
> example that I could work on an modify would be greatly appreciated.
>
> Thanks,
> Phil
>
>
> On 12 Jun 2021, at 19:39, Martin Budaj  wrote:
>
> Hi,
> you need to redefine the '\dopage' macro; check the pages 70 and 71 in the 
> thbook. Let me know if more specific advice is needed.
> M.
>
> On Fri, Jun 11, 2021 at 3:27 PM Philippe Vernant  
> wrote:
>>
>> Hi,
>>
>> I tried several lines of code, but couldn’t success in adding a creative 
>> common image on each page of an atlas. I guess this is possible and I’m just 
>> too bad at metapost code to be successful. Has anyone a recipe to make it 
>> work ? I’ve managed to make it on a map, but not on an atlas.
>>
>> Thanks,
>> Phil
>>
>> ___
>> 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 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] Adding a creative common image to each page of an atlas

[Martin Budaj]

Hi,
you need to redefine the '\dopage' macro; check the pages 70 and 71 in the
thbook. Let me know if more specific advice is needed.
M.

On Fri, Jun 11, 2021 at 3:27 PM Philippe Vernant 
wrote:

> Hi,
>
> I tried several lines of code, but couldn’t success in adding a creative
> common image on each page of an atlas. I guess this is possible and I’m
> just too bad at metapost code to be successful. Has anyone a recipe to make
> it work ? I’ve managed to make it on a map, but not on an atlas.
>
> Thanks,
> Phil
>
> ___
> 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] pdftex error introduced after c43b32a (2021-03-08)

[Martin Budaj]

Hi Bruce,

I guess it's related to one of the changes, although I couldn't reproduce
it on my data. Could you please send me all *.tex files from the thTMPDIR
when you run Therion in the debug mode on the problematic dataset?

Martin

On Sun, Apr 25, 2021 at 7:39 AM Bruce Mutton  wrote:

> 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 mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Metapost / Tex error when compiling my projects on a new machine

[Martin Budaj]

Hi,

it looks exactly like https://github.com/therion/therion/issues/339

Although it hasn't been solved yet, maybe the log files from your system
could help; could you generate them according to the discussion there?

Best regards
Martin

On Wed, Apr 7, 2021 at 9:46 AM Tom Foord  wrote:

> Hi everyone
>
> I'm hoping someone can shed some light on a weird error I'm getting when
> attempting to compile my projects on a new PC.
> All of my projects are stored on Dropbox and are compiling successfully on
> other machines.
> But on my new laptop (a Dell Inspiron running Windows 10 with a fresh
> install of Therion 5.5.7) I am getting the same error every time, across
> all projects. It appears to be some issue with Metapost and/or Tex (neither
> of which I really understand to be honest). Here's the relevant bit of the
> log:
>
> ### metapost log file 
> This is MetaPost, version 2.00 (TeX Live 2020/W32TeX) (kpathsea version
> 6.3.2)  7 APR 2021 08:23
> **data.mp
> (c:/Program Files (x86)/Therion/texmf/mpost/mpost.mp
> (c:/Program Files (x86)/Therion/texmf/mpost/plain.mp
> Preloading the plain mem file, version 1.005) ) (./data.mp
> {randomseed:=42}
>  [4001] [4002] [4003] [4004] [4005] [4006] [4007] [4008] [4009] [4010]
> [4011] [
> 4012] [4013] [4014]
> [4015] [4016] [4017] [4018] [4019] [1] [2] [3]
> >> data.mp
> >> data.mpx
> ! ! Unable to read mpx file.
> l.7129 p_label.rt(btex
>\thlabel\thnormalsize \thfb\char99 \char104
> \char111 ...
> The two files given above are one of your source files
> and an auxiliary file I need to read to find out what your
> btex..etex blocks mean. If you don't know why I had trouble,
> try running it manually through MPtoTeX, TeX, and DVItoMP
>
>
>
> Here is how much of MetaPost's memory you used:
>  2803 strings using 61450 characters
>  2313328 bytes of node memory
>  1659 symbolic tokens
>  8i,82n,13p,312b,2f stack positions out of 16i,98n,15p,312b,4f22 output
> files written: data.1 .. data.4019
>
>
>  end of metapost log file 
> C:\Program Files (x86)\Therion\therion.exe: error -- metapost exit code --
> 3
> writing xtherion file ... done
>
>
>
> Any ideas?
>
> Thanks
> Tom Foord
> ___
> 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] 3D model height

[Martin Budaj]

Hi,

Proj 4 and 5 uses a different conversion than Proj 6+ resulting in the
height difference.

Actually, the behaviour of Therion was inconsistent: when doing internal
conversions it transformed only x and y coordinates, but when creating e.g.
KML output it transformed all x, y and z coordinates. The latest commit
(b6bcc92) unifies this to converting just x and y for all coordinate
systems transformations.

If there is a real need for a switch between converting and not converting
the heights, let us know.

Martin

On Fri, Feb 19, 2021 at 8:41 PM Balambér Hakapesz 
wrote:

> therion 5.5.7+0df52bd+dev (2021-02-18)
>   - using Proj 5.1.0, compiled against 5.1.0
>
> On Fri, Feb 19, 2021 at 8:40 PM Balambér Hakapesz 
> wrote:
>
>> latest Therion 5.5.7 (now install):
>>
>> 
>> 19.00961011626948,47.52649337576408,*291*.08568208824045
>> 19.00961011450532,47.52649337534078,281.08568208855468
>> 19.00962225574169,47.52658294585592,281.08562306819113
>> 19.00975449765885,47.5265747689,281.08549506128293
>> 
>>
>> On Fri, Feb 19, 2021 at 8:19 PM Martin Budaj  wrote:
>>
>>> Hi,
>>>
>>> which version of Therion and Proj are you using? I get
>>> 19.00961002698361,47.52649340144701,262.00
>>> in the kml export with the latest Therion and Proj 7.2.1
>>>
>>> Best wishes
>>> Martin
>>>
>>> On Fri, Feb 19, 2021 at 11:25 AM Balambér Hakapesz <
>>> holl.balaz...@gmail.com> wrote:
>>>
>>>> thconfig:
>>>> #cs long-lat
>>>> #fix 0 19.009617 47.526453 262
>>>> cs EPSG:23700   # Hungarian EOV
>>>> fix 0 647151 242509 262
>>>>
>>>> kml:
>>>> 
>>>> 19.00961011626948,47.52649337576407,291.08568208889801
>>>>
>>>> 291-262 = 29 m = 44m geoid height - 15m Proj4 error
>>>>
>>>>
>>>>
>>>> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>>>>  Mentes
>>>> a vírusoktól. www.avg.com
>>>> <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>>>> <#m_1264032343771874480_m_-3468513418640853693_m_2109412960721514408_m_-5536043658431662593_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>>
>>>> On Fri, Feb 19, 2021 at 11:06 AM Benedikt Hallinger 
>>>> wrote:
>>>>
>>>>> Isn't EGM84 the reference ellipsoid currently used by WGS84?
>>>>> What you get with GPS is *not* sea level, but the altitude above that
>>>>> reference geoid (which takes into account gravital anonalys).
>>>>>
>>>>> If you calibrate your barometric altimeter to the hieght given by a
>>>>> height coordinate of WGS84 (like read from your car's navi at the
>>>>> parking lot, or from a map calibrated to WGS84) then you should get
>>>>> about the same altitude.
>>>>> If you take the cave location from GPS and enter that coordinates into
>>>>> the therion dataset wirh correct "cs" marking, the conversion should
>>>>> yield the correct result.
>>>>> If you take the altitude from a map (or an altimeter calibrated to
>>>>> that
>>>>> map) in another coordinate system, you have to either apply an offset
>>>>> manually, add an instrument correction factor in therion, or supply
>>>>> the
>>>>> correct coordinate system (which then probalby demands conversion of
>>>>> the
>>>>> lat/lon coordinates).
>>>>>
>>>>> If generating 3D surfce meshes, you also need to supply matching
>>>>> coordinate systems data and/or specify the correct "cs" parameter.
>>>>>
>>>>> I think your problem comes from mixing coordinate systems in respect
>>>>> to
>>>>> the height model, either at data input or when using the height mesh.
>>>>>
>>>>>
>>>>> Am 2021-02-19 9:49, schrieb Balambér Hakapesz:
>>>>> > Very rarely can anyone work at ellipsoidal heights. In local
>>>>> > coordinate systems, it only makes sense for upper geodetic
>>>>> > calculations. Only for GPS measurements we get an ellipsoidal
>>>>> > altitude, even there the devices can immediately calculate the
>>>>> > altitude of the EGM96 model with an altitude above sea level (with a
>>>>>

Re: [Therion] 3D model height

[Martin Budaj]

Hi,

which version of Therion and Proj are you using? I get
19.00961002698361,47.52649340144701,262.00
in the kml export with the latest Therion and Proj 7.2.1

Best wishes
Martin

On Fri, Feb 19, 2021 at 11:25 AM Balambér Hakapesz 
wrote:

> thconfig:
> #cs long-lat
> #fix 0 19.009617 47.526453 262
> cs EPSG:23700   # Hungarian EOV
> fix 0 647151 242509 262
>
> kml:
> 
> 19.00961011626948,47.52649337576407,291.08568208889801
>
> 291-262 = 29 m = 44m geoid height - 15m Proj4 error
>
>
>
> 
>  Mentes
> a vírusoktól. www.avg.com
> 
> <#m_-5536043658431662593_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Fri, Feb 19, 2021 at 11:06 AM Benedikt Hallinger 
> wrote:
>
>> Isn't EGM84 the reference ellipsoid currently used by WGS84?
>> What you get with GPS is *not* sea level, but the altitude above that
>> reference geoid (which takes into account gravital anonalys).
>>
>> If you calibrate your barometric altimeter to the hieght given by a
>> height coordinate of WGS84 (like read from your car's navi at the
>> parking lot, or from a map calibrated to WGS84) then you should get
>> about the same altitude.
>> If you take the cave location from GPS and enter that coordinates into
>> the therion dataset wirh correct "cs" marking, the conversion should
>> yield the correct result.
>> If you take the altitude from a map (or an altimeter calibrated to that
>> map) in another coordinate system, you have to either apply an offset
>> manually, add an instrument correction factor in therion, or supply the
>> correct coordinate system (which then probalby demands conversion of the
>> lat/lon coordinates).
>>
>> If generating 3D surfce meshes, you also need to supply matching
>> coordinate systems data and/or specify the correct "cs" parameter.
>>
>> I think your problem comes from mixing coordinate systems in respect to
>> the height model, either at data input or when using the height mesh.
>>
>>
>> Am 2021-02-19 9:49, schrieb Balambér Hakapesz:
>> > Very rarely can anyone work at ellipsoidal heights. In local
>> > coordinate systems, it only makes sense for upper geodetic
>> > calculations. Only for GPS measurements we get an ellipsoidal
>> > altitude, even there the devices can immediately calculate the
>> > altitude of the EGM96 model with an altitude above sea level (with a
>> > few meters error which is not significant compared to the 15m altitude
>> > error of handheld GPS).
>> > Proj4 calculates the horizontal coordinates well, but there is a
>> > serious error in the height coordinates (for special national
>> > projections
>> > (http://www.agt.bme.hu/gis/workshop4/eloadasok/proj_poszter_3d.pdf)),
>> > so it would be better if not we would count on it but leave the
>> > altitude unchanged.
>> > Could it be an option not to change the height with Therion?
>> >
>> >[2]
>> >   Mentes a vírusoktól. www.avg.com [2]
>> >
>> > On Fri, Feb 19, 2021 at 9:18 AM Benedikt Hallinger
>> >  wrote:
>> >
>> >> Hi there,
>> >> if you measure the altitude with a barometric device, you do not get
>> >> the
>> >> altitude above the ellipsoid. You have to account for that at the
>> >> input
>> >> of your data.
>> >>
>> >> With the "cs" command you define your input data to be in a specific
>> >>
>> >> coordinate system, and also your altitude has to be given in that
>> >> system. If you just put the barometric altitude there (which you
>> >> usually
>> >> did calibrate to a map, didn't you?) you have to transform the
>> >> altitude
>> >> manually if the reference altitude differs.
>> >>
>> >> Am 2021-02-19 8:44, schrieb Balambér Hakapesz:
>> >>> Hi!
>> >>>
>> >>> When generating 3D models, Proj4 transforms between different
>> >>> coordinate systems.
>> >>> This also transforms the ellipsoidal altitude, but the data always
>> >>> refer to altitude above sea level and should not be changed.
>> >>> The finished models do not fit the topography, you have to cheat
>> >> with
>> >>> the height to be good.
>> >>>
>> >>> Balázs Holl.
>> >>>
>> >>> [1]
>> >>> Mentes a vírusoktól. www.avg.com [1] [1]
>> >>>
>> >>>
>> >>>
>> >>> Links:
>> >>> --
>> >>> [1]
>> >>>
>> >>
>> >
>> http://www.avg.com/email-signature?utm_medium=emailutm_source=linkutm_campaign=sig-emailutm_content=webmail
>> >>> ___
>> >>> Therion mailing list
>> >>> Therion@speleo.sk
>> >>> https://mailman.speleo.sk/listinfo/therion
>> >> ___
>> >> Therion mailing list
>> >> Therion@speleo.sk
>> >> https://mailman.speleo.sk/listinfo/therion
>> >
>> >
>> > Links:
>> > --
>> > [1] http://www.avg.com
>> > [2]
>> >
>> http://www.avg.com/email-signature?utm_medium=emailutm_source=linkutm_campaign=sig-emailutm_content=webmail
>> > 

Re: [Therion] "\legendbox" "\loadpicture" and absolute paths

[Martin Budaj]

On Thu, Jan 15, 2015 at 9:59 AM rowena  wrote:

> I am using the “\loadpicture” capability in “\legendbox” constructs to  
> include map sections, elevations, etc.
> It all works nicely on my PC where I am using relative paths to the pdf files.
> My club has a desire to archive the map data for posterity – ie if my pc dies 
> or I go walkabout, the map data should still be available so that others can 
> add to the maps as they are extended.
> I would prefer to have  the images included using relative pathnames, rather 
> than absolute pathnames, so that future explorers can download the map data 
> and extend it, without having to duplicate my file hierarchy.
>
> How can I include relative paths in the \loadpicture  functionality?

Hi,

it took some time, but now \loadpicture supports both relative and
absolute paths. Check out the devel branch (not yet merged to master):

Source: https://github.com/therion/therion/tree/devel
Windows installer:
https://github.com/therion/therion/actions?query=workflow%3AInstaller+branch%3Adevel

Best wishes
Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] specific which label appears in output

[Martin Budaj]

On Sun, Jan 17, 2021 at 8:02 PM Axel  wrote:
> for an overview map I need to specific the labels I want to have in the 
> output. Just sorting them by size is not possible. After searching I found a 
> label re-definition at 
> http://marcocorvi.altervista.org/caving/tbe/m_07/m_072.htm (7.2.10).
>
> Works like a charm in a small cave but taken to my project it behaves odd:
> If I compile, Therion (5.5.6) gives this error (and creates no map):
>   converting scraps ... done
>   making map ... C:\Program Files (x86)\Therion\therion.exe: error -- Can't 
> open file data.8bbox!

Therion expects to find a *bbox file for each scrap containing labels.
It is generated by metapost when the labels are processed. In your
case, you instructed metapost to skip all the labels in a scrap (so no
*bbox file was produced), but therion knows there were some labels
defined for that scrap (if you displayed at least one label in the
scrap, the *bbox file would be generated). The easiest solution is to
create an empty *bbox file if there is none by writing an empty string
to it. Here is a modified Marco's macro:

   vardef p_label@#(expr txt,pos,rot,mode) =
   if known ATTR_visibility:
 if ATTR_visibility="on":  % ADDED CONDITIONS
   if (mode=1) or (mode=7):
 interim labeloffset:=(u/8).
   fi;
   lab:=thelabel@#(txt, pos);
   if mode>1: pickup PenD fi;
   if mode=1: % altitude
 pickup pencircle scaled (u/6);
 drawdot(pos);
 process_label(pos,0);
   elseif mode=2: process_uplabel;% passage height
positive
   elseif mode=3: process_downlabel;  % passage height
negative
   elseif mode=4: process_updownlabel;% passage height both
   elseif mode=5: process_circledlabel;   % passage height
unsigned.
   elseif mode=6: process_boxedlabel;
   elseif mode=7: process_label(pos,rot); % station name
   elseif mode=8: process_filledlabel(pos, rot);
   else:% mode=0 date
 process_label(pos,rot);
   fi;
 else:
   write "" to jobname & "." & decimal(charcode) & "bbox";
 fi;
   else:
 write "" to jobname & "." & decimal(charcode) & "bbox";
   fi;  % END OF CONDITIONS
 enddef;


> However, if I put in the –d command it compiles and produces the warning:
>warning -- cavern exit code – 1
> But it creates a nice map showing the labels I want.

There was surely some old data.8bbox file in the thTMPDIR, as therion
doesn't clean this directory between runs in the debug mode. Check the
timestamps of the files.

Best wishes
Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Therion 5.5.5 bug - statistics missing from header

[Martin Budaj]

Yes, the bug was discovered after the release 5.5.5 was published. We plan
to release 5.5.6 which fixes this bug tomorrow. That should be the version
included in the next Debian stable.
Martin

On Sat, Dec 26, 2020 at 5:24 PM Benedikt Hallinger 
wrote:

> Here Explorers/etc statistics are missing with the debian package, sadly
> :(
>
> Am 2020-12-25 23:07, schrieb Wookey:
> > On 2020-12-23 15:06 +0100, Benedikt Hallinger wrote:
> >> Ok wookey, will check that regarding the glx Patch issue then.
> >>
> >> > Am 23.12.2020 um 14:26 schrieb Wookey :
> >> >
> >> > On 2020-12-23 10:42 +0100, Stacho Mudrak wrote:
> >> >>   I am sorry, one bug fixed, another introduced :/
> >> >>   It should be OK in 5a614ef. Windows binaries should be
> automatically built
> >> >>   within half an hour.
> >> >
> >> > And the Debian packages are now built in unstable. They should move
> into testing in 5 days time.
> >
> > Therion 5.5.5 is now in debian testing (for testing :-)
> > https://tracker.debian.org/pkg/therion
> >
> > Wookey
> > ___
> > 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 mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Gradient out of range - does not process

[Martin Budaj]

On Sat, Dec 19, 2020 at 1:07 PM Andrew Atkinson  wrote:

> > I would hesitate to use magnetic legs for this
> > purpose (there is much uncertainty with the declination as the models
> > are not particularly precise, there is a daily variation of declination
> > (up to 0.2 degrees!) and there might be local magnetic anomalies).
>
> In this case the cave comes out in a valley with little gps signal, the
> position and orientation was set from the 2 gps positions we could get,
> the a traverse to the cave. So I have very little idea how that ties in
> with the declination model. I have been assuming that the direction it
> gave where OS grid as that is the format of the positions, I have no way
> to check this. I have set the declination to 0 to stop date and position
> correction. I think this it right, but advice welcome.


Ah, that was a reaction to some previous remarks in the discussion:

> In places where we haven't been able to get GPS we have used a distox to
set up the leg

and

> I did consider using an approach similar to Andrew’s, ie to calibrate the
Theodolite against a magnetic leg ...

Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Gradient out of range - does not process

[Martin Budaj]

Hi,

>> Theodolites are not really set up for doing traverses, for a loop of a
few hundred metres we have an mis-closure of about 1m.

Yes, theodolites are not really suitable for long traverses where the
angular errors accumulate. When using them it's essential to eliminate all
sources of error, most importantly errors in the instrument position (this
requires forced centering of the instruments, see e.g.
https://books.google.com/books?id=jPVxSDzVRP0C=PA80="centering,+forced;).
Also it is essential to make traverse legs as long as possible when using
theodolite.

Here is a comparison (taken from a surveying textbook by Ryšavý, 1949) of
an error Δ in position of the last point on a traverse of length D, with an
average leg length S, and with a mean angle error α for theodolite and β
for compass (in radians):

Δ_theod ≃ ±α√(D³/(3S))
Δ_compass ≃ ±β√(D·S)

Which gives for e.g. D = 500 m, S = 10 m, α = ±20′′, β = ±3′

Δ_theod ≃ ±20 cm
Δ_compass ≃ ±6 cm

It's easy to check the formulas whether you should expect better results
using a theodolite or a compass depending on the length of traverse legs
and the precision of your instruments.

That’s an interesting anecdote, thanks Andrew. Conversely I had a surveyor
> complete a traverse around my house, a distance of about 60m from about 6
> legs, with a loop closure error of 3mm.


In our case we got a 3.4 cm error on a 95 m loop with 9 legs in a cave.


> So it would be useful to be able to incorporate Theodolite angular
> measurements into the Therion or Survex network with appropriately small
> standard deviations, notwithstanding Andrew’s observation in Wookey, but
> they would have to be treated differently to magnetic bearings.
> Can anyone suggest the mathematical approach for doing that?  Apologies
> that’s very lazy of me to ask!
>

Indeed, they should be treated very differently and something like
https://www.gnu.org/software/gama/ should be integrated to do it properly :(

I did consider using an approach similar to Andrew’s, ie to calibrate the
> Theodolite against a magnetic leg, but intuitively that seems to tie the
> measurement to the inaccuracy of a single leg losing the benefit of error
> reduction across multiple measurements of the magnetic field (which is what
> happens in a magnetic traverse). It feels that somehow we need to use both
> techniques at the same time, using the Theodolite to “lock” the angle
> between legs while using the compass to align the survey to North.
>

You can use a gyrotheodolite to combine both approaches :)

When using theodolite, always use multiple directions for orienting the
survey (shots to multiple distant points with known coordinates, the more
distant the better). I would hesitate to use magnetic legs for this purpose
(there is much uncertainty with the declination as the models are not
particularly precise, there is a daily variation of declination (up to 0.2
degrees!) and there might be local magnetic anomalies).

Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Trouble compiling latest therion code in Linux (Ubuntu 20.04)

[Martin Budaj]

Hi,

compilation on Ubuntu 20.04 works fine in our CI, check
https://github.com/therion/therion/blob/master/.github/workflows/make.yaml
if there are any differences to your setup.

Martin

On Tue, Dec 15, 2020 at 11:22 AM Rodrigo Severo via Therion <
therion@speleo.sk> wrote:

> Hi,
>
>
> I'm having trouble compiling the latest therion code in Linux (Ubuntu
> 20.04).
>
> First I had to manually create the following symlinks inside
> /lib/x86_64-linux-gnu so ld would stop complaining about missing libraries
> during the linking process:
>
> libvtkIOLegacy.so -> libvtkIOLegacy-7.1.so
> libvtkFiltersHybrid.so -> libvtkFiltersHybrid-7.1.so
> libvtkFiltersCore.so -> libvtkFiltersCore-7.1.so
> libvtkCommonCore.so -> libvtkCommonCore-7.1.so
> libvtkCommonDataModel.so -> libvtkCommonDataModel-7.1.so
> libvtkCommonExecutionModel.so -> libvtkCommonExecutionModel-7.1.so
>
> Now, after an apparently clean compile, I'm getting the following errors
> at the end of "sudo make install":
>
> installation error: could not write /usr/local/bin/therion
> installation error: could not write /usr/local/bin/xtherion
> installation error: could not write /usr/local/bin/loch
>
> There are no therion, xtherion and loch executables on the build directory
> to be copied.
>
> Any ideias what could be wrong?
>
>
> Regards,
>
> Rodrigo Severo
>
>
>
> Sent with ProtonMail  Secure Email.
> ___
> 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] Gradient out of range - does not process

[Martin Budaj]

On Mon, Dec 14, 2020 at 8:51 PM Andrew Atkinson  wrote:

> Those fixed positions would need to be calculated, by something. Errors do
> occur which are better distributed about the loops. Most none surveying
> software doesn't really do this.


Check https://www.gnu.org/software/gama/

BTW, how did you get the azimuth (compass column in the data you sent) from
the theodolite data?

Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Creating PDF/A map files

[Martin Budaj]

On Thu, Oct 22, 2020 at 6:39 PM Martin Sluka via Therion
 wrote:
>
> http://texdoc.net/texmf-dist/doc/latex/pdfx/pdfx.pdf

Hi,
this unfortunately requires LaTeX, while Therion uses Plain TeX. I'm
afraid I don't see any viable option to produce PDF/A directly from
Therion without reimplementing the functionality of that package in
Plain TeX.
Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Survex (loop closure) related fixes

[Martin Budaj]

On Wed, Oct 14, 2020 at 10:38 AM Benedikt Hallinger 
wrote:

> When trying to compile a specific plan map view PDF i get an error about
> UTF8. The compile runs fine with release-therion 5.5.1, however!
> (i don't know if this is related)
>

Hi, there was no change in the processing of utf-8 strings between 5.5.1
and 5.5.2. Could you check the same data set is used by those versions?

You should get this error if you use a unicode character outside of the BMP
(see https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane).
Do you such exotic characters?

Sending a minimal data sample would be helpful.

M.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Therion uses wrong declination for surveys 'in the future'

[Martin Budaj]

Hi,

On Tue, Oct 6, 2020 at 4:10 AM Wookey  wrote:

> On 2020-10-05 23:54 +0200, Matthias Keller wrote:
> >Unfortunately, even the current Therion 5.5.1 doesn't have a more
> >meaningful (and correct) message than "unable to determine magnetic
> >declination for undated surveys"
>

 This has already been fixed in the latest commit.


> >I would propose:
> >
> > 1. If a survey is dated but is newer than available correction data,
> >build should fail with a message like:
> >"Error determining magnetic declination for survey  with
> date
> >. Please specify the declination explicitly using for
> example
> >'declination 3 deg'"
> >instead of the (completely wrong)
> >"unable to determine magnetic declination for undated surveys"
>

We have discussed it with Stacho and the following seems to be the best
approach:

IGRF models are designed to predict over the 5 year period (IGRF 13
released at the end of 2019 is intended to be used to predict the
declination up to the end of 2024, when a new version, IGRF 14 will be
released). In Therion, we will allow to use the model for additional 5
years (using linear extrapolation) and produce a warning (so IGRF 13 could
be used until the end of 2029). After 2029, more firm warnings will be
produced if Therion still uses IGRF 13, but we don't expect anybody to use
such an outdated Therion.

On the other hand: is there any need to use the data older than 1900? If
yes, we could implement the GUFM1 model covering the period 1590–1890.


> > 2. If at least one of the imported (and thus joined) surveys has
> magnetic
> >data but at least one does not (or cannot be determined), an error
> >shall be thrown as well, because mixing corrected and uncorrected
> >surveys is just plain wrong and causes a lot of confusion (as it
> has
> >happened to me). The same error message shall be displayed and the
> >build fails.
>

You can't always avoid mixing dated and undated surveys (sometimes the
older survey data might be undated), so using the min(survey_dates) as a
proxy for undated surveys (and producing a warning as well) should be a
reasonable approach.


> >btw, is there any way to update the data in an existing therion
> >installation? Or is the only way the update to a (hopefully existing)
> new
> >version?
>
> There could be - the files are available online so therion could use
> the currently-installed version of the file. But currently the igrf
> coefficients file is compiled-in as thgeomagdata.h This means therion
> can always find the data, but it's not updateable without
> recompiling. I could fix this for linux relatively easily, but it's
> harder on Windows. (and it was making things work on windows that
> caused therion to compile-in all the stuff it needed from subsystems,
> many years ago). Ideally it would compile one in but have the ability
> to read a newer file if provided. But then someone has to write a
> parser.


Not sure if writing the parser is worth the effort, as AFAIK all the real
issues with the declination come from the incorrect handling of
undated/out-of-range data, not from an outdated model.
Even a model outdated 10 or 15 years should provide very reasonable
results. E.g. for our cave area:

The declination for 2015-01-01 calculated as a
* 10-year prediction from IGRF 10 = 4.6206
* 5-year prediction from IGRF 11 = 4.6593
* model result from IGRF 12 = 4.6836
* definitive model result from IGRF 13 = 4.6834

The difference is absolutely negligible even between the models 3
generations apart.

The declination for 2020-01-01 calculated as a
* 15-year prediction from IGRF 10 = 5.1626
* 10-year prediction from IGRF 11 = 5.2685
* 5-year prediction from IGRF 12 = 5.3231
* model result from IGRF 13 = 5.4036

The difference is still less than a typical compass reading error.

The example is not really representative and there might be areas
(definitely near the magnetic poles) where the differences are larger, but
it should illustrate the point. Also consider that the model is approximate
anyway (even in its intended time range) and no local/regional deviations
in the geomagnetic field are taken into account at all.


> We could also try a little harder not to get 10 years behind
> again. (5.4.4 was released in May 2019 with a model that expired in
> mid 2020, when the 2025 model had been available since 2015 (and was
> included with the next therion release in May 2020). Not sure why the
> update was not to 2030 as that was available from Dec 2019.)
>

There was actually no 2025 model available since 2015. The models are
always for 5-year predictions and there is zero overlap between them. Just
to illustrate, here is an overview of the history of publication of IGRF
models and their inclusion into Therion (see
https://github.com/therion/therion/commits/master/thgeomagdata.h):
* IGRF 11 released in December 2009, included into Therion on 

Re: [Therion] Error while compiling Therion 5.5.x (proj issue?) on MacosX

[Martin Budaj]

On Thu, Sep 10, 2020 at 12:21 PM Xavier Robert <
xavier.rob...@univ-grenoble-alpes.fr> wrote:

> I am trying to compile the last Therion version on my Macos 10.14.6. The
> compilation fails with the ./utest with the error:
> ./utest
> proj_create: cannot build projectedCRS 32634: cannot build geodeticCRS
> 4326: SQLite error on SELECT name, ellipsoid_auth_name, ellipsoid_code,
> prime_meridian_auth_name, prime_meridian_code, area_of_use_auth_name,
> area_of_use_code, publication_date, deprecated FROM geodetic_datum WHERE
> auth_name = ? AND code = ?: no such column: publication_date
> (null): error -- PROJ library: -61 (generic error of unknown origin):
> epsg:32634
> make: *** [tests] Error 1
>

Hi, this looks like a Proj version mismatch (Proj compiled into Therion
trying to open a database belonging to another version of Proj installed in
the system). Check if Proj command line utilities work (run e.g. "projinfo
EPSG:32634"), check the version and check if the version matches the
version of Proj used in Therion.


> With the master (6c41c82) version:
>
>- A « tclsh thcdata.tcl » gives « No PROJ system definitions
>imported ».
>- If I do a search for « 32634 » in thcsdata.cxx, I find only 1 line:
>
> This is expected as the latest commits call Proj API to get the
definitions instead of preprocessing them.


> I also have the sqlite3 from Anaconda installed.
>

The sqlite error is produced by sqlite linked to Proj directly, it doesn't
use external/system sqlite3.


> On the other side, I also tried to recompile the 5.4.4 version (that I
> already have and that is running fine), and I could recompile it without
> any errors (with proj 6.3.2, I did not tried with proj 7).
>

5.4.4 used different handling of Proj definitions (they were compiled into
therion binary).

Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Building Therion on Centos 8 (stream)

[Martin Budaj]

Hi,
check out the latest commit in the master branch. It uses a different
approach to labels handling for newer Proj versions.
M.

On Mon, Aug 17, 2020 at 10:10 PM Þórir Már Jónsson 
wrote:

> There is only one line with each of these values:
>
> The last line of the file contains epsg_labels:
>
> map epsg_labels = {};
>
> and line 738 contains 32634:
>
> {false, true, false, "+init=epsg:32634", 
> "PROJCS[\"WGS_1984_UTM_Zone_34N\",GEOGCS[\"GCS_WGS_1984\",DATUM[\"D_WGS_1984\",SPHEROID[\"WGS_1984\",6378137.0,298.257223563]],PRIMEM[\"Greenwich\",0.0],UNIT[\"Degree\",0.0174532925199433]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"False_Easting\",50.0],PARAMETER[\"False_Northing\",0.0],PARAMETER[\"Central_Meridian\",21.0],PARAMETER[\"Scale_Factor\",0.9996],PARAMETER[\"Latitude_Of_Origin\",0.0],UNIT[\"Meter\",1.0]]",
>  "WGS84 / UTM zone 34N"},
>
> There is no output when I run tclsh thcsdata.tcl. The script seems to exit
> normally, but without printing anything.
>
> Þórir Már
>
>
> On Mon, Aug 17, 2020 at 7:38 PM Martin Budaj  wrote:
>
>> Hi,
>> check the definition of map epsg_labels in the
>> file thcsdata.cxx (the file is generated by make). Is there a key/value
>> pair with a key 32634? What's the value associated with the key? There
>> should be a line containing something like
>>  {32634, "WGS 84 / UTM zone 34N"},
>>
>> Also check the terminal output when you run
>> tclsh thcsdata.tcl
>>
>> Martin
>>
>> On Mon, Aug 17, 2020 at 4:35 AM Þórir Már Jónsson 
>> wrote:
>>
>>> With some difficulty I've managed to find and install libsqlite-tcl.
>>> This package was apparently dropped when CentOs went from version 7 to 8,
>>> but it is still built for CloudLinux which happens to be based on CentOs 8,
>>> saving me from having to find the source and building it myself.
>>> Nevertheless make is still failing on the same test as before:
>>>
>>> ~~~utest
>>>  is a Catch v2.11.3 host application.Run with -? for options
>>>
>>> ---
>>> projections: EPSG label
>>> ---utest-proj.cxx:77...
>>> utest-proj.cxx:78: *FAILED:*  CHECK( (epsg_labels.count(32634) > 0 && 
>>> strcmp(epsg_labels[32634],"WGS 84 / UTM zone 34N") == 0) )
>>> with expansion:*  false*
>>> **===
>>> test cases: 18 | 17 passed | *1 failed*
>>> assertions: 44 | 43 passed | *1 failed*
>>>
>>> make: *** [Makefile:184: tests] Error 1
>>>
>>>
>>> I went to through the dependencies listed in the Appendix of the book
>>> just to make sure I had not missed anything; here is what I have installed:
>>>
>>>- gcc-8.3.1-5.1.el8.x86_64
>>>- gcc-c++-8.3.1-5.1.el8.x86_64
>>>- make-4.2.1-10.el8.x86_64
>>>- Perl (I'm not sure which of these are relevant, but these are the
>>>once I have installed):
>>>   - perl-Carp-1.42-396.el8.noarch
>>>   - perl-constant-1.33-396.el8.noarch
>>>   - perl-CPAN-Meta-2.150010-396.el8.noarch
>>>   - perl-CPAN-Meta-Requirements-2.140-396.el8.noarch
>>>   - perl-CPAN-Meta-YAML-0.018-397.el8.noarch
>>>   - perl-Data-Dumper-2.167-399.el8.x86_64
>>>   - perl-DBD-MySQL-4.046-3.module_el8.3.0+419+c2dec72b.x86_64
>>>   - perl-DBI-1.641-3.module_el8.3.0+413+9be2aeb5.x86_64
>>>   - perl-devel-5.26.3-416.el8.x86_64
>>>   - perl-Digest-1.17-395.el8.noarch
>>>   - perl-Digest-MD5-2.55-396.el8.x86_64
>>>   - perl-Encode-2.97-3.el8.x86_64
>>>   - perl-Encode-Locale-1.05-10.module_el8.3.0+416+dee7bcef.noarch
>>>   - perl-encoding-2.22-3.el8.x86_64
>>>   - perl-Errno-1.28-416.el8.x86_64
>>>   - perl-Error-0.17025-2.el8.noarch
>>>   - perl-Exporter-5.72-396.el8.noarch
>>>   - perl-ExtUtils-Command-7.34-1.el8.noarch
>>>   - perl-ExtUtils-Install-2.14-4.el8.noarch
>>>   - perl-ExtUtils-MakeMaker-7.34-1.el8.noarch
>>>   - perl-ExtUtils-Manifest-1.70-395.el8.noarch
>>

Re: [Therion] Building Therion on Centos 8 (stream)

[Martin Budaj]

8.x86_64
>   - perl-Test-Harness-3.42-1.el8.noarch
>   - perl-Text-ParseWords-3.30-395.el8.noarch
>   - perl-Text-Tabs+Wrap-2013.0523-395.el8.noarch
>   - perl-Text-Unidecode-1.30-5.el8.noarch
>   - perl-Thread-Queue-3.13-1.el8.noarch
>   - perl-threads-2.21-2.el8.x86_64
>   - perl-threads-shared-1.58-2.el8.x86_64
>   - perl-Time-HiRes-1.9758-1.el8.x86_64
>   - perl-Time-Local-1.280-1.el8.noarch
>   - perl-Unicode-Normalize-1.25-396.el8.x86_64
>   - perl-URI-1.73-3.el8.noarch
>   - perl-version-0.99.24-1.el8.x86_64
>   - perl-XML-Parser-2.44-11.el8.x86_64
>   - perl-XML-XPath-1.42-3.el8.noarch
>- python36-3.6.8-2.module_el8.3.0+389+6a62c88d.x86_64
>- PROJ:
>- proj-datumgrid-1.8-6.3.2.4.epel8.playground.noarch
>   - proj-datumgrid-north-america-1.4-1.epel8.playground.noarch
>   - proj-datumgrid-europe-1.6-1.epel8.playground.noarch
>   - proj-static-6.3.2-4.epel8.playground.x86_64
>   - proj-devel-6.3.2-4.epel8.playground.x86_64
>   - proj-datumgrid-world-1.0-3.epel8.playground.noarch
>   - proj-datumgrid-oceania-1.2-1.epel8.playground.noarch
>   - proj-6.3.2-4.epel8.playground.x86_64
>   - tcl/tk:
>   - tcl-8.6.8-2.el8.x86_64
>   - tcl-devel-8.6.8-2.el8.x86_64
>   - tcllib-1.19-3.el8.noarch
>   - BWidget-1.9.14 I had to manually download this library, I copied
>the tarball to /usr/lib64/tcl-8.6/ and extracted it there in accordance
>with the included README file.
>- sqlite:
>   - sqlite-3.26.0-6.el8.x86_64
>   - sqlite-devel-3.26.0-6.el8.x86_64
>   - sqlite-libs-3.26.0-6.el8.x86_64
>   - sqlite-tcl-3.26.0-6.el8.x86_64 (from CloudLinux repository)
>- tkImg-1.4.11 I also had to manually download this library. No README
>was included in the file, and no documentation is to be found on the
>projects github page, so I did the same as with BWidget and copied the
>folder into the tk library directory: (/usr/share/lib64/tk8.6/Img1.4.11/).
>- TeX:
>   - texlive-20180414-17.el8.x86_64
>   - texlive-metapost-20180414-17.el8.x86_64/pdf
>   - texlive-pdftex-20180414-17.el8.x86_64
>   - and a host of other texlive packages (211 in total)
>- LCDF Typetools 2.108 (this one I had to download and build from
>source, for some reason I was unable to configure it for kpathsea, despite
>it already being installed. I ended up needing to use the –without-kpathsea
>option during the configuration to get it work – I hope this is not
>important for the Therion installation).
>- ImageMagick:
>   - ImageMagick-perl-6.9.10.86-1.el8.x86_64
>   - ImageMagick-libs-6.9.10.86-1.el8.x86_64
>   - ImageMagick-doc-6.9.10.86-1.el8.x86_64
>   - ImageMagick-6.9.10.86-1.el8.x86_64
>   - ImageMagick-devel-6.9.10.86-1.el8.x86_64
>   - ImageMagick-c++-6.9.10.86-1.el8.x86_64
>- ghostscript-9.25-7.el8.x86_64
>- freetype:
>   - freetype-2.9.1-4.el8.x86_64
>   - freetype-devel-2.9.1-4.el8.x86_64
>- VTK 9.0.1 (built from source)
>- libjpeg-turbo-1.5.3-10.el8.x86_64
>- libjpeg-turbo-devel-1.5.3-10.el8.x86_64
>- libpng-1.6.34-5.el8.x86_64
>- libpng-devel-1.6.34-5.el8.x86_64
>- zlib-1.2.11-15.el8.x86_64
>- zlib-devel-1.2.11-15.el8.x86_64
>
>
> Is there anything obvious that I am missing? I don't know what to try next.
>
>
>
>
>- On Thu, Aug 13, 2020 at 6:35 AM Martin Budaj 
>wrote:Hi,
>
> just build-time, introduced in 5.4.4. It's used to generate parts of
>> thcsdata.cxx (esri_labels and epsg_labels). It's used for Proj 6 and newer,
>> which uses sqlite3 format of its database (older versions used plain text
>> files).
>> Martin
>>
>> On Thu, Aug 13, 2020 at 1:18 AM Wookey  wrote:
>>
>>> On 2020-08-12 22:01 +0200, Martin Budaj wrote:
>>> >Hi,
>>> >check if you have libsqlite3-tcl (or equivalent) installed and
>>> working.
>>> >It's required for correct parsing of projection names from the EPSG
>>> >database.
>>>
>>> Is this a build-time only dependency or should it also be present at
>>> runtime?
>>>
>>> It gets pulled in on debian builds but I'm not quite sure why. It
>>> should perhaps be explicitly specified. Is this new or has it been true
>>> for years?
>>>
>>> Wookey
>>> --
>>> Principal hats:  Linaro, Debian, Wookware, ARM
>>> http://wookware.org/
>>> ___
>>> 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 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] Building Therion on Centos 8 (stream)

[Martin Budaj]

Hi,
just build-time, introduced in 5.4.4. It's used to generate parts of
thcsdata.cxx (esri_labels and epsg_labels). It's used for Proj 6 and newer,
which uses sqlite3 format of its database (older versions used plain text
files).
Martin

On Thu, Aug 13, 2020 at 1:18 AM Wookey  wrote:

> On 2020-08-12 22:01 +0200, Martin Budaj wrote:
> >Hi,
> >check if you have libsqlite3-tcl (or equivalent) installed and
> working.
> >It's required for correct parsing of projection names from the EPSG
> >database.
>
> Is this a build-time only dependency or should it also be present at
> runtime?
>
> It gets pulled in on debian builds but I'm not quite sure why. It
> should perhaps be explicitly specified. Is this new or has it been true
> for years?
>
> Wookey
> --
> Principal hats:  Linaro, Debian, Wookware, ARM
> http://wookware.org/
> ___
> 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] Building Therion on Centos 8 (stream)

[Martin Budaj]

Hi,

check if you have libsqlite3-tcl (or equivalent) installed and working.
It's required for correct parsing of projection names from the EPSG
database.

Best regards
Martin


On Wed, Aug 12, 2020, 19:34 Þórir Már Jónsson  wrote:

> I am building Therion for the first time and getting one Proj related
> error when running make:
>
> ---
> projections: EPSG label
> ---utest-proj.cxx:77...
> utest-proj.cxx:78: *FAILED:*  CHECK( (epsg_labels.count(32634) > 0 && 
> strcmp(epsg_labels[32634],"WGS 84 / UTM zone 34N") == 0) )
> with expansion:*  false*
> **===
> test cases: 18 | 17 passed | *1 failed*
> assertions: 44 | 43 passed | *1 failed*
>
> make: *** [Makefile:184: tests] Error 1
>
> Is this an error I can ignore or something I need to fix? If so, do you have 
> any pointers to how I might do that?
>
>
> Best regards,
>
> Þórir Már
>
> ___
> 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] Extended Gridl ines longer and other font for altitude

[Martin Budaj]

On Tue, Jul 28, 2020 at 5:38 PM Axel  wrote:

> Now the only question is how to get the labels in normal font and not
> italic...
>

Hi, the elevations are typeset in math mode to get e.g. the minus sign
correct (it's different from both hyphen and dash). The side effect of the
math mode in TeX is that the text is in italics, numbers are in the upright
font. But there should be no text, just the numbers in coordinate labels.
Could you send an example of what's in italic font?
M.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Extended Gridl ines longer and other font for altitude

[Martin Budaj]

Hi,

you can modify the appearance of lines (using s_vgrid MetaPost macro as you
tried) and also the alignment of the altitude labels (using \gridcoord TeX
macro).

This modification (it's simplified and wouldn't work for the plan
projection) displays coordinates on the outer side of the imaginary map
box, vertically centered on the elevation lines:

\def\gridcoord#1#2{\hbox to0pt{%
  \ifnum#1=3\hss\fi
  \ifnum#1=9\hss\fi
\vbox to0pt{%
  \vss
  \kern2pt%
  \hbox{\kern2pt#2\kern2pt}%
  \kern2pt%
  \vss
}%
  \ifnum#1=1\hss\fi
  \ifnum#1=7\hss\fi
  }%

Cheers
Martin


On Sun, Jul 26, 2020 at 10:55 AM Axel  wrote:

> Hi all,
>
> I am looking for a way to extend the gridlines in an extended elev to the
> left and right that the alitude notations don't cover the survey.
> If u think of the survey as a box it would be good to have the
> altitude-notations outside this box (in fact I think this is a bug).
>
> I tried to change the s_vgrid definition a bit but only achieved that my
> lines get longer and are dashed again (if xpos < -1: 0). Text won't move
> though...
> It also would be nice to get a non italic font for the notations. I guess
> the key is to know where Therion actually generates the grid?
>
> would be greate if someone could give me a kick in the right direction
>
> cheers,
> Axel Hack
> ___
> 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] For JM Begley - Rebuild for Fedora 32

[Martin Budaj]

Hi,

we plan to release the next version in a couple of days, so it would be
best to wait a bit.

Best wishes
Martin

On Wed, Apr 29, 2020 at 9:26 PM Bill Gee  wrote:

> No worries, mate! It's not like I have a huge need to use Therion right
> now. All my mapping projects are up to date, and no more data will be
> coming in for some months. The machine I tried the upgrade on is a test
> system. If I get impatient enough, I can always uninstall Therion.
>
>
>
> And besides - There were other applications showing similar problems.
> Therion is not the only victim.
>
>
>
> Sometimes I feel like the vulture in the classic Far Side panel. The
> vulture says to his friend "Patience my ass! I'm gonna kill something."
>
> --
>
> Bill Gee
>
>
>
>
>
>
> On Wednesday, April 29, 2020 11:19:37 AM CDT James Begley wrote:
>
> > Hi Bill,
>
> >
>
> > Unfortunately F32 has moved to proj v6, which has a number of fairly
>
> > significant changes associated with it. Therion support for proj v6
>
> > appears to be a bit of a work in progress, but I'm trying to pick out the
>
> > commits that are required to get it working. It might take a few days
>
> > though :(
>
> >
>
> > Cheers,
>
> > James
>
> >
>
> > On Wed, 29 Apr 2020 at 17:08, Bill Gee  wrote:
>
> >
>
> > > If it is not already in progress ... The Therion package in JM Begley's
>
> > > COPR repository needs to be rebuilt so it works on Fedora 32. When I
> try to
>
> > > run the upgrade from F31 to F32, it gives me this:
>
> > >
>
> > >
>
> > >
>
> > > 
>
> > >
>
> > > 
>
> > >
>
> > >
>
> > >
>
> > > Problem 3: package therion-5.4.4-2.fc31.x86_64 requires
>
> > > libproj.so.13()(64bit), but none of the providers can be installed
>
> > >
>
> > > - proj-5.2.0-5.fc31.x86_64 does not belong to a distupgrade repository
>
> > >
>
> > > - problem with installed package therion-5.4.4-2.fc31.x86_64
>
> > >
>
> > >
>
> > >
>
> > > 
>
> > >
>
> > > =
>
> > >
>
> > >
>
> > >
>
> > > 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 mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion-cs] - Re: Chybný výpočet truenorth

[Martin Budaj]

Ahoj, skús najnovšiu vývojársku verziu (a18b2f0) s aktualizovanou databázou
na výpočet deklinácie.

M.

On Fri, Jan 17, 2020 at 6:33 PM Vratislav Ouhrabka 
wrote:

> Ahoj,
> souvisí to s datem kompilace, jakmile naskočí rok 2020 tak je ve výpočtu
> chyba.  Do roku 2019 je výpočet OK. Zkoušel jsem starší verze a je to
> stejné.
>
> Vratik
> --
> *Od:* Therion-cs [therion-cs-boun...@speleo.sk] za uživatele Stacho
> Mudrak [s...@group-s.sk]
> *Odesláno:* 17. ledna 2020 8:09
> *Komu:* List pro česky a slovensky mluvící uživatele programu Therion
> *Předmět:* - Re: [Therion-cs] Chybný výpočet truenorth
>
> Caves, fakt netusim, ako sa to mohlo stat. Ale kebyze mas nejaky
> minimalisticky .th subor, ktory tento error robi - tak sa na to mozem
> kuknut.
>
> Popr. ak mas moznost to vyskusat s nejakou starsou verziou theriona,
> menila sa kniznica na projekcie, tak moze to suvisiet s tym.
>
> S.
>
> On Thu, 16 Jan 2020 at 14:55, Vratislav Ouhrabka 
> wrote:
>
>> Ahoj,
>>
>> nevíte někdo, z jakého důvodu může dojít k takovému to výpočtu parametru
>> truenorth?
>>
>>
>>
>> []\thfb  truenorth
>>  52154014543966924175334463996458298597934990672737081895688
>>
>> 2405913338404987189325239861926910147019157456659094744997971570863229775522102
>>
>>
>> 7831486768777080433126182506241348942729834466121085875723301841470054321007256
>>
>>
>> 8107398803099094124142544987512285462072515362816.00deg |
>>
>>
>>
>> Chyba se projeví v hlavičce výkresu, výpisem nesmyslné hodnoty a v
>> směrové růžici je použita mag. dekl  0.
>>
>>
>>
>> Výpočet deklinace a konvergence je OK:
>>
>>
>>
>> output coordinate system: UTM38
>>
>> meridian convergence (deg): 1.5973
>>
>> geomag declinations (deg):
>>
>>   2019.1.1  6.8828
>>
>>   2020.1.1  6.9639
>>
>>
>>
>> Díky
>>
>>
>>
>> Vratik
>>
>>
>>
>>
>> ___
>> Therion-cs mailing list
>> Therion-cs@speleo.sk
>> https://mailman.speleo.sk/listinfo/therion-cs
>>
> ___
> Therion-cs mailing list
> Therion-cs@speleo.sk
> https://mailman.speleo.sk/listinfo/therion-cs
>
___
Therion-cs mailing list
Therion-cs@speleo.sk
https://mailman.speleo.sk/listinfo/therion-cs

Re: [Therion] Problem with dots in symbols: map-connection is empty

[Martin Budaj]

Hi,

the problem is in a global "linecap := butt;" setting in the point
mudcrack symbol (added on December 6) which changes the appearance of
the line endings (the dot is a zero-length line which used to be drawn
with a round pen). A thorough revision of newly added symbols is
necessary before the next stable release.

Martin

On Wed, Dec 18, 2019 at 8:01 PM Bruce Mutton  wrote:
>
> OK, it’s not ‘just’ a Therion issue.
>
> Here is the same 5.4.4+19eb624 (2019-12-09) output viewed with Foxit on the 
> left, and Sumatra on the right.
>
> If we go back in Therion versions, there is some point where both pdf viewers 
> plot the dots correctly (5.4.4+00a31d0 (2019-10-22) at is OK I think).  My 
> previous message shows shots from Foxit (I think).  Now I have realised this 
> I will need to start narrowing it down again.
>
> Bruce
>
>
>
> From: Therion  On Behalf Of Bruce Mutton via 
> Therion
> Sent: Thursday, 19 December 2019 07:05
> To: 'List for Therion users' 
> Cc: Bruce Mutton 
> Subject: Re: [Therion] Problem with dots in symbols: map-connection is empty
>
>
>
> Yes, with Therion version 5.4.4+4d5750d (2019-12-17) even my customised point 
> map-connection is affected.  The dot is missing.
>
>
>
> In another project, my area sand is looking a bit weird (short dashes, not 
> dots).
>
>
>
> If I revert to 5.4.4+00a31d0 (2019-10-22) (and remove maps-set and log extend 
> from my thconfigs) then the short dashes have rounded dot-like appearance, as 
> I believe they should.
>
>
>
> And my map connection gets better.
>
> Bruce
>
>
>
>
>
> -Original Message-
> From: Therion  On Behalf Of Benedikt Hallinger
> Sent: Thursday, 19 December 2019 04:12
> To: List for Therion users 
> Subject: [Therion] Problem with dots in symbols: map-connection is empty
>
>
>
> Hi there,
>
> we noticed some problems with dots in symbols yesterday, the won't show 
> anymore.
>
>
>
> I can reproduce this with therion 5.4.4+19eb624 (2019-12-09).
>
> The problem exists with the default symbol for "point map-connection", as 
> well as with my custom layout code for clay:
>
>
>
> Has something changed recently in the point definition?
>
> I assume, because the default map-connection item should still work but 
> doesn't show points?
>
>
>
>
>
> With best regards,
>
> Beni
>
> ___
>
> 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 mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Metapost for a line ending in an ellipse

[Martin Budaj]

On Fri, Nov 22, 2019 at 8:56 PM Tarquin Wilton-Jones via Therion
 wrote:

> In Therion's Metapost, the line is easy;
> pickup PenC;
> thdraw P;
>
> Drawing a horizontal ellipse at the coordinates of the last point in the
> line is easy:
> p:=fullcircle xscaled (.5u) yscaled (.25u);
> draw p shifted (point (length P) of P);
>
> But making the last "leg" of the line stop at the point where it
> intersects the ellipse ... I am baffled.

Hi,

instead of "thdraw P;" use "thdraw P cutafter p;" after defining both
paths P and p.

Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] therion crashes on debian testing (bullseye)

[Martin Budaj]

Build-time, just for therion. It's used to parse the definitions of CSs
from the Proj database.
M.

On Mon, Sep 16, 2019, 01:16 Olly Betts  wrote:

> On Sun, Sep 15, 2019 at 09:45:23PM +0200, Martin Budaj wrote:
> > @Olly, Wookey: While investigating this issue I noticed that a dependency
> > on libsqlite3-tcl should be added in Debian if Proj library version 6 is
> > used.
>
> What sort of dependency?  Build-time, run-time, both?
>
> And if run-time, what exactly needs it?  There's a separate binary
> package for loch (therion-viewer).
>
> Cheers,
> Olly
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] therion crashes on debian testing (bullseye)

[Martin Budaj]

Hi,

after a quick investigation (no time for going more in depth) it seems that
there is some issue in Proj v.6 itself.

Therion internally generates the following transformation for Benedikt's
example:
+proj=pipeline +step +inv +init=epsg:31258 +step +init=epsg:31258 (source
and destination CS are the same)

When processed outside of therion using proj's command line utility, you
get the same error as given by therion:

$ proj +proj=pipeline +step +inv +init=epsg:31258 +step +init=epsg:31258
Rel. 6.2.0, September 1st, 2019
:
projection initialization failure
cause: no arguments in initialization list
program abnormally terminated

Currently I have no Proj v.5 environment to test this example, but I guess
it would work -- could anybody check it?

Proj's other utility cs2cs acccepts this init string in version 6.2.0
without any issue, though:

$ cs2cs +init=epsg:31258 +to +init=epsg:31258

@Olly, Wookey: While investigating this issue I noticed that a dependency
on libsqlite3-tcl should be added in Debian if Proj library version 6 is
used.

M.



On Fri, Sep 13, 2019 at 9:21 PM Olly Betts  wrote:

> On Fri, Sep 13, 2019 at 05:54:20PM +0200, Benedikt Hallinger wrote:
> > therion: error -- PROJ4 library: -1 (no arguments in initialization list)
>
> OK, this fails for me too.  Thanks for reducing that testcase.
>
> I also spotted that therion had been binNMUed (read "rebuilt against the
> latest dependencies") so it is actually fully using PROJ 6.1.0.
>
> I'd guess this is probably a general incompatibility with newer PROJ.
>
> 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] Automatic scaling of PDF output

[Martin Budaj]

Hi

unfortunately Therion doesn't support this. It would be actually quite
complicated to implement it, as map symbols are scale-dependent so to know
the exact size of the output drawing (not just the centreline), you have to
draw it first in the selected scale.

Martin

On Fri, May 24, 2019 at 11:00 AM Tarquin Wilton-Jones via Therion <
therion@speleo.sk> wrote:

> Hi,
>
> I am sure this must have been asked before, but was not able to find
> anything in the mailing list archives or wiki...
>
> Our survey is going to be published in a magazine. The magazine has very
> strict limits on the survey size; 28 cm x 18 cm max, with limits on line
> thickness as well. Making the final PDF survey the right size is done
> with the layout "scale" definition, but this means I need to very
> carefully (painfully) recalculate it whenever an extension changes the
> size of the survey.
>
> Main question; Is there a way to make Therion automatically calculate
> the correct scale to fit certain dimensions?
>
> (I do understand that this might be impossible, since the output can
> change based on the scale, so it would become an iterative process. I am
> just hoping there might be some magic.)
>
> 
>
> For those interested, I have used code metapost to set the line
> thicknesses so that they work according to the minimum line thickness:
>
> def minimumpen = 0.18pt enddef;
> def PenA = pencircle scaled (minimumpen*1/0.35) enddef;
> def PenB = pencircle scaled (minimumpen*0.7/0.35) enddef;
> def PenC = pencircle scaled (minimumpen*0.5/0.35) enddef;
> def PenD = pencircle scaled (minimumpen) enddef;
> def PenX = pencircle scaled (minimumpen*1.2/0.35) enddef;
>
> 
>
> Thanks for any assistance.
>
> 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] Setting scale on custom symbol

[Martin Budaj]

>
> There is a partial explanation of u: here
> https://therion.speleo.sk/wiki/metapost#symbol_sizing but I will admit to
> not knowing if it relates directly to U:  Are u: and U: the same? I suspect
> not.
>

Hi,
check also the chapter New map symbols / Point symbols in the Therion book
(page 73) for an explanation of "u" and "U" variables.
M.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] JMBegley need repackaged survex and therion

[Martin Budaj]

Hi,

Therion 5.4.4 (released today) should be compatible with proj-5.2.0 used in
Fedora 30 (and proj-6.0.0 as well). Let us know if there is any problem
packaging this new version.

Martin

On Wed, May 1, 2019 at 6:04 PM Bill Gee  wrote:

> For JMBegley who very kindly maintains Fedora packages for both Therion
> and Survex ...
>
>
>
> When I start the dnf process to upgrade from Fedora 29 to Fedora 30, I get
> errors related to both Therion and Survex. The messages are:
>
>
>
> Problem 1: package survex-1.2.38-1.fc29.i686 requires libproj.so.12, but
> none of the providers can be installed
>  - proj-4.9.3-6.fc29.i686 does not belong to a distupgrade repository
>  - problem with installed package survex-1.2.38-1.fc29.i686
>
> Problem 8: package libgeotiff-1.4.3-3.fc30.i686 requires libproj.so.13,
> but none of the providers can be installed
>  - cannot install both proj-5.2.0-2.fc30.i686 and proj-4.9.3-6.fc29.i686
>  - cannot install both proj-5.2.0-1.fc30.i686 and proj-4.9.3-6.fc29.i686
>  - problem with installed package libgeotiff-1.4.0-14.fc29.i686
>  - package therion-5.4.3-1.fc29.i686 requires libproj.so.12, but none of
> the providers can be installed
>  - libgeotiff-1.4.0-14.fc29.i686 does not belong to a distupgrade
> repository
>  - problem with installed package therion-5.4.3-1.fc29.i686
>
> There are other problem packages, but these two at least can be addressed
> through this list.
>
> --
>
> 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

Re: [Therion] World Magnetic Model

[Martin Budaj via Therion]

Hi,

Therion does not use WMM at all (as it doesn't contain 20th century
historical data).
It uses IGRF model (https://www.ngdc.noaa.gov/IAGA/vmod/igrf.html) which
hasn't been updated yet.

Best regards
Martin

On Thu, Apr 11, 2019 at 5:05 PM kevin dixon via Therion 
wrote:

> The last Therion release 5.4.3 is dated 01 Feb 2019.
>
> There has in recent years been a significant change of the Magnetic North
> Pole location, less so for the Geomagnetic South Pole:
> https://ngdc.noaa.gov/geomag/GeomagneticPoles.shtml
>
> Given the above, an out of cycle World Geomagnetic Model WMM2015v2 was
> released 04 Feb 2019.
>
> When will this update appear in Survex and Therion ?
>
> Thanks,
>
> Kevin Dixon
> ___
> 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] SVG output gives blank file and compiling error

[Martin Budaj via Therion]

> On Fri, Mar 1, 2019 at 12:00 PM Andrew Atkinson via Therion
> > The conclusion is that with the same data set svg output works on a
> > windows 10 machine but does not work on Debian testing therion 5.4.3
> > (2019.02.01)

Fixed now in the current development version (947e945).
Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] SVG output gives blank file and compiling error

[Martin Budaj via Therion]

On Fri, Mar 1, 2019 at 12:00 PM Andrew Atkinson via Therion
 wrote:

> The conclusion is that with the same data set svg output works on a
> windows 10 machine but does not work on Debian testing therion 5.4.3
> (2019.02.01)

Hi,

could you send me that example? I processed 'Maze' part of the cave on
Debian 9 / therion 5.4.3+d0538ee without any problem (svg and xhtml
looking fine). Didn't process the whole cave, though, as some of the
th2 files are missing on the web.

Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Therion 5.4.2. potential bug

[Martin Budaj via Therion]

No, we don't modify existing releases. The fix will be included in 5.4.3
eventually, but until then you can use the latest snapshot (
https://therion.speleo.sk/downloads/therion-setup-dev.exe).

Martin

On Fri, Jan 18, 2019 at 9:32 AM Michael  wrote:

> Thank you, Martin, for the quick fix.
>
> Is it also fixed in
>
> https://therion.speleo.sk/downloads/therion-setup-5.4.2.exe
>
> ?
>
> Regards,
>
> Michael.
>
>
>
> *Von:* Therion  *Im Auftrag von *Martin Budaj
> via Therion
> *Gesendet:* Donnerstag, 17. Januar 2019 19:26
> *An:* List for Therion users 
> *Cc:* Martin Budaj 
> *Betreff:* Re: [Therion] Therion 5.4.2. potential bug
>
>
>
> Hi, it's fixed in d98a0a6.
>
> Martin
>
>
>
> On Tue, Jan 15, 2019 at 7:28 PM Martin Budaj  wrote:
>
> On Sat, Jan 12, 2019 at 10:51 AM Michael  wrote:
>
> I have now attached a minimal cave sample produced  with 5.4.1. and one
> produced with 5.4.2. to demonstrate the displacement.
>
>
>
> Hi,
>
>
>
> the problem is that EPSG:31467 projection uses the "potsdam" datum and the
> PROJ library used by Therion changed the way how to transform potsdam datum
> to the standard WGS84 datum – it switched from a simple string parameter
> (towgs84) to using external grid file (see
> https://proj4.org/resource_files.html#transformation-grids for examples).
>
>
>
> No grid files are currently included in the windows Therion distribution,
> so the transformation is not correct in 5.4.2. Therion needs to be modified
> to include and use those files – hopefully soon.
>
>
>
> Best regards
>
> Martin
>
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Therion 5.4.2. potential bug

[Martin Budaj via Therion]

Hi, it's fixed in d98a0a6.
Martin

On Tue, Jan 15, 2019 at 7:28 PM Martin Budaj  wrote:

> On Sat, Jan 12, 2019 at 10:51 AM Michael  wrote:
>
>> I have now attached a minimal cave sample produced  with 5.4.1. and one
>> produced with 5.4.2. to demonstrate the displacement.
>>
>
> Hi,
>
> the problem is that EPSG:31467 projection uses the "potsdam" datum and the
> PROJ library used by Therion changed the way how to transform potsdam datum
> to the standard WGS84 datum – it switched from a simple string parameter
> (towgs84) to using external grid file (see
> https://proj4.org/resource_files.html#transformation-grids for examples).
>
> No grid files are currently included in the windows Therion distribution,
> so the transformation is not correct in 5.4.2. Therion needs to be modified
> to include and use those files – hopefully soon.
>
> Best regards
> Martin
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Therion 5.4.2. potential bug

[Martin Budaj via Therion]

On Sat, Jan 12, 2019 at 10:51 AM Michael  wrote:

> I have now attached a minimal cave sample produced  with 5.4.1. and one
> produced with 5.4.2. to demonstrate the displacement.
>

Hi,

the problem is that EPSG:31467 projection uses the "potsdam" datum and the
PROJ library used by Therion changed the way how to transform potsdam datum
to the standard WGS84 datum – it switched from a simple string parameter
(towgs84) to using external grid file (see
https://proj4.org/resource_files.html#transformation-grids for examples).

No grid files are currently included in the windows Therion distribution,
so the transformation is not correct in 5.4.2. Therion needs to be modified
to include and use those files – hopefully soon.

Best regards
Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Therion 5.4.2. potential bug

[Martin Budaj via Therion]

Hi,

On Wed, Jan 9, 2019 at 4:03 PM Michael via Therion 
wrote:

> Excited to see the new version being available, as not everyone is IT-savy
> enough to build it.
>
>
actually there is always a windows installer for the most recent git commit
at https://therion.speleo.sk/download.php; just look for "*current *Therion
for Windows ".
It should be available 30 minutes after the commit at the latest.


> Producing a KML file for GoogleEarth results in the cave map being
> displaced towards NE by 100 meters or so.
>
> When I re-install Therion 5.4.1., the displacement is gone and the map is
> where it should be.
>
> Perhaps a glitch or change in the way coordinates are calculated?
>

Possibly yes, as we updated PROJ library from 4.7 to 5.1 for windows
builds. Could you send a minimal example illustrating the issue?

Best regards
Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] new Therion release

[Martin Budaj via Therion]

Hi all,

there is a new release of Therion, 5.4.2.

See https://github.com/therion/therion/blob/v5.4.2/CHANGES for a list of
changes.

Best regards
Therion team
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Height numbers in square boxes

[Martin Budaj via Therion]

Hi Bruce, thanks for the feedback.

Possibly some issues for now though,
>
> >> p_label_mode_dbgscrap-1
>
> Looks like have missed changing a dbgscrap to debugscrap somewhere in the
> code.
>
>
>
> Also some odd assignments.
>
> p_label_mode_debugstation:=2; %should be set to 7…
>
> p_label_mode_debugscrap:=1; % Perhaps it should be 6?
>

These should be fixed now in ad685a3.

>

> I tried the filled labels, mode 8, but cannot see the difference to the
> generic label, mode 0.
>

You have to define the fill color, which is white by default. See
samples/q-marks for an example.

Best regards
Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] What file I have to translate for Loch

[Martin Budaj via Therion]

On Sun, Mar 11, 2018 at 2:31 AM, Wookey via Therion 
wrote:

> On 2018-03-11 00:13 +0100, Evaristo Quiroga via Therion wrote:
> > Thanks Olly.
> >
> > I have already translated it. Now, What do have I do. Wait for a new
> > compilation, or I can install it directly in the program directory to
> run.
>
> By publishing it, Olly (or I) can add it to the Debian version so it's
> out there for those users very soon. For other users, they have to wait
> until
> there is a new upstream release including it.
>

Hi,

thank you Evaristo for the updates.

The best way to include your changes into Therion is to create a pull
request (https://help.github.com/articles/about-pull-requests/) for the
Therion repository on Github (https://github.com/therion/therion/). Stacho
or I can then merge it; after that the Windows installer is updated
automatically in a few minutes.

I already incorporated this set of changes (Olly's typo fix included).

Best regards,
Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Scrap limits

[Martin Budaj via Therion]

Hi,

there is no change regarding the limits in Therion. If there is a real
need, following could be done:

- in the current version of MetaPost, it's possible to used "double"
arithmetic just by specifying a command line option, which practically
eliminates MetaPost limits

- instead of pdfTeX we could use LuaTeX to produce the PDFs. This
doubles the number of registers available from 32768 to 65536.
Registers are needed to reference the fragments of all
scraps/sections; you usually need up to 6 of them for a scrap. So you
would get maybe 12000 instead of 6000 scraps in one output file. It
would require some substantial work to support LuaTeX (there is e.g.
completely different font handling compared to PdfTeX).

And yes, the limit applies just to the data selected for export.

Martin


On Tue, Nov 28, 2017 at 9:44 PM, Benedikt Hallinger via Therion
 wrote:
> Maybe another question:
> Assume a large cave with thousands of scraps.
> When i make a thconfig file sourcing all that data, but using "select"
> statements i only select partial data,
> does the metapost limit apply to the whole dataset or just the scraps
> covered by the select command?
>
>
>
> Am 2017-11-28 22:19, schrieb Benedikt Hallinger via Therion:
>>
>> Hello Martin,
>> is the blow limit of 4096 scraps still valid in the current version?
>> Or is it already fixed so we can use more scraps?
>>
>>
>>
>>> On Tue, Dec 1, 2009 at 5:26 PM, Carl Magnuson 
>>> wrote:

 It looks like the solution is to issue the following metapost command:
 warningcheck := 0;
>>>
>>>
>>> Indeed. The new limit will be 32768 and could not be increased further
>>> in Metapost itself.
>>>
>>> The solution would be modification of how therion manages metapost
>>> pictures (currently they are stored in files data.1 to data.4000, with
>>> files data.4001 to data.4095 reserved for pattern definitions). This
>>> numbering scheme could be modified to allow more file name prefixes
>>> and consequently theoretically unlimited number of scraps processed by
>>> metapost.
>>>
>>> On the other hand there is still pdfTeX limit which would not allow
>>> much more scraps. PdfTeX uses internal registers for scraps
>>> referencing (scrap data is included only once in pdf file and can be
>>> referenced on multiple pages). You could avoid pdftex limit by using
>>> SVG output (if SVG viewers would process large number of internal
>>> references).
>>>
>>> In the longer-term future (a few years) I would like to use metapost
>>> as a library instead of external metapost executable, which would
>>> solve the problems with temporary files (and other problems as well).
>>>
 However adding it in a
 code metapost
 warningcheck := 0;
 endcode
 block seems to have no effect, mpost still fails on more then 4096
 scraps.
>>>
>>>
>>> Therion currently inserts warningcheck:=1; before scraps without good
>>> reason, so it will be fixed soon.
>>>
>>> If the new warningcheck setting would work for you, I would prefer not
>>> to modify current file numbering scheme for metapost pictures and have
>>> it fixed later with implementation of metapost library.
>>>
>>> Martin
>>
>> ___
>> 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 mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Therion 5.4.1

[Martin Budaj via Therion]

Hi,

the installer should be fixed now (for both 5.4.1 and the development
version).

Martin


On Wed, Apr 19, 2017 at 8:06 AM, Евгений via Therion 
wrote:

> Hello!
>
> I have some problem with installation of Therion 5.4.1.
> When pushing the button "install", occurs error: "Folder names cannot
> include of the following characters: / : * ? " < > |".
>
> Could you say what am I doing wrong? Or may be there is a bug?
> My OS is windows 10 Pro x64, version 1703, build 15063.138.
>
> Here is a screenshot:
>
>
> Evgeniy
>
> ___
> 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 version of Therion 5.4.0 available

[Martin Budaj via Therion]

Check https://github.com/therion/therion/blob/master/CHANGES

Martin

On Fri, Apr 7, 2017 at 5:39 AM, rowena_l--- via Therion
 wrote:
> Hi,
>
> Is there a summary of new features in the 5.4.0 release?
>
> thanks,
>
> Rowena
>
>
> - Original Message -
> From:
> "List for Therion users" 
>
> To:
> "List for Therion users" 
> Cc:
> "Martin Sluka" 
> Sent:
> Wed, 05 Apr 2017 21:22:44 +0200
> Subject:
> [Therion] New version of Therion 5.4.0 available
>
>
>
> On Github!
>
> No any 1th April!
>
> m.s.
>
>> 5. 4. 2017 v 20:02, Olly Betts via Therion :
>>
>> On Sun, Apr 02, 2017 at 11:49:54PM +0200, Benedikt Hallinger via Therion
>> wrote:
>>> The source giving causing it is:
 fix 1.0 x y z 0 0 0
>>>
>>> If i remove the standard-deviation zeros, cavern stops to complain.
>>>
>>> The reason was that the entrance location was measured by public service
>>> against official grid by theodolite and as such is "perfectly correct".
>>> How can i give this information? Am i forced to use some minimal positive
>>> fraction? (eg. "0.1"?)
>>
>> Just omit the SDs - that means it's an exact fix.
>>
>>> If yes, could this be an cavern bug?
>>
>> It's really a bug in the .svx file therion generates - it should omit
>> the zero SDs even if they're explicitly specified in the .th file, since
>> the documented syntax for an exact *FIX command is that you omit the SDs.
>>
>> 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
>
>
> ___
> 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] Current Therion for Windows version 13Mar2017

[Martin Budaj via Therion]

>
> One request, if the new build(s) could have the version identifier in the
> UI and /thversion variable updated; they still read 5.3.16.  Perhaps
> ‘5.3.16 13Mar2017’ or the like, would help with identifying which version I
> have active, and from which version pdf outputs were created.
>
>
>
Implemented in a form:

X.Y.Z (-MM-DD) for releases
X.Y.Z+short_commit_id (-MM-DD) for other commits subsequent to a release

Martin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Declination handling imprecise?

[Martin Budaj via Therion]

On Sat, Feb 18, 2017 at 9:20 AM, Benedikt Hallinger via Therion
 wrote:
> If therion calculates the average position of all fixed points this is fine.
> the cave spans about 5km w/e and about 3km n/s.

The change in declination over 5 km distance in your area is about 1'
which is completely negligible for compass surveys.

> I strongly dont think this is the error source as it is also visible in the
> test file.

The problem with your test file is that the declination on 2013-12-31
should be 3.08 degrees, not 3.8. If you use 3.08 (or more precisely
3.08), than the error in the test file is less than 20 cm on 2 km
legs. You should also take into account that the declination value at
GFZ Potsdam is rounded to the nearest minute.

> Also, calculating the igrf for each station should not be
> neccessary unless there are some strong amd small local anomalys which is
> not the case here.

IGRF model does not take local anomalies into account anyway.

> However i have seen that it looks like the calculated declination is maybe
> rounded to full degrees? Or is this just an display thing in aven viewer?

No rounding in therion here.

> Based on what you have said, i would assume that the problem source lies in
> therion itself summarizing all centreline dates into one survey average
> date, and not just by centerline as i would assume, when each centerline has
> a date specification.

The automatic declination is bound to centreline. You can check it
also in your example if you change the date of the first centerline to
e.g. 1950.

Maybe there is some other source of error in the data?

Martin

> Am 2017-02-17 23:26, schrieb Olly Betts:
>>
>> On Fri, Feb 17, 2017 at 07:08:48PM +0200, Benedikt Hallinger via Therion
>> wrote:
>>>
>>> i found out that the declination handling seems to be somewhat
>>> inaccurate.
>>> The produced error is marginal and negligible with small caves, however i
>>> am
>>> currently working on a system with >100km and this produces errors of
>>> >10m
>>> there.
>>
>>
>> Therion calculates all declination values at the same location (the
>> average
>> location of all the fixed points), which is potentially problematic if
>> your
>> survey spans that sort of distance.  I wonder if this might actually be
>> the
>> source of your problems.
>>
>> Survex requires specifying the location to calculate declination values
>> at,
>> and you can use different locations for different parts of the survey
>> hierarchy.  So keeping your centreline data in Survex format and feeding
>> therion a 3d file would be one solution if this is the issue you're
>> hitting.
>>
>> (Using the actual location of the station the reading was taken at is hard
>> as you need the declination value to calculate that location.  It would
>> also be
>> fairly slow to evaluate the IGRF model at every station where a compass
>> was
>> read.)
>>
>>> What i observe is the following:
>>> - Therion seems to use the first day of any given year referenced by
>>> "date"
>>> command.
>>
>>
>> If that's from looking at therion's log file, the "geomag declinations
>> (deg)"
>> table there is just a summary.  It indeed shows the values on January 1st
>> of
>> each "interesting" year, but doesn't reflect the dates actually being used
>> to
>> calculate declinations for surveys.
>>
>> Or was that from looking at the source code?  The get_start_year() and
>> get_end_year() methods actually return a fractional year value, not just
>> the
>> year of the survey.  The fraction is calculated assuming each month is
>> 1/12 of
>> the year - not quite right, but probably not a significant error in
>> practice.
>>
>>> - If a survey was taken at the end of a year it seems that the 1.1 of the
>>> following year will be used (i assume this happens at mid-year).
>>> - This approach looses at most half a years magnetic drift.
>>> This alone is acceptable as the data by itself is already not that
>>> accurate.
>>>
>>> However if you have several centerlines in the survey, each with
>>> different
>>> date-commands, therion seems to calculate the average of all dates and
>>> then
>>> uses the calculated declination for that date (applying the rule above,
>>> so
>>> taking the "closest 1.1.").
>>> This is then applied to all shots of the whole survey.
>>
>>
>> Not sure - I don't know therion's code that well.
>>
>>> A possible solution to this seems, to get the correct declination for
>>> each
>>> date and explicitely write suitable "declination" commands that override
>>> the
>>> "date"-calculated values. This then gives the proper results.
>>
>>
>> This approach is less than ideal, and not just because it's a significant
>> effort.
>>
>> Each generation of the IGRF model is necessarily predictive for dates
>> after it
>> was issued and only declared to be definitive for dates more than 5 years
>> before it was issued.  So each new generation of the model can change the
>> declination figures reported for the last 10 years compared to the

Re: [Therion] Wiki search finds not much

[Martin Budaj via Therion]

Hi,
the search index was updated; the problem should be fixed.
Martin

On Wed, Jan 25, 2017 at 9:00 AM, Bruce Mutton via Therion
 wrote:
> I noticed just now that the search at the top of the Therion wiki page does
> not return many results.
>
> https://therion.speleo.sk/wiki/doku.php
>
>
>
> For example, searching for 'history' (without quotes) returns no results,
> and yet on the wiki start page there is a link "History of Therion"
>
>
>
> And searching for 'survex' finds two results, on the tips page, but does not
> find the three instances of "survex" on the start page.
>
> I’m sure there must be many more references to survex.
>
>
>
> I am using Chrome on Windows 10
>
>
>
> Bruce
>
>
>
>
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion