[Therion] fixed point std error causes extreme survey network distortion
Hi Xavier I tried your approach and like it a lot. Unfortunately I get the same result; -specified std errors result in gross distortion, -no std errors give accurate survey plot (but forced to specified gps location without accounting for itÂs inaccuracy) Other ideas? Perhaps itÂs time to try 5.3.12 Bruce _ From: therion-bounces at speleo.sk [mailto:therion-boun...@speleo.sk] On Behalf Of Xavier Pennec Sent: Sunday, 22 December 2013 9:52 p.m. To: therion at speleo.sk Subject: Re: [Therion] fixed point std error causes extreme survey network distortion Hi Bruce, I have hundreds of fixed points with different accuarcy and never noticed the effect you are describing. However, I am not fixing directly the coordinates of stations of my survey. I always create independant fixed points and then equate them to the survey stations. In your case, this would give something like: fix GPS_12 1562372 5439558 99220 20 20 # entrance equate GPS_12 12 at 01 fix GPS_0 1562117 5440239 1080 5 5 20 # another entrance equate GPS_0 0 at 10 fix GPS_120 1562124 5439500 1020 10 10 10 #entrance three equate GPS_120 120 at 05 An advantage of this strategy is that I can comment all the equates but one to start with and verify with Aven on the 3d file where are the GPS points located with respect to the cave survey. That way, I can spot the outliers in the GPS points (or the errors in their retranscription) and iteratively validate the equates. Xavier PS: between us, I would not qualify your gps stddev below as very rough. A stddev of 5 meters about the smallest I use when I get long GPS averages (more than 30 minutes) with one of the a differential satellites. Le 22/12/2013 01:35, Bruce a écrit : I got some unexpected results recently when I added some very rough gps coordinates to my survey for a cave that has three entrances. Because they are approximate I added some estimates of standard errors as below, so that I could get Therion to factor the relative accuracy into the loop closure. fix 12 at 011562372 5439558 99220 20 20 # entrance fix 0 at 10 1562117 5440239 1080 5 5 20 # another entrance fix 120 at 05 1562124 5439500 1020 10 10 10 #entrance three With any ONE of the entrances fixed as above, the cave plots accurately  I can verify this in Google Earth. As soon as I have any two or more entrances fixed, then the cave distorts significantly, and the entrances are stretched some hundreds of metres away from the centroid of the cave. Also quite often getting Âscrap exceeding maximal scale errors if I output to pdf. I checked this was not just a feature of that dataset by mocking up a similar situation in two other datasets, and got similar results. The work around seems to be to avoid using the standard errors; fix 12 at 011562372 5439558 992#20 20 20 entrance fix 0 at 10 1562117 5440239 1080 #5 5 20 another entrance fix 120 at 05 1562124 5439500 1020 #10 10 10 entrance three but this then results in each gps location receiving equal weighting. I think I might have noticed this problem a few years ago, and gave up on trying to sort it out because I wasnÂt able to identify the characteristics of the problem well enough. Anyone else having problems like this? Or identify a reason why what I am trying to do is not possible? Or is it a bug? Bruce -- next part -- An HTML attachment was scrubbed... URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20131224/527bbe86/attachment.html>
[Therion] new DISTO X2 boards available
Check: paperless.bheeb.ch The best Christmas present, I think. Martin
[Therion] Building therion for HomeBrew
I hope there is no any problem if they will be there m. Dec 24, 2013 v 10:30 AM, Christian Sandrini : > As per HomeBrew rules they all have to sit in their own subdirectory and just > link to binaries to /usr/bin. Martin Sluka - Studio Sluka prodej Hahnemühle DFA tisk fotografiÃ, reprodukcà a volné tvorby Na Rovnosti 2692/21 130 00 Praha 3 tel.: +420 603513640 mail: martinsluka at mac.com web: http://www.piezografie.cz -- next part -- An HTML attachment was scrubbed... URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20131224/bb560d48/attachment.html>
[Therion] Building therion for HomeBrew
Hi I am building therion for HomeBrew Mac so it is a bit easier for every mac user. Is it possible to specify a prefix when compiling? I only have the option make config-macosx but I should be able to specify where the binaries are going to be copied. As per HomeBrew rules they all have to sit in their own subdirectory and just link to binaries to /usr/bin. a make config-macosx âprefix= would be ideal Thanks Chris -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20131224/29ca45fd/attachment.sig>
[Therion] 5.3.12
+++ Wookey [2013-12-24 03:41 +]: > +++ Martin Sluka [2013-12-22 23:26 +0100]: > >Exactly after one year! > A few observations about the source tarball: > > 3) output files are shipped in the samples dirs: > q-marks/map.xvi > survex/create/create.3d > survex/ignore/ignore.3d > survex/use/use/3d > survex/cave.3d Actually the .3ds are supposed to be there - ignore that, (but the xvi isn't) :-) > Anyway, I have updated all the patches and will build and test. OK. amd64 packages for wheezy (Debian stable) are at: http://wookware.org/software/repo/ Please test them. Do we believe that http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718294 is fixed in 5.3.12? Trying an unstable build next. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/
[Therion] 5.3.12
+++ Martin Sluka [2013-12-22 23:26 +0100]: >Exactly after one year! >Martin Sluka Nice! And some of the bugs I have patches for are fixed. Great. A few observations about the source tarball: 1) There is a thTMPDIR in samples/areas/ which I don;t think should be there. 2) I think someone changed their editor settings. Many of the C++ changes have the new lines TAB-indented amongst existing space-indented code, which, at least on my editor, comes out all wrong (and is generally bad practice for exactly this reason). Looks like the editor was set to TAB=2spaces. I'll fix all that up in the debian package and send a patch. 3) output files are shipped in the samples dirs: q-marks/map.xvi survex/create/create.3d survex/ignore/ignore.3d survex/use/use/3d survex/cave.3d I don't think that's really right either, although it doesn't break anything 4) There are a pile of bugs the debian patches fix which remain unfixed in 5.3.12: compiler warnings and code cleanup (mostly unused variables): * (fix-icon-compiler-warnings) * (fix-compiler-warnings.patch) The update to understand survex v8 .3d files (with splays) (update-survex-img-parser-to-v8.patch) Some files missed by the clean target The extensionless files fix (90load-extensionless-files.patch) The fix to avoid segfaulting if the language file is missing (82-nolang-segfault-fix.patch) samples encoding, and clean fixes 'hardening' fix: (hardening-flags-fix.patch) Did you look at some of those and decide not to include them? Mostly I thnk they are uncontroversial. Anywa, I have updated all the patches and will build and test. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/
