topic Re: Shape_Area/Shape_Length fields on PostgreSQL in ArcGIS Enterprise Questions

Shape_Area/Shape_Length fields on PostgreSQL

MariusBartašius — Wed, 27 Aug 2025 07:08:39 GMT

I try to append data using Arcpy and sometimes, I lose geometry due to different data map. On GDB it's Shape_Area. On SDE it's ST_AREA(SHAPE). Can I rename it so I would always have same field names, if not why?

Re: Shape_Area/Shape_Length fields on PostgreSQL

George_Thompson — Wed, 27 Aug 2025 09:49:47 GMT

Here is some additional information on those fields. They are system generated and maintained:

https://pro.arcgis.com/en/pro-app/latest/tool-reference/appendices/geoprocessing-considerations-for-shapefile-output.htm#ESRI_SECTION1_0125A6BC969E486B9470F55825EC6C62

https://support.esri.com/en-us/knowledge-base/why-are-there-differences-in-the-shape-area-and-shape-l-000011203

So the name cannot be changed.

Re: Shape_Area/Shape_Length fields on PostgreSQL

RPGIS — Wed, 27 Aug 2025 11:22:57 GMT

Like @George_Thompson said, those names cannot be renamed. However, when it comes to using any programming language, you can create a dictionary of mapped field names. For example ( { Shape_Area: ST_AREA } ) so when you change data sources you can get the equivalent field that you need and vice versa.

Re: Shape_Area/Shape_Length fields on PostgreSQL

CalvinHarmin — Wed, 27 Aug 2025 13:32:27 GMT

I also found this to be a bit frustrating, it's even different between SQL Server enterprise gdb using ST_Geometry, Shape.STArea(), vs Postgres enterprise gdb using ST_Geometry, st_area(shape).

In the SQL Server or Postgres databases, Shape is a single geometry field, so it seems confounding why ArcGIS desktop must 'interpret' the shape area/length meta-field names in different ways between file geodatabases, and enterprise geodatabases of different underlying db type. I'd be curious about the explanation for that if there is one.

Using python arcpy cursor methods, you can refer to all of these the same standardized way with the 'geometry tokens' SHAPE@, or more specific SHAPE@AREA, SHAPE@XY, SHAPE@LENGTH, etc.

Re: Shape_Area/Shape_Length fields on PostgreSQL

George_Thompson — Wed, 27 Aug 2025 19:29:23 GMT

As I understand it, there are "auto-generated" fields by the software. If you need "true" calculations I would look at having a specific field and use this tool: https://pro.arcgis.com/en/pro-app/latest/tool-reference/data-management/calculate-geometry-attributes.htm

Re: Shape_Area/Shape_Length fields on PostgreSQL

CalvinHarmin — Wed, 27 Aug 2025 20:33:38 GMT

I get that it's autogenerated, but it seems quite arbitrary to have the field names be different depending on the *gdb source, since there is not an actual column named st_area(shape) in the postgres database, for example. When using ST_geometry for the feature class in the egdb, the geometry is stored in the shape column in postgres in a well-known-binary format, if I understand correctly, so I assume that is being interpreted by ArcGIS software, so why not have the software display the polygon geometry in a field simply named shape_area the same way that a file geodatabase displays it?

I'm not expecting you to have the answer, but I'm still throwing it out to the universe since I expect there is a good reason, and I'm just curious what's going on under the hood.

Re: Shape_Area/Shape_Length fields on PostgreSQL

George_Thompson — Thu, 28 Aug 2025 10:23:04 GMT

Good question as to the "why", unfortunately I am not sure. I know that this behavior has been around for a while 15+ years I have been at this.

Re: Shape_Area/Shape_Length fields on PostgreSQL

RPGIS — Thu, 28 Aug 2025 14:57:10 GMT

As someone who also does SQL querying in SQL server you can rename a shape field to any name you want in SQL. As to why the default is what it is nobody truly knows. My only thoughts are that it is the variation in database types since SQL has mulitple variants such as PostgreSQL, MySQL, OracleSQL, and SQL Server. I think geodatabases are a stem of what are considered Microsoft Access Databases but are created to have local shapefields.

As @CalvinHarmin pointed out, using the SHAPE@ should be used in python since I believe it is catchall regarding any shape field.