5

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.

  • What you describe in words (excluding the code you have pasted) should work. I cannot comment on your code because you have only presented something that appears to be on its way to becoming a code snippet that works up to where you are stuck. I say this because you have a suspicious ... in the middle of it and you seem to be using some aliases DM and DA that not only make the code harder to read but have not been specified. – PolyGeo Sep 9 '16 at 23:38
  • Also, if the issue is with the CreateFeatureClass line then anything after that is irrelevant to the question that you are asking. To be certain that it is the CreateFeatureClass line at fault can you include the full error message, which includes its line number, from running any code snippet that you present, please? – PolyGeo Sep 9 '16 at 23:41
  • @PolyGeo: Sure. Anything I've left out is an attempt to make things more legible. I've gone back and added the DM and DA assignments, as well as the full error message. The line with CreateFeatureClass is the line identified in the error message. There are 16 more lines I can add in place of '...', but I'm pretty sure they're irrelevant. I'll go ahead and add them, and I suppose I can remove them again later for clarity once people have ruled them out as the problem. – joechoj Sep 9 '16 at 23:47
  • 1
    See gis.stackexchange.com/a/34964/64785 – Midavalo Sep 10 '16 at 1:53
  • 1
    For ideas on how to quickly accrue the 50 pts of rep and why we require it to comment everywhere please review meta.gis.stackexchange.com/q/3860/115. It looks like you got downvotes when you appeared to be just dumping your code in (which is not what I requested) rather than working to write a code snippet that would help us help you. . – PolyGeo Sep 11 '16 at 20:44
4

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.

  • This looks promising. I've been able to run it successfully after closing out the MXD, and the overwrite does occur. So overwrite will only occur if enabled in ArcMap and running native tools; or using ArcPy with layer not loaded in an MXD, yes? I made the following edits to your explanation, for clarity. Please correct me if I've misinterpreted. 1: "The overwrite environment setting ..." --> "The overwrite environment setting within ArcMap...." 2: "It only works like that" --> "Overwriting will only occur". 3: "... any other MXDs" --> "... any other open MXDs". – joechoj Sep 12 '16 at 22:17
  • 1
    @joechoj It sounds like that was the issue then! I have edited my answer fairly extensively to try to explain it more clearly and comprehensively. – malcoholic Sep 13 '16 at 1:03
  • I think that explains it. Thanks very much for expanding your answer, very helpful. – joechoj Sep 13 '16 at 4:00

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.