Issues with ArcPy SpatialReference Class

6595
25
04-27-2016 01:34 AM
MattBrehm
New Contributor II

     I am attempting to write a Python script that uses a general reference map of the NAD 1983 UTM Zones to automate the selection of an appropriate map projection for a specific area. I have completed the script up until the point at which I need to create a SpatialReference object that contains the appropriate projection. I have been getting a 999999 general runtime error whenever I try to assign the SpatialReference object the value of "NAD 1983 UTM Zone 9N" or lower, but past "NAD 1983 UTM Zone 10N", it works.

     This screenshot is the result of a test script in which I import ArcPy, and then try to initialize a SpatialReference object with the respective values mentioned above. In the second run, I printed the SpatialReference object's name in order to test to make sure that the value was assigned correctly. Am I missing something here, or is this a known issue with assigning the names of projections to SpatialReference objects? I would otherwise use the WKID for the projection, but the reference map that I am using only contains a field for the name of the projection.

Edit: I am using general reference maps for both the NAD 1983 UTM Zones as well as the USA State Plane Zones NAD83 in order to find an appropriate projection for an input dataset. I first find the centroid of the dataset, and then select by location from the reference projection maps. From the responses here and my own testing, it seems as if trying to assign SpatialReference objects the projections by name does not work for certain types of projections. Namely, the NAD 1983 UTM Zone 1-9 projections. I have also yet to find a U.S. State Plane projection in which the SpatialReference object does not give an error when attempting to assign the projection by name. The solution seems to be to assign the SpatialReference object by WKID. but this could be quite cumbersome if the assignment of projection WKIDs does not follow an intuitive pattern and you're working with hundreds of reference projections.

Tags (2)
0 Kudos
25 Replies
DanPatterson_Retired
MVP Esteemed Contributor

I have a vague recollection of something... try putting an r in front of the coordinate reference ie r"NAD....." but I remember something about underscores, but I can't put my hands on it.

MattBrehm
New Contributor II

I did try this, I know that putting an 'r' in front of a string indicates to Python to read the string as a literal, rather than reading in special characters.

i.e. Writing a string with "\n" in it will tell Python to print to the next line, etc.

I also ran a few tests with underscores vs. spaces

But unfortunately, it did not solve the issue.

0 Kudos
NeilAyres
MVP Frequent Contributor

Why not just use the WKID to reference the correct zone.

NAD83 UTM xxN is numbered very logically

NAD_1983_UTM_Zone_1N 26901

NAD_1983_UTM_Zone_2N 26902

...

NAD_1983_UTM_Zone_10N 26910

etc

DanPatterson_Retired
MVP Esteemed Contributor

his last sentence says why

NeilAyres
MVP Frequent Contributor

You could just create it on the fly.

A quick investigation...

>>> import arcpy
>>> idList = [str(i+1).zfill(2) for i in range(0, 50)]
>>> idList
['01', '02', '03', '04', '05', '06', '07', '08', '09', '10', '11', '12', '13', '14', '15', '16', '17', '18', '19', '20', '21', '22', '23', '24', '25', '26', '27', '28', '29', '30', '31', '32', '33', '34', '35', '36', '37', '38', '39', '40', '41', '42', '43', '44', '45', '46', '47', '48', '49', '50']
>>> base = "269"
>>> for i in idList:
 sr = arcpy.SpatialReference(int(base + i))
 name = sr.name
 print "WKID {}  Name {}".format(int(base + i), name)

WKID 26901  Name NAD_1983_UTM_Zone_1N
WKID 26902  Name NAD_1983_UTM_Zone_2N
WKID 26903  Name NAD_1983_UTM_Zone_3N
WKID 26904  Name NAD_1983_UTM_Zone_4N
WKID 26905  Name NAD_1983_UTM_Zone_5N
WKID 26906  Name NAD_1983_UTM_Zone_6N
WKID 26907  Name NAD_1983_UTM_Zone_7N
WKID 26908  Name NAD_1983_UTM_Zone_8N
WKID 26909  Name NAD_1983_UTM_Zone_9N
WKID 26910  Name NAD_1983_UTM_Zone_10N
WKID 26911  Name NAD_1983_UTM_Zone_11N
WKID 26912  Name NAD_1983_UTM_Zone_12N
WKID 26913  Name NAD_1983_UTM_Zone_13N
WKID 26914  Name NAD_1983_UTM_Zone_14N
WKID 26915  Name NAD_1983_UTM_Zone_15N
WKID 26916  Name NAD_1983_UTM_Zone_16N
WKID 26917  Name NAD_1983_UTM_Zone_17N
WKID 26918  Name NAD_1983_UTM_Zone_18N
WKID 26919  Name NAD_1983_UTM_Zone_19N
WKID 26920  Name NAD_1983_UTM_Zone_20N
WKID 26921  Name NAD_1983_UTM_Zone_21N
WKID 26922  Name NAD_1983_UTM_Zone_22N
WKID 26923  Name NAD_1983_UTM_Zone_23N

It errors out after 23.

NeilAyres
MVP Frequent Contributor

This name vs wkid to specify the sr is very odd.

This wkid from my help files.

sr = arcpy.SpatialReference(102007)
>>> sr.name
u'Hawaii_Albers_Equal_Area_Conic'
>>> sr = arcpy.SpatialReference('Hawaii_Albers_Equal_Area_Conic')
Traceback (most recent call last): # errors out here, but then replace the "_" with a space
  File "<pyshell#23>", line 1, in <module>
sr = arcpy.SpatialReference('Hawaii_Albers_Equal_Area_Conic'.replace("_", " "))
>>> sr
<SpatialReference object at 0x2a68850[0x1108ead0]>
>>> sr.name
u'Hawaii_Albers_Equal_Area_Conic'
NeilAyres
MVP Frequent Contributor

But that approach doesn't work with these UTM ids.

>>> sr = arcpy.SpatialReference(26901)
>>> sr.name
u'NAD_1983_UTM_Zone_1N'
>>> sr = arcpy.SpatialReference('NAD_1983_UTM_Zone_1N'.replace("_", " "))
Traceback (most recent call last):
  File "<pyshell#29>", line 1, in <module>
    sr = arcpy.SpatialReference('NAD_1983_UTM_Zone_1N'.replace("_", " "))
  File "C:\Program Files (x86)\ArcGIS\Desktop10.3\ArcPy\arcpy\arcobjects\mixins.py", line 949, in __init__
    self._arc_object.createFromFile(item)
RuntimeError: ERROR 999999: Error executing function.
>>> 
MattBrehm
New Contributor II

It's very odd. I am not sure as to why the UTM ids don't work if the SpatialReferece object is assigned their name rather than their WKID. I was hoping to avoid creating a dictionary in Python for the UTM zones and their respective WKID numbers. I wasn't sure that they were sequential, but that will work.

0 Kudos
MattBrehm
New Contributor II

It also seems to work with UTM Zones greater than 10. If you were to run your test again with the NAD 1983 UTM Zone 10N projection, it should work correctly.

Such as:

vs.