Re: [Therion] 5.4.3 has broken output cs conversions

[Stacho Mudrak via Therion]

Hi Bruce,

thanks for finding this serious bug out. It should be fixed in the latest
commit. Could you please check, whether it works for you?

S.

On Thu, 7 Mar 2019 at 10:43, Bruce Mutton via Therion 
wrote:

> Therion version 5.4.3 and subsequent development versions have broken the
> functionality whereby coordinates entered with a variety of coordinate
> systems are converted to a user selected coordinate system for output.
>
> The 5.4.2 output attached is from the last installation file I have that
> gives a correct output (all coordinates start with 159), and the next one,
> 5.4.3 and all subsequent versions have coordinates some 1000 km apart.  It
> makes it a very long cave, but unfortunately two of the entrances are in
> the middle of the pacific ocean!  The problem is that Therion is assuming
> that they are all in the  chosen output coordinate system, but it is not
> performing any conversion.  No errors are reported (although there are
> mysterious scale related errors in other datasets that could be as a result
> of this problem).
>
>
>
> I am using these coordinate systems for input;
>
> cs EPSG:2193  #NZ Transverse Mercator 2000
>
> cs EPSG:27200 #NZ Map Grid 1949
>
> cs lat-long
>
>
>
> and for output in this case I am using;
>
> cs EPSG:2193  #NZ Transverse Mercator 2000
>
>
>
>
>
> 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] Height numbers in square boxes

[Stacho Mudrak via Therion]

Hi Bill,

we have rearranged therion metapost code in latest commits and now (using
last devel build) it should be possible to have boxed height labels just by
using following code in your layout:

code metapost
p_label_mode_height:=6;
endcode

The magic number 6 stands for boxed label. See
https://github.com/therion/therion/blob/master/mpost/thText.mp#L85 for list
of all label modes.

Please let us know, if this is what you have been looking for or more
complicated changes are needed.

S.

On Wed, 19 Sep 2018 at 23:35, Bill Gee via Therion 
wrote:

> Hello everyone -
>
> A common convention around Missouri cave mapping is to indicate the height
> change of a floor step by enclosing the value in a square box.  This is
> not
> the same as ceiling height which is enclosed in a circle or oval.
>
> I have been using the object "point height" for this.  It works except
> there
> is nothing around the value.  It just hangs out in space, so to speak.
>
> I used the "-d" option to dump all the MetaPost and TeX code.  I find no
> references in any of the files to objects of type height or
> passage-height,
> which implies that these two objects are not generated by MetaPost.
>
> Is it possible to redefine the "point height" symbol so it draws a square
> box
> around the value?
>
> 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] Eurospeleo 2018

[Stacho Mudrak via Therion]

Hi everybody,

eurospeleo meeting in Austria starts tomorrow. Me and Martin (Budaj), we
are leaving there tomorrow and we will be there until Surveying workshop on
Sunday afternoon. If you are interested, we could meet at welcome ceremony.


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

Re: [Therion] Error while compiling on mac

[Stacho Mudrak via Therion]

Oops, a mistake. Should be fixed now.

S.

On 15 February 2018 at 18:05, Philippe Vernant via Therion <
therion@speleo.sk> wrote:

> Thanks Stacho,
>
> No more issue with thbezier, but now :
>
> gcc -c -DIMG_API_VERSION=1 -Wall -DTHMACOSX -std=c++11 -O2 -o
> extern/getopt.o extern/getopt.c
> error: invalid argument '-std=c++11' not allowed with 'C/ObjC'
> make: *** [extern/getopt.o] Error 1
>
> 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] Spanish translation

[Stacho Mudrak via Therion]

There is also second commit with your Spanish translation update. But
compilation takes some time - so it occurs with cca 1/2 hour delay after
commit. But it should be already there.

S.

On 15 February 2018 at 17:34, Evaristo Quiroga via Therion <
therion@speleo.sk> wrote:

> I see today (2018/02/15) a new development  Therion version (*e1ff09b
> )*, with windows
> compilation.
>
> In the github, I see the thlang and xtherion/lang don't have changed.
>
> Two weeks ago I send this messages with the updated spanish translation of
> the texts.txt and xtexts.txt, and I had asked if someone can compile a new
> windows version to incorporate the new spanish translation.
>
> Thanks,
>
> Evaristo.
>
>
> El 03/02/2018 a las 20:51, Evaristo Quiroga via Therion escribió:
>
> Hi,
>
> In order to accelerate the learning curve of Therion, and convince more
> other club members (not English speaking), and I have updated the Therion
> and Xtherion Spanish translation, filling the empty  "es"  in the files
> texts.txt and xtexts.txt.
>
> I need someone to incorporate this files to the program, and make a new
> Windows compilation to have a new windows binary  with the new spanish
> translation to distribute to the spanish community.
>
> Thanks,
>
> Evaristo Quiroga
>
>
>
>
> ___
> Therion mailing 
> listTherion@speleo.skhttps://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] Error while compiling on mac

[Stacho Mudrak via Therion]

I have just commited thbezier.cxx patch to github. Could you please let me
know, whether it worked?

Thanks, S.

On 15 February 2018 at 15:34, Philippe Vernant via Therion <
therion@speleo.sk> wrote:

> Hi guys,
>
> I have a problem while compiling on mac OSX Sierra, I have an error with
> thbezier.o ? Anyone had the same issue and find a way to work around ?
> Several problems are related to is NaN.
>
> 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] Scrap limits

[Stacho Mudrak via Therion]

I am sorry, I am not sure I understand.

The problem is, if there are two lines in two different scraps within one
.th2 file starting or ending from point with same coordinates, therion
automatically creates a join between them. In your file, each of line of
5000 scraps are the same. Therefore they start and end at same points.
Therefore therion automatically creates 5000x5000 joins for each line end.
And this is the problem. I have modified your script to add some randomness
to the coordinates (just shift every scrap by random vector) and it solves
the problem.

S.



On 29 December 2017 at 15:42, Benedikt Hallinger via Therion <
therion@speleo.sk> wrote:

