[Therion] FW: Source and Select

Thu Nov 18 09:24:06 CET 2010

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

  _____  

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

Well, as you have noticed, map selection and survey selection are completely
independent - even map selections are independent between projections. With
exception of maps, everywhere else survey selection is used.

Do you have some idea, how to solve this discrepancy? Normally, just survey
selection could be enough. But then there need to be specified the map -
that need to be shown, when this survey is selected (link survey - map). But
then you will loose a possibility to export all scraps from given survey if
some of them will not be included in that map.

Or the other way - discrepancy between lengths in 2D and 3D could be solved
by adding a link from map to survey. Which way would you prefer? For me,
probably the second one is better. If there will be link from map to survey
- than this survey could be selected, when a map is selected and
length/depth from this survey could be taken into account.

Best regards, S.

On 17 November 2010 09:26, Bruce <dangle at tomo.co.nz> wrote:

OK, I tried it.
Selected a map containing a few caves, and a single survey, a small part of
one of those caves in one of my datasets.  The 2d pdf map produced a cave
and reported 12km and the lists and 3d model in the same thconfig run
reported a single survey of 45m.

I see now it has always been this way, but was not what I had assumed for
all these years. (One can never read the Therion book too carefully).

It also explains the discrepancy in reported cave lengths between 2d pdf
maps and the list outputs.  If there are no scraps for a short length of
survey, then the 2d pdf map does not report that portion of the cave length.

This means that, assuming the surveys and maps are decoupled as is one of
the supposed advantages of Therion (and I agree it is), it is therefore NOT
usually possible to get a comprehensive set of outputs (2d pdfs, 3d models,
lists of caves, continuations and surveys) that relate to a particular
discrete SUBset of data (It is however possible to get these for the ENTIRE
dataset at any level, but if the global effect of loop closures is to be
accounted for at a lower level the outputs are unlikely to represent a
consistent portion of the cave-unless map objects and surveys join at the
same places).

I agree Andrew, it would be good to select a map object and have all types
of output refer to drawings and centrelines contained in that map object.
It is the behaviour I was incorrectly assuming, and the inevitable
discrepancies I had been putting down to bugs either in Therion or my
haphazard data organisation.
The reverse currently happens when a survey is selected I think. Ie all
scraps are exported for selected surveys.  This does not allow passage
previews and offsets though.

Martin, Stacho,
Should/could Therion produce such synchronised outputs where maps are
selected, or should the users have to make the boundaries of their map
objects match survey junctions at key locations to enable them to get
consistency between map based outputs and survey based outputs?  The later,
status quo, is workable, but seems to make it difficult for the user and
make interpretation of output statistics quite onerous.

So if I were to suggest a specific change it would be that when maps are
selected, only data relating to survey legs contained within selected maps
would be exported.

Or am I missing something?
Comments?

Regards
Bruce

-----Original Message-----
From: therion-bounces at speleo.sk [mailto:therion-bounces at speleo.sk] On Behalf
Of Andrew Atkinson
Sent: Wednesday, 17 November 2010 6:56 a.m.

Your suggested solution, is what I do, for 3d, and it works, but I have
not used lists yet. However, it would be nice to be able to select a map
and only get a centreline with this would be good, but I suspect too
much work for it to be worth while. (plus lots of decisions about what
exactly would appear in the output

Andrew

On 16/11/10 09:08, Bruce wrote:
> My reading of the Therion Book suggests to me;
>
> - that 'source' specifies the files that Therion should read and process
> before deciding what to export. The source files should contain or
> reference surveys and or a surface.
>
> - that 'select' chooses which survey(s) and or map(s) from the above
> files to export. If there is no 'select' statement then 'all' are
exported.
>
> My interpretation #1 is that this should allow all the surveys of a
> large (or modest) system of cave passages to be referenced by way of
> 'source' so that all the survey loop and scrap join distortions can be
> processed BEFORE Therion decides what to export. This is what seems to
> occur. So far, so good.
>
> My interpretation #2 is that when a map or maps for any particular
> projection is 'selected' then ONLY the data that relates to those maps
> should be exported. This is what seems to happen for Map outputs (pdf
> and ?kml) and Atlas outputs.
>
> I have some difficulty and confusion with outputs that don't have a
> projection, such as the lists, 3d outputs and database. What seems to
> happen is that regardless of the 'selected' maps, all of the 'sourced'
> data is exported to this type of output.
>
> What I would like is that only the data related to the 'selected' maps
> are exported. This way all subset outputs can be consistent (same loop
> closure distortions applied), and separately exported.
>
> In writing this out I suspect I may have realised the answer to my
> question (but not yet tested it). Perhaps what I need to do is 'select'
> survey(s) that encompass the same part of the cave as the maps?
>
> Any insights or clarifications gratefully received.
>
> Bruce

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20101118/6b244fc2/attachment.htm>