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
