Re: Surveys without centrelines

[graham.mullan@coly.org.uk]

In effect, the G.B. main chamber survey was done this way. Will look out the data when back at my desk.

Graham

Sent from my HTC

----- Reply message -----
From: "Wookey" <wookey at wookware.org>
Date: Fri, Sep 6, 2013 3:46 pm
Subject: Surveys without centrelines
To: "Survex User Group" <survex at survex.com>

+++ kevin dixon [2013-09-06 05:39 -0700]:
>    The term for this type of survey is Trilateration.
>    One problem you will have with this is that where there are only two
>    distances to a point, there will be two valid position solutions,
>    equidistant either side of the baseline that has been used to measure
>    from. In this situation, you will need to have some way of telling the
>    algorithm which side of the baseline is correct.

Good point. I'm not sure what the best way to deal with that is.
An approximate bearing could be used. Or some kind of
'handedness' indicator. e.g 'right of leg stn-stn'. But you don't want
to have to put that in on every leg.

For most stations in a network the errors will be minimised by
choosing the correct solution. It's just the ones round the edge that
will normally be an issue; although more generally: any section of the
network where there is only one line separating them, then it can be
'flipped' either way (e.g. either side of the original baseline). So
you need one bearing in every such section.

I guess the easiest way to deal with this without changing the
codebase much is to allow both:
* data triangular from to length fromdepth todepth
and
* data triangular from to length bearing fromdepth todepth

(I use triangular because I think the same data entry syntax can be
used for trilateration and triangulation: just swap 'length' for
'angle', although actually doing that is a big deal because survex
internal data structures are all about 'legs' not 'relations between
legs', which is why we've not had * DATA TRIANGULATION (I believe, but
defer to Ol) ).

A quick look at the code suggests that adding this format in would be
quite simple. What I'm not sure about is how the data processing bit
would cope. Ol?

>    Should this unusual survey method be added to Survex ? 
>    Would it be better to do the trilateration calculations in excel and then
>    output data suitable for use in Therion/Survex ?

Why would it be 'better' to have to use a general-purpose spreadsheet
tool because my preferred survey tool doesn't understand the format my
survey comes in?

It would be expedient right now as you dont have any choice. But it's
always 'better' if your software understands data in the form you have
it.

Now in practice maybe no-one can be bothered writing the necessary
code, or we can't think of a nice syntax to describe the correct
'handing' of paired solution, so this never actually gets done. And
that might represent sensible allocation of resources (there are
plenty of more useful functions survex could get first). Perhaps
that's what you meant by 'better' - resource allocation? But no,
having to hack data about in a spreadsheet first is never 'better'
IMHO - it means you have some software missing..

Trilateration surveying isn't actually that rare is it? OK, I've not
seen many cave surveys done this way, but it wouldn't surprise me if
archaeology types use it regularly. I guess triangulation is a lot
more common at larger scales.

Wookey