Re: [Therion] Splays appearing when not selected

[Xavier Robert]

Hi Stacho,

Thanks for your answer ! I tried to compile the map with your code, it works 
well, all the un-surveyed scrap is at the altitude of the referenced station.

Otherwise, Yes, my map is composed of several scraps, but the un-surveyed part 
is a single scrap.

And if you want to test and play with that issue, let me know, I can send you 
my working folder with all the source files.

Cheers,

Xavier



> Le 3 févr. 2021 à 06:13, Stacho Mudrak  a écrit :
> 
> Hi Xavier,
> 
> this is very strange - because if your map consists of several scraps, 
> therion should not be aware of total depth when doing 3d reconstruction of a 
> single scrap. There must be some issue...
> 
> Anyway, I have tried to fix at least the height interpolation formula - are 
> you able to compile and run my fork of therion code 
> (https://github.com/smudrak/therion ) - 
> whether this issue is also present there?
> 
> Combining plan/profile when doing 3d reconstruction would be the ultimate 
> solution, but it requires a change of this algorithm completely. 
> 
> And thanks for the idea of fake stations - they could also simplify life a 
> lot when digitizing old maps without having access to centreline data.
> 
> S.
> 
> 
> 
> On Tue, 2 Feb 2021 at 11:18, Xavier Robert 
>  > wrote:
> Hi,
> 
> I also had that behaviour with some of my surveys. 
> In fact, it mostly happen for scraps that I used to draw explored but 
> unsurveyed passages. In that case, there is no surveyed data to clip the 
> drawing to the main survey. To be able to clip it to the drawing, I fixed the 
> unsurveyed part with 1 known station and a scale definition in the scrap.
> 
> In that case, the resulting 3D-view consider that the floor of almost the 
> whole un-surveyed galerie is at the altitude of the fixed point, and that the 
> roof is at the altitude of the highest point of the cave. See for instance 
> the picture JB-Sump-NoHeight.png below:
> If in my scrap (plan projection) I add some points height, on the 3D view, it 
> clips the scrap at the altitude of the highest point (see 
> JB-Sump-WithpointHeight.png below, that is false because the unsurveyed 
> galerie follows more or less the parallel surveyed galerie; To get an idea, I 
> attached the pdf maps):
> To get these 3D-outputs, I compiled the project with both, plan- and 
> extended-projections scraps, but the extend-projection is not taken in 
> account to build the 3D. This could probably be resolved if Therion could 
> take in account both, plan and extended projection, during the compilation.
> 
> I suppose that this is not a simple request, as there is no points that can 
> link the 2 scraps with the 2 projections. I do not know if that is a good 
> idea or not, but one idea could be to define in the drawing similar fake 
> stations in the two projected scraps. For instance, if we draw in the 
> extended scrap a station point with the options « -name fake1 -unsurveyed » 
> (or a new subtype), and if we draw the same station point in the plan scrap 
> with the same option, Therion could link the 2 scraps and compute a better 
> approximate of the 3D view?
> 
> Cheers,
> 
> Xavier
> 
>> Le 2 févr. 2021 à 10:01, Martin Sluka via Therion > > a écrit :
>> 
>> Hi Beni
>> 
>> 
>> that is not a problem of „spikes“ but as you may see on attached picture I 
>> had the same problem with one my project.
>> 
>> There were two scraps covered part the same area overlapped. Surveyed in two 
>> different surveying trips by two different groups drawn by two different 
>> people. As a result that overlapped area created something as infinite 
>> vertical chimney.
>> 
>> I had to comment one scrap in time from that part of cave and checked the 
>> result. Than I shorted one of those particular scraps and added correct join.
>> 
>> HTH
>> 
>> Martin
>> 
>> 
>> 
>>> 2. 2. 2021 v 9:48, Benedikt Hallinger >> >:
>>> 
>>> Hm, that didn't help, unfortunately.
>>> in the meantime I also tried coloring the PDF by altitude, this is not 
>>> affected and working like expected.
>>> 
>>> Martin has readonly svn access to the data and may investigate in the 
>>> dataset?
>>> I just unlocked it for that purpose.
>>> 
>>> The affected thconfig is svn/Hirlatzhoehle/Zubringer/therion/thconfig
>>> and the scrap in question is in  
>>> svn/Hirlatzhoehle/Zubringer/1/therion/1.1.plan-2-b.th2
>>> The last known station is 1.2.26j
>>> 
>>> In the thconfig I noted the following (just local here)
>>> 
>>> # Hirlatzdaten importieren
>>> source ../../../Hirlatzhoehle/therion/Hirlatzhoehle.th 
>>>   # wrong dimensions in lox
>>> #source ../../../Hirlatzhoehle/Zubringer/therion/Zubringer.th 
>>>    # works somewhat-ok in lox (still extruded to top 
>>> of box, but the box itself is small)
>>> 
>>> 
>>> Greetings,
>>> Beni
>>> 
>>> 
>>> 
>>> Am 

Re: [Therion] Splays appearing when not selected

[Martin Sluka via Therion]

Hi Beni


that is not a problem of „spikes“ but as you may see on attached picture I had 
the same problem with one my project.

There were two scraps covered part the same area overlapped. Surveyed in two 
different surveying trips by two different groups drawn by two different 
people. As a result that overlapped area created something as infinite vertical 
chimney.

I had to comment one scrap in time from that part of cave and checked the 
result. Than I shorted one of those particular scraps and added correct join.

HTH

Martin



> 2. 2. 2021 v 9:48, Benedikt Hallinger :
> 
> Hm, that didn't help, unfortunately.
> in the meantime I also tried coloring the PDF by altitude, this is not 
> affected and working like expected.
> 
> Martin has readonly svn access to the data and may investigate in the dataset?
> I just unlocked it for that purpose.
> 
> The affected thconfig is svn/Hirlatzhoehle/Zubringer/therion/thconfig
> and the scrap in question is in  
> svn/Hirlatzhoehle/Zubringer/1/therion/1.1.plan-2-b.th2
> The last known station is 1.2.26j
> 
> In the thconfig I noted the following (just local here)
> 
> # Hirlatzdaten importieren
> source ../../../Hirlatzhoehle/therion/Hirlatzhoehle.th  # wrong 
> dimensions in lox
> #source ../../../Hirlatzhoehle/Zubringer/therion/Zubringer.th   # works 
> somewhat-ok in lox (still extruded to top of box, but the box itself is small)
> 
> 
> Greetings,
> Beni
> 
> 
> 
> Am 2021-02-02 6:31, schrieb Stacho Mudrak:
>> In that case and if there is just one station in this wrong scrap,
>> maybe inserting point dimensions with some reasonable -value [
>>  m] over this station in the scrap should help to normalize
>> these crazy heights.
>> If there are no up/down data in the centreline, therion calculates
>> up/down dimensions from shots from a given station. It is not a
>> perfect algorithm and in your case, there is some issue. Placing a
>> point dimension close to the station should override this calculation.
>> HTH, S.
>> On Mon, 1 Feb 2021 at 23:10, Benedikt Hallinger 
>> wrote:
>>> It's hard to isolate.
>>> The structure is like this:
>>> Hirlatzhoehle/Zubringer/,
>>> where Zubringer contains more surveys.
>>> Each folder has its own therion/ subfolder containing the therion
>>> sources.
>>> If i do "source ../../../Hirlatzhoehle/therion/Hirlatzhoehle.th" the
>>> bug
>>> occurs.
>>> That command sources the entire cave.
>>> If i do source just the region with "source
>>> ../../../Hirlatzhoehle/Zubringer/therion/Zubringer.th" (which
>>> contains
>>> essentially the same maps and scraps!) the bug occurs.
>>> I have no idea how to track this don further, since we already talk
>>> about alot of data (2.4 km).
>>> Am 2021-02-01 21:37, schrieb Benedikt Hallinger:
 I try to boil it down
 Am 2021-02-01 21:12, schrieb Stacho Mudrak:
