[Therion] Splays appearing when not selected

Wed Feb 3 12:01:15 CET 2021

I second that: My (similar) problem is solved as well.

Am 2021-02-03 11:55, schrieb 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 <lists at group-s.sk> 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
>> <xavier.robert at 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
>> <therion at speleo.sk> 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
>> 
>> <Snímek obrazovky 2021-02-02 v 9.55.23.png>
>> 
>> 2. 2. 2021 v 9:48, Benedikt Hallinger <beni at hallinger.org>:
>> 
>> 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 [<up>
>> <down> 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 <beni at hallinger.org>
>> 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
>  <beni at hallinger.org>
> 
>> 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
>> <beni at hallinger.org>
>> 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
> 
> 
> Links:
> ------
> [1] http://hirlatzhoehle.th/
> [2] http://zubringer.th/
> _______________________________________________
> Therion mailing list
> Therion at speleo.sk
> https://mailman.speleo.sk/listinfo/therion