Fix the *cs values so that the UTM33N coordinate frame is correct

[goatchurchprime]

I've tried commenting out the different *cs commands in the dataset but I can't get it to output in a cs frame that appears in Slovenia.

For UTM33N I think you want points around the lng,lat of 429096E,5130056N, but it's giving values of 123754N, which is to close to the equator.

If this is fixed then it will be possible to load the centreline into QGIS and project it under lidar elevation models.

[jarvist]

A number of people have looked at this over the years - we should certainly sit down and finally fix it!
I guess all you would need is a head 'Mig.svx' file or similar, with a suitable tie into a UTM + grid spec?

Our survey is still located versus the Slovene Gauss-Kruger grid, which isn't quite a UTM (they use a different, now mostly obsolete, spheroid).
For this Slovene grid, we were provided with DEM data back in 2005, which we rendered to a form of pseudo-cave legs so we could display it on the mountain as we brought back data from the caves:
https://github.com/jarvist/migovecsurveydata/tree/master/migovecsurveydata/DEM

[goatchurchprime]

2005 DEM data is going to be well out of date. The tech has moved on very far.

You might be able to get the 1-second-arc NASA terrain data from http://viewfinderpanoramas.org/dem3.html#alps or https://dds.cr.usgs.gov/srtm/version2_1/SRTM3/Eurasia/

Looking at the terrain mapping tools here shows that a 1m lidar dataset exists for the whole of the country: http://gis.arso.gov.si/atlasokolja/profile.aspx?id=Atlas_Okolja_AXL@Arso&culture=en-US

There's a QGIS plugin that allows for downloading this data, but it didn't work last time I tried it: https://github.com/nejcd/LidarSloveniaDataDownloader You could take a stab at reverse engineering the URL in the code to try and download the bit you need using this function

[agseaton]

I spent a while looking into the coordinate system setup a couple of years ago and I think it is correctly set up for the data we currently have. I'm not sure if you have seen it, but I have tried to document this in the master survex file (here).

We are also well aware of the LIDAR data - it's a fantastic dataset! A couple of us have been playing around with this but as far as I'm aware there aren't many in the club who use QGIS (perhaps we should!). I wrote a small script that puts the data into a form that survex can read (though survex is limited to 1m altitude resolution), which you can find here. In terms of downloading the LIDAR data, you can do this manually through the link you sent in your last post. This isn't too much of a chore as each tile is 1km² so you don't have to download many. Of course, it would be nice to automate the process!

[jarvist]

The 2005 DEM data isn't as primitive as you may imagine!
It's calibrated and hand-cleaned, based on some space data but then supplemented with plane LIDAR data on a 25 m grid (the Slovene G.K. one), with centimetre height resolution. It is enormously superior to raw SRTM data (which is full of artefacts / shadows), or for any orbital radar derived data for that matter.
It came directly from the Slovene Karst institute, and is the precursor to the 1 m gridded data, and was generated for and used in their landslide risk analysis.

The benefits of the primitive artificial-survey legs way of the DEM directory are:-
1/ we can view it on the mountain top, even on the rusty old OLPC
2/ you can do a point-to-point distance within aven, to see how and where different parts of the surface are relative to the exploration. The stations are named as the grid coordinates, for cross-reference to the 1:10'000 ex-military maps.

@randomp1 - where you ever able to fix that issue with the height of the 1mx1m DEM data? I seem to recall it sort of floated +25 m above the surface legs?

[goatchurchprime]

The gis.arso.gov.si site gies these as the same place:

GKY: 424033
GKX: 97708
Lat: 46o01'09,52'' (46,019311o)
Lon: 14o00'50,69'' (14,014081o)
ETRS89 X: 423663
ETRS89 Y: 98193
Nadmorska višina 763,799987792969

*cs out UTM33N results in a map overlaying equatorial guinea with this data. This is sort of thing is always very fiddly to get right. CUCC-Austria has an out-of-date austria-centric coordinate system that the austrians no longer use as its input basis, but somehow the output coords are cooperating with the rest of the world.

I checked the geoid height there, and it gives 46m. Unfortunately not the same as your +25m altitude error, so that's not the easy answer. https://geographiclib.sourceforge.io/cgi-bin/GeoidEval?input=46d01%2709%22+14d00%2750%27%27&option=Submit

Mike Futrell (virginia caver) whose job is professional surveying for property says they ignore all instrument altitudes (eg GPS and altimeter) and simply lift the numbers off the lidar maps when they know the lat-lng. This eliminates all these geoid altitude problems.

The most advanced use of QGIS is I know is the matienzo data set: http://matienzocaves.org.uk/MCP-QGIS/index.htm It's the way forward as it connects us into all the other GIS tech/functions that are more advanced than we can imagine.