> Hmmm, even scraps extending far beyond a known station could
>>> cause a
> problem - usually, it is the case with steep passages. In your
>>> case,
> it looks like some outline problem.
> Are you able to isolate such scrap and send me some minimalistic
> sample?
> Thanks, S.
> On Mon, 1 Feb 2021 at 20:10, Benedikt Hallinger
>>> 
> wrote:
>> Hi, thanks for responding,
>> i have the problem only tested with the lox.
>> The red box fits nicely my selected data.
>> The survex file also is OK.
>> Probably it's caused by artifacts, see screenshot.
>> Thats an old bug, and caused by some scraps extending far beyond
>>> a
>> known
>> station (walls are marked unsurveyed).
>> Am 2021-02-01 19:52, schrieb Stacho Mudrak:
>>> Hi Beni,
>>> thanks for review.
>>> Are you having coloring problem with .lox file or .pdf map?
>>> I have tried on my dataset, but when I select whole cave -
>>> entire
>>> color range is used - from magenta to red.
>>> When I select just a part of the cave, coloring changes and the
>> whole
>>> range is used for selected part.
>>> Does your red rectangle fit selected data or is it much bigger?
>>> If
>> the
>>> latter is the case, there must be some artifacts still
>>> remaining -
>>> that were not removed with selection. Maybe some stations? Does
>> this
>>> problem remain also with aven .3d export?
>>> It would be great if we could find this bug before therion goes
>>> to
>>> debian release.
>>> S.
>>> On Mon, 1 Feb 2021 at 10:17, Benedikt Hallinger
>> 
>>> wrote:
 Checked it, looks good for me (data selection, and pdf map
>> printout
 with
 people showing up again), with one exception:
 - I source all of the cave's data. (ok)
 - Then i select jsut a part of it. (ok)
 - The lox output contains just the selected part (ok)
 - The altitude coloring is all the same, despite having
>> significant
 altitude changes in the dataset.
 The reason seems to be that the coloring is done according in

Re: [Therion] Splays appearing when not selected

[Benedikt Hallinger]

Hm, that didn't help, unfortunately.
in the meantime I also tried coloring the PDF by altitude, this is not 
affected and working like expected.


Martin has readonly svn access to the data and may investigate in the 
dataset?

I just unlocked it for that purpose.

The affected thconfig is svn/Hirlatzhoehle/Zubringer/therion/thconfig
and the scrap in question is in  
svn/Hirlatzhoehle/Zubringer/1/therion/1.1.plan-2-b.th2

The last known station is 1.2.26j

In the thconfig I noted the following (just local here)

# Hirlatzdaten importieren
source ../../../Hirlatzhoehle/therion/Hirlatzhoehle.th  # wrong 
dimensions in lox
#source ../../../Hirlatzhoehle/Zubringer/therion/Zubringer.th   # works 
somewhat-ok in lox (still extruded to top of box, but the box itself is 
small)



Greetings,
Beni



Am 2021-02-02 6:31, schrieb Stacho Mudrak:

In that case and if there is just one station in this wrong scrap,
maybe inserting point dimensions with some reasonable -value [
 m] over this station in the scrap should help to normalize
these crazy heights.

If there are no up/down data in the centreline, therion calculates
up/down dimensions from shots from a given station. It is not a
perfect algorithm and in your case, there is some issue. Placing a
point dimension close to the station should override this calculation.

HTH, S.

On Mon, 1 Feb 2021 at 23:10, Benedikt Hallinger 
wrote:


It's hard to isolate.

The structure is like this:
Hirlatzhoehle/Zubringer/,
where Zubringer contains more surveys.
Each folder has its own therion/ subfolder containing the therion
sources.

If i do "source ../../../Hirlatzhoehle/therion/Hirlatzhoehle.th" the
bug
occurs.
That command sources the entire cave.

If i do source just the region with "source
../../../Hirlatzhoehle/Zubringer/therion/Zubringer.th" (which
contains
essentially the same maps and scraps!) the bug occurs.
I have no idea how to track this don further, since we already talk
about alot of data (2.4 km).

Am 2021-02-01 21:37, schrieb Benedikt Hallinger:

I try to boil it down

Am 2021-02-01 21:12, schrieb Stacho Mudrak:

Hmmm, even scraps extending far beyond a known station could

cause a

problem - usually, it is the case with steep passages. In your

case,

it looks like some outline problem.

Are you able to isolate such scrap and send me some minimalistic
sample?

Thanks, S.

On Mon, 1 Feb 2021 at 20:10, Benedikt Hallinger



wrote:


Hi, thanks for responding,

i have the problem only tested with the lox.
The red box fits nicely my selected data.
The survex file also is OK.

Probably it's caused by artifacts, see screenshot.
Thats an old bug, and caused by some scraps extending far beyond

a

known
station (walls are marked unsurveyed).

Am 2021-02-01 19:52, schrieb Stacho Mudrak:

Hi Beni,

thanks for review.

Are you having coloring problem with .lox file or .pdf map?

I have tried on my dataset, but when I select whole cave -

entire

color range is used - from magenta to red.

When I select just a part of the cave, coloring changes and the

whole

range is used for selected part.

Does your red rectangle fit selected data or is it much bigger?

If

the

latter is the case, there must be some artifacts still

remaining -

that were not removed with selection. Maybe some stations? Does

this

problem remain also with aven .3d export?

It would be great if we could find this bug before therion goes

to

debian release.

S.

On Mon, 1 Feb 2021 at 10:17, Benedikt Hallinger



wrote:


Checked it, looks good for me (data selection, and pdf map

printout

with
people showing up again), with one exception:

- I source all of the cave's data. (ok)
- Then i select jsut a part of it. (ok)
- The lox output contains just the selected part (ok)
- The altitude coloring is all the same, despite having

significant

altitude changes in the dataset.
The reason seems to be that the coloring is done according in
relation
to ALL the cave, not just the selected parts - in comparison

to

the

entire system the altitude difference is negligible, but i

expected

the
lox to generate the altitude band according to the actual

min/max

values
of the selected dataset.

$ therion -v
therion 5.5.6 (2020-12-27)
- using Proj 7.2.1, compiled against 7.2.1

But: therion compile cdf201b5bf921 has the same behaviour.

Am 2021-01-27 8:59, schrieb Benedikt Hallinger:

I just did apt-get update, and see 5.5.6ds1-5

That is the old version, right? I do wait for 5.5.6ds1-6 ?


Am 2021-01-26 16:16, schrieb Wookey:

On 2021-01-24 14:40 +0100, Benedikt Hallinger wrote:

Wookey, when is this expected to appear in testing?
I would test it


It's there now.

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

Re: [Therion] Splays appearing when not selected

[Stacho Mudrak]

In that case and if there is just one station in this wrong scrap, maybe
inserting point dimensions with some reasonable -value [  m] over
this station in the scrap should help to normalize these crazy heights.

If there are no up/down data in the centreline, therion calculates up/down
dimensions from shots from a given station. It is not a perfect algorithm
and in your case, there is some issue. Placing a point dimension close to
the station should override this calculation.

HTH, S.


On Mon, 1 Feb 2021 at 23:10, Benedikt Hallinger  wrote:

