From: https://survex.com/docs/manual/datafile.htm

If you have specified the output coordinate system (using *cs out) then you can use *declination auto (and we recommend that you do). This is supported since Survex 1.2.21 and automatically calculates magnetic declinations based on the IGRF (International Geomagnetic Reference Field) model for the specified date of each survey and at the specified representative location (given in the current input coordinate system, as set with *cs). Survex 1.2.27 and later also automatically correct for grid convergence (the difference between Grid North and True North) when *declination auto is in use, based on the same specified representative location.

Missing spaces on this line:
https://github.com/jarvist/migovecsurveydata/blob/master/migovecsurveydata/garden/garden-low/bigrock/miles.svx#L39

26 27 5.39-up;27 is bolt at top of pitch

https://github.com/jarvist/migovecsurveydata/blob/master/migovecsurveydata/garden/garden-low/bigrock/miles.svx#L39

26 27 5.39-up;27 is bolt at top of pitch

(It looks like these are duplicate directories anyway, and probably one of them should be deleted).

This seems to be a common formatting error in a number of places (missing spaces around NNN-up and NNN-down), which prevents tunnel from loading it. Survex handles it, but it's definitely not right, and looks like something that was caused by a script running over the data and rewriting it.

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.

There are a couple in this file:
https://github.com/jarvist/migovecsurveydata/blob/master/migovecsurveydata/sysmig/level2/rockroll.svx

;*ref https://drive.google.com/open?id=0BxkZAUc06EK5OHZrd2xNRmtEXzg
;*ref https://drive.google.com/open?id=0BxkZAUc06EK5ekxhcUhaUE5HVHc

The first is available, and the second isn't. There has to be a better place for these images.

In the future it should be possible to handle binary blobs in git properly, and might be a feature available on http://cave-registry.org.uk/ soon.