> Shouldnt they be placed at the actual position according to station
> coordinates prior joining, ie the scrap point reference coordinates be
> local to its namespace?
>
> Am 2017-12-29 11:20, schrieb Stacho Mudrak via Therion:
>
>> ​Hello, I have not investigated to details a lot, but the problem with
>> this huge file is search for automatic joins. All the scraps are in one
>> giant file and have a lot of common points so it tries to auto-connect
>> every scrap with every scrap, therefore n^2 memory usage. Situation that
>> should not happen in reality.
>>
>> If you apply attached patch and disable automatic scrap joins - therion
>> runs smoothly even with such a giant structure. But more proper solution
>> would be to shift every scrap, that they will not have common points.
>>
>> S.
>>
>> diff --git a/thdb2d.cxx b/thdb2d.cxx
>> index b8c9720..7d7b72e 100644
>> --- a/thdb2d.cxx
>> +++ b/thdb2d.cxx
>> @@ -2428,6 +2428,7 @@ void thdb2d::pp_process_joins(thdb2dprj * prj)
>>
>>// prida na koniec automaticke joiny
>>jci = joincandlist.begin();
>> +  jci = joincandlist.end();
>>while (jci != joincandlist.end()) {
>>  njci = jci;
>>  njci++;
>>
>> ​
>>
>> On 27 December 2017 at 13:26, Benedikt Hallinger via Therion <
>> therion@speleo.sk [14]> wrote:
>>
>> Hello,
>>> for further testing i wrote a small script generating a sample cave of
>>> variable length.
>>>
>>> The bash-script generateTestCave.sh generates a th-file one main survey
>>> and *n* linked subusrveys with included scrap and is called as following:
>>>   ./generateTestCave.sh  test.th [9]
>>> eg "./generateTestCave.sh 1000 test.th [10]" generates a survey "test"
>>> containing 1000 linked subsurveys containing each a suitable inline-copy of
>>> the scrap.th [11]. On the main "test"-survey level also for each
>>> subsurvey a "map n-Plan" is generated.
>>> This is then selected in the "thconfig" file.
>>>
>>> With the contained thconig file one can pay a little to explore behavior.
>>>
>>> What i encounter is the following unexepected:
>>> With raising survey count the memory needed and time to compile
>>> increases very heavily. This is DESPITE i only select 3 distinct maps for
>>> output in lox and pdf plan projection.
>>> Why is that so? i expected, that the selection influences the scraps
>>> selected and thus compile time should nearly remain constant (at least only
>>> increase slightly due to more data processed and discarded)?
>>> Also, in the mailing list there was an encounter of strange behavior of
>>> the select/unselect command - do we have a bug here somewhere that also
>>> causes the behavior i see here?
>>>
>>> Am 2017-12-03 10:41, schrieb Benedikt Hallinger:
>>>
>>> Thank, how could i switch this?
>>>> I also wrote a small testcase that segfaulted at about 3000 scraps.
>>>>
>>>> Am 2017-12-02 9:55, schrieb 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, its 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 o

Re: [Therion] Scrap limits

[Stacho Mudrak via Therion]

​Hello, I have not investigated to details a lot, but the problem with this
huge file is search for automatic joins. All the scraps are in one giant
file and have a lot of common points so it tries to auto-connect every
scrap with every scrap, therefore n^2 memory usage. Situation that should
not happen in reality.

If you apply attached patch and disable automatic scrap joins - therion
runs smoothly even with such a giant structure. But more proper solution
would be to shift every scrap, that they will not have common points.

S.

diff --git a/thdb2d.cxx b/thdb2d.cxx
index b8c9720..7d7b72e 100644
--- a/thdb2d.cxx
+++ b/thdb2d.cxx
@@ -2428,6 +2428,7 @@ void thdb2d::pp_process_joins(thdb2dprj * prj)

   // prida na koniec automaticke joiny
   jci = joincandlist.begin();
+  jci = joincandlist.end();
   while (jci != joincandlist.end()) {
 njci = jci;
 njci++;


​

On 27 December 2017 at 13:26, Benedikt Hallinger via Therion <
therion@speleo.sk> wrote:

> Hello,
> for further testing i wrote a small script generating a sample cave of
> variable length.
>
> The bash-script generateTestCave.sh generates a th-file one main survey
> and *n* linked subusrveys with included scrap and is called as following:
>   ./generateTestCave.sh  test.th
> eg "./generateTestCave.sh 1000 test.th" generates a survey "test"
> containing 1000 linked subsurveys containing each a suitable inline-copy of
> the scrap.th. On the main "test"-survey level also for each subsurvey a
> "map n-Plan" is generated.
> This is then selected in the "thconfig" file.
>
> With the contained thconig file one can pay a little to explore behavior.
>
> What i encounter is the following unexepected:
> With raising survey count the memory needed and time to compile increases
> very heavily. This is DESPITE i only select 3 distinct maps for output in
> lox and pdf plan projection.
> Why is that so? i expected, that the selection influences the scraps
> selected and thus compile time should nearly remain constant (at least only
> increase slightly due to more data processed and discarded)?
> Also, in the mailing list there was an encounter of strange behavior of
> the select/unselect command - do we have a bug here somewhere that also
> causes the behavior i see here?
>
>
>
>
>
> Am 2017-12-03 10:41, schrieb Benedikt Hallinger:
>
>> Thank, how could i switch this?
>> I also wrote a small testcase that segfaulted at about 3000 scraps.
>>
>> Am 2017-12-02 9:55, schrieb 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
>> referen

Re: [Therion] Development 5.4.1+4369eea inverts and recolours altitude legend

[Stacho Mudrak via Therion]

Great, thanks for testing it. If it works, then no need for that sample.

S.



On Dec 14, 2017 6:12 PM, "Bruce Mutton via Therion" 
wrote:

Hi Stacho

Therion-setup-dev-e7e9d34 has fixed both problems.  I have double checked,
and if 4369eea is reinstalled the ‘out of order’ colours reappear.

Do you still want a sample for future reference?

Bruce



*From:* Therion [mailto:therion-boun...@speleo.sk] *On Behalf Of *Stacho
Mudrak via Therion
*Sent:* Friday, 15 December 2017 3:48 AM

*To:* List for Therion users 
*Cc:* Stacho Mudrak 
*Subject:* Re: [Therion] Development 5.4.1+4369eea inverts and recolours
altitude legend



Hi Bruce,



I have fixed the altitude coloring in latest commit, but I was not able to
reproduce your strange coloring of scraps. For me it seems to work fine.



Could you please send me some data sample for inspection of this bug?



Thanks, S.



On 9 December 2017 at 04:52, Bruce Mutton via Therion 
wrote:

Stacho

FYI not only are the colours inverted, but they are a bit out of order as
well.

Refer the images.



I have not used any lookup syntax yet, partly as I am keeping my projects
compatible with earlier Therion versions.

These were generated with 5.4.1+ce29e7b



Bruce









*From:* Therion [mailto:therion-boun...@speleo.sk] *On Behalf Of *Stacho
Mudrak via Therion
*Sent:* Thursday, 9 November 2017 11:54 PM
*To:* List for Therion users 
*Cc:* Stacho Mudrak 
*Subject:* Re: [Therion] Development 5.4.1+4369eea inverts and recolours
altitude legend



Hi Bruce,



thanks for pointing out this bug. I will check the order of numbers, I have
probably made some mistake when dealing with automatic color scale
generation.



I have rewritten the scale code completely, but I had no time until now to
write the docs. But if you want to try, something like that should now work
in the layout:



lookup altitude -title "Altitude legend"

700 [100 0 0] "700 m a.s.l."

680

660

640

620

600 [0 0 100] "below 600 m"

endlookup



It should generate red -> blue scale with desired values. Also explo-date,
topo-date should now work with addition to maps, scraps. E.g.



export map -layout-color map-fp topo-date



and for example:



lookup topo-date

2010.12.31 [] "2010 and before"

2011.12.31 [] 2011

2012.12.31 [] 2012

- [] "2013 and later"

endlookup



You may specify multiple lookup tables for same criterion using ":"
separator in label



lookup altitude:scale1

600

800

endlookup



and



lookup altitude:scale2

800

750

700

endlookup



and use then "color map-fg altitude:scale1" or "color map-fg
altitude:scale2"



You may use also:



lookup maps

map1@some_survey [color]

map2 [color]

map3 [color]

endlookup



Same should work with scraps. With maps, also more simple way should work -
you may specify color of a particular map within selection.



select map1 -color [100 0 0]



Also intervals should work:



lookup altitude

[1500 1600] [] "cave floor 1"

[1800 1900] [] "cave floor 2"

endlookup



If you are willing to try, I would appreciate any feedback. Probably there
are a lot of bugs because a lot of use-cases. I was not able to test them
all.



S.



On 2 November 2017 at 10:05, Bruce Mutton via Therion 
wrote:

I’ve just noticed that the latest development snapshot 5.4.1+4369eea seems
to have messed with the altitude legend.

You can see from the screenshot below, which shows part of identical
project compilations, one with 9d96803 and then one with 4369eea.

Pretty sure I have not made any other changes that could have caused this
at my end, and I see that some of the intervening commits on github relate
to colour changes.



Neutral (perhaps) changes are that there are more colour bands and the
colours are brighter, in the legend at least, though not in the map.

A negative change is that the altitude range is now upside down.



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

Re: [Therion] Development 5.4.1+4369eea inverts and recolours altitude legend

[Stacho Mudrak via Therion]

Hi Bruce,

I have fixed the altitude coloring in latest commit, but I was not able to
reproduce your strange coloring of scraps. For me it seems to work fine.

Could you please send me some data sample for inspection of this bug?

Thanks, S.

On 9 December 2017 at 04:52, Bruce Mutton via Therion 
wrote:

> Stacho
>
> FYI not only are the colours inverted, but they are a bit out of order as
> well.
>
> Refer the images.
>
>
>
> I have not used any lookup syntax yet, partly as I am keeping my projects
> compatible with earlier Therion versions.
>
> These were generated with 5.4.1+ce29e7b
>
>
>
> Bruce
>
>
>
>
>
>
>
>
>
> *From:* Therion [mailto:therion-boun...@speleo.sk] *On Behalf Of *Stacho
> Mudrak via Therion
> *Sent:* Thursday, 9 November 2017 11:54 PM
> *To:* List for Therion users 
> *Cc:* Stacho Mudrak 
> *Subject:* Re: [Therion] Development 5.4.1+4369eea inverts and recolours
> altitude legend
>
>
>
> Hi Bruce,
>
>
>
> thanks for pointing out this bug. I will check the order of numbers, I
> have probably made some mistake when dealing with automatic color scale
> generation.
>
>
>
> I have rewritten the scale code completely, but I had no time until now to
> write the docs. But if you want to try, something like that should now work
> in the layout:
>
>
>
> lookup altitude -title "Altitude legend"
>
> 700 [100 0 0] "700 m a.s.l."
>
> 680
>
> 660
>
> 640
>
> 620
>
> 600 [0 0 100] "below 600 m"
>
> endlookup
>
>
>
> It should generate red -> blue scale with desired values. Also explo-date,
> topo-date should now work with addition to maps, scraps. E.g.
>
>
>
> export map -layout-color map-fp topo-date
>
>
>
> and for example:
>
>
>
> lookup topo-date
>
> 2010.12.31 [] "2010 and before"
>
> 2011.12.31 [] 2011
>
> 2012.12.31 [] 2012
>
> - [] "2013 and later"
>
> endlookup
>
>
>
> You may specify multiple lookup tables for same criterion using ":"
> separator in label
>
>
>
> lookup altitude:scale1
>
> 600
>
> 800
>
> endlookup
>
>
>
> and
>
>
>
> lookup altitude:scale2
>
> 800
>
> 750
>
> 700
>
> endlookup
>
>
>
> and use then "color map-fg altitude:scale1" or "color map-fg
> altitude:scale2"
>
>
>
> You may use also:
>
>
>
> lookup maps
>
> map1@some_survey [color]
>
> map2 [color]
>
> map3 [color]
>
> endlookup
>
>
>
> Same should work with scraps. With maps, also more simple way should work
> - you may specify color of a particular map within selection.
>
>
>
> select map1 -color [100 0 0]
>
>
>
> Also intervals should work:
>
>
>
> lookup altitude
>
> [1500 1600] [] "cave floor 1"
>
> [1800 1900] [] "cave floor 2"
>
> endlookup
>
>
>
> If you are willing to try, I would appreciate any feedback. Probably there
> are a lot of bugs because a lot of use-cases. I was not able to test them
> all.
>
>
>
> S.
>
>
>
> On 2 November 2017 at 10:05, Bruce Mutton via Therion 
> wrote:
>
> I’ve just noticed that the latest development snapshot 5.4.1+4369eea seems
> to have messed with the altitude legend.
>
> You can see from the screenshot below, which shows part of identical
> project compilations, one with 9d96803 and then one with 4369eea.
>
> Pretty sure I have not made any other changes that could have caused this
> at my end, and I see that some of the intervening commits on github relate
> to colour changes.
>
>
>
> Neutral (perhaps) changes are that there are more colour bands and the
> colours are brighter, in the legend at least, though not in the map.
>
> A negative change is that the altitude range is now upside down.
>
>
>
> 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] How to move a line in xtherion

[Stacho Mudrak via Therion]

Sorry, it was not, I have put it there after your suggestion :)

