3

I have a directory full of .CSVs representing point data. I run this code on them:

#define output feature class path
outFC2016 = os.path.join(r"...\Output.gdb\outputFDS", "Data_2016")
if arcpy.Exists(outFC2016):
    arcpy.Delete_management(outFC2016)

#define table directory
table16dir = r"...\Data_2016_Dir"

#list all tables in dir
tables16 = os.listdir(table16dir)

#define MakeXYEventLayer_management parameters
in_x_field = "Easting"
in_y_field = "Northing"
in_z_field = "Altitude"
sr =  r"Coordinate Systems\Projected Coordinate Systems\Utm\Nad 1983\NAD 1983 UTM Zone 11N.prj"

#create empty list to hold lyrs for merge
inTableLyrs16 = []

for table in tables16:
    if table.endswith(".csv"):
        inTable = os.path.join(table16dir, table)
        lyrName = table.replace(".csv", "") + "_lyr"
        if arcpy.Exists(lyrName):
                    arcpy.Delete_management(lyrName)
        inTableLyrs16.append(lyrName)

        #make xy event
        arcpy.MakeXYEventLayer_management(inTable, in_x_field, in_y_field, lyrName, sr, in_z_field)


#merge all 2016 GOEA data
arcpy.Merge_management (inTableLyrs16, outFC2016)

It produces a feature class that draws near the equator, when it should be drawing in Southern California.

I think that the spatial reference is correct for a few reasons. First, the metadata for the table says the coordinates are in NAD83 zone 11. That should be 11N. Second, the value I have for "sr" is taken directly from the ESRI example online. Third, I'm pushing it into a feature dataset with UTM 11N projection. Fourth, when I use the Go To XY tool in ArcMap, it places any point from one of these tables in the correct location. Fifth, if I use Add XY Data, and assign the projection to UTM Zone 11N, they show up in the correct location.

One possible factor worth mentioning is I'm working on Citrix.

Can anyone tell me why it doesn't work when scripted?

Here is a sample of the table I'm working with.

Easting     Northing    Zone    Altitude
521341.6335 3618762.765 11      901
521396.3151 3618613.56  11      917
522064.6776 3618697.498 11      975
522063.268  3618699.158 11      981
522062.5182 3618699.156 11      980
522066.8389 3618694.953 11      970
522064.0168 3618699.603 11      977
522063.2746 3618696.165 11      981
522064.6766 3618697.942 11      980
522066.0844 3618697.058 11      975
522004.2594 3618554.804 11      1069
522004.2678 3618551.035 11      1068
522005.6709 3618552.257 11      1058
522004.9238 3618551.036 11      1068
3
  • 1
    try setting sr to be a full path (e.g. c:\temp\something\xyz.prj) as currently it starts at "Coordinate Systems" which could be anywhere.
    – Hornbydd
    Commented Jun 28, 2017 at 15:44
  • 5
    Or set the sr using the factoryCode (well-known ID): 26911.
    – mkennedy
    Commented Jun 28, 2017 at 16:41
  • I ran your code with this sample. It's Ok !!
    – BBG_GIS
    Commented Nov 22, 2017 at 23:09

1 Answer 1

1

As mentioned by @Hornbydd or @mkennedy, there are a few ways to create the spatial reference.

Per arcpy documentation:

  1. Using the name of the coordinate system sr = arcpy.SpatialReference("NAD 1983 UTM Zone 11N") #doublecheck beacause it may be written incorrectly
  2. Using a projection file (.prj) sr = arcpy.SpatialReference(" c:\temp\something\xyz.prj")
  3. Using a coordinate system's factory code (or authority code) sr = arcpy.SpatialReference(26911) EPSG:26911

Since your script doesn't include an absolute path to the .prj, perhaps it's accessing a different file than you're expecting, or maybe file corruption? Try the third option (ESPG code).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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