Surveys without centrelines

[Robert Smallshire]

> I guess triangulation is a lot more common at larger scales.

Trilateration in common a larger scales because it's *much* easier to
measure distances with high accuracy than it is angles (these days).  The
last large-scale "retriangulations" before the advent of GPS were
combinations of triangulation and trilaterations: Measure everything you
can and solve everything simultaneously. I've used at least one piece of
software for these type of problems called StarNet:

    <http://www.microsurvey.com/products/starnet/>

They have a free trial which may be suitable for small problems.

Rob




On 6 September 2013 16:46, Wookey <wookey at wookware.org> wrote:

> +++ 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
> --
> Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
> http://wookware.org/
>
> --
> Survex http://lists.survex.com/mailman/listinfo/survex
>