On Dec 4, 2017 8:24 PM, "Benedikt Hallinger via Therion" 
wrote:

> Thank you very much, i was not aware that it already was in the wiki :)
>
> Am 2017-12-04 12:18, schrieb Stacho Mudrak via Therion:
>
>>
>> https://therion.speleo.sk/wiki/tips#moving_lines_and_scraps_
>> within_drawing_area [6]
>>
>> Feel free to modify it.
>>
>> S.
>>
>> On 4 December 2017 at 10:52, Benedikt Hallinger via Therion <
>> therion@speleo.sk [7]> wrote:
>>
>> It would be very good if one could add this to the wiki and/or book :)
>>>
>>> Am 2017-12-04 0:00, schrieb Bruce Mutton via Therion:
>>>
>>> Very cool.
>>>>
>>>> If I might expand on the instructions, as I almost did not figure out
>>>> the easy way.
>>>>
>>>> * Create or select a point (or line point) that defines the
>>>> start of the movement vector.  Click ‘shift from’.
>>>> * Create or select a point that defines the end (destination)
>>>> of the movement vector.  Click ‘shift to’.
>>>> * If you did that in the wrong order, click ‘Swap’ to swap the
>>>> vector coordinates.
>>>> * Select the object (point or line) that you want to move.
>>>> Click ‘Shift object’.
>>>> * Repeat step 4 until you have moved all the objects that you
>>>> wish to move.
>>>>
>>>> (for version 5.4.1 + ce29e7b)
>>>>
>>>> Bruce
>>>>
>>>> FROM: Therion [mailto:therion-boun...@speleo.sk [1]] ON BEHALF OF
>>>> Stacho Mudrak via Therion
>>>> SENT: Sunday, 3 December 2017 11:04 PM
>>>> TO: List for Therion users 
>>>> CC: Stacho Mudrak 
>>>> SUBJECT: Re: [Therion] How to move a line in xtherion
>>>>
>>>> Hello, ​I have just posted a commit, that enables movement of selected
>>>> object in xtherion (line or area) according to specified vector.
>>>>
>>>> It is not interactive (too much work), but you can select or enter 2
>>>> points of vector and move entire line or scrap just by one click. Controls
>>>> for this feature are at the end of objects toolbar.
>>>>
>>>> S.
>>>>
>>>
>>> ___
>>> Therion mailing list
>>> Therion@speleo.sk [4]
>>> https://mailman.speleo.sk/listinfo/therion [5]
>>>
>>
>>
>>
>> Links:
>> --
>> [1] mailto:therion-boun...@speleo.sk
>> [2] mailto:therion@speleo.sk
>> [3] mailto:li...@group-s.sk
>> [4] mailto:Therion@speleo.sk
>> [5] https://mailman.speleo.sk/listinfo/therion
>> [6] https://therion.speleo.sk/wiki/tips#moving_lines_and_scraps_
>> within_drawing_area
>> [7] mailto:therion@speleo.sk
>>
>
> ___
> 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] How to move a line in xtherion

