Extract Multi Values to Points NOT WORKING!

[KevinWiley]

I am trying to use this tool, but it isn't working correctly.  I'm trying to extract values from multiple rasters to a set of points.  I run the tool, and it always creates the new fields in the point attribute table; however, it never populates those fields with all the values.  Sometimes, it's no values at all. Sometimes, it's one out of five raster fields. Sometimes, it's three out of seven. But so far, I've never had all the new fields properly populated with values. Also, if I use the Extract Values to Points tool, and go one raster at a time, that tool works fine.  But the multi tool would be far more convenient, if only I could get it to work.  Is this tool just buggy, or do I need to do something differently?  Please help!

[StephenBan]

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).

[ChrisSimpson]

Try switching off Background Processing in Geoprocessing Options.

[ScottLamon1]

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).

I don't think they fixed this in 10.1.  I have a user who is having the tool crash on him if he adds the rasters in the wrong order.

[ThomasStanley]

I find that ArcMap 10.2 crashes to desktop if I load this tool up with many layers. However, it functions quite reliably one layer at a time. The python console makes this very easy to use:

layers = 

band-select layers, drag and drop into console, hit enter,

for layer in layers:
  arcpy.sa.ExtractMultiValuesToPoints('RandomPoints', layer, 'NONE')

hit enter

Has been much easier and more foolproof than other methods.

[ChrisParker]

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:

• The first time I run the tool it assigns incorrect values for the newly created field (but if I re-run the tool it does assign the correct values from the raster to the newly created field)
• Whenever I run the tool the ‘OBJECTID’ fields for each point change from their original values – so the points are re-ordered.

[curtvprice]

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.

[ChrisParker]

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

[curtvprice]

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.

[maheshrao]

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.

[AlfredWagtendonk]

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...