InsertCursor fails when trying to insert XY point data

Question

I have a text file with X and Y coordinates, as well as a third piece of information. I'm trying to create a point feature class from this text file by use of an insert cursor. I'm working with "SHAPE@XY" token, but can't figure out the exact syntax. What am I doing wrong?

Pertinent code:

#Open text file
textFile = open (inFile, "r")
#Get X, Y, and PGA
lines = [r.split (" ")[0:3] for r in textFile]
#Spatial reference
SR = SpatialReference ("WGS 1984")
#Create point feature class
CreateFeatureclass_management (outPath, outName, "POINT", spatial_reference = SR)
#Add PGA field
AddField_management (outFc, "PGA", "FLOAT")
#Create insert cursor object
cursor = InsertCursor (outFc, ["SHAPE@XY", "PGA"])
for X, Y, PGA in lines:
 #XY tuple
 XY = (float(X), float(Y))
 #Create row tuple
 row = (XY, float(PGA))
 print row
 #Insert row
 cursor.insertRow (row)

The first line prints as I would expect:

((-123.224, 38.4105), 0.02)

But the next line throws the following error:

Traceback (most recent call last):
 File "C:/Users/e1b8/Desktop/E1B8/DASH_GIS_Integration/Calculate_PGA_per_plat_Point.py", line 277, in textToFeatureClass
 cursor.insertRow (row)
 File "C:\Program Files (x86)\ArcGIS\Desktop10.1\arcpy\arcpy\arcobjects\arcobjects.py", line 106, in insertRow
 return convertArcObjectToPythonObject(self._arc_object.InsertRow(*gp_fixargs(args)))
RuntimeError: Error in InsertRow

Three sample lines from the text file:

-123.2240 38.4105 0.02 0.01 1
-123.2157 38.4105 0.02 0.01 1
-123.2073 38.4105 0.02 0.01 1

• ianbroad: Are you using the da.InsertCursor?
• Emil Brundage: Whoops, nope! d'uh. Of course. Thanks for the second set of eyes.
• Michael Stimson: I suggest with arcpy.da.InsertCursor (outFc, ["SHAPE@XY", "PGA"]) as cursor: to automatically clean up the resources and release locks. The examples I've seen use lists instead of tuples for the geometry; I talked with PolyGeo recently and it seems that either can be used in this case... is your problem fixed? I like the way you've split and iterated this text file, +1 just for that.
• PolyGeo: Well spotted @ian, it reminds me why I think any import used should always be included in code snippets presented here, and why I rarely use the "variant of the import statement that imports names from a module directly into the importing module’s symbol table." (docs.python.org/2/tutorial/modules.html). I think just using import arcpy makes code more readable and easy to debug.
• Emil Brundage: Yes, just needed the da.

Answer 1

Since I used from arcpy import * (not shown), the line:

cursor = InsertCursor (outFc, ["SHAPE@XY", "PGA"])

...was calling the older version of InsertCursor.

The proper code is:

cursor = da.InsertCursor (outFc, ["SHAPE@XY", "PGA"])

This line calls the data access InsertCursor.

• mr.adam: This is a perfect example of why using from module import * syntax is roundly discouraged in Python. Just too many potential issues, not worth the bit of typing that it saves... look here, here, and even here from 1999.
• Emil Brundage: I find it suits my simple needs quite well and have had problems with import * next to never. I deal with 3 or 4 modules at most at any given time. This was a rare hiccup, and quite minor. I could have easily made the same mistake if I had instead used import arcpy.
• mr.adam: I know what you mean, and don't dispute your circumstances. For my own use, there have been so many little standards of practice that didn't seem necessary at first but later turned out to be very good habits to have formed (or not formed as the case may be).
• Emil Brundage: I think the "best practices" argument is a good one. Until I start experiencing negative consequences from the shortcut though I'm sure I'll continue to keep it up.
• Michael Stimson: Emil, at that stage you could be in for a lot of fixing. If a method exists in two (or more) libs the interpreter can get confused as to which one you want; your code works, of that I have no doubt, but say you come back later to add a new function only to find the new import introduces an error as it can tell lib1.foo from lib2.foo when you say foo(arg,arg2), I have encountered this in C# using Esri and GDAL - both have a Dataset object, I had to change the using (import) and specify both fully when I added the new lib. I'm not saying you're doing it wrong, just consider the future.