[Stacho Mudrak via Therion]

https://therion.speleo.sk/wiki/tips#moving_lines_and_scraps_within_drawing_area

Feel free to modify it.

S.

On 4 December 2017 at 10:52, Benedikt Hallinger via Therion <
therion@speleo.sk> wrote:

> It would be very good if one could add this to the wiki and/or book :)
>
> Am 2017-12-04 0:00, schrieb Bruce Mutton via Therion:
>
>> Very cool.
>>
>> If I might expand on the instructions, as I almost did not figure out the
>> easy way.
>>
>> * Create or select a point (or line point) that defines the start
>> of the movement vector.  Click ‘shift from’.
>> * Create or select a point that defines the end (destination) of
>> the movement vector.  Click ‘shift to’.
>> * If you did that in the wrong order, click ‘Swap’ to swap the
>> vector coordinates.
>> * Select the object (point or line) that you want to move.  Click
>> ‘Shift object’.
>> * Repeat step 4 until you have moved all the objects that you
>> wish to move.
>>
>> (for version 5.4.1 + ce29e7b)
>>
>> Bruce
>>
>> FROM: Therion [mailto:therion-boun...@speleo.sk] ON BEHALF OF Stacho
>> Mudrak via Therion
>> SENT: Sunday, 3 December 2017 11:04 PM
>> TO: List for Therion users 
>> CC: Stacho Mudrak 
>> SUBJECT: Re: [Therion] How to move a line in xtherion
>>
>> Hello, ​I have just posted a commit, that enables movement of selected
>> object in xtherion (line or area) according to specified vector.
>>
>> It is not interactive (too much work), but you can select or enter 2
>> points of vector and move entire line or scrap just by one click. Controls
>> for this feature are at the end of objects toolbar.
>>
>> S.
>>
>
> ___
> 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] How to move a line in xtherion

[Stacho Mudrak via Therion]

Hello, ​I have just posted a commit, that enables movement of selected
object in xtherion (line or area) according to specified vector.

It is not interactive (too much work), but you can select or enter 2 points
of vector and move entire line or scrap just by one click. Controls for
this feature are at the end of objects toolbar.

S.

​

On 9 November 2017 at 11:22, Benedikt Hallinger via Therion <
therion@speleo.sk> wrote:

> It would be cool to be  able to cl7ck to a line point, and while pressing
> ctrl and move the mouse to m8ve the entire line.
>
>
> Am 2017-11-09 8:55, schrieb Martin Sluka via Therion:
>
>> 8. 11. 2017 v 20:47, Benedikt Hallinger via Therion :
>>>
>>> for the future: it would be very cool to have a nice drag&drop solution
>>> in the editor
>>>
>>
>> This feature is in Therion text editor too. Search/Replace too.
>>
>> But for me is regular plain text editor faster.
>>
>> m.s.
>> ___
>> 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] Development 5.4.1+4369eea inverts and recolours altitude legend

[Stacho Mudrak via Therion]

Hi Bruce,

thanks for pointing out this bug. I will check the order of numbers, I have
probably made some mistake when dealing with automatic color scale
generation.

I have rewritten the scale code completely, but I had no time until now to
write the docs. But if you want to try, something like that should now work
in the layout:

lookup altitude -title "Altitude legend"
700 [100 0 0] "700 m a.s.l."
680
660
640
620
600 [0 0 100] "below 600 m"
endlookup

It should generate red -> blue scale with desired values. Also explo-date,
topo-date should now work with addition to maps, scraps. E.g.

export map -layout-color map-fp topo-date

and for example:

lookup topo-date
2010.12.31 [] "2010 and before"
2011.12.31 [] 2011
2012.12.31 [] 2012
- [] "2013 and later"
endlookup

You may specify multiple lookup tables for same criterion using ":"
separator in label

lookup altitude:scale1
600
800
endlookup

and

lookup altitude:scale2
800
750
700
endlookup

and use then "color map-fg altitude:scale1" or "color map-fg
altitude:scale2"

You may use also:

lookup maps
map1@some_survey [color]
map2 [color]
map3 [color]
endlookup

Same should work with scraps. With maps, also more simple way should work -
you may specify color of a particular map within selection.

select map1 -color [100 0 0]

Also intervals should work:

lookup altitude
[1500 1600] [] "cave floor 1"
[1800 1900] [] "cave floor 2"
endlookup

If you are willing to try, I would appreciate any feedback. Probably there
are a lot of bugs because a lot of use-cases. I was not able to test them
all.

S.

On 2 November 2017 at 10:05, Bruce Mutton via Therion 
wrote:

> I’ve just noticed that the latest development snapshot 5.4.1+4369eea seems
> to have messed with the altitude legend.
>
> You can see from the screenshot below, which shows part of identical
> project compilations, one with 9d96803 and then one with 4369eea.
>
> Pretty sure I have not made any other changes that could have caused this
> at my end, and I see that some of the intervening commits on github relate
> to colour changes.
>
>
>
> Neutral (perhaps) changes are that there are more colour bands and the
> colours are brighter, in the legend at least, though not in the map.
>
> A negative change is that the altitude range is now upside down.
>
>
>
> 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] Aven colour by loop error

[Stacho Mudrak via Therion]

​Hello,

it is already fixed in the latest release and therion is parsing survex
.err file for loop errors and outputs sigmas to .3d file. ​You may compare
data.3d generated by survex (in thTMPDIR when -d is used) and therion
generated .3d file, that they are equal when colored by error.

S.

On 3 April 2017 at 03:49, Olly Betts via Therion  wrote:

