Re: [Therion] Turning LIDAR point clouds into cave maps
> Has anyone in the group taken the point cloud from an Apple LIDAR scan and > turned it into a Therion cave map? If so, I am very interested in the > details of the process. As Tarquin said Jono Lester has been main UK pioneer on this. He may send a response. Julian Todd will say that you are asking the wrong question, and the right thing to do with a point cloud is use it to draw a 3D simplification rather than try to convert it to a traditional 2D simplification. His tunnelVR software lets you do this. Not everyone is convinced of this argument, but tunnelVR is well worth a look: https://sidequestvr.com/app/1630/tunnelvr https://www.youtube.com/watch?v=vOktKq0c7BY Wookey -- Principal hats: 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] Change default PDF output font
On 2023-09-05 23:15 +1200, Paul Rowe wrote: >This will be really handy as our Māori alphabet includes accented >characters unavailable in the default non-Unicode set. Maybe the default therion font should be set to a unicode one so it works for more people/languages/countries? That seems sensible at this point. Pretty-much everyone should have unicode fonts avaiable and working, shouldn't they? Wookey -- Principal hats: 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] Invalid length reading error reported due to (valid) scrap definition
On 2023-08-07 08:38 +0200, Benedikt Hallinger wrote: > Hm, I'm not sure this will trigger a lot of false positives in some of my > projects, where structure is heavily divided into smaller files which are > inputted to form a whole complete. Right. centreline doesn't have to be balanced on a per-file basis. Survey structure and file structure are independent in Therion same as they are in survex. > When an encenterline is missing somewhere, this is some sort of unbalanced > braces problem like in a C compiler; so mabye therion should output at the > end that there is unbalanced centerline/endcenterline numbers (or all other > such structures, in this regard) in the input data. Right if it errored on unbalanced start/end primitives and said which files were unbalanced that should narrow it down enough to find the mistake (because on most projects most files will be balanced?). I'm not sure if there is a better interface/algorithm? Wookey -- Principal hats: 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] Mapiah and WTherion
On 2022-09-14 21:11 +, Rodrigo Severo via Therion wrote: >Development of Mapiah has halted. That's a pity. >After some talks during the last ICS, the idea seems to be to convert >WTherion to a Electron app and further develop it. Both the electron-baed apps I use have a fundamental problem: select and paste does not work (either in or out). (i.e. It does not correctly deal with unix/X two different cut buffers.) This would be a serious problem for Therion use IMHO. I presume this can be fixed but I'd recomend checking that before going too far down this road. If this is something fundamental in the design of electron (or upstream refuse to fix it for some reason) then we still need some other solution for desktop use. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Tunnel to therion conversion
Has anyone done any work on the task of converting existing Tunnel sketches (xml) to therion .th2 files? CUCC (Cambridge Loser expeditions: https://expo.survex.com) has a huge investment of tunnel drawings (55km of cave?), but because there are no elevations for any of this and Tunnel is a bit niche we are pondering using therion more. If a semi-automated conversion of the existing drawings was possible, that would help enormously. It seems like it shouldn't fundamentally be too hard to turn xml lines/beziers into therion lines/beziers, and map the line types, but there are issues with how to allocate lines to files and how to get the scaling right. I've not done anything at all about it yet, but thought I'd check if anyone else had before having a proper look. Thoughts? Wookey -- Principal hats: 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] Problem with new default settings and recent proj changes
On 2022-04-26 12:40 +0200, Benedikt Hallinger wrote: > Besides that, I cant compile due to missing deps. > Does someone already have info on what debian packages i need to install? The list in https://sources.debian.org/src/therion/6.0.6-1/debian/control/ should be sufficient, unless some new dependency has been introduced by 6.06 Build-Depends: dpkg (>=1.16.2), debhelper, debhelper-compat (=13), perl (>= 5.5), tcl, libvtk9-dev, libwxgtk3.0-gtk3-dev, libfreetype6-dev, libjpeg-dev, libpng-dev, pkg-config, texlive-base, libproj-dev, libsqlite3-tcl, python3, libshp-dev, catch2, cmake, ninja-build, libfmt-dev Build-Depends-Indep: texlive-metapost, imagemagick, ghostscript > -L/usr/lib/x86_64-linux-gnu/mit-krb5 -lproj -lpthread -lstdc++ -lm -lsqlite3 > -lm -ldl -lz -lpthread -ltiff -lwebp -lzstd -llzma -ljbig -ljpeg -ldeflate > -lz -lm -lcurl -lnghttp2 -lidn2 -lrtmp -lssh2 -lpsl -lssl -lcrypto -lssl > -lcrypto -lgssapi_krb5 -llber -lldap -llber -lzstd -lbrotlidec -lz -pthread > /usr/bin/ld: cannot find -lnghttp2: Datei oder Verzeichnis nicht gefunden > /usr/bin/ld: cannot find -lidn2: Datei oder Verzeichnis nicht gefunden > /usr/bin/ld: cannot find -lrtmp: Datei oder Verzeichnis nicht gefunden > /usr/bin/ld: cannot find -lssh2: Datei oder Verzeichnis nicht gefunden > /usr/bin/ld: cannot find -lpsl: Datei oder Verzeichnis nicht gefunden > /usr/bin/ld: cannot find -lgssapi_krb5: Datei oder Verzeichnis nicht > gefunden > /usr/bin/ld: cannot find -llber: Datei oder Verzeichnis nicht gefunden > /usr/bin/ld: cannot find -lldap: Datei oder Verzeichnis nicht gefunden > /usr/bin/ld: cannot find -llber: Datei oder Verzeichnis nicht gefunden This does seem to be a pile of new dependencies: libnghttp2-dev, libidn2-dev, librtmp-dev, libssh2-1-dev, libpsl-dev, libkrb5-dev, libldb-dev, lidldap-dev. Put that lot in and it should build. Is that all from libproj's online download facility? ssh, kerberos, ldap, real-time streaming? Seems excessive. Wookey -- Principal hats: 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] My take on a new Therion map editor
On 2022-01-15 15:40 +0100, Csongor Zih wrote: > >I'm a university student and I decided to try and make an XTherion >replacement as a short term project. You wait 10 years for a new therion editor and then 3 come alaong all at once! It's like buses. :-) Good work, I'll take a look with interest. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Therion chat space (matrix)
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/ signature.asc Description: PGP signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Presenting Mapiah, a multi-platform, more friendly, modern and performant graphical interface for Therion
On 2021-11-14 23:42 +, 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/
signature.asc
Description: PGP signature
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Get shortest route
On 2021-11-28 21:33 +, Tarquin Wilton-Jones via Therion wrote:
> > I implemented such functionality (not the visualization) a while ago
> > as a little exercise in Python. If you know how to run a Python
> > script, then you might find this useful.
>
> Awesome!
That is nifty. I've wanted this functionality quite often too.
> I would love for that to be built in to Aven, so it could actually
> highlight the route too (you know the problem, you give someone an inch
> they ask for a mile).
It's probably not that hard to do. The UI will be more work than the
routing. Of course what we really want is to apply normal routing
algorithms to the cave network (the graphhopper library is my
favourite as it's fast enough to make routing dragable), and include
weighting metadata so we could do somthing slightly more sophisticated
than 'shortest'. ('quickest', and 'least gear' are probably
useful). Being able to have dragable routing with timings (and maybe
tackle lists one day!) would be very nice, but relies on a lot of
metadata being available sonehow that currently isn't.
https://wiki.openstreetmap.org/wiki/GraphHopper
Annoyingly it seems not to be packaged yet. That can be fixed.
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] new Therion 6.0.3
On 2021-10-03 12:20 +0200, Therion via Therion wrote: > 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. This builds, but doesn't install, on debian unstable. Something is wrong with the new help file stuff: The issue is ninja tries to install build/loch/help/en/loch.htb but it hasn't been built. I'm not sure if this is windows-specific like the old help files loch.chm or if this should be present on linux? Either way it should be built-and-installed or not-built-and-not-installed (or even built-and-not-installed). From log: dh_installdirs -O--buildsystem=cmake\+ninja -O--builddirectory=build install -d debian/therion/etc debian/therion/usr/bin debian/therion/usr/share/doc/therion debian/therion/usr/share/doc/therion/examples debian/therion/usr/share/therion debian/rules override_dh_auto_install-arch make[1]: Entering directory '/home/wookey/packages/therion/therion-6.0.3' dh_auto_install install -d /home/wookey/packages/therion/therion-6.0.3/debian/tmp cd build && DESTDIR=/home/wookey/packages/therion/therion-6.0.3/debian/tmp LC_ALL=C.UTF-8 ninja install [0/1] Install the project... -- Install configuration: "None" -- Installing: /home/wookey/packages/therion/therion-6.0.3/debian/tmp/usr/bin/therion -- Installing: /home/wookey/packages/therion/therion-6.0.3/debian/tmp/usr/bin/loch CMake Error at loch/help/cmake_install.cmake:46 (file): file INSTALL cannot find "/home/wookey/packages/therion/therion-6.0.3/build/loch/help/en/loch.htb": No such file or directory. Call Stack (most recent call first): loch/cmake_install.cmake:63 (include) cmake_install.cmake:69 (include) FAILED: CMakeFiles/install.util cd /home/wookey/packages/therion/therion-6.0.3/build && /usr/bin/cmake -P cmake_install.cmake ninja: build stopped: subcommand failed. reproduce with: sbuild -d unstable -A -s One other thing: I also noticed the source incudes extern/img.patch. I think that's superfluous - it's been applied. That should presumably just be removed. 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
[Therion] Linux xtherion will not load thconfig
There is a bug in xtherion 5.5.7, at least in the debian build I am using (therion 5.5.7ds1-2). If you try to open a thconfig file, you get an error: "thconfig.thcfg does not exist". Fortunately you can run 'xtherion thconfig' and that works, otherwise xtherion would be completely broken unless you renamed all your thconfig files. This seems a fairly fundamental bug - I'm surprised it's not come up before. This is now in the version in Debian stable, so people will be getting it for the next 2 years, which is somewhat embarassing. Hopefully we can declare it bad enough to get a fix in. I've not looked into the code yet for a fix, but can someone confirm this is not just me? -- Wookey ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] cannot load thconfig in xtherion
If you run xtherion then try to load a thconfig file you get this error: /thconfig.thcfg does not exist It works if you run xtherion thconfig (or otherwise specifying the correct path to the thconfig file) So something in the codebase seems to have decided that thconfig files must now be called thconfig.thcfg or thconfig.thconfig. This seems quite broken. -- Wookey ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] new Therion 5.5.7
On 2021-02-06 10:01 +0100, Therion wrote: > Hi, there is a new release 5.5.7 of Therion. Uploaded to debian unstable. Built on all arches. 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] Splays appearing when not selected
On 2021-01-27 08:59 +0100, Benedikt Hallinger wrote: > I just did apt-get update, and see 5.5.6ds1-5 > > That is the old version, right? I do wait for 5.5.6ds1-6 ? No 5.5.6ds1-5 is the latest, including the fix discussed inthis thread. There isn't a -6 (yet) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Splays appearing when not selected
On 2021-01-24 14:40 +0100, Benedikt Hallinger wrote: > Wookey, when is this expected to appear in testing? > I would test it It's there now. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Splays appearing when not selected
On 2021-01-24 14:40 +0100, Benedikt Hallinger wrote: > Wookey, when is this expected to appear in testing? Follow the status on the tracker page: https://tracker.debian.org/pkg/therion (only updates every few hours, so right now shows only the previous version) It should happen approx 48 hours from now if all goes well. The last architecture (mipsel) is just building now. https://buildd.debian.org/status/package.php?p=therion > I would test it Thanks, that is very useful (to make sure I didn't screw anything up) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Splays appearing when not selected
On 2021-01-23 11:34 +0100, Stacho Mudrak wrote: >Hi Axel, >these big numbers are just NaNs in fact. It does not affect any output - >it just means the map has no altitude associated with it. But thanks for >finding out, I have tried to fix it in the latest commit, could you please >try? I've included this fix (and the other minor one you did) in the debian package (as 5.5.6ds1-5). It turns out that updates to non-core packages (which definately includes Therion :-) are actually allowed until 12th Feb, not 12th Jan so it should still make it the next stable release. It looks like this stable release of therion should be in quite good shape. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] new Therion 5.5.6
On 2021-01-07 21:42 +0100, Stacho Mudrak wrote: >Thanks a lot, Xavier. >You are right, this fix introduced another (much more serious) bug. It >should be fixed in54ea382. OK. Debian updated again. 5.5.6ds1-4 (-3 had the previous broken fix). -2 is already in stable. 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] Therion 5.5.5 bug - statistics missing from header
On 2020-12-26 17:26 +0100, Benedikt Hallinger wrote: > GLX issue seems to be fixed in the debian package! OK. Good. That means that it is indeed fixed for everyone because I removed the original debian-specific fix. 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] Therion 5.5.5 bug - statistics missing from header
On 2020-12-23 15:06 +0100, Benedikt Hallinger wrote: > Ok wookey, will check that regarding the glx Patch issue then. > > > Am 23.12.2020 um 14:26 schrieb Wookey : > > > > On 2020-12-23 10:42 +0100, Stacho Mudrak wrote: > >> I am sorry, one bug fixed, another introduced :/ > >> It should be OK in 5a614ef. Windows binaries should be automatically > >> built > >> within half an hour. > > > > And the Debian packages are now built in unstable. They should move into > > testing in 5 days time. Therion 5.5.5 is now in debian testing (for testing :-) https://tracker.debian.org/pkg/therion 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] Therion 5.5.5 bug - statistics missing from header
On 2020-12-23 10:42 +0100, Stacho Mudrak wrote: >I am sorry, one bug fixed, another introduced :/ >It should be OK in 5a614ef. Windows binaries should be automatically built >within half an hour. And the Debian packages are now built in unstable. They should move into testing in 5 days time. 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] Converter for Compass to Therion
On 2020-12-20 11:44 +0100, Roger Schuster wrote: > Hello cavers, > > for those of you who either use the "Compass" cave surveying package > together with Therion or need to convert legacy data from Compass there is > something to try out. I wrote a little converter that transfers Compass raw > data (*.dat) to Therion (*.th). You can find a description and the source > code at > > <https://github.com/rogerschuster/compass2therion> That's great Roger (so thanks for doing that), but I wonder if you are aware of 'caveconverter' which already does compass to Survex amongst a selection of other formats (survex, and toporobot out, compass, survex, pockettopo and DXF in). http://wscc.darkgem.com/caveconverter/ It is also java, and it's really better to have one versatile converter than lots of separate ones, so I don't know if I could persuade you to take a look and see if you can merge your code into caveconverter because 'therion output' is the main thing it is missing and you've done that? This may be too much like hard work, but I feel the caving world would benefit if it was done, and it may actually be quite easy. 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] new Therion 5.5.4 on debian
On 2020-12-16 18:45 +0100, Stacho Mudrak wrote: >VTK9 should be OK, no need to use older versions. Done. Therion is stuck waiting for current vtk package to transition to testing, and both are stuck because the mipsel buildds can't keep up but it should be OK in a week or so. >Exception catching has been removed from samples intentionally. We use >them as a series of tests when implementing a CMake build system. I did >not know, that samples are built on Debian. We've been doing that for many, many years as it provides some useful local documentation (although, checking, I see that the resolution of some of the images is too low to be useful). I chose not to use cavern so that the back-up calculation system in therion got tested. That seemed more appropriate for the therion build. It also simplified the build-dependency tree a little. >There is an option to have generated .3d files also present in the >samples. But adding cavern as a build-dependency seems to me as a better >idea in any case. And using it for the loop closure. OK. But then the therion back-up functionality may hardly ever get tested? Now that we have autopackage tests (tests run after the build on the installed packages), I guess we could run some tests both with and without cavern installed (maybe - not sure if we have that level of control). But we don't have the sample sources available to run a runtime, only at build-time. Using cavern is the 'normal' case so maybe it's better to do that at build-time too. I'll try it. 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] Italian translation update
On 2020-12-16 23:23 +0100, Fra wrote: >Hello everyone, >I recently started using Therion and I noticed that the Italian >translation has some typos and it was probably not updated for quite a >while. >I updated the /thlang/texts.txt file, is there a way to get permissions to >push it with git? Or else can I just send the updated file to anybody so >it can maybe be included in the next update? You can just send it here and someone will sort it out. You should really also translate loch too, which needs a new loch/locales/it/loch.po file. The easiest way to create that is run poedit (you need the poedit package installed) and click on 'create new translation', load up another (e.g the english one) and ask to create 'italian'. Then fill in the translations and save. and send us the resulting loch.po file. You can do all this by hand but the tool makes it easier unless you are familiar with the process. 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] Trouble compiling latest therion code in Linux (Ubuntu 20.04)
On 2020-12-15 17:17 +, Rodrigo Severo via Therion wrote: > >Hi Martin, >Using the above file as reference, I used make config-debian instead of >make config-linux that I was using before. >Everything compiled just fine now. As you found, you need config-debian, not config-linux, to build on debian, and I'm glad to hear it does still work as it's a long time since it had any attention. But there are quite a few changes in the kosher debian packages to make sure things like security flags are set, files are stored in the right paths, system libraries are used, docs are referenced. Here is the list: https://sources.debian.org/src/therion/5.5.4ds1-1/debian/patches/ In general you are better off building the packages than the bare upstream releases unless you really need to for development. 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] new Therion 5.5.4 on debian
On 2020-12-15 18:32 +0100, Therion wrote:
> Hi, there is a new release 5.5.4 of Therion.
OK. I have updated the debian patches for this release. Mostly
straightforward, and I see the build has been made a little less
baroque in various places, which is good :-)
makeinstall.tcl changing its behaviour to use $DESTDIR and make it's
directories was a little surprise, but easily sorted and a cleaner
rules file.
I see there is now vtk9 support (since 5.5.2). Debian has vtk9 now
(in unstable and testing). Do we get useful things for building
against vtk9 rather than vtk7?
We'd need to use vtk7 (or vtk6) in backports but as vtk is just for
the loch gui and image processing I can't see why different versions would
matter.
Both vtk7 and vtk9 seem to work. I guess we should move on so I'll
move to vtk9 unless someone can think of a good reason why not.
One oddness:
samples/samples.tcl has had the catch stanza commented out in proc
process_files {}
#catch {
eval "exec $p >&@ stdout"
# eval exec "cmd /c $p"
#}
What's that about? It looks like debugging that accidentally got into
the release? The effect is to prevent the samples build from
completing unless cavern is actually installed. I could make cavern a
build-dependency, but we never have before, and if I just put it back
then the samples build as usual (so that's what I've done for now).
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] Creating PDF/A map files
On 2020-10-22 08:17 -0500, Bill Gee wrote: >The new feature I propose is to modify the PDF creation code so that it >produces files that are PDF/A version 1b (or possibly version 2) >compliant. >https://en.wikipedia.org/wiki/PDF/A Therion would need to use PDF/A-2 because we need tranparency (I think). And whilst this is mostly sensible why on earth do they think banning LZW compression is a good idea? That's probably why your file expanded from 4 to 52MB. The last patents on it expired in 2004 and free implementations have been available for decades. If it wasn't for that we could have made it a standard output format (because self-contained files are a very good thing, and I'd expect my therion PDFs to already have this property). We can gzip the files after creation but a foo.PDF.gz is a lot less handy than a foo.PDF with internal compression. 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
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] Therion uses wrong declination for surveys 'in the future'
On 2020-10-06 21:10 +0200, Martin Budaj wrote: >On the other hand: is there any need to use the data older than 1900? If >yes, we could implement the GUFM1 model covering the period 1590–1890. We've had to use data back to about 1910 in Ireland but I'm not aware of anyone needing to go back before 1890. I'm not sure if there is/was any conventional cave survey data that old. I reckon we are safe to carry on ignoring it until someone asks. >You can't always avoid mixing dated and undated surveys (sometimes the >older survey data might be undated), so using the min(survey_dates) as a >proxy for undated surveys (and producing a warning as well) should be a >reasonable approach. Very good point. We have a lot of data imported from other programs which ends up with no date. And fake data generated from existing survey plots also ends up dateless. This is definitely a thing. > Ideally it would compile one in but have the ability > to read a newer file if provided. But then someone has to write a > parser. > >Not sure if writing the parser is worth the effort, as AFAIK all the real >issues with the declination come from the incorrect handling of >undated/out-of-range data, not from an outdated model. >Even a model outdated 10 or 15 years should provide very reasonable >results. Agreed. > We could also try a little harder not to get 10 years behind > again. (5.4.4 was released in May 2019 with a model that expired in > mid 2020, when the 2025 model had been available since 2015 (and was > included with the next therion release in May 2020). Not sure why the > update was not to 2030 as that was available from Dec 2019.) > >There was actually no 2025 model available since 2015. The models are >always for 5-year predictions and there is zero overlap between them. Just >to illustrate, here is an overview of the history of publication of IGRF >models and their inclusion into Therion Cheers for the corrections. (and for the quick fixes). 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] Therion uses wrong declination for surveys 'in the future'
On 2020-10-05 23:54 +0200, Matthias Keller wrote: >Exactly this. > >Unfortunately, even the current Therion 5.5.1 doesn't have a more >meaningful (and correct) message than "unable to determine magnetic >declination for undated surveys" I thought this might be a proj confusing error message, but it is therion's. >I would propose: > > 1. If a survey is dated but is newer than available correction data, >build should fail with a message like: >"Error determining magnetic declination for survey with date >. Please specify the declination explicitly using for example >'declination 3 deg'" >instead of the (completely wrong) >"unable to determine magnetic declination for undated surveys" > 2. If at least one of the imported (and thus joined) surveys has magnetic >data but at least one does not (or cannot be determined), an error >shall be thrown as well, because mixing corrected and uncorrected >surveys is just plain wrong and causes a lot of confusion (as it has >happened to me). The same error message shall be displayed and the >build fails. This does seem reasonable behaviour. And I agree the error message is wrongly worded or issued here. I just had a look at the code that produces this error but it's rather confusing. A bitmap is used to record what declination data was used and if bits 1 and 3 are set you get the above error. I think bit 2 is 'used igrf model to get delination' and bit 3 is 'used defined declination', and bit 3 is 'didn't use any', but I'm not sure and I don't see why two bits would be set. I'll leave it to Martin/Stacho to work out how the logic should run here. >Is this the right place to request that or shall I open an issue on >github? I think this list is the canonical place to discuss such things. >I really find this issue pressing, because I just cannot imagine, that >this doesn't happen to everyone here from time to time - keeping therion >up to date is not the same cycle as adding new surveys, and suddenly you >fall out of the prediction data. This is really an issue of the geomag model. It does work some way into the future, but there is a cutoff. Looks like it does 10 years into the future as the latest data in the therion source (igrf12) ends in 2015 and the previos igrf11 (used in therion 5.4.4) ended in 2010. igrf13 (with data to 2020) was released in December 2019 https://www.ngdc.noaa.gov/IAGA/vmod/coeffs/igrf13coeffs.txt So clearly this will arise anytime you have survey data 10 years newer than the model in the therion you are running, which as they are only released every 5 years and therion may take a year or two to update and the installed one may be a few years old, is quite likely to happen from time to time, especially in years ending with 0 or 5. >btw, is there any way to update the data in an existing therion >installation? Or is the only way the update to a (hopefully existing) new >version? There could be - the files are available online so therion could use the currently-installed version of the file. But currently the igrf coefficients file is compiled-in as thgeomagdata.h This means therion can always find the data, but it's not updateable without recompiling. I could fix this for linux relatively easily, but it's harder on Windows. (and it was making things work on windows that caused therion to compile-in all the stuff it needed from subsystems, many years ago). Ideally it would compile one in but have the ability to read a newer file if provided. But then someone has to write a parser. We could also try a little harder not to get 10 years behind again. (5.4.4 was released in May 2019 with a model that expired in mid 2020, when the 2025 model had been available since 2015 (and was included with the next therion release in May 2020). Not sure why the update was not to 2030 as that was available from Dec 2019.) 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] Building Therion on Centos 8 (stream)
On 2020-08-12 22:01 +0200, Martin Budaj wrote: >Hi, >check if you have libsqlite3-tcl (or equivalent) installed and working. >It's required for correct parsing of projection names from the EPSG >database. Is this a build-time only dependency or should it also be present at runtime? It gets pulled in on debian builds but I'm not quite sure why. It should perhaps be explicitly specified. Is this new or has it been true for years? 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] Survey without clino
On 2020-07-14 19:51 +0100, Tarquin Wilton-Jones via Therion wrote: > Note the spelling. There is a typo in the Survex docs. So there is. That must have been there for years. Patch filed. https://trac.survex.com/attachment/ticket/117/#ticket 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] Survey without clino
On 2020-07-14 18:28 +0200, Anton van Rosmalen wrote: > Hey guys, > > How do I enter survey data made without a clinometer. I'm not sure about therion, but as it uses survex the same rules usually apply. In survex you just specify that there are no clino readings, *data normal from to tape compass 1 2 3 160 2 3 3 143 3 4 3 180 4 5 3 165 or omit them with a '-' (the default 'OMIT' character) *data normal from to tape compass clino 1 2 3 160 - 2 3 3 143 - 3 4 3 180 - 4 5 3 165 - (The latter is more useful where some readings have a clino, but not all) The default vertical standard deviation used for such legs, if not otherwise specified "is taken to be proportional to the tape measurement" https://survex.com/docs/manual/datafile.htm (*data command, 'normal' description) I would assume that you can do this in therion too, but I've not checked. 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] new Therion 5.5.1
On 2020-07-03 22:02 +0200, Therion wrote: > Hi, there is a new release 5.5.1 of Therion. This has now been uploaded to Debian so is available in unstable. It should migrate into Ubuntu too in a few days. https://tracker.debian.org/pkg/therion Thanks to Martin for promptly fixing the libproj issue in 5.5.0. 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] For JM Begley - Rebuild for Fedora 32
On 2020-04-29 17:19 +0100, James Begley wrote: > Hi Bill, > > Unfortunately F32 has moved to proj v6, which has a number of fairly > significant changes associated with it. Therion support for proj v6 appears to > be a bit of a work in progress, but I'm trying to pick out the commits that > are > required to get it working. It might take a few days though :( Debian has this patch which may be relevant: https://sources.debian.org/src/therion/5.4.4ds1-5/debian/patches/fix-proj6-use-proj4-init-rules.patch 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] Getting started with Therioning a trad survey
Forwarding some queries as I only know the answer to 1 out of 4 :-)
On 2020-03-29 02:25 +0100, Stuart Bennett wrote:
> On 15/03/2020 17:30, Wookey wrote:
> > It uses survex to do all the sums if survex is installed (and both use
> > proj for the co-ordinate systems) so you should get exactly the same
> > answers. Without survex it does a rather simple-minded job on its own.
>
> Ok, so suddenly having a lot more time at home I've made reasonable
> progress, but have a few new questions. Various bits attached, should they
> be relevant to the below.
I don't know the answers to most of these, so forwarding to the therion list.
> 1) I'd quite like it to say P33 next to the pitch, rather than just `33',
> but using a `height' point type doesn't let me set a `value' including a
> letter. Is there a way to use what seems like the semantically correct
> type, or should I just use a label?
>
> 2) Having gone down the `import a .3d' route, I don't seem to get any dates
> in the output, despite the 3d file knowing them, which is a shame.
> Inserting a bogus centreline just to specify a date fails, as there's no
> measurements. Is there a neat way around this?
I think this is a feature, but it may be fixable.
> 3) The boulders are enormous. The ones you get with a `breakdown'-type
> point are much more suitable, but that defeats the point of having an area
> fill. Is there a way to scale the area fill symbols?
You want Andrew's 'fancy boulders' function. 'Customisable Area blocks' on
https://therion.speleo.sk/wiki/metapost
> 4) More generally, working with a survey drawn up in pencil over a Survex
> printout is ok, but if I'd drawn up digitally first, would the LRUD data
> have somehow been used/displayed automatically? Does using a .3d import vs
> transcribing to Therion native format affect this?
>
> Thanks, Stuart
> encoding utf-8
> import daves_hole.3d -surveys use
> survey dh -title "Dave's Höhle"
> input daves_hole.th2
> # date 2017.09.17
> # team SB insts
> # team OGHM/KIH notes,dog
> endsurvey
> encoding utf-8
> ##XTHERION## xth_me_area_adjust -132.0 -1368 1883 141.0
> ##XTHERION## xth_me_area_zoom_to 50
> ##XTHERION## xth_me_image_insert {0 1 1.0} {0 {}} daves_hole_scan.png 0 {}
>
>
>
> scrap scrap1 -projection plan -scale [709.0 -992.25 1654.5 -991.6
> 0.0 0.0 40 0.0 m]
>
> point 686.0 -595.0 archeo-material
>
> point 1301.0 -445.0 continuation
>
> point 616.75 -766.5 height -value 1
>
> point 648.0 -788.5 station -name 15
>
> point 615.0 -698.0 station -name 14
>
> point 848.5 -535.0 station -name 13
>
> point 458.0 -681.5 station -name 12
>
> point 564.5 -653.0 station -name 11
>
> point 436.5 -141.0 station -name 10
>
> point 504.0 -267.0 station -name 9
>
> point 833.0 -769.0 station -name 8
>
> point 946.5 -308.0 station -name 7
>
> point 1180.5 -725.0 station -name 6
>
> point 1284.0 -441.5 station -name 5
>
> point 1241.5 -479.5 station -name 4
>
> point 1026.5 -509.0 station -name 3
>
> point 1219.0 -571.0 station -name 2
>
> point 1350.5 -669.5 station -name 1
>
> line pit -id l17-1162--732 -close on -reverse on
> 1163.75 -734.25
> 1158.99 -733.3 1175.47 -717.75 1176.5 -717.5
> 1193.75 -713.25 1193.25 -722.0 1188.25 -729.25
> 1181.83 -738.56 1170.0 -735.5 1163.75 -734.25
> endline
>
> line floor-step -id l65-1266--488 -reverse on
> 1288.0 -489.5
> 1275.0 -489.75 1238.0 -486.0 1241.5 -467.0
> smooth off
> endline
>
> area blocks
> l85-925--470
> l20-859--786
> l57-842--770
> l20-859--786
> l63-758--730
> endarea
>
> line border -id l85-925--470 -subtype invisible
> 912.0 -716.0
> 970.0 -655.5 1012.64 -524.97 883.5 -431.0
> 777.0 -353.5 615.21 -361.72 582.0 -398.0
> 501.0 -486.5 597.5 -684.5 603.0 -733.5
> smooth off
> endline
>
> area blocks
> l17-558--678
> l65-1266--488
> l19-1314--500
> l20-859--786
> l83-1147--640
> endarea
>
> line border -id l83-1147--640 -subtype invisible
> 1175.0 -425.5
> 1175.0 -598.59 1142.0 -677.0 1075.5 -804.0
> smooth off
> endline
>
> line floor-step
> 628.5 -763.0
> 633.25 -750.25 642.75 -743.25 653.25 -743.25
> smooth off
> endline
>
> line ceiling-step -id l63-758--730
> 585.25 -700.75
> 615.0 -692.75 682.53 -679.87 691.25 -681.75
> 716.75 -687.25 773.0 -747.75 781.0 -754.0
> smooth off
> endline
>
> line ceiling-step
> 1339.5 -680.0
> 1406.6 -722.96 1433.75 -683.5 1362.0 -651.5
> smooth off
> endline
>
> line ceiling-step -reverse on
> 1284.25 -485.0
> 1272.25 -
Re: [Therion] New DEM data from NASA
On 2020-03-06 09:02 +0100, Benedikt Hallinger wrote: > I have a (german commented) bash script doing this. > Only thing is that it is hatdcoded fir a specific case, but it shows the > commands imvolved. > > Should i post it to you? Post it here. I doubt if Paweł is the only one interested. 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] Need metapost wizard: new text label
On 2020-02-26 23:47 +0100, Benedikt Hallinger wrote: > Hello, > meanwhile i tried to play more with this. > I'm nearly there, however i still have no clue how to read out the text > attribute i attached to the symbol in the th2. "txt := ATTR__text;" throws > metapost out the window. One underscore, not two. Here is an example that works: https://therion.speleo.sk/wiki/metapost#customisable_area_blocks_with_different_number_of_sides I'm no expert, so there may be some other issue, but that's the thing I noticed. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Breaking a loop at a specific station on extended elevation
On 2019-11-12 07:20 +1300, Bruce Mutton wrote: > I don't have a problem with the characteristic you mention in point 2. I > think it is just semantics associated with the word 'ignore', and sequential > process. If you think 'break' then is it all OK? We think it should be possible to specify 'break/ignore' at a point, rather than a point+direction (i.e. a leg/pair of points) We want the computer to worry about the 'direction' aspect, and feel we shouldn't have to. It seems like this should be possible. 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] Detecting errors
On 2019-08-15 11:50 +0200, Benedikt Hallinger wrote: > To expand a little in this, you could also use the standard „grade“ to tell > theriob which centerline data has which quality. We use this to mark the > centerlines we have surveyed with distox and traditional way and therion uses > this to put more of the errors towards the more bad survey. What SD numbers do you use for this? I agree they should be different, but I've not seen much research evidence on what the correct numbers are. Also SDs are about expected errors and do not cover blunder probability very usefully, which is also quite different for fully digital and paper-based surveying as well as for compass/clino/tape vs SAP or DistoX. You could adjust the SDs to allow for this, given that we don't have a better mechanism, but again - how do we choose the numbers? I have asked this before and not had useful answers. I have a re-survey project which has found a lot of errors in old (both compass/clino and distoX surveys). I'm struggling to work out what to do with the differences, but it's possible that some plausible blunder probabilities could be generated if enough resurvey is done. The main problem is that the resurvey is wrong too, just by a different unknown amount, and could itself contain blunders. In practice I found it really difficult to refind all the previous stations so the resurveys are not mostly leg-for-leg, just connected every so often. None of that helps much with the fact that survex does its sums as if there are only measurments errors, not blunders. 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] BreakOut 3D cave viewer
On 2019-06-26 07:10 -0500, Bill Gee wrote: > Update: > I tried it on Ubuntu 18.04 and debian stretch. It runs on both, but the file menu is hidden behind the display pane (so the 'Import' option is not visible (I managed to get it to appear a couple of times with some twiddling). I see it comes from Mr Edwards, who's 'dewalls' package I have already packaged (a dependnecy of cavewhere). Guess I'd better do this one too. > After much web searching, I think the problem on my laptop is not with > Breakout itself but rather with the display driver. Breakout requires GLX3, > but the Intel i915 display driver for my Lenovo Thinkpad T410 does not > provide that. It only provides GLX2. I'm using a thinkpad here with "Skylake GT2 [HD Graphics 520]" I guess that's a generation or two newer than an i915. > The two systems that work are running nVidia and VirtualBox display drivers. > I have not tried it with Nouveau. The nVidia display driver I use is the > kmod packaged driver from the Fedora repository. My Stretch machine is running nouveau. Seems to work the same (badly WRT menu visibility) as the intel driver) > Breakout Cave Survey Viewer duplicates much of the functionality > provided by Aven and Loch. The main new feature is searching. You > can tell Breakout to search for a particular survey station and it > will take you there. Aven has that already. Do you mean it is different in some significant way. I'll report the menu bug on the breakout github and do a bit of gentle packaging when I have some tuits. 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] Compass (.dat) to Therion (.th) converter?
On 2019-01-07 11:28 +, Footleg via Therion wrote: > You might also find the Cave Converter tool I wrote of some use. It doesn't > convert to Therion, but it can read Compass.dat and convert to Survex. The > survex files are not too difficult to then convert into Therion in a text > editor: > http://wscc.darkgem.com/caveconverter/ Hmm, that makes the man page out of date, which does not mention compass as an input format. Turns out that's my fault for not updating it to keep sync with the code. Just fixed and uploaded (to debian). ($someone really should update caveconverter to output (and input) therion so it could do survex<->therion conversion because it's not hard but boring by hand) /me knows no java so I have resisted trying. 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] Add Coordinate data back at last level of Survey Hierarchy?
On 2018-11-14 20:36 +, Olly Betts via Therion wrote: > On Wed, Nov 14, 2018 at 07:07:50PM +, Andrew Atkinson via Therion wrote: > > I've not had time to play with this, since Alistair showed me the problem > > on the weekend. The bit that I cannot get my head round is when 3d are > > imported with a coordinate system, if a th centreline then connects 2 parts > > of the survey from the 3d or an entrance coordinate is specified for the > > 3d, how does this change, or can it change the coordinates of the data from > > the 3d as the stations from this already has coordinates with little > > information about the connections [I hope that makes sense] > > Survex .3d files record the coordinate system the data is in, if one was > specified. This was added in Survex 1.2.14 (released 2014-07-05). Right, and that is metadata saying, effectively, 'the numbers in this file should be considered to be in a co-ordinate system starting at X,Y on the planet, oriented this way'. > But looking at the therion source code, it appears therion never makes > use of this information. I suspect therion just hasn't been updated for > Survex gaining coordinate system support. > > You can specify the coordinate system as an option to therion's import > command, so for now I guess that's what you have to do. Right, but (if I understand this correctly), that option does not change the numbers in the file. They must be valid for the cordinate system given in the import command. This info effectively says where the origin for the co-ordinates in the file are to be interpreted-as (and stuff about axis angles). So let's say that your survex data was processed in 'local' co-ordinates so it just starts from 0,0 in arbitrary 'nowhere' co-ordinates. What Alistair wants to do is read that in, but use it with therion data that is in real-world co-ordinates (UTM30N). The question is, can that be offset by some arbitrary number on reading-in so that it appears in the right place in the UTM30 co-ordinate system? Is a rotation needed too? Adding a rune to the line saying 'this is already in UTM30' will not have the desired effect, because data in UTM30 doesn't necessarily start from 0,0, and even if it did, his survey presumably needs to be at some other co-ord withint that space. The import -calibrate x y z X Y Z command looks like it should do the right thing, so long as the axes are aligned, by shifting from x y z to X Y Z. 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] Background zoom-level bug
On 2018-11-12 21:22 +1300, Bruce Mutton via Therion wrote: > On Monday, 12 November 2018 16:32 Wookey wrote: > > > There seems to be a bug in xtherion graphics editor revealed if you manage > > to enter a non-power-of-two zoom level. > > > > If you get into this state then the background image and the lines drawn on > > top of it go out of registration. > This bug has been around ever since mouse wheel zooming was introduced. An > attempt was made to fix it I recall, but it did not have the desired effect. > It manifests for bitmap background images, but not for xvi 'images'. Aha - this would explain why most of us had not noticed it before. People using a pockettopo->topparser->xtherion workflow would never notice this (no jpegs/gifs/pngs). 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] Topodroid import
On 2018-11-12 10:02 +0100, Evaristo Quiroga via Therion wrote: > Hi Wookey, > > Yours problems with the high density line segments are from the Setting > selection. > > In "Settings/Sketching/Lines/Lines style" you can select the segment density > type (Fine, Normal or Coarse). But it's better to use the Bezier option. OK, thanks, that's good to know. I'll pass it on to the user in question (who may or may not have got round to joining this list already). But if someone has done a survey like that (or maybe a whole expeditions-worth) then they would still like a reasonably easy way to convert it/them back to manageable lines. So I think the original question still stands: can we have a way to select more than one line at a time for such processing in xtherion. Or perhaps decide that the 'fine' setting in topodroid is no practical use, or should at least be advised against. What is the default setting for line segment density? 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
[Therion] Old version of Windows filer dialog
One issue reported was that the 'open' dialog in xtherion on Windows is now older than the 'normal' explorer one, so it doesn't support some handy things like being able to cut and paste a path. I'm not sure where the filer dialog comes from, but I guess it's wx? Perhaps this can't easily be fixed without an update in that library? If it can be updated it would be appreciated. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Background zoom-level bug
There seems to be a bug in xtherion graphics editor revealed if you manage to enter a non-power-of-two zoom level. If you get into this state then the background image and the lines drawn on top of it go out of registration. Here is an easy way to reproduce the problem. You will need a mouse with a scroll-wheel, and the latest 5.4.1 version of therion.. * Insert a jpeg into a new .th2 file in xtherion. * Draw a line over part of it. * Move it around and observe that the line moves with the background. This is true at all 5 fixed zoom levels. * zoom with the mouse scroll button as far out as possible. It seems to allow 12% for example. Now when you come back out you get 24%, 48%, 96% etc. * Now if you move the image around, the image and lines stay together until you have moved a bit, but then start to move seprately. This seems to be something to do with bounding boxes. * Click on 25/50/100/200/400 scaling the line+ images go back into registration. I can't reproduce this problem right now because my therion is too old, so the mouse wheel doesn't produce scrolling in the xtherion window, but we had the same problem on both Windows and Linux machines at the weekend with 5.4.1. If others can confirm that the above is a sufficient set of instructions, then hopefully someone with clue can work out why it goes wrong for 'intermediate' zoom levels. It took us quite a while to work out what on earth was going on at the weekend! Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Topodroid import
We just held a weekend of 'intermediate/advanced' digital surveying, largely about therion usage in the UK. Expect some questions :-) One thing that came up was export from topodroid. It exports directly into therion .th2 format, which is good, but the exported drawings have a very high point-density on lines. There are hundreds of small straight line-segments in even quite a short survey. A large survey is pretty-much unmanageable in xtherion as it goes so slowly with lots of lines. It is possible to select each line and use 'edit line' -> 'convert to curve' to greatly simplify each line, and after doing this things work much better, but this process is very tedious indeed. What would it take to be able to select 'all lines' and apply this transformation in one go, or, even better, could topodroid do this before export so a much smaller and more useful file is exported? Any other sugestions for making this less painful? 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] Therion ini linefeeds
On 2018-11-09 04:09 +, Olly Betts via Therion wrote: > On Fri, Nov 09, 2018 at 02:44:09AM +0000, Wookey via Therion wrote: > > The issue is the difference between Unix lineends, windows/DOS lineends and > > macos lineends. > > unix uses 0x0A (10), Macos Uses 0x0D (14) and DOS/Windows uses both > > (0x0D,0x0A). > > 0x0D is actually 13 not 14. Gah - I counted that out on my fingers and still got it wrong :-) > Pre-OS-X Macs used that, but modern macs use Unix-style line endings. That's progress :-) 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] Therion ini linefeeds
On 2018-11-05 10:27 +0100, Torsten Schnitter via Therion wrote: > Hi Bruce > > I'm using Windows 7 (64bit). > Normally and right now I just used a double click to open the ini files. > The default is notepad.exe to open these files. > This editor does not show the line feeds in a correct way. > > I now tested it with following programms: > - Visual Studio Code > - Notepad++ > - UltraEdit-32 > - Wordpad > All these programms show the line feeds in a correct way. > > In my opinion the file is OK. It's using 0x0D and 0x0A for a line feed (CR+LF) > which is the correct way as far as I know. Correct on DOS/Windows, not elsewhere, and it's actually probably just being shown like that, but not _actually_ like that on disc. > So the problem is obviously "Notepad.exe". Indeed it is (mostly). The issue is the difference between Unix lineends, windows/DOS lineends and macos lineends. unix uses 0x0A (10), Macos Uses 0x0D (14) and DOS/Windows uses both (0x0D,0x0A). Most editors can cope with this and will try to show you something that looks sensible on your screen whichever one it finds. i.e. any of those 3 combination will cause a new line (and the DOS version doesn't do _two_ new lines). If you think about it this is actually quite difficult to get right in all circumstances, and can only be done by 'translating' a file at load and save time from whatever convention it uses to 'native'. If a file ends up being 'half and half' Unix and DOS lineends then editors have almost no hope of showing things as originally intended, because they can't tell what is 'right'. Notepad is famous for being very old and rather stupid about this - it only shows DOS linefeeds correctly. It ignores the unix linefeed and thus puts unix-linefeed files all on one line. Not sure what it does if you give it a mac file. Version control systems also sometimes do this translation so that files 'come out right' wherever you checked them out, but they are still identical when checked back in/compared. The original therion.ini file is presumably unix linefeeds so notepad is showing it all on one line. That's expected behaviour, even if it's not very helpful. Upstream could try to make different lineends for all the files in the windows and unix and mac versions of therion, but that's work and could cause other difficulties. Mostly if you just avoid notepad because it's really very shit that's probably best. > May be it's a good advice not to use notepad.exe. ;-) That is indeed good advice. 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] Eurospeleo 2018
On 2018-08-23 07:40 +1200, Bruce Mutton via Therion wrote: > Might there be an electronic conferencing option for the cave survey > workshop? > (a bit late notice I know) Yeha, quite late notice. I'm running it, and am sympathetic to the idea - what sort of thing did you have in mind? We could connect you via https://meet.jit.si/surveymeetingeurospeleo, and you could contribute to the sessions. That should work for others hearing you if we connect to the AV, but you will not be able to hear much of us as it'll just be my laptop mic. It would need proper room mic discipline to make a remote connection work for 2-way discussion. I'm happy to run the session that way if there is a room mic available. We should probably test it beforehand otherwise it'll be a big faff. It's also 3pm local time so it'll be around 3am for you. Mail me offlist and we'll try a session beforehand. 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] SDs for distoX surveys
On 2018-08-05 08:44 +0200, Graham Mullan wrote: > I am not sufficiently versed in the maths to suggest what figures might be > used, but I do want to know why you think that the 3-times feature might > affect the expected error for the angles but not for the length? The 3-times thing greatly reduces blunders. Blunders are usually in compass and clino readings, rather than length readings. But you are right that the 3-times measurement improves all 3 readings (I assume that's what you were implying). Now the SD doesn't represent blunder frequency as it's really about expected mesurement error, but in practice we use it for blunder distribution too, so that's why a lower SD for surveys done this way makes sense to me. If we put in all three versions of the leg then we could leave the SDs the same, but that's not often done (depending how you get your data out of a distoX). Similar considerations apply to backsighted surveys, where both sets of readings _are_ normally entered. 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
[Therion] SDs for distoX surveys
Has anyone thought about what the correct SDs for distoX/distoX2 (as opposed to compass and tape) surveys are? I reckon distoX surveys have significantly lower expected error, due to the 'measure 3 times' leg feature (if used) and just higher accuracy due to instrument itself, ease of taking readings (no need to get head near station), and no difficulties with steep legs > 15 degrees. Seems to me this means that we should be using different SDs for these surveys (at least for bearing and inclination readings - length is not obviously more reliable), but I'm not sure how to quantify those improvements. Anyone got any ideas what numbers to use? 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] Complex model visualization with Aven, Loch, KML and Compass
On 2018-07-16 19:20 +0200, Evaristo Quiroga via Therion wrote: > Aven is a very powerful tool too. I like the easy and intuitive rotation > controls and Error visualization. I can show/hide Therion surveys. But a > can't show/hide the "Centerlines". You can show/hide centrelines. Presumably you mean you can only hide all or none? Last year it gained 'hide all but this one' feature, and just last week it gained 'show/hide each individual survey'. Does that help? (it certainly helps us) > All my centerlines have "id" and "title". > I can't choose a color by survey. You mean that you want to be able to 'display survey foo in '? Or display title in colour ? Or something else? 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] Therion and vtk7.1
On 2018-06-09 14:42 -0400, Philip Balister via Therion wrote: > Anyone build therion with vtk7.1 on Fedora? It feels like some vtk > libraries have new names. Vtk seems to rename its libraries regularly. It's quite dull. e.g. We had to do this when VTK6.1 was new: https://sources.debian.org/src/therion/5.3.15-2/debian/patches/vtk6.patch/ Just installing 783MB of build-deps and I'll try it with vtk7 on debian. ...and 283 MB of other stuff that neeeds to change OK. Therion 5.4.1 builds fine there (v7.1.1). Which version are you trying to build? 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] Wrong average calculation from compass/backcompass data
On 2018-05-17 09:25 +0200, Evaristo Quiroga via Therion wrote: > El 17/05/2018 a las 0:36, Olly Betts escribió: > I think the formula is too complicated. I purpose a simpler formula, > like: > If bearing <=180 > AverageBearing = (bearing + (backbearing > -180))/2 > else > AverageBearing = (bearing + (backbearing > +180))/2 > > Your proposed formula gives wrong answers in some cases - consider: > > bearing = 80, backbearing = 0 > > These give AverageBearing = (80 + 0 - 180) / 2 = -50 (equivalent to > 310), but this should be 130 (average of 80 and 180). > > > In this case is not a problem with my formula, is a serious magnetic anomaly > (100 degrees difference) and the program should to stop and to send a > warning. Yes a warning should probably be issued about poor data, but it _is_ a problem with your formula. It's just an example showing that all cases have to be dealt with correctly, including the wrap-around at 0/360 (or 0/400 for grads) and your simplified formula doesn't. An example with a much smaller difference between back and foresight could still be constructed to show the issue: Fore: 175, Back: 0 AverageBearing= (175+0-180)/2 = -2.5. That's wrong. It should be 177.5 in this case. 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] Eurospeleo surveying
On 2018-05-01 20:27 +1200, Bruce Mutton via Therion wrote: > > 2pm Sunday 26th 'Surveying Workshop' (Lecture Hall 3) > > http://eurospeleo.at/ Anyone planning to go? > > As per the message that Martin forwarded, I am interested, but don't think I > can justify travelling around the world. Travelling halfway round the world for this would indeed be excessive, and poor allocation of your increasingly limited carbon budget. > Some sort of electronic conferencing might be nice, to at least listen in, > and maybe contribute just a little. That's a good point. I will try and make sure we do that. Jitmeet is good for this sort of thing: https://meet.jit.si/ I'll anounce a conference URL nearer the time. > Timing will be a bit challenging in NZ, looks like just after midnight on a > Monday morning. That I don't have a solution for :-) 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] Eurospeleo surveying
On 2018-01-26 16:23 +, Wookey via Therion wrote: > Eurospeleo is in Austria this summer (Ebensee). > > I plan to be there. Some of the rest of you no doubt are too. > > I think it would be a good idea to arrange a session of some sort just > to meet up and find pout what people are doing. > > If there is nothing already planned, I will register for an 'open > session' to be scheduled so surveyors can just compare notes and > report what they are doing, as we did informally at Brno. This has now been arranged: 2pm Sunday 26th 'Surveying Workshop' (Lecture Hall 3) I hope to see a few of you there. Anyone planning to go? http://eurospeleo.at/ 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] How to "equate" between two caves
On 2018-04-26 09:51 -0500, Bill Gee via Therion wrote: > The combined map is generated from a single thconfig file that uses "source" > commands to bring in the .th files from each of the member caves. > > Now we have surveyed a link between two of the four caves. I need to set up > an "equate" command so that the two caves actually link up. > Based on a message from Martin, I added a .th file which contains a "survey" > command. However, that is generating an error from Therion: ... > == BigCavernRanch.th === > # Bring in subsidiary files > > # Name the input caves > source ../AllieSpringCaveSurvey/AllieSpringCave.th > source ../MillCreekCaveSurvey/MillCreekCave.th > source ../ShiftyRockPit/ShiftyRockPit.th > source ../CascadeCaverns/CascadeCaverns.th > > survey all > equate AA42@ShiftyRockPit DR23@AllieSpringCave > endsurvey 'source' is a command that goes in a thconfig file. 'survey' is a command that goes in a .th file. thconfig and .th files have different formats. So even though you've called the file 'BigCavernRanch.th', it's being treated as a thconfig file. I think if you change: input BigCavernRanch.th to source BigCavernRanch.th that should do the trick. input is 'insert file as if it was written here' source is 'read this .th data file here' 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] Syntax highlighting for therion files (.th, .th2 and .thconfig)
On 2018-03-26 11:00 -0500, Bill Gee via Therion wrote: > I plan to look at syntax highlighting files for both joe and gvim. emacs, please Bill :-) Survex has vim syntax highlingting files. If anyone was enthused to add more for that software too (should be fairly mild variations of the therion versions) it would no doubt be appreciated. 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] What file I have to translate for Loch
On 2018-03-11 00:13 +0100, Evaristo Quiroga via Therion wrote: > Thanks Olly. > > I have already translated it. Now, What do have I do. Wait for a new > compilation, or I can install it directly in the program directory to run. By publishing it, Olly (or I) can add it to the Debian version so it's out there for those users very soon. For other users, they have to wait until there is a new upstream release including it. 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
[Therion] Eurospeleo surveying
Eurospeleo is in Austria this summer (Ebensee). I plan to be there. Some of the rest of you no doubt are too. Does anyone know if there are any surveying meet-ups planned? I think it would be a good idea to arrange a session of some sort just to meet up and find pout what people are doing. Anyone got any enthusiasm for something more comprehensive, like practical survey work, or training or otherwise comparing notes? Maybe reporting on the survey/GIS work in the UK (initial meeting next weekend)? Talk abstracts need to be in by 30th Jan so if you want to give talks say so now. Maybe reporting on the survey/GIS work in the UK (initial meeting next weekend) which I am unfortunately going to miss? If there is nothing already planned, I will register for an 'open session' to be scheduled so surveyors can just compare notes and report what they are doing, as we did informally at Brno. 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] Multiple fixes for the same point
On 2017-09-07 14:46 +0100, Andrew Atkinson via Therion wrote: > On 07/09/17 14:23, Wookey via Therion wrote: > > I've wanted to do this too, but wasn't sure how. > > > > Alternatively you can give them different names (with variances), then > > equate them. > > Okay that probably will get round it, but is that the right solution? As > this entrance has 3 locations it gets a variance, but most of the other > 9 entrances only have one fix. This would mean they are deemed perfectly > correct, while the ones with more than one location will be moved by the > averaging and the surveys that connects all the entrances together. So > in this case I could just go through and give a the variances for all > the fixes in the data files (it is only a small set.) However it is part > of a very large data set, with something like 200 entrances, that will > take me sometime (or a script.) Now one of the answers which I might > start to do is always be explicit in the variance, however, is it really > reasonable for survex and therefore therion to assume a fix is perfect, > we know that they are not. No. Almost all fixed points really have some sort of variance. Having standard 'GPS' assumptions for GPS points would be helpful. We really should be putting some numbers in for this until Survex/Therion does it for us. Fixed points coming off map benchmarks or laser surveys could have very small variances which might be close enough to zero that leaving them as zero is not too innacurate. > 2 gps locations fixed by survey legs all the > error is distributed to the survey legs, does not seem right. > So what I'm suggesting is that the default for fix to be perfect should > be looked at and maybe amended to almost perfect variance. Agreed, or at least some shorthand for 'type of fix'. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Multiple fixes for the same point
On 2017-09-07 13:07 +0100, Andrew Atkinson via Therion wrote: > I'm sure that this has been covered, but I cannot find it anywhere. > > I have 3 different gps results for a surface point, all taken with the > same gps but on different days, so rather then picking one I just used > fix on all 3. > > However, therion appears to be taking only the last one I enter. > This does not seem to be the right behaviour! Is there a way for Therion > to take all 3 and 'average' them? I've wanted to do this too, but wasn't sure how. From *FIX on https://survex.com/docs/manual/datafile.htm The standard errors default to zero (fix station exactly). cavern will give an error if you attempt to fix the same survey station twice at different coordinates, or a warning if you fix it twice with matching coordinates. You can also specify just one standard error (in which case it is assumed equal in X, Y, and Z) or two (in which case the first is taken as the standard error in X and Y, and the second as the standard error in Z). So I just checked and if you add some variances you can then give more than one set of locations for it without getting errors, and the final location is the average. Alternatively you can give them different names (with variances), then equate them. So survex can do the right thing. Hopefully therion will pass this through so that it works right, but I've not tested that. So this works: *fix pt1 5 5 5 1 1 1 *fix pt1 5 5.5 5 1 1 1 dump3d fixtest.3d: ERROR_INFO #legs 2, len 0.00m, E 0.20 H 0.25 V 0.00 NODE 5.00 5.25 5.00 [pt1] FIXED And so does this: *fix pt1_1 5 5 5 1 1 1 *fix pt1_2 5 5.5 5 1 1 1 *equate pt1_1 pt1_2 dump3d fixtest.3d: ERROR_INFO #legs 2, len 0.00m, E 0.20 H 0.25 V 0.00 NODE 5.00 5.25 5.00 [pt1_1] FIXED NODE 5.00 5.25 5.00 [pt1_2] FIXED Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] mud!
On 2017-08-14 11:51 -0700, Rob Countess via Therion wrote: > It would seem like a break in tradition to use a different symbol for mud. > I've > been surveying caves for 20 years with this symbol. As far as I understood, we > were using British mapping symbols because of the large number of British > cavers like Mike Boon and Tich Morris, and others who came over because of > Derek Ford at McMaster University. I used to have a huge list of symbols with > this mud symbol included, I can't find anything to back this up several pages > deep on google. You will notice that the UIS calcite symbol is exactly the mud > symbol in Canada whereas our calcite symbol is connected scallops. Not sure if > this is based of some now defunct british symbols set. You don't have to draw your caves with the UIS sysmbol set. You can choose a different symbol-set if you prefer. As you say, the lack of a 'mud' sysmbol is a bit difficult for cavers of a UK mindset, but the UIS logic in just defining sediments by particle size does make some sense. Therion is quite happy for you to specify any sysmbol set you like, or to add a few extra sysmbols. (Most UK surveyors can't really get by without the 'slope arrow' symbol for example) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] CaveView a 3D web viewer
On 2017-07-27 08:40 -0500, Bill Gee via Therion wrote: > CaveView requires installation to a running Web server and manual > editing of HTML files. It is not a stand-alone application. But it could be packaged as one, available to run on your local webserver. Not sure how useful that is in practice. > Second, the archive files I looked at seem to be incomplete. I downloaded > the > source code but could not find any file called CaveView.js. > I also tried cloning the git repository with this command: > > git clone https://github.com/aardgoose/CaveView.js.git > > Good grief, it downloaded over 260 megabytes! Even that did not have a > CaveView.js file. Heh, hooray for 'the modern way'? There is a CV.js which I presume is the top-level file. (and there are two worker threads which need to run too). CaveView.js is the application name - there isn't actually a file called that, just a directory. This does look nice and shiny. I'll take at look at what's involved in packaging it for use as a local app then people don't need to worry about all those setup instructions. I've not fiddled with any node stuff before, but expect it to be somewhat painful, from what I've heard about the node ecosystem :-) Looks like it needs the following: rollup, which is currently in experimental. three.js (already in since stable) (however it wants r85 and debian has 73 or 80 - this may or may not actually matter) proj4js (already in since stable) So none of that looks too bad, although the rollup piece could be a pain in practice. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Loop closure algorithms
On 2017-07-19 18:56 +, Saeid Bostandoust via Therion wrote: > Hi, what is loop closure algorithm(s) used in therion core? If survex is installed therion uses the survex loop closure algorithm. If not it uses its own which is somewhat less sophisticated. > Can some body explain an algorithm for me? The survex process is mostly documented here (in some very old docs, but nothing much has changed in the core algorithm): http://csg.bcra.org.uk/surveynotes.html More details on how instument standard deviations are specified and used is given in the survex manual. Not sure if the therion algorithm is documented in detail. > If these are more than one algorithms used in therion, how can i choose and > change default loop closure algorithm? Installing or not-installing survex switches the algorithm. Not sure if there is a way of forcing one or the other algorithm without doing that.. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Linux and DistoX (Wookey)
On 2017-04-07 14:19 +0200, Marco Corvi wrote: > Before that, Wookey wrote: > So, thanks to me giving a competent person (who also doesn't own any > Windows or Android devices) a couple of distoX's that needed calibrating... > > At the moment this only works with python3 and distoX1, But Stuart > plans to use the topodroid codebase to work out the differences for the > X2 protocol (unless anyone has a doc for this already, or Marco can > tell him). > > > wookey, > > I may be not precise because i do not have the docs at hand. > > the distox2 protocol is backward compatible. > > therefore, getting the calib raw data from the distox2 is the same as in > distox1, namely two data packets, one for G, one for M. > > the commands to toggle calib mode on and off are the same, too. So, it turns out that distoX2 does not work quite the same as the distoX1 (same commands, but it does not always respond to 'are you in cal mode' and 'which are most recent measurement' usefully, so it took a question to Beat to get the secret runes for doing comms with both types (without just waiting for an 'I have these readings' message, which seems to be how topodroid deals with this). Stuart has now done that and updated the download/comms code to work with both and it is here: https://github.com/malc0/distox I will package that in Debian at some point, along with Marco's calibration tools. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Loch fails to start in Debian
On 2017-05-22 15:00 +0200, Bjørn Egil Johansen via Therion wrote: > I have a fairly fresh Debian 9 Stretch 64bit install , using propietary > NVIDIA-drivers. Therion from debian repositories 5.3.16-10+b4 > > When trying to open Loch i encountered this error: > > Failed to load module "canberra-gtk-module" > The program 'loch' received an X Window System error. Thanks for the thorough bug report. Putting this email in a debian bugreport is probably a good idea in case others come across the same problem. I don't actually have stretch installed yet on hardware with nvidia GPU - but I guess it's time that I tried it, so I'll upgrade and see if I can reproduce. I use the nouveau drivers so may not be able to reproduce if it's actually to do with the binary drivers. I would certainly try the noveau driver and see if it still happens to you or not. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] linux and distoX
On 2016-09-23 13:37 +0100, Wookey wrote: > On 2016-09-22 20:52 +0200, cawa.so...@gmail.com wrote: > > Hello, > > > > I look for a software to use a distoX on linux, I found for windows, > > android, but nothing on linux. > > Do you know if a linux soft exist ? > > Sort-of. The situation is not great. You can download, but not calibrate, in > my experience. > The other codebase is Marco Corvi's precursor to topodroid: topolinux > The drawing part of that codebase, using QT3 is competely obsolete, > but the distoX tools comms part is still useful. I got it to download > data, and calibration numbers but I never got it to successfully > calculate new calibrations and upload them. It was 90% there but there > were problems with different tools ordering data in different ways. I > never got round to fixing it. > > It would be good if someone got enthused to fix up this code and then > we could do calibrations without needing a windows PDA or laptop to > run pockettopo, or an android device to run topodroid. As I own > neither of those things I would really like to see this fixed, but > still haven't got round to it as it's usually expedition time and it's > easier to borrow a suitable device than to stop and fiddle with > software :-) > > I would be keen to work with anyone who has some time for this, to > resurrect the 'utils' part of that codebase in working form. So, thanks to me giving a competent person (who also doesn't own any Windows or Android devices) a couple of distoX's that needed calibration, the software situation just improved. Stuart Bennett wrote a python script to do the device detection, calib toggling, data dumping and calib coefficient upload/dpownload, and another to convert csv to the format that topolinux calibration code expects. Combining these bits with a sufficiently-recent (>=0.2) pybluez, I managed to dicover device, set up connection, pair, set calibration mode, do a calibration, download the data, process it with topolinux, and upload the resulting coefficients. i.e. a full linux-based calibration (for a distoX1 only so far), for the first time in about 6 years. Yay! So thanks to Stuart for sorting that. The script is handy in that it deals with discovery, pairing and rfcomm setup painlessly. At the moment this only works with python3 and distoX1, But Stuart plans to use the topodroid codebase to work out the differences for the X2 protocol (unless anyone has a doc for this already, or Marco can tell him). Then the code really needs to be made python2 compatible, because Debian fucked-up and accidentlaly uploaded pyblues 0.18 source as pybluez 0.22, so the forthcoming stable will only have bluetooth support for python2, so this will remain the situation for the next 2 years. This is just the byte-string construction, which is easy and native in python3, but a bit of a pain in python2. Once this is sorted, I plan to package this (i.e these scripts and the calib utilities from topolinux codebase) as distoxtools or something similar so that linux people can easily calibrate/download. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] New version of Therion 5.4.0 available
On 2017-04-05 21:29 +0100, Olly Betts via Therion wrote: > On Wed, Apr 05, 2017 at 10:20:55PM +0200, Benedikt Hallinger via Therion > wrote: > > Can't wait to see it in debian testing :) > > Debian testing is currently frozen in preparation for the next release, > but it should appear in Debian experimental soon. Ol has uploaded this already, so it's built on all release architectures and available now: https://buildd.debian.org/status/package.php?p=therion=experimental https://packages.qa.debian.org/t/therion.html As always, feedback welcome. Just to be clear, that upload is to Debian experimental because Debian is frozen for the imminent stable release. It will be 5.3.16-10 (which does actually include some of the changes in 5.4) in that stable release. As soon as the release is done we'll move therion 5.4 into unstable. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] th2 empty objects
On 2017-03-15 11:23 +0100, Ladislav Blažek via Therion wrote: > Martin’s regexp works as well, juast add backlash before first w > > this is working: > > ^\s*(\w+) \w+(-?)\w*\s+end\1 Someone add this to the wiki, as working out a regex yourself takes ages :-) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Revise command: how to remove persons later on
On 2017-03-05 19:30 +0200, Benedikt Hallinger via Therion wrote: > The same reason like already told in this thread: the data should reflect > otherwise recorded data. Right, but in this case they didn't actually turn up, so how is it correct to leave them as listed on the survey team? I, too, like to keep notes original, but when they are provably wrong they are changed (usually with a comment explaining the change from the original notes). This happens regularly for instrument readings, and sometimes for station conenctions. It can happen for team members too. Unless someone wants to propose a general 'revised notes' command, I don't think it makes sense to provide this for team members, but not readings, or indeed anything else. I can see that marking data as 'revised from original notes' might actually be useful (because that effectively makes it possible to show the 'thisa was revised' comments in some kind of UI). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] xtherion: "Edit line" contextual menu for line points doesn't work
On 2017-02-23 22:32 -0300, Rodrigo Severo via Therion wrote: > Em 23 de fev de 2017 19:19, "Wookey via Therion" <therion@speleo.sk> escreveu: > On 2017-02-23 12:02 -0300, Rodrigo Severo via Therion wrote: > > I can't make any of xtherion's "Edit line" contextual menu options to > work. > > When I right click on a line point and choose some of the "Edit line" > submenu > > options nothing happens: no error, no change on the line, just the menu > > disappears. > > Platform/OS? Version? Distro? did you build it yourself or use a > supplied binary? > > Ubuntu 15.10 and 16.04. Both with Debian package 5.3.16. Right. I see what you mean. I can reproduce that. It does work if you use the keyboard to select the item, rather than clicking with the mouse, so I think the issue is actually the click getting lost. No idea why that should be. I've created a bug report to stop it getting lost: https://bugs.launchpad.net/ubuntu/+source/therion/+bug/1667550 Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] xtherion: "Edit line" contextual menu for line points doesn't work
On 2017-02-23 12:02 -0300, Rodrigo Severo via Therion wrote: > Hi, > > > I can't make any of xtherion's "Edit line" contextual menu options to work. > When I right click on a line point and choose some of the "Edit line" submenu > options nothing happens: no error, no change on the line, just the menu > disappears. Platform/OS? Version? Distro? did you build it yourself or use a supplied binary? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Translation doubt: what's a "clay-tree" point?
On 2017-02-21 12:16 -0300, Rodrigo Severo via Therion wrote: > Hi, > > > I'm making a small revision on the translations I did yesterday. I'm not > entirely satisfied with some of them. > > What's a "clay-tree" point? I couldn't find out even searching Google. I've never heard of this term before either. I recognise the formations from the pics, but I have no idea what we call them in English. I'd be surprised if it really is 'clay-tree'. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Greek letters not appearing in pdf export
On 2016-10-24 10:58 +0300, georgpa wrote: > I have defined a title for my map in greek and when I create a pdf export the > letters are shown as dots "." > (System is Win10 64bit, text files are saved in UTF8) > > Any ideas on that? 'Fonts not available', seems likely. Or possibly 'font not defined', but I'd expect therion to complain in that case. I don't know what fonts therion uses for greek letters, but I'm guessing they are not installed on your system, or not available when/where you view the PDF. On Debian(Linux) I can use 'pdffonts ' to get a list of the fonts it uses. (from the poppler-utils package). There is presumably some equivalent on Windows. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Therion 5.3.16 using raft symbol both for rafts and raft cones
On 2016-09-27 10:30 -0300, Rodrigo Severo wrote: > 2016-09-27 10:24 GMT-03:00 Wookey <woo...@wookware.org>: > > > > So, not a solution, but may be useful background. > > Yeah. Not a solution but useful background nonetheless. So, for a bit more detail (as I'm wondering myself). In the source the mpost dir contains thArea.mp, thLine.mp, thtrans.mp etc thTrans.mp contains all the mappings from label to actual national symbol, including let p_raft = p_raft_NSS; all those files are concatenated by a script 'genmpost.pl' into thmpost.cxx. (SYMBOLS.txt, thsymbolsets.h, thsymbolsets.cxx are also created) thmpost.cxx is a 160K C++ file that essentially defines one huge string that is all the metapost config files. And that's what gets used (rather than just reading in the file(s) at runtime like a sensible arrangment would). I really would like to undo all this nonsense one day, but it's not actually broken, and presumably can't actually be thrown away because the Windows/Mac builds need it, so the incentives are not large. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Therion 5.3.16 using raft symbol both for rafts and raft cones
On 2016-09-27 08:20 -0300, Rodrigo Severo wrote:
> 2016-09-27 3:03 GMT-03:00 Martin Sluka <martinsl...@mac.com>:
>
> First of all, thanks for your help and attention.
>
> > There is the file thTrans.mp in the mpost directory of Therion.
> >
> > In that file there are the rules which symbol to use for the final output.
> >
> > Anyway it should work as you presume:
> >
> > let p_scallop = p_scallop_UIS;
> > let p_flute = p_flute_UIS;
> > let p_raft = p_raft_NSS;
> > let p_raftcone = p_raftcone_NSS;
> > let p_spring = p_spring_SKBB;
> > let p_sink = p_sink_SKBB;
> >
> > Check it, please.
>
> Unfortunatelly I don`t have neither this file nor this directory on my
> system. Did I mention that I`m using a Ubuntu package? ;)
>
> Can`t I get this info from some file in the thTMPDIR?
>
> I found this on the data.mp file:
>
> root@prata15:~/Dropbox/EGB/exploracao poco
> surubim/topografia/thTMPDIR# grep -irn raft .
> ./data.mp:1305:def p_raft_NSS (expr pos,theta,sc,al)=
> ./data.mp:1313:def p_raftcone_NSS (expr pos,theta,sc,al)=
> ./data.mp:4794:let p_raft = p_raft_NSS;
> ./data.mp:4795:let p_raftcone = p_raftcone_NSS;
> ./data.mp:4986:initsymbol("p_raft_NSS");
> ./data.mp:4987:initsymbol("p_raftcone_NSS");
> ./data.mp:5137:p_raft((-22.99,-140.49),0.0,1.00,(0,0));
> ./data.mp:5139:p_raft((-20.97,-127.92),0.0,1.00,(0,0));
> ./data.mp:5141:p_raft((-23.21,-110.27),0.0,1.00,(0,0));
> ./data.mp:5143:p_raft((-10.48,-105.85),0.0,1.00,(0,0));
So, this isn't going to help you much, becuase I don't understand it
myself, but it's worth explaining. In the early days of Therion it did
install various config files in the tex and metapost directories to
get used when processing caves.
However, whilst this worked fine on Linux, it was a pain for
Windows/Mac people (as they have no packaging). So therion changed to
'inject' the config files automagicially into tex and metapost as
needed. (So that's probably why you see this stuff in the tmpdir, but
not elsewhere).
I preferred it the old way as it made this sort of hackery easier (and
was more obvious what was going on), but patching it back was work
that didn't seem necessary and might lead to bugs unless I understood
all that stuff much better than I do. It's still on the 'would be
nice' list.
I expect it's possible to put a file somsewhere to override all these
things, but I don't know what or where.
So, not a solution, but may be useful background.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion
Re: [Therion] linux and distoX
On 2016-09-22 20:52 +0200, cawa.so...@gmail.com wrote: > Hello, > > I look for a software to use a distoX on linux, I found for windows, > android, but nothing on linux. > Do you know if a linux soft exist ? Sort-of. The situation is not great. You can download, but not calibrate, in my experience. There are two bits of software, both a bit half-arsed. dxtool by Mateusz Golicz, simple tool to download distoX data. This summer Olly Betts patched it to work on a distoX2. A preliminary version of that patch is included in my dxtool version at: http://wookware.org/software/repo/pool/main/d/dxtool/ A better one is stuck on a machine that is poorly. This is not fancy but it does download readings. upstream is at: http://jaskinie.jaszczur.org/index_en.html prompted by this mail to finished this off, I have just uploaded it to debian, so it should be available there quite soon at https://tracker.debian.org/pkg/dxtool The other codebase is Marco Corvi's precursor to topodroid: topolinux The drawing part of that codebase, using QT3 is competely obsolete, but the distoX tools comms part is still useful. I got it to download data, and calibration numbers but I never got it to successfully calculate new calibrations and upload them. It was 90% there but there were problems with different tools ordering data in different ways. I never got round to fixing it. It would be good if someone got enthused to fix up this code and then we could do calibrations without needing a windows PDA or laptop to run pockettopo, or an android device to run topodroid. As I own neither of those things I would really like to see this fixed, but still haven't got round to it as it's usually expedition time and it's easier to borrow a suitable device than to stop and fiddle with software :-) I would be keen to work with anyone who has some time for this, to resurrect the 'utils' part of that codebase in working form. Upstream is at https://code.google.com/archive/p/topolinux/ but was abondonned to work on topodroid instead. Marco could no doubt provide more info. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] Simple Android Software with export to Therion
On 2016-08-29 20:32 +0200, Martin Sluka wrote: > I hope Beat will make promised Android version of PocketTopo sometime. Sexytopo is an Android re-implementation of pockettopo. It's almost identical (AIUI), and unlike pockettopo is free software, so there seems to be no point re-doing that work, especially not under a more restricitive licence. Binary from store: https://f-droid.org/forums/topic/sexytopo/ Upstream source: https://github.com/richsmith/sexytopo Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[Therion] Therion compiling error (Loch, lxGUI)
+++ Christian RöÃler [2016-05-13 23:32 +0200]:
> Am Montag, 2. Mai 2016, 23:10:06 schrieb Christian RöÃler (Roessler):
>
> Hallo everyone,
>
> >> I am trying to compile Therion on an openSuse 13.2 64bit, and had no
> >> success so far.
> > But now it hangs at:
> >> lxGUI.cxx:517:73: error: invalid cast from type âwxStringâ to type
> >> âconst wxChar* {aka const wchar_t*}â
> >> #define matchtype(w,t) if (fName.EndsWith((const wxChar
> >> *)wxString(_T(w return t;
> well, after reading the hint to that repository, I downloaded it at once,
> and read in file changes: VTK 6.0 support. So I compiled it anew, as
> working in a virtual machine is sometimes a bit bothersone. But it hangs
> at the exactly same point while compiling as mentioned above. So I would
> like to ask if there is a solution on the horizon, so to say?
You might have more joy with the Debian package which is patched to fix various
such build-time issues:
http://httpredir.debian.org/debian/pool/main/t/therion/therion_5.3.16-10.dsc
and the corresponding .orig.tar.gz and .debian.tar.gz
That's built against vtk6.2
This one is built against vtk6.1:
http://httpredir.debian.org/debian/pool/main/t/therion/therion_5.3.15-2.dsc
The debian vtk packaging layouts may not exactly match the Suse ones
but you will probably find clues.
Or you can look online here (although I don't see anything much that looks
relevant):
https://sources.debian.net/src/therion/5.3.16-10/debian/patches/
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: 819 bytes
Desc: Digital signature
URL:
<http://mailman.speleo.sk/pipermail/therion/attachments/20160514/cbe3e613/attachment.sig>
[Therion] Setting Scrap Colours
+++ Olly Betts [2016-03-27 09:44 +0100]: > On Mon, Mar 14, 2016 at 09:23:39PM +1300, Bruce wrote: > > Colour by map works just fine, as does colour by scrap or altitude. > > > > In the context of your question I thought you were trying to SPECIFY > > which colour a particular scrap (or map or altitude) would be > > assigned. > > I was "commissioned" to implement the ability to specify the colour > used for each map - patch attached. I've included this, in the latest therion upload to Debian 5.3.16-10 which has now migrated to Testing. One with Geogiev's v8 3D (co-ordinate system export in 3D file) changes has been prepared but I need to fix a couple of other things before uploading. Soon, if I don't get too distracted... 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: 819 bytes Desc: Digital signature URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20160404/edee41c4/attachment.sig>
[Therion] Simple Android map software with export to Therion
+++ Erin Lynch [2015-12-25 09:34 +]: > I wish all of these apps had apk files available for direct download from > their > websites, instead of play.google.com. Google is blocked in China, so none of > the cavers here can install software which is only available from the Play > store. Absolutely. And some of us want to use our tech with code we actually trust, and if you do that Google prevent access to the play store (AIUI). And you can't do it without a gmail account (which is a very reasonable thing to not want). So we need stuff on either fDroid or as plain .apks too. Sexytopo is now on fdroid (Yay!). topodroid isn't. 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: 819 bytes Desc: Digital signature URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20160328/9a0cf4a3/attachment.sig>
[Therion] Recovering data marked as sent from DistoX2
+++ Marco Corvi [2016-03-23 12:52 +0100]: > andrew, > > topodroid has a function to read the distox2 memory (and optionally save it to > a text file). > it is slow, and it has no way to know where the most recent data are. may want > to read it in small chunks. And if you don't have an android device to hand you can get Marco's Linux code (topolinux) to do this too. However it is not packaged (I never finished that) and has various issues, so you can be pleased that you don't need it. (But I must finish that packaging (combined with Mateusz's dxtool) sometime as getting data out of distoX on Linux remains painful) 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: 819 bytes Desc: Digital signature URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20160325/342e3b8b/attachment.sig>
[Therion] Survex Terrain model problem
+++ ÐÐ»Ð°Ð´Ð¸Ð¼Ð¸Ñ ÐеоÑгиев [2016-03-24 16:30 +0200]: > ââThanks for the info. Seems that the data is not exported to the .3dâ > format > indeed. If I have the time I will try to find the place in the Therion sources > where that export happens.â Please post the patch if you do that, and I can include it in the Debian build until there is a new upstream release. 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: 819 bytes Desc: Digital signature URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20160324/0620f377/attachment.sig>
[Therion] XTherion modifications
+++ ÐÐ»Ð°Ð´Ð¸Ð¼Ð¸Ñ ÐеоÑгиев [2016-02-19 19:11 +0200]: > > On Fri, Feb 19, 2016 at 5:23 PM, Wookey wrote: > So I merged your code into the debian package. You had managed to > 'dosify' me_cmds2.tcl which made a massive patch, but I've fixed that > (and quite a lot of trailing whitespace). > Patch attached to save anyone else the work. > I'm building the package now and will upload soon if everything works. > > > âDon't know that you mean by "dosify" :) Changed all the lineends from 0x0A (unix linefeeds) to 0x0D,0x0A (DOS linefeeds) (which makes every line different). Normally this is a problem with editors silently converting your files, but sometimes also VCSes. Not helped by the fact that some files from upstream are 'mixed line-ends', which can confuse editors. > Indeed there was some whitespace in most of the files. I didn't remove it > exactly to avoid making a large patch/commit. Right, but you (well, your editor, no doubt) added some more :-) The debian package has a huge whitespace patch to fix this irritation, but Stacho has not merged it upstream yet :-( > About building the packages, I actually tried building xtherion only, not the > whole Therion. But I suppose that xtherion should not affect the rest of the > build process. No, it's not your fault. I recall this being an issue already. Therion build-depends on itself, so it builds OK if it's already installed on the build machine (and the library catalogue hasn't changed between what's installed and what's building), but not in a clean environment. Which means I don't understand how the current debian builds are building at all (because they should be done in just such an environement) I was going to fix it properly by generating the catalogue in a less crufty way, but have clearly not got round to it. 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: 819 bytes Desc: Digital signature URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20160219/dfc601f4/attachment.sig>
[Therion] XTherion modifications
+++ Wookey [2016-02-19 15:23 +]: > > I'm building the package now and will upload soon if everything works. It didn't. Therion tries to run itself to build the librarydata file (which will never work in a cross-build and is a bad plan) and it's not working in a normal clean build either right now. I'm not sure why that's now failing (builds used to work). And I'm off on hols for 3 weeks in a mo, so this will have to wait. Sorry. make library make[2]: Entering directory '/«PKGBUILDDIR»' ./therion --print-library-src thlibrarydata.thcfg > thlibrarydata.log /bin/sh: 1: ./therion: not found make[2]: *** [library] Error 127 Makefile:179: recipe for target 'library' failed make[2]: Leaving directory '/«PKGBUILDDIR»' make[1]: *** [thlibrarydata.cxx] Error 2 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: 819 bytes Desc: Digital signature URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20160219/010bebd6/attachment.sig>
[Therion] Online interactive survey of 58km system
+++ Martin Sluka [2016-01-05 17:44 +] wrote: > ___ > Therion mailing list > Therion at speleo.sk > http://mailman.speleo.sk/mailman/listinfo/therion Martin - can you please get an email client that actually sends some text content. Or at least bear in mind that if you want to reply to me, then this client is pretty-much useless. 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: 819 bytes Desc: Digital signature URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20160106/f1bc6b34/attachment.sig>
[Therion] Online interactive survey of 58km system
+++ Footleg [2016-01-05 13:58 +]: > I thought people on this list might be interested in the latest presentation > of > the 58km system survey I have been working on. I have just added the first > part > drawn using Therion (the colourful bit around the Carcavuezo entrance in the > middle of the southern edge). This survey assembles the best data over 40 > years, featuring 'pencil and graph paper', 'ink on tracing paper', 'offlet > litho printed', Tunnel and Therion software drawings. > > http://wscc.darkgem.com/matienzo/4valleys/ > > This format should work on all mobile devices and web browsers on computers. Yep - that works on a flash-free machine with a fairly current iceweasel. Very nice. The mix of ouput forms is most entertaining :-) 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: 819 bytes Desc: Digital signature URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20160105/e652b5bd/attachment.sig>
[Therion] Best practice - orientation of original sketch?
+++ Martin Sluka [2015-12-25 21:56 +0100]: > > > 25. 12. 2015 v 21:33, Wookey : > > > > Martin, you misunderstand my comment. I am talking about the > > labels/writing on the sketch drawing. If N is not up on the paper, but > > the scan is imported with N up, then the writing is > > sideways/upside-down in the xtherion editor, which can be quite > > tiresome. > > Wookey, > > I really donât understand. Therion will import any sketch with orientation > as it was scanned or photographed. How Therion will recognize where is north > of sketch? Exactly, and there is no way of rotating the interface, so if you have one sketch with the writing a different way up from the others, it's difficult to read. It would be nice to be able to rotate the whole drawing area whilst drawing scraps based on that sketch so that one can read the notes/labels. Perhaps there is a way, but I couldn't find one, last time I had this issue. (And this lack is presumably why the drawer in the original post asked for sketchers to use N=up so that writing/notes/labels and N are consistently aligned in the scans). 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: 819 bytes Desc: Digital signature URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20151225/71ff60fb/attachment.sig>
[Therion] Best practice - orientation of original sketch?
+++ Martin Sluka [2015-09-23 22:38 +0200]: > > > 15. 9. 2015 v 4:03, Wookey : > > > > (which doesn't have a way of rotating the view to more easily read the > > writing, for example (SFAICS)). > > Wookey, in Therion if labels has not fixed orientation they are automatically > oriented to top of map. If North orientations is to top of the sheet too, it > is what that man needs. If you draw a particular map in Therion in any > direction it will be exported with North to top of page if not rotate in > layout is used. Martin, you misunderstand my comment. I am talking about the labels/writing on the sketch drawing. If N is not up on the paper, but the scan is imported with N up, then the writing is sideways/upside-down in the xtherion editor, which can be quite tiresome. 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: 819 bytes Desc: Digital signature URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20151225/de58ec21/attachment.sig>
[Therion] new Therion?
+++ Philip Schuchardt [2015-12-18 13:44 -0500]: > Hey, I'm the primary developer for Cavewhere. I though I would chime in. > > Cavewhere is open source, under the GPL, although I think I need to > actually upload that bit (tonight). It's currently on github, as mentioned on > a > previous post. It currently runs under, Windows, Mac, and Ubuntu > Linux. Since most linux users are complete computers nerds, they get > the fun job of compiling it themselves. Although my friend, Jon L is > creating a debian installer. I need to check with him on the status of > that. I'm happy to help with Debian packaging, or sponsoring as I currently package most of the available cave software tools for Debian. (I'm also happy for someone else to do it :-) 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: 819 bytes Desc: Digital signature URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20151218/19691fc1/attachment.sig>
[Therion] change palette for color map-fg altitude
+++ Henry_Bennett at Dell.com [2015-12-10 12:39 +]: > Hi, > > âcolor map-fg altitudeâ will color the map passage by scrap according to > its > relative elevation and works well. > > Iâd like to customise the color pallete to avoid the blue on blue I get for > river cave. Iâve modified the water in the example below to be blue too. > > Anyone know where the palette is defined? I think this is an outstanding wishlist item. i.e. there is no way to do this yet, but you are not the first person to ask. Andrew knows. Patches always welcome, if you get enthused. 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: 836 bytes Desc: Digital signature URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20151210/e6eaf705/attachment.sig>
[Therion] new Therion?
+++ Martin Sluka [2015-12-01 18:28 +0100]: > https://www.youtube.com/watch?v=N_Et5CAoJfo Looks nice (all pointy and clicky, with some nifty features like the 'carpeting'), but there is no source and only binaries for windows and mac. That's no use to me at all, and not to anyone else except Philip over the longer term. Is Philip on this list? Is it free software? What's the platform (some clues online suggest QT/opengl/C++)? If the latter then we can fix the missing platform issue so long as it's FLOSS (and thus available to fix). 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: 836 bytes Desc: Digital signature URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20151201/abeba1a7/attachment.sig>
[Therion] Best practice - orientation of original sketch?
+++ Bill Gee [2015-09-14 19:48 -0500]: > When you are drawing the sketch in the cave, is it normal to ALWAYS make north > the same direction on each sheet of paper? No - whatever fits on the paper best is generally best (although if surveying in one rarely knows how that will go unless you have a very joint-controlled cave). In practice I do almost always put North up (and 'up' up on elevations) as I don't know which way the cave is going to go for more than a couple of legs. > What is considered "best practice" in this regard? Always marking 'N' and 'up' on the sketches so it's obvious. > The man who is coordinating the project is also doing cartography using > Windows > tools (Walls, Xara, etc.) He sent me an email today asking if I will commit to > making all future sketches with north being the top of the page. He asks > because some of the computer work he does results in portions of the sketch > being upside-down and therefore more difficult to read. That is probably true with most drawing tools, including xtherion (which doesn't have a way of rotating the view to more easily read the writing, for example (SFAICS)). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
[Therion] Making potractors
What is the best way to make therion potractors? Years ago Martin S sent me some really nice robust ones. Ones I have tried to make since (by printing onto acetate and laminating the result) do not work well because my laminating sheets only stick to themselves, not the protractor material, so it opens up at the baseline and delaminates. Is it possible to print on one side of a laminating sheet then put two sheets through the laminator to encapsulate, or will my laminating sheet just melt in the laser printer? Maybe that could be done, but printed in a (cold) inkjet printer, so long as no water ever got in? There is also the matter of the correct 'floppiness/stiffness'. MartinS were nice and stiff (but robust). Laminator/acetate ones are rather floppy. So, how does everyone else do it? Also http://therion.speleo.sk/protractor/index.php only links to a 1:200 protractor. It would be useful to keep others available there and save people editing the metafont. Ah-ha - turns out that we have 1:250 and 1:500 versions carefully preserved on the CUCC site! http://expo.survex.com/templates/therion1_250.pdf http://expo.survex.com/templates/therion1_500.pdf And there are some US-units ones online. Collecting them would be a useful little task. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
[Therion] having trouble, first time user
+++ Robert Countess [2015-04-18 12:25 -0700]: > Im using Mac OSX10.9. followed MacOSX installation instructions on wiki > > Roberts-MacBook-Pro:~ Rob$ ruby -e "$(curl -fsSL https:// > raw.githubusercontent.com/Homebrew/install/master/install)" [lots of dependency/package building] > ðº /usr/local/Cellar/therion/5.3.16: 6 files, 4.4M, built in 50 seconds > Roberts-MacBook-Pro:~ Rob$ xtherionxtherion > -bash: xtherionxtherion: command not found > Roberts-MacBook-Pro:~ Rob$ xtherion This is exactly the reason that 20 years ago binary linux distributions were invented, to replace the previous painful process of users downloading code and tools and dependencies and building them all until they got some software working. 'brew' attempts to automate this process but there are still a lot of ways it can go wrong. Do Mac people not have a proper packaging system someone could make therion packages for? > _ > > A program named WISH opened and window named therion compiler. The Status bar > at the bottom read âUser interface is not active. To activate it open and > existing file or create a new one." > When I try to open a file with either the Wish file|open or the folder button > I am unable to open any files in the Demo data set - they are all grey and > cannot be selected. > > I am a first time user. Previously used On Station and the Walls. I had data > for 3 major caving areas in Walls totalling about 50 km of cave. I want to > switch it all to Therion but if I canât get the program to work then Iâll > have > to stick with Walls. I'm sure we can get you going. We do have several mac users here, but I'm not one so can't really provide much help. Can you get a command prompt? Can you run 'xtherion' from there? That's the user interface for drawing stuff up. 'therion' is the compiler tool that processes the data. What happens if you run 'therion -v version'? Does that print out a version? or 'therion --print-init-file'? If you can convert some of your (centreline) data (just using a text editor) you should be able process it using just 'therion'. You will need xtherion in order to draw up cave sections. Has anyone written a walls to therion conversion tool? I'm not aware of one. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
[Therion] plumbs on
+++ Guy Demars [2015-04-13 16:41 +0200]: > sorry, but it doesn't work > It's not exactly a Therion problem, but a Survex one > > I' tried with a sample > first export with no plumps you mean plumbs, right? > second with plumps on > third with plumps on a tranlation of my centreline from grads to degres > > the firs and second exports are same, the third is corrected ( not > exactly as I hope, but fine) > > I suspect this because with the centreline : > > from to tape compass clino > a0a1 55 - -90 > > Therion compile without error > > if you replace by > > units clino grad > from to tape compass clino > a0a1 55 - -100 > > Therion compile with warning > Survex gives the error : > 3> /tmp/th6261/data.svx:231: La valeur de lâazimut ne peut être > omise, sauf sur les visées verticales > > sorry it's in french, in english : azimut can't be omitted unless > for vertical shots I tested this in survex. (cavern plumbtest) This works for me: *units clino grads *infer plumbs on ;from to tape compass clino a0a1 55 - -100 if you do: *units clino grads *infer plumbs off ;from to tape compass clino a0a1 55 - -100 instead then it complains: "error: Compass reading may not be omitted except on plumbed legs if you do: *units clino grads *infer plumbs off ;from to tape compass clino a0a1 55 - DOWN then that works OK too. so this is working as expected in cavern/survex. doing the same in therion syntax: (therion -s plumbtest) this fails: centreline units clino grad infer plumbs off data normal from to tape compass clino a0a1 55 - -100 endcentreline and this works: centreline units clino grad infer plumbs on data normal from to tape compass clino a0a1 55 - -100 endcentreline and so does this: centreline units clino grad data normal from to tape compass clino a0a1 55 - DOWN endcentreline So that seems to me to be working OK. Your example expects plumbs to be inferred without actually turning 'infer' on. That doesn't work because the default for 'infer' is off. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
