Select to view content in your preferred language

Point Statistics output - force 32 bit pixel depth?

1210
3
08-03-2011 11:57 PM
UrbisMelbourne
Emerging Contributor
Hi,

My input: point data, with the input field being population counts
Output raster is going into a geodatabase, so it should be a GRID by default.
I'm using a circle neighborhood, with a radius of 5000m, and the statistics type is SUM.

The output raster tops out at 65535.  This seems to indicate it's a 16 bit raster.  I know for a fact that the population sums within a 5km radius in some areas should be in the low 100,000s, so I don't understand why the GRID file isn't defaulting to 32 bit unsigned in terms of pixel depth.

What am I doing wrong here?  Can I force the output to be 32 bit unsigned?
0 Kudos
3 Replies
UrbisMelbourne
Emerging Contributor
Couldn't fix this issue, so I eventually gave up and implemented a workaround: in my point features, I added a new FLOAT field and calculated across the values, divided by 10.  I then re-ran the Point Statistics on the new field, and used Raster Calculator to multiply the resulting raster by 10.

Tedious to have to do this for what should be a one-step process, but there you go.
0 Kudos
MatthewArmistead
New Contributor
Nathaniel I'm running into the same problem and cannot find a solution other than the workaround that you mentioned.

http://support.esri.com/en/knowledgebase/techarticles/detail/35053
I did find this Knowledge Base article that recommended changing a field in the Raster Dataset options under Customize > ArcMap Options but that did not change anything for me. No matter what the number is set to it still tops out at 65535.
0 Kudos
kevinjohns
New Contributor
same thing is happening to me. i'm running pointstatistics on a statewide census points layer (50mm features) on a double field and depending on the field, it creates an unsigned 8-bit or a signed 16-bit raster. i'll try converting the double field to a float field and see if that helps, but it'd be really nice if this could be addressed without significant workaround.
0 Kudos