> On Sat, Apr 01, 2017 at 09:10:02PM +1300, Bruce Mutton via Therion wrote:
> > The new capability of exporting loop closure information to 3d format is
> > helping to identify the bad loops on our surveys.
> >
> > Very nice.
> >
> > However the scalebar at the top right seems to be locked into a range of
> 0.0
> > to 12.0 (%) error.
>
> Aven's error scale isn't in %, but rather in "sigmas" - i.e. it's how many
> times the expected error the observed error is.  Assuming normal
> distribution
> of errors (which sums of random errors will tend towards) anything more
> than
> 3 is only 0.3% likely by random errors, so highly suspect:
>
> https://en.wikipedia.org/wiki/68%E2%80%9395%E2%80%9399.7_rule
>
> If what Stacho said back in February is still true, therion outputs the
> wrong data in this field in the 3d file, so you actually see "2 * relative
> error of a loop" there, by which I think he means percentage misclosure.
>
> But as I said at the time, percentage misclosure isn't really a useful
> measure of loop quality because the threshold of what is reasonable
> varies with the length of the loop:
>
> https://mailman.speleo.sk/pipermail/therion/2017-February/006300.html
>
> > This is OK for our really nasty loop closures; the maps look suitably
> > colourful, but some of our more recent cave surveys don't have error much
> > more than 1.5%, so the picture is kind of shades of blue, as below.  It
> > doesn't help with visualising the relative quality of the loops.
>
> Unless Stacho has since fixed this, you're actually seeing 0-6% there
> currently.
>
> > Would it be possible to change the default scalebar to something like
> 0.0 to
> > 2.0, with the upper limit stepping upwards to suit the data, if there are
> > larger loop errors?
>
> I'd much rather we fixed therion to export the correct error information.
> Trying to colour based on percentage error just seems to be fundamentally
> a less helpful approach.
>
> Also, not varying the colours for a particular number of sigmas depending
> on
> how bad the data is was a deliberate choice.  2 sigmas is no better or
> worse
> just because someone blundered a survey elsewhere.  And if data is
> surveyed to
> a lower quality the grades should be set appropriately to reflect that.
>
> 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] Current Therion for Windows version 13Mar2017

[Stacho Mudrak via Therion]

Hi Bruce,

thanks a lot for the feedback.


>- Loch v13Mar2017 beta works OK, except always crashes if I
>right-click to view the context menu (Loch v5.3.16is always just fine).
>
> ​This is probably related to cross-compilation. When I compile on Win32,
no such error occurs, but same error with downloaded version also on Win 7.
I will try to investigate the problem, but it will definitely take some
time.​

warning -- error deleting temporary directory --
> C:\Users\Bruce\AppData\Local\Temp\th10044
>

​I have no idea about this.​

>
>
>- For Therion v13Mar2017 beta version, only loop-closure survex
>tested: Crashes almost immediately while reading file, complaining about
>‘symbol-show point cave-station:fixed’ as per attached log file.  I’m
>guessing this unrelated to the loop closure method used.
>
> ./LayoutMapThisCave.thc [54] -- unknown symbol specification -- point
> cave-station:fixed
>
> writing xtherion file ... done
>

​Same error on my machine, I will try to fix it.​



>
>- Therion v13Mar2017 beta version crashes (similar to the image above)
>when there are two or more loops present, *unless* ‘loop-closure
>therion’ is *explicitly* set in therion.ini.  Tested on projects with
>zero, 1, 2 and up to 107 loops.  This seems a pretty reliable hypothesis,
>but I want to test a few more projects with 1, 2 and 3 loops to be sure.
>
>
​May be, this is related to reading of survex loop closure statistics,
which was added recently. I have tried on my dataset with survex loop
closure (which is default), but without any crash. Are you able to isolate
some small dataset, where this happens to you?

Thanks, S.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Depth seems to be including surface legs

[Stacho Mudrak via Therion]

Hmm, but it looks to me, that scale is only up to altitude 481m​, which is
altitude of entrance. No surface centerline taken into account.

S.

On 23 March 2017 at 16:17, Duncan via Therion  wrote:

> Yes the entrance is marked.
> I've attached the Aven view with entrances highlighted (Therion generated
> 3D file).
> Note that the surface legs have been excluded from the Aven presentation.
>
> Entrance was declared as follows:
> cs OSGB:XX
> fix 21 X X 480   # Tweaked to match Google Earth
> station 21 "Old Mine" entrance
> Coordinates blanked out at this time.
>
> Duncan
>
> On 23/03/2017 13:36, Martin Sluka via Therion wrote:
>
> Is there entrance marked?
>
> m.s.
>
> On Mar 23, 2017, at 02:04 PM, Duncan via Therion 
>  wrote:
>
> We surveyed the surface above an old mine to get a feel for how thin the
> roof is.
> See attached Loch screenshot.
>
> Unfortunately, the surface legs are being included in the Depth value
> displayed on the Plan PDF (see attached).
> Displayed value is 13m, it should be about 8m. 13m is the maximum
> vertical extent of all our survey legs.
>
> The centerline data for the surface legs has been flagged as "flags
> surface".
> These have been correctly omitted from the cave length, and cave length
> is updated when the surface flag is commented out. However, the vertical
> range does not alter when the surface flag is toggled.
>
> I expected cave depth to be the maximum vertical range of the
> underground data.
> Hope someone can set me straight :)
> Duncan
>
> 
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
>
>
> ___
> Therion mailing 
> listTherion@speleo.skhttps://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] Aven colour by loop error

[Stacho Mudrak via Therion]

Hi, I agree with Bruce, that it is really a very useful feature. I have
just pushed it on GitHub (see commit 2ebc7ed).

The only problem is, that survex calculates error which "is the ratio of
the observed misclosure to the theoretical one". I have implemented more
simple export (it was much easier), currently therion .3d export contains
error equal to 2 * relative error of a loop. (because of 0-12 aven fixed
error scale). It should be possible to extract survex relative error from
either thTMPDIR/data.err or data.3d file, but it will take some time.

But when I compared 3D files with relative loop error and error with survex
ratio, I received two quite different pictures. Are these two measures not
comparable? Is a relative error of a loop useless number? Has anybody tried
to go to a cave and resurvey "red shots", whether they are really so bad?

S.



On 22 February 2017 at 23:20, Olly Betts via Therion 
wrote:

> On Wed, Feb 22, 2017 at 09:34:03PM +, Footleg via Therion wrote:
> > Therion strips most of the data apart from staions and legs out of 3D
> files
> > it generates. Colour by error and by date are not possible because that
> > information is not in the 3D files generated from a Therion project.
> > Entrances are lost too. One of the reasons I plan to add Therion to
> Survex
> > conversion into my cave converter program (when time permits).
>
> Therion-generated .3d files now[*] contain date and coordinate system
> information, thanks to a patch from Vlad:
>
> https://github.com/therion/therion/commit/43e6630e3109196d2c
> 251f05e52c2663496419d9
>
> [*] This isn't in a released version of therion yet, but I'm guessing
> there's likely to be a new release soon as it's been years since 5.3.16
> and a lot of useful stuff has been merged recently.
>
> 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] Clino question

[Stacho Mudrak via Therion]

Hello,

I am sorry, but when I have tried, I was not able to reproduce your
problem. Could you please post some small sample, where this behavior
occurs?

Thanks, S.

On 15 February 2017 at 11:09, Torsten Schnitter via Therion <
therion@speleo.sk> wrote:

