Ok, thanks for the heads-up. I'll le them know.

Prima!

OK, will let my friends know :). Thanks.

great! looking forward to it! :)

great thanks!

Got an email from Marco, shot/splay notes will be added to topodroid regular csv export with next release.

Got a couple of email exchange with Marco,

Re: Therion import : looks like the only difference between *.th from TD and from Therion is the very first line i.e.: "encoding utf-8".
As adding this line to a *.th file issued by TD, seems to make CRP happy on import, he's going to add that first line to the *.th export

Re csv import : at the moment, the only way to get the Notes (=splay/shot comments) from TD in the csv format is to export the raw data as well (tick box on export). But CRP doesn't seems to like the extra raw data. I have suggested to add the notes within the default export. will see what he says.

At the moment, the only way I have found to get the Notes imported in CRP is to use *.tro format.

1) I have tried importing Therion files straight out from TopoDroid as the Notes written in TD are not exported in *.csv file.
I suppose if several softwares use the csv format as import format, it might be more complicated for me to ask Marco Corvi to make such a change.

2) Done

I have a survey with "info" on splays but not on stations. I just run a test, title, info, material and tasks are actually displayed for stations but not for splays so that's why I wasn't seeing anything. Not sure if it is the normal, but if it is I think all these fields should be displayable on splays as well.

The idea would be to use the already existing column "LRUDs". My suggestion is not to create classical LRDUs from the Magic LRDUs feature selecting the 4 columuns. The idea is to define 4 splays as LRDUs. then LRDUs can be based on their actual length, azimut and inclinaison and match what the surveyor thought would be the best measurements to render the cave volume. I'm sure this would improve the Volume display, primarily in side-way slanted galeries, as classical LRDUs only works well in tubic galeries or pits.

sounds like a good option. I guess this could be applied to "profile" as well as if all splays are displayed, the profile can be far away from the results we are looking for.

what do you think of my second option... pickable LRDU?

sounds like a good option.

what do you think of my second option... pickable LRDU?

hmmmm... maybe the cone angles were too large.

Hi Jorchen,

As you know, I do loads of splays to the point where LRUDs are pretty much meaningless to me. However, I still acquire LRUDs just after my station to station shoots, because they improve flagging a station change in a massive amount of data lines in case Topodroid missed an change of station (i.e. 3 similars shoots). I also acquire them to make sure I have the LRUDs I want in case I go for a simplified version of the volume. Splays acquisition strategy can be very different from LRUDs. I always have many splays that reach walls far beyond the next/previous stations or even several stations. This allow me to enhance the characterisation of the volume as well as ensuring that the data are consistent. By doing this, magic LRUDs become an awkward tool to use as it will use all the splays, and not only the one likely to be LRUDs.

I see 2 improvements that could be made:

1 - magic LRDUs only use splays within 4 cones (Left, Right, Up, Down) based on the LRUDs mode selected (0,1,2,3,-1,-2,-3) for its axis direction and a setting defining the cone angle (+/- 15-20° by default?). Any splays out of these cone volumes should be disregarded for LRDUs calculation.
[[File:LRDUs1.png|none|auto]]


2 - add an option in the LRUDs mode column to define which splays to use as LRUDs (L,R,U,D). This could improve the volume rendering, as it would provide slope and direction to selected LRDUs.
[[File:LRDUs3.png|none|auto]]
[[File:LRDUs2.png|none|auto]]

I replied to Pascal in PM... and in French!

Thanks for your inputs! I found the issue: the file had 2 caves with same ID... . Problem solved with paste issue as well.
To avoid this to happen, maybe there should be a test on cave ID uniqueness when entering or editing the cave ID.