Interactive Extended Elevations

[Olly Betts]

In message <00062410020200.00811@localhost.localdomain>, Phil Underwood writes:
>On Fri, 23 Jun 2000, Olly Betts <olly@survex.com> wrote:
>> * where to force folds (by default heuristics would decide where to fold by
>>   looking at the trends in angles between survey legs)
>
>I've tried this using a fairly simple algorithm; comparing the bearing of
>the next leg with the previous one. It doesn't work at all well - you tend
>to get reversals where you don't expect them, and it doesn't reverse where
>you'd expect it to.

Survey legs havee a tendency to zigzag across the passage in places so you
need to look at the trends, or better still make use of passage dimension
information.

>I would prefer to have no automatic folding, meaning
>that everything has to be done by hand; there are usually only a few folds
>required for any particular extension. Also, having automatic folding could
>result in an extended elevation gaining or losing a fold when (say) another
>loop is added to the survey, slightly changing the data used, and taking a
>particular bend over the cut-off for folding. I don't know how often this
>would happen, however. 

Hmm yes, perhaps better to have any auto-folding as an option in the
front-end?  If the results of auto-fold were accepted then the would be
stored just as any user-supplied folding would be.

>> * where to break loops (again heuristics can make a default stab)
>This is done fairly primitively in my existing extend routine - but it
>breaks at junctions, which I agree is poor.

Looking at existing extended elevations it seems a human would rarely choose
to split at a junction - it's more usually in the middle of a "bland" bit of
passage.

>Another question (I think this
>was debated before, but I've forgotten if any consensus was agreed) is
>whether one specifies a leg or station to break at. Legs are certainly
>easier to code for, and what should occur if a 4-node (say) is marked as
>breakable?

Isn't breaking a station effectively the same as breaking some or all of the
legs attached to it?  In which case perhaps best to stick to legs (at least
internally - the UI could still allow a station to be broken).

>*begin pedant
>1 2  4.51  217 +05
>1 2  4.49  216 +04
>1 2  4.50  218 +05
>*end pedant
>
>How would one refer to the second leg in this file?

Hmm, tricky.  Would it be acceptable to say that such groups of legs must
always be broken together?  I can't see how it would be useful to break them
individually (although it does seem a bit icky to lump them together).

>>The only slightly tricky case I can see is where a connection is made back
>>to the EE from excluded survey (e.g. ambidextrous, which connected the right
>>hand route back to the left hand route a couple of hundred metres below
>>where they originally split.  But that can be detected automatically (using
>>a node colouring algorithm) and the user prompted about what to do.

>Could you send me a brief explanation of what a node colouring algorithm
>is? I'm guessing that it probably doesn't actually have much to do with
>red,green, blue stuff.

Give each station a flag and set all these flags to false.

For each break point, colour the station on the far side of the break point
by setting its flag.  Then recursively do the same for each of its unflagged
neighbours (unless connected only by a broken leg).  If your colouring
reaches the station on the near side of the break point then you have a
problem.

The flags are really just an easy way to stop you from wandering round in
circles.

You may want to avoid actual recursion in the implementation since for a
large survey you can potentially use up a lot of stack space, and may cause
stack overflow on some platforms.  Look at netartic.c for one approach
(though not an especially clean one).  If there's no state which needs to be
stored for each recursion then it can be a lot cleaner (in fact a good C/C++
compiler might be able to eliminate the recursion by itself in such cases).

Cheers,
Olly