> Hi
>
> I get a strange problem with survey data and clino numbers.
> I  can't figure out the error and therefore need any help or advice.
>
> I have to stations with this data:
>   survey line_25
> centreline -id "line_25"
>   date 2014.09.23
>   cs lat-long
>   walls on
>   units compass degree
>   data normal from   to left right up   down tape compass
> backcompass clino backclino
>   
>   IMO113 IMO114  0.0  0.0   0.0  0.0 58.7 132
> 309   0.5  -2.0
>   
> endcentreline
>   endsurvey
>
> The output is shown in attached picture "Clino-Problem.jpg" which is
> elevation view of course.
>
> The problem is that this survey shot (grey line) is going much to high on
> the right side. The difference in height from left point to right point
> should be less than 1m (squares in background of image are 1m).
> I checked this with: sin(1.25°) x 58,7m = 1,28m. So the difference in
> height should be 1,28m.
> (The calculated average of clino should be 1,25°, shouldn't it!?)
> But the picture shows a difference of close to 5m related to the squares.
>
> To show this strange problem more easy I changed the clino and backclino
> numbers to 0 and expected a horizontal shot:
>   survey line_25
> centreline -id "line_25"
>   date 2014.09.23
>   cs lat-long
>   walls on
>   units compass degree
>   data normal from   to left right up   down tape compass
> backcompass clino backclino
>   
>   IMO113 IMO114  0.0  0.0   0.0  0.0 58.7 132
> 309   0.0  0.0
>   
> endcentreline
>   endsurvey
>
> The output is shown in attached picture "Clino-Zero.jpg" and as you can
> see the shot is not horizontal. The difference in height is around 4m. But:
> sin(0°) x 58,7m = 0m. So the difference in height should be zero.
>
> So what I'm missing or doing wrong?
>
> Thanks for you help,
> 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] First use of locally compiled Therion: metapost error

[Stacho Mudrak via Therion]

Hi,

I have finished implementation today, but it was a long term problem. Now
therion should compile without any additional therion.ini modifications. If
it does not find required fonts, it will not use them.

S.

On 21 February 2017 at 15:04, Rodrigo Severo via Therion 
wrote:

> Hi Stacho,
>
> 2017-02-21 8:48 GMT-03:00 Stacho Mudrak via Therion :
>
>> Hello,
>>
>> we have implemented Olly's proposal of tex-fonts-optional. It should work
>> now I believe, because all non standard TeX fonts used are now optional.
>>
>
> I'm not sure I understood. Have you implemented Olly's proposal after
> yesterday afternoon?
>
> I'm asking because I got Therion's code yesterday afternoon and that code
> got me the 768 metapost error that I had to fix by manually inserting the
> *text-fonts* line in /etc/therion.ini. And again, just copying the
> therion.ini would not have solved the issue as it has no uncommented lines
> in it.
>
> May be there should be a new text-fonts-optional line on source's
> therion.ini file. Is that what's missing now?
>
>
> Regards,
>
> Rodrigo
>
>
>
>>
>> S.
>>
>> On 21 February 2017 at 01:31, Rodrigo Severo via Therion <
>> therion@speleo.sk> wrote:
>>
>>> 2017-02-20 21:00 GMT-03:00 Olly Betts :
>>>
>>>> On Mon, Feb 20, 2017 at 08:40:36PM -0300, Rodrigo Severo via Therion
>>>> wrote:
>>>> > To fix it I had to include the following line on */etc/therion.ini*
>>>> >
>>>> > tex-fonts raw cmr10 cmti10 cmbx10 cmss10 cmssi10
>>>> >
>>>> > despite Therion Book stating at page 80 that this is the default
>>>> setting.
>>>> >
>>>> > Should this line be uncommented on the default *therion.ini* file?
>>>>
>>>> Do you have the Ubuntu package of therion installed too?
>>>>
>>>
>>> Yes, I do.
>>>
>>>
>>>> If so, my guess is that /etc/therion.ini is from that package.
>>>
>>>
>>> I bet it is.
>>>
>>>
>>>> Currently
>>>> the Debian (and hence Ubuntu) packages have a couple of patches in this
>>>> area - see the discussion here for details:
>>>>
>>>> https://github.com/therion/therion/pull/31
>>>>
>>>> Assuming I'm right, the quickest fix for your situation is probably to
>>>> copy
>>>> therion.ini from the source tree to /etc.
>>>>
>>>
>>> I just checked the diferences between *therion.ini* from the source
>>> tree and the one at */etc/therion.ini*. There are a few but all on
>>> lines that are commented, so they are irrelevant for this situation.
>>>
>>> The only diference on a non commented line is exactly the line I
>>> included in */etc/therion.ini* that is not present on the *therion.ini* file
>>> available at the source and also wasn't at */etc/therion.ini* until I
>>> included it myself.
>>>
>>> So, no, coping the *therion.ini* available at the source to
>>> */etc/therion.ini* wouldn't fix my issue.
>>>
>>> My issue is exactly the one discussed at the link you sent.
>>> Unfortunatelly that issue isn't solved yet.
>>>
>>> AFAICT, right now new Therion installations from source on Linux won't
>>> work because of error 768.
>>>
>>>
>>> Regards,
>>>
>>> Rodrigo
>>>
>>>
>>>
>>>>
>>>> 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] Troubles with the 3D generation

[Stacho Mudrak via Therion]

Hi, this is a problem of 3D generation algorithm of therion...

If a wall is relatively far away from centreline, height and dimensions
interpolation algorithm "averages too much". To overcome this, you need to
play with dimensions data for stations (putting some arbitrary large
numbers there - see example) or using "point dimensions -value [up down]"
in 2D plan somewhere near wall that needs to be affected.

But these are not nice changes. We should modify 3D generation algorithm to
solve these situations correctly.

S.

On 15 February 2017 at 13:23, Philippe Vernant via Therion <
therion@speleo.sk> wrote:

> Hi guys,
>
> Here is the .th and .th2 file from a survey of a large chamber. What I
> don’t understand is why the line survey is outside below  the chamber. Any
> advice on how to fix that ?
>
> Thanks,
> Phil
>
>
>
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
>
# 2016.06.05 created by TopoDroid v 3.1.1

survey test -title "Test"

  centerline
date 2016.06.04 
# declination 0.00 degrees
units length meters
units compass clino degrees
walls off


