[Therion] FW: Source and Select

[Stacho Mudrak]

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 <dangle at tomo.co.nz> 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
>
>
>  ------------------------------
>
> *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
>
> _______________________________________________
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20101118/eeaa8122/attachment.htm>