I just came across this bug in 10.0 SP5; as described above, it seems they did fix it in 10.1 SP1.
The order in which I added raster layers was important; if I added a layer that had NODATA values, all subsequent layers would also show NODATA values for those locations. If the same layers were added before the NODATA layers, the values would be fine.
Running the multivalue tool one layer at a time also seems to work (of course, this defeats the purpose of the multi-value tool).
layers =
for layer in layers: arcpy.sa.ExtractMultiValuesToPoints('RandomPoints', layer, 'NONE')
Is anyone else still having problems with this? I'm running ArcGIS Version 10.4.0.5524 (Advanced License) and over the past few months I have been experiencing issues with the ‘Extract multi value to points’ tool that I did not have before. The problems are:
I don't know about the first issue. But it is generally true that OBJECTID is internally maintained by the database (ie it can be changed by the database software where the data is stored) and is not persistent. You should use some other identifer besides OBJECTID to keep track of things if you need it to remain unchanged through edits and modifications to the dataset (including adding fields).
What format is the point dataset in? You may want to try a different format and see if the tool behaves better.
Hi Curtis,
Thanks - I've been directed to some text in the tool description that does warn that this can happen:
Whilst I can work round the issue it seems strange to me that:
1. This issue has been introduced relatively recently (I have been using this tool without this issue for several years)
2. The ObjectID can be modified. I thought the whole point of an object identifier was that it is a unique and constant reference to an object? I can't see any user benefits of allowing the ObjectID to be modified but would like to think that it is more than just lazy coding?
I've tried working from both shapefiles and feature classes within a geodatabase and the issue occurs regardless. Or did you mean something else when referring to different formats?
Cheers,
Chris
I thought the whole point of an object identifier was that it is a unique and constant reference to an object? I can't see any user benefits of allowing the ObjectID to be modified but would like to think that it is more than just lazy coding?
Unique, yes. Persistent, definitely not. This has to do with how data are stored in the RDBMS world - objectIDs are used internally by the software for its own purposes, for example in some RDBMS's when an object is edited, instead of deleting it, a new feature is created and added to the end of the table, and the existing object is flagged for deletion ( this is what "Compact geodatabase" is all about.) Supporting this means that OID should not be messed with, and is only useful for relates right after an operation (for example an Intersect operation). Of the inputs of the intersect are edited, OID's may change and the joins back to the inputs may no longer work. How persistent the OIDs are depends on the data format (RDBMS [various formats], coverage, shapefile, gdb) and which operations you do.
Clearly they mess with this tool in some way that alters the input, I'm guessiong for robustness and performance reasons. I wonder why this basic tool has been so buggy for so long? There are probably issues 'under the hood' we don't know about.
Extract Multi-Values To Points and Sample are very similar tools and often I use one when the other won't work on a given dataset (on a given day!!!) Sample is a Spatial Analyst tool and honors the raster environment settings well, so it is sometimes more useful than the other.
Extract Multi-Values to points is a very useful tool, and I use it often.
Make sure the raster datasets and the feature shp file conform to the same coordinate sys. The points might display correctly on the rasters in the DataFrame due to the on-the-fly projection, but it is important that the coordinate sys is consistent across the stack and match to that of the point feature layer.
I remember having issues with the use of this tool a few years ago. Using it again now caused me Python to crash each time. Almost giving up (thinking this tool was still not improved by ESRI) I read the comment by Mahesh Rao and indeed I had forgotten to check if my layers had the same coordinate systems. After reprojecting the feature layer to the projection of the raster layer, the issue was solved. Thanks! So, make sure to check the coordinate systems of your input layers...