I also had an error message when I tried to import CRP generated *.kml files into QGIS and this was caused by slight format issue. *.kml files output by CRP don't follow exactly the structure/format of a *.kml file generated by Google Earth. However, the generated *.kml files are readable by Google Earth, so a way around to correct any format issues is to open the file in Google Earth and save/overwrite the file from there. Then the format glitches should be corrected and you should have no issues importing your files in third part software/apps.
If you select LRDUs + Volume before exporting to kml, then you should get something similar, the difference with VT being the polygones are not filled.
same kind of issue here but it's not as bad as total freezing and PC reboot. When I go to OpenTopoMap view, it takes some times to get the cave displayed (with graphical scale and OTM license comments) but no OTM tiles are uploaded. Then CRP seems to freeze, but if I click on Plan view, after a while, CRP actually goes to Plan view. So CRP doesn't seem to be completely frozen at this stage. However, CRP gets sluggish as hell and pretty much nothing can be done at this point but to close and relaunch CRP.
I noticed an issue with OTM view. When several entrances to a cave are linked and auto-adjustment is on, all entrances but one are in the wrong position, slightly off. I checked the *.kml export in QGIS with OTM layer, and the entrances are in the correct spot, no issue. So, I wonder if there could be an issue with the meridian convergence with OTM view.
As mentioned previously, the shoots and splays are not displayed based on their actual vertical position but are piled up from top to bottom of the data table. This lead to very awkward display of caves where underlaying galeries can to displayed as if the were above upper ones. If this issue can't easily be solved in Perspectives (as I understand CRP uses a 2D viewer to display 3D data), I believe it can be fixed in Plan view (and probably in Side view). The display process should include sorting the shoots and splays based on their Z position before display. This won't be perfect in all cases, but surely it will be much better than the current data table order. This shouldn't require any calculations, just sorting the data before display. This should also be applied to kml export as it suffers the same issue.
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.
I noticed 2 format issues: Import : File created by Topodroid X as *th (Therion) are not readable by CRP getting the following message: No (...) Therion (...) format in xxxxxx.th Export : File created by CRP as *.kml are readable by Google Earth but not by QGIS. Comparison between the actual file format of the issued by CRP and the kml file issued by Google Earth (i.e. file created by CRP opened in G-Earth and saved again) show significant differences, which are likely to explain the issue.
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.
CaveRenderPro » Foren Suche nach Inhalten von Droniste
30.09.2024 09:48
