Attribute Table — Indicate if SHAPE field is null vs. geometry is empty

Bud

ArcGIS Pro 2.6.8, Oracle 18c 10.7.1 EGDB; SDE.ST_GEOMETRY

If I understand correctly, a feature can either have:

Null SHAPE field, or
SHAPE field is not null, but the geometry is null
(Never both at the same time)

There isn't a way to visually determine if the feature is A or B from within the attribute table.

However, when querying using Select By Attributes or a definition query, it's important for the user to know if a feature is A or B. For example, if we use the SQL expression SHAPE IS NULL, that's only going to catch A, not B. If we didn't know there were B rows, then we wouldn't think to query for them.

I'm aware that I can use St_Geometry's isEmpty SQL function in some cases. That does work (beware of a bug for versioned data), but I think it would be helpful to have an option to display B differently from A in the attribute table, as a way of alerting the user.

MErikReedAugusta · ‎10-27-2023

This might be an issue of terms, because as you point out, there's quite a bit of conflict and overlap, however:

Can the Shape field ever be NULL? I know a feature can potentially have NULL geometry, but I always viewed the shape field as being dictated by the chosen geometry type of the feature class.

i.e., If I create a new Polygon Feature Class that has Z coordinate values, the Shape field is always going to say "Polygon Z" for all features in that feature class, isn't it, as shown below?

I wasn't aware it was possible for that field to ever be NULL, even if the geometry of the feature is NULL.

EDIT: My experience thus far is largely with FGDBs, so it's possible what you're discussing is possible in Enterprise, but not FGDB.

Bud · ‎10-27-2023

@MErikReedAugusta

It's possible to set a SHAPE field to null using the attribute table, field calculator, Python, and SQL. Here's how to do it in the field calculator:

Right-click the SHAPE field —> Field Calculator —> Type None —> Apply.

Verify that the SHAPE is now null by querying in a SQL client like SQL developer:

In the attribute table in ArcGIS Pro, the SHAPE is still shown as "Polygon", even though the SHAPE is really null in the underlying data:

So that makes me think that the "Polygon" text is fake. Maybe ArcGIS Pro just grabs that text from the FC system tables and uses it to show something in the SHAPE field. Maybe Esri couldn't think of anything better to display there, since it's not like they're going to list the feature coordinates (too long & slow).

Just guessing.

Related: Display null SHAPE as <Null> in the attribute table

Bud · ‎10-30-2023

Likewise, "Click to add new row" in the attribute table creates a row with a null SHAPE.

And if I were to load non-spatial data into the FC from Excel, etc. using the Load/Append tool, the SHAPE would also be null.

Yet, the SHAPE field in the attribute table would be displayed as "Polygon", not "<Null>".

MErikReedAugusta · ‎10-30-2023

I've always viewed that SHAPE field as being the type of geometry that the feature can hold, not necessarily what it is holding.

I'll agree, though, that this is further complicated by things like the Data Access cursors in ArcPy, where the field name/token "SHAPE@" gets you the geometry object, which can be NULL.

You're probably right that "Polygon" in your screenshots means absolutely nothing in practice, and better UI would be to show what type of geometry is contained in the feature. 99/100, it'll be the same as the geometry of your Feature Class, because otherwise why bother with a geolocated feature in the first place. But it would help find that 1/100 mistake with NULL geometry.

Though as an aside, I've never understood why NULL geometry would need to be permitted. We're talking about a geographically-aware Feature Class; there are other data structures for when the position isn't vitally important.

Bud · ‎11-23-2023

@MErikReedAugusta

Though as an aside, I've never understood why NULL geometry would need to be permitted. We're talking about a geographically-aware Feature Class; there are other data structures for when the position isn't vitally important.

We have a workflow where we load rows from a non-spatial datasource (like a spreadsheet) into a FC. Then we go in after the fact and create/digitize the shapes. It's worked well for us in the past.