Adding Terrain data/viewing

[Wookey]

+++ Matt Kirby [2013-09-12 19:07 +0100]:
> Olly
> 
> Is there any intention to include a terrain function in future
> releases, we have found it very useful for the Mulu stuff.

Yes. We'd love to - lots of us would find it useful. I don't know if
phil's patch ever made it to the list. It's not in trac.

You could most usefully write down what functionality you currently
have for surfaces and/or what would be most useful? And put it in as a
survex 'ticket': http://trac.survex.com/wiki 

We already have the ability to turn 'surface' data visibility on/off,
and there is an external program (Terraintool) which converts STRM and
ASTER DEMS to fake survex surveys. Does phil's patch give you something
different from this?

Better than 'fake survey legs' would be a proper 3D surface, with
controllable transparency. The main blocker to doing this properly is
that survex needs to learn about real-world co-ordinates, as that's
how most surface data comes, rather than having to run an external
converter.

Stuart Bennett knocked up a version with (very hacky) openGL surface
support a couple of years back. Which was discussed here:
http://lists.survex.com/pipermail/survex/2011-September/thread.html
And that thread showed that there was already some support for this
that MarkS did, in the repo. Developing something from that would be
great. As ever, $someone needs to sit down and write (finish - it's
already at least somewhat written) the code. I need to work out where
that patch went. Unfortunately survex has moved from svn to git (boo
hiss), so none of the links in those threads work any more. (Ol, can
we do anything about that - the actual changes are quite important in
reading those threads?)

turns out that you can't usefully do this in gitorious webUI, but can
on the comand line: git log | grep -C 5 @2059

So the corresponding git commits are:
r2035 8ed7e813da6bb872ef3d5d5f7064c3ad16ecb921
https://gitorious.org/survex/survex/commit/8ed7e813da6bb872ef3d5d5f7064c3ad16ecb921
r2059 33b2094393ec862b7206d12f49c9735a53d8fb88
https://gitorious.org/survex/survex/commit/33b2094393ec862b7206d12f49c9735a53d8fb88

And as I apparently never sent Stuarts patch in, I've put all this in
trac: http://trac.survex.com/ticket/43 so there is somewhere to track
this henceforth.

There are these parts:
1) Add 'real-world' co-ordinates to survex (using libproj - we've started
this with the new 'findentrances' command which exports entrances in
real co-ordinates, but tighter integration so that all files are read
or written ina specifiabe co-ordinate system would be best.

2) Add openGL display of terrain, with transparency and Z-ordering (so
when you look from underneath you can see the cave). This actually
isn't hard. Stuart's patch/Mark's code would be a useful starting point.

3) Add direct reading of DEM data files. And maybe an X,Y,Z survex
data type too.  

Knowing what things are most important to people would be helpful. 
1) Being able to display terrain at all (we have this via
terraintool/surface visibility)
2) Display as surface, not dotted legs
3) transparency (how would the control work? A slider in the UI?
Pre-sets in the file, a la therion)
4) What input formats for 3D data? (XYZ spreadsheet, STRM, ASTER,
other?)
5) Survex data style for terrain?
6) Overlay maps onto terrain. (How? formats?)
7) What should happen when you try to print terrain (in plan, in
elevation)? 

But don't forget you can make up 'would be nice' features till you
are blue in the face. Nothing actually happens until someone writes
some code - a useful chunk of which has been sat there half-finished
for years...

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/