Setting the Z Factor parameter correctly

By Charlie Frye, Esri Chief Cartographer

Z factor - Thumbnail

We set the Z-Factor parameter based on our latitude.

The Z-Factor parameter is in many Spatial Analyst and 3D Analyst tools; Hillshade and Slope are the two that I use most. Not setting the Z-Factor correctly makes the hillshades look heavy or leaden. It will also make slope values, e.g., for percent slope very small, like 0.00023% – 0.00032% instead of 1.8% to 7.2%.

When we download digital elevation models (DEMs) in raster format, the spatial reference is usually a geographic coordinate system (versus a projected coordinate system). Using these DEMS to create a hillshade using the Hillshade tool with the default values often produces a result that looks molten or over-done. This happens because linear units are not and cannot be defined for geographic coordinate systems.

Z factor - Figure 1

Z factor - Figure 2

Because the Hillshade Tool needs linear units to perform the function, it assumes that the linear unit of measurement (X,Y) is the same as the height unit of measurement (Z). The problem occurs when the linear units for the geographic coordinate system are different than the Z units for the DEM, like decimal degrees (which will vary across the extent of the data set depending on latitude), with a Z unit in meters or feet.

There are two ways to avoid this problem: 1) project the DEM using the Project Raster tool so that the linear units are defined (the linear unit is an inherent property of projected coordinate systems), or 2) use the optional Z-Factor parameter in the Hillshade tool (which multiplies the decimal degree value by the conversion factor to produce a measurement feet or meters, depending on the value you use). In terms of best practices, for medium and large scale maps we recommend projecting the DEM before producing a hillshade or doing any analysis. The only reason we can think of not to project a DEM or any data products produced from the DEM is when these will be part of a web service where the client of the service can choose a projection for the data themselves (projecting and then re-projecting a raster can result in unwanted loss of information).

If it is necessary to retain the DEM in a geographic coordinate system, knowing the appropriate values for the optional Z-Factor parameter is essential. The exact values will vary depending on the latitude of your dataset, here are some values to start with:

While there is variation in latitude within the extent of the data set (from the northern to southern edges), it is usually OK to use a single value in the approximate center of your dataset. Also, it is usually OK to use an approximate value since the visual differences in using similar numbers are so minimal. If you need to calculate a more exact value, simply determine the length of one degree at the latitude being mapped.

Latitude Z factor (in meters) Z factor (in feet)
0 0.00000898 0.00000273
10 0.00000912 0.00000278
20 0.00000956 0.00000291
30 0.00001036 0.00000316
40 0.00001171 0.00000357
50 0.00001395 0.00000425
60 0.00001792 0.00000546
70 0.00002619 0.00000798
80 0.00005156 0.00001571

In addition to the Hillshade tool, there are many other tools in the Spatial Analyst and 3D Analyst that depend on proper use of the optional Z-Factor parameter when the data you are working with uses a spatial reference that is geographic coordinate system. You can use the same guidelines as above in these cases as well.

Note that you should also use the Z-Factor when the X,Y values are in feet and the Z units are in meters, or visa versa.

This entry was posted in Imagery, Mapping, Migrate and tagged . Bookmark the permalink.

Leave a Reply


  1. MappingCenterTeam says:

    I’d rather recommend using the z-factor to adjust for different horizontal / vertical units (like meters / feet) ONLY. Brightness and contrast are best adjusted by the lighting / insolation angle in the hillshade dialog. ‘Misusing’ the z-factor for tht might lead to wrongly manipulating this same z-factor in other functionality (like slope, hydro), where this would generate wrong and useless results.

    Posted by Josef Strobl on June 16, 2007 at 10:00 AM PDT

    I absolutely agree with Josef’s point regarding the potential for misusing many of the tools that rely on a Z-Factor for just using the values in the table I included. My first recommendation was to appropriatly project the data, which entirely alleviates or at least minimizes the potential for problems.

    I included the lines about the other tools because I’ve seen too many people run a slope analysis on data that only has a GCS and while they recognize the values as garbage, they think it’s the tool’s fault, and give up. So, in those cases if the data must remain in a GCS, then definitely heed Josef’s warning and fully extrapolate a Z-Factor conversion that exactly fits your data’s extent.
    Posted by Charlie Frye on June 19, 2007 at 10:12 AM PDT

  2. stacemaples says:

    I’ve made the “ugly hillshade” an example of the necessity of projecting data in my teaching for years. Now, I find that the Hillshade tool in 9.2 will calculate & populate the Z-Factor field with a value that provides one with a perfectly serviceable hillshade. I can’t find any mention of this new feature in any forums or Service Pack docs.

    At the same time, ESRI has dropped the “Assumed GCS” feature (which is great, in my opinion, since it forces one to deal with Proj’s & Coord Sys’s) so that I’ve added a section to several of my sessions on defining projections (aggravatingly enough for data downloaded from the ESRI Sources).

    So I wonder…

    What is the motivation for “dumbing down” tools like this, while removing other “dummy” functions?

    When was this feature added (9.2, SP1, 2, 3…)?

    Stace Maples
    Yale University Map Collection

  3. mapg33k says:

    Can you post the formula for calculating the z-factor for a given latitude? I thought I had it figured out but I wasn’t coming up with the same number you were.

    BTW, I use this page as a reference pretty regularly. Thanks for posting this.

  4. cfrye says:

    All I do is just interpolate between the values in the small table given in this blog, no formula needed.

  5. meena18 says:

    i want know the how to calculate the elevation value using the point data

    • cfrye says:

      Meena18–there are many possible answers given the phrasing of your question. I cannot tell whether you want to interpolate an elevation raster from point data, or assign elevation values to points from a elevation raster. If it is the former, then search for “Interpolation” in the help section of the ArcGIS Resource Center. If it is the latter, then search for “Interpolate Shape”, which is the name of the tool that does that task.

  6. inkeninken says:

    Dear Esri Staff and Users,

    currently I am working with an SRTM DEM and I am having trouble projecting it which, I understand, is essential for calculating slope. Its geographical projection is “D WGS 1984″ and so far I have been trying to project it to “WGS 1984 UTM Zone 32N”. Once I entered the information into the “Project Raster” too window, a progress bar window opened up but then ArcMap would set its status to “Not Responding” and the progress bar would stay at 0% (I even tried this over night with no result). Does anyone know what could cause this, and more importantly, how this could be resolved?

    I can perform all kinds of other calculations with the same raster without any problems. Using the above mentioned z-factor I even slope values that are reasonable and which line up with those of another properly projected raster (the latter elevation does unfortunately not cover the entire area that I need slope data for).

    I would greatly appreciate any hints on this!

  7. mcneil1724 says:

    Why does in ARCGIS instead of elevation SRTM shows stretch value?? How can I correct this and find the correct value for height? Thanks!