Extract Aspect Values to Points
Summary
Adds a field holding the aspect at each point, read from an aspect raster, to a copy of a point feature class or to the feature class itself. It does what Esri's Extract Values to Points does, but built for aspect: the optional interpolation is a weighted mean direction, a circular calculation that never averages 359° and 1° into 180°; flat cells, stored as −1, are handled as cells with no direction rather than as a value; D-infinity flow-direction rasters are accepted; and no Spatial Analyst extension is needed. The raster can also be a DEM: the tool then computes the aspect itself at each point, by Horn's 3 × 3 method (the method of Esri's Aspect tool) or a least-squares quadratic over a window you choose, with the distances between cells measured on the spheroid in any coordinate system (see Computing from a DEM).
Why a special tool for aspect
Aspect is the compass direction a slope faces, from 0° at north clockwise through 90° east, 180° south and 270° west back to north at 360°. It is a circle, not a number line: 359° and 1° are two degrees apart, not 358. Esri's Extract Values to Points is a fine tool for elevation, slope, or any other ordinary raster, but with interpolation switched on it averages the neighboring cell values as plain numbers. A point lying between a cell facing 359° and a cell facing 1° comes out at about 180°, due south, when both cells face almost due north. Jenness (2012) gives that example as the commonest mistake made with directional data.
This tool interpolates the way circular statistics do. Each of the four cell centers around the point is treated as an arrow of length one pointing in its aspect direction, with an east-west component sin θ and a north-south component cos θ. The four arrows are weighted by the standard bilinear weights, which depend on how close the point lies to each cell center, and added. The direction of the summed arrow is the interpolated aspect:
where θi is the aspect of each of the four surrounding cell centers, wi its bilinear weight, and atan2 the two-argument arctangent that returns the full 0° to 360° circle. For the point between 359° and 1°, the two arrows both point nearly north, their sum points north, and the answer is about 0°. A cell facing due north and one facing due east, weighted equally, give northeast, 45°, which is what a person standing between the two slopes would expect.
Flat cells have no direction, so a flat neighbor contributes no arrow: it is left out and the weights of the remaining directional neighbors are renormalized to sum to one. A NoData neighbor is left out the same way. If every neighbor of a point is flat, the point gets −1, the flat value; if every neighbor is NoData, the point gets no value. A point also gets −1 when its neighbors' arrows cancel exactly, two facing north and two facing south with equal weights, say: the summed arrow then has no length and no bearing, so the point has no defined direction, and the run report counts it with the flat points. Directions that come out at exactly 360° are written as 0°, so the field never holds both names for north.
Two ways to extract
The Interpolate checkbox chooses between two readings of the raster, and the default matches Esri's default:
- Unchecked: each point receives the value of the cell it falls in, exactly as stored. A point on a flat cell receives −1. This is the right choice when the raster's cells are small compared with the precision of the point locations, or when the stored values themselves are what you need. For a compass aspect raster, the values are exactly the ones Esri's Extract Values to Points writes with its default setting; nothing is converted, not even 360. The differences lie around the values: no Spatial Analyst license is needed, the field is named Aspect (or whatever you choose) rather than RASTERVALU, the field's metadata records what the numbers mean, and the run report counts the points that fell on flat cells. The one case where the values themselves differ is a D-infinity raster read with the Mathematical convention, whose angles are converted to compass degrees (see below).
- Checked: each point receives the weighted mean direction of the four surrounding cell centers, as above. This smooths out the cell edges and gives a point near the boundary of two cells a direction between them rather than the direction of whichever cell happens to contain it.
Computing from a DEM
Set What the raster holds to Elevation (DEM) and the tool computes the aspect itself, at exactly the cells the extraction needs, so the numbers are the same as making an aspect raster first and extracting from it. Two methods are offered.
- Horn (3 × 3), the default, is the third-order finite difference of Horn (1981), the method Esri's Aspect tool uses with its planar method, reproduced down to Esri's handling of NoData neighbors and its −1 for cells with no gradient. On a projection that is true to scale, such as UTM or State Plane, the values are identical to extracting from an Esri planar aspect raster of the same DEM. The one difference is that the distances between cells are measured on the spheroid whatever the DEM's coordinate system, so a latitude/longitude DEM gives correct values too, which Esri's planar method is not designed to do, and a Web Mercator DEM is handled with no regard to its scale distortion (see Projection Distortion and Terrain Analysis).
- Quadratic least squares fits the Evans–Young quadratic surface (Evans 2013) to a window of 3 to 15 cells on a side and takes the aspect from the fitted surface's first derivatives at the center cell. At 3 × 3 it is the equal-weight estimator in the table below; a wider window averages over more terrain and smooths a noisy, fine-resolution DEM, in the way Esri's Surface Parameters neighborhood distance does.
How the two methods differ
Both methods estimate the same two numbers at the center cell, the east–west and north–south gradients ∂z/∂x and ∂z/∂y, and both then turn them into aspect in the same way, the compass direction of the steepest descent, with −1 where both gradients are zero. They differ in how the gradients are estimated from the neighboring cells. Number the cells of the 3 × 3 window around the center cell z5:
| z1 | z2 | z3 |
| z4 | z5 | z6 |
| z7 | z8 | z9 |
Horn's method is a finite difference: a fixed recipe of weights. The east–west gradient is the difference between the east column and the west column, with the middle cell of each column counted twice and the corners once, divided by eight cell widths h (the north–south gradient is the same recipe applied to the top and bottom rows). The center cell itself is not used.
The quadratic method is a surface fit. A quadratic surface, z = ax² + by² + cxy + dx + ey + f, is fitted to the cells of the window by least squares — it passes as close as it can to all of them, not exactly through any — and the gradients are the fitted surface's own gradients at the center, the coefficients d and e. The fit uses every cell in the window, the center included, and it also yields the surface's curvatures, which this tool does not need. Applied to the 3 × 3 window, the least-squares fit works out to a finite difference of its own, the Evans–Young estimator: the same column differences as Horn's, with every cell weighted equally and the sum divided by six cell widths.
So at 3 × 3 the two methods differ only in whether the four orthogonal neighbors count double. Horn's weights put more trust in the nearest cells and less in the corners, which is why Horn is a little more accurate on an error-free surface and a little more sensitive to a bad cell (the table below); on real DEMs the two agree closely, and for a plane they are identical. The real difference appears when the quadratic window is widened. A 5 × 5 or 15 × 15 fit takes in 25 or 225 cells, so its gradient is the gradient of a surface averaged over that footprint: individual noisy cells have little say, and features smaller than the window are smoothed out, which is exactly what Esri's Surface Parameters neighborhood distance does and what Wood (1996) and Evans (2013) recommend for fine-resolution DEMs. Horn's method has no such setting; its footprint is always the 3 × 3 window, which Hodgson (1995) showed represents an area roughly twice the cell size.
Which to choose. Horn's method is the right default: it is what every aspect raster made with Esri's Aspect tool, GRASS, and most other software already contains, so values computed here from the DEM agree with values extracted from such rasters. The quadratic method earns its place when the DEM is much finer than the terrain features of interest — a 1 m lidar DEM on which a 3 × 3 aspect follows every furrow — or when the question is which way the hillside faces at a chosen scale rather than which way the cell faces; a window of 5 to 15 cells gives the aspect of the surface averaged over that footprint. On nearly level ground any aspect estimate is unstable, since a small change in the gradient swings the direction a long way, and a wider quadratic window steadies it by averaging more cells.
Horn's method is kept as the default for a reason beyond matching Esri. Every comparison of 3 × 3 slope estimators since Skidmore (1989) has found it a highly accurate estimator in practice: Jones (1998) ranked it second only to the four-cell method on an error-free surface, Florinsky (1998) and Zhou and Liu (2004) showed that the eight-neighbor estimators are the least sensitive to errors in the DEM, and Evans (2013) summarized the literature as favoring the nine-point quadratic family, of which Horn's weights are a member. Zhou and Liu's error model makes the trade-off explicit:
| Estimator | Slope RMSE, error-free surface | Aspect RMSE, error-free | Sensitivity to DEM error, relative to Horn |
|---|---|---|---|
| Four-cell (Fleming and Hoffer 1979; Zevenbergen and Thorne 1987; Esri's biquadratic at 3 × 3) | 0.22° | 0.13° | 1.63× |
| Horn (1981) — Esri's Slope and Aspect tools; this tool's default | 0.36° | 0.12° | 1.00× |
| Equal-weight six-cell (Sharpnack and Akin 1969; the Evans–Young quadratic, Esri's quadratic and this tool's quadratic at 3 × 3) | 0.41° | 0.20° | 0.94× |
From Zhou and Liu (2004), Tables 2–4: the root-mean-square errors of the three 3 × 3 estimators on an error-free analytic surface (an inverse ellipsoid, 10 m cells), and the coefficient by which each passes DEM error into the slope, scaled to Horn's. The four-cell estimator is the most accurate on perfect data and the most sensitive to error; the equal-weight estimator is the least sensitive and the least accurate; Horn's weights sit between them on both counts.
One thing to know about aspect from any projected DEM, this tool's and Esri's alike: it is measured from the grid's north, the top of the raster, which differs from true north by the grid convergence, under a degree across most of a UTM zone but up to about ten degrees at the edges of a continental Albers or Lambert projection. The Projection Distortion page explains it.
Esri's Surface Parameters tool fits its quadratic or biquadratic surface in geocentric coordinates, a different arithmetic from the planar fit here. To extract values computed exactly as Surface Parameters computes them, run Surface Parameters first and extract from its raster with What the raster holds left at Aspect values.
Elevation units default from the DEM's vertical coordinate system when it has one, and are locked; when the DEM gives nothing to go on, choose Meters or Feet yourself, since a wrong unit scales every aspect value. The Input aspect convention does not apply to a DEM: the computed values are compass degrees, 0 to 360 clockwise from the top of the raster, with −1 for flat.
Where the values go
The Where to write the values drop-down offers two choices:
- A new point feature class (a copy of the input): the default, and what Esri's tool does. The input points are copied, with all their attributes, and the field is added to the copy. If the input layer has an active selection or a definition query, only the points it shows are copied.
- A new field in the input feature class: the field is added to the input itself and no copy is made. Only the points the layer shows, through its selection and definition query, receive values; any other rows of the feature class are left NULL, and the run report says how many. A layer with a join cannot take a new field, so remove the join first. Esri's Extract Values to Points always writes a new feature class; writing into the existing one takes its Extract Multi Values to Points tool.
In either case the new field is a DOUBLE named Aspect unless you choose another name. A name that is not valid for the workspace, or is already taken, is adjusted to Aspect_2, Aspect_3 and so on; the dialog warns when the input already has a field of that name, and the run messages report the name actually used. Its values are compass degrees, 0 to 360, in every case, with −1 for a flat cell. A point that falls on NoData or outside the raster gets NULL in a geodatabase output; a shapefile cannot store NULL in a number field, so it gets −9999 there.
The field's own metadata records the units, the −1 and NULL or −9999 conventions, whether the value was interpolated, and the source raster, so the meaning of the numbers travels with the data. Esri's option to append all of the raster's attributes is deliberately not offered: an aspect raster has no attribute table worth appending, and the one field says everything.
The tool warns if the raster's values fall outside the range −1 to 360, which nearly always means the raster is not aspect at all, such as a slope or elevation raster picked by mistake. The run still completes.
Coordinate systems
The points are read in the raster's coordinate system. Point coordinates can be reprojected exactly, while projecting a raster resamples every cell and damages the values, so the raster is never projected, and the points and raster may be in different coordinate systems without harm. When the two are on different datums, such as NAD27 points on a NAD83 raster, the points are moved with a datum transformation as well, and the run messages name the transformation used; without one, points can land 100 m or more from their true cells. The raster is read only over the extent of the points, with a margin of cells around it, so a regional raster with a small cluster of points is handled quickly. Projected and geographic rasters both work, since a point's containing cell and its four neighboring cell centers are found the same way in either. See Projecting Rasters for why the raster is left alone.
Direction conventions and flow-direction rasters
The Input aspect convention drop-down says how the raster measures direction. Compass (0 = north, clockwise), the default, is ordinary aspect. Mathematical (0 = east, counter-clockwise; e.g. D-infinity) is the convention of D-infinity flow-direction rasters, whose values are the direction of steepest descent and so are essentially aspect measured the other way round. With the mathematical convention chosen, each extracted direction is converted to compass degrees before it is written, so the field reads the same as one extracted from an ordinary aspect raster.
The tool sets the drop-down for you when it can, by reading the geoprocessing history stored in the raster's metadata: a raster made by Esri's Flow Direction tool with the D-infinity option is recognized and the drop-down is set to Mathematical; when the history says nothing, it stays at Compass. A raster from Flow Direction's D8 option is a different matter. Its values, 1, 2, 4, 8, 16, 32, 64 and 128, are codes for eight categories, not angles, and the tool warns that they are not valid input.
A tour of the dialog
The dialog asks for the points, the aspect raster, what the raster holds (aspect values, or a DEM to compute them from) and where to write the values; for a new feature class, an output name is suggested from the input, and for the input itself the output name row disappears. Below those are the Interpolate checkbox, the output field name, and the convention drop-down, which fills itself in from the raster's history when it can. The checkbox and field name are remembered from run to run.
Choosing Elevation (DEM) in What the raster holds changes the pane: the convention row no longer applies and three rows appear for the method, the window size (quadratic method only) and the elevation units, the last filled in and locked when the DEM has a vertical coordinate system.
ModelBuilder
When the values go into the input, connect the derived Updated input point features element onward instead of the output feature class.
Parameters
| Label | Explanation | Data type |
|---|---|---|
| Input point featuresRequired · in_points | The points to extract aspect for. An active selection is honored. Single-point features only; multipoint feature classes are not accepted. | Feature Layer |
| Input aspect raster or DEM (single band)Required · in_raster | A single-band aspect raster in degrees, 0 to 360 clockwise from north, with −1 for flat cells (a D-infinity flow-direction raster is also valid with the convention set to Mathematical; the tool warns if the values fall outside −1 to 360), or a DEM with the next parameter set to Elevation (DEM). | Raster Layer |
| What the raster holdsRequired · surface_type | Aspect values, the default, or Elevation (DEM), which makes the tool compute the aspect from the elevations by the method chosen below (see Computing from a DEM). | String |
| Where to write the valuesRequired · write_to | A new point feature class (a copy of the input), the default, or A new field in the input feature class, which adds the field to the input itself and disables the output name. | String |
| Output point featuresOptional · out_points | The new point feature class: a copy of the input points with all their attributes plus the new aspect field. A name is suggested from the input. Required when the values go to a new feature class; ignored when they go into the input. | Feature Class |
| Interpolate values at the point locations (weighted mean direction)Optional · interpolate | Unchecked (default): each point gets the value of the cell it falls in, as stored, including −1 for flat. Checked: each point gets the bilinear weighted mean direction of the four surrounding cell centers, with flat and NoData neighbors left out and the weights renormalized; all-flat neighbors give −1. | Boolean |
| Output field nameOptional · field_name | The name of the new DOUBLE field. Default Aspect; adjusted if the name is not valid for the output workspace or is already in use. | String |
| Input aspect convention (aspect raster only)Required · input_convention | Compass (0 = north, clockwise) for ordinary aspect, or Mathematical (0 = east, counter-clockwise; e.g. D-infinity) for a D-infinity flow-direction raster, whose values are then converted to compass degrees. Set automatically when the raster's history identifies a D-infinity raster. Does not apply to a DEM. | String |
| Method (from a DEM)Optional · slope_method | Only when the raster is a DEM. Horn (3 x 3; the method of Esri's Slope and Aspect tools), the default, or Quadratic least squares (choose the window size); see Computing from a DEM. | String |
| Window size in cells (quadratic method)Optional · window_size | 3, 5, 7, 9, 11, 13 or 15 cells on a side for the quadratic fit; Horn's method is always 3 × 3. Default 3. | Long |
| Elevation units (from a DEM)Optional · elev_units | Meters or Feet. Filled in and locked from the DEM's vertical coordinate system when it has one; otherwise choose, since a wrong unit scales every value. | String |
| Updated input point featuresDerived · updated_points | For ModelBuilder: the input point features with their new field, filled in when the values are written into the input feature class and empty when a new feature class is made. | Feature Layer |
Python
interpolate is True or False. The write_to strings
are exactly "A new point feature class (a copy of the
input)" and "A new field in the input feature
class". The input_convention
strings are exactly "Compass (0 = north, clockwise)"
and "Mathematical (0 = east, counter-clockwise; e.g.
D-infinity)". The surface_type strings are
"Aspect values" and "Elevation (DEM)", and
the slope_method strings "Horn (3 x 3; the method of
Esri's Slope and Aspect tools)" and "Quadratic least
squares (choose the window size)". The new field is DOUBLE, in compass degrees;
−1 is flat; NULL (geodatabase) or −9999 (shapefile) is
NoData or outside the raster.
import arcpy
arcpy.ImportToolbox(r"C:\path\to\JennessEnterprisesTools.pyt") # your installed path is shown in this tool's run messages
# Value of the cell each point falls in (no interpolation), written to a copy of the points
arcpy.jenness.ExtractAspectValuesToPoints(
in_points=r"C:\Project\Wildlife.gdb\telemetry_points",
in_raster=r"C:\Project\Terrain.gdb\aspect",
surface_type="Aspect values",
write_to="A new point feature class (a copy of the input)",
out_points=r"C:\Project\Wildlife.gdb\telemetry_points_Aspect",
interpolate=False,
field_name="Aspect",
input_convention="Compass (0 = north, clockwise)")
# Circular (weighted mean direction) interpolation, written into the input feature class
arcpy.jenness.ExtractAspectValuesToPoints(
in_points=r"C:\Project\Wildlife.gdb\telemetry_points",
in_raster=r"C:\Project\Terrain.gdb\aspect",
surface_type="Aspect values",
write_to="A new field in the input feature class",
interpolate=True,
field_name="Aspect")
# Aspect straight from a DEM: Horn's 3 x 3 method, the numbers Esri's Aspect tool gives
arcpy.jenness.ExtractAspectValuesToPoints(
in_points=r"C:\Project\Wildlife.gdb\telemetry_points",
in_raster=r"C:\Project\Terrain.gdb\dem",
surface_type="Elevation (DEM)",
write_to="A new field in the input feature class",
interpolate=False,
field_name="Aspect",
slope_method="Horn (3 x 3; the method of Esri's Slope and Aspect tools)",
elev_units="Meters")Recommended citation
Credits and references
By Jeff Jenness, Jenness Enterprises (www.jennessent.com). The tool is modeled on Esri's Extract Values to Points; the weighted mean direction follows the circular statistics of Batschelet (1981), Fisher (1993), Mardia and Jupp (2000) and Zar (1999), as set out for wildlife work in Jenness (2012). The DEM option uses Horn's (1981) gradient, the method of Esri's Aspect tool, or the Evans–Young quadratic; the comparison of estimators is from Zhou and Liu (2004).
- Batschelet, E. 1981. Circular Statistics in Biology. Academic Press, London. ISBN 0-12-081050-6.
- Esri. Extract Values to Points (Spatial Analyst). ArcGIS Pro tool reference. pro.arcgis.com. Accessed on 27 September 2026.
- Esri. How Slope works and How Aspect works. ArcGIS Pro tool reference. <https://pro.arcgis.com/en/pro-app/latest/tool-reference/spatial-analyst/how-slope-works.htm> and <https://pro.arcgis.com/en/pro-app/latest/tool-reference/spatial-analyst/how-aspect-works.htm>. Accessed 28 Sep 2026.
- Esri. Surface Parameters (Spatial Analyst). ArcGIS Pro tool reference. <https://doc.esri.com/en/arcgis-pro/latest/tool-reference/spatial-analyst/surface-parameters.html>. Accessed 16 Oct 2026.
- Evans, I. S. 2013. Land surface derivatives: history, calculation and further development. Proceedings of Geomorphometry 2013, Nanjing, China. <https://geomorphometry.org/uploads/pdf/pdf2013/Evans2013geomorphometry.pdf>. Accessed 16 Oct 2026.
- Fisher, N. I. 1993. Statistical Analysis of Circular Data. Cambridge University Press, Cambridge. doi.org/10.1017/CBO9780511564345
- Hodgson, M. E. 1995. What cell size does the computed slope/aspect angle represent? Photogrammetric Engineering & Remote Sensing 61:513–517.
- Horn, B. K. P. 1981. Hill shading and the reflectance map. Proceedings of the IEEE 69:14–47. https://doi.org/10.1109/PROC.1981.11918
- Jenness, J. 2012. Issues with directional data. Remotely Wild, newsletter of the Spatial Ecology and Telemetry Working Group of The Wildlife Society. PDF
- Mardia, K. V., and P. E. Jupp. 2000. Directional Statistics. Wiley, Chichester. doi.org/10.1002/9780470316979
- Wood, J. 1996. The geomorphological characterisation of digital elevation models. Dissertation, University of Leicester, Leicester, United Kingdom.
- Zar, J. H. 1999. Biostatistical Analysis, 4th edition. Prentice Hall, Upper Saddle River, New Jersey. (Chapter 27, circular statistics.)
- Zhou, Q., and X. Liu. 2004. Error analysis on grid-based slope and aspect algorithms. Photogrammetric Engineering & Remote Sensing 70:957–962. https://doi.org/10.14358/PERS.70.8.957
Licensing information
Works at every ArcGIS Pro license level (Basic, Standard, Advanced). No extension licenses are required; the extraction and the circular interpolation are computed internally, without Spatial Analyst.
Related tools and pages
- About Aspect — why aspect matters, and why it needs circular arithmetic.
- Aspect Focal Statistics — circular statistics over a neighborhood of cells.
- Aspect Transformation — classes, northness and eastness, and deviation from a bearing.
- Aspect Zonal Statistics as Table — circular statistics by zone, including point zones.
- Extract Slope Values to Points — the same tool for slope, interpolating on the slope angles, with the same choice of where to write the values.
- Projecting Rasters — why the raster is read in its own coordinate system.