Are Shape_Length and Shape__Length really the same?

Question

I’ve noticed discrepancies between Shape_Length and Shape__Length when exporting feature classes to different formats (e.g., FGDB → shapefile / CAD). In some workflows they match, in others they don’t. How are you all handling this in production pipelines?

Miralem_Zeljo · Answer

Thank you for the reply!

Miralem_Zeljo · Answer

System-driven automations appear to have a significant impact on how custom symbology behaves in both ArcGIS Online and ArcGIS Pro. Specifically, when using Save Web Layer to update symbology driven by Shape_Length or Shape__Length, I’ve encountered cases where the symbology becomes corrupted. In those situations, the only reliable fix was to republish the data.

Miralem_Zeljo · Answer

I’m starting to suspect that relying on `Shape_Length` (or `Shape__Length` after export) for symbology in ArcGIS Pro can introduce subtle—but real—issues.

Here’s what I’m seeing:

* In FGDB vs enterprise GDB, length values can differ slightly due to parametric curves vs densified geometry
* When exporting (e.g., to shapefile or CAD), `Shape_Length` often becomes `Shape__Length` or gets truncated
* After that, symbology driven by those fields sometimes:

* fails to apply
* behaves inconsistently
* or throws field-related errors when overriding symbology

My assumption is that this is a combination of:

* system-managed field behavior
* field renaming/recreation during export
* and ArcGIS Pro’s sensitivity to field references in renderers

In workflows where symbology is tied to length (fiber segmentation, QA layers, etc.), this can get messy fast.

Curious how others are handling this:

* Do you avoid using `Shape_Length` for symbology altogether?
* Do you copy values into a user-defined field to stabilize things?
* Have you run into symbology breaking after data moves between FGDB / SDE / shapefile?

Feels like one of those edge cases that turns into a real production issue if not handled carefully.