Select to view content in your preferred language

Display Name in layer properties defaulting to Shape_Length despite other fields called "Name" in attribute table

521
4
01-19-2024 10:01 AM
Labels (3)
RyanWalter
Occasional Contributor

Hi all, title says most of it.

We've built a tool in ModelBuilder to create a number of datasets for us that we then upload to our organization's AGOL account. That tool applies custom symbologies and creates specific fields that other people in our organization will use. Our tool has worked nicely for us, but we've added a new module that creates new feature classes (which we then add to a map from the output feature database, we'd love for these to add to the map automatically, but they don't, per a bug someone else has previously ID'd) we then want to upload those layers to AGOL using the "Share>Publish Web Layer" option on the whole group of new feature classes we've created.

The problem we're running into is that the display name for these new feature layers defaults to "Shape_Length" despite the fact that there are multiple other fields in the layer called "Project Name," "Label," etc. The ArcPro documentation here states that the display field is "By default, it is set to the first available string field in the feature layer containing the word name in the field name." This default behavior is not occurring and we do not know why.

Has anyone run into this issue before? Does anyone know how we can set in ModelBuilder or in the publish web layer menu the display name to not be "Shape_Length"?

To be clear, setting the display name individually in the layer properties is not an option, as we will be running this tool on hundreds of sites and do not have the bandwidth to set it all manually. Thanks!

0 Kudos
4 Replies
Robert_LeClair
Esri Notable Contributor

So I believe this is BUG-000143180 - "ArcGIS Pro has to assign the Display field of a feature class in the same manner as ArcMap."  Per the bug report:

  • When a new feature class is created in ArcMap, without additional fields, the Display field is SHAPE_Length.  (My thoughts:  In your model, you stated you're creating new feature classes.  Question - are user attribute fields being created here, later in the model or no user attribute fields?  If no, then 4 ArcGIS maintained fields are being created:  OBJECTID, SHAPE, SHAPE_LENGTH, and SHAPE_AREA.  So the Display field is defaulting to SHAPE_LENGTH as you're seeing)
  • If there are multiple fields, the first text field is the display field. If there are no text fields, the first number field is display field.  (My thoughts:  This is SHAPE_LENGTH again.)
  • When you create a feature class in ArcGIS Pro with multiple fields, the display field will still be SHAPE_Length.
  • When users try to publish this feature class in ArcGIS Pro, they will always receive the error “00241: Unsupported fields cannot be used for authoring”. This is very annoying and confusing for the user. If ArcGIS Pro behaves the same way as ArcMap, the user won’t get this error when the feature class has multiple fields.

One test to run is create a new feature class outside of the model - one without user attribute fields created - what does the Display Name default to?  And another one with user defined attribute fields when creating the new feature class outside of the model.  What does the Display name default to?

0 Kudos
AndreaB_
Frequent Contributor

Hi @Robert_LeClair ,

This is interesting. Does this bug report imply that ArcGIS Pro should not be defaulting to shape_length field if there are no user attribute fields? circle back to https://community.esri.com/t5/arcgis-pro-ideas/make-display-field-default-to-objectid/idi-p/1350948 

0 Kudos
Robert_LeClair
Esri Notable Contributor

I tested a new polygon feature class with no attributes and the Display Field defaulted to Shape_Length in both so that's functional equivalency there.  I think what should be done is the default display field to be ObjectID so it doesn't throw the error.  Since ObjectID's are 32-bit, it would not cause an error publishing.

0 Kudos
AndreaB_
Frequent Contributor

I would 100% agree. Thanks.

0 Kudos