> It's hard to isolate.
>
> The structure is like this:
> Hirlatzhoehle/Zubringer/,
> where Zubringer contains more surveys.
> Each folder has its own therion/ subfolder containing the therion
> sources.
>
> If i do "source ../../../Hirlatzhoehle/therion/Hirlatzhoehle.th" the bug
> occurs.
> That command sources the entire cave.
>
> If i do source just the region with "source
> ../../../Hirlatzhoehle/Zubringer/therion/Zubringer.th" (which contains
> essentially the same maps and scraps!) the bug occurs.
> I have no idea how to track this don further, since we already talk
> about alot of data (2.4 km).
>
>
> Am 2021-02-01 21:37, schrieb Benedikt Hallinger:
> > I try to boil it down
> >
> > Am 2021-02-01 21:12, schrieb Stacho Mudrak:
> >> Hmmm, even scraps extending far beyond a known station could cause a
> >> problem - usually, it is the case with steep passages. In your case,
> >> it looks like some outline problem.
> >>
> >> Are you able to isolate such scrap and send me some minimalistic
> >> sample?
> >>
> >> Thanks, S.
> >>
> >> On Mon, 1 Feb 2021 at 20:10, Benedikt Hallinger 
> >> wrote:
> >>
> >>> Hi, thanks for responding,
> >>>
> >>> i have the problem only tested with the lox.
> >>> The red box fits nicely my selected data.
> >>> The survex file also is OK.
> >>>
> >>> Probably it's caused by artifacts, see screenshot.
> >>> Thats an old bug, and caused by some scraps extending far beyond a
> >>> known
> >>> station (walls are marked unsurveyed).
> >>>
> >>> Am 2021-02-01 19:52, schrieb Stacho Mudrak:
>  Hi Beni,
> 
>  thanks for review.
> 
>  Are you having coloring problem with .lox file or .pdf map?
> 
>  I have tried on my dataset, but when I select whole cave - entire
>  color range is used - from magenta to red.
> 
>  When I select just a part of the cave, coloring changes and the
> >>> whole
>  range is used for selected part.
> 
>  Does your red rectangle fit selected data or is it much bigger? If
> >>> the
>  latter is the case, there must be some artifacts still remaining -
>  that were not removed with selection. Maybe some stations? Does
> >>> this
>  problem remain also with aven .3d export?
> 
>  It would be great if we could find this bug before therion goes to
>  debian release.
> 
>  S.
> 
>  On Mon, 1 Feb 2021 at 10:17, Benedikt Hallinger
> >>> 
>  wrote:
> 
> > Checked it, looks good for me (data selection, and pdf map
> >>> printout
> > with
> > people showing up again), with one exception:
> >
> > - I source all of the cave's data. (ok)
> > - Then i select jsut a part of it. (ok)
> > - The lox output contains just the selected part (ok)
> > - The altitude coloring is all the same, despite having
> >>> significant
> > altitude changes in the dataset.
> > The reason seems to be that the coloring is done according in
> > relation
> > to ALL the cave, not just the selected parts - in comparison to
> >>> the
> > entire system the altitude difference is negligible, but i
> >>> expected
> > the
> > lox to generate the altitude band according to the actual min/max
> > values
> > of the selected dataset.
> >
> > $ therion -v
> > therion 5.5.6 (2020-12-27)
> > - using Proj 7.2.1, compiled against 7.2.1
> >
> > But: therion compile cdf201b5bf921 has the same behaviour.
> >
> > Am 2021-01-27 8:59, schrieb Benedikt Hallinger:
> >> I just did apt-get update, and see 5.5.6ds1-5
> >>
> >> That is the old version, right? I do wait for 5.5.6ds1-6 ?
> >>
> >>
> >> Am 2021-01-26 16:16, schrieb Wookey:
> >>> On 2021-01-24 14:40 +0100, Benedikt Hallinger wrote:
>  Wookey, when is this expected to appear in testing?
>  I would test it
> >>>
> >>> It's there now.
> >>>
> >>> 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] Splays appearing when not selected

[Wookey]

On 2021-01-27 08:59 +0100, Benedikt Hallinger wrote:
> I just did apt-get update, and see 5.5.6ds1-5
> 
> That is the old version, right? I do wait for 5.5.6ds1-6 ?

No 5.5.6ds1-5 is the latest, including the fix discussed inthis thread.
There isn't a -6 (yet)

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Splays appearing when not selected

[Benedikt Hallinger]

It's hard to isolate.

The structure is like this:
Hirlatzhoehle/Zubringer/,
where Zubringer contains more surveys.
Each folder has its own therion/ subfolder containing the therion 
sources.


If i do "source ../../../Hirlatzhoehle/therion/Hirlatzhoehle.th" the bug 
occurs.

That command sources the entire cave.

If i do source just the region with "source 
../../../Hirlatzhoehle/Zubringer/therion/Zubringer.th" (which contains 
essentially the same maps and scraps!) the bug occurs.
I have no idea how to track this don further, since we already talk 
about alot of data (2.4 km).



Am 2021-02-01 21:37, schrieb Benedikt Hallinger:

I try to boil it down

Am 2021-02-01 21:12, schrieb Stacho Mudrak:

Hmmm, even scraps extending far beyond a known station could cause a
problem - usually, it is the case with steep passages. In your case,
it looks like some outline problem.

Are you able to isolate such scrap and send me some minimalistic
sample?

Thanks, S.

On Mon, 1 Feb 2021 at 20:10, Benedikt Hallinger 
wrote:


Hi, thanks for responding,

i have the problem only tested with the lox.
The red box fits nicely my selected data.
The survex file also is OK.

Probably it's caused by artifacts, see screenshot.
Thats an old bug, and caused by some scraps extending far beyond a
known
station (walls are marked unsurveyed).

Am 2021-02-01 19:52, schrieb Stacho Mudrak:

Hi Beni,

thanks for review.

Are you having coloring problem with .lox file or .pdf map?

I have tried on my dataset, but when I select whole cave - entire
color range is used - from magenta to red.

When I select just a part of the cave, coloring changes and the

whole

range is used for selected part.

Does your red rectangle fit selected data or is it much bigger? If

the

latter is the case, there must be some artifacts still remaining -
that were not removed with selection. Maybe some stations? Does

this

problem remain also with aven .3d export?

It would be great if we could find this bug before therion goes to
debian release.

S.

On Mon, 1 Feb 2021 at 10:17, Benedikt Hallinger



wrote:


Checked it, looks good for me (data selection, and pdf map

printout

with
people showing up again), with one exception:

- I source all of the cave's data. (ok)
- Then i select jsut a part of it. (ok)
- The lox output contains just the selected part (ok)
- The altitude coloring is all the same, despite having

significant

altitude changes in the dataset.
The reason seems to be that the coloring is done according in
relation
to ALL the cave, not just the selected parts - in comparison to

the

entire system the altitude difference is negligible, but i

expected

the
lox to generate the altitude band according to the actual min/max
values
of the selected dataset.

$ therion -v
therion 5.5.6 (2020-12-27)
- using Proj 7.2.1, compiled against 7.2.1

But: therion compile cdf201b5bf921 has the same behaviour.

Am 2021-01-27 8:59, schrieb Benedikt Hallinger:

I just did apt-get update, and see 5.5.6ds1-5

That is the old version, right? I do wait for 5.5.6ds1-6 ?


Am 2021-01-26 16:16, schrieb Wookey:

On 2021-01-24 14:40 +0100, Benedikt Hallinger wrote:

Wookey, when is this expected to appear in testing?
I would test it


It's there now.

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

___
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] Splays appearing when not selected

[Benedikt Hallinger]

I try to boil it down

Am 2021-02-01 21:12, schrieb Stacho Mudrak:

Hmmm, even scraps extending far beyond a known station could cause a
problem - usually, it is the case with steep passages. In your case,
it looks like some outline problem.

Are you able to isolate such scrap and send me some minimalistic
sample?

Thanks, S.

On Mon, 1 Feb 2021 at 20:10, Benedikt Hallinger 
wrote:


Hi, thanks for responding,

i have the problem only tested with the lox.
The red box fits nicely my selected data.
The survex file also is OK.

Probably it's caused by artifacts, see screenshot.
Thats an old bug, and caused by some scraps extending far beyond a
known
station (walls are marked unsurveyed).

Am 2021-02-01 19:52, schrieb Stacho Mudrak:

Hi Beni,

thanks for review.

Are you having coloring problem with .lox file or .pdf map?

I have tried on my dataset, but when I select whole cave - entire
color range is used - from magenta to red.

When I select just a part of the cave, coloring changes and the

whole

range is used for selected part.

Does your red rectangle fit selected data or is it much bigger? If

the

latter is the case, there must be some artifacts still remaining -
that were not removed with selection. Maybe some stations? Does

this

problem remain also with aven .3d export?

It would be great if we could find this bug before therion goes to
debian release.

S.

On Mon, 1 Feb 2021 at 10:17, Benedikt Hallinger



wrote:


Checked it, looks good for me (data selection, and pdf map

printout

with
people showing up again), with one exception:

- I source all of the cave's data. (ok)
- Then i select jsut a part of it. (ok)
- The lox output contains just the selected part (ok)
- The altitude coloring is all the same, despite having

significant

altitude changes in the dataset.
The reason seems to be that the coloring is done according in
relation
to ALL the cave, not just the selected parts - in comparison to

the

entire system the altitude difference is negligible, but i

