Opened 16 months ago

Last modified 10 months ago

#124 new enhancement

It should be possible to fix x,y separately from z

Reported by: Tarquin Wilton-Jones Owned by: Olly Betts
Priority: minor Milestone:
Component: Other Version:
Keywords: Cc:

Description

With some surveys, it might only be possible to fix the horizontal x,y coordinates accurately at a different location from the z height. An example would be a trig point for x,y, and a benchmark for the z (this is my actual use-case), which could be in completely different locations in the surface survey. Another would be for a marine cave where the z can be fixed at the water surface, while the x,y might be taken from local mapping at an obvious landmark. In the UK, it is common for benchmarks to have very imprecise locations but highly accurate heights, and trigpoints often do not have a benchmark.

Currently, the *fix command insists on having x,y and z coordinates for every fix. It would be useful for the *fix command to support - as a measure like this:

*fix trig 1234 5678 - *fix benchmark - - 317

The present workaround is quite laborious:

  1. Fix the location of the benchmark with random x,y and actual z.
  2. Process the survey and read the z of the trigpoint.
  3. Remove the benchmark fix.
  4. Add a fix for the trigpoint, using the calculated z, and the actual x,y.
  5. Hope that loop closure never changes the height difference between the points.
  6. Add a load of comments to explain why the benchmark has no height fix, but the non-benchmark does.

Or: Specify approximate heights or x,y for the unknown quantity at each of the two points, using standard deviations to enable the bad coordinates to be ignored.

Change History (1)

comment:1 Changed 10 months ago by Olly Betts

Essentially the same question was also asked on the cave-surveying list. As I replied there:

It should be possible to allow height-only or no-height fixes (or legs which only connect horizontally or only connect vertically) with the current loop closure code, but I think it would be a lot of work.

I'll leave this open though.

Maybe at some point we'll redo the loop closure code. The tight memory usage of the current code is much less important than it was in the 1990s, and it'd be handy to be able to iterate quickly to solve a slightly modified network for interactive changes to the network while trying to locate blunders (break a leg, quickly see how that affects station positions).

Note: See TracTickets for help on using tickets.