data normal from to length compass clino
extend right
0 - 6.92 140.9 0.2
0 - 9.02 171.8 7.1
extend left
0 - 4.31 203.5 -8.3
0 - 1.56 235.6 -16.0
extend right
0 - 4.36 95.7 -26.4
0 - 2.05 69.3 -25.9
0 - 5.80 110.8 -49.7
0 - 7.22 141.0 -55.7
extend left
0 - 9.17 187.4 -53.3
0 - 8.18 207.7 -68.7
extend right
0 - 13.11 115.4 -73.3
0 - 13.17 105.8 -73.8
0 1 17.30 175.1 -82.5
extend left
1 - 2.97 237.9 25.6
1 - 4.55 264.0 28.8
1 - 5.72 305.7 29.4
1 - 6.91 333.9 25.4
extend right
1 - 7.54 1.5 21.9
1 - 15.68 20.1 10.9
1 - 9.78 40.3 12.6
1 - 8.39 63.4 15.8
1 - 4.71 92.0 25.0
1 - 3.63 126.3 28.5
1 - 3.19 155.8 31.6
1 - 3.50 122.1 61.1
1 - 9.40 137.3 -17.1
1 - 19.01 130.0 -20.6
1 - 45.18 120.3 -17.8
1 - 21.47 121.2 -25.1
1 - 78.86 103.4 -24.9
1 - 81.04 90.7 -21.6
1 - 52.54 77.3 -20.9
1 - 44.48 74.6 -17.6
1 - 36.75 68.4 -15.6
1 - 75.90 62.5 -25.0
1 2 15.99 16.9 -24.2
extend left
2 - 17.85 297.6 7.5
2 - 14.74 295.6 26.7
2 - 14.43 289.5 50.6
2 - 10.28 306.8 73.0
2 - 11.29 333.0 52.6
2 - 19.53 329.2 21.9
2 - 25.92 316.8 8.8
2 - 34.97 339.0 5.9
extend right
2 - 22.31 5.0 14.0
2 - 13.19 12.6 34.8
2 - 20.65 21.6 3.5
2 - 32.13 21.0 -11.2
2 - 33.65 39.2 -17.2
2 - 31.03 45.7 -11.6
2 - 18.75 56.1 3.4
2 - 44.98 121.9 -10.4
2 - 29.90 119.2 -0.9
2 - 18.10 117.7 12.7
2 - 13.22 120.8 26.9
2 - 22.54 139.3 15.1
2 3 10.65 81.6 -31.5
extend left
3 - 14.19 357.6 -17.7
extend right
3 - 17.80 29.2 -28.7
3 - 4.76 41.9 -51.3
3 - 10.62 40.8 74.4
3 - 11.06 84.1 50.8
3 - 16.22 62.3 8.9
3 - 37.03 51.7 -11.6
3 - 29.60 43.3 -21.2
3 - 26.04 65.0 -27.7
3 - 66.50 81.8 -21.4
3 - 63.56 96.0 -18.7
3 - 64.02 96.3 -23.5
3 - 64.57 115.3 -9.6
3 - 31.38 116.0 -3.9
3 - 20.35 113.4 10.0
3 - 23.07 86.8 -33.0
3 4 23.06 76.1 -33.0
4 - 29.87 14.5 16.3
4 - 15.69 19.9 40.0
4 - 13.12 33.4 57.2
4 - 12.93 84.7 69.4
4 - 16.21 140.9 50.9
4 - 23.76 140.8 22.8
4 - 31.61 136.8 13.8
4 - 52.82 136.3 3.8
4 - 55.46 135.5 -6.2
4 - 0.98 94.5 -52.3
4 - 43.57 170.6 13.1
4 5 5.76 96.8 -16.4
5 - 26.15 23.1 4.9
5 - 18.76 27.2 17.7
5 - 13.19 46.5 35.5
5 - 12.49 86.5 42.9
5 - 14.14 77.7 18.7
5 - 19.02 74.2 3.2
5 - 26.41 54.3 -15.0
5 - 26.60 56.7 -14.1
5 - 29.97 95.5 -12.0
5 - 35.16 99.8 -10.1
5 - 37.14 97.5 -5.2
5 - 40.86 100.3 -4.8
5 - 42.24 101.7 0.5
5 - 41.12 101.5 5.6
5 - 43.58 103.4 -17.6
5 - 37.99 120.6 -13.6
5 - 43.51 123.4 3.6
5 - 44.54 127.7 9.9
5 - 17.77 107.1 -28.9
5 - 0.61 107.0 -28.8
5 6 17.78 88.7 -28.9
6 - 13.69 101.3 -13.8
6 - 14.00 44.6 20.3
6 - 16.79 59.7 19.1
6 - 22.11 68.0 -5.2
6 - 22.96 80.3 -13.5
6 - 20.40 86.6 -20.0
6 - 24.77 95.6 -7.3
6 - 25.54 105.4 6.7
6 - 29.25 112.8 32.7
6 - 26.65 147.0 39.8
6 - 34.44 162.0 32.0
6 - 45.91 168.0 23.1
6 - 51.12 167.3 13.8
6 - 47.10 161.6 0.4
6 - 34.91 143.7 -1.3
6 7 6.78 102.1 -21.2
6 8 21.54 178.0 0.2
extend left
8 - 18.57 264.6 73.8
8 - 20.67 218.2 58.2
8 - 25.39 191.3 40.4
8 - 2.29 287.7 -34.9
8 - 4.04 277.2 1.8
8 - 7.47 304.2 4.9
extend right
8 - 32.31 163.9 19.2
8 - 23.68 135.5 12.5
8 - 21.24 115.0 12.1
8 - 28.26 148.6 18.9
8 9 2.76 141.4 16.4
9 10 13.73 97.8 -11.4
10 - 32.23 9.1 3.1
10 - 10.60 20.8 3.9
10 - 5.93 47.9 6.4
10 - 5.90 74.7 11.3
10 - 5.47 105.6 15.9
10 - 7.73 138.9 11.3
10 - 9.60 158.4 10.6
10 - 18.34 177.6 13.4
extend lef

Re: [Therion] First compilation of Therion in Ubuntu 16.04

[Stacho Mudrak via Therion]

Hello,

I think that using libvtk6-dev (instead of libvtk-dev) would work without
modification of Makefile.

S.

On 20 February 2017 at 22:29, Rodrigo Severo via Therion 
wrote:

> 2017-02-20 15:39 GMT-03:00 Rodrigo Severo :
>
>>
>> I'm trying to compile Therion (sources from github) on Ubuntu 16.04 for
>> the first time.
>>
>> After installing several missing libraries I'm getting the following
>> error:
>>
>> make[1]: Entering directory '/home/rodrigo/devel/therion/loch'
>> c++ -o ./loch -Wall ./lxR2P.o ./lxTR.o ./lxOGLFT.o ./lxSetup.o
>> ./lxRender.o ./lxWX.o ./lxImgIO.o ./lxLRUD.o ./lxFile.o ./lxSTree.o
>> ./lxData.o ./lxMath.o ./lxSView.o ./lxSScene.o ./lxGUI.o ./lxGLC.o
>> ./lxOptDlg.o ./lxAboutDlg.o ./lxPres.o ./img.o -lwx_gtk2u_gl-3.0
>> -L/usr/lib/x86_64-linux-gnu -pthread   -lwx_gtk2u_xrc-3.0
>> -lwx_gtk2u_html-3.0 -lwx_gtk2u_qa-3.0 -lwx_gtk2u_adv-3.0
>> -lwx_gtk2u_core-3.0 -lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0
>>  -L/usr/lib/vtk-5.10 -lvtkHybrid -lvtkImaging -lvtkIO -lvtkGraphics
>> -lvtkFiltering -lvtkCommon -lfreetype -lGLU -lGL -lpthread -lX11 -lz -s
>> /usr/bin/ld: ./lxRender.o: undefined reference to symbol 'png_write_row@
>> @PNG12_0'
>> //lib/x86_64-linux-gnu/libpng12.so.0: error adding symbols: DSO missing
>> from command line
>> collect2: error: ld returned 1 exit status
>> Makefile:162: recipe for target 'loch' failed
>> make[1]: *** [loch] Error 1
>> make[1]: Leaving directory '/home/rodrigo/devel/therion/loch'
>> Makefile:202: recipe for target 'loch/loch' failed
>> make: *** [loch/loch] Error 2
>>
>>
>> The problem here is that libpng12.0-dev is already installed.
>>
>> After some research I believe this might be a problem related to missing
>> symbols related to bad ordering of library inclusion: http://stackoverflo
>> w.com/questions/19901934/strange-linking-error-dso-
>> missing-from-command-line
>>
>> How can I fix this?
>>
>
> Attached is a patch of the changes I made on loch/Makefile to fix the
> above error. I'm really not sure if this is the proper fix but "it work's".
>
> Please consider it for inclusion on Therion source.
>
> If it's better that I send a pull request, let me know.
>
>
> 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] First use of locally compiled Therion: metapost error

