Don't get me wrong, I like CRP and will continue to use it. Swapping software always come with some data loss and in the case of CPR, the raw drawings (that's a lots of works and times I'd rather spent surveying . I'd rather raise that point and hear what Jochen has planned (or not) to ensure CRP will remain a nice software with a dynamic development if he stops developing it himself for any reason. Having a group of developers involve in the project can also bring some new ideas, skills, etc... saying this I'm not a developer myself so this to offer my help on this matter but to open up a legitimate discussion.
Looks like CRP import process doesn't deal with some of the TopoRobot specificities. I don't think the issue Jean-Pierre is related to the "inversion" of the series. I suppose the import ignore the information contained in each series header where the relation with other series is actually defined.
Oui, si ça ne te dérange pas. J'aimerai voir ce que ça donne à l'import. Il est probable que le problème soit que l'import soit limité à une logique simple. Il peut y avoir des pertes d'informations dans l'importation en raison de la complexité des formats ou de leurs logiques mais aussi peut-être parce que Jochen n'utilise pas TopoRobot (il me semble) et n'aurait donc pas une maîtrise complète du format. J'ai beaucoup de données au format *.tro (VTopo) et il a fallu pas mal d'ajustement du process d'import pour tenir compte des différentes configurations.
an alternative would be to merge the shots and to keep both direct and backsight shot in the table but disabled. So it would be possible to run the QC check in CRP and decide what to keep...
I recently had an interesting discussion with a Therion user. He came up with a strong argument in favour of Therion: Therion has a group of developpers and therefore is more likely to stay around in the next decades than a software relying on one person. I have to admit I can't agree more with this argument. Fuel for thoughts?
Something that could be (very) interesting is to add OpenTopoMap layer. OpenTopoMap map layer is more useful than GoogleMaps map layer... OpenTopoMap has terrain/hillshade/contours and one of the big advantage is that OpenTopoMap is directly related to OpenStreetMap project and anyone can edit/add some geographical information (very practical for expeditions).
Are you planning to look into other options ? If this is to stay like it is, can you please at least add a step in the import process to accept or reject the shot/backsight shot merging option? As it is, I'd rather deal with the regular/backsight shots couples in the table rather than loosing the raw data.
The painful method I have used to get things right : Basic correction: 1 - Change direct shot direction using "Direction <->". this correctly set the splay direction as somehow the splays get the opposite direction they should get during the import (that was before the merging version). 2 - Manually revert the direct shot direction, so direct shot and splays directions are consistent. 3 - Set the backsight shot to the opposite direction as of the direct shot.
It gets a bit more complicated when I want to flip the overall direction...
It seems like the stability issue is fixed, no more erratic changes, but there's a new issue: My gml contours files are definitely created with UTM coordinates, however, when I select UTM Grid mode, contours and caves are far apart. When I select Geographic, then contours and caves are together. It looks like there's a mix up between UTM Grid and Geographic modes somewhere in the code.
I tested the shot/backsight shot import. As far as I can tell, it works as expected: the couples of shots seem to be identified and merged. However, I really don't like the fact that the raw data (i.e. shot and backsight shot) are processed and removed from the data table. I do backsight shots to be able to assess the quality of the shots and to reduce the error related to the DistoX calibration (e.g. difting) and/or magnetic errors. If the shot/backsight shot are merged during the import, then we loose the possibility to QC the data (in the table and in the views) and to decide wether the couple is OK to merge or to reject one of the 2 shots (if not both).
I'd rather see a solution identifying the backsight shot in the data table with linked behaviours (i.e. direction 1/-1, direction <->) and let the auto-adjustement merging the couples of shots.
Calculation of path length: Thanks! Do you think it would be possible to highlight the path calculated? in complex network it can be interesting to see what is actually the calculated path.
The new depth and height filters work fine, thanks.
A couple of suggestions - why not having both depth and height as one filter with e.g: 100/-50 ? - filtering by altitude could be also interesting for multi-caves.
The french translation "profondeur"/"hauteur" sounds a bit awkward to me. "hauteur" isn't clear in this context. I suggest to use the combo "dénivelé négative" for depth / "dénivelés positive" for height and if you merge both depth and height in one filter "dénivelé".
Hi Jochen, Thanks for all the recent implementations... unfortunately I’ve been away from home and computers for a while, and didn’t had a chance to test the latest versions. I let you know as soon as I can.
Levels: level plan mode vs level section mode. Would it be possible to divide "Level" in 2 columns, levels can be useful for overlaying areas, but the horizontal overlap vs. vertical overlap doesn't follow the same logic (top to bottom vs foreground to background). It would be very helpful to be able to set and filter levels for both types of view (plan vs sections)? maybe Level_Horiz. and Level_Vert.
Filters: when you have numerous spalys, having all that information at one can make make the interpretation difficult (too much info at once) Here is a couple of extra filters than could be helpful: - Filters by Station. When you have numerous splays, it can make life easier to - Filters by Z with +/- range... this would only display splays within a depth range and would allow to focus on specific area. That could help in drawing details.
Elements: Water: brook and streams should have a dashed option. sometime the water disappear in a narrow passage and it is not possible to survey but we're able to guess a water path... this should be dashed.
Data: New automated fields: It could interesting to have a columns with calculated path length from entrance, total negative and positive elevation from entrance (i.e. addition of all negative elevation difference between stations and addition of all positive elevation difference between stations along the caver path). Material filter: Only display rows with Material filled in. That would provide a quick summary/table of the equipment required. This should be displayed with columns Supplementary and the above suggestion
Would it be possible to freeze columns Cave, Ref Passage, Ref Station, Passage, Station? This would improve horizontal scrolling experience... and not getting lost in the dable :)
That's what I've done so far... screenshot in Google map mode with the survey shots displayed then dragged it to the approximate position. Aren't the drawing features referenced in UTMxx?
CaveRenderPro » Foren Suche nach Inhalten von Droniste
05.11.2021 12:40
