3

I'm having a bit of trouble with a script that uses ArcPy. I keep getting the following error:

ExecuteError: ERROR 000622: Failed to execute (Reclassify). Parameters are not valid. ERROR 000628: Cannot set input into parameter remap.

This would seem simple to fix, but I've reached the edge of my knowledge without making headway. The most frustrating thing is that RemapRange isn't throwing any errors at all, so I don't know why Reclassify seems to have a problem with the type of parameter I'm giving it. Relevant portion of my code is below.

# Set the output raster name
out = "MMRWFS__for" + str(forestValue) + "__gra" + str(grassValue) + "__agr" + str(agricultureValue)+ "__dev" + str(developedValue) + ".asc"
            outASCII = "Resistance Surfaces\\" + out

# Set the reclassify ranges
arcpy.CheckOutExtension("Spatial")
reclassifyValues = RemapRange([[11,12,"NODATA"], [21,24,developedValue],[41,43,forestValue],[71,81,grassValue],[82,82,agricultureValue],[90,95,wetlandValue]])

        # 11 Open Water
        # 12 Perennial Ice/Snow
        # 21 Developed, Open Space $
        # 22 Developed, Low Intensity $
        # 23 Developed, Medium Intensity $
        # 24 Developed, High Intensity $
        # 31 Barren Land
        # 41 Deciduous Forest *
        # 42 Evergreen Forest *
        # 43 Mixed Forest *
        # 52 Shrub/Scrub
        # 71 Grassland/Herbaceous **
        # 81 Pasture Hay **
        # 82 Cultivated Crops ***
        # 90 Woody Wetlands 000
        # 95 Emergent Herbaceous Wetlands 000

# PROCESS: Reclassify and Convert to ASCII
print "Creating " + out
arcpy.RasterToASCII_conversion(Reclassify(inRaster, reclassField, reclassifyValues, "NODATA"),env.workspace + "\\" + outASCII)

All the importing, etc. is correct. I'm sure there's something obvious here that I'm just missing as a novice.

  • 1
    Although I cannot test this, the documentation is clear that the third element of each list in the argument must be an integer. "NODATA" (appearing in [[11,12,"NODATA"], [21...) is manifestly not an integer. Does the procedure succeed when you replace this string with an integer? – whuber Jul 8 '15 at 22:28
  • 1
    It actually wasn't the string that was the problem (note the third line under "Discussion" here: resources.arcgis.com/en/help/main/10.2/index.html#//… ), but you're still right. One of my values is a float and removing it fixes the problem. Thanks! – Conrad Jul 8 '15 at 23:18
4

Analysis

I would like to share the process of discovering and fixing the problem (whose solution is documented in comments to the question) because it works in many similar circumstances.

  1. Look at the error message. Really read it. This one says

    Parameters are not valid.

  2. Make some guesses about what that gobbledygook means. (Experience helps immensely here.) I interpret "parameters" as being the arguments in some functional call.

  3. Guess where the error occurred. (Good software will tell you, but that hasn't happened here.) One way to guess is to start stripping out code from the bottom first. If the error doesn't occur, add some code back in; if it still occurs, take some more code out. This is a binary search for the source of the error. It will converge quickly to the (or at least a) problem spot. In the present case, no search was needed because we have been presented with a well-formulated question in which the code already is short. It is clear the error must be located in the invocation of RemapRange.

  4. Look up and read the documentation. ArcGIS has extensive publicly-available help. (I Googled for "arcgis help remaprange" and got the right page on the top hit.)

    Because this particular error seems to have something to do with the function call itself, I skipped right to the syntax documentation, looking for a description of the arguments ("parameters") this function expects:

    The components are:

    startValue—The lower boundary ... . (data type: double)
    endValue—The upper boundary ... . (data type: double)
    newValue—The new value to be assigned  .... (data type: integer)
    
  5. Compare the code to the documentation. At this point I could detect a possible problem: one of the arguments, "NODATA", clearly was not of an integer data type, contrary to these explicit requirements. However, I was stymied because the code uses variables for some of the arguments--and the question provided no information about those variables.

This left two obvious avenues of investigation to pursue. (Is "NODATA" allowable? What are the values of the variables?) It turned out that "NODATA" actually is valid, as explained elsewhere in the help page in contradiction to preceding quotation. The OP (original poster) found this (I did not). I will only comment that help pages that contradict themselves (strings are definitely not integers) can be worse than worthless, and leave it at that. The OP, picking up on the thrust of this investigation, checked the types of the other arguments and found one (at least) was not an integer. Problem solved.


Retrospective

It is not unusual for the software to fail us (note the lack of clear useful information in the error message) and the documentation to be confusing or even wrong. That's part of what makes forensic computing so much fun: despite such obstacles, enough clues lie around that you can almost always locate and fix a problem. It's also what makes working with such software so exasperating at times: isn't it obvious that it could be improved, how it could be improved, and that improvements would require so very little effort?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.