Latest Contributions by ChrisSnyder

Use a shapefile. Contrary to popular belief, the ESRI formats in order of (in general) best to worst performance: 1. Shapefile 2. FGDB 3. PGDB Also, if you are attempting to store a raster in a geodatabase and are wanting to do actual analysis, stop right now! Put it in Grid format, and I guarantee you better performance. ... View more

Hasn't this always been like this though? Even in v9.3 if you manually create a square having coordinate pairs of: 0,0 0,2 2,2 2,0 It reports the centroid as being: 1.000061, 1.000061 and the area as: 4.000488 and the perimeter as: 8.000488 Could be wrong here, but I was led to believe what Bill hinted at: ESRI's data models store/process coordinates as integers rather that double precision floats (seemingly to save space and speed processing). Seems like the larger the feature (relative distances) that, at least in v9.3, things become more "precise". For example, if you make a larger square of: 0,0 0,100000 100000,100000 100000,0 the centroid is now "exactly": 50000, 50000 and the area: 10000000000 ... View more

Damn! I found that while it appears that you can load a geometry object straight into a dictionary it gets corupted somehow in the process!!! The tabular data however is perfect. I am guessing it has something to do with the stupid geometry object being incompatible with the dictionary. If you really need the geometry in the dictionary, you could just loop through all thr coordinate pairs in the searchcursor and add them to the dictionary as raw values rather than the stupid ESRI geometry thing. But that makes things more complicated. Oh well - maybe in v10 since things seem more Pythonic (although I suspect it's just a wrapper of some sort)... Tables are easy at least. Rich you could handle a multi-dimential array via Python in several ways (embedded lists or a dictionary). Python doesn't really have an "array" like VB, but I think Python array-type objects are better: listObj = [["ORIG_NAME1","NEW_NAME1"],["ORIG_NAME2","NEW_NAME2]] #print the original and name of the 2nd field print str(listObj[1][0]) + ", " + str(listObj[1][1]) ORIG_NAME2, NEW_NAME2 #or my favorite, a dictionary keyed from the original name: >>> dictionaryObj = {"ORIG_NAME1":["NEW_NAME1", "String"],"ORIG_NAME2":["NEW_NAME2","DOUBLE"]} >>> str(print dictionaryObj["ORIG_NAME2"][0]) + ", " + str(print dictionaryObj["ORIG_NAME2"][1]) NEW_NAME2, DOUBLE ... View more

Rich, you will like this: import arcgisscripting gp = arcgisscripting.create(9.3) fc = r"D:\csny490\oesf_nso_models_20100623\landscape_model\results\results_bu.gdb\summary_results" fieldList = gp.listfields(fc) fieldIndex = 0 fieldNameDict = {} for field in fieldList:     fieldNameDict[field.name] = fieldIndex     fieldIndex = fieldIndex + 1 fcDictionary = {} oidFieldName = gp.describe(fc).oidfieldname searchRows = gp.searchcursor(fc) searchRow = searchRows.next() while searchRow:     recordReadCount = 0     oidFieldValue = searchRow.getvalue(oidFieldName)     fcDictionary[oidFieldValue] = []     for field in fieldList:         fcDictionary[oidFieldValue].append(searchRow.getvalue(field.name))     searchRow = searchRows.next() del searchRow del searchRows #Now that it's in the memory, fetch the habitat density field value of OID = 31 and its width... fcDictionary[31][fieldNameDict["HAB_DENSITY"]] + " - " + str(fcDictionary[31][fieldNameDict["Shape"]].extent.width) + " feet wide!" ... View more

Holy crap! Rich, you got me thinking here and check this out. I had no idea you could do this (load the geometry object ito a dictionary so easily). Not sure how to use it, but that so damn cool!!! basically this way you could store an entire FC as a Python dictionary! Wow! dict = {} >>> searchRows = gp.searchcursor(fc) >>> searchRow = searchRows.next() >>> dict[0] = searchRow.Shape >>> dict {0: <geoprocessing describe geometry object object at 0x00C1AAE8>} >>> del searchRow >>> del searchRows >>> dict[0].getpart(0) <geoprocessing array object object at 0x00C1A890> >>> dict[0].getpart(0).next().x 820175.92491082847 >>> ... View more

However, for truly embedded cursor routines that have to look up records against each other or walk through a sorted pair of cursors (using multi-field keys especially), the primary hit is from maintaining the secondary query synchronization on unsorted records or records that are only sorted in memory. This is a great description of the case where the dictionary structure is so fast/usefull! ... View more

Jinx posting. Look at my post right above yours concerning dictionaries. This is all great stuff - I'm a hack self-taught programmer, so it's great to get someone else's suggestions, tips, tricks, etc. ... View more

Wow that's good info! So I do know of a way to get the field's index via Python, but it's slow and hokey, and you have to use a featurelayer or tableview as input. For example: gp.makefeaturelayer(fc,"fl") print gp.describe("fl").fieldinfo.findfieldbyname("TER_ID") 6 #that is to say TER_ID is the 7th field, 0 being the 1st. However, I don't think there is a way to retrieve a field value in a cursor using it's index value. Maybe I'm wrong though... Seems that would be a major performance enhancement like you said. I have mostly shied away from embedded cursors (current script being an exception) since they tend to be slow. One thing I have used a lot (and that could be useful here if the table wasn't too huge and you didn't care to transfer the geometry) is using a Python Dictionary object to emulate a table structure in memory. Once you have loaded a table into a dictionary (using a searchcursor) it is EXTREEMLY fast to access the field values. This is especially useful to when you have a need to constantly look up lots and lots of unordered values. For example, I wrote a script that performs traces of a stream network (created using the hydrology tools). The idea is that every arc is flowing downhill, so has a startnode that is upstream of the endnode. The basic approach I took was to load the OIDs and their start/end nodes into a dictionary. Then (if tracing downstream) I basically traverse the items in the dictionary, looking up the arcs end node, searching for an arc that has its startnode == the last end node and so on. See: http://forums.esri.com/thread.asp?t=275202&f=1729&c=93#948148 for the code. A simple dictionary example: lookupDict = {} searchRows = gp.searchcursor(lookupTbl) searchRow = searchRows.next() while searchRow:    lookupDict[searchRow.LOOKUPITEM] = [searchRow.FIELDVALUE1,searchRow.FIELDVALUE2]    searchRow = searchRows.next() del searchRow del searchRows updateRows = gp.updatecursor(tableToUpdateTbl) updateRow = updateRows.next() while updateRow:    updateRow.MEAN = (lookupDict[updateRow.LOOKUPITEM][0] + lookupDict[updateRow.LOOKUPITEM][1]) / 2    updateRows.UpdateRow(updateRow)    updateRow = updateRows.next() del updateRow del updateRows del lookupDict ... View more

Rich, You are totally correct! Great observation... I thought it seemed like when I was testing this stuff yesterday it was running a bit slow when I used the ORIG_OID option... Another idea to structure it would be to append the ORIG_OID field (if the user provides it) to the inputLayerFieldList, and then have a condition in the loop that says if inputLayerField == originalOidFieldName, then attempt to write it. ... View more

Jim, That test looks fine to me (no random spaces). Seems like the issue is when users paste text into the message body. My assertion that it was the code tag was wrong. Must be a dyslexic day toady... ... View more

Sounds like the classic gp memory leak issue... Unless ESRI fixes it, only workaround is to break up the process into pieces using os.spwanv, subprocess, etc. ... View more

Woops, I guess it's not the tagged code at all, just the raw text that is affected. Anyway, it's weird that there are spaces! Maybe something to do with the line wrapping? ... View more

Great - thanks for the error checking part - I will add that to my version. The part where the OIDs get populated: The deal is that you can't populate some fields in a fc/table like OID, Length, Area, etc. That is what the "try" is for: Loop through the fieldList, and for each field, try to populate that field (but we can't for OID, Shape, etc). However, we can popualte the ORIG_OID field (whataver its called) and other fields since they are writable. I have some other logic in there for dealing with the 10 character limitation for .dbf/.shp files, and there probably is a better way to organize that, but... Also some logic for dealing with the ORIG_OID field if the user provided a field name, otherwise don't populate it (since we never added it in the 1st place). Hope that helps... ... View more

Rich, I will post an update to acrscripts in the next few days. So as I understand, the requirements are: 1. The user can select up to four fields to sort. 2. The user can specify a new field name that will contain the original OID prior to sorting. Sound Good? ... View more