[GIS] Output not overwritten despite “overwriteOutput = True”

arcmaparcpyenvironment variableerror-000258overwriteoutput

As I understand it, overwriteOutput is an environment setting that controls whether an output overwrites an existing file of a duplicate name. Just re-checked the help pages, which confirms.

Despite having checked the relevant box in Geoprocessing > Geoprocessing Settings, as well as specified in my standalone python script that overwriteOutput = True, I received an error that the output file already exists.

bathy = r'F:\Joe_School\Thesis\data\kur_5m_bathy\kure_5m'
out_prof = r'F:\Joe_School\Thesis\scripts\Jerry\scratch.gdb\testprof'

import arcpy, os, math, time
from arcpy import env
import arcpy.management as DM
arcpy.CheckOutExtension("spatial")

env.overwriteOutput = True
desc = arcpy.Describe(bathy)
env.outputCoordinateSystem = desc.spatialReference
env.workspace = os.path.dirname(out_prof)

centroid = pointx, pointy = (367521.402, 3147853.81)
XMin = pointx - 200
XMax = pointx + 200
YMin = pointy - 200
YMax = pointy + 200
patch = SA.ExtractByRectangle(bathy, SA.Extent(XMin, YMin, XMax, YMax), "INSIDE")

DM.CreateFeatureclass(os.path.dirname(out_prof), os.path.basename(out_prof), "POLYLINE", "", "", "", patch)

It errors out on CreateFeatureClass.

Message File Name   Line    Position    
Traceback               
    <module>    <module1>   22      
    CreateFeatureclass  c:\program files (x86)\arcgis\desktop10.3\ArcPy\arcpy\management.py 1807        
ExecuteError: ERROR 000258: Output F:\Joe_School\Thesis\scripts\Jerry\scratch.gdb\testprof already exists
Failed to execute (CreateFeatureclass).

Given that there are 2 places that I know of to set this env setting, which takes precedent, and how do I make my script overwrite duplicate files?

I looked at arcpy.env.overwriteOutput = True appears not to be working?, but the problem there seemed to be with an associated function, and not the 'overwriteOutput' setting.

Best Answer

You said this is a standalone script, so it is possible that there is already a lock on the feature class you are trying to overwrite if you have it open in an MXD already. From the ArcMap resource on File Geodatabases and Locking regarding editing or modifying a dataset::

However, if another process is already accessing the data, whether it be a process on your computer or another user's, ArcGIS prevents you from performing any of these operations until the other process has terminated.

It does this by placing a .lock file on the feature class. If you have that feature class loaded in an MXD that is currently open and you attempt to overwrite it using a tool within ArcMap, the tool will look to the environment settings and if overWrite = True then it will attempt to overwrite it. If that feature class is only locked by that one particular process that is attempting to modify it, it will be permitted to overwrite.

However, if that feature class is also locked by another process (eg open in another MXD concurrently, editing its metadata in ArcCatalog, or being accessed by a standalone script tool), then regardless of the environment setting for overwrite the feature class cannot be modified until the other locks are removed. When the process accessing the feature class is terminated, the lock is removed (or supposed to - sometimes you can end up with .lock files that remain when they shouldn't).

Make sure that any other processes that might be accessing the dataset are terminated. Try the following:

  • close any MXDs that are accessing the feature class

  • reboot your python editor

  • sometimes even rebooting your machine and ArcMap/ArcCatalog fully can do wonders for removing pesky lingering lock files that won't disappear.

For the query regarding which level of the overwrite environment setting takes precedent - I would read over the documentation for geoprocessing enviroment settings and hierarchy, and also the related subpage on script environments and submit a new question if you need to. If you are running a standalone script, the overwrite environment setting is not inherited from the application level settings (what you set in Geoprocessing options in ArcMap) - the only thing that matters is what is set in the script.

Related Question