nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Memory Workspace: Geometry difference between Script Tool and Python Terminal?

GB_MattPanunto_GISS

Hello,

I'm trying to project a feature class and save the output to the memory workspace. However, it seems that outputs from the Project tool can't be stored in the memory workspace. I figured I could get around this by setting my arcpy.env.outputCoordinateSystem, then running FeatureClasstoFeatureClass, and storing the output in the memory workspace. That seems to work just fine.

To check that it is indeed working properly, I've also created a GDB feature class with the Project tool. Then, I calculate geometry for both the memory workspace output and the GDB feature class, and compare the values.

I get identical geometry values when I run this code from a script tool, but when I run the same code from a Python terminal I get slightly different values. Is there something different about these two environments that I'm unaware of? Also, is there a better way to project a feature class and store the output in the memory workspace?

Thanks!

Trouver plus de publications taguées avec

Accepted answers

All comments

GB_MattPanunto_GISS

The change from "memory" to "in_memory" seems to yield the same results. I've attached a .zip with the toolbox, script, and test GDB feature class if you'd like to check it out. Thanks for the suggestions.

inmemoryissue.zip

danretired

Interesting...

on a lark, change "memory" to the legacy "in_memory"

Write geoprocessing output to memory—ArcGIS Pro | Documentation

That would nail down whether having the map is the issue or there is a "memory" issue (or both)

I can't test since all of my toolboxes and tools work of maps or tables.

GB_MattPanunto_GISS

Maybe these screenshots will help explain what I'm experiencing.

The first screenshot shows the calculated geometry values I get when running from the Python terminal, and from script tool when ArcGIS Pro is first opened (no map inserted). The values do not match.

The second screenshot shows the calculated geometry values I get when running from script tool when a map is inserted, and the map frame's coordinate system is changed to NAD83. The values match.

GB_MattPanunto_GISS

I'm not actually using Web Mercator, I was just explaining how I happened to discover the changing behavior of the geometry value for the memory workspace output. Why would the map frame's coordinate system affect that when using a script tool? And yes, you are correct that the feature class I am projecting is in a GCS with WGS84 datum.

danretired

Web Mercator has "issues" with geometry properties such as area and distance/length. I wouldn't use it for anything other than having to look at something (like on AGOL).

Find a projected coordinate system that is well used for your area if you are working with anything doing with geometry (UTM (sf 0.9996), State Plane (modified transverse mercator sf 0.9999). For larger extents, do the same (albers, LCC etc) use widely supported variants for your locale

If you are stuck with having to use web mercator for some of your stuff, do geometry on you local machine and web it after.

As for WGS84, I assume that you mean a GCS (geographic coordinate system with decimal degree coordinates, and a WGS84 datum)

GB_MattPanunto_GISS

sys.executable returns the same executable in the script tool and Python terminal, and am only using arcpy-based methods for the projection.

After poking around a bit more, I discovered something I didn't notice before. If I open a fresh ArcGIS Pro project without a template, and also without having inserted a map yet, the script tool actually returns the exact same values as the Python terminal. Meaning that the small differences in geometry will be present between the memory workspace output and the GDB feature class.

Additionally, if I insert a map into the project, but do not change the map frame's coordinate system (leave it as Web Merc Aux Sphere), the script tool will also give me the exact same geometry values as the Python terminal. Again, the small differences in geometry will be present between the two outputs.

However, if I then change the coordinate system of the map frame to NAD83 or a projection with NAD83 as the datum, the geometry value of the memory workspace output changes to match that of the GDB feature class. The geometry value of the GDB feature class never changes. So it would seem that the coordinate system of the map frame has some influence on the memory workspace when used in a script tool, though I don't understand why. For what it's worth, the feature class being projected is in WGS84.

It would be great to be able to reliable use the memory workspace because it is so much faster than generating outputs and deleting them.

danretired

import sys
sys.executable
'C:\\arc_pro\\bin\\Python\\envs\\arcgispro-py3\\python.exe'
# --- where "arc_pro" is your ArcGIS Pro install folder

Check that you are using the same python executable.

There is nothing special about "memory" workspaces.

If you are using arcpy-based methods for the projection, then you should have no differences in geometry (that is, directly through arcpy or via the Project tool)

If you are using non-arcpy based projection (eg. external packages, arcgis module using shapely etc etc) you might get differences. Just use esri/arcpy based geometry tools for geometry.

Everything is "memory" whether temporary or more permanent. Just make sure you are working "local" versus network/web/cloud

What is wrong with projecting a feature class and storing the output to the scratch workspace? You can delete it or keep it as you see fit.

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.