[Therion] topodroid to therion

[Marco Corvi via Therion]

*The meaning I meant to convey was; I don’t think I have seen a description
of exactly the settings and workflow TopoDROID users should use if they
want to export their data for Therion to process, in one place, and step by
step.  No doubt the detail is in the TopoDROID user manual, but it is
scattered around, and interspersed with information that is not
particularly useful for Therion users.*

bruce, you are right. i misunderstood.
a therion wiki page, a sort of "howto use topodroid for therion", is
probably a good idea

*And little indication of what settings will make life pleasant or
unpleasant for Therion users.  Many of the default settings seem to be
Therion unfriendly, as evidenced by the examples posted on the Therion
forum over the previous year or so, and my own subsequent experimentations.*

this is probably because the default values of topodroid settings try to
fit the average cave surveyor/cartographer, and only a minority of them
uses therion.
anyways, i think that the therion-relevant settings are only a few

*I suspect what is missing is a user guide that describes what to do to
ensure a pleasant Therion experience with data generated by TopoDROID.
Your post from 3-4 December is the first time I recall seeing such a
targeted user guide format, and I am wondering if a Therion wiki page based
on your post might fill that gap. *

however, i do not expect my way to be the best and the only one. i do not
think there is a definitive way to work from topodroid to therion. the
process depends also on the environment (=cave) and resources (=android
device/distox). the wiki page might provide general rules and point to
program features that are important for the drafting of maps with therion
and cave project managing.

* I am happy to create the outline of a wiki page and fit it into the
Therion wiki structure somehow.  If I start something, maybe someone else
can fill in the gaps*

as i said, i think it's a good idea.
do it.
and i hope other users add in their advices

marco
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] topodroid to therion

[Marco Corvi via Therion]

i apologize the cut-n-paste, but i get post in digest
and i try to keep reply short.
- - - - - -

That is a good description.  I can see a wiki page developing from it. I
don’t think I have seen similar information before?

that info is in the user manual, more or less

It is a while since I played with TopoDROID.  Is it the intention that one
TopoDROID sketch produces, or is equivalent to, one matching pair of
Therion scraps (plan and elevation)?

yes, initially sketches were saved as th2 files. then i realized users were
drawing huge sketches (well over 1 km), so i turned to a binary format (and
a cache) to speed up opening (and saving) the sketches

I am interested in the data naming conventions you use, to facilitate the
tracing of parent and child object relationships (ie data files (TopoDROID
and Therion) through to survey and scrap, for example).

the survey name is the base name.

sketches append their name to that of the survey, separated by a dash, and
with suffix 'p' or 's'
survey name and sketch names can be chosen by the user (topodroid suggest
numbers for sketch names).
cross-section names are chosen by topodroid (eg "xx1" etc; there are four
patterns, if i'm not mistaken, for four different types of cross-section)

scraps take the name from the file
the xvi scale is almost 1:39.37 (the exact number is somewhere in therion
sources)

an exported data file (.th) contains input for all its sketches (.th2
files), and map commands.
however these are all under comment.

topodroid does not create the thconfig file

And I should just check exactly what you mean by ‘mid-line’?  I have always
been guessing. Is it the survey shot line that goes from ‘from station’ to
‘to station’?

midline = the set of legs

marco
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] topodroid to therion

[Marco Corvi via Therion]

Is there a workflow that is easy to use with ‘TopoDROID to Therion’
process, that also allows more than one scrap per survey trip file?  With
limited experimentation (and making assumption that TopoDROID ‘sketches’
might be approximately equivalent to Therion ‘scraps’), I have not yet
found a way that is easy to implement and encourages a naming convention
that eases tracing of scraps to their parent TopoDROID file.  And breaking
existing scraps into smaller scraps is a task I find unnecessarily tedious,
when one could just have drawn smaller scraps in the first place.

Am I missing something obvious?  What are experienced Therion users who
subsequently became proficient with TopoDROID as a data collector doing in
this space?

--
topodroid has many features requested by users that probably use other
programs than therion to draft their
cave maps,

anyways, i use therion for my cave maps, and here is what i do.

