Hi Bruce, could you please try f18c718? I had a similar issue with my dataset. S. On Mon, 8 Mar 2021 at 05:58, Bruce Mutton <bruce@tomo.co.nz> wrote:
Good afternoon or morning
I have a situation that I suspect might stem from user error, because it affects only one project, the data is a little messy, and there are 30 m miscloses involved, although Therion is good at dealing with such things, so maybe that is not significant.
My other suspect is the kml model generation code, because that is apparently the only thing that falls over. This has been, for this project only, a problem for many years, and through many versions of Therion, although it is likely that there was an old version that compiled it OK. I have tried it on yesterday’s version 3e14a09 and the behaviour is the same.
It is a large project involving many caves, some groups of caves, and then a master cave at three different folder levels. I’ve tracked the issue down to one cave, and if it is removed (and the station equates joining the other centrelines are broken [of course]) the problem goes away. The export model kml at all folder levels involving this cave will cause an untrapped error if it is present with other caves. The problem cave will however produce a perfect kml model if it is compiled stand alone.
It is notable that the problem only ever manifests with export model kml. I can produce lists, loch and 3d models. Every type of export map plan and elevation pdf and kml output is also fine.
If loop-closure survex is set, I get a truncated XTherion transcript and a therion.log that truncates midstream.
If loop-closure therion is set, I get no XTherion transcript, and a zero length therion.log file.
Similar to the log files, the kml files appear to be truncated midstream, one or two hundred lines in.
I have checked the coordinates at the point where the kml truncates, so that I could focus on that particular survey and leg. There is nothing untoward there, however I suspect that the cause of the crash is not necessarily right at the last station written. The log and kml truncations are fairly consistent however, but not always the same if I make adjustments to the input data.
Any insights out there?
Anyone else had similar behaviour?
I have copied some short extracts below.
Bruce
eg
XTHERION TRANSCRIPT and THERION.LOG with LOOP CLOSURE SURVEX
…
selecting export objects ... done
writing ./Output/GLSM_SystemSurveys.html ... done
writing ./Output/GLSM_SystemContinuations.html ...
processing projection plan ... done
average distortion: 1.12%
processing projection elevation ... done
average distortion: 5.40%
done
writing ./Output/GLSM_SystemCaves.html ... done
writing ./Outp
KML MODEL with LOOP CLOSURE SURVEX
…
name><![CDATA[Survey J2 Mainstream Flush Corner to Upstream Sump GreenLink Cave]]></name>
<Placemark>
<name>M10</name>
<styleUrl>#ThSurveyLine</styleUrl>
<MultiGeometry>
<LineString><coordinates>
172.88735579937293,-40.99769937251387,639.02999999999997 172.88728319623294,-40.99774299151084,637.23000000000002 172.88716109616212,-40.99773710678338,637.76999999999998 172.88714596870241,-40.99782276033864,637.94000000000005 172.88705675083290,-40.99784789603311,638.0
KML MODEL with LOOP CLOSURE THERION
…
<Folder>
<name><![CDATA[Survey J2 Mainstream Flush Corner to Upstream Sump GreenLink Cave]]></name>
<Placemark>
<name>M10</name>
<styleUrl>#ThSurveyLine</styleUrl>
<MultiGeometry>
<LineString><coordinates>
172.88736168357167,-40.99769608966369,638.91567858257895 172.88728901384377,-40.99773967188410,637.11607014782805 172.88716696109856,-40.99773379656759,637.65513049713036 172.88715179697692,-40.99781949576298,637.82267359892830 172.88706263582006,-40.99784457013876,637.9
END
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion