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 <[email protected]> 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 <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] > <mailto:[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] >> <mailto:[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] >>> <mailto:[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] >>>> <mailto:[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] <mailto:[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] <mailto:[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