(0) a note3 with a stylus: reasonable compromise between the size of the
android and that of the caves (lucky surveyors might go for a 7" tablet)
(1) enable only drawing tools that are supported by therion, otherwise i
must go for metapost code
(2) each topodroid survey can have many sketches, and i usually draw
several sketches, except for very simple surveys.
(3) switch off fractional 'extend"
(4) switch off loop closure compensation: better see potential blunders
(5) i usually use "normal" line style, and the decimation button to
simplify them (if need arises)
(6) pre-exporting: check every sketch with joining sketches using the
sketch outline feature, and make then fit nicely
(7) it may happen that a sketch needs to be splitted in two, but this is
rare as i'm used to draw small sketches.
i never user sketch merge
(8) i use automatic station points, even if, unfortunately,
topodroid puts in all the stations in the convex hull of the sketch, and
there can happen spurious ones. i do not remember if midline hide helps for
this, however, midline hide is something i use only when the midline is
very messy, i usually go over the station points and remove those that do
not belong to the piece of midline of the skatch: this is easily done with
a "good" text editor
(9) i usually do not use "line continuation", but i fix the gaps between
wall lines with point line editings (snap to point and merge with line). i
sometimes use the feature that shifts a portion of a line, but i find often
easier to redraw the line and erase the old one.
(10) i have the feeling that outline is no longer very important to therion
(it is however for csurvey, but this is ot on this list), thus i do not pay
much attention that wall lines are properly oriented. anyways when i notice
a line should be reversed i do it, as it's quick
(11) automatic export because it's a nuisance to export each sketch
(12) ... other things i do not recall at the moment

marco
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] topodroid lines

[Marco Corvi via Therion]

sorry for the late reply (i read digest)

there is a setting in topodroid to set the spacing of line points.
units of screen pixels, i think (not sure, i should check)

there are also a couple of setting to control how cubics are generated

apks: besides google play store,
some are on the site (which is on google, but i suppose does not require
sign-in)

marco
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] boxed label

[Marco Corvi via Therion]

hi bruce,

this is a boxed u:label
basically it gets the string as picture,
its bounding box corners, and define the x and y to draw the box,
then draw the string picture

point 10 20 u:label -attr val 20

def p_u_label ( expr p,r,s,t ) =
  picture pic;
  pic := thelabel( ATTR_val, (0,0)) scaled s;
 pair q[]; numeric n[], m[], v;
 path bb;
 v := defaultscale;
 qO = ulcorner pic;
 q1 = lrcorner pic;
 nO := ypart q0 + 2.5 * v;
 n1 := ypart q1 - 1.5*v;
 m0 := xpart q0 - v;
 m1 := xpart q1 + 1.5*v;
bb := (m0,n0) -- (m0,n1) -- (m1,n1) -- (m1,n0) -- cycle;
draw bb  rotated r shifted p;
draw pic rotated r shifted p;
enddef
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] coloring

[Marco Corvi via Therion]

thanks bruce
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] coloring

[Marco Corvi via Therion]

what about a scrap option "-color" that overrides the layout foreground
color ?

survey too could have a color option.

marco
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Therion Digest, Vol 151, Issue 3

[Marco Corvi via Therion]

in reply to markus question:

quick answer is 'no":

(1) semantics are different: therion is richer, topodroid has features of
its own.
(2) therion is OFFline (post)processing,
topodroid is ONline processing
(3) focus: large for therion, small for topodroid
(4) maybe something else

marco

On Thu, Jul 5, 2018, 12:00  wrote:

> Send Therion mailing list submissions to
> therion@speleo.sk
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mailman.speleo.sk/listinfo/therion
> or, via email, send a message with subject or body 'help' to
> therion-requ...@speleo.sk
>
> You can reach the person managing the list at
> therion-ow...@speleo.sk
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Therion digest..."
>
>
> Today's Topics:
>
>1. from therion back to topodroid? (Markus Boldt)
>
>
> --
>
> Message: 1
> Date: Wed, 4 Jul 2018 18:51:39 +0200
> From: "Markus Boldt" 
> To: "List for Therion users" 
> Subject: [Therion] from therion back to topodroid?
> Message-ID: <003701d413b7$47897280$d69c5780$@gmx.net>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> is there a possibility to get a topodroid-file from therion?
>
> Markus
>
>
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://mailman.speleo.sk/pipermail/therion/attachments/20180704/04f20fce/attachment-0001.html
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
>
> --
>
> End of Therion Digest, Vol 151, Issue 3
> ***
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] extend

