idea Display null SHAPE as <Null> in the attribute table in ArcGIS Pro Ideas

Display null SHAPE as in the attribute table

Bud — Tue, 16 Jan 2024 12:01:17 GMT

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

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 with 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 table:

So that makes me think that the "Polygon" text is kind of fake, for lack of a better word. Maybe ArcGIS Pro just grabs that text from the FC system tables and uses it to show something in the SHAPE field -- for the whole field, regardless if the shapes are populated or not.

Could that behaviour be changed so that null SHAPEs are displayed as <Null>?

Re: Display null SHAPE as in the attribute table - Status changed to: Needs Clarification

SSWoodward — Sat, 28 Oct 2023 01:54:20 GMT

Thanks for the ideas @Bud ,

Could you help us understand what problem this would solve for you in a current workflow?

Re: Display null SHAPE as in the attribute table

DuncanHornby — Sat, 28 Oct 2023 15:32:22 GMT

I wonder rather than saying null, it's coloured or in italics. I hear what you are saying but seeing null might think I could put a point in when it's a polygon feature class or something daft like that?

Re: Display null SHAPE as in the attribute table

MErikReedAugusta — Mon, 30 Oct 2023 17:52:17 GMT

I can't kudo this because of @SSWoodward 's "Needs Clarification" tag, but I'd be very much in favor of this.

I can think of vanishingly few cases where NULL geometry would need to even be permissible in a geographically-aware Feature Class. We generally flip the switch to NOT allow it on all our Feature Classes, but when QA/QC-ing things I get from other parties, this would be helpful to tell at-a-glance that they broke something.

I get that it's saying the Feature Class is a polygon Feature Class in Bud's photos, but I feel like that's at best needlessly-redundant information. And it's potentially incorrect and misleading information on top of that potential redundancy.

If I go to try to work with that first feature in a data access cursor in ArcPy, it's going to throw all kinds of errors, because NoneType != arcpy Polygon Geometry Object, and therefore all the attributes I might try to check for like Area or perimeter Length won't exist, because NoneType doesn't have those.

Re: Display null SHAPE as in the attribute table - Status changed to: Open

SSWoodward — Mon, 30 Oct 2023 17:57:49 GMT

@MErikReedAugusta I opened it back up for you. Give it a kudo.

Re: Display null SHAPE as in the attribute table

Bud — Mon, 30 Oct 2023 20:41:42 GMT

@SSWoodward Regarding, "Could you help us understand what problem this would solve for you in a current workflow?"

Users load non-spatial data into FCs using the Load/Append tool, such as loading rows from an Excel spreadsheet into a polygon FC, which results in rows where the SHAPE is null. Then, a user edits the rows afterwards to populate the SHAPE. When working in the attribute table, it would be helpful to see right in the attribute table what rows have null SHAPEs and what ones have the SHAPE populated. Yes, we can query for nulls using SQL if we need to, but other users might not be aware they exist or are even possible. It would help if the attribute table informed users that the nulls were there -- without needing to go looking for them.

It's also possible to create null SHAPEs by hitting, "Click to add new row" in the attribute table. And it can be done with Python and SQL (using legitimate Esri ST_GEOMETRY SQL functions). There are probably other ways as well. I just used the field calculator scenario in my original post as a simple example, but the Excel/load example is more likely.

Re: Display null SHAPE as in the attribute table

Bud — Tue, 28 Nov 2023 22:41:21 GMT

@DuncanHornby
I wonder rather than saying null, it's coloured or in italics. I hear what you are saying but seeing null might think I could put a point in when it's a polygon feature class or something daft like that?

I'd like to think ArcGIS Pro (or the underlying spatial type in ST_GEOMETRY) would prevent the wrong geometry type from being inserted into an FC.

Edit: But I suppose other datatypes like Oracle's SDO_GEOMETRY don't have the same constraint. SDO_GEOMETRY allows points, lines, and polygons to be stored in the same SHAPE column in the same table (FC).

Re: Display null SHAPE as in the attribute table

Bud — Thu, 23 Nov 2023 17:32:48 GMT

@MErikReedAugusta

We generally flip the switch to NOT allow it on all our Feature Classes

Just a heads up, that doesn't seem to be possible in ArcGIS Pro, only in ArcMap:

Idea - Disallow null shape when creating feature class

Re: Display null SHAPE as in the attribute table

Bud — Tue, 16 Jan 2024 12:10:36 GMT

This idea is especially applicable to point FCs because they don't have the other SHAPE-related fields like area and length that would indicate that a SHAPE field is null.

For example, in this point FC, the selected feature has a null SHAPE. But there's no way to tell from the attribute table.

In my opinion, that's not really acceptable. The attribute table should tell us the shape is null.

I'm aware that the Edit Vertices pane indicates that there are no vertices, which tells us that the SHAPE is null. But that only helps us for a single feature at a time. And it doesn't help us find null shapes that we weren't already aware of.

So I really do think the SHAPE column in the attribute table should indicate null SHAPEs.

Re: Display null SHAPE as in the attribute table

AJR — Tue, 23 Jan 2024 23:50:16 GMT

@MErikReedAugusta- there are many use cases where null shapes are needed (i.e. integration with non-GIS systems where the spatial portion of the record is updated after initial insert by a non-spatial system). Better display/handling in the ArcGIS Pro UI along the lines of what @Bud mentions would be very helpful.