I am doing a slope analysis.
I have features from a larger set of features selected and turned into a layer.
I am using that layer of selected features as the mask.
When I run the spatial analyst slope tool and set the mask and extent to that layer (those 3 features) the analysis returns a raster data set that is masked by all the features in the parent feature class and is not limited to the selection.
I have tried this many types of raster and features.
If I export the selected features and write it to as a separate feature class.
This is similar to prior issues where the selection reverts to the whole dataset.
This is a difficult problem to debug in model builder workflows.
What data type is the feature class that you are using as the mask (raster, polygon)?
I would set the mask in the environments tab of the slope GP tool AND set the processing extent using your mask feature class , or clip the raster to your mask layer and then perform the slope analysis.
Thank you for ideas for the work around.
The feature class used to mask is a polygon.
(...can a feature class be a raster data type? I don't think it works like that for ESRI data types and tools)
As a matter of habit I set the analysis extent (processing extent in the environments setting) and the mask to the same feature class, unless there is a compelling reason to have the analysis include the whole raster extent.
The data being used in the slope tool is a raster in a File Geodatabase (DEM) and the tools returns a raster (DEM) as expected for the slope calculation--the problem is that it is the wrong mask.
Clipping the raster data set does work, but this requires that I export the selected features I want to use to a new data set to perform the clip, then perform the clip, then run the slope analysis on the clipped data set.
I tested this workflow to confirm it works before concluding the mask option is doing odd things and before posting my question/observation.
To get the task done and off my plate I used that workaround and settings to complete the slope calculation.
The task was to calculate the slope limited to my area of interest (a few ranches) so I could then estimate locations to exclude from grazing due to erosion criteria related to steep slope.
However, while this workflow is possible (thank you for confirming) this process leaves me with the two interstitial data sets I was trying to avoid creating (plus manage and now need to delete) that the mask setting should have skipped.
I'll clarify my settings:
Slope tool did not calculate whole raster, it did a mask.
However, from the results it is clear that the mask used all the parcel polygons in the underlying feature class, not the set of three polygons in the layer chosen as input.
Because the mask was not limited to the features in the layer that was chosen as the mask input I believe this is not the expected behaviour.
While the work around as a one-off solution is good, creating extra steps in a model that require the creation, deletion, and confirmation of deletion of multiple sets of additional data in the process means I can't make use of the speed and efficiency of the mask- especially in an iterative model.
I suspect this is a bug.
Or... if it is true that layers created from selections cannot be used as a mask input then this should be noted in the slope tool documentation.
A previous and troublesome bug of selections in ArcGIS Pro was that when selected features were turned into layers the layer was damaged if you renamed it. The layer was was a product of the "turn this selection into a layer" tool in the context menu for the feature class with selected features. When you renamed the new layer created from the selected subset of features (e.g. to use in the legend) the selection disappears and the layer reverts to displaying all the features of it's source (similar to deleting a definition query)
I suspect that if this is a bug I am encountering in the slope tool, it is related to that prior bug that caused those problems with renamed layers.
I'll try to have an ESRI technical support staff reproduce to see if it is an existing bug documented in the production management database after the winter holidays unless anyone else has already confirmed this problem with the mask.