Using the code below, if I set minScale = 500000 and maxScale = 200, the results look correct and effectiveLODs fall within the expected range. But when I change maxScale to 50, it flips and I get:
effectiveMinScale: 591,657,528
effectiveMaxScale: 288,895
I expected effectiveLODs to remain between 50–500,000. Is this expected, why does setting maxScale below the finest LOD cause the effective min/max/LODs to jump this way?
The LOD level is 22 at 141 scale so the effective max scale will not go past 141. If the requested maxScale is finer then the LOD then replace it with the lowest possible without going out of bounds. It also seemed to want to fight the inputs as they changed, I think it is because you are setting the constraints separately, so I set them at the same time instead.
let finestAvailableScale = 0;
const applyScaleInputs = () => {
if (!view) return;
const requestedMax =
toNumber(maxScaleInput.value);
const safeMax =
(finestAvailableScale > 0 &&
requestedMax > 0 &&
requestedMax < finestAvailableScale)
? finestAvailableScale
: requestedMax;
view.constraints = {
...view.constraints,
minScale: toNumber(minScaleInput.value),
maxScale: safeMax,
};
renderOutputs();
};
mapElement.addEventListener(
"arcgisViewReadyChange", () => {
view = mapElement.view;
const initLODs =
view.constraints.effectiveLODs;
if (initLODs?.length) {
finestAvailableScale =
Math.min(...initLODs.map(
l => l.scale));
}
minScaleInput.value = String(
view.constraints.minScale ?? 0);
maxScaleInput.value = String(
view.constraints.maxScale ?? 0);
view.watch(...);
renderOutputs();
});
Thanks Matthew, the workaround seems to be working.
But I’m wondering if this is the expected behavior? When I set maxScale = 50 (finer than the most detailed LOD), I’d expect the effective max scale to clamp to the layer’s finest scale (~70.5) and the effective LODs to include all levels from that min scale up to that finest scale. Instead, the SDK jumps to an effective max range of 288,895 - 591,657,528. That seems like a bug in how the constraints are being resolved internally.
Would the underlying issue be fixed in a future release?
Thanks again.
In my opinion it is not expected behavior. Worth reporting.