Then I have the source raster files plus the virtual raster to manage 😉

I've been looking at it as: why triple, quadruple, or worse the number of files the user needs to manage with when the data naturally overlaps and is easily merged into a multi-band file? Using a multi-band file also ensures that each band covers the analysis area with the same CRS and resolution, which is important for usage here. We'll see what users think—I do have an option to read single-band files and merge them internally, but for my usage it's been easier to deal with a single file.

Probably not. The files have both terrain and surface elevation data, both of which I'll want to examine. I'm also embedding color map data for the surface type band, and that data can only get attached to band one, so surface type has to be band one. It's interesting how well QGIS generally handles multi-band files but there isn't a provision for that here. 🤷‍♂️

Thanks! It's a couple extra steps but I'm able to get the 3D views I need like this. I'm building custom raster files that combine surface type, terrain height, and surface height in a single file, then reviewing them in QGIS.

Same problem here: these aren't working for me with QGIS 3.20.

Were you able to figure out a way to remove bands from a dataset?

Were you able to figure this out? Oddly, the WKT for EPSG:5819 comes back as: PROJCS["EPSG topocentric example A"] spatialreference.org/ref/epsg/5819/prettywkt Not much of an example to work from.

Thanks—this clarified much for me. Looks a possible next step would be deriving the WKT string for an arbitrary topocentric CRS to cover the area of interest. I see that someone asked this question a while back: gis.stackexchange.com/questions/241094/…