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
Is there any addtional property that needs to be set prevent the overlaping of the labels?
Solved! Go to Solution.
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.
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?
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).