Path to .prj files in ArcGIS v10.1?

[ChrisSnyder]

In v10.0 and before there was always a folder that contained all the ESRI .prj definition files... Usually something like C:\Program Files\ArcGIS\Desktop10.0\Coordinate Systems.

Maybe I messed up my install somehow, but now in v10.1 it seems that 'Coordinate Systems' folder is no longer there, and to boot, there are no .prj files at all in the ArcGIS Program Files directory... at all!

I always used the .prj files to set the arcpy.env.outputCoordinateSystem variable (and all its various past incarnations).

What gives? How can we now access the official ESRI projection definitions in a script if there are no .prj definition file anymore?

The help says you can use .prj files, and the provided example in the arcpy.env.outputCoordinateSystem help topic yields:

arcpy.env.outputCoordinateSystem = "Coordinate Systems/Projected Coordinate Systems/UTM/WGS 1984/Northern Hemisphere/WGS 1984 UTM Zone 18N.prj"
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File "C:\Program Files\ArcGIS\Desktop10.1\arcpy\arcpy\geoprocessing\_base.py", line 515, in set_
    self[env] = val
  File "C:\Program Files\ArcGIS\Desktop10.1\arcpy\arcpy\geoprocessing\_base.py", line 567, in __setitem__
    ret_ = setattr(self._gp, item, value)
RuntimeError: Object: Error in accessing environment <outputCoordinateSystem>

Am I totally missing something?

[ChrisSnyder]

Thanks Kim...

http://forums.arcgis.com/threads/43644-UTM-Conversion-in-Python?p=222580&viewfull=1#post222580

Good ole' .prj... you will be missed!

[MathewCoyle]

Well that throws a wrench in things, thanks for posting this so I have time to make some much needed changes before I even start the switch over to 10.1. How does this impact the project tool?

In 10.0 I would do essentially something like this.

outCS = os.path.join(installDir,r"Coordinate Systems\Projected Coordinate Systems\National Grids\Canada\NAD 1983 CSRS UTM Zone 12N.prj")
inCS = os.path.join(installDir,r"Coordinate Systems\Geographic Coordinate Systems\World\WGS 1984.prj")

arcpy.Project_management(in_fc, out_feature, outCS, transform_method, inCS)

In 10.1 would look like this?

inCS = arcpy.SpatialReference()
inCS.factoryCode = some_code1
inCS.create()

outCS = arcpy.SpatialReference()
outCS.factoryCode = some_code2
outCS.create()

arcpy.Project_management(in_fc, out_feature, outCS, transform_method, inCS)

[ChrisSnyder]

Ya - i guess that's how it would work via scripting.

Sure is a pain to find the "codes" since the .pdf is not well structured like the Coordinate Systems directory tree.

Only way I could find the right code was by using v10.0, getting the sr object, and spitting out the "factory code" such as:

>>> arcpy.env.outputCoordinateSystem = r"C:\Program Files\ArcGIS\Desktop10.0\Coordinate Systems\Projected Coordinate Systems\State Plane\NAD 1983 HARN (US Feet)\NAD 1983 HARN StatePlane Washington South FIPS 4602 (US Feet).prj"
>>> arcpy.env.outputCoordinateSystem.factoryCode
2927 

So, my new syntax in v10.1 is this:

arcpy.env.outputCoordinateSystem = 2927 #WA_SPS_NAD83HARN_USFEET

Note that (contrary to the Help topic) this syntax DOES NOT appear to work for me:

>>> arcpy.env.outputCoordinateSystem = arcpy.SpatialReference('NAD_1983_HARN_StatePlane_Washington_South_FIPS_4602_Feet')Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File "C:\Program Files\ArcGIS\Desktop10.0\arcpy\arcpy\geoprocessing\_base.py", line 505, in set_
    self[env] = val
  File "C:\Program Files\ArcGIS\Desktop10.0\arcpy\arcpy\geoprocessing\_base.py", line 557, in __setitem__
    ret_ = setattr(self._gp, item, value)
RuntimeError: <unprintable RuntimeError object>

Note sure why the .prj files went away... Dawning of a new age of fully integrated seamless geospatial technology I guess... Sigh...

COMPLAINT TO ESRI:The v10.1 Help topics that cover to projection-related stuff via Python scripting could use some further explanation about the new code/name based syntax. Script example syntax relating to using spatial reference names to set the SR appears to be incorrect.

[JasonScheirer]

You can find the correct string for the spatial reference you want to create with arcpy.ListSpatialReferences.

[ChrisSnyder]

Thanks Jason - That did work...

For example:

