Adding Terrain data/viewing

[Olly Betts]

On Tue, Sep 17, 2013 at 03:52:07PM +0100, Wookey wrote:
> +++ Matt Kirby [2013-09-12 19:07 +0100]:
> > Is there any intention to include a terrain function in future
> > releases, we have found it very useful for the Mulu stuff.

There is, but we really need something which is usable in general,
rather than specific to a particular survey project.

> 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?)

That was working, but it looks like the python subversion bindings it
needs got lost in the recent server upgrade.  I'll see if I can get that
fixed.

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

Or slicker:

git log --grep @2059

> 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.

This is the part which really needs sorting out.  Until Survex knows
what coordinate system is in use, trying to combine the survey data 
and other data in a known coordinate system (like GPS fixes, DEM files,
etc) has to dance around that fact.

I'm currently refactoring the findentrances stuff to be more general,
so hopefully this will be resolved fairly soon.

> 3) Add direct reading of DEM data files. And maybe an X,Y,Z survex
> data type too.
[...]
> 5) Survex data style for terrain?

I don't think we want to invent our own special formats for DEM data.
There are existing formats, so let's stick with those.  Any "*data
terrain" style isn't going to be typed in by hand by anyone sane, and if
you're writing code to generate a .svx file of "*data terrain", you can
just generate it in some suitable DEM format instead.

I think support for SRTM and ASTER is probably the first thing to aim
for, since these are free and have close to global coverage.

Cheers,
    Olly