3.2 And ArcGISTiledMapServiceLayer MinimumResolution Property

[LanceCrumbliss]

In 3.1, an ArcGISTiledMapServiceLayer with MinimumResolution set to 0 in a Map with SnapToLevels set to False allowed the map to zoom in past the highest ArcGISTiledMapServiceLayer LOD and still show the ArcGISTiledMapServiceLayer, albeit somewhat blurred of course.  However, in 3.2 the ArcGISTiledMapServiceLayer disappears after zooming in past the highest LOD.  This only occurred after upgrading to 3.2. Nothing changed in the code.  Any ideas?

Lance

[SebastienPelletier]

We seem to have a similair problem here
can anyone at ESRI confirm this is a bug and if so, suggest a workaround?

https://community.esri.com/message/92454#92454

[LanceCrumbliss]

I can't believe no one from ESRI has commented or suggested a work around.  3.2 is a non-starter for us and others with this bug.

[deleted-user-Jie3eyjOl9XM]

Same issue here, also detailed on the related thread. Seems like a genuine defect in the API that we need ESRI to get fixed.

[deleted-user-Jie3eyjOl9XM]

I created a workaround. I'm not proud of it. But, it works. Given an extent, this function will return the smallest extent that is greater than the minimum resolution. "Greater Than" actually needs a tolerance, because due to this defect, even a resolution that's a tiny bit greater will cause the layer to disappear. That's why I multiply by 10,000 and then compare.

private static Envelope CorrectExtent(Map map, Envelope extent)
{
     int comparisonFactor = 10000;
     double resolution = extent.Width / map.ActualWidth;
     while (Math.Floor(resolution * comparisonFactor) <= Math.Floor(map.MinimumResolution * comparisonFactor))
     {
          extent = extent.Expand(1.1);
          resolution = extent.Width / map.ActualWidth;
     }
     return extent;
}

Perhaps there's somebody smarter than me that can comment on this question. How will this function work if the coordinate system changes? I wrote this for some data in State Plane, but will the factor need to change if the data is in web mercator? What about map units in feet or meters?

[SebastienPelletier]

The best workaround is to use ArcGIS Server Manager and delete the values ​​Min and Max scale of your service.

You can not do this with ArcCatalog but with the manager yes.

Thereafter API responds correctly

[deleted-user-Jie3eyjOl9XM]

Excellent, Sebastien Pelletier. That works perfectly. But, the effect of changing those values seems very strange.

1) On one map, my original problem, I've got tiled layers are cached down to 1000, and if the Max Scale is set to 1000, the layers disappear at 1000. I should mention that using the JSAPI, nothing disappears, using the same services.

2) Using your fix, I've got tiled layers are cached down to 1000, and no Max Scale is set, so the layers zoom to 1000 and nothing disappears.

3) Meanwhile, on another map, I've got tiled layers that are cached down to 1000, but I set the Max Scale to 500 on all layers, allowing me to zoom closer and blur the tiles. No layers disappear.

It just doesn't make sense. Why would #1 fail, but #3 work???

[deleted-user-Jie3eyjOl9XM]

I believe that this Silverlight 3.2 defect only affects basemaps that are not web mercator. I've got a map that uses default projections, and the layers do not disappear when the map scale equals the service's maximum scale.

[dotMorten_esri]

This change was by design. It was a bug that the service's scale range wasn't respected. Unfortunately there's currently not a way to override the default scale range for those who want to ignore the scale range and stretch the tiles. We'll address this in the upcoming update allowing you to override the service scale range and continue to stretch tiles beyond the scale range.

[deleted-user-Jie3eyjOl9XM]

Thank you, Morten. It's good to know that the developers are aware of this issue.

Like Ryan Coodey‌ our Support issue was assigned to a Nimbus bug, but it was a different, existing one (NIM100435). That bug is a very similar a 3.2 regression -- limited to non-web mercator projections. And, there's another issues remaining since 3.1 with non-web mercator projections where the IsInScale() is broken for the legend.

So, to summarize the four perhaps related issues:

1) This issue, about tiles no longer stretching when Zoomed beyond the Max Scale (see NIM104466)

2) ZoomToExtent should not be allowed to zoom beyond the Max Scale (see NIM100435)

3) Zooming TO the Max Scale (not beyond) shouldn't cause the layer to disappear (see Custom base map minimum scale fails to load in version 3.2‌)

4) IsInScaleRange() for the legend is broken (see IsInScaleRange not working in Legend‌)

For our services, which are State Plane, I've applied the workaround (remove Max Scale from service), which resolved #1, #2, and #3, but not #4.

So, I can certainly understand that the change is by design. But I'm hoping that the upcoming fix will apply to the whole range of scale-related issues with other projections.

[RyanCoodey]

Morten beat me to it but to add a little more info, after talking with support for a few weeks about this we got a ticket assigned (NIM104466: ArcGISTiledLayer does not display data when zooming in beyond the minimum resolution defined by the service)

With this response:

"The change that was introduced was to honor the visible scale range as defined by the service. Currently the only way to handle this is by changing the settings on the service. We understand that this not a workable solution for many customers. I just got out of a meeting with Product Management and they are aware of this and the current plan is to target this for the 10.2.4 release of the WPF SDK that we should see later this year."

They also mentioned there was no gurantee we would see it in 10.2.4, but that is their current goal.

Thanks a lot ESRI for addressing this issue for us! It is much appriciated.