>>> srList = arcpy.ListSpatialReferences("*washington*south*", "PCS")
>>> for sr in srList:
...  print sr
Projected Coordinate Systems/State Plane/NAD 1927 (US Feet)/NAD 1927 StatePlane Washington South FIPS 4602
Projected Coordinate Systems/State Plane/NAD 1983 (CORS96) (Meters)/NAD 1983 (CORS96) StatePlane Washington South FIPS 4602 (Meters)
Projected Coordinate Systems/State Plane/NAD 1983 (CORS96) (US Feet)/NAD 1983 (CORS96) StatePlane Washington South FIPS 4602 (US Feet)
Projected Coordinate Systems/State Plane/NAD 1983 (Meters)/NAD 1983 StatePlane Washington South FIPS 4602 (Meters)
Projected Coordinate Systems/State Plane/NAD 1983 (US Feet)/NAD 1983 StatePlane Washington South FIPS 4602 (US Feet)
Projected Coordinate Systems/State Plane/NAD 1983 HARN (Meters)/NAD 1983 HARN StatePlane Washington South FIPS 4602 (Meters)
Projected Coordinate Systems/State Plane/NAD 1983 HARN (US Feet)/NAD 1983 HARN StatePlane Washington South FIPS 4602 (US Feet)
Projected Coordinate Systems/State Plane/NAD 1983 NSRS2007 (Meters)/NAD 1983 NSRS2007 StatePlane Washington South FIPS 4602 (Meters)
Projected Coordinate Systems/State Plane/NAD 1983 NSRS2007 (US Feet)/NAD 1983 NSRS2007 StatePlane Washington South FIPS 4602 (US Feet)
>>> arcpy.env.outputCoordinateSystem = arcpy.SpatialReference(srList[6])
>>> 

This also works (not sure what I was doing wrong before):

arcpy.env.outputCoordinateSystem = arcpy.SpatialReference('NAD 1983 HARN StatePlane Washington South FIPS 4602 (US Feet)')

[ChrisSnyder]

Oh see what's different...

The "sR.name" property appears to be slightly different than the "official" syntax compliant name that uis given by the arcpy.ListSpatialReferences() method.

Is there any sR property that yields the "syntax compliant" name?

sR.name property of 'NAD_1983_HARN_StatePlane_Washington_South_FIPS_4602_Feet'
vs.
compliant name of 'NAD 1983 HARN StatePlane Washington South FIPS 4602 (US Feet)'

[NeilAyres]

Phew,
I am so glad I stumbled across this little gem. I was about to upgrade my system to 10.1 this w/end.
Now I am not so sure....
The old directory system of *.prj files worked and was quite flexible. ie It was easy to create a new prj for a particular project, say a custom crafted UTM like system (ie with a non-standard central meridian). Now what do you do?
It was also useful to browse the directories when searching for obscure projection info for certain regions.

Why make this info harder to find? And use. Oh and Yes, I can also memorise all xx thousand "factory codes"....

Miffed,
Neil

[PeterYurkosky1]

The old directory system of *.prj files worked and was quite flexible. ie It was easy to create a new prj for a particular project, say a custom crafted UTM like system (ie with a non-standard central meridian). Now what do you do?
It was also useful to browse the directories when searching for obscure projection info for certain regions.

Neil,

We've tried to make it much easier to search for coordinate systems. If you're working in the desktop apps, you can search on a text string (if you only know a fragment of the coordinate system's name), or apply a spatial filter to reduce the list to only those coordinate systems applicable to the map's extent. Once you've found that obscure coordinate system, you can add it to your Favorites and never have to search for it again.

[ChrisSnyder]

Many (most/all?) of the scripting users were accustomed to using the file-based .prj definitions. Some issues I see:

1. The SR properties .name, .PCSName and/or .GCSName do not necessarily match the allowable spatial reference token keywords�?� For example the factory code of 2927 (the projection for all WA State Govt. agencies) has a .name and .PCSName property of 'NAD_1983_HARN_StatePlane_Washington_South_FIPS_4602_Feet', however the spatial reference token keyword is actually 'NAD 1983 HARN StatePlane Washington South FIPS 4602 (US Feet)'. So the effect of this issue is that this works:

arcpy.env.outputCoordinateSystem = arcpy.SpatialReference('NAD 1983 HARN StatePlane Washington South FIPS 4602 (US Feet)')

and this DOES NOT work:

arcpy.env.outputCoordinateSystem = arcpy.SpatialReference('NAD_1983_HARN_StatePlane_Washington_South_FIPS_4602_Feet')

Perhaps my projection (WA SPS NAD83HARN USFEET) is the exception here, but it would be nice to have a SR property that would yield the correct sr token keyword.

2. The Help system topics (Project tool, Project Raster tool, arcpy.env.outputCoordinateSystem, etc) do not adequately describe the disappearance of the file-based .prj files and it's impact on script-based use of the geoprocessing tools, nor does it describe the proper syntax of the factory codes (or how to search for them in projected coordinate systems .pdf reference doc), fails to mention the arcpy.ListSpatialReferences() method, and fails to mention a way to retrieve the proper sr token keywords. Also, script examples for the arcpy.env.outputCoordinateSystem method have the wrong syntax for using the spatial reference token keywords (Help provided example of arcpy.env.outputCoordinateSystem = "Coordinate Systems/Projected Coordinate Systems/UTM/WGS 1984/Northern Hemisphere/WGS 1984 UTM Zone 18N.prj" results in an error.

3. There are no file-based .prj files anymore. This threw me for a big loop! I suppose you can make some with the .exportToString() method, but that's kinda a pain... Seems like some of the legacy tools such as Project Coverage required .prj files... Not sure why the help system mentions .prj files anymore if there aren't any to speak of!

I liked the .prj file folders because they were easy to search... Other than the directory tree in the the coordinate system parameter GUI in the projection-related toolbox tools, I don't really see an easy way to browse and retrieve the factory codes or SR token keywords (which you now need to reference when specifying coordinate systems in a script).   

Getting rid of the file-based .prj definitions is a pretty big change... Like everything else though I'm sure we'll all get used to it.