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 < [email protected]> 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 <[email protected]> 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 <[email protected]>: > > 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 <[email protected]> > 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 > > <[email protected]> > > 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 > > <[email protected]> > > 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 > [email protected] > https://mailman.speleo.sk/listinfo/therion >
_______________________________________________ Therion mailing list [email protected] https://mailman.speleo.sk/listinfo/therion
