From rsev at pm.me Wed Dec 1 11:00:59 2021 From: rsev at pm.me (Rodrigo Severo) Date: Wed, 01 Dec 2021 10:00:59 +0000 Subject: [Therion] Presenting Mapiah, a multi-platform, more friendly, modern and performant graphical interface for Therion In-Reply-To: References: Message-ID: Em ter?a-feira, 30 de novembro de 2021 ?s 4:44 PM, Martin Budaj escreveu: > Hi, Rodrigo. > > Your PoC app looks very promising and we are happy that you've made > > this first step. C++/Qt seems to be a good choice as well. > > What might be a bit surprising for most of the users hoping for a > > better UI, there is also one other project to create a Qt replacement > > for XTherion (started by Michal Plch and available in the qtherion > > branch of our git repo ;) Uau!! I didn't know about it at all. > There are some differences in the scope and technology, though: > > - the idea was to provide a UI which would be simple enough for new > > users, not necessarily mimicking XTherion's approach > - as a result, it doesn't expect user to know internals of *.th or > > *.th2 files (and even doesn't support them directly ? in this branch > > therion was extended to use a JSON-based data package to communicate > > with qtherion UI) > - it's based on C++/Qt, too, but heavily using QML to define the UI > > It's also a PoC in a very early stage and as such hasn't been > > advertised on the list yet. But it's clear that time is ripe for a new > > UI. > > How about some brainstorming with Rodrigo, Michal and perhaps some > > others on possible synergies and the best way forward? Great ideia. It will be way better to join forces for sure. Maybe we schedule a live meeting to talk about both approaches together and decide which way to go? Regards, Rodrigo Severo From m.budaj at gmail.com Sun Dec 5 13:38:17 2021 From: m.budaj at gmail.com (Martin Budaj) Date: Sun, 5 Dec 2021 13:38:17 +0100 Subject: [Therion] Presenting Mapiah, a multi-platform, more friendly, modern and performant graphical interface for Therion In-Reply-To: References: Message-ID: On Wed, Dec 1, 2021 at 11:01 AM Rodrigo Severo via Therion wrote: > Maybe we schedule a live meeting to talk about both approaches together and decide which way to go? So here is a poll to find the best meeting time: https://doodle.com/poll/dhhz9mhk7vaizmis?utm_source=poll&utm_medium=link Martin From therion at speleo.sk Sun Dec 5 21:00:02 2021 From: therion at speleo.sk (Therion) Date: Sun, 5 Dec 2021 21:00:02 +0100 (CET) Subject: [Therion] new Therion 6.0.3 Message-ID: <20211205200002.C704160E11@mail.speleo.sk> Hi, there is a new release 6.0.3 of Therion. Check https://github.com/therion/therion/releases/tag/v6.0.3 for more details. Best regards, Therion team From therion at speleo.sk Sun Dec 5 21:10:02 2021 From: therion at speleo.sk (Therion) Date: Sun, 5 Dec 2021 21:10:02 +0100 (CET) Subject: [Therion] new Therion 6.0.4 Message-ID: <20211205201003.00E225FDFE@mail.speleo.sk> Hi, there is a new release 6.0.4 of Therion. Check https://github.com/therion/therion/releases/tag/v6.0.4 for more details. Best regards, Therion team From m.budaj at gmail.com Tue Dec 7 18:47:06 2021 From: m.budaj at gmail.com (Martin Budaj) Date: Tue, 7 Dec 2021 18:47:06 +0100 Subject: [Therion] Presenting Mapiah, a multi-platform, more friendly, modern and performant graphical interface for Therion In-Reply-To: References: Message-ID: On Sun, Dec 5, 2021 at 1:38 PM Martin Budaj wrote: > > On Wed, Dec 1, 2021 at 11:01 AM Rodrigo Severo via Therion > wrote: > > Maybe we schedule a live meeting to talk about both approaches together and decide which way to go? > > So here is a poll to find the best meeting time: > > https://doodle.com/poll/dhhz9mhk7vaizmis?utm_source=poll&utm_medium=link Tuesday December 14 at 8 PM CET (= 7 PM GMT) is good for all. We'll send the meeting link via email. Looking forward to meeting you all Martin From beni at hallinger.org Thu Dec 9 10:37:19 2021 From: beni at hallinger.org (Benedikt Hallinger) Date: Thu, 09 Dec 2021 10:37:19 +0100 Subject: [Therion] Map offset: just specify offset in complex dataset (proposes new "offset" thconfig compiler command) Message-ID: Hello, I currently experiment with creating a nice overview map of a fairly complex part of the Hirlatz cave. The dataset spans about 8km in passage lengths in variuous levels with lots of over-/underlaying passages. The data is organised in surveys, where each survey defines at least a "Hauptmap" wich usually includes all the submaps the main map is composed of. The main intend of the "Hauptmap" is to nicely render the survey alone. Now I want to create an overview map and using the select statement I can easily instruct therion to suck in and render all the maps of the entire region. Offsets are stripped this way, but therion does a very nice job in sorting te maps according to the altitude, which eases my brain very much, since i don't need to wrap my head around sorting 54 maps by hand. Therion does a splendid job with this already. However this produces one problem for me: I cannot render map offsets easily anymore. So what I had to do is to select the entire region using "select Wandaugenlabyrinth.Hirlatzhoehle" and render that. This will print the processes maps into the therion.log file. From there I have picket it up to create a new "map" structure (`grep ^M therion.og |sort -r | awk '{print $3}'`). This i added to the thconfig file and selected that instead. There it is now easy to define offets again. BUT: This introduces another, long term problem: When sometimes in the future someone adds a new survey to this region, he needs to remember to merge its maps also into the overview map definition (at the correct position because of altitude!). Thus, it would be cool if we had some kind of "offset" thconfig command alongside the select one. This would allow me to read in the entire regions maps, and just specify offsets for the offset ones; something like this: ----- thconfig ----- source ../../therion/Hirlatzhoehle.th select Wandaugenlabyrinth.Hirlatzhoehle # read in all defined maps of the Region offset 173-Anschluss-177 at 173.Wandaugenlabyrinth.Hirlatzhoehle [20 15 m] below offset 177-Hauptplan at 177.Wandaugenlabyrinth.Hirlatzhoehle [-30 -20 m] above -------------------- Expected result would be all the maps read and printed at their altitude level, but the two maps offset as already known from the "map" command. If someone adds, lets say, 200-Hauptplan at 200.Wandaugenlabyrinth.Hirlatzhoehle and recompiles the file, the new survey would be included *without specifying it explicitely*. Is such a command possible? I know it's not such a big deal with smaller caves, but in my dataset this would save a tremendous ammount of time down the road when I will make the atlas of Hirlatz regions (not to mention a big overview map). ps. and probably relatet: When I give "select Wandaugenlabyrinth.Hirlatzhoehle" and then "unselect 177-Hauptplan at 177.Wandaugenlabyrinth.Hirlatzhoehle", 177 survey is still printed to the map. I would had expected that the scraps of the map would be hidden from output. Kind regards, Beni From wookey at wookware.org Tue Dec 14 06:17:37 2021 From: wookey at wookware.org (Wookey) Date: Tue, 14 Dec 2021 05:17:37 +0000 Subject: [Therion] Presenting Mapiah, a multi-platform, more friendly, modern and performant graphical interface for Therion In-Reply-To: References: Message-ID: <20211214051737.GZ29287@mail.wookware.org> On 2021-11-14 23:42 +0000, Rodrigo Severo via Therion wrote: > Presenting Mapiah. > > Mapiah is my take on a multi-platform, more friendly, modern and performant graphical interface for Therion. It's written in C++/Qt. It aims to be as compatible as practical and possible with XTherion. > > This is the "proof-of-concept" release. > > It's source code and it's releases files can be found at the projects home at SourceForge: https://sourceforge.net/projects/mapiah/ OK. As I didn't know what to do with an appimage (and don't like installing binaries anyway) I tried building a deb. Things went quite well but I hit this: make[3]: *** [CMakeFiles/Mapiah.dir/build.make:359: CMakeFiles/Mapiah.dir/data/th2xtherionsetting.cpp.o] Error 1 make[3]: *** Waiting for unfinished jobs.... /home/wookey/packages/therion/mapiah/debian/mapiah-0.0.orig/functional/th2reader.cpp: In member function 'void TH2Reader::parseXTherionSetting()': /home/wookey/packages/therion/mapiah/debian/mapiah-0.0.orig/functional/th2reader.cpp:59:42: error: 'class QStringList' has no member named 'sliced' 59 | QString xtherionParameters = m_words.sliced(2).join(" "); | ^~~~~~ Which comes from this build line: [ 52%] Building CXX object CMakeFiles/Mapiah.dir/data/th2xtherionsetting.cpp.o /usr/bin/c++ -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_WIDGETS_LIB -I/home/wookey/packages/therion/mapiah/debian/mapiah-0.0.orig/obj-x86_64-linux-gnu -I/home/wookey/packages/therion/mapiah/debian/mapiah-0.0.orig -I/home/wookey/packages/therion/mapiah/debian/mapiah-0.0.orig/obj-x86_64-linux-gnu/Mapiah_autogen/include -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -isystem /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -g -O2 -ffile-prefix-map=/home/wookey/packages/therion/mapiah/debian/mapiah-0.0.orig=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -std=gnu++11 -MD -MT CMakeFiles/Mapiah.dir/data/th2xtherionsetting.cpp.o -MF CMakeFiles/Mapiah.dir/data/th2xtherionsetting.cpp.o.d -o CMakeFiles/Mapiah.dir/data/th2xtherionsetting.cpp.o -c /home/wookey/packages/therion/mapiah/debian/mapiah-0.0.orig/data/th2xtherionsetting.cpp Any idea why that might be happening? I've got Qt 5.15.2 (in both stable and unstable). Do I need a newer QT or something? So then I worked out what to do with an appimage... > Please let me know what you think about it, if it has any future, if you want to help. > *Functionality* > > This 0.0.1 release can read a TH2 file, present it on the screen and save it. > > With an open file you can change the zoom level and write the file again. > > You should be able to see your TH2 file on screen correctly and the saved file should be functionally identical to the original one. Yep I saw a correct-looking file (although the colour made it very hard to actually see on my screen) And saving worked. The files has been munged quite a lot with layout changes and numbers reformated/significant figures changed. The image_insert numbers were changed drastically: from: ##XTHERION## xth_me_image_insert {0 1 1.0} {0 {4}} oldmansrift-plan.xvi 0 {} to: ##XTHERION## xth_me_image_insert {2500.9558480028363 1 1.0} {1629.5298423667257 4} oldmansrift-plan.xvi 0 {} not sure about that? I'm certainly in favour of a nicer UI than the 'proof of concept' tcl one we've had for nearly 20 years now :-) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From bruce at tomo.co.nz Tue Dec 14 07:41:24 2021 From: bruce at tomo.co.nz (Bruce Mutton) Date: Tue, 14 Dec 2021 19:41:24 +1300 Subject: [Therion] A little French in XTherion English language text editor Message-ID: <000001d7f0b5$9dfa1c80$d9ee5580$@tomo.co.nz> First time I have manually entered survey data into XTherion for years. A mysterious French prompt has appeared - I think it is a toggle forcing XTherion to ask for station names. Except that ticked or unticked there seems to be no difference in behaviour . Is there meant to be a tick box? What should it do? And perhaps an English translation in the next release? Cheers Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 63813 bytes Desc: not available URL: From bruce at tomo.co.nz Tue Dec 14 07:46:48 2021 From: bruce at tomo.co.nz (Bruce Mutton) Date: Tue, 14 Dec 2021 19:46:48 +1300 Subject: [Therion] A little French in XTherion English language text editor In-Reply-To: <000001d7f0b5$9dfa1c80$d9ee5580$@tomo.co.nz> References: <000001d7f0b5$9dfa1c80$d9ee5580$@tomo.co.nz> Message-ID: <000b01d7f0b6$5eca4f70$1c5eee50$@tomo.co.nz> Answered my questions. Ticking the box makes the data table cycle through the from and to station boxes. Unticking the box makes the data table omit the from and to station boxes from the data entry cycle. Bruce From: Therion On Behalf Of Bruce Mutton Sent: Tuesday, 14 December 2021 19:41 To: 'List for Therion users' Subject: [Therion] A little French in XTherion English language text editor First time I have manually entered survey data into XTherion for years. A mysterious French prompt has appeared - I think it is a toggle forcing XTherion to ask for station names. Except that ticked or unticked there seems to be no difference in behaviour . Is there meant to be a tick box? What should it do? And perhaps an English translation in the next release? Cheers Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 85976 bytes Desc: not available URL: From wookey at wookware.org Tue Dec 14 21:54:47 2021 From: wookey at wookware.org (Wookey) Date: Tue, 14 Dec 2021 20:54:47 +0000 Subject: [Therion] Therion chat space (matrix) Message-ID: <20211214205447.GB29287@mail.wookware.org> There has been a (barely used) therion IRC channel for a decade or so. Now there is a Therion matrix space too, which we propose to use for 'new UI' development chat, but can of course be used for any chat not really suited to the mailing list. #therion:matrix.org With two rooms: General and UIdevelopment - we could add more if need be There are lots of ways/apps to talk to matrix this is an easy web-based place to get started: https://matrix.to/#/#therion:matrix.org You will need a matrix account somewhere - either your own/local, or a default one on matrix.org I use 'revolt' on my laptop and 'element' on my phone or inside a browser. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From lists at group-s.sk Sat Dec 18 15:37:22 2021 From: lists at group-s.sk (Stacho Mudrak) Date: Sat, 18 Dec 2021 15:37:22 +0100 Subject: [Therion] Map offset: just specify offset in complex dataset (proposes new "offset" thconfig compiler command) In-Reply-To: References: Message-ID: Hi Beni, first, I am sorry for the late answer. Do I understand you correctly, that you want to mix "select survey" and "unselect/offset particular map"? To be able to export all maps from a given survey without the need of specification of the master map for this survey. Am I right? Select survey and unselect survey seems to work for me. But unselect map is missing/not working, neither combination of map/survey select/unselect. Normally - if map selection for a given projection is available, it is used. If not, survey selection is used. I think, unselecting/offsetting maps from survey selection is feasible without any negative side effects. I am just not sure, how much work would it be to implement it. S. On Thu, 9 Dec 2021 at 10:37, Benedikt Hallinger wrote: > Hello, > I currently experiment with creating a nice overview map of a fairly > complex part of the Hirlatz cave. The dataset spans about 8km in passage > lengths in variuous levels with lots of over-/underlaying passages. > The data is organised in surveys, where each survey defines at least a > "Hauptmap" wich usually includes all the submaps the main map is > composed of. The main intend of the "Hauptmap" is to nicely render the > survey alone. > > Now I want to create an overview map and using the select statement I > can easily instruct therion to suck in and render all the maps of the > entire region. Offsets are stripped this way, but therion does a very > nice job in sorting te maps according to the altitude, which eases my > brain very much, since i don't need to wrap my head around sorting 54 > maps by hand. Therion does a splendid job with this already. > > However this produces one problem for me: I cannot render map offsets > easily anymore. > So what I had to do is to select the entire region using "select > Wandaugenlabyrinth.Hirlatzhoehle" and render that. > This will print the processes maps into the therion.log file. > From there I have picket it up to create a new "map" structure (`grep ^M > therion.og |sort -r | awk '{print $3}'`). > This i added to the thconfig file and selected that instead. There it is > now easy to define offets again. > > BUT: This introduces another, long term problem: > When sometimes in the future someone adds a new survey to this region, > he needs to remember to merge its maps also into the overview map > definition (at the correct position because of altitude!). > > > > Thus, it would be cool if we had some kind of "offset" thconfig command > alongside the select one. > This would allow me to read in the entire regions maps, and just specify > offsets for the offset ones; something like this: > > ----- thconfig ----- > source ../../therion/Hirlatzhoehle.th > select Wandaugenlabyrinth.Hirlatzhoehle # read in all defined maps of > the Region > > offset 173-Anschluss-177 at 173.Wandaugenlabyrinth.Hirlatzhoehle [20 15 m] > below > offset 177-Hauptplan at 177.Wandaugenlabyrinth.Hirlatzhoehle [-30 -20 > m] above > -------------------- > > Expected result would be all the maps read and printed at their altitude > level, but the two maps offset as already known from the "map" command. > If someone adds, lets say, > 200-Hauptplan at 200.Wandaugenlabyrinth.Hirlatzhoehle and recompiles the > file, the new survey would be included *without specifying it > explicitely*. > > > Is such a command possible? > I know it's not such a big deal with smaller caves, but in my dataset > this would save a tremendous ammount of time down the road when I will > make the atlas of Hirlatz regions (not to mention a big overview map). > > > ps. and probably relatet: When I give "select > Wandaugenlabyrinth.Hirlatzhoehle" and then "unselect > 177-Hauptplan at 177.Wandaugenlabyrinth.Hirlatzhoehle", 177 survey is still > printed to the map. I would had expected that the scraps of the map > would be hidden from output. > > > Kind regards, > Beni > _______________________________________________ > Therion mailing list > Therion at speleo.sk > https://mailman.speleo.sk/listinfo/therion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at group-s.sk Sat Dec 18 15:38:40 2021 From: lists at group-s.sk (Stacho Mudrak) Date: Sat, 18 Dec 2021 15:38:40 +0100 Subject: [Therion] A little French in XTherion English language text editor In-Reply-To: <000001d7f0b5$9dfa1c80$d9ee5580$@tomo.co.nz> References: <000001d7f0b5$9dfa1c80$d9ee5580$@tomo.co.nz> Message-ID: Thanks, for finding out Bruce. It was some typo in the translation file. S. On Tue, 14 Dec 2021 at 07:41, Bruce Mutton wrote: > First time I have manually entered survey data into XTherion for years. > > A mysterious French prompt has appeared ? I think it is a toggle forcing > XTherion to ask for station names. > > Except that ticked or unticked there seems to be no difference in > behaviour > > . > > > > Is there meant to be a tick box? What should it do? And perhaps an > English translation in the next release? > > Cheers > > Bruce > _______________________________________________ > Therion mailing list > Therion at speleo.sk > https://mailman.speleo.sk/listinfo/therion > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 63813 bytes Desc: not available URL: From beni at hallinger.org Sat Dec 18 17:15:20 2021 From: beni at hallinger.org (Benedikt Hallinger) Date: Sat, 18 Dec 2021 17:15:20 +0100 Subject: [Therion] Map offset: just specify offset in complex dataset (proposes new "offset" thconfig compiler command) In-Reply-To: References: Message-ID: Hi, the more important question for me is, how (if?) i can select an entire survey structure(containing scraps, maps etc), and specify that i want a specific map to be offset. Your main conclusion was correct, i want to print all maps, without explicitely specifying them, and at the same time offset some maps thereof. I want to ?select all?, ?offset 1234-map? and optionally completely hide ?456-map? (or alternatively its survey) > Am 18.12.2021 um 15:38 schrieb Stacho Mudrak : > > ? > Hi Beni, > > first, I am sorry for the late answer. > > Do I understand you correctly, that you want to mix "select survey" and "unselect/offset particular map"? To be able to export all maps from a given survey without the need of specification of the master map for this survey. Am I right? > > Select survey and unselect survey seems to work for me. But unselect map is missing/not working, neither combination of map/survey select/unselect. Normally - if map selection for a given projection is available, it is used. If not, survey selection is used. > > I think, unselecting/offsetting maps from survey selection is feasible without any negative side effects. I am just not sure, how much work would it be to implement it. > > S. > > > >> On Thu, 9 Dec 2021 at 10:37, Benedikt Hallinger wrote: >> Hello, >> I currently experiment with creating a nice overview map of a fairly >> complex part of the Hirlatz cave. The dataset spans about 8km in passage >> lengths in variuous levels with lots of over-/underlaying passages. >> The data is organised in surveys, where each survey defines at least a >> "Hauptmap" wich usually includes all the submaps the main map is >> composed of. The main intend of the "Hauptmap" is to nicely render the >> survey alone. >> >> Now I want to create an overview map and using the select statement I >> can easily instruct therion to suck in and render all the maps of the >> entire region. Offsets are stripped this way, but therion does a very >> nice job in sorting te maps according to the altitude, which eases my >> brain very much, since i don't need to wrap my head around sorting 54 >> maps by hand. Therion does a splendid job with this already. >> >> However this produces one problem for me: I cannot render map offsets >> easily anymore. >> So what I had to do is to select the entire region using "select >> Wandaugenlabyrinth.Hirlatzhoehle" and render that. >> This will print the processes maps into the therion.log file. >> From there I have picket it up to create a new "map" structure (`grep ^M >> therion.og |sort -r | awk '{print $3}'`). >> This i added to the thconfig file and selected that instead. There it is >> now easy to define offets again. >> >> BUT: This introduces another, long term problem: >> When sometimes in the future someone adds a new survey to this region, >> he needs to remember to merge its maps also into the overview map >> definition (at the correct position because of altitude!). >> >> >> >> Thus, it would be cool if we had some kind of "offset" thconfig command >> alongside the select one. >> This would allow me to read in the entire regions maps, and just specify >> offsets for the offset ones; something like this: >> >> ----- thconfig ----- >> source ../../therion/Hirlatzhoehle.th >> select Wandaugenlabyrinth.Hirlatzhoehle # read in all defined maps of >> the Region >> >> offset 173-Anschluss-177 at 173.Wandaugenlabyrinth.Hirlatzhoehle [20 15 m] >> below >> offset 177-Hauptplan at 177.Wandaugenlabyrinth.Hirlatzhoehle [-30 -20 >> m] above >> -------------------- >> >> Expected result would be all the maps read and printed at their altitude >> level, but the two maps offset as already known from the "map" command. >> If someone adds, lets say, >> 200-Hauptplan at 200.Wandaugenlabyrinth.Hirlatzhoehle and recompiles the >> file, the new survey would be included *without specifying it >> explicitely*. >> >> >> Is such a command possible? >> I know it's not such a big deal with smaller caves, but in my dataset >> this would save a tremendous ammount of time down the road when I will >> make the atlas of Hirlatz regions (not to mention a big overview map). >> >> >> ps. and probably relatet: When I give "select >> Wandaugenlabyrinth.Hirlatzhoehle" and then "unselect >> 177-Hauptplan at 177.Wandaugenlabyrinth.Hirlatzhoehle", 177 survey is still >> printed to the map. I would had expected that the scraps of the map >> would be hidden from output. >> >> >> Kind regards, >> Beni >> _______________________________________________ >> Therion mailing list >> Therion at speleo.sk >> https://mailman.speleo.sk/listinfo/therion > _______________________________________________ > Therion mailing list > Therion at speleo.sk > https://mailman.speleo.sk/listinfo/therion -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce at tomo.co.nz Sun Dec 19 00:42:59 2021 From: bruce at tomo.co.nz (Bruce Mutton) Date: Sun, 19 Dec 2021 12:42:59 +1300 Subject: [Therion] Migovec Github survey data project Message-ID: <000801d7f468$febb8fc0$fc32af40$@tomo.co.nz> Not directly a Therion question. I've been loosely following the progress of https://github.com/iccaving/migovec-survey-data a couple of years, but only recently started migrating some projects of my own to git. So thought I'd dispense with just admiring the outputs and fork the migovec repository to do a deep dive learn from the apparent masters. The REDME.md is exemplary, but the section on 'How to contribute' seems to be missing a most important thing - how do contributors interact with other contributors and the repository? The lack of issues and forks that similar sized GitHub projects have suggests I'm missing something obvious. I know Therion pretty well, passible on version control but only just cutting my teeth on git and GitHub. I found a simple problem in some thconfigs that causes Therion to crash and exit, and located the cause in the history. I could potentially fix it, make a pull request, but as I have only studied the migovec structure for literally 10 minutes, any 'fix' I work on will take me a while and be bound to be error prone. Better for me just to point out the problem. Anyone here know how the iccaving migovec Therion team communicates or would one of them on this list be able to PM me? Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From beni at hallinger.org Sun Dec 19 12:38:04 2021 From: beni at hallinger.org (Benedikt Hallinger) Date: Sun, 19 Dec 2021 12:38:04 +0100 Subject: [Therion] Migovec Github survey data project In-Reply-To: <000801d7f468$febb8fc0$fc32af40$@tomo.co.nz> References: <000801d7f468$febb8fc0$fc32af40$@tomo.co.nz> Message-ID: Hi, no specific info on the exact project, but generally you could open a issue ticket there and ask your very question. Each project may have its own rules. But most commonly it works this way: - you clone the repo at github (so its public) - you make a new branch and do your stuff - you then open a pull request against the upstream repo - someone there inspects it and if it is accepted, will merge - done > Am 19.12.2021 um 00:43 schrieb Bruce Mutton : > > ? > Not directly a Therion question. > I?ve been loosely following the progress of https://github.com/iccaving/migovec-survey-data a couple of years, but only recently started migrating some projects of my own to git. > > So thought I?d dispense with just admiring the outputs and fork the migovec repository to do a deep dive learn from the apparent masters? > The REDME.md is exemplary, but the section on ?How to contribute? seems to be missing a most important thing ? how do contributors interact with other contributors and the repository? The lack of issues and forks that similar sized GitHub projects have suggests I?m missing something obvious. I know Therion pretty well, passible on version control but only just cutting my teeth on git and GitHub. > > I found a simple problem in some thconfigs that causes Therion to crash and exit, and located the cause in the history. I could potentially fix it, make a pull request, but as I have only studied the migovec structure for literally 10 minutes, any ?fix? I work on will take me a while and be bound to be error prone. Better for me just to point out the problem. > > Anyone here know how the iccaving migovec Therion team communicates or would one of them on this list be able to PM me? > > Bruce > _______________________________________________ > Therion mailing list > Therion at speleo.sk > https://mailman.speleo.sk/listinfo/therion -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhystyers1 at gmail.com Tue Dec 21 00:08:14 2021 From: rhystyers1 at gmail.com (Rhys Tyers) Date: Mon, 20 Dec 2021 23:08:14 +0000 Subject: [Therion] Migovec Github survey data project In-Reply-To: References: <000801d7f468$febb8fc0$fc32af40$@tomo.co.nz> Message-ID: Hey, I work on this repository. Thank you for your kind words. We use github as a convenient means to collaborate amongst ourselves and host data but I guess we differ from an open source software project in that there's not much point in accepting outside contribution as only people who attend our expedition are generally interested in drawing our survey! We generally collaborate by running a meeting via voice chat and drawing survey as a social activity, emulating how we drew before Therion. Theoretically we could use pull requests and issues to work on our data but as we are normally talking to eachother as we draw it is just easier to push what each person does sequentially to master, relying on git to avoid messing anything up. Also most of our contributors are science students and while they have a familiarity with git they normally haven't really used it for collaboration in the same way someone working in software would. As for the broken thconfigs the answer is similar, that the current drawers know which ones work and it's a bit fluid so we haven't bothered documenting it. Half the reason it exists in it's current format is that I do work in software so I tend to maintain all the extraneous git cruft as my armchair caving while other people focus on the _actual_ work of drawing stuff ? If you do have any questions about it feel free to email me or Imperial caving. Rhys On Sun, 19 Dec 2021, 11:38 Benedikt Hallinger, wrote: > Hi, > no specific info on the exact project, but generally you could open a > issue ticket there and ask your very question. Each project may have its > own rules. > > But most commonly it works this way: > - you clone the repo at github (so its public) > - you make a new branch and do your stuff > - you then open a pull request against the upstream repo > - someone there inspects it and if it is accepted, will merge > - done > > Am 19.12.2021 um 00:43 schrieb Bruce Mutton : > > ? > > Not directly a Therion question. > > I?ve been loosely following the progress of > https://github.com/iccaving/migovec-survey-data a couple of years, but > only recently started migrating some projects of my own to git. > > > > So thought I?d dispense with just admiring the outputs and fork the > migovec repository to do a deep dive learn from the apparent masters? > > The REDME.md is exemplary, but the section on ?How to contribute? seems to > be missing a most important thing ? how do contributors interact with other > contributors and the repository? The lack of issues and forks that similar > sized GitHub projects have suggests I?m missing something obvious. I know > Therion pretty well, passible on version control but only just cutting my > teeth on git and GitHub. > > > > I found a simple problem in some thconfigs that causes Therion to crash > and exit, and located the cause in the history. I could potentially fix > it, make a pull request, but as I have only studied the migovec structure > for literally 10 minutes, any ?fix? I work on will take me a while and be > bound to be error prone. Better for me just to point out the problem. > > > > Anyone here know how the iccaving migovec Therion team communicates or > would one of them on this list be able to PM me? > > > > Bruce > _______________________________________________ > Therion mailing list > Therion at speleo.sk > https://mailman.speleo.sk/listinfo/therion > > _______________________________________________ > Therion mailing list > Therion at speleo.sk > https://mailman.speleo.sk/listinfo/therion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce at tomo.co.nz Tue Dec 21 10:18:17 2021 From: bruce at tomo.co.nz (Bruce Mutton) Date: Tue, 21 Dec 2021 22:18:17 +1300 Subject: [Therion] Migovec Github survey data project In-Reply-To: References: <000801d7f468$febb8fc0$fc32af40$@tomo.co.nz> Message-ID: <000001d7f64b$b2c9f900$185deb00$@tomo.co.nz> Thanks Rhys, good to meet you. Your answer explains the gap I detected. I recall small groups of cavers bent over a large table drawing on film with ink pens. Thirty years ago. We haven?t managed to duplicate the physicality and sociability since, but at least since we found version control just over a decade ago we can have a few people working on the same project, even if it is usually alone and one at a time. And we don?t have to unclog pens. Very interested in your custom point map-connection by the way. Bruce From: Therion On Behalf Of Rhys Tyers Sent: Tuesday, 21 December 2021 12:08 To: List for Therion users Subject: Re: [Therion] Migovec Github survey data project Hey, I work on this repository. Thank you for your kind words. We use github as a convenient means to collaborate amongst ourselves and host data but I guess we differ from an open source software project in that there's not much point in accepting outside contribution as only people who attend our expedition are generally interested in drawing our survey! We generally collaborate by running a meeting via voice chat and drawing survey as a social activity, emulating how we drew before Therion. Theoretically we could use pull requests and issues to work on our data but as we are normally talking to eachother as we draw it is just easier to push what each person does sequentially to master, relying on git to avoid messing anything up. Also most of our contributors are science students and while they have a familiarity with git they normally haven't really used it for collaboration in the same way someone working in software would. As for the broken thconfigs the answer is similar, that the current drawers know which ones work and it's a bit fluid so we haven't bothered documenting it. Half the reason it exists in it's current format is that I do work in software so I tend to maintain all the extraneous git cruft as my armchair caving while other people focus on the _actual_ work of drawing stuff ? If you do have any questions about it feel free to email me or Imperial caving. Rhys On Sun, 19 Dec 2021, 11:38 Benedikt Hallinger, > wrote: Hi, no specific info on the exact project, but generally you could open a issue ticket there and ask your very question. Each project may have its own rules. But most commonly it works this way: - you clone the repo at github (so its public) - you make a new branch and do your stuff - you then open a pull request against the upstream repo - someone there inspects it and if it is accepted, will merge - done Am 19.12.2021 um 00:43 schrieb Bruce Mutton >: ?Not directly a Therion question. I?ve been loosely following the progress of https://github.com/iccaving/migovec-survey-data a couple of years, but only recently started migrating some projects of my own to git. So thought I?d dispense with just admiring the outputs and fork the migovec repository to do a deep dive learn from the apparent masters? The README.md is exemplary, but the section on ?How to contribute? seems to be missing a most important thing ? how do contributors interact with other contributors and the repository? The lack of issues and forks that similar sized GitHub projects have suggests I?m missing something obvious. I know Therion pretty well, passible on version control but only just cutting my teeth on git and GitHub. I found a simple problem in some thconfigs that causes Therion to crash and exit, and located the cause in the history. I could potentially fix it, make a pull request, but as I have only studied the migovec structure for literally 10 minutes, any ?fix? I work on will take me a while and be bound to be error prone. Better for me just to point out the problem. Anyone here know how the iccaving migovec Therion team communicates or would one of them on this list be able to PM me? Bruce _______________________________________________ Therion mailing list Therion at speleo.sk https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion at speleo.sk https://mailman.speleo.sk/listinfo/therion -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinsluka at mac.com Tue Dec 21 10:51:26 2021 From: martinsluka at mac.com (Martin Sluka) Date: Tue, 21 Dec 2021 10:51:26 +0100 Subject: [Therion] Migovec Github survey data project In-Reply-To: <000001d7f64b$b2c9f900$185deb00$@tomo.co.nz> References: <000001d7f64b$b2c9f900$185deb00$@tomo.co.nz> Message-ID: <6F2F0457-7454-4825-8E43-3E75B0ED7E02@mac.com> For communication with Github repository you may use Github Desktop application. M. Odesl?no z iPhonu > 21.?12.?2021 v 10:18, Bruce Mutton : > > ? > Thanks Rhys, good to meet you. > Your answer explains the gap I detected. > I recall small groups of cavers bent over a large table drawing on film with ink pens. Thirty years ago. We haven?t managed to duplicate the physicality and sociability since, but at least since we found version control just over a decade ago we can have a few people working on the same project, even if it is usually alone and one at a time. And we don?t have to unclog pens. > Very interested in your custom point map-connection by the way. > Bruce > > From: Therion On Behalf Of Rhys Tyers > Sent: Tuesday, 21 December 2021 12:08 > To: List for Therion users > Subject: Re: [Therion] Migovec Github survey data project > > Hey, I work on this repository. Thank you for your kind words. > > We use github as a convenient means to collaborate amongst ourselves and host data but I guess we differ from an open source software project in that there's not much point in accepting outside contribution as only people who attend our expedition are generally interested in drawing our survey! > > We generally collaborate by running a meeting via voice chat and drawing survey as a social activity, emulating how we drew before Therion. > > Theoretically we could use pull requests and issues to work on our data but as we are normally talking to eachother as we draw it is just easier to push what each person does sequentially to master, relying on git to avoid messing anything up. > > Also most of our contributors are science students and while they have a familiarity with git they normally haven't really used it for collaboration in the same way someone working in software would. > > As for the broken thconfigs the answer is similar, that the current drawers know which ones work and it's a bit fluid so we haven't bothered documenting it. > > Half the reason it exists in it's current format is that I do work in software so I tend to maintain all the extraneous git cruft as my armchair caving while other people focus on the _actual_ work of drawing stuff ? > > If you do have any questions about it feel free to email me or Imperial caving. > > Rhys > > On Sun, 19 Dec 2021, 11:38 Benedikt Hallinger, wrote: > Hi, > no specific info on the exact project, but generally you could open a issue ticket there and ask your very question. Each project may have its own rules. > > But most commonly it works this way: > - you clone the repo at github (so its public) > - you make a new branch and do your stuff > - you then open a pull request against the upstream repo > - someone there inspects it and if it is accepted, will merge > - done > > Am 19.12.2021 um 00:43 schrieb Bruce Mutton : > > ?Not directly a Therion question. > I?ve been loosely following the progress of https://github.com/iccaving/migovec-survey-data a couple of years, but only recently started migrating some projects of my own to git. > So thought I?d dispense with just admiring the outputs and fork the migovec repository to do a deep dive learn from the apparent masters? > The README.md is exemplary, but the section on ?How to contribute? seems to be missing a most important thing ? how do contributors interact with other contributors and the repository? The lack of issues and forks that similar sized GitHub projects have suggests I?m missing something obvious. I know Therion pretty well, passible on version control but only just cutting my teeth on git and GitHub. > I found a simple problem in some thconfigs that causes Therion to crash and exit, and located the cause in the history. I could potentially fix it, make a pull request, but as I have only studied the migovec structure for literally 10 minutes, any ?fix? I work on will take me a while and be bound to be error prone. Better for me just to point out the problem. > Anyone here know how the iccaving migovec Therion team communicates or would one of them on this list be able to PM me? > Bruce > _______________________________________________ > Therion mailing list > Therion at speleo.sk > https://mailman.speleo.sk/listinfo/therion > _______________________________________________ > Therion mailing list > Therion at speleo.sk > https://mailman.speleo.sk/listinfo/therion > _______________________________________________ > Therion mailing list > Therion at speleo.sk > https://mailman.speleo.sk/listinfo/therion -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgee at campercaver.net Sat Dec 25 15:50:26 2021 From: bgee at campercaver.net (Bill Gee) Date: Sat, 25 Dec 2021 08:50:26 -0600 Subject: [Therion] Handling of tape and backtape in survey data Message-ID: <1820748.6CsIbPlgNm@main2.billgee.local> Hello everyone - I have a holiday question for the group. We have for years done our survey shots both directions, obtaining a forward and backward reading for both compass and inclinometer. The two readings are averaged by Survex and Therion in an effort to reduce errors. The tape reading, however, has only been a single number. Now that the use of DistoX2 devices is becoming common, it is easy to get a distance measurement both forward and backward. I have been ignoring the backward distance reading in the field. It does not get into my notes. I might need to change that practice. I looked at the Survex manual yesterday and see that it supports both TAPE and BACKTAPE (also called LENGTH and BACKLENGTH) in the survey data. That brings up two questions: 1) Does Therion also recognize the BACKTAPE data type? 2) What does Survex do if both TAPE and BACKTAPE are given? Does it average the two readings? Does Therion do the same thing? I understand that Therion will use Survex to reduce the centerline data - if Survex is installed. In case Survex is NOT installed, then Therion reduces the centerline itself. As a result they might handle this situation differently. As I write this, another related question occurred to me. When either Therion or Survex averages a forward and backward reading, how many significant digits does it carry in the calculation? Can the significant digits be changed? And the same question applies to loop closure calculations. How many significant digits are carried through the calculations? Thanks! ======== Bill Gee From ben at caver.plus.com Sun Dec 26 09:00:49 2021 From: ben at caver.plus.com (Ben Cooper) Date: Sun, 26 Dec 2021 08:00:49 +0000 Subject: [Therion] Handling of tape and backtape in survey data In-Reply-To: <1820748.6CsIbPlgNm@main2.billgee.local> References: <1820748.6CsIbPlgNm@main2.billgee.local> Message-ID: <890B2E35-B532-438C-9CD8-A75277E656E9@caver.plus.com> Hi Bill, et al, I?ve always thought that backsites didn?t need specific handling as effectively they form a small loop so would be handled by the loop averaging. I don?t often do backsites, and get reasonable accuracy without (as good as 0.5%, depending on conditions). But when I do I always do a full reading, indeed it would be hard not to with a DistoX-PDA ?total station? as all the data is collected automatically. In fact for this setup, there is no way to mark a backsite as a backsite (or if there is, I?ve never used it!) and instead Toporobot just generates a new station for the backsite. I then manually ?equate? these in the .th file, creating a loop, together with any actual loops. I usually do this after compiling the survey for the first time, as it?s fun to see on the 3d how close any two measured stations appear, and hence get a visual feel for the accuracy and where potential blunders might (eg mislabelling a station) But now I?m wondering how Survex handles all these loops because if every leg has a backsite, then the number of loops increases, crumbs, very quickly. Hmm, I can't even begin to work out how to count that mathematically. It?s very much smaller than nCr because the loops can only be made up of adjacent legs, eg for 5 legs, the loops generated between any three are only 1-2-3, 2-3-4, and 3-4-5; nCr also counts 1-2-4, 1-2-5, etc, which are not loops. So while nCr quickly becomes uncomputable for even modest sizes of n, I don?t know if the number of loops also becomes uncomputable? What does Survex actually do for all these loops? Best regards Ben Sent from my iPhone > On 25 Dec 2021, at 14:51, Bill Gee wrote: > > ?Hello everyone - > > I have a holiday question for the group. We have for years done our survey shots both directions, obtaining a forward and backward reading for both compass and inclinometer. The two readings are averaged by Survex and Therion in an effort to reduce errors. The tape reading, however, has only been a single number. > > Now that the use of DistoX2 devices is becoming common, it is easy to get a distance measurement both forward and backward. I have been ignoring the backward distance reading in the field. It does not get into my notes. I might need to change that practice. > > I looked at the Survex manual yesterday and see that it supports both TAPE and BACKTAPE (also called LENGTH and BACKLENGTH) in the survey data. That brings up two questions: > > 1) Does Therion also recognize the BACKTAPE data type? > > 2) What does Survex do if both TAPE and BACKTAPE are given? Does it average the two readings? Does Therion do the same thing? > > I understand that Therion will use Survex to reduce the centerline data - if Survex is installed. In case Survex is NOT installed, then Therion reduces the centerline itself. As a result they might handle this situation differently. > > As I write this, another related question occurred to me. When either Therion or Survex averages a forward and backward reading, how many significant digits does it carry in the calculation? Can the significant digits be changed? > > And the same question applies to loop closure calculations. How many significant digits are carried through the calculations? > > Thanks! > ======== > Bill Gee > > > > > _______________________________________________ > Therion mailing list > Therion at speleo.sk > https://mailman.speleo.sk/listinfo/therion From tarquin.wilton-jones at ntlworld.com Sun Dec 26 19:32:39 2021 From: tarquin.wilton-jones at ntlworld.com (Tarquin Wilton-Jones) Date: Sun, 26 Dec 2021 18:32:39 +0000 Subject: [Therion] Handling of tape and backtape in survey data In-Reply-To: <890B2E35-B532-438C-9CD8-A75277E656E9@caver.plus.com> References: <1820748.6CsIbPlgNm@main2.billgee.local> <890B2E35-B532-438C-9CD8-A75277E656E9@caver.plus.com> Message-ID: <250e1123-8561-476c-c13c-69d96e293116@ntlworld.com> > when I do I always do a full reading A splay is useful only for immediate error checking on the data gathering device (magnetic or calibration), but cannot be used for automatic error correction unless the app can do it for you (like SexyTopo can, but only for opposing splays, not for opposing legs). So there is a benefit to having a full leg there. However, for Disto surveying, it feels largely unnecessary, as the accuracy is already a lot more than most surveys need when just using forward sightings. > instead Toporobot just generates a new station for the backsite. This must be a nightmare for mistakes, always having to tell the app which station the next readings are going to be taken from, before you continue surveying. > I then manually ?equate? these in the .th file, creating a loop While nice for error handling, this must make your cave lengths completely meaningless; typically twice the correct length (if you consistently do it throughout a survey). Or do you manually set the "flags duplicate" for every backsight, then back to "flags not duplicate" for the forward sighting? Do Survex and Therion know to use only a single length if there is a forward and backsight leg between the same two stations? I sense an investigation coming soon unless Wookey appears with some knowledge gem... Cheers, Tarquin From martinsluka at me.com Mon Dec 27 20:15:27 2021 From: martinsluka at me.com (Martin Sluka) Date: Mon, 27 Dec 2021 20:15:27 +0100 Subject: [Therion] Handling of tape and backtape in survey data In-Reply-To: <250e1123-8561-476c-c13c-69d96e293116@ntlworld.com> References: <1820748.6CsIbPlgNm@main2.billgee.local> <890B2E35-B532-438C-9CD8-A75277E656E9@caver.plus.com> <250e1123-8561-476c-c13c-69d96e293116@ntlworld.com> Message-ID: <7C9C280F-C8D7-4F59-987C-FBD35002CE5A@me.com> > 26. 12. 2021 v 19:32, Tarquin Wilton-Jones via Therion : > > However, for Disto > surveying, it feels largely unnecessary, as the accuracy is already a > lot more than most surveys need when just using forward sightings. But because DistoX is an electronic device it is only way to be sure it works properly. The same as check, if three (four) readings for surveying leg with rotation around the longitudinal axe of DistoX are in tolerance interval. Martin S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgee at campercaver.net Mon Dec 27 20:36:57 2021 From: bgee at campercaver.net (Bill Gee) Date: Mon, 27 Dec 2021 13:36:57 -0600 Subject: [Therion] Handling of tape and backtape in survey data In-Reply-To: <7C9C280F-C8D7-4F59-987C-FBD35002CE5A@me.com> References: <1820748.6CsIbPlgNm@main2.billgee.local> <250e1123-8561-476c-c13c-69d96e293116@ntlworld.com> <7C9C280F-C8D7-4F59-987C-FBD35002CE5A@me.com> Message-ID: <1971623.i4taiW3uLq@main2.billgee.local> Ben's comment about backshots being a form of loop is interesting. I had not though of it that way, but he is right! I do not use electronic sketching in a cave. All the data from the DistoX2 goes on paper just like Suunto/tape data. I have looked at Qave and TopoDroid, and for now I think they are not quite ready for prime time. There are people out there who swear by electronic sketching. I am just an old curmudgeon! But not quite old enough to go back to Bruntons. I am also not convinced that a DistoX is more accurate than Suunto/tape methods. It is certainly easier to use, especially for newbies. It is much less bulky since the tape reel can be left behind, and it really helps with LRUD measurements. But -- Do not assume that "electronic" is the same as "accurate". In a recent update to one of my project caves, I noticed the loop closure errors from Survex were impressive. Most were under 2%, and several under 1%. Even better - those loops used readings taken with both Suunto/tape and DistoX2 by several teams over a period of three years. I think the critical factor is getting good back shots to verify the data in the field, and then having the computer average the forward and back shots. I remember seeing a presentation at a recent NSS Convention (2020, maybe?) where someone took an uncalibrated DistoX2 and ran it around a survey course on the surface. By averaging the forward and backward shots he got loop closures around 1% over 400 feet and a dozen stations. The data using Suunto/tape and a calibrated DistoX2 was not significantly different in the loop closure. ======== Bill Gee On Monday, December 27, 2021 1:15:27 PM CST Martin Sluka via Therion wrote: > > > 26. 12. 2021 v 19:32, Tarquin Wilton-Jones via Therion : > > > > However, for Disto > > surveying, it feels largely unnecessary, as the accuracy is already a > > lot more than most surveys need when just using forward sightings. > > But because DistoX is an electronic device it is only way to be sure it works properly. The same as check, if three (four) readings for surveying leg with rotation around the longitudinal axe of DistoX are in tolerance interval. > > Martin S. > From tarquin.wilton-jones at ntlworld.com Mon Dec 27 20:41:40 2021 From: tarquin.wilton-jones at ntlworld.com (Tarquin Wilton-Jones) Date: Mon, 27 Dec 2021 19:41:40 +0000 Subject: [Therion] Handling of tape and backtape in survey data In-Reply-To: <7C9C280F-C8D7-4F59-987C-FBD35002CE5A@me.com> References: <1820748.6CsIbPlgNm@main2.billgee.local> <890B2E35-B532-438C-9CD8-A75277E656E9@caver.plus.com> <250e1123-8561-476c-c13c-69d96e293116@ntlworld.com> <7C9C280F-C8D7-4F59-987C-FBD35002CE5A@me.com> Message-ID: <74b4d091-3705-6b09-9161-ead849375c91@ntlworld.com> On 27/12/2021 19:15, Martin Sluka via Therion wrote: > > >> 26. 12. 2021 v 19:32, Tarquin Wilton-Jones via Therion >> >: >> >> However, for Disto >> surveying, it feels largely unnecessary, as the accuracy is already a >> lot more than most surveys need when just using forward sightings. > > But because DistoX is an electronic device it is only way to be sure it > works properly. The same as check, if three (four) readings for > surveying leg with rotation around the longitudinal axe of DistoX are in > tolerance interval. Oh very true. This is one of the checks I recommend performing occasionally to test calibration (or every leg when working around scaffolding or magnetic rocks). Create legs with one reading flat, one rotated 90 degrees longitudinally, another reading flat or in any other orientation. Then validate with a splay back to the previous station. But personally I consider the leg forward, then duplicate backsighted *leg* for every single leg, to be largely overkill. There are already 3 readings for every leg, and a rotational test (with optional backsight splay) already serves the purpose of testing calibration and magnetic effects. And standard leapfrogging can already counteract clinometer calibration faults. But I am sure someone will have their reason to make each leg from 6 readings. :) From andrew at wotcc.org.uk Mon Dec 27 21:15:02 2021 From: andrew at wotcc.org.uk (Andrew Atkinson) Date: Mon, 27 Dec 2021 20:15:02 +0000 Subject: [Therion] Handling of tape and backtape in survey data In-Reply-To: <74b4d091-3705-6b09-9161-ead849375c91@ntlworld.com> References: <1820748.6CsIbPlgNm@main2.billgee.local> <890B2E35-B532-438C-9CD8-A75277E656E9@caver.plus.com> <250e1123-8561-476c-c13c-69d96e293116@ntlworld.com> <7C9C280F-C8D7-4F59-987C-FBD35002CE5A@me.com> <74b4d091-3705-6b09-9161-ead849375c91@ntlworld.com> Message-ID: On 27/12/2021 19:41, Tarquin Wilton-Jones via Therion wrote: >> But because DistoX is an electronic device it is only way to be sure it >> works properly. The same as check, if three (four) readings for >> surveying leg with rotation around the longitudinal axe of DistoX are in >> tolerance interval. > Oh very true. This is one of the checks I recommend performing > occasionally to test calibration (or every leg when working around > scaffolding or magnetic rocks). Create legs with one reading flat, one > rotated 90 degrees longitudinally, another reading flat or in any other > orientation. Then validate with a splay back to the previous station. I think, but have no proof, that if you rotate the distoX it is probably better than a manual backsight. pockettopo records the rotation, and I have this in the therion file. People surveying with me know I check that they rotate at least every 5 stations and i relity they rotate most station. All the times I've been with people doing backsights (mainly US cavers) all it seems to stop is blunders, if they don't get a reading that is within their personal tolerance they do it all again. The real question is how much are they doing expectation bias? I cannot really comment further as I have too little experience of this. On 27/12/2021 19:36, Bill Gee wrote: >> I remember seeing a presentation at a recent NSS Convention (2020, maybe?) where someone took an uncalibrated DistoX2 and ran it around a survey course on the surface. By averaging the forward and backward shots he got loop closures around 1% over 400 feet and a dozen stations. The data using Suunto/tape and a calibrated DistoX2 was not significantly different in the loop closure. A compass that is 10? (well any degrees off will give a 0% loop error, the longer the loop the lower the percentage error, however bad the survey. (bit of over simplification, but relatively true) High percent loop closure is a poor survey, the opposite is not true. This could turn into a long interesting debate, please feel free to argue with me, let's see how robust our ideas are :-) Andrew From olly at survex.com Mon Dec 27 22:56:04 2021 From: olly at survex.com (Olly Betts) Date: Mon, 27 Dec 2021 21:56:04 +0000 Subject: [Therion] Handling of tape and backtape in survey data In-Reply-To: <1820748.6CsIbPlgNm@main2.billgee.local> References: <1820748.6CsIbPlgNm@main2.billgee.local> Message-ID: <20211227215604.GR2728@survex.com> On Sat, Dec 25, 2021 at 08:50:26AM -0600, Bill Gee wrote: > 1) Does Therion also recognize the BACKTAPE data type? It seems not - there's no match in the source code repo for: git grep -i BACKTAPE > 2) What does Survex do if both TAPE and BACKTAPE are given? Does it > average the two readings? Does Therion do the same thing? Survex warns if they differ by more than 3 standard deviations, and then takes the mean of the readings. > I understand that Therion will use Survex to reduce the centerline > data - if Survex is installed. In case Survex is NOT installed, then > Therion reduces the centerline itself. As a result they might handle > this situation differently. Also, Therion generates a .svx file behind the scenes, but not necessarily the .svx file you'd write yourself given the same data. For example, I think Therion collapses backsights to a single reading itself before processing with Survex. > As I write this, another related question occurred to me. When either > Therion or Survex averages a forward and backward reading, how many > significant digits does it carry in the calculation? Can the > significant digits be changed? Survex uses double precision for this: https://en.wikipedia.org/wiki/Double-precision_floating-point_format That has 15-17 significant decimal digits - i.e. many more than matter here. Using more precision seems overkill. If you really want to use fewer it should be possible to build cavern to use single precision, but I don't think anyone actually does this. We made it an option as decades ago it seemed you might want to do this to reduce memory usage (4 bytes per floating point number instead of 8) but cavern's memory use is very modest by modern standards, and single precision only gives 6-9 significant decimal digits, which isn't even enough to reliably store a UTM Northing to the nearest metre so you'd be limited in what coordinate systems you could use in such a build. I don't see why you'd want to be able to dynamically force rounding to fewer significant figures - what's the benefit? Downsides of rounding are it would slow things down a bit, and it risks introducing systematic biases - a dumb example to make the issue clearer: if all readings are to the nearest inch and you round the average to the nearest inch and always round 0.5 up, then then assuming an even distribution there's an average bias of +0.25 inches on each tape reading. The problem with systematic biases is they accumulate rather than tending to cancel. There are other rounding schemes which try to address this sort of issue (like rounding 0.5 to the nearest even number) but it's hard to be certain they might not introduce a more subtle bias (some cave systems have dominant direction passage develops along so the distribution is may not uniform across odd and even) and there doesn't seem a compelling reason to be rounding in the first place. > And the same question applies to loop closure calculations. How many > significant digits are carried through the calculations? The same. The final results are then stored in the .3d file to the nearest cm (that's 0.000049710 furlongs for our US readers). That precision was chosen so that coordinate values will fit in a 32 bit integer, and seems adequate for the final results. Cheers, Olly From olly at survex.com Mon Dec 27 23:02:40 2021 From: olly at survex.com (Olly Betts) Date: Mon, 27 Dec 2021 22:02:40 +0000 Subject: [Therion] Handling of tape and backtape in survey data In-Reply-To: <890B2E35-B532-438C-9CD8-A75277E656E9@caver.plus.com> References: <1820748.6CsIbPlgNm@main2.billgee.local> <890B2E35-B532-438C-9CD8-A75277E656E9@caver.plus.com> Message-ID: <20211227220240.GS2728@survex.com> On Sun, Dec 26, 2021 at 08:00:49AM +0000, Ben Cooper wrote: > What does Survex actually do for all these loops? It deal with any backsights up front and just adds a single link to the network for each survey leg. It's harder to properly account for partial backsights if we created a separate link for the backsight (e.g. backcompass and backclino but no backtape is common). But even just from a network solving perspective, if we generated a trivial loop for each backsight the network optimisations would later rediscover each trivial loop and collapse it to a single leg, but that would be less efficient than collapsing it when we have the knowledge it's a trivial loop as we read in that leg. Cheers, Olly From bgee at campercaver.net Tue Dec 28 00:04:20 2021 From: bgee at campercaver.net (Bill Gee) Date: Mon, 27 Dec 2021 17:04:20 -0600 Subject: [Therion] Handling of tape and backtape in survey data In-Reply-To: <20211227215604.GR2728@survex.com> References: <1820748.6CsIbPlgNm@main2.billgee.local> <20211227215604.GR2728@survex.com> Message-ID: <78128087.vtJHq7cr8S@main2.billgee.local> Hi Olly - Many thanks for the answers. I think I will give BACKTAPE a try the next time I do some survey, if only to see what happens. My question about significant digits is really related to how much precision can and should be carried through a calculation. If compass readings are taken to four significant digits, then the mean of two such numbers is really only good to about three and a half significant digits. Displaying more significant digits implies more precision that actually exists. A compass reading even from a DistoX2 is probably accurate to only +/- 2 least significant digits. https://en.wikipedia.org/wiki/Significant_figures[1] However, you have an excellent point about easting and northing data. Those number can be measure accurately to enough significant digits that a double-precision data type is needed. Speed is not an issue. Survex and Therion both compile my biggest maps in seconds. Shaving a few seconds is of little benefit. And to your last comment about furlongs ... LOL! I remember a huge argument some years ago about what the speed of light is in furlongs per fortnight. It was a hoot! Thanks! ======== Bill Gee On Monday, December 27, 2021 3:56:04 PM CST Olly Betts wrote: > On Sat, Dec 25, 2021 at 08:50:26AM -0600, Bill Gee wrote: > > 1) Does Therion also recognize the BACKTAPE data type? > > It seems not - there's no match in the source code repo for: > > git grep -i BACKTAPE > > > 2) What does Survex do if both TAPE and BACKTAPE are given? Does it > > average the two readings? Does Therion do the same thing? > > Survex warns if they differ by more than 3 standard deviations, and then > takes the mean of the readings. > > > I understand that Therion will use Survex to reduce the centerline > > data - if Survex is installed. In case Survex is NOT installed, then > > Therion reduces the centerline itself. As a result they might handle > > this situation differently. > > Also, Therion generates a .svx file behind the scenes, but not > necessarily the .svx file you'd write yourself given the same data. > For example, I think Therion collapses backsights to a single reading > itself before processing with Survex. > > > As I write this, another related question occurred to me. When either > > Therion or Survex averages a forward and backward reading, how many > > significant digits does it carry in the calculation? Can the > > significant digits be changed? > > Survex uses double precision for this: > > https://en.wikipedia.org/wiki/Double-precision_floating-point_format > > That has 15-17 significant decimal digits - i.e. many more than matter > here. > > Using more precision seems overkill. > > If you really want to use fewer it should be possible to build cavern > to use single precision, but I don't think anyone actually does this. > We made it an option as decades ago it seemed you might want to do this > to reduce memory usage (4 bytes per floating point number instead of 8) > but cavern's memory use is very modest by modern standards, and single > precision only gives 6-9 significant decimal digits, which isn't even > enough to reliably store a UTM Northing to the nearest metre so you'd be > limited in what coordinate systems you could use in such a build. > > I don't see why you'd want to be able to dynamically force rounding to > fewer significant figures - what's the benefit? > > Downsides of rounding are it would slow things down a bit, and it risks > introducing systematic biases - a dumb example to make the issue > clearer: if all readings are to the nearest inch and you round the > average to the nearest inch and always round 0.5 up, then then assuming > an even distribution there's an average bias of +0.25 inches on each > tape reading. The problem with systematic biases is they accumulate > rather than tending to cancel. > > There are other rounding schemes which try to address this sort of > issue (like rounding 0.5 to the nearest even number) but it's hard to be > certain they might not introduce a more subtle bias (some cave systems > have dominant direction passage develops along so the distribution is > may not uniform across odd and even) and there doesn't seem a compelling > reason to be rounding in the first place. > > > And the same question applies to loop closure calculations. How many > > significant digits are carried through the calculations? > > The same. > > The final results are then stored in the .3d file to the nearest cm > (that's 0.000049710 furlongs for our US readers). That precision was > chosen so that coordinate values will fit in a 32 bit integer, and seems > adequate for the final results. > > Cheers, > Olly > -------- [1] https://en.wikipedia.org/wiki/Significant_figures -------------- next part -------------- An HTML attachment was scrubbed... URL: From olly at survex.com Tue Dec 28 00:59:49 2021 From: olly at survex.com (Olly Betts) Date: Mon, 27 Dec 2021 23:59:49 +0000 Subject: [Therion] Handling of tape and backtape in survey data In-Reply-To: <78128087.vtJHq7cr8S@main2.billgee.local> References: <1820748.6CsIbPlgNm@main2.billgee.local> <20211227215604.GR2728@survex.com> <78128087.vtJHq7cr8S@main2.billgee.local> Message-ID: <20211227235949.GT2728@survex.com> On Mon, Dec 27, 2021 at 05:04:20PM -0600, Bill Gee wrote: > My question about significant digits is really related to how much > precision can and should be carried through a calculation. If compass > readings are taken to four significant digits, then the mean of two > such numbers is really only good to about three and a half significant > digits. That seems wrong to me - we expect the mean to have *better* accuracy than the individual readings (otherwise one would want to avoid averaging readings!) Assuming independence (which may not an entirely valid assumption here admittedly) and that both readings have the same standard deviation x, then the s.d. of the mean of 2 readings is x/sqrt(2) - or about 0.707*x. I think that means you actually would expect to gain log(1/sqrt(2))/log(1/10) or about 0.15 decimal significant digits from taking the mean of two readings. (And it's 1/sqrt(n) for n readings, so if you average 100 independent readings then you'd expect to gain a whole decimal significant digit.) > Displaying more significant digits implies more precision > that actually exists. Right, but that argues for suitably presenting reported values, not for rounding intermediate values during the calculations. > A compass reading even from a DistoX2 is > probably accurate to only +/- 2 least significant digits. > > https://en.wikipedia.org/wiki/Significant_figures I'm not quite sure what "2 least significant digits" means, and that wikipedia page doesn't seem to help. But I think I get the gist, and indeed any instrument will have a limit to its accuracy, especially so for anything you'd be likely to consider taking underground. Cheers, Olly From bruce at tomo.co.nz Thu Dec 30 09:43:25 2021 From: bruce at tomo.co.nz (Bruce Mutton) Date: Thu, 30 Dec 2021 21:43:25 +1300 Subject: [Therion] Handling of tape and backtape in survey data In-Reply-To: <250e1123-8561-476c-c13c-69d96e293116@ntlworld.com> References: <1820748.6CsIbPlgNm@main2.billgee.local> <890B2E35-B532-438C-9CD8-A75277E656E9@caver.plus.com> <250e1123-8561-476c-c13c-69d96e293116@ntlworld.com> Message-ID: <000001d7fd59$509a11b0$f1ce3510$@tomo.co.nz> > instead Toporobot just generates a new station for the backsite. PocketTopo automatically detects backsights if they are taken immediately after a foresight. So the software handles the station naming, no user intervention required. While I processed the only survey I ever did this way with Therion, it never made it into the main cave dataset and so I didn't get as far as checking the survey length was correct (or doubled). I'm pretty sure it would be correct though. It was only done to find a reasonably precise gap in an 'almost looped' passage. The gap was too big to dig so we lost interest and I haven't drawn the enhanced accuracy map yet. It is at the bottom of my priority list. The exercise was also helpful to gauge the frequency and size of foresight/backsight mismatch with 'three-shot' disto readings. My conclusion: a few instances that may be of interest occur, but not enough to ever bother actually taking all those backsights. Have never done a backsight since. Our disto driven loop closures are typically 0.5% (I like to think) but a bad one will be 1.0%. Compared to our pre-disto loops over a decade ago which were typically 2% and a good one 1%. Although I prefer to think in Survex's standard deviation approach to loop closure, which tells a different story about which loop is good and which not... Bruce From lists at group-s.sk Thu Dec 30 18:32:17 2021 From: lists at group-s.sk (Stacho Mudrak) Date: Thu, 30 Dec 2021 18:32:17 +0100 Subject: [Therion] Handling of tape and backtape in survey data In-Reply-To: <000001d7fd59$509a11b0$f1ce3510$@tomo.co.nz> References: <1820748.6CsIbPlgNm@main2.billgee.local> <890B2E35-B532-438C-9CD8-A75277E656E9@caver.plus.com> <250e1123-8561-476c-c13c-69d96e293116@ntlworld.com> <000001d7fd59$509a11b0$f1ce3510$@tomo.co.nz> Message-ID: Thanks Bill for pointing that out. BACKTAPE/BACKLENGTH reading support was added to therion in the latest commit. S. On Thu, 30 Dec 2021 at 09:44, Bruce Mutton wrote: > > instead Toporobot just generates a new station for the backsite. > > PocketTopo automatically detects backsights if they are taken immediately > after a foresight. So the software handles the station naming, no user > intervention required. While I processed the only survey I ever did this > way with Therion, it never made it into the main cave dataset and so I > didn't get as far as checking the survey length was correct (or doubled). > I'm pretty sure it would be correct though. It was only done to find a > reasonably precise gap in an 'almost looped' passage. The gap was too big > to dig so we lost interest and I haven't drawn the enhanced accuracy map > yet. It is at the bottom of my priority list. > The exercise was also helpful to gauge the frequency and size of > foresight/backsight mismatch with 'three-shot' disto readings. My > conclusion: a few instances that may be of interest occur, but not enough > to ever bother actually taking all those backsights. Have never done a > backsight since. > Our disto driven loop closures are typically 0.5% (I like to think) but a > bad one will be 1.0%. Compared to our pre-disto loops over a decade ago > which were typically 2% and a good one 1%. Although I prefer to think in > Survex's standard deviation approach to loop closure, which tells a > different story about which loop is good and which not... > Bruce > > _______________________________________________ > Therion mailing list > Therion at speleo.sk > https://mailman.speleo.sk/listinfo/therion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce at tomo.co.nz Thu Dec 30 21:34:35 2021 From: bruce at tomo.co.nz (Bruce Mutton) Date: Fri, 31 Dec 2021 09:34:35 +1300 Subject: [Therion] Handling of tape and backtape in survey data In-Reply-To: <000001d7fd59$509a11b0$f1ce3510$@tomo.co.nz> References: <1820748.6CsIbPlgNm@main2.billgee.local> <890B2E35-B532-438C-9CD8-A75277E656E9@caver.plus.com> <250e1123-8561-476c-c13c-69d96e293116@ntlworld.com> <000001d7fd59$509a11b0$f1ce3510$@tomo.co.nz> Message-ID: <000001d7fdbc$a9b8d2a0$fd2a77e0$@tomo.co.nz> I just checked on my little experiment of some years ago, and I misrepresented it. > PocketTopo automatically detects backsights if they are taken immediately after a foresight. So the software handles the station naming, no user intervention required. That much is true. You end up with something like: 1.4 splays 1.4 1.5 shot 1.4 1.5 shot 1.4 1.5 shot 1.5 1.4 shot # for back shots it will recognise 1 or more shots within tolerance as 'back legs', so you can do as many as you want, I think 1.5 1.4 shot 1.5 1.4 shot 1.5 splays 1.5 1.6 shot etc >While I processed the only survey I ever did this way with Therion... Not true. I did not bother parsing the data from PocketTopo, as the passage ends were too far apart to consider digging, and so no point to mapping with Therion (we already have an older map). Never the less, I am almost curious to see what TopParser and Therion does with it. Lots of loops and doubled survey length I expect. Maybe I will process it one day. Tarquin You mention that SexyTopo deals with this by treating the backsight as a splay. Does it detect and label this splay as a backleg if it is within tolerance for the previous leg? I think it should (similarly to PocketTopo). While I don't tend to use backsights as a rule, there is that 1 in 100 occasion where I do consider it, and I expect that the field software should automatically detect this and number the shot/leg accordingly. In a generic sense, rigorous foresight//backsight/splay is a valid survey protocol (along with variations of that). Bruce