Diving data loop closures altering depths
wookey at wookware.org
Tue Jun 18 12:33:39 BST 2013
+++ Footleg [2013-06-17 18:48 +0100]:
> On 17 Jun 2013 18:43, "Footleg" <drfootleg at gmail.com> wrote:
> > I tried to post the data in line but now the list is rejecting it as too
> big a message. This list needs to come out of the dark ages. Some of us
> have upgraded from 386 processors.
It's not about '386 processors', so stop sniping. It's about annoying
people with big attachments. Mailing lists are, in general, a very bad
medium for distributing files, because they explode the file to
hundreds of people, most of who probably didn't want it. If you want to
send files of any size put them somewhere and send a link to them..
I still don't like getting big attachments by email because (as you
observe with your '7K doesn't fit inside 40K limit' post), it's a
very inefficient method of data transfer, as well as being a faff to
extract (I run remote mail). Yes, this is probably a rather
old-fashioned view of the net, but then it means I could still use
this list on a phone without it randomly costing 2 quid just to
download someone's email. Data size does still matter at least in
phone world where you have to pay proper money for it.
Still, small attachments like this that have been cut down to
illustrate a point, clearly _are_ a reasonable thing to post so we
should probably turn the limit up from 0. Olly has the rights to do
that. I would be happy with a 200K limit.
> >> Both ends of the loop are at the same depth before the loop is closed.
> The equate which closes the loop is commented out (line 4). All data is
> diving format.
I've not looked at this in detail, but survex constrains the
measurements, and thus adjustments, with standard deviation numbers.
Check the default SDs for diving guage data and (underwater)
compass/length data. Fiddling with these numbers may be instructive.
Clearly if external data constrains a sump to different heights at the
ends then survex is right to 'tilt' the sump a bit. Equally if the
heights already match at a closure then I can't see why it would be
correct to adjust those heights. So that does sound buggy.
I don't think there should need to be any 'bodging' to get this right.
If the measurements are properly assigned their relative accuracies
then survex should DTRT.
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
More information about the Survex