[Therion] Topparser response

[Bruce]

Andrew

 

Thanks for those revised input/output file instructions - makes perfect
sense now.

 

>> Perhaps the plan and elevation scraps should be forced (or at least 

>> have the option)to inherit the map suffixes entered on the Data TAB 

>> (and then the specific plan, elevation and section suffixes entered on 

>> the plan and elevation TABs).

>> 

>> This would ensure better consistency and ready recognition by the 

>> human user of the relationship of particular scraps - maps - files.

 

>Sorry not sure what you mean, do you mean that they all should be
NewPassageSuffix.

>Can you give an example, this is different from what I do

 

The approach I am trying to enforce is that each object inherits the name of
it's parent, and any suffixes that might have been appended to the parent
(or grandparent).  Also that each object name describes quite explicitly and
unambiguously what it contains (but not overly verbose). Pretty close to
what Topparser encourages already.

 

eg

Survey name: 404-Quackery

 

Associated maps are therefore named;

404-QuackeryPlan

404-QuackeryElevEXT

404-QuackeryElev290

Etc

 

Topparser encourages this at present.



 

(A somewhat unrelated observation: Maps do not need to be children of the
surveys they are based on, but the way Topparser currently creates them they
are.  Therion does allow them to be outside of the 'survey' 'endsurvey'
block, and indeed outside of the survey.th file altogether.  This is another
topic however, but it could add complexity to Topparser in due course. For
now it is easy enough for the user to move the map definitions to another
file if they so wish.)

 

Children of the maps (scraps) are therefore named;

404-QuackeryPlan-s1, 404-QuackeryPlan-x1

404-QuackeryElevEXT-s1, 404-QuackeryElevEXT-xp1, 404-QuackeryElevEXT-xv1

 

All the above can be achieved with Topparser at present, but you have to
duplicate part of the suffix as in these screen dumps.



 

The current implementation cannot mimic the type of inheritance I would like
for projected elevations however;

404-QuackeryElev290-s1 is what I would like, but;



The above produces;

404-QuakeryElev-s290_1

 which is at odds with the rest of the object naming.

 

So in summary, Topparser in general allows scraps that are not named the
same as the th2 file they are inside of.  While this might allow for more
abbreviated scrap names it is not what the Therion wiki recommends (sure
I've seen it somewhere :) ).

This can be compensated for as in the examples above in all cases except for
projected elevations.

 

A minor thing that is easy for the user to overwrite each time - but worth
considering.

 

Bruce

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20130729/6745bd04/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 18967 bytes
Desc: image003.jpg
URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20130729/6745bd04/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 13469 bytes
Desc: image004.jpg
URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20130729/6745bd04/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 14105 bytes
Desc: image005.jpg
URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20130729/6745bd04/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.jpg
Type: image/jpeg
Size: 12151 bytes
Desc: image008.jpg
URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20130729/6745bd04/attachment-0003.jpg>