Custom Query (95 matches)

We currently have surface data as legs, which can be used to make a terrain grid (using terraintool to import DEM data). A proper surface using openGL would make for much better visualisations, separate surface survey/GPS data from terrain models and allow later additton of map-draping and similar features.

Related features are data reading, a DEM survex data type, DEM import, co-ordinate conversion, and overlay images, but those are subjects for separate tickets.

Some work on this has been done in 2002 and 2011, as discussed in various 'Surface data' threads at: ​http://lists.survex.com/pipermail/survex/2011-September/thread.html Since then the survex VCS has been converted from SVN to git so the links are broken.

The important bits are these commits: r2035 8ed7e813da6bb872ef3d5d5f7064c3ad16ecb921 ​https://gitorious.org/survex/survex/commit/8ed7e813da6bb872ef3d5d5f7064c3ad16ecb921 r2059 33b2094393ec862b7206d12f49c9735a53d8fb88 ​https://gitorious.org/survex/survex/commit/33b2094393ec862b7206d12f49c9735a53d8fb88

And this is Stuart's hacky patch showing that the core if this is straightforward:

Pockettopo measures 3 versions of each leg, and if you feed such data into cavern it treats each version as a separate leg, producing a very loopy network which takes a while to solve.

Ideally we want to average the repeat readings in this case, and then solve the network treating each set of such readings as one leg. That would also make the leg count saner.

Not sure if we just always do this when we have multiple readings between two points, or if we only consider consecutive readings. The later is probably easier to implement if nothing else.

comments on Mac version...

• processing a .svx file does not produce a log file - so unable to get length/depth details of survey

• clicking on a station in Aven view most times resets the view to some random angle or size/magnification....sometimes flipping the survey 180º !