<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:blue;
text-decoration:underline;}
p.avgcert, li.avgcert, div.avgcert
{mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=EN-US link=blue vlink=blue>
<div class=Section1>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Thanks for exploring this idea Stacho.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>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.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I guess we are talking about making the
statistics consistent across the outputs –length, depth, surveyors,
explorers etc.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>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).<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>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…<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Could it be like this:-<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>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?<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>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.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I think most of the existing default
behaviours of ‘select’ could (and should) remain the same.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>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.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>To avoid missing any legs, the user could
explicitly select a survey at an appropriate level as well.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>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.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Congratulations for getting this far!<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Bruce<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>
<hr size=2 width="100%" align=center tabindex=-1>
</span></font></div>
<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>
therion-bounces@speleo.sk [mailto:therion-bounces@speleo.sk] <b><span
style='font-weight:bold'>On Behalf Of </span></b>Stacho Mudrak<br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, 18 November 2010
10:40 a.m.<br>
<b><span style='font-weight:bold'>To:</span></b> <st1:PersonName w:st="on">List
for Therion users</st1:PersonName><br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [Therion] FW: Source
and Select</span></font><o:p></o:p></p>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Best regards, S.<o:p></o:p></span></font></p>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>On 17 November 2010 09:26, Bruce <<a href="mailto:dangle@tomo.co.nz">dangle@tomo.co.nz</a>>
wrote:<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><br>
OK, I tried it.<br>
Selected a map containing a few caves, and a single survey, a small part of<br>
one of those caves in one of my datasets. The 2d pdf map produced a cave<br>
and reported 12km and the lists and 3d model in the same thconfig run<br>
reported a single survey of 45m.<br>
<br>
I see now it has always been this way, but was not what I had assumed for<br>
all these years. (One can never read the Therion book too carefully).<br>
<br>
It also explains the discrepancy in reported cave lengths between 2d pdf<br>
maps and the list outputs. If there are no scraps for a short length of<br>
survey, then the 2d pdf map does not report that portion of the cave length.<br>
<br>
This means that, assuming the surveys and maps are decoupled as is one of<br>
the supposed advantages of Therion (and I agree it is), it is therefore NOT<br>
usually possible to get a comprehensive set of outputs (2d pdfs, 3d models,<br>
lists of caves, continuations and surveys) that relate to a particular<br>
discrete SUBset of data (It is however possible to get these for the ENTIRE<br>
dataset at any level, but if the global effect of loop closures is to be<br>
accounted for at a lower level the outputs are unlikely to represent a<br>
consistent portion of the cave-unless map objects and surveys join at the<br>
same places).<br>
<br>
I agree Andrew, it would be good to select a map object and have all types<br>
of output refer to drawings and centrelines contained in that map object.<br>
It is the behaviour I was incorrectly assuming, and the inevitable<br>
discrepancies I had been putting down to bugs either in Therion or my<br>
haphazard data organisation.<br>
The reverse currently happens when a survey is selected I think. Ie all<br>
scraps are exported for selected surveys. This does not allow passage<br>
previews and offsets though.<br>
<br>
Martin, Stacho,<br>
Should/could Therion produce such synchronised outputs where maps are<br>
selected, or should the users have to make the boundaries of their map<br>
objects match survey junctions at key locations to enable them to get<br>
consistency between map based outputs and survey based outputs? The
later,<br>
status quo, is workable, but seems to make it difficult for the user and<br>
make interpretation of output statistics quite onerous.<br>
<br>
So if I were to suggest a specific change it would be that when maps are<br>
selected, only data relating to survey legs contained within selected maps<br>
would be exported.<br>
<br>
Or am I missing something?<br>
Comments?<br>
<br>
Regards<br>
<font color="#888888"><span style='color:#888888'>Bruce</span></font><o:p></o:p></span></font></p>
</div>
<p class=avgcert style='margin-bottom:12.0pt'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'><br>
-----Original Message-----<br>
From: <a href="mailto:therion-bounces@speleo.sk">therion-bounces@speleo.sk</a>
[mailto:<a href="mailto:therion-bounces@speleo.sk">therion-bounces@speleo.sk</a>]
On Behalf<br>
Of Andrew Atkinson<br>
Sent: Wednesday, 17 November 2010 6:56 a.m.<br>
<br>
Your suggested solution, is what I do, for 3d, and it works, but I have<br>
not used lists yet. However, it would be nice to be able to select a map<br>
and only get a centreline with this would be good, but I suspect too<br>
much work for it to be worth while. (plus lots of decisions about what<br>
exactly would appear in the output<br>
<br>
Andrew<br>
<br>
On 16/11/10 09:08, Bruce wrote:<br>
> My reading of the Therion Book suggests to me;<br>
><br>
> - that 'source' specifies the files that Therion should read and process<br>
> before deciding what to export. The source files should contain or<br>
> reference surveys and or a surface.<br>
><br>
> - that 'select' chooses which survey(s) and or map(s) from the above<br>
> files to export. If there is no 'select' statement then 'all' are<br>
exported.<br>
><br>
> My interpretation #1 is that this should allow all the surveys of a<br>
> large (or modest) system of cave passages to be referenced by way of<br>
> 'source' so that all the survey loop and scrap join distortions can be<br>
> processed BEFORE Therion decides what to export. This is what seems to<br>
> occur. So far, so good.<br>
><br>
> My interpretation #2 is that when a map or maps for any particular<br>
> projection is 'selected' then ONLY the data that relates to those maps<br>
> should be exported. This is what seems to happen for Map outputs (pdf<br>
> and ?kml) and Atlas outputs.<br>
><br>
> I have some difficulty and confusion with outputs that don't have a<br>
> projection, such as the lists, 3d outputs and database. What seems to<br>
> happen is that regardless of the 'selected' maps, all of the 'sourced'<br>
> data is exported to this type of output.<br>
><br>
> What I would like is that only the data related to the 'selected' maps<br>
> are exported. This way all subset outputs can be consistent (same loop<br>
> closure distortions applied), and separately exported.<br>
><br>
> In writing this out I suspect I may have realised the answer to my<br>
> question (but not yet tested it). Perhaps what I need to do is 'select'<br>
> survey(s) that encompass the same part of the cave as the maps?<br>
><br>
> Any insights or clarifications gratefully received.<br>
><br>
> Bruce<o:p></o:p></span></font></p>
</div>
</body>
</html>