Issue with JS 4.19 Label deconflictionStrategy

160
5
Jump to solution
3 weeks ago
TonyUrquidi1
New Contributor II

I'm running into an issue with deconflictionStrategy not working as expected for FeatureLayers that use collection source for their data instead of a url.

At version 4.18, when I set the deconflictionStrategy to 'none', needed for FeatureReduction, on FeatureLayers from a collection,  labels for layers that were below that layer were removed so they didn't overlap. Other layers in the map have the default deconflictionStrategy of 'static'.

At 4.19 and above, the labels are now covering this feature layer. 

Below codepens are the same except for the version number


Codepen for 4.18, where it was working as expected: https://codepen.io/alexurq/pen/JjJwGEX
Codepen for 4.19 where it isn't: https://codepen.io/alexurq/pen/OJgrMbQ

Is there any addtional property that needs to be set prevent the overlaping of the labels?

0 Kudos
1 Solution

Accepted Solutions
mgeorge
Esri Contributor
5 Replies
mgeorge
Esri Contributor

Hi Tony, the behavior for deconflictionStrategy in 4.19 affecting the collision of other layers wasn't the intended behavior... the intended behavior is that it was supposed to be "removed" from the collision detection all-together and always show labels, but you bring up a good point, and I can see the use case.

Are you able to avoid using deconflictionStrategy=none for featureReduction? Are you using it because you have a bunch of clusters that are close to each other?

E.g., can you do this: https://codepen.io/matt9222/pen/Rwgvwjw?editors=1000

PS: In 4.20/4.21 we discovered an issue with the ordering of collisions with respect to multiple layers and are working on a fix for that now.

0 Kudos
TonyUrquidi1
New Contributor II

We are using featureReduction to display clusters of records that are close together and provide a label on the cluster itself. When the clusters are too close together, some clusters are not labeled.

Since setting the deconflictionStrategy to none completly removes them from collision detection, the behavior we saw in 4.18 was not intended. Any way to submit a request to get it to function as in 4.18?

 

Any timeline when the 4.20/4.21 ordering of collisions bug would get fixed?

0 Kudos
mgeorge
Esri Contributor
TonyUrquidi1
New Contributor II

Awesome!! Looks good, thanks for the quick turnaround. 

mgeorge
Esri Contributor

No problem! As for deconflictionStrategy, we're trying to sync up with the rest of the platform on this, so depending on that investigation it may or may not behave as it does in 4.19 or 4.21. I completely see the usefulness of the 4.19 behavior though and will try and see if we can get back to this in some way (worst case hopefully via some slightly different API).

0 Kudos