[Therion] Splays appearing when not selected
Stacho Mudrak
lists at group-s.sk
Wed Feb 3 06:13:29 CET 2021
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
>
> <Sní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
> <http://hirlatzhoehle.th/> # wrong dimensions in lox
> #source ../../../Hirlatzhoehle/Zubringer/therion/Zubringer.th
> <http://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 [<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
> <http://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
> <http://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
>
> <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
>
>
>
> _______________________________________________
> Therion mailing list
> Therion at speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20210203/7a544c03/attachment.htm>
More information about the Therion
mailing list