Re: [Therion] Splays appearing when not selected

[Stacho Mudrak]

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 <
xavier.rob...@univ-grenoble-alpes.fr> 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 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 therio

Re: [Therion] endless chimneys (was: Splays appearing when not selected)

[Benedikt Hallinger]

Hello,
that is not the case here: the sole drawer was myself and there is no 
overlap (i know of - the data is self contained in that folder).


The scraps are like this:
map 1-Deckenschlot-vor-KPZ
  1.1-2-26a-SP1-Aufstieg   # <- has stations, is OK
  1.1-2-26a-SP1# <- has stations, is OK
  1.1-2-26a-SP2# <- last known station at start. OK until 
the middle of the scrap!
  1.1-2-26a-SP3# <- no station; joined to 1.1-2-26a-SP2, 
completely "endless chimney"

endmap

What puzzles me is that the chimney starts at a bend in my scrap.
The altitude range is that of the entire cave, and thus the 
"endless-chimney" is very prominent; I think this is a second issue we 
should tackle also (it will somewhat help with the issue here, but not 
solve it).



Am 2021-02-02 10:01, schrieb 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 [1]
# wrong dimensions in lox
#source ../../../Hirlatzhoehle/Zubringer/therion/Zubringer.th [2]
# 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 [1]"
the
bug
occurs.
That command sources the entire cave.
If i do source just the region with "source
../../../Hirlatzhoehle/Zubringer/therion/Zubringer.th [2]" (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 on

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
Therio