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.html>