expected

the
lox to generate the altitude band according to the actual min/max
values
of the selected dataset.

$ therion -v
therion 5.5.6 (2020-12-27)
- using Proj 7.2.1, compiled against 7.2.1

But: therion compile cdf201b5bf921 has the same behaviour.

Am 2021-01-27 8:59, schrieb Benedikt Hallinger:

I just did apt-get update, and see 5.5.6ds1-5

That is the old version, right? I do wait for 5.5.6ds1-6 ?


Am 2021-01-26 16:16, schrieb Wookey:

On 2021-01-24 14:40 +0100, Benedikt Hallinger wrote:

Wookey, when is this expected to appear in testing?
I would test it


It's there now.

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

___
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] Splays appearing when not selected

[Benedikt Hallinger]

Yes, the scraps are like this (s=station:)

[good scrap: s1 s2 s3]
joined
[bad scrap: s3 ..only walls]


Am 2021-02-01 20:19, schrieb Martin Sluka via Therion:

1. 2. 2021 v 20:10, Benedikt Hallinger :

Probably it's caused by artifacts, see screenshot.
Thats an old bug, and caused by some scraps extending far beyond a 
known station (walls are marked unsurveyed).


I had the same artifact when I created two overlapped scraps of the
same part of passage referenced by the same stations.

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] Splays appearing when not selected

[Martin Sluka via Therion]

> 1. 2. 2021 v 20:10, Benedikt Hallinger :
> 
> Probably it's caused by artifacts, see screenshot.
> Thats an old bug, and caused by some scraps extending far beyond a known 
> station (walls are marked unsurveyed).

I had the same artifact when I created two overlapped scraps of the same part 
of passage referenced by the same stations.

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

Re: [Therion] Splays appearing when not selected

[Benedikt Hallinger]

Hi, thanks for responding,

i have the problem only tested with the lox.
The red box fits nicely my selected data.
The survex file also is OK.

Probably it's caused by artifacts, see screenshot.
Thats an old bug, and caused by some scraps extending far beyond a known 
station (walls are marked unsurveyed).



Am 2021-02-01 19:52, schrieb Stacho Mudrak:

Hi Beni,

thanks for review.

Are you having coloring problem with .lox file or .pdf map?

I have tried on my dataset, but when I select whole cave - entire
color range is used - from magenta to red.

When I select just a part of the cave, coloring changes and the whole
range is used for selected part.

Does your red rectangle fit selected data or is it much bigger? If the
latter is the case, there must be some artifacts still remaining -
that were not removed with selection. Maybe some stations? Does this
problem remain also with aven .3d export?

It would be great if we could find this bug before therion goes to
debian release.

S.

On Mon, 1 Feb 2021 at 10:17, Benedikt Hallinger 
wrote:


Checked it, looks good for me (data selection, and pdf map printout
with
people showing up again), with one exception:

- I source all of the cave's data. (ok)
- Then i select jsut a part of it. (ok)
- The lox output contains just the selected part (ok)
- The altitude coloring is all the same, despite having significant
altitude changes in the dataset.
The reason seems to be that the coloring is done according in
relation
to ALL the cave, not just the selected parts - in comparison to the
entire system the altitude difference is negligible, but i expected
the
lox to generate the altitude band according to the actual min/max
values
of the selected dataset.

$ therion -v
therion 5.5.6 (2020-12-27)
- using Proj 7.2.1, compiled against 7.2.1

But: therion compile cdf201b5bf921 has the same behaviour.

Am 2021-01-27 8:59, schrieb Benedikt Hallinger:

I just did apt-get update, and see 5.5.6ds1-5

That is the old version, right? I do wait for 5.5.6ds1-6 ?


Am 2021-01-26 16:16, schrieb Wookey:

On 2021-01-24 14:40 +0100, Benedikt Hallinger wrote:

Wookey, when is this expected to appear in testing?
I would test it


It's there now.

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

___
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] Splays appearing when not selected

[Stacho Mudrak]

Hi Beni,

thanks for review.

Are you having coloring problem with .lox file or .pdf map?

I have tried on my dataset, but when I select whole cave - entire color
range is used - from magenta to red.

[image: image.png]

When I select just a part of the cave, coloring changes and the whole range
is used for selected part.

[image: image.png]

Does your red rectangle fit selected data or is it much bigger? If the
latter is the case, there must be some artifacts still remaining - that
were not removed with selection. Maybe some stations? Does this problem
remain also with aven .3d export?

It would be great if we could find this bug before therion goes to debian
release.

S.


On Mon, 1 Feb 2021 at 10:17, Benedikt Hallinger  wrote:

> Checked it, looks good for me (data selection, and pdf map printout with
> people showing up again), with one exception:
>
>
> - I source all of the cave's data. (ok)
> - Then i select jsut a part of it. (ok)
> - The lox output contains just the selected part (ok)
> - The altitude coloring is all the same, despite having significant
> altitude changes in the dataset.
>The reason seems to be that the coloring is done according in relation
> to ALL the cave, not just the selected parts - in comparison to the
> entire system the altitude difference is negligible, but i expected the
> lox to generate the altitude band according to the actual min/max values
> of the selected dataset.
>
>
> $ therion -v
> therion 5.5.6 (2020-12-27)
>- using Proj 7.2.1, compiled against 7.2.1
>
>
> But: therion compile cdf201b5bf921 has the same behaviour.
>
>
>
> Am 2021-01-27 8:59, schrieb Benedikt Hallinger:
> > I just did apt-get update, and see 5.5.6ds1-5
> >
> > That is the old version, right? I do wait for 5.5.6ds1-6 ?
> >
> >
> > Am 2021-01-26 16:16, schrieb Wookey:
> >> On 2021-01-24 14:40 +0100, Benedikt Hallinger wrote:
> >>> Wookey, when is this expected to appear in testing?
> >>> I would test it
> >>
> >> It's there now.
> >>
> >> 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
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Splays appearing when not selected

[Benedikt Hallinger]

Checked it, looks good for me (data selection, and pdf map printout with 
people showing up again), with one exception:



- I source all of the cave's data. (ok)
- Then i select jsut a part of it. (ok)
- The lox output contains just the selected part (ok)
- The altitude coloring is all the same, despite having significant 
altitude changes in the dataset.
  The reason seems to be that the coloring is done according in relation 
to ALL the cave, not just the selected parts - in comparison to the 
entire system the altitude difference is negligible, but i expected the 
lox to generate the altitude band according to the actual min/max values 
of the selected dataset.



$ therion -v
therion 5.5.6 (2020-12-27)
  - using Proj 7.2.1, compiled against 7.2.1


But: therion compile cdf201b5bf921 has the same behaviour.



Am 2021-01-27 8:59, schrieb Benedikt Hallinger:

I just did apt-get update, and see 5.5.6ds1-5

That is the old version, right? I do wait for 5.5.6ds1-6 ?


Am 2021-01-26 16:16, schrieb Wookey:

On 2021-01-24 14:40 +0100, Benedikt Hallinger wrote:

Wookey, when is this expected to appear in testing?
I would test it


It's there now.

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] Splays appearing when not selected

[Benedikt Hallinger]

I just did apt-get update, and see 5.5.6ds1-5

That is the old version, right? I do wait for 5.5.6ds1-6 ?


Am 2021-01-26 16:16, schrieb Wookey:

On 2021-01-24 14:40 +0100, Benedikt Hallinger wrote:

Wookey, when is this expected to appear in testing?
I would test it


It's there now.

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

Re: [Therion] Splays appearing when not selected

[Wookey]

On 2021-01-24 14:40 +0100, Benedikt Hallinger wrote:
> Wookey, when is this expected to appear in testing?
> I would test it

It's there now.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Splays appearing when not selected

[Wookey]

On 2021-01-24 14:40 +0100, Benedikt Hallinger wrote:
> Wookey, when is this expected to appear in testing?

Follow the status on the tracker page:
https://tracker.debian.org/pkg/therion
(only updates every few hours, so right now shows only the previous version)

It should happen approx 48 hours from now if all goes well.
The last architecture (mipsel) is just building now.
https://buildd.debian.org/status/package.php?p=therion

> I would test it

