> (5) "cave length": in the (old) manuals i studied that the cave length is "computed" measuring the length of an ideal line that goes thru the middle of the passage.
> now it is rather cumbersome to compute that line
In Ukraine we are using term "Projected Cave Length", which is length of middle line of cave plan, for more or less horizontal caves,
or middle line of extended elevation for vertical ones.
In practice good middle line approximation is skeletal line of 2d shape, computed on its vector or raster representation.
Also Global Mapper has feature to compute middle line.
So when dealing with therion output i.e. plan in kml format it is possible to compute projected cave length in Global Mapper.
If your input to calculate projected cave length is raster monochrome mask of cave internal area in any projection (plan|ext)
than you can use thinning algorithm to produce single-pixel line and then vectorize it.
In the 2010 I and A. Vechenko implemented own app to automate cave projected length calculation using raster data:
Raster gets thinned and then vectorized in the way similar to use r.thin + r.to.vect, but in gui app and with different thinning algorithm.
Certainly raster-based approach has some drawbacks, such it is unable to do proper calculation for overlapping passages
(GlobalMapper capable to handle overlapped plans to compute centerline),
you need to do a post-process near entrance areas and so on, but it has significant advantage - raster skeleton can be computed
very fast, compared to vector-based algorithms (cavevaluer is not the fastest one, it is possible to do factor 100x faster on GPU).
Thinking about how it should be done in general, not relating to projections - is to compute 3d skeleton from 3d cave model,
then we will have a good length approximation in all meanings.
For convenience, attaching our with A. Verchenko thesis about the raster algorithm in Ukrainian language.