Extract Multi Value Problem - is there a limit to the number of points?

[KerryNicholson]

Hi,

Im trying to extract from 7 rasters values to my point files.  My point files are HUGE we are talking >3,000,000 points across my landscape that I want to attribute with elevation, slope, etc. values.  I am using Arc10 I have NOT installed any service packs yet.  I am trying to download sp4. 

I have read that there were problems with extract multi values that were to be addressed in the service pack updates, but have no idea what was "addressed".  I vaguely remember running into this problem with Arc 9.3 and being told that there is a maximum limit of 10,000 points that can be processed at a time (or something like that number).  Is this true? Is there a way around this?  Ive been told to increase the processing speed that to use SAMPLE or/and to use File geodatabase files instead of shape files.  Will SAMPLE have a limit to the number of locations to process?  Will File Geodatabase have the same limitations?  I do not know if my problem which is basically I can't get extract values to work on my larger files when it works on my smaller flies.

[MarcinGasior]

I don't know if there's any limit.
But I made a try:
- file geodatabase AG10, sp2
- ~1,000,000 points
- 2 rasters
- the same coordinate system for features and rasters
- Sample tool

After ~20 minutes I had the table with point's IDs, coordinates and values from both rasters.

So, just do it;) And you will know if there is a limit on your system:)

[curtvprice]

  Will File Geodatabase have the same limitations?  I do not know if my problem which is basically I can't get extract values to work on my larger files when it works on my smaller flies.

Extract Multi Values to points has been a little more squirrelly about things like spaces in pathnames, but the biggest issue you may be running in with your large files of millions of points is that if the workspace is a folder, you may run into the 2.1GB limit of file size (with .dbf files). I'm assuming that's where this advice was coming from - from tech support? Other posts? At 9.3,  no matter the ultimate desination, the output would be written to a .dbf in the scratch workspace (or a the folder above it) and then copied to the eventual output location -- so there was no way around the 2.1GB limit and tiling your data was the only way around it.  You could monitor the scratch workspace (which should be in the same .gdb for quickest processing). If the .dbf size is the issue, if you monitored a file scratch workspace, you'd see the temporary .dbf file grow until the tool crashes.

Since ArcGIS 10.x Spatial Analyst tools now do native read write, the current and scratch workspace can both be set to file geodatabase, and no .dbf is written, so you may have a little more luck with your large files.

Sample is an older tool (from Arcinfo GRID) that is a little clunkier but sometimes will work with EVTP will not.

BTW, you can look at issues addressed on the service pack page, searching though the NIMs for things you are interested in. Also, if you have a NIM, sometimes you can find it on the support site by searching by its number to check on its status. If it's not there, tech support is usually happy to check on the status of a known NIM for you.