Thanks, that is very useful (to make sure I didn't screw anything up)

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Splays appearing when not selected

[Benedikt Hallinger]

Wookey, when is this expected to appear in testing?
I would test it

> Am 24.01.2021 um 13:57 schrieb Wookey :
> 
> On 2021-01-23 11:34 +0100, Stacho Mudrak wrote:
>>   Hi Axel,
>>   these big numbers are just NaNs in fact. It does not affect any output -
>>   it just means the map has no altitude associated with it. But thanks for
>>   finding out, I have tried to fix it in the latest commit, could you please
>>   try?
> 
> I've included this fix (and the other minor one you did) in the debian
> package (as 5.5.6ds1-5).  It turns out that updates to non-core packages 
> (which
> definately includes Therion :-) are actually allowed until 12th Feb,
> not 12th Jan so it should still make it the next stable release.
> 
> It looks like this stable release of therion should be in quite good shape.
> 
> 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] Splays appearing when not selected

[Wookey]

On 2021-01-23 11:34 +0100, Stacho Mudrak wrote:
>Hi Axel,
>these big numbers are just NaNs in fact. It does not affect any output -
>it just means the map has no altitude associated with it. But thanks for
>finding out, I have tried to fix it in the latest commit, could you please
>try?

I've included this fix (and the other minor one you did) in the debian
package (as 5.5.6ds1-5).  It turns out that updates to non-core packages (which
definately includes Therion :-) are actually allowed until 12th Feb,
not 12th Jan so it should still make it the next stable release.

It looks like this stable release of therion should be in quite good shape.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Splays appearing when not selected

[Stacho Mudrak]

Hi Axel,

these big numbers are just NaNs in fact. It does not affect any output - it
just means the map has no altitude associated with it. But thanks for
finding out, I have tried to fix it in the latest commit, could you please
try?

I am just curious, what OS are you using? Normally - it should write nan
instead of such a big number. This big number is just a fallback if the
compiler does not support NaN.

S.



On Fri, 22 Jan 2021 at 09:16, Axel  wrote:

> morning,
>
> just had time to try the fix (5.5.6+5208297) and it solves the issue
> Benedikt mentioned in my projects as well,
> thx!
>
> also had another look at my cavern error -- 1 issue (label with attr
> selected in layout/ wont compile unless -d option is choosen).
> looking at the map/scrap selection I get huge numbers for the map and
> wonder if that might cause the problem? I draw all my maps with Inkscape
> but checked the th2 files and found nothing strange+ it compiles without a
> problem with the normal label...
>
> ### export maps & scraps selection #
> M
> -8000.00
> IH_HauptPlan@IH ()
> M
> -8000.00
> 02-plan-o...@02.ih ()
> S  1643.48  02-plan...@02.ih ()
> S  1634.82  02-plan...@02.ih ()
> M
> -8000.00
> 02-plan-saueleng...@02.ih ()
> S  1674.29  02-plan2...@02.ih ()
> S  1673.77  02-plan...@02.ih ()
>
> cheers,
> Axel
>
> *Gesendet:* Mittwoch, 20. Januar 2021 um 09:10 Uhr
> *Von:* "Benedikt Hallinger" 
> *An:* "List for Therion users" 
> *Betreff:* Re: [Therion] Splays appearing when not selected
> I just recompiled and can confirm that my problem indeed was the same
> and is gone with therion 5.5.6+5208297 (2021-01-19)
>
> Good work!
> Thank you!
>
>
> Am 2021-01-19 22:00, schrieb Benedikt Hallinger:
> > Hello,
> > Axel and i had the same bug, and we noticed that when explicitely
> > select the wall source at the export lox command, the issue is solved
> > ("export model -o out.lox -wall-source maps").
> >
> > Personally i would assume this is a bug, because when i select
> > datasets i would want the remaining data to be not present in my
> > output. That is the purpose of selecting in the first place, isn’t it?
> >
> >
> >> Am 19.01.2021 um 15:48 schrieb Tarquin Wilton-Jones via Therion
> >> :
> >>
> >> Hi Rhys,
> >>
> >>> I have noticed something that I am not sure if it's a bug or not. I
> >>> am
> >>> trying to export a selected bit of a survey as a loch file:
> >>
> >> From my experience...
> >> Lox file export will always select all of the survey that were
> >> imported.
> >> It will generate walls using all splays. It will use all scraps to
> >> enhance the passage walls, even if you do not select them. If they
> >> exist
> >> in any surveys or subsurveys, they are used, no matter which survey or
> >> map is selected.
> >>
> >> I always assumed this was intentional behaviour.
> >>
> >> Personally, I have wanted to be able to select the specific maps that
> >> should be used for lox, since I may have more than one version of a
> >> survey in my data - traces over an old low quality survey, and a new
> >> high quality survey of the same cave. Lox export insists on trying to
> >> merge both versions rather than being able to select just one of them.
> >>
> >> Cheers,
> >>
> >> Tarquin
> >> ___
> >> Therion mailing list
> >> Therion@speleo.sk
> >> https://mailman.speleo.sk/listinfo/therion
> > ___
> > Therion mailing list
> > Therion@speleo.sk
> > https://mailman.speleo.sk/listinfo/therion
> ___
> Therion 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] Splays appearing when not selected

[Rhys Tyers]

Fixed for me, thanks Stacho.

On Fri, 22 Jan 2021 at 08:16, Axel  wrote:

> morning,
>
> just had time to try the fix (5.5.6+5208297) and it solves the issue
> Benedikt mentioned in my projects as well,
> thx!
>
> also had another look at my cavern error -- 1 issue (label with attr
> selected in layout/ wont compile unless -d option is choosen).
> looking at the map/scrap selection I get huge numbers for the map and
> wonder if that might cause the problem? I draw all my maps with Inkscape
> but checked the th2 files and found nothing strange+ it compiles without a
> problem with the normal label...
>
> ### export maps & scraps selection #
> M
> -8000.00
> IH_HauptPlan@IH ()
> M
> -8000.00
> 02-plan-o...@02.ih ()
> S  1643.48  02-plan...@02.ih ()
> S  1634.82  02-plan...@02.ih ()
> M
> -8000.00
> 02-plan-saueleng...@02.ih ()
> S  1674.29  02-plan2...@02.ih ()
> S  1673.77  02-plan...@02.ih ()
>
> cheers,
> Axel
>
> *Gesendet:* Mittwoch, 20. Januar 2021 um 09:10 Uhr
> *Von:* "Benedikt Hallinger" 
> *An:* "List for Therion users" 
> *Betreff:* Re: [Therion] Splays appearing when not selected
> I just recompiled and can confirm that my problem indeed was the same
> and is gone with therion 5.5.6+5208297 (2021-01-19)
>
> Good work!
> Thank you!
>
>
> Am 2021-01-19 22:00, schrieb Benedikt Hallinger:
> > Hello,
> > Axel and i had the same bug, and we noticed that when explicitely
> > select the wall source at the export lox command, the issue is solved
> > ("export model -o out.lox -wall-source maps").
> >
> > Personally i would assume this is a bug, because when i select
> > datasets i would want the remaining data to be not present in my
> > output. That is the purpose of selecting in the first place, isn’t it?
> >
> >
> >> Am 19.01.2021 um 15:48 schrieb Tarquin Wilton-Jones via Therion
> >> :
> >>
> >> Hi Rhys,
> >>
> >>> I have noticed something that I am not sure if it's a bug or not. I
> >>> am
> >>> trying to export a selected bit of a survey as a loch file:
> >>
> >> From my experience...
> >> Lox file export will always select all of the survey that were
> >> imported.
> >> It will generate walls using all splays. It will use all scraps to
> >> enhance the passage walls, even if you do not select them. If they
> >> exist
> >> in any surveys or subsurveys, they are used, no matter which survey or
> >> map is selected.
> >>
> >> I always assumed this was intentional behaviour.
> >>
> >> Personally, I have wanted to be able to select the specific maps that
> >> should be used for lox, since I may have more than one version of a
> >> survey in my data - traces over an old low quality survey, and a new
> >> high quality survey of the same cave. Lox export insists on trying to
> >> merge both versions rather than being able to select just one of them.
> >>
> >> Cheers,
> >>
> >> Tarquin
> >> ___
> >> Therion mailing list
> >> Therion@speleo.sk
> >> https://mailman.speleo.sk/listinfo/therion
> > ___
> > Therion mailing list
> > Therion@speleo.sk
> > https://mailman.speleo.sk/listinfo/therion
> ___
> Therion 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] Splays appearing when not selected

