2

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
6
  • 4
    Are you using the da.InsertCursor? – ianbroad Jul 28 '15 at 21:10
  • 1
    Whoops, nope! d'uh. Of course. Thanks for the second set of eyes. – Emil Brundage Jul 28 '15 at 21:12
  • 1
    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. – Michael Stimson Jul 28 '15 at 22:16
  • 1
    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. – PolyGeo Jul 28 '15 at 22:35
  • Yes, just needed the da. – Emil Brundage Jul 28 '15 at 22:35
2

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.

6
  • 4
    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. – mr.adam Jul 29 '15 at 0:12
  • 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. – Emil Brundage Jul 29 '15 at 0:16
  • 1
    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). – mr.adam Jul 29 '15 at 0:22
  • 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. – Emil Brundage Jul 29 '15 at 0:36
  • 3
    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. – Michael Stimson Jul 29 '15 at 0:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.