I am trying to run the Weighted Sum tool but I keep getting the Error 010050 Cell size not set. The problem is that I have set the cell size in the environment and can't quite figure out the issue. Any ideas?
cell size was set within the tool's environments? or at a general level?
Are you still having this issue? I am having an issue with it...
I actually ran into this issue recently. Any news on it? I eventually just sampled the raster to vector and did a calculate field in python to do the weighted sum...
Anyone else?
This GP error sometimes comes up when the output cell size the system attempts to set is invalid, for example, it's set to 30 and the input coordinate system is in degrees units. I have a wild guess that this may be what's happening here.
I have also seen this error (usually together with others) when the raster output path or scratch workspace path is invalid (or the workspace does not exist). The raster can't be written and this error popups as a side-effect.
When doing this kind of analysis, it's advisable to project and resample your input data are in the same coordinate system before you run a raster analysis, as the environment can get garbled when projecting on the fly. You also have less control of resampling, etc when you have the system do all the resampling and projecting automatically.
Hi Curtis, I will check on this back at work, but I am not sure that explains my error. This does help though, it gives me something to check. I went though pains to make sure everything was state plane, but I could have missed something.
Hey I am having the same issue. Except I am using the weighted overlay tool.
See my response above
Cell Size (Environment setting)—Geoprocessing | ArcGIS Desktop
Hi Curtis, To follow back to this, it seems weighted sum does not have the same raster name validation as raster calculator. This is one thing I found. Raster Calc requires 13 character names. Another thing I found is even when the name is less than 13 characters, this tool does not work. I have not tried reprojecting, but I have tried using raster calculator and it is working on the same data. I am thinking I will just elect to do this the old fashion way in raster calculator. It feels like a bug, but I could be mistaken.
David
The issue with 13 characters is when data is output in grid format. If you save to another format (for example, using a .tif extension) the naming rules are little more relaxed. In general I highly recommend sticking with short raster names that start with a letter and only [a-z][0-9]_ -- this usually keeps you out of trouble. Also, never use spaces in data file, field, workspace, folder names.
A copy paste from your dialog window would probably help us out here diagnose your problem. It does sound like there may be a path naming issue.
https://community.esri.com/people/curtvprice/blog/2016/05/07/how-to-name-things-in-arcgis?sr=search&searchId=5efcd37d-0415-47ff-b244-c59a1997c2a0&searchIndex=0
I had the same issue then I got rid of the mask I had in environments and Weighted Sum worked like a charm
I don't like that this is the answer...I actually used a mask for my processing. It sounds like it might just make sense to use a processing extent and then mask after then?
It may work better if you use a raster mask instead of a polygon. The behind the scenes vector to raster processing doesn't always perform well, especially if the polygon is complex. Also, I didn't mention, for heavy raster processing it is best practice to set the scratch workspace to a local, nicely named folder. This allows these (so-called) in-memory temporary rasters used by map algebra to be written quickly to disk.
Removing the raster mask worked for me!
Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