[Stacho Mudrak via Therion]

Hello,

we have implemented Olly's proposal of tex-fonts-optional. It should work
now I believe, because all non standard TeX fonts used are now optional.

S.

On 21 February 2017 at 01:31, Rodrigo Severo via Therion 
wrote:

> 2017-02-20 21:00 GMT-03:00 Olly Betts :
>
>> On Mon, Feb 20, 2017 at 08:40:36PM -0300, Rodrigo Severo via Therion
>> wrote:
>> > To fix it I had to include the following line on */etc/therion.ini*
>> >
>> > tex-fonts raw cmr10 cmti10 cmbx10 cmss10 cmssi10
>> >
>> > despite Therion Book stating at page 80 that this is the default
>> setting.
>> >
>> > Should this line be uncommented on the default *therion.ini* file?
>>
>> Do you have the Ubuntu package of therion installed too?
>>
>
> Yes, I do.
>
>
>> If so, my guess is that /etc/therion.ini is from that package.
>
>
> I bet it is.
>
>
>> Currently
>> the Debian (and hence Ubuntu) packages have a couple of patches in this
>> area - see the discussion here for details:
>>
>> https://github.com/therion/therion/pull/31
>>
>> Assuming I'm right, the quickest fix for your situation is probably to
>> copy
>> therion.ini from the source tree to /etc.
>>
>
> I just checked the diferences between *therion.ini* from the source tree
> and the one at */etc/therion.ini*. There are a few but all on lines that
> are commented, so they are irrelevant for this situation.
>
> The only diference on a non commented line is exactly the line I included
> in */etc/therion.ini* that is not present on the *therion.ini* file
> available at the source and also wasn't at */etc/therion.ini* until I
> included it myself.
>
> So, no, coping the *therion.ini* available at the source to
> */etc/therion.ini* wouldn't fix my issue.
>
> My issue is exactly the one discussed at the link you sent. Unfortunatelly
> that issue isn't solved yet.
>
> AFAICT, right now new Therion installations from source on Linux won't
> work because of error 768.
>
>
> Regards,
>
> Rodrigo
>
>
>
>>
>> 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] wall altitude

[Stacho Mudrak via Therion]

Sorry

symbol-hide point wall-altitude

S.

On 19 January 2017 at 16:25, Stacho Mudrak  wrote:

> Hi,
>
> symbol hide point:wall-altitude
>
> should work.
>
> S.
>
> On 19 January 2017 at 12:03, Martin Sluka via Therion 
> wrote:
>
>> or Tex code, sorry
>>
>> m.s.
>>
>>
>> > 19. 1. 2017 v 11:51, Martin Sluka via Therion :
>> >
>> > You may try to modify MetaPost or code by yourself.
>> >
>> > m.s.
>> >
>> >
>> >> 19. 1. 2017 v 11:01, Pavel Herich via Therion :
>> >>
>> >> Yes, but I´d like to to make something which would be represented by
>> following syntax: "symbol-hide line wall:altitude" and i did try several
>> options how to write this, but without succes.. As well there is similar
>> problem with new symbols defined under u, f.e. "symbol-hide line
>> u:newsymbol" doesn´t work.
>> >> Thank you
>> >> Pavel
>> >>
>> >>
>> >> Dňa 2017-01-18 13:51 Martin Sluka napísal(a):
>> >>> Symbol is line:wall altitude is option of point of this symbol.
>> >>> m.s.
>> >>> Odesláno z iPhonu
>> >>> 18. 1. 2017 v 12:53, Pavel Herich via Therion :
>>  Hello,
>>  I cannot find a right syntax to handle with point of wall line,
>> which is set as altitude . . I´d like to use symbol-hide or symbol-color
>> option. Anyone has an idea? Or just would be enough to have possibility to
>> disable it.
>>  Pavel
>>  ___
>>  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] wall altitude

[Stacho Mudrak via Therion]

Hi,

symbol hide point:wall-altitude

should work.

S.

On 19 January 2017 at 12:03, Martin Sluka via Therion 
wrote:

> or Tex code, sorry
>
> m.s.
>
>
> > 19. 1. 2017 v 11:51, Martin Sluka via Therion :
> >
> > You may try to modify MetaPost or code by yourself.
> >
> > m.s.
> >
> >
> >> 19. 1. 2017 v 11:01, Pavel Herich via Therion :
> >>
> >> Yes, but I´d like to to make something which would be represented by
> following syntax: "symbol-hide line wall:altitude" and i did try several
> options how to write this, but without succes.. As well there is similar
> problem with new symbols defined under u, f.e. "symbol-hide line
> u:newsymbol" doesn´t work.
> >> Thank you
> >> Pavel
> >>
> >>
> >> Dňa 2017-01-18 13:51 Martin Sluka napísal(a):
> >>> Symbol is line:wall altitude is option of point of this symbol.
> >>> m.s.
> >>> Odesláno z iPhonu
> >>> 18. 1. 2017 v 12:53, Pavel Herich via Therion :
>  Hello,
>  I cannot find a right syntax to handle with point of wall line, which
> is set as altitude . . I´d like to use symbol-hide or symbol-color option.
> Anyone has an idea? Or just would be enough to have possibility to disable
> it.
>  Pavel
>  ___
>  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] News from therion.sk page

[Stacho Mudrak via Therion]

Hello Vladimir,

firstly thanks for your work. We are slowly getting to work therion
developement on github and we would like to review and merge all pull
requests there. Would it be a huge work for you to split this large pull
request into smaller (feature or function specific) parts, that could be
easier to review?

Thanks, S.

On 9 January 2017 at 11:08, Martin Sluka via Therion 
wrote:

> Do it, please!
>
> I'll check it. :)
>
> m.s.
>
> On Jan 09, 2017, at 11:06 AM, Владимир Георгиев via Therion <
> therion@speleo.sk> wrote:
>
> Hi Martin
>
> Happy new year.
> It's good to see that there is some activity on the Github and Stacho and
> Martin are making updates.
>
> When you say that we can submit pull requests, do you think that someone
> will have the time to review and approve them? There are already 5 requests
> pending for some time.
> In my fork of the repo there are other changes too https://github.com/
> vldgeorgiev/therion/wiki/Changelog
> I can make a pull request combining all of the changes if there is
> interest and if the authors can review and merge them.
>
> Best
> Vladimir
>
> On Mon, Jan 2, 2017 at 10:48 AM, Martin Sluka via Therion <
> therion@speleo.sk> wrote:
>
>> December 27th 2016 Contact page:
>>
>> You can submit issues and pull requests on GitHub. There is also a
>> historical project page on Savannah.
>>
>> https://github.com/therion/therion
>>
>> http://savannah.nongnu.org/projects/therion/
>>
>> Theriony New Year
>>
>> m.s.
>> ___
>> 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