Latest Contributions by ChrisSnyder

bartekent - I think you are confusing a feature layer and and a layer file (.lyr file), which are two different things. The Solve_na tool returns a feature layer, which is a fancy in-memory reference to a featureclass. A feature layer's spatial/attribute data is not necessarily stored in memory, it's refernce toa feature class is just "abstracted" in memory. By saving a layer file as a .lyr file, you are in effect writing the in memory "reference" information to a file. This includes things like SQL queries, symbols, etc. Anyway, like ksshannon says, just use the CopyFeatures tool (or another tool) to copy the feature layer to a feature class stored on disk. For example: arcpy.AddLocations_na("cfl", "Polygon Barriers", dnrHaulBarrierPolysFC, "", "", "", "", "", "", "", "", "", ""); showGpMessage() arcpy.AddLocations_na("cfl", "Facilities", haulDestinationPntsFC, "", "", "", "", "", "", "", "", "", ""); showGpMessage() arcpy.AddLocations_na("cfl", "Incidents", actDislvPntsFC, "", "", "", "", "", "", "", "", "EXCLUDE", ""); showGpMessage() arcpy.Solve_na("cfl", "SKIP", "CONTINUE"); showGpMessage() dnrHaulRoutesFC = fgdbPath + "\\dnr_haul_routes_least_time" arcpy.env.outputMFlag = "DISABLED" arcpy.CopyFeatures_management("cfl\\Routes", dnrHaulRoutesFC); showGpMessage() ... View more

Ouch... Can't hide from the numbers. FYI: A lot of the ESRI geoprocessing tools exhibit this behavior (consistently longer run times) when run in a loop. It used to be FAR worse, and to their credit, ESRI has made great strides in correcting/minimizing the issue. http://forums.esri.com/Thread.asp?c=93&f=1729&t=177007 http://forums.esri.com/Thread.asp?c=93&f=1729&t=175721 http://forums.arcgis.com/threads/8866-Spatial-Join-CRASHING-at-10 The gp "memory leak" might not be the underlying issue here though... ... View more

Maybe you could pre-build a FGDB FC (maybe several differnt schemas depending on the data needs), and the script could then just copy and populate the template(s)? ... View more

Okay - your're right, FGDB are slow... I don't have ogr installed... So no OGR times... Creating feature classes... Feature classes created. GDB time: 23.3795888001(0.935183552003 sec per call) SHP time: 0.984445672708(0.0393778269083 sec per call) MEM time: 0.992119302926(0.039684772117 sec per call) Deleting feature classes... Feature classes deleted. AddField is on shp is 23.7489883375 times faster than on gdb Go shapefiles!!! How about doing all the field adding and calcing using in_memory, and then copy top FGDB? I use this method quite a bit for the added speed in calcing and dropping fields. I never paid that much atention to how long it took to add the field in a FGBD, but yep, it is pretty slow relative to the competition. ... View more

This was run out of the arcmap environment That might be the issue... What if you run it via PythonWin (or some other IDE)? I remeber a while back someone had determined that the ArcMap Python window interface (for whatever reason), perfomed quite a bit slower than other IDE's when running a searchcursor (I think that was what it was). I can't seem to find that post... Anyway. I run my stuff almost exclusivly in Pythonwin, and AddField for a FGDB has pretty good perfomance. ... View more

So my point is that the particular FGDB that you are using (C:\Users\\kshannon\Documents\ArcGIS\Default.gdb) is a new and evil ESRI invention in v10.0. By "default" all the geoprocessing tools write their results to this specific FGDB. My point is that there is a large potential for this specific FGDB and the data within it to become quite fragmented over time - the more fragmented it gets, the slower the perfomance becomes (like adding fields to a table stored there). If performance is important, I would recomend not using the Deafult.gdb. When you say "I am using a brand new geodatabase each time", is it that you are deleting and recreating the Default.gdb everytime (which would certaily take a while)? What functionality offered in a FGDB precludes using an in_memory featureclass? An interesting feature of an in_memory table is that field add and deletes are virtually instantanious, which contrasts with a FGDB. Depending on the number of records, field deletes in a FGDB can take a very long time. Field adds however, in a "fresh" FGDB should take less than a second even when the table has a lot of records. ... View more

Could it be that there is something different/special about Default.gdb? If you copy your table or feature class to a brand new FGDB, does it still take a long time? What if you run a Compact on Default.gdb? It is probably a bad practice (performace-wise) to use Default.gdb, as there is a lot of opportunity for it to get quite fragmented. ... View more

