Latest Contributions by KimOllivier

Don't need next() ? Yes you do, in anything but a SearchCursor because you need access to a row object. How would you do cur.insert(row) and cur.update(row) ? If your 9.3 script is working, why bother rewriting it? The arcgisscripting module is still there and it works just fine. Maybe write new scripts using arcpy, and leave the rest alone. ... View more

First you must get the correct version of GDAL for Python 2.5 Then the install notes tell you to add the directory to the search path PATH in Windows. You cannot add path names using import. Here is the download page and instructions http://pypi.python.org/pypi/GDAL/ ... View more

It seems that geometry objects are not being properly returned from the cursor. If you create a geometry object and populate a geometry list then the comparison can work. In my test of 4 lines, 2 and 3 cross and 1 and 4 have a shared end. Only crosses() produced a True. A geometry list is not ideal because there are no attributes, but it should be a clue for your problem. # different method import arcpy g = arcpy.Geometry() g1 = arcpy.Geometry() g2 = arcpy.Geometry() gList = arcpy.CopyFeatures_management("c:/data/sample.gdb/exlin", g) g1 = gList g2 = gList n=0 for f1 in g1:     n+=1     m=0     print     for f2 in g2:         m+=1         print n,m,f1.overlaps(f2),f2.crosses(f1) 1 1 False False 1 2 False False 1 3 False False 1 4 False False 2 1 False False 2 2 False False 2 3 False True 2 4 False False 3 1 False False 3 2 False True 3 3 False False 3 4 False False 4 1 False False 4 2 False False 4 3 False False 4 4 False False I don't particularly like this idea, it seems to be reinventing GIS in Python scripts. Would it not be better to use topology if you have a large dataset? ... View more

@csny490 I believe that the benevolent dictator for life is recommending that you not use the string module. You can now use the string methods to accomplish most of what I believe you are trying to do, for instance I could not find any reference or discussion in the PEP's suggesting the string module will be deprecated. I did see an uninformed speculation in the year 2000 at version 1.5 thinking that it may happen after string functions were built-in. It is still there in 3.0, stonger than ever with the new string Template functions. http://docs.python.org/py3k/library/stdtypes.html#string-methods Since looking up the help I did find a better string function than string.capwords(<name>) called <name>.title() which does the same thing as capwords, but defines words as contiguous letters, so apostrophies and dashes are also counted as word boundaries (unlike capwords). This avoids using  regular expressions. The help does give an elegant example to handle special case exceptions using a generalised regular expression. Therefore my one-liner can be even simpler and now handles name punctuation as is required for some strings such as roadnames. No need to import the string module even. gp.CalculateField_management(fc,"name","!name!.title()","PYTHON") Note that I do not have to handle variable numbers of words in the string, and there is no need to define a function in a block. At Version 10 you can use Python expressions in the interactive field calculator to replace VB expressions so this would be very easy. You will have to expand your comments regarding  returning entire strings, I don't want the strings returned and they are not, they are written directly into the featureclass if you use CalculateField. "Letting the geoprocessor interpret code"? I have no idea what you are getting at. ... View more

Seeing a geoprocessing tool inside a cursor always gives me the shivers. This looks like reinventing GIS in a Python script with an unnecessary loop. Maybe like emptying the ocean with a thimble. It surely will be very very slow calling union for a thousand separate features, and I have trouble understanding the need to do this. ArcGIS is a geo-relational system, at least it was before ArcObjects. The mindset is to find a tool that processes the whole dataset with an implied loop over the whole featureclass. Try to think of a problem in the same way as an SQL query. You don't usually open a cursor there. If the sources are suitably tagged, then a union between the two featureclasses will do all the unions in one step without a cursor. ... View more

