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; } } }

A script that used to work before is now behaving strangely.

-_-

I was using a script to rewrite the graded color labels with Arcpy, but it stopped working (maybe after I updated to 3.4.3).
I simplified the code and tested it, and the labels were set for just a moment, but then they went back to normal.
Is there something wrong with this code?

import arcpy

lyr="test"
tani="ha"

aprx=arcpy.mp.ArcGISProject("CURRENT")

view=aprx.activeView
mapname=view.map.name
maps=aprx.listMaps(mapname)[0]

l=maps.listLayers(lyr)[0]
label_count_last=l.symbology.renderer.breakCount

if hasattr(l.symbology, 'renderer'):
  if l.symbology.renderer.type == 'GraduatedColorsRenderer':
    sym = l.symbology
    sym.renderer.lowerBound = -10000000                 #3.4 lowerBound set on Renderer
    for i in range(0,label_count_last):
        brk=sym.renderer.classBreaks[i].upperBound
        sym.renderer.classBreaks[i].label=str(brk)+tani

    sym.renderer.classBreaks[-1].upperBound = 10000000 #upperBound set on upper ClassBreak
    l.symbology = sym

When executed:

Najděte více příspěvků označených jako

Accepted answers

JeffreyBarrette

@-_- This is indeed a regression we discovered and fixed during 3.5 and will patch 3.4 with the next available patch. What happened was new behavior was added into the the software called "alwaysUpdateClassLabels". When you simply use the arcpy.mp API to update a class label, it got overwritten due to this new behavior.

aprx = arcpy.mp.ArcGISProject('CURRENT')
active_map = aprx.activeMap
lyr = active_map.listLayers()[0]

sym = lyr.symbology
sym.renderer.classBreaks[0].label = "Testing 123"   #RESETS TO ORIG
lyr.symbology = sym

But as you discovered, if the labels are modified via the CIM, it bypasses internal behavior and works.

aprx = arcpy.mp.ArcGISProject('CURRENT')
active_map = aprx.activeMap
lyr = active_map.listLayers()[0]

lyr_cim = lyr.getDefinition('V3')
lyr_cim.renderer.breaks[0].label = "Testing 123"  #This works
lyr.setDefinition(lyr_cim)

This applies to all renderers and colorizers with class breaks. Our apologies for the breaking change.

Jeff - arcpy.mp team

All comments

JeffreyBarrette

@-_- Pro 3.5 is soon to be released but we will also patch Pro 3.4. The next patch will be Pro 3.4.4.

Jeff - arcpy.mp team

-_-

I see.
The latest version of the Japanese version I use is 3.4.3, so I didn't realize that there was a 3.5 version. I'm sorry.
I feel relieved now that I know the cause. Thank you.

JeffreyBarrette

aprx = arcpy.mp.ArcGISProject('CURRENT')
active_map = aprx.activeMap
lyr = active_map.listLayers()[0]

sym = lyr.symbology
sym.renderer.classBreaks[0].label = "Testing 123"   #RESETS TO ORIG
lyr.symbology = sym

But as you discovered, if the labels are modified via the CIM, it bypasses internal behavior and works.

aprx = arcpy.mp.ArcGISProject('CURRENT')
active_map = aprx.activeMap
lyr = active_map.listLayers()[0]

lyr_cim = lyr.getDefinition('V3')
lyr_cim.renderer.breaks[0].label = "Testing 123"  #This works
lyr.setDefinition(lyr_cim)

This applies to all renderers and colorizers with class breaks. Our apologies for the breaking change.

Jeff - arcpy.mp team

-_-

I still don't know why the original code was causing the problem, but I was able to use CIM access to rewrite the label.

import arcpy

lyr="test"
tani="ha"

aprx=arcpy.mp.ArcGISProject("CURRENT")

view=aprx.activeView
mapname=view.map.name
maps=aprx.listMaps(mapname)[0]

l=maps.listLayers(lyr)[0]
label_count_last=l.symbology.renderer.breakCount

if hasattr(l.symbology, 'renderer'):
  if l.symbology.renderer.type == 'GraduatedColorsRenderer':

    l_cim=l.getDefinition('V3')
    l_cim.renderer.minimumBreak = -10000000

    for i in range(0,label_count_last):
        brk=l_cim.renderer.breaks[i].upperBound
        l_cim.renderer.breaks[i].label=str(brk)+tani

    l_cim.renderer.breaks[-1].upperBound = 10000000
    l.setDefinition(l_cim)

-_-

Sorry, I've always used the scripts in the toolbox and don't know how to run them standalone.

David_Lindsey

Unless this is you in the comment section of this Reddit post, you may not be the only one experiencing this issue recently. In my experience with minor releases (and given how much symbology-related stuff that Esri touched with the 3.4 release), I wouldn't rule out a bug being introduced. No mention of deprecations related to your issue in the release notes either. I use aprx.save() with my symbology updates as well, but haven't been doing the same workflows that you are doing. It does look like you are running the code while Pro is open though. Do the edits save correctly if you run the script as a standalone while Pro is closed? That test might help you rule out a lock or read-only issue...maybe. Oh, and be sure to save a copy of your project beforehand if you try anything as a standalone. I learned that lesson the hard way. Ha.

-_-

The original code included code to set upper and lower limits, but this has now been removed in order to identify the cause.

Does this code work as intended in your environment?

-_-

I think it was around 3.4.1.
However, when I upgraded to 3.4, various other problems occurred, so I can't clearly remember whether this problem was there at the time and I didn't notice it, or whether it started occurring when I upgraded to 3.4.3.

David_Lindsey

OP, what version of Pro did you upgrade from when you jumped to 3.4.3?

danretired

GraduatedColorsRenderer—ArcGIS Pro | Documentation

which leaves the lower bound statement

(Read and Write)
A double that represents the minimum value of the symbolized classificationField to be displayed.

Note:
The value of the lowerBound should only be set to a value within the range of the first class break, otherwise it will fail. The maximum value gets modified in the last class break by changing the upperBound property.

-_-

Removing aprx.save() doesn't change the result.

danretired

Do the classes stay in place is you drop the aprx.save()?

The code examples in the help use aprx.saveas or there is no saving.

Připojte se k diskusi

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.