Projection-on-the-fly affecting ArcMap vs. ArcCatalog script results

[JuanDeclet-Barreto]

I am running an Intersect operation within a Python script between two feature classes, one points, the other polygon. I am getting different outputs depending on whether I run the script in ArcCatalog or in ArcMap, but only when the spatial references of the inputs don't match. In such a case, running the tool in ArcCatalog gives me one output feature class, but when I run it in ArcMap I get the same point data, but spatially displaced.

I believe that ArcMap's projection on the fly is responsible for this. So I'd like to write some logic into my script to account for different spatial references and get the same exact result in either Catalog or Map, but I find this hard to achieve. I would think that projecting one of the feature classes to the other's spatial reference would do the trick, but to my knowledge it's not efficient to predict all possible combinations of spatial references and transformations to be able to do this programatically.

I tried setting the Output Coordinate System and the Cartographic Coordinate System environment properties, but these seemed to have no impact on the Intersect operation.

Any suggestions?

[MathewCoyle]

Project them to the same coordinate system, this is the only way to get accurate data. Not doing so I would construe as unethical or even fraudulent, depending on the sensitivity/importance of what you are managing.

You are having problems because on the fly projections in scripting will use default transformations and not take into account where you are or what transformations are available (possibly this can change in 10.1 given their new management of coordinate systems, but I don't recall hearing anything about changes to transformations). Operating in WGS84 is a good solution, most other coordinate systems have solid transformations for going in/out of this system.