<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><div class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">Xavier<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">Le 2 févr. 2021 à 10:01, Martin Sluka via Therion <<a href="mailto:therion@speleo.sk" class="">therion@speleo.sk</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Beni<div class=""><br class=""></div><div class=""><br class=""></div><div class="">that is not a problem of „spikes“ but as you may see on attached picture I had the same problem with one my project.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">HTH</div><div class=""><br class=""></div><div class="">Martin</div><div class=""><br class=""></div><div class=""><span id="cid:F16BB8B7-9B63-4648-A365-727EB6DC9C93"><Snímek obrazovky 2021-02-02 v 9.55.23.png></span></div><div class=""><br class=""><blockquote type="cite" class="">2. 2. 2021 v 9:48, Benedikt Hallinger <<a href="mailto:beni@hallinger.org" class="">beni@hallinger.org</a>>:<br class=""><br class="">Hm, that didn't help, unfortunately.<br class="">in the meantime I also tried coloring the PDF by altitude, this is not affected and working like expected.<br class=""><br class="">Martin has readonly svn access to the data and may investigate in the dataset?<br class="">I just unlocked it for that purpose.<br class=""><br class="">The affected thconfig is svn/Hirlatzhoehle/Zubringer/therion/thconfig<br class="">and the scrap in question is in svn/Hirlatzhoehle/Zubringer/1/therion/1.1.plan-2-b.th2<br class="">The last known station is 1.2.26j<br class=""><br class="">In the thconfig I noted the following (just local here)<br class=""><br class=""># Hirlatzdaten importieren<br class="">source ../../../Hirlatzhoehle/therion/<a href="http://hirlatzhoehle.th/" class="">Hirlatzhoehle.th</a> # wrong dimensions in lox<br class="">#source ../../../Hirlatzhoehle/Zubringer/therion/<a href="http://zubringer.th/" class="">Zubringer.th</a> # works somewhat-ok in lox (still extruded to top of box, but the box itself is small)<br class=""><br class=""><br class="">Greetings,<br class="">Beni<br class=""><br class=""><br class=""><br class="">Am 2021-02-02 6:31, schrieb Stacho Mudrak:<br class=""><blockquote type="cite" class="">In that case and if there is just one station in this wrong scrap,<br class="">maybe inserting point dimensions with some reasonable -value [<up><br class=""><down> m] over this station in the scrap should help to normalize<br class="">these crazy heights.<br class="">If there are no up/down data in the centreline, therion calculates<br class="">up/down dimensions from shots from a given station. It is not a<br class="">perfect algorithm and in your case, there is some issue. Placing a<br class="">point dimension close to the station should override this calculation.<br class="">HTH, S.<br class="">On Mon, 1 Feb 2021 at 23:10, Benedikt Hallinger <<a href="mailto:beni@hallinger.org" class="">beni@hallinger.org</a>><br class="">wrote:<br class=""><blockquote type="cite" class="">It's hard to isolate.<br class="">The structure is like this:<br class="">Hirlatzhoehle/Zubringer/,<br class="">where Zubringer contains more surveys.<br class="">Each folder has its own therion/ subfolder containing the therion<br class="">sources.<br class="">If i do "source ../../../Hirlatzhoehle/therion/<a href="http://hirlatzhoehle.th/" class="">Hirlatzhoehle.th</a>" the<br class="">bug<br class="">occurs.<br class="">That command sources the entire cave.<br class="">If i do source just the region with "source<br class="">../../../Hirlatzhoehle/Zubringer/therion/<a href="http://zubringer.th/" class="">Zubringer.th</a>" (which<br class="">contains<br class="">essentially the same maps and scraps!) the bug occurs.<br class="">I have no idea how to track this don further, since we already talk<br class="">about alot of data (2.4 km).<br class="">Am 2021-02-01 21:37, schrieb Benedikt Hallinger:<br class=""><blockquote type="cite" class="">I try to boil it down<br class="">Am 2021-02-01 21:12, schrieb Stacho Mudrak:<br class=""><blockquote type="cite" class="">Hmmm, even scraps extending far beyond a known station could<br class=""></blockquote></blockquote>cause a<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">problem - usually, it is the case with steep passages. In your<br class=""></blockquote></blockquote>case,<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">it looks like some outline problem.<br class="">Are you able to isolate such scrap and send me some minimalistic<br class="">sample?<br class="">Thanks, S.<br class="">On Mon, 1 Feb 2021 at 20:10, Benedikt Hallinger<br class=""></blockquote></blockquote><<a href="mailto:beni@hallinger.org" class="">beni@hallinger.org</a>><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">wrote:<br class=""><blockquote type="cite" class="">Hi, thanks for responding,<br class="">i have the problem only tested with the lox.<br class="">The red box fits nicely my selected data.<br class="">The survex file also is OK.<br class="">Probably it's caused by artifacts, see screenshot.<br class="">Thats an old bug, and caused by some scraps extending far beyond<br class=""></blockquote></blockquote></blockquote>a<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">known<br class="">station (walls are marked unsurveyed).<br class="">Am 2021-02-01 19:52, schrieb Stacho Mudrak:<br class=""><blockquote type="cite" class="">Hi Beni,<br class="">thanks for review.<br class="">Are you having coloring problem with .lox file or .pdf map?<br class="">I have tried on my dataset, but when I select whole cave -<br class=""></blockquote></blockquote></blockquote></blockquote>entire<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">color range is used - from magenta to red.<br class="">When I select just a part of the cave, coloring changes and the<br class=""></blockquote>whole<br class=""><blockquote type="cite" class="">range is used for selected part.<br class="">Does your red rectangle fit selected data or is it much bigger?<br class=""></blockquote></blockquote></blockquote></blockquote>If<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">the<br class=""><blockquote type="cite" class="">latter is the case, there must be some artifacts still<br class=""></blockquote></blockquote></blockquote></blockquote>remaining -<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">that were not removed with selection. Maybe some stations? Does<br class=""></blockquote>this<br class=""><blockquote type="cite" class="">problem remain also with aven .3d export?<br class="">It would be great if we could find this bug before therion goes<br class=""></blockquote></blockquote></blockquote></blockquote>to<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">debian release.<br class="">S.<br class="">On Mon, 1 Feb 2021 at 10:17, Benedikt Hallinger<br class=""></blockquote><<a href="mailto:beni@hallinger.org" class="">beni@hallinger.org</a>><br class=""><blockquote type="cite" class="">wrote:<br class=""><blockquote type="cite" class="">Checked it, looks good for me (data selection, and pdf map<br class=""></blockquote></blockquote>printout<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">with<br class="">people showing up again), with one exception:<br class="">- I source all of the cave's data. (ok)<br class="">- Then i select jsut a part of it. (ok)<br class="">- The lox output contains just the selected part (ok)<br class="">- The altitude coloring is all the same, despite having<br class=""></blockquote></blockquote>significant<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">altitude changes in the dataset.<br class="">The reason seems to be that the coloring is done according in<br class="">relation<br class="">to ALL the cave, not just the selected parts - in comparison<br class=""></blockquote></blockquote></blockquote></blockquote></blockquote>to<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">the<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">entire system the altitude difference is negligible, but i<br class=""></blockquote></blockquote>expected<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">the<br class="">lox to generate the altitude band according to the actual<br class=""></blockquote></blockquote></blockquote></blockquote></blockquote>min/max<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">values<br class="">of the selected dataset.<br class="">$ therion -v<br class="">therion 5.5.6 (2020-12-27)<br class="">- using Proj 7.2.1, compiled against 7.2.1<br class="">But: therion compile cdf201b5bf921 has the same behaviour.<br class="">Am 2021-01-27 8:59, schrieb Benedikt Hallinger:<br class=""><blockquote type="cite" class="">I just did apt-get update, and see 5.5.6ds1-5<br class="">That is the old version, right? I do wait for 5.5.6ds1-6 ?<br class="">Am 2021-01-26 16:16, schrieb Wookey:<br class=""><blockquote type="cite" class="">On 2021-01-24 14:40 +0100, Benedikt Hallinger wrote:<br class=""><blockquote type="cite" class="">Wookey, when is this expected to appear in testing?<br class="">I would test it<br class=""></blockquote>It's there now.<br class="">Wookey<br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></div></div></div></blockquote></div></div></body></html>