[Marco Corvi via Therion]

i put together comments to all the posts
about "extend"

(1) yes, -1 = left, 1 = right and vert is in the middle (0)

(2) evaristo, with his proposal of idealized profile not only suggested a
way to control shortening, but that also allows stretching. that's good

(3) bruce described a procedure for a program to automatically decide how
to draw splays in the extended profile.
it's more or less what topodroid implements: at a station the range of
azimuths is divided into angular sectors one for each leg at that station.
a splay is "projected" using the leg of the sector its azimuth falls in.
(by the way, to really be in bad luck one need three vert in a row)

(4) a program may assign extends to splays automatically, but the user
should always be allowed to override what the program does.
(that's why a user can set extend also for splays, in topodroid)

(5) "cave length": in the (old) manuals i studied that the cave length is
"computed" measuring the length of an ideal line that goes thru the middle
of the passage.
now it is rather cumbersome to compute that line, and all the programs uses
the length of the midline, with some discount (duplicate in therion, L in
compass, and so on).
the problem, i think, is that cave length is not a thing that can be
well-defined.
so the numbers we give for cave length are an approximation of a fuzzy
concept.

marco
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] extend

[Marco Corvi via Therion]

i think that extend should take values in the interval [-1,1], ie also
fractional values, plus some special value such as "ignore" to open loops,
and "undefined" to let the program choose, because it's a nuisance to enter
a decimal number for every shot (legs + splays).
therion uses the left/right normal/reverse etc. solution,

and users should be allowed to set extend also for splays, if they need to.

for now, let's use left/right/vert, and ignore only to open loops

btw, are vertical extend considered in the computation of the cave length
by therion ?

marco
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Conflict between "extend ignore" command and inverse legs

[Marco Corvi via Therion]

I have commented all the splays "extend ignore", and Therion is doing
now a good job, ignoring the appropriate leg (extend ignore 83 92). All
the splays "extend ignore" was confusing the Therion compiler.

This data is an export from Topodroid, that incorporates the "extend
ignore" command before the splays shots. I will comment to Marco Corvi
on the problem.

@ Evaristo & Bruce:
what about a command "extend auto", which means let therion decide how to
extend the splay shot ?

for the moment therion parser could behave as if the command weren't there.

marco
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] Fwd: Extended elevation discussion

[Marco Corvi via Therion]

here is a short mail exchange with bruce about "extend"

i played a little with the extend command. there are many variations (1 and
2 are stations)
- placing it before the data or after them
- "extend ??? 1 2" or "extend ??? 2 1"
- with an "extend ???" in the data or not
- combining with "extend ??? 1"

not considering the variations on the theme when there are crossways and
loops

and the interaction with "flip horizontal"

maybe someone with plenty of time (and patience) will go thru the analysis
of how therion handles these commands . . .

personally i use "absolute" extends the data. and it's been years now since
i used "flip" (in therion).

we moved from lrud to splay.
what about going from L/R to fractional extend (including nil to break
loops) ?

marco

-- Forwarded message -
From: Bruce Mutton 
Date: Wed, May 2, 2018, 21:48
Subject: Extended elevation discussion
To: Marco Corvi 


Hi Marco

Glad you are spending time caving.  And is good to be disconnected
sometimes!



