Optional Hillshades?

[MattReimer]

The hillshade algorithm is quite inefficient (compared to other matrix math-y type operations) and we call it a lot. For larger datasets like the Dee the copy step takes less than 2 seconds whereas the hillshade generation can take up to a minute or even two,

It might be nice for users to be able to disable Hillshades as a software setting, (at least until we can figure out how to speed things up for them). We can sure it's turned on by default.

Reasons it might make sense:

• Larger datasets slow everything down
• People using standalone don't have a map anyway

[joewheaton]

Good question and solution. We have a similar problem in VBET with calculating flow accumulation. In that case, we give the user an option of adding their own manually to save time. If I understand correctly, it is the calculation of a large hillshade that is quite slow, and not adding it to the map? I like the suggestion of having a Options setting of whether or not the hillshade gets calculated by default. However, if we go down that route a few things to consider in the can of worms you are opening ;) :

1. How does a user get the hillshade in later if they decide they want it? I could see providing from the DEM Survey Properties form:

• the ability to add it manually (i.e. if they already had one derived). Since it is just used as context, its not something we need to be that careful about enforcing nodata extents or even orthogonality with associated DEM
• Another nice feature would be the ability to derive the hillshade if it does not exist (this again could be accessed from the DEM Survey Properties form. This could be a button on whatever the surface properties form?

2. How does the user know if a hillshade is in the project without opening up the folders? Right now, we don't show this in the project explorer in anyway (nor do we track it in the *.gcd project. I don't know that we want to either. However, we could show whether or not it was added, as one of the DEM Survey properties in that table?
3. Should we add a radio button to the Add DEM Survey, Add Reference Surface, and Derive Reference Surface forms that lets you choose between Derive Hillshade from Surface for Context vs. Do Not Derive Hillshade (the setting in Options you describe would represent the default state for the button).

This all strikes me as a lot of work right now for something that is a fairly rare problem at this point? Not sure. I offer above for when we do try to tackle it... I concur with 'Future Version' milestone.

[MattReimer]

it is the calculation of a large hillshade that is quite slow, and not adding it to the map?

Yup. You got it.

This all strikes me as a lot of work right now for something that is a fairly rare problem at this point? Not sure. I offer above for when we do try to tackle it... I concur with 'Future Version' milestone.

I just solved a huge memory leak problem that would've crashed the program on sufficiently large rasters. Since that got fixed the only real danger is that large rasters will take a long time to import and people will get bored without any status messages to tell them things are still happening.

I agree: Future version

[MattReimer]

For future matt:

---------------------------OP TIMER---------------------------
Raster Reading: 0:0:723
Raster Writing: 0:1:329
Calculations: 1:22:526
Total Time: 1:25:8
--------------------------------------------------------------

The vast majority of time is spent in the calculations phase. I wonder if we couldn't make this algorithm more efficient.