I can see that you are not working through the quote characters in a logical way. You cannot hide the double quote string in the middle of a double quoted string with single quotes. You have to use the wonderful escape character (\). So your calculate expression must be like this: gp.CalculateField_management(fc + "\\Parcels.shp", "!SIT_FULL_S!.replace('\"','')", "PYTHON", "") Just visually "unpack" the string to see what is happening. Even better make a separate expression string and print it out to see if you get what is expected. expression = "!SIT_FULL_S!.replace('\"','')" print expression gp.CalculateField_management(fc + "\\Parcels.shp", expression, "PYTHON", "") the expression without the backslash would be: "!SIT_FULL_S!.replace('" ...followed by a syntax error:  ',")" - an unclosed single quote which you don't find because CalculateField does not run TabNanny before it attempts to run it. So it does not compile and "doesn't work". Actually this is picked up by TabNanny. I recommend that you use it in Pythonwin to trap this sort of syntax error. It is the little tick icon. This is why it is not a good idea to be sucked into using CalculateField instead of a cursor. Use a cursor in scripts. Leave CalculateField for Modelbuilder. With a cursor you can pre-check the syntax with TabNanny (I hope you always do that!), you can expand out the steps to make it clearer, you can test for unexpected data and correct it, and you can add a try/except block to trap more unexpected errors without stopping the whole process. you can print out current variables when it crashes to see what the faulty data was. ... View more

