Shape_Area/Shape_Length fields on PostgreSQL

[MariusBartašius]

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?

[George_Thompson]

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-...

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

So the name cannot be changed.

[RPGIS]

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.

[CalvinHarmin]

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.

[George_Thompson]

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-attribute...

[CalvinHarmin]

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.

[George_Thompson]

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.

[RPGIS]

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.