API 3.3: BaseMapGallery issue

1962
8
01-24-2013 06:34 AM
MattLane
Occasional Contributor II
I'm getting an issue with the BaseMapGallery after updating to 3.3. Specifically, after switching from an initially loaded basemap to another one, zooming in fails for the new basemap. This can be recreated on the sample at:
http://help.arcgis.com/en/webapi/javascript/arcgis/samples/widget_basemapManual/index.html

Switch to the Public Safety basemap and then zoom in. The transition from level 6 to 7 and on doesn't fetch new tiles, but shows the old in an odd way. I suspect there is an issue with the widget when loading multiple cached services that have a different number of scales.

In that sample, the initial basemap (Water Template) only has 13 scales, but the Public Safety that you switch to has 17.
0 Kudos
8 Replies
MattLane
Occasional Contributor II
Forgot to mention. Tested in Chrome 24, IE 9 (and 8).
0 Kudos
PavelKornilov
New Contributor
Also similar issue with http://help.arcgis.com/en/webapi/javascript/arcgis/samples/map_customtilelevels/index.html sample.
Though it has only one basemap.
0 Kudos
ManojrajTeli
Occasional Contributor II
Hello Pavel Kornilov,

I have gone through the example and the problem is lod not the API 3.3 .I have taken the example and commented the lod and the application is working fine.Only problem is lods. you can check this http://jsfiddle.net/U8VxC/. for the example you have mention.
0 Kudos
ManojrajTeli
Occasional Contributor II
Hello Matt Lane ,

I don't see any lods or the proper init function could you share your code so i can test on my end Or could you redirect me that ESRI article.

Thanks
Manojraj Teli
0 Kudos
ManojrajTeli
Occasional Contributor II
Hello Matt Lane ,


I believe both the layer configuration are different and you are right watershedlayer is configured for 13 levels [0-12] and publicSafetyLayer is configured 17 levels [0-16].So i guess one one layer exceed another layers level gives the problem.check the service layers where the level information is elaborated.
0 Kudos
PavelKornilov
New Contributor
Hello Pavel Kornilov,

I have gone through the example and the problem is lod not the API 3.3 .I have taken the example and commented the lod and the application is working fine.Only problem is lods. you can check this http://jsfiddle.net/U8VxC/. for the example you have mention.


Thanks, manojrajteli.

But the same code was working correctly in previous versions of jsapi (at last 3.2). And I need to determinate specific array of lods (like in sample) - not all of them. The problem with lods occurs in 3.3 only.
Look at my topic there: http://forums.arcgis.com/threads/75865-Visible-scales-example-bug

Sincerely,
Pavel Kornilov
0 Kudos
MattLane
Occasional Contributor II
Also similar issue with http://help.arcgis.com/en/webapi/javascript/arcgis/samples/map_customtilelevels/index.html sample.
Though it has only one basemap.

Hey Pavel, that is odd, and the LODS in the sample match LODS on the service it's using.
Hello Matt Lane ,


I believe both the layer configuration are different and you are right watershedlayer is configured for 13 levels [0-12] and publicSafetyLayer is configured 17 levels [0-16].So i guess one one layer exceed another layers level gives the problem.check the service layers where the level information is elaborated.

It certainly seems to be an issue between two different numbers of LODs. Reversing the order of the basemaps in the digit doesn't affect the bug.

Does not happen in 3.2.
0 Kudos
JeffJacobson
Occasional Contributor III
I have created a sample that demonstrates the bug.


  1. When the page opens, it will be zoomed to the extent of WA.

  2. Select the WSDOT Basemap from the Basemap Gallery.  When you do this, the wrong tiles are used.

  3. If you switch to one of the other basemaps, the map displays properly again.

0 Kudos