Survex 1.0 within sight

[Olly Betts]

In message <200008161339.OAA17270@pc9.mcs.le.ac.uk>, Gavin Lowe writes:
>1. Allow the user to include legs that are used for calculating the
>coordinates, but omitted from the survey diagrams.

This would need a revised 3d format which I'm trying to avoid for 1.0 (for
time reasons).  But you should be able do this fairly easily using chasm.
Just put the legs to be hidden in a different survey prefix, then in chasm
hide that prefix, then do a printout (from chasm).

>For example, the Pozu
>Jultayu streamway has a choke where the survey gives the downstream end as
>being higher than the upstream end (oops!).  I've hacked this by adding a
>horizontal leg through the choke, but this leg should not be included in
>the survey diagrams.  (BTW, is there a better solution to this problem?)

Not really.  For this what you really want to say is that one station is
below another, but not say anything horizontally.  Survex's current notion
of connectedness is all or nothing - you can't have connections in only some
directions (the obvious distinction to draw is horizontal vs vertical).

You *can* process data with no clino readings, but that is handled by using
the adjusted tape reading to determine a variance for the vertical
change.

>2. Differentiate between magnetic deviation (i.e., the difference between
>magnetic and grid north) and calibration (i.e., the difference between a
>particular compass's reading and magnetic north).

You mean like "*calibrate compass ..." and "*calibrate declination ..."?
That's been in for years, and is documented:

http://www.survex.com/docs/svxdocs/datafile.htm#AEN631

>3. Allow the user to specify where Survex looks for input files.  For
>example, I'd like to do something like (under csh):
>
>setenv TEXINPUTS .:${SURVEXHOME}/share/survex:~/Caving/Expedition/Surveys/MagD
>ev
>
>and have Survex search those directories in that order (to allow it to pick
>up files defining the BCRA grades, and magnetic deviations for different
>years, respectively).

The problem with this scheme is that you can't then easily package up the
dataset and send it to someone, archive it, or whatever since (a) the files
aren't all in one place and (b) information needed to process the dataset
(i.e. this environmental variable) isn't stored anywhere in the dataset.
And even if it were, it's not likely to work unchanged on a different
machine.

I wonder if fact magnetic declination is perhaps better handled by having an
"auto" option to "*calibrate declination" (which perhaps would be better as
"*declination" since it doesn't work like the other calibrations), and then
allow declinations to be specified by date (or perhaps even automatically
determined from the date and coordinates).

Cheers,
Olly