Someone else just asked me the same thing. How about this one-liner? gp.CalculateField_management(fc,"name","string.capwords(!name!)","PYTHON","import string") (You have to import the string module because it's not a built-in string function.) There may be other exceptions such as dashes and apostropies that need Uppercasing such as O'Brien or other Double-Banger names. In this case use a cursor and regular expression import arcgisscripting import string import re gp = arcgisscripting.create(9.3) # settings fc = "d:/work/test.gdb/trail" # simple way but inadequate gp.CalculateField_management(fc,"name","string.capwords(!name!)","PYTHON","import string") print gp.GetMessages() # Handle imbedded quotes like O'Brien quoteabbrev = re.compile("'[a-z]") # just as fast as a calculate and we can trap exceptions, errors cur = gp.UpdateCursor(fc) row = cur.next() while row:     x = string.capwords(row.name)     if quoteabbrev.search(x):         print x,name         name = quoteabbrev.sub(quoteabbrev.search(x).group(0).upper(),x)     cur.updateRow(row)     row = cur.next() del row,cur print gp.GetMessages() I never got the VB equivalent ProperCase to work in a script. ... View more

I got exactly the opposite result. I ran the example on my laptop, Windows 7, ArcGIS 10 SP1, Intel Core I5. Running from Pythonwin: Total 0.751 (Units??) Elapsed time 00:00:02.999500 ie 3 seconds Running from ArcMap as a tool, foreground,in process: Total 0.913 Elapsed time  0:00:00.95100 ie less than 1 second Turning off foreground process Total 0.335 Turning off inprocess Total 0.338 Just for fun I pasted it into the interactive Python window: Total 10.395 Elapsed time 10.434 seconds This seems to be because each command was executed separately with the result log echoed to the window It will make a big difference if you run the script out of process. ... View more

It just means that you have to use Python to load the XY.txt table to a geodatabase table first. There are plenty of tools for that such as the CSV module. There are plenty of other issues with Windows XY events when trying to write it out to a featureclass. ... View more

It must be the different default environment settings. We need more detail of your setup to guess the issues. Where are you creating the featureclass? SDE, versioning, local geodatabase? Have you set your scratch workspace too? These will all have defaults when you add a tool What version and service pack? Why can't you use a template? ... View more

I finally reproduced your errors, and some more using your data. There seems to be something about data in proper metric units that works ok but not US Feet 😉 So I thought that it must be a data corruption. I have not found a fault that would explain that, and now after fiddling around have ended up with some similar results. I think the fundamental problem is similar to one I hit on another project where the shape object is only referenced in memory when it is extracted with a cursor. Later when we try to access it, there are no methods because it is not a proper Python object. Try doing a dir(shape). If it was a compliant Python object it would return all the methods listed on the Geometry object. Even with interactive mode you cannot do any useful request on a shape retrieved from the dictionary, you get a crash, even when editing a script and invoking a method. It only works while in the cursor. The only solution at 9.3 is to extract out all the vertices into an object that Python can use, like a string based GeoJSON dictionary! (At 10 this is practical because there is a function to convert a shape to a GeoJSON string.) See Bruce Harold's example trying to comprehensively detect the changes between two feature datasets on the Resource Centre. Although the script is in 10 format, the same applies at 9.3. My shortcut solution for a difference machine was to test the perimeter, length or centroid instead of every vertex because if even one changes it will affect these values. Can you save gp.Geometry objects in a dictionary? It appears to be intended at 10, but I know there were issues at 9.3. So I don't think that there is much point in proceeding with more testing at 9.3. ... View more

The code example worked for me. I could not get it to fail on a complex polygon featureclass such as the pine forest landcover for a small country. I changed the test to a random shape and printed all vertices and handled possible donuts. I did not compare the vertices with a normal cursor, but they look plausible. There are a few more convenient touches at 10 for iterating over parts and of course the spatial operators but otherwise its the same for 9.3 or 10. The featurecount is 47,713 and the script took 14 seconds. THIS CODE LOADS A FC INTO A PYTHON DICTIONARY IN RAM # http://forums.arcgis.com/threads/17956-Using-centroid-geometry-to-get-values-of-intersecting-feature#post60607 # edits by Kimo import arcgisscripting, sys import random,datetime,pprint start = datetime.datetime.now() gp = arcgisscripting.create(9.3) #THE INPUT FC fc = "d:/workspace/datetest.gdb/pineforest" #Process: Build a field list and a mini dictionary to look up the field order (aka index) given a field name fieldList = gp.listfields(fc) fieldIndex = 0 fieldNameDict = {} for field in fieldList:     fieldNameDict[field.name] = fieldIndex     fieldIndex = fieldIndex + 1 shapeFieldName = gp.Describe(fc).shapeFieldName #  fix missing definition pprint.pprint(fieldNameDict) #Process: Load the fc into a dictionary fcDictionary = {} oidFieldName = gp.describe(fc).oidfieldname searchRows = gp.searchcursor(fc) searchRow = searchRows.next() while searchRow:     oidFieldValue = searchRow.getvalue(oidFieldName)     fcDictionary[oidFieldValue] = []     for field in fieldList:         fcDictionary[oidFieldValue].append(searchRow.getvalue(field.name))     searchRow = searchRows.next() del searchRow,searchRows print print "Size of dictionary",len(fcDictionary) for sample in range(10):     print     idx = random.randint(0,len(fcDictionary))     #Print the values     print fcDictionary[idx]     #Print a name field value     print fcDictionary[idx][fieldNameDict["LCDB1NAME"]]     #Print the extent rectangle     print fcDictionary[idx][fieldNameDict[shapeFieldName]].extent     #Print ALL the coordinate pairs including parts and interior rings     shapeObj = fcDictionary[idx][fieldNameDict[shapeFieldName]]     for p in range(shapeObj.partCount):         part = shapeObj.getPart(p)         pnt = part.next()         while pnt:             print p,pnt.X,pnt.Y             pnt = part.next()             if not pnt:                 pnt = part.next()                 if pnt:                     interiorRing = True                     print "Hole" print "Completed",datetime.datetime.now() - start [12139, <geoprocessing describe geometry object object at 0x16A388D8>, 66.0, u'Pine Forest - Closed Canopy', 66.0, u'Pine Forest - Closed Canopy', u'no', 64.70760971, 182.0, u'Rodney District', 16.0, u'Auckland Region', 11067.655349413637, 646803.66190707707] Pine Forest - Closed Canopy 1811685.23719998 5594544.72269999 1811781.95419998 5594599.59829999 NaN NaN NaN NaN 0 1811685.2372 5594544.9228 0 1811688.5206 5594544.9241 0 1811733.3278 5594561.747 0 1811781.9542 5594599.5983 0 1811780.0872 5594596.3042 0 1811757.3881 5594569.9774 0 1811726.5661 5594549.7439 0 1811689.9306 5594544.7227 0 1811685.2372 5594544.9228 Completed 0:00:14 ... View more

But is it corrupted? This works for me: # create a dictionary of centroids sr = gp.Describe(fcAU).SpatialReference cur = gp.SearchCursor(fcAU,"land = 1") row = cur.next() dAU = {} pt = gp.CreateObject("Point") while row:     pt = row.shape.centroid     au = row.AU_NO     dAU[au] = pt     row = cur.next() del row,cur print "OD records",len(dAU) ... View more

E00 files are ASCII dumps of a coverage. You have to use a special tool to import them that requires an ArcInfo licence. Coverage Tools>Conversion>To Coverage>Import From Interchange File But this will load into a coverage which needs a second export to a geodatabase ArcView 3.x has a simple standalone import utility too. Or use any open source tool. They load them without fuss into shape files. ... View more

If you don't need measures then make sure that they are disabled, or drop them. Sometimes the range of valid measures also defaults to much smaller than you might have by default. When you define new featureclasses in 'high precision' then always define a projection to let ArcGIS calculate suitable limits for xy and m values. Have a look at your coordinate system extents to see if they are unexpectedly small. ... View more