Re: [Therion] Survex (loop closure) related fixes
> I think that the problem is caused by this line: > > rv.prjname = thcs_get_label(params).c_str(); > > because rv.prjname now contains a pointer to a temporary (and already > destroyed) string. Bravo on the speedy bug hunting! > With every run the string changes Heart sank as soon as I read that. Never as easy to narrow those down. Have to set up enough state beforehand to get the nonsense, so cutting the lines out of the file often makes the bug go away. I assume one of your cartographers was listed with an unexpected name on the PDF when it "worked". Or perhaps some other little string. Bisect is definitely the easiest way to do it. At least enough to give the dev an idea of what code to analyse. ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Survex (loop closure) related fixes
Hi, I think that the problem is caused by this line: rv.prjname = thcs_get_label(params).c_str(); because rv.prjname now contains a pointer to a temporary (and already destroyed) string. st 14. 10. 2020 v 23:04 odesílatel Benedikt Hallinger napsal: > > I just made a new issue ticket: > https://github.com/therion/therion/issues/278 > > > Am 2020-10-14 22:53, schrieb Benedikt Hallinger: > > Hi there, > > i performed a git bisect (the very first in my lifetime, and that is > > really a nice and easy tool to search such things!!!). > > > > The commits at and before c7d41d9 compiled the cave sucessfully 10 of > > 10 times. > > > > 1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8 is the first bad commit > > commit 1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8 > > Author: mbudaj > > Date: Wed Aug 19 07:25:53 2020 +0200 > > > > dynamically load EPSG/ESRI labels in Proj>=6 > > > > https://github.com/therion/therion/commit/1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8 > > > > This compiles unstable like described before. > > > > > > > > Am 2020-10-14 22:32, schrieb Wookey: > >> On 2020-10-14 22:05 +0200, Benedikt Hallinger wrote: > >>> OK, now i got something. > >>> > >>> Guess what - one of about 5 compiles runs trough. > >>> This leads me to think that there is a race condition or something > >>> else > >>> somewhere, overwriting memory of the to-be-checked string. > >>> I'm pretty sure now that this is not a problem with the dataset per > >>> se, but > >>> some memory issue of the compiled therion program. > >>> > >>> The following pattern resulted in several runs with 5.5.2 (n=failed, > >>> y=ok): > >>> nnnynnynnynynynynnny > >> > >> Oh dear. This could be fun to track down > >> > >> Better check 5.5.1 always works, not just more often. But if it does > >> then careful examination of what changed is in order. Maybe send some > >> others the dataset to see who can reproduce (windows/linux/macOS)? > >> > >> 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
Re: [Therion] Survex (loop closure) related fixes
I just made a new issue ticket: https://github.com/therion/therion/issues/278 Am 2020-10-14 22:53, schrieb Benedikt Hallinger: Hi there, i performed a git bisect (the very first in my lifetime, and that is really a nice and easy tool to search such things!!!). The commits at and before c7d41d9 compiled the cave sucessfully 10 of 10 times. 1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8 is the first bad commit commit 1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8 Author: mbudaj Date: Wed Aug 19 07:25:53 2020 +0200 dynamically load EPSG/ESRI labels in Proj>=6 https://github.com/therion/therion/commit/1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8 This compiles unstable like described before. Am 2020-10-14 22:32, schrieb Wookey: On 2020-10-14 22:05 +0200, Benedikt Hallinger wrote: OK, now i got something. Guess what - one of about 5 compiles runs trough. This leads me to think that there is a race condition or something else somewhere, overwriting memory of the to-be-checked string. I'm pretty sure now that this is not a problem with the dataset per se, but some memory issue of the compiled therion program. The following pattern resulted in several runs with 5.5.2 (n=failed, y=ok): nnnynnynnynynynynnny Oh dear. This could be fun to track down Better check 5.5.1 always works, not just more often. But if it does then careful examination of what changed is in order. Maybe send some others the dataset to see who can reproduce (windows/linux/macOS)? 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
Re: [Therion] Survex (loop closure) related fixes
Hi there, i performed a git bisect (the very first in my lifetime, and that is really a nice and easy tool to search such things!!!). The commits at and before c7d41d9 compiled the cave sucessfully 10 of 10 times. 1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8 is the first bad commit commit 1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8 Author: mbudaj Date: Wed Aug 19 07:25:53 2020 +0200 dynamically load EPSG/ESRI labels in Proj>=6 https://github.com/therion/therion/commit/1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8 This compiles unstable like described before. Am 2020-10-14 22:32, schrieb Wookey: On 2020-10-14 22:05 +0200, Benedikt Hallinger wrote: OK, now i got something. Guess what - one of about 5 compiles runs trough. This leads me to think that there is a race condition or something else somewhere, overwriting memory of the to-be-checked string. I'm pretty sure now that this is not a problem with the dataset per se, but some memory issue of the compiled therion program. The following pattern resulted in several runs with 5.5.2 (n=failed, y=ok): nnnynnynnynynynynnny Oh dear. This could be fun to track down Better check 5.5.1 always works, not just more often. But if it does then careful examination of what changed is in order. Maybe send some others the dataset to see who can reproduce (windows/linux/macOS)? 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
Re: [Therion] Survex (loop closure) related fixes
On 2020-10-14 22:05 +0200, Benedikt Hallinger wrote: > OK, now i got something. > > Guess what - one of about 5 compiles runs trough. > This leads me to think that there is a race condition or something else > somewhere, overwriting memory of the to-be-checked string. > I'm pretty sure now that this is not a problem with the dataset per se, but > some memory issue of the compiled therion program. > > The following pattern resulted in several runs with 5.5.2 (n=failed, y=ok): > nnnynnynnynynynynnny Oh dear. This could be fun to track down Better check 5.5.1 always works, not just more often. But if it does then careful examination of what changed is in order. Maybe send some others the dataset to see who can reproduce (windows/linux/macOS)? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Survex (loop closure) related fixes
OK, now i got something. Guess what - one of about 5 compiles runs trough. This leads me to think that there is a race condition or something else somewhere, overwriting memory of the to-be-checked string. I'm pretty sure now that this is not a problem with the dataset per se, but some memory issue of the compiled therion program. The following pattern resulted in several runs with 5.5.2 (n=failed, y=ok): nnnynnynnynynynynnny Am 2020-10-14 21:53, schrieb Martin Sluka via Therion: I use BBEdit on MacOSX and it has all features you mentioned. Martin 14. 10. 2020 v 21:17, Tarquin Wilton-Jones via Therion : On 14/10/2020 20:08, Martin Sluka via Therion wrote: What about multifile search for”P]” in text files? It is quite strange combination of characters and they are part of ASCII set. If you have an editor that is working in the same character set as Therion, that could work. Definitely worth a try. I suspect the fault relates to character set conversion though. Such as an editor working in 8859-1, and Therion trying to interpret it in UTF-8. Most basic text editors don't let you control character set, and just work in the system default (Windows-1252 on English-based Windows systems). Even if they do, most users are not aware of what it all means, and just stick with the default. ___ 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
Re: [Therion] Survex (loop closure) related fixes
I use BBEdit on MacOSX and it has all features you mentioned. Martin > 14. 10. 2020 v 21:17, Tarquin Wilton-Jones via Therion : > > On 14/10/2020 20:08, Martin Sluka via Therion wrote: >> What about multifile search for”P]” in text files? It is quite strange >> combination of characters and they are part of ASCII set. > > If you have an editor that is working in the same character set as > Therion, that could work. Definitely worth a try. > > I suspect the fault relates to character set conversion though. Such as > an editor working in 8859-1, and Therion trying to interpret it in > UTF-8. Most basic text editors don't let you control character set, and > just work in the system default (Windows-1252 on English-based Windows > systems). Even if they do, most users are not aware of what it all > means, and just stick with the default. > ___ > Therion mailing list > Therion@speleo.sk > https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Survex (loop closure) related fixes
I sent Martin a dataset to investigate. Hopefully he can spot something... Am 2020-10-14 21:40, schrieb Benedikt Hallinger: Hello all, thanks for all the hints. What about multifile search for”P]” in text files? It is quite strange combination of characters and they are part of ASCII set. I had that in mind, but i don't think its the problem here. If it would, 5.5.1 should fail too... What about multifile search for”P]” With every run the string changes. I have seen that before with C++ code, that was when i tried to put out a memory adress instead of the actual string. Maybe the passed string is already memory garbage at this point? QA folks start grinning. Generic instructions below: Uh, then i will have a grey beard finishing this. We talk about 130km of cave in way over 600 files here. I also commented the the error line in the source code that bails out here, and everything (therion, but also the map) compiles just fine as it should. Also the cartographers names print nicely. Nonewithstanding i had a idea i went trough. A part of the cave is done using an inkscape plugin, which converts the svg data into th2 files. That usually goes good, and did to therion 5.5.1. I also was able to isolate a scrap line causing the problem (excerpt attached). However, if i craft a very simple thconfig, it compiles fine; and the isolated line looks not suspicious at all for me! The problem occurs only if i try to render the whole cave (in a very big scale 1:5000); if i craft a very simple thconfig and source only the passage th file, it goes OK. Could it be that somewhere some string buffer runs over when gathering all the cartographers? or that something else messes stuff up memory-wise, because the dataset is so big already? I'm out of ideas. Am 2020-10-14 20:34, schrieb Benedikt Hallinger: Hey Martin, thanks for responding. The exact same dataset compiles well with 5.5.1. As far as i know, no special characters are used here. As its rather huge, and i have no idea how to reduce the problem. It surely must be somewhere in the .th2 files "author", since that is probably the only place where this gets gathered from, isn't it? I enhanced the thtexfonts.cxx on line 247 to print out the offending string (if you want i make a PR for that) that now shows something looking like garbage: ./therion: error -- Invalid utf-8 string! (offending string: 'P]���U') I probably need to wade trough the data manually. Am 2020-10-14 20:04, schrieb Martin Budaj: On Wed, Oct 14, 2020 at 10:38 AM Benedikt Hallinger wrote: When trying to compile a specific plan map view PDF i get an error about UTF8. The compile runs fine with release-therion 5.5.1, however! (i don't know if this is related) Hi, there was no change in the processing of utf-8 strings between 5.5.1 and 5.5.2. Could you check the same data set is used by those versions? You should get this error if you use a unicode character outside of the BMP (see https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane). Do you such exotic characters? Sending a minimal data sample would be helpful. M. ___ 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
Re: [Therion] Survex (loop closure) related fixes
Hello all, thanks for all the hints. What about multifile search for”P]” in text files? It is quite strange combination of characters and they are part of ASCII set. I had that in mind, but i don't think its the problem here. If it would, 5.5.1 should fail too... What about multifile search for”P]” With every run the string changes. I have seen that before with C++ code, that was when i tried to put out a memory adress instead of the actual string. Maybe the passed string is already memory garbage at this point? QA folks start grinning. Generic instructions below: Uh, then i will have a grey beard finishing this. We talk about 130km of cave in way over 600 files here. I also commented the the error line in the source code that bails out here, and everything (therion, but also the map) compiles just fine as it should. Also the cartographers names print nicely. Nonewithstanding i had a idea i went trough. A part of the cave is done using an inkscape plugin, which converts the svg data into th2 files. That usually goes good, and did to therion 5.5.1. I also was able to isolate a scrap line causing the problem (excerpt attached). However, if i craft a very simple thconfig, it compiles fine; and the isolated line looks not suspicious at all for me! The problem occurs only if i try to render the whole cave (in a very big scale 1:5000); if i craft a very simple thconfig and source only the passage th file, it goes OK. Could it be that somewhere some string buffer runs over when gathering all the cartographers? or that something else messes stuff up memory-wise, because the dataset is so big already? I'm out of ideas. Am 2020-10-14 20:34, schrieb Benedikt Hallinger: Hey Martin, thanks for responding. The exact same dataset compiles well with 5.5.1. As far as i know, no special characters are used here. As its rather huge, and i have no idea how to reduce the problem. It surely must be somewhere in the .th2 files "author", since that is probably the only place where this gets gathered from, isn't it? I enhanced the thtexfonts.cxx on line 247 to print out the offending string (if you want i make a PR for that) that now shows something looking like garbage: ./therion: error -- Invalid utf-8 string! (offending string: 'P]���U') I probably need to wade trough the data manually. Am 2020-10-14 20:04, schrieb Martin Budaj: On Wed, Oct 14, 2020 at 10:38 AM Benedikt Hallinger wrote: When trying to compile a specific plan map view PDF i get an error about UTF8. The compile runs fine with release-therion 5.5.1, however! (i don't know if this is related) Hi, there was no change in the processing of utf-8 strings between 5.5.1 and 5.5.2. Could you check the same data set is used by those versions? You should get this error if you use a unicode character outside of the BMP (see https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane). Do you such exotic characters? Sending a minimal data sample would be helpful. M. ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therionencoding utf-8 ##XTHERION## xth_me_area_adjust 0 0 1432.044359 1455.405165 ##XTHERION## xth_me_area_zoom_to 100 # THIS HAS OFFENDING CHARACTERS: scrap 237-plan1.3 -scale [0 0 90 0 0 0 500 0 inch] -projection plan -author 2020.03.22 "Foo Bar" # THIS DOES WORK: #scrap 237-plan1.3 -scale [0 0 90 0 0 0 500 0 inch] -projection plan line wall -subtype debris 698.1766 498.9593 698.9107 510.1675 698.4598 521.3301 693.7274 532.328 endline point 1350.6446 56.0884 u:mappe -attr text 253 point 1017.9026 158.2627 passage-height -value 16 point 1264.195 71.1864 passage-height -value 12 point 905.4025 90.8898 passage-height -value 4 point 674.3731 473.9263 passage-height -value 1.1 point 956.171 212.2135 continuation -text [Schlot] point 1058.3538 248.9031 continuation -text [Schlot] point 742.8787 178.1511 altitude -align r point 1231.4015 34.8879 altitude -align l point 1103.6943 242.364 altitude -align r point 710.4934 492.3343 altitude -align r point 1353.6321 105.8449 station-name -scale xs point 1237.7953 57.0631 station-name -scale xs point 998.0274 167.6244 station-name -scale xs point 676.8842 539.3195 station-name -scale xs point 700.5987 294.6161 station-name -scale xs point 729.1645 393.9866 label -text [Klamm] -align r -scale s line border 1349.3419 95.0398 1350.8979 92.9743 1351.8803 90.4498 1351.3281 86.6977 endline point 1158.2586 159.375 debris -orientation 336.025125 point 967.0364 196.1817 height -value "+" point 1065.6624 231.3641 height -value "+" point 776.7726 142.1957 gradient -scale xs -orientation 258.18624432 line border -close on -id 237-plan1.3_debris_1 -visibility off 684.8291 528.1967 675.2952 519.2984 684.1935 482.4339 688.3249 424.5949 697.2232
Re: [Therion] Survex (loop closure) related fixes
On 14/10/2020 20:08, Martin Sluka via Therion wrote: > What about multifile search for”P]” in text files? It is quite strange > combination of characters and they are part of ASCII set. If you have an editor that is working in the same character set as Therion, that could work. Definitely worth a try. I suspect the fault relates to character set conversion though. Such as an editor working in 8859-1, and Therion trying to interpret it in UTF-8. Most basic text editors don't let you control character set, and just work in the system default (Windows-1252 on English-based Windows systems). Even if they do, most users are not aware of what it all means, and just stick with the default. ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Survex (loop closure) related fixes
What about multifile search for”P]” in text files? It is quite strange combination of characters and they are part of ASCII set. Martin Odesláno z iPhonu 14. 10. 2020 v 20:55, Tarquin Wilton-Jones via Therion : >> I probably need to wade trough the data manually. > > QA folks start grinning. Generic instructions below: > > Take a copy of your dataset. Reproduce the problem. > Comment out any joins. Recompile. > Delete half the "input" statements, and their "equate". Recompile. > Repeat until the problem disappears. If you get all of it gone and the > problem is still happening, great. > Repeat on any remaining sub-surveys, until the only files left are the > ones needed to show the bug. > Remove any contents of the file (maps etc.) bit by bit, until the > problem disappears. > > Or send it to me, and I will do it. > ___ > Therion mailing list > Therion@speleo.sk > https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Survex (loop closure) related fixes
> I probably need to wade trough the data manually. QA folks start grinning. Generic instructions below: Take a copy of your dataset. Reproduce the problem. Comment out any joins. Recompile. Delete half the "input" statements, and their "equate". Recompile. Repeat until the problem disappears. If you get all of it gone and the problem is still happening, great. Repeat on any remaining sub-surveys, until the only files left are the ones needed to show the bug. Remove any contents of the file (maps etc.) bit by bit, until the problem disappears. Or send it to me, and I will do it. ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Survex (loop closure) related fixes
Hey Martin, thanks for responding. The exact same dataset compiles well with 5.5.1. As far as i know, no special characters are used here. As its rather huge, and i have no idea how to reduce the problem. It surely must be somewhere in the .th2 files "author", since that is probably the only place where this gets gathered from, isn't it? I enhanced the thtexfonts.cxx on line 247 to print out the offending string (if you want i make a PR for that) that now shows something looking like garbage: ./therion: error -- Invalid utf-8 string! (offending string: 'P]���U') I probably need to wade trough the data manually. Am 2020-10-14 20:04, schrieb Martin Budaj: On Wed, Oct 14, 2020 at 10:38 AM Benedikt Hallinger wrote: When trying to compile a specific plan map view PDF i get an error about UTF8. The compile runs fine with release-therion 5.5.1, however! (i don't know if this is related) Hi, there was no change in the processing of utf-8 strings between 5.5.1 and 5.5.2. Could you check the same data set is used by those versions? You should get this error if you use a unicode character outside of the BMP (see https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane). Do you such exotic characters? Sending a minimal data sample would be helpful. M. ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Survex (loop closure) related fixes
On Wed, Oct 14, 2020 at 10:38 AM Benedikt Hallinger wrote: > When trying to compile a specific plan map view PDF i get an error about > UTF8. The compile runs fine with release-therion 5.5.1, however! > (i don't know if this is related) > Hi, there was no change in the processing of utf-8 strings between 5.5.1 and 5.5.2. Could you check the same data set is used by those versions? You should get this error if you use a unicode character outside of the BMP (see https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane). Do you such exotic characters? Sending a minimal data sample would be helpful. M. ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Survex (loop closure) related fixes
I experimented a little bit more. In the thconfig file I set some header data. statistics explo off statistics topo off statistics carto off statistics copyright all If i comment out the line #statistics carto off the compilation works again (then showing the people of course). The same is true with "statistics carto all". Why does turning off the carto yield invalid UTF8 data? Am 2020-10-14 10:38, schrieb Benedikt Hallinger: I tried to compile the model of the Hirlatz cave with it and it looks good, from a big picture view. The passages shifted sometimes slightly, as expected. When trying to compile a specific plan map view PDF i get an error about UTF8. The compile runs fine with release-therion 5.5.1, however! (i don't know if this is related) therion 5.5.2+4683494 (2020-10-13) cavern - Survex 1.2.42 initialization file: therion.ini reading ... done This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian) (preloaded format=pdftex) restricted \write18 enabled. entering extended mode (./fonttest.tex checking optional fonts csr10 csti10 csbx10 csss10 csssi10 ... NOT INSTALLED This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian) (preloaded format=pdftex) restricted \write18 enabled. entering extended mode (./fonttest.tex checking optional fonts cmcyr10 cmcti10 cmcbx10 cmcss10 cmcssi10 ... NOT INSTALLED configuration file: ../../Dokumente/cave/HVHO/svn/Hirlatzhoehle/therion/plan.DOP.map.thconfig reading ... done reading source files ... done preprocessing database ... done ./therion: warning -- year 1951 magnetic declination used for undated surveys undated surveys: 155.Wilder_Westen.Hirlatzhoehle 323.Westen.Hirlatzhoehle 326.Hochdonnerbach.Hirlatzhoehle scanning centreline tree ... done searching for centerline loops ... done calculating station coordinates ... done average loop error: 1.98% processing survey data ... done calculating basic statistics ... done processing extended elevation ... done processing references ... done selecting export objects ... done processing projection plan ... done average distortion: 3.21% writing ../../Dokumente/cave/HVHO/svn/Hirlatzhoehle/therion/../Hirlatz.plan.DOP.map.pdf ... ./therion: error -- Invalid utf-8 string! Am 2020-10-14 10:02, schrieb Tarquin Wilton-Jones via Therion: Hi folks, Stacho fixed these "when using Survex loop closure" bugs in yesterday's development release: https://github.com/therion/therion/issues/269 Therion miscalculates fixes in multiple centreline blocks when using Survex loop closure https://github.com/therion/therion/issues/270 Therion cannot have exactly 2 fixes for a station when using Survex loop closure And this Survex compatibility bug: https://github.com/therion/therion/issues/263 Scale value should default to 1 when omitted from "calibrate" commands I have checked and verified the fixes, and my surveys still look right. But could someone with a bigger dataset check that it didn't break anything else when using Survex loop closures. That particular fix looks like the kind that could create regressions. It only improved things for me though :) Yes, your cave entrance locations will change if you ever ran into #269 without realising - they are supposed to. And yes, you might find some parts of the cave change size if you ever hit the calibrate statement bug. 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
Re: [Therion] Survex (loop closure) related fixes
I tried to compile the model of the Hirlatz cave with it and it looks good, from a big picture view. The passages shifted sometimes slightly, as expected. When trying to compile a specific plan map view PDF i get an error about UTF8. The compile runs fine with release-therion 5.5.1, however! (i don't know if this is related) therion 5.5.2+4683494 (2020-10-13) cavern - Survex 1.2.42 initialization file: therion.ini reading ... done This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian) (preloaded format=pdftex) restricted \write18 enabled. entering extended mode (./fonttest.tex checking optional fonts csr10 csti10 csbx10 csss10 csssi10 ... NOT INSTALLED This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian) (preloaded format=pdftex) restricted \write18 enabled. entering extended mode (./fonttest.tex checking optional fonts cmcyr10 cmcti10 cmcbx10 cmcss10 cmcssi10 ... NOT INSTALLED configuration file: ../../Dokumente/cave/HVHO/svn/Hirlatzhoehle/therion/plan.DOP.map.thconfig reading ... done reading source files ... done preprocessing database ... done ./therion: warning -- year 1951 magnetic declination used for undated surveys undated surveys: 155.Wilder_Westen.Hirlatzhoehle 323.Westen.Hirlatzhoehle 326.Hochdonnerbach.Hirlatzhoehle scanning centreline tree ... done searching for centerline loops ... done calculating station coordinates ... done average loop error: 1.98% processing survey data ... done calculating basic statistics ... done processing extended elevation ... done processing references ... done selecting export objects ... done processing projection plan ... done average distortion: 3.21% writing ../../Dokumente/cave/HVHO/svn/Hirlatzhoehle/therion/../Hirlatz.plan.DOP.map.pdf ... ./therion: error -- Invalid utf-8 string! Am 2020-10-14 10:02, schrieb Tarquin Wilton-Jones via Therion: Hi folks, Stacho fixed these "when using Survex loop closure" bugs in yesterday's development release: https://github.com/therion/therion/issues/269 Therion miscalculates fixes in multiple centreline blocks when using Survex loop closure https://github.com/therion/therion/issues/270 Therion cannot have exactly 2 fixes for a station when using Survex loop closure And this Survex compatibility bug: https://github.com/therion/therion/issues/263 Scale value should default to 1 when omitted from "calibrate" commands I have checked and verified the fixes, and my surveys still look right. But could someone with a bigger dataset check that it didn't break anything else when using Survex loop closures. That particular fix looks like the kind that could create regressions. It only improved things for me though :) Yes, your cave entrance locations will change if you ever ran into #269 without realising - they are supposed to. And yes, you might find some parts of the cave change size if you ever hit the calibrate statement bug. 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