[Axel]

morning,

 

just had time to try the fix (5.5.6+5208297) and it solves the issue Benedikt mentioned in my projects as well,
thx!

 

also had another look at my cavern error -- 1 issue (label with attr selected in layout/ wont compile unless -d option is choosen).

looking at the map/scrap selection I get huge numbers for the map and wonder if that might cause the problem? I draw all my maps with Inkscape but checked the th2 files and found nothing strange+ it compiles without a problem with the normal label...

 

### export maps & scraps selection #
M -8000.00 IH_HauptPlan@IH ()
M -8000.00 02-plan-o...@02.ih ()
S  1643.48  02-plan...@02.ih ()
S  1634.82  02-plan...@02.ih ()
M -8000.00 02-plan-saueleng...@02.ih ()
S  1674.29  02-plan2...@02.ih ()
S  1673.77  02-plan...@02.ih ()

 

cheers,

Axel


 

Gesendet: Mittwoch, 20. Januar 2021 um 09:10 Uhr
Von: "Benedikt Hallinger" 
An: "List for Therion users" 
Betreff: Re: [Therion] Splays appearing when not selected

I just recompiled and can confirm that my problem indeed was the same
and is gone with therion 5.5.6+5208297 (2021-01-19)

Good work!
Thank you!


Am 2021-01-19 22:00, schrieb Benedikt Hallinger:
> Hello,
> Axel and i had the same bug, and we noticed that when explicitely
> select the wall source at the export lox command, the issue is solved
> ("export model -o out.lox -wall-source maps").
>
> Personally i would assume this is a bug, because when i select
> datasets i would want the remaining data to be not present in my
> output. That is the purpose of selecting in the first place, isn’t it?
>
>
>> Am 19.01.2021 um 15:48 schrieb Tarquin Wilton-Jones via Therion
>> :
>>
>> Hi Rhys,
>>
>>> I have noticed something that I am not sure if it's a bug or not. I
>>> am
>>> trying to export a selected bit of a survey as a loch file:
>>
>> From my experience...
>> Lox file export will always select all of the survey that were
>> imported.
>> It will generate walls using all splays. It will use all scraps to
>> enhance the passage walls, even if you do not select them. If they
>> exist
>> in any surveys or subsurveys, they are used, no matter which survey or
>> map is selected.
>>
>> I always assumed this was intentional behaviour.
>>
>> Personally, I have wanted to be able to select the specific maps that
>> should be used for lox, since I may have more than one version of a
>> survey in my data - traces over an old low quality survey, and a new
>> high quality survey of the same cave. Lox export insists on trying to
>> merge both versions rather than being able to select just one of them.
>>
>> Cheers,
>>
>> Tarquin
>> ___
>> Therion mailing list
>> Therion@speleo.sk
>> https://mailman.speleo.sk/listinfo/therion
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
___
Therion 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] Splays appearing when not selected

[Benedikt Hallinger]

I just recompiled and can confirm that my problem indeed was the same 
and is gone with therion 5.5.6+5208297 (2021-01-19)


Good work!
Thank you!


Am 2021-01-19 22:00, schrieb Benedikt Hallinger:

Hello,
Axel and i had the same bug, and we noticed that when explicitely
select the wall source at the export lox command, the issue is solved
("export model -o out.lox -wall-source maps").

Personally i would assume this is a bug, because when i select
datasets i would want the remaining data to be not present in my
output. That is the purpose of selecting in the first place, isn’t it?


Am 19.01.2021 um 15:48 schrieb Tarquin Wilton-Jones via Therion 
:


Hi Rhys,

I have noticed something that I am not sure if it's a bug or not. I 
am

trying to export a selected bit of a survey as a loch file:


From my experience...
Lox file export will always select all of the survey that were 
imported.

It will generate walls using all splays. It will use all scraps to
enhance the passage walls, even if you do not select them. If they 
exist

in any surveys or subsurveys, they are used, no matter which survey or
map is selected.

I always assumed this was intentional behaviour.

Personally, I have wanted to be able to select the specific maps that
should be used for lox, since I may have more than one version of a
survey in my data - traces over an old low quality survey, and a new
high quality survey of the same cave. Lox export insists on trying to
merge both versions rather than being able to select just one of them.

Cheers,

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

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

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

Re: [Therion] Splays appearing when not selected

[Tarquin Wilton-Jones via Therion]

> Tarquin, did you know, there is a "-walls off" option for scrap?

Very neat :)

I will certainly use that.

It does limit you though, to only being able to hardcode it into the
scrap. You could not prepare two different versions of the .lox by
selecting the relevant maps (plan and extended elevations at the same
time). You could prepare the two versions, but only by manually editing
the scraps in between.

For me, the existing solution is fine, but does seem oddly limited.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Splays appearing when not selected

[Stacho Mudrak]

Hi,

survey selection was really ignored when splay shots 3D models were
exported. I hope, it is fixed in 5208297
.
Thanks again for finding out Rhys, that it was just a splay shots issue!

Tarquin, did you know, there is a "-walls off" option for scrap? It was
designed specifically for this purpose. To turn off wall generation from
unwanted scraps - low-quality surveys in your case. Or is there some
problem with using it? OK, you have to specify it for every scrap, maybe it
should be also supported for maps. Would it solve your problem?

The original idea was to generate walls from all available information
(centreline lrud, splays, and scraps) in the given survey. It is not yet
fully implemented but still remains a goal. Therefore selection by surveys
and not by maps. Selection of scraps in selected surveys for 3D export
works I assume.

S.



On Tue, 19 Jan 2021 at 15:48, Tarquin Wilton-Jones via Therion <
therion@speleo.sk> wrote:

> Hi Rhys,
>
> > I have noticed something that I am not sure if it's a bug or not. I am
> > trying to export a selected bit of a survey as a loch file:
>
> From my experience...
> Lox file export will always select all of the survey that were imported.
> It will generate walls using all splays. It will use all scraps to
> enhance the passage walls, even if you do not select them. If they exist
> in any surveys or subsurveys, they are used, no matter which survey or
> map is selected.
>
> I always assumed this was intentional behaviour.
>
> Personally, I have wanted to be able to select the specific maps that
> should be used for lox, since I may have more than one version of a
> survey in my data - traces over an old low quality survey, and a new
> high quality survey of the same cave. Lox export insists on trying to
> merge both versions rather than being able to select just one of them.
>
> Cheers,
>
> Tarquin
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Splays appearing when not selected

[Benedikt Hallinger]

