|
POST
|
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
08-09-2010
09:36 AM
|
0
|
0
|
622
|
|
POST
|
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
08-05-2010
03:53 PM
|
0
|
0
|
3712
|
|
POST
|
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
08-05-2010
11:34 AM
|
0
|
0
|
1104
|
|
POST
|
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
08-04-2010
03:44 PM
|
0
|
0
|
1716
|
|
POST
|
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
08-04-2010
02:45 PM
|
0
|
0
|
1716
|
|
POST
|
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
08-04-2010
02:39 PM
|
0
|
0
|
1716
|
|
POST
|
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
08-04-2010
01:48 PM
|
0
|
0
|
1716
|
|
POST
|
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
08-04-2010
01:41 PM
|
0
|
0
|
1716
|
|
POST
|
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
08-04-2010
01:05 PM
|
0
|
0
|
1716
|
|
POST
|
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
08-04-2010
12:40 PM
|
0
|
0
|
1081
|
|
POST
|
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
08-04-2010
09:25 AM
|
0
|
0
|
1763
|
|
POST
|
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
08-04-2010
08:53 AM
|
0
|
0
|
1081
|
|
POST
|
I have been noticing that when you apply a code tag in the forums, sometimes random spaces are introduced in the taged code. I don't think this is user error, since I have seen it more than a few times. For example the post here: http://forums.arcgis.com/threads/9559-Python-if-...-then-Statement conatains: Contours = "\\\\Atlas\\data\\geodata\\state\\contour\\arc " Crossings = "\\\\Atlas\\data\\geodata\\state\\crossings\\a rc" Contour = "Contour.shp" Crossing = "Crossing.shp" P_L = "C:\\Daves_Stuff\\ArcPad_Data\\Standard_Layers\\La mberts_Projection\\Pts_Lines" Clip_Feature = "C:\\Daves_Stuff\\ArcPad_Data\\Standard_Layers\\Clip_Feature\\Clip_Feature.shp" I have noticed this weird placement of random spaces in the code tags of several other posts as well, for example: http://forums.arcgis.com/threads/9512-Rectangle-for-Clip_management-tool-in-arcpy Code with random spaces introduced to it is lame... P.S. Funny thing I noticed is that when composing this message, the last line of the Python code above contained no spaces, but when I preview it, there is a space in "Cl ip". This space wasn't there when I composed the message - see the attached screen shot image for proof. Seems like it's not just tagged code that is affected? Perhaps this is another sympom of using IE8?
... View more
08-04-2010
08:48 AM
|
0
|
3
|
4582
|
|
POST
|
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
08-04-2010
08:03 AM
|
0
|
0
|
1693
|
|
POST
|
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
08-03-2010
02:33 PM
|
0
|
0
|
1693
|
| Title | Kudos | Posted |
|---|---|---|
| 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 | |
| 1 | 02-08-2012 03:09 PM |
| Online Status |
Offline
|
| Date Last Visited |
08-30-2024
12:25 AM
|