Didn't test it, but this code should "blank-ify" any NULL text fields: #One way... txtFieldList = arcpy.ListFields(myFC, "", "STRING") updateRows = arcpy.UpdateCursor(myFC) for updateRow in updateRows:    for txtField in txtFieldList:       if updateRow.isNull(txtField.name):          updateRow.setValue(txtField.name, '')    updateRows.updateRow(updateRow) del updateRow, updateRows #Another way that might? be faster/better: txtFieldList = arcpy.ListFields(myFC, "", "STRING") for txtField in txtFieldList:    updateRows = arcpy.UpdateCursor(myFC, txtField.name + " IS NULL", "", txtField.name)    for updateRow in updateRows:       updateRow.setValue(txtField.name, '')       updateRows.updateRow(updateRow) del updateRow, updateRows ... View more

A good read... ... View more

"other approaches that may be more realistic" Nothing out of the box comes to mind... Although there are lots of tantalizing possibilities that would require programming and a lot of R&D... I've been messing around with Network Analyst quite a bit lately. What if you had a "Network" of lines that connected all the adjacent cell centers (or maybe all the cell centers within a certain radius). And your birds used Network analyst to find the optimum route to their food spot? Kick out the routes that cross land. Graph theory type stuff. ... View more

I reproduced your analysis and ended up with a similar result... a less than optimal "shortest path" to the destination cells. In the defense of the ESRI algorithm, "shortest path" is sort of relative in a raster environment. For example, when traveling diagonaly, you are forced traverse from cell to cell in an often "stairstep" sort of path instead of a more logical straight line like an actual animal might travel along. Some other GIS programs (IDRISI) make use of hexagonal cells, which helps to minimize the problem I think. ... View more

Having submitted quite a few bugs to ESRI over the years, I am frankly a bit... jaded... and am now reluctant to submit every little issue I find (of which there are many). However, if I can't find a good work around to an issue, I will still take the time to submit a formal bug fix and repro case... In this case though, I have a good work around (keep scratch raster in GRID format). I did try to post my dataset to this thread, but it is too large (1.9 MB zipped)... A clue that helps: I can repoduce the error with my original dataset that is 8287 cols x 12513 (~30,000 unique values)rows, but when I try to repro with a smaller dataset (4913 cols x 7165 rows and 18,000 unique values - which I created in order to make some repro data small enough to post to the forum), the output result is correct (i.e. I can't reproduce the issue with the smaller dataset). Like Pavan from ESRI said, it seem to only affect "fairly large" datasets. ... View more

Harsh at first perhaps.... Once you understand her though, she is a real gem 😉 ... View more

To add to this issue, in v10.0 SP3, I found that Eulcidean Allocation also suffers from the same sort of buggy behavior as RegionGroup (weird linear artifacts) when the euclidean allocation output grid is placed in FGDB format. When run entirely using grid format, the output is correct. In my Python code I was able to rectify the problem very simply: By changing the arcpy.env.Workspace variable to a folder (thus forcing the Grid format) instead of using my FGDB as the workspace. Somewhat related, I find it a bit frustrating in the new v10.0 map algebra that you cannot seem to force the "temp" output rasters to be a particular name, and have to rely on the .save method to, in effect, rename it. I wish you could do this: r"C:\Temp\euc_aloc" = arcpy.sa.EucAllocation(roadGrd, "", "", "", "VALUE", "", "") But it seems you have to do this: arcpy.env.workspace = r"C:\Temp" junk = arcpy.sa.EucAllocation(roadGrd, "", "", "", "VALUE", "", "") eucAlocGrd = r"C:\Temp\euc_aloc" junk.save(eucAlocGrd) If I do this, the euclidean allocation output (in FGDB format) gets wonkey: arcpy.env.workspace = r"C:\Temp\test.gdb" junk = arcpy.sa.EucAllocation(roadGrd, "", "", "", "VALUE", "", "") eucAlocGrd = r"C:\Temp\test.gdb\euc_aloc" junk.save(eucAlocGrd) #roadGrd is in Grid format BTW... ... View more

getvalue() is for retreiving values when the field name is stored as a variable. In your case, you don't need it, since you already know the field name. Since there is only a single record in the tables, how about: strlen = gp.SearchCursor(streamtable,"", "","","").next().SUM_LENGTH artlen = gp.SearchCursor(Arttable,"", "","","").next().SUM_LENGTH index = artlen / float(strlen) print index del strlen, artlen ... View more