Hello,
Axel and i had the same bug, and we noticed that when explicitely select the 
wall source at the export lox command, the issue is solved ("export model -o 
out.lox -wall-source maps").

Personally i would assume this is a bug, because when i select datasets i would 
want the remaining data to be not present in my output. That is the purpose of 
selecting in the first place, isn’t it?


> Am 19.01.2021 um 15:48 schrieb Tarquin Wilton-Jones via Therion 
> :
> 
> Hi Rhys,
> 
>> I have noticed something that I am not sure if it's a bug or not. I am
>> trying to export a selected bit of a survey as a loch file:
> 
> From my experience...
> Lox file export will always select all of the survey that were imported.
> It will generate walls using all splays. It will use all scraps to
> enhance the passage walls, even if you do not select them. If they exist
> in any surveys or subsurveys, they are used, no matter which survey or
> map is selected.
> 
> I always assumed this was intentional behaviour.
> 
> Personally, I have wanted to be able to select the specific maps that
> should be used for lox, since I may have more than one version of a
> survey in my data - traces over an old low quality survey, and a new
> high quality survey of the same cave. Lox export insists on trying to
> merge both versions rather than being able to select just one of them.
> 
> Cheers,
> 
> Tarquin
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Splays appearing when not selected

[Tarquin Wilton-Jones via Therion]

Hi Rhys,

> I have noticed something that I am not sure if it's a bug or not. I am
> trying to export a selected bit of a survey as a loch file:

From my experience...
Lox file export will always select all of the survey that were imported.
It will generate walls using all splays. It will use all scraps to
enhance the passage walls, even if you do not select them. If they exist
in any surveys or subsurveys, they are used, no matter which survey or
map is selected.

I always assumed this was intentional behaviour.

Personally, I have wanted to be able to select the specific maps that
should be used for lox, since I may have more than one version of a
survey in my data - traces over an old low quality survey, and a new
high quality survey of the same cave. Lox export insists on trying to
merge both versions rather than being able to select just one of them.

Cheers,

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

Re: [Therion] Splays appearing when not selected

[Stacho Mudrak]

Thanks Rhys for pointing this out and discovering, that it is a splay shot
issue.

I have recently seen this behaviour also in my dataset but had no time yet
to investigate. With knowing that it is a splay shot issue I hope it will
be much easier.

Best regards, S.

On Tue, 19 Jan 2021 at 15:10, Rhys Tyers  wrote:

> Hello,
>
> I have noticed something that I am not sure if it's a bug or not. I am
> trying to export a selected bit of a survey as a loch file:
>
> source "data/system_migovec.th"
> select vrtnarija_vilinska@system_migovec
> export model -o outputs/vrtnarija.lox
>
> This seems to correctly export the centerline only for
> "vrtnarija_vilinska" but if I turn on the walls in loch then other bits of
> the survey are shown.
>
> Centerline correct:
> [image: image.png]
> With walls there are other bits of passage shown:
> [image: image.png]
>
> These seem to correspond to bits of passage that have splays and LRUD data
> so it seems like those aren't correctly filtered out using the "select".
>
> Using:
> therion 5.5.6 (2020-12-27)
>   - using Proj 6.3.1, compiled against 6.3.1
>
> Thanks,
> Rhys
>
> ___
> 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] Splays appearing when not selected

[Rhys Tyers]

Hello,

I have noticed something that I am not sure if it's a bug or not. I am
trying to export a selected bit of a survey as a loch file:

source "data/system_migovec.th"
select vrtnarija_vilinska@system_migovec
export model -o outputs/vrtnarija.lox

This seems to correctly export the centerline only for "vrtnarija_vilinska"
but if I turn on the walls in loch then other bits of the survey are shown.

Centerline correct:
[image: image.png]
With walls there are other bits of passage shown:
[image: image.png]

These seem to correspond to bits of passage that have splays and LRUD data
so it seems like those aren't correctly filtered out using the "select".

Using:
therion 5.5.6 (2020-12-27)
  - using Proj 6.3.1, compiled against 6.3.1

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

Re: [Therion] Splays - Revisiting Breaking extended elevations

[Tarquin Wilton-Jones via Therion]

> 1. splay shots should be extended relatively to survey shot with closest
> (horizontal) bearing

Holy _, somebody buy this man a beer!

Seriously, if I ever meet you in person, I owe you one. This is going to
make our surveys so much easier to draw.

You will also have Gareth's gratitude once he gets off his bike and
realises what you have done :)

> extend ignore   

Glad you went with your own suggestion in the end. Fewer keywords to
learn, and the controls are simple enough, and very intuitive. AFAICT,
it does allow you to offer all of the controls needed even for complex
looping (bugs aside).

> Could you please try your datasets?

I do not yet have enough loops in my system to test it in anger, but I
will let you know once I get a more complex extended elevation to draw up.

(In surveys where I do have enough loops, I use projected elevation
instead.)

Hopefully Marco can use something more convoluted for testing. An oxbow
maze should be perfect.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Splays - Revisiting Breaking extended elevations

[Stacho Mudrak]

I have tried to fix all the extended elevation issues in the latest
development snapshot (commit 6860f82

).

1. splay shots should be extended relatively to survey shot with closest
(horizontal) bearing

2. there is a possibility to specify reduction ratio for extended elevation
(0 = vertical, 100 = normal left/right) - just use "extend "

3. extend ignore via path of 3 points should now work -- use "extend ignore
  ". I think this should allow all crazy loop configurations to
be solved, but I am not still 100% sure.

Unfortunately (but not surprisingly :/), there was a bug with the extended
elevation algorithm. In the case there were loops present in the
centerline, it caused some random behaviour.

I have tried to fix this bug, but it required quite a deep change to the
code. My data seems to work, but I suppose, there may be some cases when it
still can fail. Could you please try your datasets?

Thanks, S.


On Thu, 30 Jul 2020 at 01:18, Olly Betts  wrote:

> On Wed, Jul 29, 2020 at 06:25:50PM +0100, Tarquin Wilton-Jones via Therion
> wrote:
> > TopoDroid, Pocket Topo and Survex all extend only the legs. They all
> > keep the splays in the "same" direction (relative to the leg) as they
> > were before, which makes them normally perfect for drawing extended
> > elevations. They can project forwards and backwards out of the page (so
> > to speak), so they end up the right distance, visually, from the station.
> >
> > There is always the issue when you are at a station where the extend
> > direction changes from left to right or vertical, since at that point
> > you don't know whether a splay should take its direction from the leg
> > before or the leg after (or the "nearest" leg to it - perhaps the most
> > useful answer). Survex gets this wrong sometimes, but is normally useful.
>
> Examples of where Survex it gets it wrong are definitely of interest.
>
> I added extending of splays just over 3 years ago, and the NEWS entry
> (which also explains the algorithm used) explicitly invites feedback:
>
> | + Splays are now carried over the extended survey.  The current
> |   handling is simplistic, but should do a good enough job to be more
> |   useful than discarding splays.  The splays at each station are all
> |   rotated together based on the bearing between the stations either
> |   side of the current one along the first path extended through that
> |   station.  This nicely handles dead ends and the situation at the top
> |   or bottom of a pitch, and should tend to pick an angle close to the
> |   passage orientation along a traverse.  It's weakest at junctions.
> |   Feedback (especially examples which could be handled better) most
> |   welcome.
>
> But so far the only thing I could possibly count as feedback on this
> subject is what you wrote above (which is good to hear overall, but it'd
> be helpful to have some details of where you've seen it go wrong).
>
> 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] Splays - Revisiting Breaking extended elevations

[Olly Betts]

On Wed, Jul 29, 2020 at 06:25:50PM +0100, Tarquin Wilton-Jones via Therion 
wrote:
> TopoDroid, Pocket Topo and Survex all extend only the legs. They all
> keep the splays in the "same" direction (relative to the leg) as they
> were before, which makes them normally perfect for drawing extended
> elevations. They can project forwards and backwards out of the page (so
> to speak), so they end up the right distance, visually, from the station.
> 
> There is always the issue when you are at a station where the extend
> direction changes from left to right or vertical, since at that point
> you don't know whether a splay should take its direction from the leg
> before or the leg after (or the "nearest" leg to it - perhaps the most
> useful answer). Survex gets this wrong sometimes, but is normally useful.

Examples of where Survex it gets it wrong are definitely of interest.

I added extending of splays just over 3 years ago, and the NEWS entry
(which also explains the algorithm used) explicitly invites feedback:

| + Splays are now carried over the extended survey.  The current
|   handling is simplistic, but should do a good enough job to be more
|   useful than discarding splays.  The splays at each station are all
|   rotated together based on the bearing between the stations either
|   side of the current one along the first path extended through that
|   station.  This nicely handles dead ends and the situation at the top
|   or bottom of a pitch, and should tend to pick an angle close to the
|   passage orientation along a traverse.  It's weakest at junctions.
|   Feedback (especially examples which could be handled better) most
|   welcome.

