3

I am looking at a large geographic area (e.g., continental Africa). I generated a raster of modeled habitat (using MaxEnt) defined in WGS 1984 depicting the hypothetical distribution of an organism at 2.5 Arc-minutes. I am looking to calculate a number of seemingly simple area statistics (using ArcGIS 10.3) but I am having trouble accounting for changes in cell sizes.

For example, I have an expert delineated range polygon shapefile with defined presence zones for the species defined in World Cylindrical Equal Area. I want to know how many pixels (and how much area in km2) of my raster are found in each of the zones, but my raster spans continental Africa. I've run zonal statistics but direct pixel counts provide inaccurate estimates of area size. I've tried projecting my raster into World Cylindrical Equal Area but subsequent error messages have deduced this is not possible.

I've thought about converting the raster pixels to a pointfile, projecting the pointfile to World Cylindrical and then counting the number of pixels per zone as defined in the expert delineated shapefile. If the pointfile and range polygon are both projected into World Cylindrical Equal Area projection would I be able to then 'sum' the number of points found in each zone delineated in the expert range shapefile and then multiply the number of points by the cell-size of the original raster (2.5 Arc-minutes)? Or am I losing information here?

I've looked around on the forum and found similar questions (particularly this one) but I'm a bit lost on how to actually generate a reliable estimate of area spanning large changes in latitude.

I'm not entirely new to GIS but I am a bit rusty.

It seems like this would be a relatively straightforward procedure as most articles I read on MaxEnt outputs report pixel percents and area coverage, but studies spanning large geographic regions must be accommodating for the change in cell size somehow.

I receive the following errors using the 'Project Raster' tool from WGS 1984 to World Cylindrical Equal Area.

ERROR 999999: Error executing function. FDO error: -2147217370 [binary_ProjectRaster] No spatial reference exists. The table was not found. [binary_ProjectRaster] Failed to execute (Project Raster). Failed at Sat Jun 18 15:18:20 2016 (Elapsed Time: 54.82 seconds)

Screenshots of layer projection and tool interface enter image description here

| improve this question | | | | |
  • 1
    welcome to GIS SE. I don't understand why you cannot project the data. I would first investigate this problem because the strange zonal stat results could be linked with it, and s your workaround would not solve it either. What was your tool and error message ? – radouxju Jun 18 '16 at 19:05
  • Thanks for your reply @radouxju I added the error messages as an edit above. I checked the 'properties' of the binary input raster and it is defined and does contain an attribute table. It is entirely possible (likely) I am overlooking something. – toneply Jun 18 '16 at 19:24
  • are you exporting to geodatabase? if so, try another output type (e.g tiff file) and make sure that your names do not include special characters) – radouxju Jun 18 '16 at 19:29
  • I've attempted both geodatabase and general folders created in ArcCatalog. No dice on either one. I've exported the the binary raster as a TIFF and GRID file and tried to project into World Cylindrical but the project raster tool still returns error messages and fails to execute. File names are simple without special characters, ex: Binary.tiff (input), Bin_WC (output). Another thought: I can convert raster to polygon then project the shapefile to World Cylindrical. Presumably I could use this method and a different tool to determine overlap between my layer and the expert layer? – toneply Jun 18 '16 at 19:46
  • this is strange. have you tried to redefine the crs (with define tool) before you project ? If I were you I would switch to gdal for the projection. – radouxju Jun 18 '16 at 20:01
2

on your screenshot, there is a problem with the cell size. The unit in mercator cylindrical is meter, therefore your should "convert the cell size from degree to meters. If your input cell size is 0.04166 degree, I suggest that you use 4000 m (at the equator, 1 degree ~= 110 km and it decreases towards the poles, here I take a rounded value with something smaller to keep the information during resampling)

| improve this answer | | | | |
  • You know, it's amazing. When you do something properly it tends to work. Thanks @radouxju this solved the problem. Projected without issues and cell sizes adjusted for latitude. All I needed was a fresh set of eyes to show me I was asking Arc to do something counter-intuitive re: cell sizes. Thank you. Problem solved. – toneply Jun 20 '16 at 16:49

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.