1

I use the SRTM DEM and I have used the "Project Rater" tool in ArcGIS10.2 in order to project it from GCS_WGS_84 to a certain UTM zone in WGS84. With my projected elevation raster, I have calculated slope (min: 0, max:73 in degrees) and aspect (0-360). When I try to convert again the projected slope and aspect into GCS_WGS_84 (my analysis must be carried out in latitude, longitude) their values change, and I get for slope min:-1,24 max:74 (in degrees), and for aspect I get 1-460! Why does this happen?

3

You are correct to use an appropriate projection for computing slope and aspect. The problems occur when reprojecting those results to another coordinate system (such as lat-lon). Two things happen:

  1. Grid values must be resampled in order to interpolate them to the new cell centers.

  2. Aspects, being circular data, must be specially handled. Otherwise the resampling will blithely average, say, 359 and 1 degrees (which are almost the same aspect) and obtain 180 degrees (which is exactly the opposite of the correct average).

To deal with (1), it is usually best to use "cubic convolution" for the resampling, because this tends to preserve the whole statistical variation of the data. Other methods, especially bilinear interpolation, are local averages and therefore will always reduce the ranges and variances of the data. Regardless, expect some small changes in statistical summaries of the values.

To deal with (2) is harder. One of the simpler approaches is to compute two grids from the aspect: its cosine and its sine. Reproject those, then recompute the angle from the reprojected values (using an arctangent function). Watch the process carefully, because much GIS software is schizophrenic concerning trig functions: it tends to use degrees to report angular values (like aspects) but to insist on radians as input to trig functions. Spot-check the cosine and sine grids to make sure the calculations are correct.

You have to be careful with ESRI grids, because they tend to use a code of -1 to represent unknown aspects (horizontal cells). Before doing anything, convert those codes to NoData values--otherwise the codes will be averaged with the aspects of their neighbors, completely screwing things up. You can always convert any NoData values in the final aspect grid back to -1 (or whatever).

A slightly better approach is to combine the slope and aspect grids into grids to represent the gradient of the UTM values: one will be the partial derivative with respect to x and the other with respect to y. Reproject those and then recompute the slope and aspect from them. Since this is rarely worth the bother--greater errors are typically created by whatever coordinate system is used for the calculations--I will not provide details here.

1

Projecting a raster results in a resampling/alteration of the values in that raster because the size/shape/number of cells are changed. It's basically creating a whole new raster and interpolating the values of the new cells based on how that grid lines up with the source grid. The help file usage notes describe some of the issues involved in detail.

  • It is better to project the DEM then create the slope/aspect from that rather than projecting slope/aspect, the resampling of the slope/aspect rasters makes them almost unusable. – Michael Stimson Feb 8 '15 at 23:13
  • @Michael Away from the vicinity of the Equator, both aspect and slope will be badly calculated if lat-lon is used as the coordinate system. They should be computed in a reasonably accurate projection and then reprojected, which seems to be the opposite of what you are recommending. – whuber Feb 9 '15 at 19:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.