I have a broad question on how to calculate the 'correct' cell size for a raster when analyzing an area not at the equator. My goal is to project a land cover raster provided in GCS WGS84 to an equal area projection and 'accurately' calculate the area in hectares.

The land cover layer metadata (accompanying text file) states that it has a 300 m resolution, by which I assume they mean 300 m equivalent at the equator. Manually measuring the cell size near the equator seems to indicate that this could be true. However, my area of interest is centered on 15 North Lat., 96 East Long. and therefore each projected cell will cover a slightly different area.

The issue arises when I choose the cell size while projecting to equal area. Two older posts suggest projecting and/or using a raster calculator equation that incorporates the latitude in order to calculate the correct area. Does this make sense or is there a better and simpler way to achieve this goal:



  • 1
    +1 This is a good simple question but it has a complex answer. One option is to dodge the issue by calculating areas in the original WGS84 coordinates. You can do this by computing zonal sums of cell areas. The cell areas can be found by multiplying the squared cellsize by a "shrinkage factor," which can be computed either with a spherical formula (it is the cosine of the latitude) or an ellipsoidal formula (a more complicated function of the latitude). – whuber Aug 26 '13 at 15:31
  • @whuber: thank you for the tip, that's an elegant solution. My initial thought is that this would be best for calculating the total regional area, by raster value? I also need to tabulate area by several area boundary zones (created by converting polygons to rasters with the same cell size as the land cover raster). As such, do you think it would it be easier to project to equal area, then calculate the area by land cover type/ spatial zone. Or, instead select raster cells by a location (spatial zone), extract by mask, and calculate using (cell size)^2 * Cos($$YMap * 0.0174532925)? – Dan Aug 26 '13 at 16:08
  • Ran out characters, to add: I have tried several methods, but I am trying to optimize this as I want to run it in a model. As such, the efficiency/logic is important to me. – Dan Aug 26 '13 at 16:10
  • To tabulate the areas, Dan, assuming the polygons do not overlap, compute a "zonal sum as table." The polygons are the zones and the values to sum are the cosines. Multiplying the zonal sums by the squared cellsize finishes the work. – whuber Aug 26 '13 at 17:42
  • I still do not quite follow. Zonal Statistics to Table using a sum of cosines based on the centroid of each polygon? I could not calculate this using cos("centroid field name here) * radian scaling factor. However, if I could, I do not understand why to sum cosines vs. cell count. As such, my final 'confused about area' question is (1) If I set the cell size as exactly 300m in equal area, will this be correct (i.e. represent 300m of area, regardless of latitude (it should, it is equal area?). (2) If not I should use your method, what (raster or vector) is the cosine calculated for? – Dan Aug 27 '13 at 8:06

Your Answer

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

Browse other questions tagged or ask your own question.