|
POST
|
Since you are specifying exctly what layer you are interested in ("Base Map Layers\Bay, Lakes & Streams"), try leaving the [0] index off. The [0] being a refrence to the 1st item in a list, but this time you are only expecting one item anyway... So instead of: updateLayer = arcpy.mapping.ListLayers(mxd, "Base Map Layers\Bay, Lakes & Streams", df)[0] try updateLayer = arcpy.mapping.ListLayers(mxd, "Base Map Layers\Bay, Lakes & Streams", df) If that idea doesn't work try: updateLayer = arcpy.mapping.ListLayers(mxd, r"Base Map Layers\Bay, Lakes & Streams", df)[0] instead of updateLayer = arcpy.mapping.ListLayers(mxd, "Base Map Layers\Bay, Lakes & Streams", df)[0] Since Python doesn't like the "\" symbol... You need to either use "\\", "/", or my favorite r"\". Also, I have seen weird things happen then map layers contain special characters such as "&". Hope something here helps.
... View more
10-05-2011
03:17 PM
|
0
|
0
|
2383
|
|
POST
|
ArcGIS/arcpy does suffer from memory leak issues, but let me assure you that it is MUCH better than it used to be. Instead of rebooting the machine, all you need to do to clear up RAM consumption is to exit and then restart the application that is calling on arcpy (ArcMap, PythonWin, Eclipse, etc). There are many tricks to handle memory issues... My favorite is using Python to launch a seperate "worker" python.exe process that will then exit upon completion (thus freeing up the memory it was using). Search this forum for "subprocess", "os.spawnv", "multiprocessing", or "parallel python". You never said what specific tool is causing the issue (i.e. Solve_na)... Care to elaborate?
... View more
10-04-2011
08:27 AM
|
0
|
0
|
3996
|
|
POST
|
This is the basic "logger" template I have been using for the last 6 years or so. Here's one for v93 and one for v10.0. By default the log file gets put in the "root" directory, so search for the "root" variable and edit it.
... View more
09-28-2011
10:14 AM
|
0
|
0
|
1905
|
|
POST
|
Just a comment, but depending on how many points you have (I am guessing these points were derived from a raster), this sort of vector based analysis could take an extremely long time. For example, if your original grid was only 1000 x 1000 cells, your code would need to loop 1,000,000 times. Assuming it takes even just 1 second to do your SelectbyLocation and SelectByAttributes (most likely more than 1 second!), your process will take about 12 days to run. This analysis would be much better handled using a Python dictionary object (a numpy array is another option, but one I don't have any experience with). Dictionaries are an in memory data structure meaning that once you load your data from disk, the processing is, well, light speed. The basic idea is that you load your land use data into a dictionary by using the column and row order as the keys: dict = {} dict[1,1] = 4 #the cell existing at column = 1, row = 1 has a landuse code of 4 dict[2,1] = 4 #the cell existing at column = 2, row = 1 has a landuse code of 4 dict[1,2] = 1 #the cell existing at column = 1, row = 2 has a landuse code of 1 dict[2,2] = 2 #the cell existing at column = 2, row = 2 has a landuse code of 2 Anyway, look into using Python dictionaries or numpy arrays to do this sort of thing... It will be immensely faster and cooler. This sort or "neighbor notation" capability was actually built in functionality in good ole' Workstation ArcInfo Grid. However, ESRI chose not to port neighbor notation forward to ArcGIS, and so we are stuck devising our own data structures and algorithms to deal with ESRI apathy.:mad: Hmmm...
... View more
09-27-2011
01:20 PM
|
0
|
0
|
2689
|
|
POST
|
I would think the set*() methods under fieldInfo() are meant to be writeable.... The get*() methods of course are read only... From the documentation: ------------------------- setFieldName (index, field_name): Sets the field name into the table. setNewName (index, new_field_name): Sets the new field name into the table. setSplitRule (index, rule): Sets the split rule into the table. setVisible (index, visible): Set the visible flag of a field on the table.
... View more
09-19-2011
09:45 AM
|
0
|
0
|
4171
|
|
POST
|
Note that ESRI made great strides in v10 getting this tool to delete features faster. Prior to v10, the tool (as you note) ran quite slowly, especially for large datasets accessed via a network or SDE. I found that in v93, it was often faster to just copy the records you wanted to keep to a new FC (use the Select_analysis tool) rather than deleting the ones you wanted to get rid of. Then just delete the original and rename the Select_analysis output FC to that of the original.
... View more
09-12-2011
10:17 AM
|
0
|
0
|
2008
|
|
POST
|
Did I mention that Oracle SDE sucks? Among other things I hate about it is that it has character limits on the SQL expresions you can pass into it. FGDB is much better in this regard... This probably doesn't help you as I bet you are developing some sort of interactive tool/toolbox or something, but I learned a long while back... Step1 to any ESRI geoprocessing analysis: Copy all the data to a local hard drive (perferably in .shp or FGDB format), then proceed with the analysis (i.e. Don't use data directly from a network connection!). Here's a work around that builds a selection table in SDE #blah blah
else:
#Process: Try to select the arcs
message = "Selecting features. Please wait..."; showPyMessage()
selectionOidList = list(currentSearchOidList)
selectionOidList.sort()
gp.SelectLayerByAttribute_management(inLayer, "NEW_SELECTION", oidFieldName + " in (" + str(selectionOidList)[1:-1] + ")")
#blah blah
#blah blah
#Process: Proceed with getting the selected feature count... if data source is in SDE this can take a while!
selectedFeatureCount = int(gp.GetCount_management(inLayer).getoutput(0))
if selectedFeatureCount > 0:
message = "Selected " + str(selectedFeatureCount) + " features..."; showPyMessage()
elif sdeDataSourceFlag == True and selectedFeatureCount == 0 and len(selectionOidList) > 0:
#Process: Build an SDE look up table to handle the large selection!
message = "Building ArcSDE selection table. Please wait..."; showPyMessage()
lookupTblName = "SEL_OID_" + string.lower(os.environ.get("USERNAME")) + "_" + time.strftime('%Y%m%d%H%M%S')
gp.CreateTable_management("in_memory", lookupTblName, "", "")
gp.AddField_management("in_memory\\" + lookupTblName, "SEL_OID", "LONG")
insertRows = gp.insertcursor("in_memory\\" + lookupTblName)
for currentSearchOid in currentSearchOidList:
insertRow = insertRows.newrow()
insertRow.SEL_OID = currentSearchOid
insertRows.insertrow(insertRow)
del insertRow
del insertRows
parentWorkspace = parentFC[0:-len(parentFC.split("\\")[-1]) - 1] #if stream dataset (aka "the parent" ) is in SDE put the lut there too
lookupTblPath = parentWorkspace + "\\" + lookupTblName
gp.CopyRows_management("in_memory\\" + lookupTblName, lookupTblPath, "")
gp.Delete_management("in_memory\\" + lookupTblName, "")
gp.ChangePrivileges_management(lookupTblPath, "public", "GRANT", "GRANT")
gp.SelectLayerByAttribute_management(inLayer, "NEW_SELECTION", oidFieldName + " in (SELECT SEL_OID FROM " + lookupTblName + ")")
gp.Delete_management(lookupTblPath, "")
message = "Selected " + str(count2) + " features..."; showPyWarning()
else:
message = "ERROR: No features were selected! Exiting script..."; showPyError(); sys.exit()
del currentSearchOidList
message = "REFRESH THE ARCMAP VIEW TO DISPLAY NEWLY SELECTED FEATURES!"; showPyWarning()
#*****************GEOPROCESSING STUFF ENDS HERE******************************
#Indicates that the script is complete
message = sys.argv[0] + " is all done!"; showPyMessage()
except:
message = "Error in script! Consult log file " + logFile + " for details..."; showPyError()
message = "\n*** LAST GEOPROCESSOR MESSAGE (may not be source of the error)***"; print >> open(logFile, 'a'), str(time.ctime()) + " - " + message
print >> open(logFile, 'a'), gp.GetMessages()
message = "PYTHON TRACEBACK INFO: " + traceback.format_tb(sys.exc_info()[2])[0]; print >> open(logFile, 'a'), str(time.ctime()) + " - " + message
message = "PYTHON ERROR INFO: " + str(sys.exc_type)+ ": " + str(sys.exc_value) + "\n"; print >> open(logFile, 'a'), str(time.ctime()) + " - " + message
message = "\n*** PYTHON LOCAL VARIABLE LIST ***"; print >> open(logFile, 'a'), str(time.ctime()) + " - " + message #don't print this mess to ArcToolbox (just the logFile)!
variableCounter = 0
while variableCounter < len(locals()):
message = str(list(locals())[variableCounter]) + " = " + str(locals()[list(locals())[variableCounter]]); print >> open(logFile, 'a'), str(time.ctime()) + " - " + message #don't print this mess to ArcToolbox (just the logFile)!
variableCounter = variableCounter + 1]
... View more
09-08-2011
10:57 AM
|
0
|
0
|
4842
|
|
POST
|
If it helps, here is some Python code that among other things calculates the % overlap of a "Spruce Zone" layer with a "watershed layer" (that is, the code figures out what pct of the watershed is covered by the spruce zone layer). Parts of it a bit cryptic (cause this code snipit is running in a large loop that I didn't include), but it should help demonstarte the process. And yes, the process is probably easier if you use the the union tool... Otherwise with intersect you would not recieve back any tabular data concerning the areas that did not overlap (FID_* = -1).... And would then you wouldn't be able to make the "full-picture" overlap % summary table if you were lacking the records where ovlp% was 0 (I guess you could do some aditional steps to put those records back in... Anyway, union is probably your best bet). watershedFC = fgdbPath + "\\" + watershedLyr
arcpy.Dissolve_management(oesfWatershedsFC, watershedFC, watershedLyrDict[watershedLyr][0], "", "SINGLE_PART"); showGpMessage()
arcpy.AddField_management(watershedFC, "ACRES", "DOUBLE"); showGpMessage()
arcpy.CalculateField_management(watershedFC, "ACRES", "!shape.area@acres!", "PYTHON_9.3", ""); showGpMessage()
union1FC = "in_memory\\union1"
arcpy.Union_analysis([watershedFC, spruceZoneFC], union1FC, "ALL", "" , "GAPS"); showGpMessage()
arcpy.DeleteField_management(union1FC, "ACRES"); showGpMessage()
arcpy.AddField_management(union1FC, "ACRES", "DOUBLE"); showGpMessage()
arcpy.CalculateField_management(union1FC, "ACRES", "!shape.area@acres!", "PYTHON_9.3", ""); showGpMessage()
arcpy.MakeFeatureLayer_management(union1FC, "fl", "FID_spruce_zone <> -1"); showGpMessage()
freq1Tbl = "in_memory\\freq1"
arcpy.Frequency_analysis("fl", freq1Tbl, watershedLyrDict[watershedLyr][0], "ACRES"); showGpMessage()
arcpy.AddField_management(watershedFC, "SPRUCE_PCT", "DOUBLE"); showGpMessage()
arcpy.AddField_management(watershedFC, "SPRUCE_FLG", "DOUBLE"); showGpMessage()
arcpy.MakeFeatureLayer_management(watershedFC, "fl"); showGpMessage()
arcpy.AddJoin_management("fl", watershedLyrDict[watershedLyr][0], freq1Tbl, watershedLyrDict[watershedLyr][0], "KEEP_ALL"); showGpMessage()
arcpy.CalculateField_management("fl", "SPRUCE_PCT", "[freq1.ACRES] / [" + watershedLyr + ".ACRES]", "VB", ""); showGpMessage()
arcpy.RemoveJoin_management("fl", "freq1"); showGpMessage()
arcpy.MakeFeatureLayer_management(watershedFC, "fl", "SPRUCE_PCT < .5 OR SPRUCE_PCT IS NULL"); showGpMessage()
arcpy.CalculateField_management("fl", "SPRUCE_FLG", "-1", "PYTHON_9.3", ""); showGpMessage()
arcpy.MakeFeatureLayer_management(watershedFC, "fl", "SPRUCE_PCT >= .50"); showGpMessage()
arcpy.CalculateField_management("fl", "SPRUCE_FLG", "1", "PYTHON_9.3", ""); showGpMessage()
freq2Tbl = "in_memory\\freq2"
arcpy.Frequency_analysis(intersect1FC, freq2Tbl, watershedLyrDict[watershedLyr][0], "STRM_MILES"); showGpMessage()
arcpy.AddField_management(watershedFC, "STRM_MILES", "DOUBLE"); showGpMessage()
arcpy.MakeFeatureLayer_management(watershedFC, "fl"); showGpMessage()
arcpy.AddJoin_management("fl", watershedLyrDict[watershedLyr][0], freq2Tbl, watershedLyrDict[watershedLyr][0], "KEEP_ALL"); showGpMessage()
arcpy.CalculateField_management("fl", "STRM_MILES", "[freq2.STRM_MILES]", "VB", ""); showGpMessage()
arcpy.RemoveJoin_management("fl", "freq2"); showGpMessage()
... View more
09-08-2011
10:00 AM
|
0
|
0
|
1597
|
|
POST
|
...tuple list instead of a list list... Okay I get it. So yes a tuple could be even better - although you can't sort a tuple 😞 , and the OID field is (always?) sorted in ascending oder, so I think having the OID-based sql expresion in a sorted order would probably make it execute a bit faster. So something like: oidList = [6,4,2,6,8,1]
oidList.sort()
gp.MakeFeatureLayer_managment(fc, "fl", "OBJECTID in (" + str(oidList)[1:-1] + ")") or using a tuple: oidList = [6,4,2,6,8,1]
oidList.sort()
gp.MakeFeatureLayer_managment(fc, "fl", "OBJECTID in " + str(tuple(oidList)))
... View more
09-08-2011
09:38 AM
|
0
|
0
|
4842
|
|
POST
|
I think it needs to be formatted like this: oidList = [1,2,3,4,5,6]
gp.SelectLayerByAttribute(layername, "ADD_TO_SELECTION", "OBJECTID in (" + str(oidList)[1:-1] + ")") Instead of using the SelectLayerByAttribute_management() tool, use the MakeFeatureLayer_managment() tool gp.MakeFeatureLayer_managment(fc, "fl", "OBJECTID in (" + str(oidList)[1:-1] + ")")
gp.Clip_analysis("fl", cookieCutterFC, blah, blah) MakeFeatureLayer_managment() is a much faster way to make "selections", the drawback is that is can oly be used to make a "NEW_SELECTION", and can't be used to"ADD_TO_SELECTION", "SWITCH_SELECTION", etc. Also, FYI: You can execute SQL statments like this (composed of lists of OIDs) that are millions of characters long using FGDB format! So cool!!!
... View more
09-08-2011
08:36 AM
|
0
|
0
|
4842
|
|
POST
|
Don't know about how to "check each OLE DB status value", but some probable issues: 1. You forgot to delete the searchcursor object, and locks persit on the table (that's why you can't update it). or 2. Since your ODBC table (probably) doesn't have an OBJECTID field, the ESRI updatecursor method might not work. I know it used to be in v9.3 that your couldn't use the cursor sort parameter (in a search or update cursor) unless there was an OBJECTID field. You could always make your table drink the ESRI-brand coolaid and import it using CopyRows or TableToTable or some other tool - thus auto creating an OBJECTID field...
... View more
08-30-2011
03:35 PM
|
0
|
0
|
652
|
|
POST
|
Somethings got to be wonkey to have a sytematic offset like that... cellsize cell allignment extent projection datum Are you ABSOLUTELY sure that your base DEM is in the proj you think it is? Can you replicate the issue with another DEM dataset?
... View more
08-29-2011
02:23 PM
|
0
|
0
|
2283
|
|
POST
|
And you are sure your ArcMap dataframe doesn't have a differnt prj and/or datum defined?
... View more
08-29-2011
01:22 PM
|
0
|
0
|
2283
|
|
POST
|
My only guess is that some of your input datasets have different extents for some reason. In your attached image a few posts bac, there is a green pixel in the mid-right hand side on the image that appears to be "displaced" (like you said). What dataset does this offset green pixel represent?
... View more
08-29-2011
12:59 PM
|
0
|
0
|
2283
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 03-25-2014 12:57 PM | |
| 1 | 08-29-2024 08:23 AM | |
| 1 | 08-29-2024 08:21 AM | |
| 1 | 02-13-2012 09:06 AM | |
| 2 | 10-05-2010 07:50 PM |
| Online Status |
Offline
|
| Date Last Visited |
08-30-2024
12:25 AM
|