nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

When selecting the Unique Values symbology option, Do Not pick a random field.

RTPL_AU

Currently with Pro 3.3.2 when you select the Unique Values option in Symbology, Pro will pick a random(?) field and attempt to add all the attribute values & colour them.
It usually picks the wrong field and you have to wait to get the UI back before you can change the field to the correct one.

Please change the behaviour so that Pro will wait for the user to specify a field once the Unique Values option is chosen.

Find more posts tagged with

Map Authoring

Status: Open

Comments

KoryKramer

@RTPL_AU

What are the field types and order of the fields in that table where Unique Values defaults to Shape_Length?

RTPL_AU

Hi @KoryKramer - that was a screenshot of the window for context.

I'll have to upgrade and check behaviour in 3.4
3.3 Just seems a bit Wanda to me.

For some reason, on some occasions, it will pick and populate the classes. I realise now that it is not normal behaviour and in most cases it picks a field and then waits for you to add the classes.

KoryKramer

@JakeJacobsAVA @AlfredBaldenweck @Luke_Pinner

Since @RTPL_AU doesn't have an example of the Unique Values renderer choosing a random field and instead going straight to Shape_Length, and you added your kudos to the idea, can one of you provide an example?

If there are other fields in the data, it shouldn't choose Shape_Length first - meaning if we get a reproducible case we would log a bug. Please share if you have something.

Thank you

AlfredBaldenweck

I think what it is is that Shape_Length is always chosen as the display field, which everything defaults to and can't be permanently changed in the file's properties outside of the map.

I just made a polygon feature class from scratch with the following fields: OBJECTID, SHAPE, NAME, DAY.

During creation, OBJECTID, SHAPE, SHAPE_LENGTH, and SHAPE_AREA are created, then (I assume) the first field that is neither OBJECTID or Shape is chosen as the default display field. THEN, the other two fields are added. You can watch it happen-- File is created, then it gives you an "Adding fields" pop-up.

Once this happens, every single thing defaults to the display field: Feature identifiers in popups, the field expression in a label class, and symbology.

Just for fun, I updated the display field to be Name, then reset my symbology to Single Symbol and back to Unique values. It still chose Shape_Length. Labelling and Popups honor it, though.

So we have a few problems here.

1) Why doesn't it go for something that isn't Shape_Length for the display field initially? I think just about every user would prefer OBJECTID to that; at least OIDs are unique. (Note: on a point FC, it chose OBJECTID. Inconsistent behavior.

2) Why don't these other settings honor what I changed the display to? It changes for the Popups and labelling, but not for Symbology.

3) Why isn't there an option in the actual feature class properties to set this sort of thing, similar to setting an alias?

4) Looks like adding it in to the map fresh resets it to the first field that is not geometry or the OID field. This will affect the Popup and Labels, but same thing: Symbology remains as the geometry field.