Yes, extend is mysterious.  Your commentary is insightful and appreciated.

   1. *Separating extend data from survey data:*   choice will depend on
   what is important to the map author.
   *Advantages* = like information is kept together, dissimilar information
   is kept separate; able to have many different extend elevation shapes for
   one survey.
   *Disadvantages* = you have duplication of survey leg enumeration for
   each extended elevation.  Sometimes every leg needs to be duplicated, but
   sometimes only at changes of extend ‘state’, so duplication can either be
   minimal or extensive, depending on the project.

   Enumerating extend stations and legs in the opposite direction (2 1) to
   what they are enumerated in the survey data (1 2) is usually OK. It often
   requires more explicit enumeration than if both progress in the same
   direction.  I have done it a number of times.  Sometimes ignores will only
   work in one direction, as I noted in the web page.



   1. Yes, I think *extend left/right may behave like revise*, I have
   thought that.  Pretty sure I have had cases where I have conflicting
   directions on the same leg, and the last one read will take precedence.  I
   tend to weed these out, as extend is unpredictable enough without leaving
   such things in the data!



   1. *Flip and left right normal reverse*: Good point, I had not thought
   of that.  However, I am always explicitly left and right myself.  While I
   have had some issues with flip, I don’t expect they are related to explicit
   extend directions.  What I do suspect is that some symbol alignments to not
   respond well to flip, and I suspect that implied joins of scraps (where
   line end points are snapped together within the same file) might tend to
   wreck flipped scraps.  That would be obviously user error if one scrap is
   flipped but not the other. The attached example from a few years ago shows
   what can happen if scraps are flipped.  I should go back and see if both
   scraps where flipped or only one!



This conversation might be useful to have on the forum.

Feel free to forward it to the forum if you like.



Bruce



*From:* Marco Corvi 
*Sent:* Wednesday, 2 May 2018 11:05 PM
*To:* Bruce Mutton 
*Subject:* Re: Extended elevation page



hi bruce,



sorry for the late answer;

i was off caving in an area with no connection.



i looked at the extend page.

that''s fine with me.

recently i have been just following therion news, without spending much
time to check out things with examples, except in a few cases.



about extend:



1) i think it's not a good idea to separate leg data from leg extend,
because you have to write the leg "name" (the stations) twice.

what happen if you have "1 2" with data and "2 1" with extend ? i do not
know, i have to check when i get home.



2) i think that the syntax "extend right 1 2", might be a sort of revise,
ie, it overrides the previous value. again i have to check this too



3) normal/reverse may be better than left/right, when you use flip



that said i tend to use absolute extend (left/right), but maybe it's time
that i go relative.



extend is a diffucult topic, and your page is a good idea. there are many
different situations for "extend"; you may add the examples in subpages.



marco



On Mon, Apr 30, 2018, 12:25 Bruce Mutton  wrote:

Hi Marco

I sent this message to the Therion forum a few hours ago, and have not
received a mail back yet, so I am wondering if it is broken in some way, I
notice the website has been responding very slowly all day.  However I
could edit the wiki just fine.

Anyway, reason for this email is to let you know about the new Extended
Elevations  page, and checking that
you are happy with what I have written, and references to your altervista
pages.

And perhaps you have further 

[Therion] Disto Data Recovery

[Marco Corvi via Therion]

topodroid can dump to a text file the data that are still in the memory of
the distox.

if you have a distox1  (A3 leica) it can also reset the hot bit and make
the distox resend the data.

both functions are "low level" (they access the memory), and not for common
use.
it can help if you do not want, or cannot, do the survey again.

marco
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Linux and DistoX (Wookey)

[Marco Corvi via Therion]

So, thanks to me giving a competent person (who also doesn't own any
Windows or Android devices) a couple of distoX's that needed ...

At the moment this only works with python3 and distoX1, But Stuart
plans to use the topodroid codebase to work out the differences for the
X2 protocol (unless anyone has a doc for this already, or Marco can
tell him).


wookey,

i may be not precise because i do not have the docs at hand.

the distox2 protocol is backward compatible.

therefore, getting the calib raw data from the distox2 is the same as in
distox1, namely two data packets, one for G, one for M.

the commands to toggle calib mode on and off are the same, too.

the computation of the calib coeff has changed a bit with firmware 2.2 (or
2.3, don't remember well) beat added three non-linear coeffs, and these are
written after the other 24.
there is a catch: in the distox1 those mem are set at 0xff (ie -1), so
these three coeff are written with 0 getting to 0xff.
the non-linear calib should not be used for older firmwares.

i have not changed the linux code, and
i do not think to have the time to do that.
i also understand you may not want to use android, but you can use the
android code and turn it in C++
the computational methods are very much C like, and the helper classes are
just basic linalgebra.

if you or stuart have any question, send me email

marco
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion