Hello, I have noticed something that I am not sure if it's a bug or not. I am trying to export a selected bit of a survey as a loch file: source "data/system_migovec.th" select vrtnarija_vilinska@system_migovec export model -o outputs/vrtnarija.lox This seems to correctly export the centerline only for "vrtnarija_vilinska" but if I turn on the walls in loch then other bits of the survey are shown. Centerline correct: [image: image.png] With walls there are other bits of passage shown: [image: image.png] These seem to correspond to bits of passage that have splays and LRUD data so it seems like those aren't correctly filtered out using the "select". Using: therion 5.5.6 (2020-12-27) - using Proj 6.3.1, compiled against 6.3.1 Thanks, Rhys
Thanks Rhys for pointing this out and discovering, that it is a splay shot issue. I have recently seen this behaviour also in my dataset but had no time yet to investigate. With knowing that it is a splay shot issue I hope it will be much easier. Best regards, S. On Tue, 19 Jan 2021 at 15:10, Rhys Tyers <rhystyers1@gmail.com> wrote:
Hello,
I have noticed something that I am not sure if it's a bug or not. I am trying to export a selected bit of a survey as a loch file:
source "data/system_migovec.th" select vrtnarija_vilinska@system_migovec export model -o outputs/vrtnarija.lox
This seems to correctly export the centerline only for "vrtnarija_vilinska" but if I turn on the walls in loch then other bits of the survey are shown.
Centerline correct: [image: image.png] With walls there are other bits of passage shown: [image: image.png]
These seem to correspond to bits of passage that have splays and LRUD data so it seems like those aren't correctly filtered out using the "select".
Using: therion 5.5.6 (2020-12-27) - using Proj 6.3.1, compiled against 6.3.1
Thanks, Rhys
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Hi Rhys,
I have noticed something that I am not sure if it's a bug or not. I am trying to export a selected bit of a survey as a loch file:
From my experience... Lox file export will always select all of the survey that were imported. It will generate walls using all splays. It will use all scraps to enhance the passage walls, even if you do not select them. If they exist in any surveys or subsurveys, they are used, no matter which survey or map is selected.
I always assumed this was intentional behaviour. Personally, I have wanted to be able to select the specific maps that should be used for lox, since I may have more than one version of a survey in my data - traces over an old low quality survey, and a new high quality survey of the same cave. Lox export insists on trying to merge both versions rather than being able to select just one of them. Cheers, Tarquin
Hello, Axel and i had the same bug, and we noticed that when explicitely select the wall source at the export lox command, the issue is solved ("export model -o out.lox -wall-source maps"). Personally i would assume this is a bug, because when i select datasets i would want the remaining data to be not present in my output. That is the purpose of selecting in the first place, isn’t it?
Am 19.01.2021 um 15:48 schrieb Tarquin Wilton-Jones via Therion <therion@speleo.sk>:
Hi Rhys,
I have noticed something that I am not sure if it's a bug or not. I am trying to export a selected bit of a survey as a loch file:
From my experience... Lox file export will always select all of the survey that were imported. It will generate walls using all splays. It will use all scraps to enhance the passage walls, even if you do not select them. If they exist in any surveys or subsurveys, they are used, no matter which survey or map is selected.
I always assumed this was intentional behaviour.
Personally, I have wanted to be able to select the specific maps that should be used for lox, since I may have more than one version of a survey in my data - traces over an old low quality survey, and a new high quality survey of the same cave. Lox export insists on trying to merge both versions rather than being able to select just one of them.
Cheers,
Tarquin _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
I just recompiled and can confirm that my problem indeed was the same and is gone with therion 5.5.6+5208297 (2021-01-19) Good work! Thank you! Am 2021-01-19 22:00, schrieb Benedikt Hallinger:
Hello, Axel and i had the same bug, and we noticed that when explicitely select the wall source at the export lox command, the issue is solved ("export model -o out.lox -wall-source maps").
Personally i would assume this is a bug, because when i select datasets i would want the remaining data to be not present in my output. That is the purpose of selecting in the first place, isn’t it?
Am 19.01.2021 um 15:48 schrieb Tarquin Wilton-Jones via Therion <therion@speleo.sk>:
Hi Rhys,
I have noticed something that I am not sure if it's a bug or not. I am trying to export a selected bit of a survey as a loch file:
From my experience... Lox file export will always select all of the survey that were imported. It will generate walls using all splays. It will use all scraps to enhance the passage walls, even if you do not select them. If they exist in any surveys or subsurveys, they are used, no matter which survey or map is selected.
I always assumed this was intentional behaviour.
Personally, I have wanted to be able to select the specific maps that should be used for lox, since I may have more than one version of a survey in my data - traces over an old low quality survey, and a new high quality survey of the same cave. Lox export insists on trying to merge both versions rather than being able to select just one of them.
Cheers,
Tarquin _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Fixed for me, thanks Stacho. On Fri, 22 Jan 2021 at 08:16, Axel <dropstone@gmx.de> wrote:
morning,
just had time to try the fix (5.5.6+5208297) and it solves the issue Benedikt mentioned in my projects as well, thx!
also had another look at my cavern error -- 1 issue (label with attr selected in layout/ wont compile unless -d option is choosen). looking at the map/scrap selection I get huge numbers for the map and wonder if that might cause the problem? I draw all my maps with Inkscape but checked the th2 files and found nothing strange+ it compiles without a problem with the normal label...
############### export maps & scraps selection ################# M -8999999999999999900000000000000000000000000000000000000000000000000000000000000000000000000000000000.00 IH_HauptPlan@IH () M -8999999999999999900000000000000000000000000000000000000000000000000000000000000000000000000000000000.00 02-plan-oben@02.IH () S 1643.48 02-plan1.3@02.IH () S 1634.82 02-plan1.2@02.IH () M -8999999999999999900000000000000000000000000000000000000000000000000000000000000000000000000000000000.00 02-plan-Sauelengang@02.IH () S 1674.29 02-plan2.10@02.IH () S 1673.77 02-plan2.9@02.IH ()
cheers, Axel
*Gesendet:* Mittwoch, 20. Januar 2021 um 09:10 Uhr *Von:* "Benedikt Hallinger" <beni@hallinger.org> *An:* "List for Therion users" <therion@speleo.sk> *Betreff:* Re: [Therion] Splays appearing when not selected I just recompiled and can confirm that my problem indeed was the same and is gone with therion 5.5.6+5208297 (2021-01-19)
Good work! Thank you!
Am 2021-01-19 22:00, schrieb Benedikt Hallinger:
Hello, Axel and i had the same bug, and we noticed that when explicitely select the wall source at the export lox command, the issue is solved ("export model -o out.lox -wall-source maps").
Personally i would assume this is a bug, because when i select datasets i would want the remaining data to be not present in my output. That is the purpose of selecting in the first place, isn’t it?
Am 19.01.2021 um 15:48 schrieb Tarquin Wilton-Jones via Therion <therion@speleo.sk>:
Hi Rhys,
I have noticed something that I am not sure if it's a bug or not. I am trying to export a selected bit of a survey as a loch file:
From my experience... Lox file export will always select all of the survey that were imported. It will generate walls using all splays. It will use all scraps to enhance the passage walls, even if you do not select them. If they exist in any surveys or subsurveys, they are used, no matter which survey or map is selected.
I always assumed this was intentional behaviour.
Personally, I have wanted to be able to select the specific maps that should be used for lox, since I may have more than one version of a survey in my data - traces over an old low quality survey, and a new high quality survey of the same cave. Lox export insists on trying to merge both versions rather than being able to select just one of them.
Cheers,
Tarquin _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Hi Axel, these big numbers are just NaNs in fact. It does not affect any output - it just means the map has no altitude associated with it. But thanks for finding out, I have tried to fix it in the latest commit, could you please try? I am just curious, what OS are you using? Normally - it should write nan instead of such a big number. This big number is just a fallback if the compiler does not support NaN. S. On Fri, 22 Jan 2021 at 09:16, Axel <dropstone@gmx.de> wrote:
morning,
just had time to try the fix (5.5.6+5208297) and it solves the issue Benedikt mentioned in my projects as well, thx!
also had another look at my cavern error -- 1 issue (label with attr selected in layout/ wont compile unless -d option is choosen). looking at the map/scrap selection I get huge numbers for the map and wonder if that might cause the problem? I draw all my maps with Inkscape but checked the th2 files and found nothing strange+ it compiles without a problem with the normal label...
############### export maps & scraps selection ################# M -8999999999999999900000000000000000000000000000000000000000000000000000000000000000000000000000000000.00 IH_HauptPlan@IH () M -8999999999999999900000000000000000000000000000000000000000000000000000000000000000000000000000000000.00 02-plan-oben@02.IH () S 1643.48 02-plan1.3@02.IH () S 1634.82 02-plan1.2@02.IH () M -8999999999999999900000000000000000000000000000000000000000000000000000000000000000000000000000000000.00 02-plan-Sauelengang@02.IH () S 1674.29 02-plan2.10@02.IH () S 1673.77 02-plan2.9@02.IH ()
cheers, Axel
*Gesendet:* Mittwoch, 20. Januar 2021 um 09:10 Uhr *Von:* "Benedikt Hallinger" <beni@hallinger.org> *An:* "List for Therion users" <therion@speleo.sk> *Betreff:* Re: [Therion] Splays appearing when not selected I just recompiled and can confirm that my problem indeed was the same and is gone with therion 5.5.6+5208297 (2021-01-19)
Good work! Thank you!
Am 2021-01-19 22:00, schrieb Benedikt Hallinger:
Hello, Axel and i had the same bug, and we noticed that when explicitely select the wall source at the export lox command, the issue is solved ("export model -o out.lox -wall-source maps").
Personally i would assume this is a bug, because when i select datasets i would want the remaining data to be not present in my output. That is the purpose of selecting in the first place, isn’t it?
Am 19.01.2021 um 15:48 schrieb Tarquin Wilton-Jones via Therion <therion@speleo.sk>:
Hi Rhys,
I have noticed something that I am not sure if it's a bug or not. I am trying to export a selected bit of a survey as a loch file:
From my experience... Lox file export will always select all of the survey that were imported. It will generate walls using all splays. It will use all scraps to enhance the passage walls, even if you do not select them. If they exist in any surveys or subsurveys, they are used, no matter which survey or map is selected.
I always assumed this was intentional behaviour.
Personally, I have wanted to be able to select the specific maps that should be used for lox, since I may have more than one version of a survey in my data - traces over an old low quality survey, and a new high quality survey of the same cave. Lox export insists on trying to merge both versions rather than being able to select just one of them.
Cheers,
Tarquin _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Hi StachoI mostly get -8999 etc for my maps (not near my computer so cannot be specific on the circumstances) especially where maps are composed of surveys rather than scraps. I'm using Windows 10.I was a little perplexed that the map altitudes are undefined. Shouldn't the second level maps just be a weighted average of the component maps, scraps or surveys?I will try the latest commit in a few days time. BruceSent from my Galaxy -------- Original message --------From: Stacho Mudrak <lists@group-s.sk> Date: 23/01/21 23:35 (GMT+12:00) To: List for Therion users <therion@speleo.sk> Subject: Re: [Therion] Splays appearing when not selected Hi Axel,these big numbers are just NaNs in fact. It does not affect any output - it just means the map has no altitude associated with it. But thanks for finding out, I have tried to fix it in the latest commit, could you please try?I am just curious, what OS are you using? Normally - it should write nan instead of such a big number. This big number is just a fallback if the compiler does not support NaN.S.On Fri, 22 Jan 2021 at 09:16, Axel <dropstone@gmx.de> wrote:morning, just had time to try the fix (5.5.6+5208297) and it solves the issue Benedikt mentioned in my projects as well, thx! also had another look at my cavern error -- 1 issue (label with attr selected in layout/ wont compile unless -d option is choosen). looking at the map/scrap selection I get huge numbers for the map and wonder if that might cause the problem? I draw all my maps with Inkscape but checked the th2 files and found nothing strange+ it compiles without a problem with the normal label... ############### export maps & scraps selection ################# M -8999999999999999900000000000000000000000000000000000000000000000000000000000000000000000000000000000.00 IH_HauptPlan@IH () M -8999999999999999900000000000000000000000000000000000000000000000000000000000000000000000000000000000.00 02-plan-oben@02.IH () S 1643.48 02-plan1.3@02.IH () S 1634.82 02-plan1.2@02.IH () M -8999999999999999900000000000000000000000000000000000000000000000000000000000000000000000000000000000.00 02-plan-Sauelengang@02.IH () S 1674.29 02-plan2.10@02.IH () S 1673.77 02-plan2.9@02.IH () cheers, Axel Gesendet: Mittwoch, 20. Januar 2021 um 09:10 Uhr Von: "Benedikt Hallinger" <beni@hallinger.org> An: "List for Therion users" <therion@speleo.sk> Betreff: Re: [Therion] Splays appearing when not selected I just recompiled and can confirm that my problem indeed was the same and is gone with therion 5.5.6+5208297 (2021-01-19) Good work! Thank you! Am 2021-01-19 22:00, schrieb Benedikt Hallinger:
Hello, Axel and i had the same bug, and we noticed that when explicitely select the wall source at the export lox command, the issue is solved ("export model -o out.lox -wall-source maps").
Personally i would assume this is a bug, because when i select datasets i would want the remaining data to be not present in my output. That is the purpose of selecting in the first place, isn’t it?
Am 19.01.2021 um 15:48 schrieb Tarquin Wilton-Jones via Therion <therion@speleo.sk>:
Hi Rhys,
I have noticed something that I am not sure if it's a bug or not. I am trying to export a selected bit of a survey as a loch file:
From my experience... Lox file export will always select all of the survey that were imported. It will generate walls using all splays. It will use all scraps to enhance the passage walls, even if you do not select them. If they exist in any surveys or subsurveys, they are used, no matter which survey or map is selected.
I always assumed this was intentional behaviour.
Personally, I have wanted to be able to select the specific maps that should be used for lox, since I may have more than one version of a survey in my data - traces over an old low quality survey, and a new high quality survey of the same cave. Lox export insists on trying to merge both versions rather than being able to select just one of them.
Cheers,
Tarquin _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Hi Bruce, there is no problem calculating map altitude. It was not calculated, because it was not needed for map generation. Added it in the latest commit. S. On Sat, 23 Jan 2021 at 19:20, Bruce Mutton <bruce@tomo.co.nz> wrote:
Hi Stacho I mostly get -8999 etc for my maps (not near my computer so cannot be specific on the circumstances) especially where maps are composed of surveys rather than scraps. I'm using Windows 10. I was a little perplexed that the map altitudes are undefined. Shouldn't the second level maps just be a weighted average of the component maps, scraps or surveys?
I will try the latest commit in a few days time. Bruce
Sent from my Galaxy
-------- Original message -------- From: Stacho Mudrak <lists@group-s.sk> Date: 23/01/21 23:35 (GMT+12:00) To: List for Therion users <therion@speleo.sk> Subject: Re: [Therion] Splays appearing when not selected
Hi Axel,
these big numbers are just NaNs in fact. It does not affect any output - it just means the map has no altitude associated with it. But thanks for finding out, I have tried to fix it in the latest commit, could you please try?
I am just curious, what OS are you using? Normally - it should write nan instead of such a big number. This big number is just a fallback if the compiler does not support NaN.
S.
On Fri, 22 Jan 2021 at 09:16, Axel <dropstone@gmx.de> wrote:
morning,
just had time to try the fix (5.5.6+5208297) and it solves the issue Benedikt mentioned in my projects as well, thx!
also had another look at my cavern error -- 1 issue (label with attr selected in layout/ wont compile unless -d option is choosen). looking at the map/scrap selection I get huge numbers for the map and wonder if that might cause the problem? I draw all my maps with Inkscape but checked the th2 files and found nothing strange+ it compiles without a problem with the normal label...
############### export maps & scraps selection ################# M -8999999999999999900000000000000000000000000000000000000000000000000000000000000000000000000000000000.00 IH_HauptPlan@IH () M -8999999999999999900000000000000000000000000000000000000000000000000000000000000000000000000000000000.00 02-plan-oben@02.IH () S 1643.48 02-plan1.3@02.IH () S 1634.82 02-plan1.2@02.IH () M -8999999999999999900000000000000000000000000000000000000000000000000000000000000000000000000000000000.00 02-plan-Sauelengang@02.IH () S 1674.29 02-plan2.10@02.IH () S 1673.77 02-plan2.9@02.IH ()
cheers, Axel
*Gesendet:* Mittwoch, 20. Januar 2021 um 09:10 Uhr *Von:* "Benedikt Hallinger" <beni@hallinger.org> *An:* "List for Therion users" <therion@speleo.sk> *Betreff:* Re: [Therion] Splays appearing when not selected I just recompiled and can confirm that my problem indeed was the same and is gone with therion 5.5.6+5208297 (2021-01-19)
Good work! Thank you!
Am 2021-01-19 22:00, schrieb Benedikt Hallinger:
Hello, Axel and i had the same bug, and we noticed that when explicitely select the wall source at the export lox command, the issue is solved ("export model -o out.lox -wall-source maps").
Personally i would assume this is a bug, because when i select datasets i would want the remaining data to be not present in my output. That is the purpose of selecting in the first place, isn’t it?
Am 19.01.2021 um 15:48 schrieb Tarquin Wilton-Jones via Therion <therion@speleo.sk>:
Hi Rhys,
I have noticed something that I am not sure if it's a bug or not. I am trying to export a selected bit of a survey as a loch file:
From my experience... Lox file export will always select all of the survey that were imported. It will generate walls using all splays. It will use all scraps to enhance the passage walls, even if you do not select them. If they exist in any surveys or subsurveys, they are used, no matter which survey or map is selected.
I always assumed this was intentional behaviour.
Personally, I have wanted to be able to select the specific maps that should be used for lox, since I may have more than one version of a survey in my data - traces over an old low quality survey, and a new high quality survey of the same cave. Lox export insists on trying to merge both versions rather than being able to select just one of them.
Cheers,
Tarquin _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
On 2021-01-23 11:34 +0100, Stacho Mudrak wrote:
Hi Axel, these big numbers are just NaNs in fact. It does not affect any output - it just means the map has no altitude associated with it. But thanks for finding out, I have tried to fix it in the latest commit, could you please try?
I've included this fix (and the other minor one you did) in the debian package (as 5.5.6ds1-5). It turns out that updates to non-core packages (which definately includes Therion :-) are actually allowed until 12th Feb, not 12th Jan so it should still make it the next stable release. It looks like this stable release of therion should be in quite good shape. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Wookey, when is this expected to appear in testing? I would test it
Am 24.01.2021 um 13:57 schrieb Wookey <wookey@wookware.org>:
On 2021-01-23 11:34 +0100, Stacho Mudrak wrote:
Hi Axel, these big numbers are just NaNs in fact. It does not affect any output - it just means the map has no altitude associated with it. But thanks for finding out, I have tried to fix it in the latest commit, could you please try?
I've included this fix (and the other minor one you did) in the debian package (as 5.5.6ds1-5). It turns out that updates to non-core packages (which definately includes Therion :-) are actually allowed until 12th Feb, not 12th Jan so it should still make it the next stable release.
It looks like this stable release of therion should be in quite good shape.
Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
On 2021-01-24 14:40 +0100, Benedikt Hallinger wrote:
Wookey, when is this expected to appear in testing?
Follow the status on the tracker page: https://tracker.debian.org/pkg/therion (only updates every few hours, so right now shows only the previous version) It should happen approx 48 hours from now if all goes well. The last architecture (mipsel) is just building now. https://buildd.debian.org/status/package.php?p=therion
I would test it
Thanks, that is very useful (to make sure I didn't screw anything up) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
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 -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
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@speleo.sk https://mailman.speleo.sk/listinfo/therion
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@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
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. [image: image.png] When I select just a part of the cave, coloring changes and the whole range is used for selected part. [image: image.png] 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@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@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
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@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@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
1. 2. 2021 v 20:10, Benedikt Hallinger <beni@hallinger.org>:
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).
I had the same artifact when I created two overlapped scraps of the same part of passage referenced by the same stations. Martin
Yes, the scraps are like this (s=station:) [good scrap: s1 s2 s3] joined [bad scrap: s3 ......only walls] Am 2021-02-01 20:19, schrieb Martin Sluka via Therion:
1. 2. 2021 v 20:10, Benedikt Hallinger <beni@hallinger.org>:
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).
I had the same artifact when I created two overlapped scraps of the same part of passage referenced by the same stations.
Martin _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
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@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@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@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
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@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@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@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion__________________________________...
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
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" the bug occurs. That command sources the entire cave. If i do source just the region with "source ../../../Hirlatzhoehle/Zubringer/therion/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@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@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@speleo.sk > https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion__________________________________...
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
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@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" the bug occurs. That command sources the entire cave.
If i do source just the region with "source ../../../Hirlatzhoehle/Zubringer/therion/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@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@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@speleo.sk >> https://mailman.speleo.sk/listinfo/therion > _______________________________________________ > Therion mailing list > Therion@speleo.sk > https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion__________________________________...
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
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 # wrong dimensions in lox #source ../../../Hirlatzhoehle/Zubringer/therion/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@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" the bug occurs. That command sources the entire cave.
If i do source just the region with "source ../../../Hirlatzhoehle/Zubringer/therion/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@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@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@speleo.sk >>> https://mailman.speleo.sk/listinfo/therion >> _______________________________________________ >> Therion mailing list >> Therion@speleo.sk >> https://mailman.speleo.sk/listinfo/therion > _______________________________________________ > Therion mailing list > Therion@speleo.sk > https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion__________________________________...
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
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
2. 2. 2021 v 9:48, Benedikt Hallinger <beni@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 # wrong dimensions in lox #source ../../../Hirlatzhoehle/Zubringer/therion/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@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" the bug occurs. That command sources the entire cave. If i do source just the region with "source ../../../Hirlatzhoehle/Zubringer/therion/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@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@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@speleo.sk >>>> https://mailman.speleo.sk/listinfo/therion >>> _______________________________________________ >>> Therion mailing list >>> Therion@speleo.sk >>> https://mailman.speleo.sk/listinfo/therion >> _______________________________________________ >> Therion mailing list >> Therion@speleo.sk >> https://mailman.speleo.sk/listinfo/therion > _______________________________________________ > Therion mailing list > Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion__________________________________... Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Hello, that is not the case here: the sole drawer was myself and there is no overlap (i know of - the data is self contained in that folder). The scraps are like this: map 1-Deckenschlot-vor-KPZ 1.1-2-26a-SP1-Aufstieg # <- has stations, is OK 1.1-2-26a-SP1 # <- has stations, is OK 1.1-2-26a-SP2 # <- last known station at start. OK until the middle of the scrap! 1.1-2-26a-SP3 # <- no station; joined to 1.1-2-26a-SP2, completely "endless chimney" endmap What puzzles me is that the chimney starts at a bend in my scrap. The altitude range is that of the entire cave, and thus the "endless-chimney" is very prominent; I think this is a second issue we should tackle also (it will somewhat help with the issue here, but not solve it). Am 2021-02-02 10:01, schrieb Martin Sluka via Therion:
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
2. 2. 2021 v 9:48, Benedikt Hallinger <beni@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@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@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@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@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion__________________________________...
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://hirlatzhoehle.th [2] http://zubringer.th _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Hm, just isolated the 1-survey. If i just select that survey, which contains the scrap in question, I cannot reproduce this. Strange. That leads me to the conclusion, that something else in the entire dataset triggers this behaviour. Am 2021-02-02 10:48, schrieb Benedikt Hallinger:
Hello, that is not the case here: the sole drawer was myself and there is no overlap (i know of - the data is self contained in that folder).
The scraps are like this: map 1-Deckenschlot-vor-KPZ 1.1-2-26a-SP1-Aufstieg # <- has stations, is OK 1.1-2-26a-SP1 # <- has stations, is OK 1.1-2-26a-SP2 # <- last known station at start. OK until the middle of the scrap! 1.1-2-26a-SP3 # <- no station; joined to 1.1-2-26a-SP2, completely "endless chimney" endmap
What puzzles me is that the chimney starts at a bend in my scrap. The altitude range is that of the entire cave, and thus the "endless-chimney" is very prominent; I think this is a second issue we should tackle also (it will somewhat help with the issue here, but not solve it).
Am 2021-02-02 10:01, schrieb Martin Sluka via Therion:
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
2. 2. 2021 v 9:48, Benedikt Hallinger <beni@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@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@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@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@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion__________________________________...
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://hirlatzhoehle.th [2] http://zubringer.th _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
5.5.7 solved the problem also for me (see attachments). Good work! Well Done! Thanks guys. Michael.
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@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@hallinger.org <mailto:beni@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@hallinger.org <mailto:beni@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@hallinger.org <mailto:beni@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@hallinger.org <mailto:beni@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
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@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@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@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@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@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@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@speleo.sk https://mailman.speleo.sk/listinfo/therion
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@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 <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@univ-grenoble-alpes.fr <mailto:xavier.robert@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@speleo.sk <mailto:therion@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@hallinger.org <mailto:beni@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@hallinger.org <mailto:beni@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@hallinger.org <mailto:beni@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@hallinger.org <mailto:beni@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
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@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@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@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@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@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@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@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@speleo.sk https://mailman.speleo.sk/listinfo/therion
Thanks for the feedback. I have just uploaded it to the official repo so also Win32 installation file should be available shortly. And we would like to make another release with this fix on Saturday. It impacts all 3d models generated from 2d map, so if also others could test their data and report potential problems, it would be great. Until now, all tested models look at least a little bit better. S. On Wed, 3 Feb 2021 at 12:01, Benedikt Hallinger <beni@hallinger.org> wrote:
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@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@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@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@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@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@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@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@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
On 2021-01-27 08:59 +0100, Benedikt Hallinger wrote:
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 ?
No 5.5.6ds1-5 is the latest, including the fix discussed inthis thread. There isn't a -6 (yet) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Hi, survey selection was really ignored when splay shots 3D models were exported. I hope, it is fixed in 5208297 <https://github.com/therion/therion/commit/52082975dddbe2601f84b82d334eb0c4cf944e05>. Thanks again for finding out Rhys, that it was just a splay shots issue! Tarquin, did you know, there is a "-walls off" option for scrap? It was designed specifically for this purpose. To turn off wall generation from unwanted scraps - low-quality surveys in your case. Or is there some problem with using it? OK, you have to specify it for every scrap, maybe it should be also supported for maps. Would it solve your problem? The original idea was to generate walls from all available information (centreline lrud, splays, and scraps) in the given survey. It is not yet fully implemented but still remains a goal. Therefore selection by surveys and not by maps. Selection of scraps in selected surveys for 3D export works I assume. S. On Tue, 19 Jan 2021 at 15:48, Tarquin Wilton-Jones via Therion < therion@speleo.sk> wrote:
Hi Rhys,
I have noticed something that I am not sure if it's a bug or not. I am trying to export a selected bit of a survey as a loch file:
From my experience... Lox file export will always select all of the survey that were imported. It will generate walls using all splays. It will use all scraps to enhance the passage walls, even if you do not select them. If they exist in any surveys or subsurveys, they are used, no matter which survey or map is selected.
I always assumed this was intentional behaviour.
Personally, I have wanted to be able to select the specific maps that should be used for lox, since I may have more than one version of a survey in my data - traces over an old low quality survey, and a new high quality survey of the same cave. Lox export insists on trying to merge both versions rather than being able to select just one of them.
Cheers,
Tarquin _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Tarquin, did you know, there is a "-walls off" option for scrap?
Very neat :) I will certainly use that. It does limit you though, to only being able to hardcode it into the scrap. You could not prepare two different versions of the .lox by selecting the relevant maps (plan and extended elevations at the same time). You could prepare the two versions, but only by manually editing the scraps in between. For me, the existing solution is fine, but does seem oddly limited.
participants (10)
-
Axel -
Benedikt Hallinger -
Bruce Mutton -
Martin Sluka -
Michael Ross -
Rhys Tyers -
Stacho Mudrak -
Tarquin Wilton-Jones -
Wookey -
Xavier Robert