[Therion] FW: Source and Select

[Bruce]

I think 'centerline by centerline' is best, as this how the input statistics
are grouped when entered anyway.  In cases where a centerline crosses a
major boundary in a cave, users can easily break the centerline into two.
It will result in less 'holes' in the reported statistics than 'leg by leg'.

 

Does this increase the need for a bit more 'input echo' in the outputs?

Maybe a listing of user selected maps and surveys;

-          in therion.log (and in .xtherion.dat for highlighting in
xtherion),

-          in the 'keywords property' of pdf outputs,

-          as a header in list outputs and header option in pdf outputs?

 

On the topic of input echos.

There were some discussion 18 months ago about adding output co-ordinate
system, north type and rotation echos to headers.  I think this is still
pending.

Tasks #9006 #9011 #9583 on the savannah page have a similar flavour.

(Sounds like another whole project)

 

Bruce

  _____  

From: therion-bounces at speleo.sk [mailto:therion-bounces at speleo.sk] On Behalf
Of Stacho Mudrak
Sent: Thursday, 18 November 2010 11:19 p.m.
To: List for Therion users
Subject: Re: [Therion] FW: Source and Select

 

Currently it is done on the "centerline" by "centerline" basis :) I.e. for a
selected map, it collects all centerline objects, where map stations are
surveyed and groups teams, lengths and depths.

But I like your idea, to add there also data from selected surveys and maps
from other projections. This would be more or less backward compatible but
it will definitely avoid confusions. I will try to do it like that.

Thanks a lot, S.

On 18 November 2010 09:24, Bruce wrote:

Thanks for exploring this idea Stacho.

After I posted I realized that each projection is independent and if we let
it, it would create a lot more permutations and make any changed behaviour
much more complicated for the user to understand or manage than the present
behaviour.  To be avoided.

 

I guess we are talking about making the statistics consistent across the
outputs -length, depth, surveyors, explorers etc.

 

If I understand properly, your first option - specify a map for each
projection to go with a selected survey.  So if you select this survey,
means you will get this particular map or atlas, and the statistics for the
survey will be reported with all outputs exported with that thconfig run.  I
think this is flawed because each survey could have a number of plan
projection maps (although unlikely because Therion is good at allowing 'many
maps from one drawing') but each plan map is only likely to have one survey
network. (I'm assuming re-survey projects will probably create new maps to
go with the new survey network).

 

Your second option seems workable.  Each map 'knows' which survey legs it is
connected to.  To some extent this must already happen.  I've drawn a
diagram to help me understand to relationships between selectable objects,
exports and data flows.  I may ponder on it some more before distributing.

Could it be like this:-

Therion collects statistics from explicitly selected surveys (if any) and
all selected maps over all projections, and (temporarily) stores a
collection of the aggregated statistics (length, depth, surveyors, explorers
etc) and then these are reported consistently across all exported outputs
for this thconfig run?

 

I suspect most beginner to intermediate users would not notice any
difference from the current situation, indeed this behaviour might be what
they expect anyway.

 

I think most of the existing default behaviours of 'select' could (and
should) remain the same.

 

Would the survey statistics extracted by selected maps be done on a 'leg by
leg' basis or a 'survey by survey' basis?  I am assuming 'leg by leg'.
There is a danger that the map might miss some legs where passage direction
is complicated and scraps join.  Similarly the reason for using aggregated
statistics across projections, is that I expect that often some parts of
surveys are not drawn in some projections.  Eg a system that includes a
large shaft system may not have complete plan drawings for the whole 300m
depth of a multi pitch shaft, much as projected elevations do not have
complete drawings for those passages the travel 'into' or 'out of' the page.

To avoid missing any legs, the user could explicitly select a survey at an
appropriate level as well.

 

The alternative of 'survey by survey' could result in over reporting of
statistics for many maps, where the component surveys extend beyond the
drawn maps.

 

Congratulations for getting this far!

Bruce

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20101119/9f5b4e79/attachment.htm>