But so far the only thing I could possibly count as feedback on this
subject is what you wrote above (which is good to hear overall, but it'd
be helpful to have some details of where you've seen it go wrong).

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

Re: [Therion] Splays - Revisiting Breaking extended elevations

[Tarquin Wilton-Jones via Therion]

> And I assumed that if I placed the extends in-line, the splays would
> behave.  I am not sure though, as I have not carried out any explicit tests.

Sadly not. Therion - in all cases - extends the splays in the same
direction as the default direction from that station (or wherever you
placed the inline extend command). Basically, the splays act like legs.

This is really quite useless when you are trying to draw the passage
shape correctly.

TopoDroid, Pocket Topo and Survex all extend only the legs. They all
keep the splays in the "same" direction (relative to the leg) as they
were before, which makes them normally perfect for drawing extended
elevations. They can project forwards and backwards out of the page (so
to speak), so they end up the right distance, visually, from the station.

There is always the issue when you are at a station where the extend
direction changes from left to right or vertical, since at that point
you don't know whether a splay should take its direction from the leg
before or the leg after (or the "nearest" leg to it - perhaps the most
useful answer). Survex gets this wrong sometimes, but is normally useful.

Even so, that issue is just peanuts compared with how difficult it
currently is to use Therion's exported XVI to draw your extended
elevations. I would take an odd splay being wrong over *all* splays
being wrong any day.

Virtual awards await anyone who chooses to attack this problem.

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

Re: [Therion] Splays - Revisiting Breaking extended elevations

[Bruce Mutton]

Yeah, I'd call it a bug now.

I think I first noticed this behaviour early in 2015, and if that was the case 
it would have been around version 5.3.16 (the date and version on my first 
decent extended elevation map).

It would have been my first forays into extended elevations and I quickly 
switched from in-line to data blocks for extends for the reasons outlined here 
<https://therion.speleo.sk/wiki/extend> .

Because I was already drawing completely electronic, not using pdfs or pencil 
sketches, I was using the xvi s exported from PocketTopo and so the Therion 
exports were a curiosity only.

Placing the extend statements in a block was essentially an undocumented 
feature, and so I assumed it was my fault for stretching boundaries.

And I assumed that if I placed the extends in-line, the splays would behave.  I 
am not sure though, as I have not carried out any explicit tests.

 

I’ve really only been prompted to bring it up now because a) we’re making good 
progress on extend behaviour and blocks of extend statements are becoming 
mainstream, and b) I have inherited some survey notes for which the sketches 
will be best drawn in pencil over a pdf printout.

 

Bruce

 

 

-Original Message-
From: Therion  On Behalf Of Tarquin Wilton-Jones via 
Therion
Sent: Monday, 27 July 2020 21:27
To: therion@speleo.sk
Cc: Tarquin Wilton-Jones 
Subject: Re: [Therion] Splays - Revisiting Breaking extended elevations

 

> Extending left and right using a block of control statements (as 

> opposed to in-line with the survey data) results in Therion extending 

> the splays incorrectly.

 

Wait ... that's a bug?!

I thought Therion just didn't handle splays well compared with Survex.

 

> Notice how all the splays are extended in the direction that the legs 

> are extended in.

 

Drives me crazy. Pretty bad behaviour, and makes all the splays useless for 
drawing extended elevations.

 

Does this mean that there is actually a solution to this, by using inline 
extend commands?

___

Therion mailing list

 <mailto:Therion@speleo.sk> Therion@speleo.sk

 <https://mailman.speleo.sk/listinfo/therion> 
https://mailman.speleo.sk/listinfo/therion

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

Re: [Therion] Splays - Revisiting Breaking extended elevations

[Tarquin Wilton-Jones via Therion]

> Extending left and right using a block of control statements (as opposed
> to in-line with the survey data) results in Therion extending the splays
> incorrectly.

Wait ... that's a bug?!
I thought Therion just didn't handle splays well compared with Survex.

> Notice how all the splays are extended in the direction that the legs
> are extended in.

Drives me crazy. Pretty bad behaviour, and makes all the splays useless
for drawing extended elevations.

Does this mean that there is actually a solution to this, by using
inline extend commands?
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] splays

[Stacho Mudrak]

In the latest version (5.3.12) released today, there is at least metapost
attribute you can use to color splay shots.

Just redefine l_survey_cave symbol in layout, e.g. 50% gray like this:

code metapost
  def l_survey_cave (expr P) =
T:=identity;
pickup PenC;
if ATTR__shotflag_splay:
  thdraw P withcolor (0.5,0.5,0.5);
else:
  thdraw P;
fi;
  enddef;
endcode

S.


On 13 December 2013 13:55, Erik VdBroeck  wrote:

> I agree with Marco about the colour of splays in different colours than the
> legs. How can we achieve this?
> erik
>
> -Original Message-
> From: Marco Corvi [mailto:marco_corvi at yahoo.com]
> Sent: jeudi 12 décembre 2013 12:53
> To: therion at speleo.sk
> Subject: [Therion] splays
>
>
> i would like that splays in pdf having only the centerline ( no scraps ),
> are drawn with different color than legs.
> any suggestion ?
> ( besides fiddling with the sources )
> thanks, marco
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20131222/d8b32fc9/attachment.html>

[Therion] splays

[Erik VdBroeck]

I agree with Marco about the colour of splays in different colours than the
legs. How can we achieve this? 
erik

-Original Message-
From: Marco Corvi [mailto:marco_co...@yahoo.com] 
Sent: jeudi 12 décembre 2013 12:53
To: therion at speleo.sk
Subject: [Therion] splays


i would like that splays in pdf having only the centerline ( no scraps ),
are drawn with different color than legs.
any suggestion ?
( besides fiddling with the sources )
thanks, marco

[Therion] splays

[Marco Corvi]

i would like that splays in pdf having only the centerline ( no scraps ), are 
drawn with different color than legs.
any suggestion ?
( besides fiddling with the sources )
thanks, marco

[Therion] Splays in pdf plans

[Andrew Atkinson]

Hope this does not break the tread, but as I am not receiving the mails
I cannot do a reply, just have to read the archives

> And this next snapshot from the same pdf file shows passages in various
> stages of drawing completion.  All of the passages have splay shots, but
> only the passages that have the centreline included in the map definition
> have their splays included in the output.
> 
> 
> This is a large project, so I may have forgotten something, but I am pretty
> sure that is all there is to it.  They are the principles I have followed on
> other smaller projects and they work out OK.
>  
> 
> I should point out that I have never used the shot flag 'splay'.  All of my
> data with splay shots comes from PocketTopo, and so I make use of the
> default behaviour.
>  
> 
> "All shots having one of the stations named either '.' or '-' are splay
> shots by default" (from the Therion Book)
>  
> 
> Explicitly using the shot flag splay may invoke different behaviour - I have
> never tried.

Thanks Bruce, this gave me the hints I needed to do it.
So I was including the survey file in the map, but that did not work.
Still only got the centreline but no splays. I am also using pockettopo
data with - as the to station.
What I was doing wrong. I only had one map in the file so was allowing
therion to do its stuff with no select option in the config file, also
as the map has map information you do not need to use -proj plan, it
just works. So to get splays displayed as the 'default' you need to
select the map it is in (possible a high level one would work but I have
tried enough for now) and explicitly have  -proj plan on the map group,
otherwise you only get the centreline.

thanks

Andrew

[Therion] Splays in pdf plans

[Bruce]

>I have the same issue has Andrew's one: cannot display right and left
indications in my pdf (map/ projection plan)

despite they are in the centerline data (with option "walls auto" or "wall
on").



Left right up down (LRUD)are not the same as splay shots.

LRUD display as shaded quadrilaterals overlaid on the centreline, provided
you also have;

a) Background colour different to foreground colour, and

b) in an established project, provided you also have the centreline in
question in the map definition.



This is how you change the map foreground colour in a layout.



  colour map-fg altitude# Shading in cave passage, , ,
, 



The image below shows an example of LRUD (blue) and survey centrelines part
of an established map.  There are no splays in this one.





And this next snapshot from the same pdf file shows passages in various
stages of drawing completion.  All of the passages have splay shots, but
only the passages that have the centreline included in the map definition
have their splays included in the output.





This is a large project, so I may have forgotten something, but I am pretty
sure that is all there is to it.  They are the principles I have followed on
other smaller projects and they work out OK.



I should point out that I have never used the shot flag 'splay'.  All of my
data with splay shots comes from PocketTopo, and so I make use of the
default behaviour.



"All shots having one of the stations named either '.' or '-' are splay
shots by default" (from the Therion Book)



Explicitly using the shot flag splay may invoke different behaviour - I have
never tried.



Bruce



-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 12425 bytes
Desc: image001.jpg
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 35860 bytes
Desc: image002.jpg
URL: