Extract Values to Points does not work correctly

[DuncanHornby]

All,

I wish to share my experience with some curious behaviour of ArcMap 10.7

A quick search on GeoNet for similar Q&A throws up many problems with this tool by many users over the years, often the problem seems related to coordinate systems. Often with replies from you guys!

But I spent the best part of this this afternoon trying to run this tool from a script and it was failing to return sensible values (but was giving no error).

My first step in my code was to use the Generate Points Along Lines tool and these fed into the Extract Values to Points tool. Simple enough but the elevation returned from my DEM was nonsense, a constant value greater than any elevation in the data! Yes my coordinate systems were correct.

It took a lot of time and effort but I worked out that it was to do with the Generate Points Along Lines tool creating an ORIG_FID and Shape_Length field (this is a point dataset so why it should have a length field I do not know). The ORIG_FID I could delete but Shape_Length would not delete, it seems to be a  protected field and the work around was to run the Copy Features tool to copy to a temporary dataset and this dropped the Shape_Length field. I then deleted the ORIG_FID and it was this dataset that I could feed into Extract Values to Points and get sensible values. It seems that this tool was being unhinged by these auto-generated fields.

So if Extract Values to Points is misbehaving for you it may down to the input having protected auto-generated fields, something to be aware of...

Dan Patterson‌ Xander Bakker‌ Joshua Bixby‌ Curtis Price Matt Wilkie Cole Andrews Thomas Colson

[DanPatterson_Retired]

I am sure you are aware of the checks

in_fc = r"C:\Arc_projects\Free_Tools\Free_tools.gdb\Polygons"
desc = arcpy.da.Describe(in_fc)

desc.keys()
    dict_keys(['catalogPath', 'FIDSet', 'aliasName', 'areaFieldName', 'baseName', 
               .... snip.... 'fields',... snip])

fld_names = [f.name for f in desc['fields']]

del_flds = [f.editable for f in desc['fields']]

fld_names
['OBJECTID', 'Shape', 'CENTROID_X', 'CENTROID_Y', 'INSIDE_X', 'INSIDE_Y', 'Shape_Length', 'Shape_Area', 'Parts', 'Points', 'Curves']

del_flds
[False, True, True, True, True, True, False, False, True, True, True]

can_delete = list(zip(fld_names, del_flds))

can_delete
[('OBJECTID', False), ('Shape', True), ('CENTROID_X', True), ('CENTROID_Y', True), ('INSIDE_X', True), ('INSIDE_Y', True), ('Shape_Length', False), ('Shape_Area', False), ('Parts', True), ('Points', True), ('Curves', True)]‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

You can then check your list against the combinations.  I have seen this behaviour before

[MattWilkie1]

Thanks for the heads up and sleuthing Duncan!

Untested: Lines 50:56 of generatepointsfromlines.py* seem the likely place to patch:

    # Add a field to transfer FID from input
    fid_name = 'ORIG_FID'
    arcpy.AddField_management(output_fc, fid_name, 'LONG')

    # Create new points based on input lines
    in_fields = ['SHAPE@', 'OID@']
    #out_fields = ['SHAPE@', fid_name] # original
    out_fields =  ['SHAPE@X','SHAPE@Y','SHAPE@Z','SHAPE@M',fid_name] # speculative fix 

Assuming it works at all, probably a good idea to test if @Z and @M exist first.

* Located in C:\ArcGIS\Desktop10.6\ArcToolbox\Scripts for me.