Map Lockup After Zoom

[MatthewLawton]

I have a highly customized JS API app that I created a couple years ago and have upgraded along the way and is currently running on version 2.8. I have recently found a very annoying bug. I'm not sure when this bug popped up, but I don't think it was always there. I noticed that when I perform a query, which includes a zoom to extent once the target feature is found, my map locks up. More specifically, the coordinate readout on my map will not update and any overlaying map services will not update, they just remain pixelated on top of my basemap. If I attempt to click on the map to do an identify then the identify hangs the first time, however if I click the map a second time then the identify is successful. If I pan the map then the coordinate readout refreshes and the overlaying map services draw correctly. So this bug only occurs immediately after a query is performed. If I run a query and the map only pans to a new target location without zooming then everything is fine. The lock only seems to occur if there is a zoom action performed when the setExtent function is called.

I am guessing that I must have some sort of listening action that is performed when zooming that is perhaps interfering with the query action which doesn't allow the map refresh to complete successfully. This is likely causing the coordinate extent to not update to the new map extent, therefore the coordinate readout lockups, and apparently it disables the map click listener so that the identify task will not execute properly.

The problem is that I cannot find anywhere in my code what the possible cause might be. I figured I would throw this out to the forum first to find out if this is a known bug or if anyone has encountered a similar problem. Sorry if this description is vague but I figured I would provide a high level explanation before diving into the details of the code. If anyone can provide some meaningful feedback then I would be much appreciative.

[StephenLead]

I am guessing that I must have some sort of listening action that is performed when zooming that is perhaps interfering with the query action which doesn't allow the map refresh to complete successfully. This is likely causing the coordinate extent to not update to the new map extent, therefore the coordinate readout lockups, and apparently it disables the map click listener so that the identify task will not execute properly.

Hi Matthew,

That sounds like a reasonable assumption. Are you able to link to a working version of your code so we can test it?

You mentioned that you upgraded from previous versions of the API - what happens if you revert the API to version 2.6, 2.5, etc?

Cheers,
Steve

[MatthewLawton]

Hi Steve,

Thanks for the response. I mis-typed in my original post. I am actually running on a locally hosted version of the 2.6 API. I did run a test pointing back to all versions down to 2.0 and the same bug still appears in my application. There must be some small change that I made to my code at some point that caused this bug to appear.

You can see it in action on our Washoe County Quick Map application here:
http://wcgisweb.washoecounty.us:8888/QuickMap/

If you type an address (it will autocomplete an address for you as you type) and click 'Search' to perform the query, you will notice after zooming to that property that the coordinate readout in the lower right is frozen. If you click the map to perform an identify on a property then the results pane on the left just hangs at the "Searching..." animation. If you pan or zoom the map or click the map again then this seems to clear the bug.

The bug is even more noticeable on our foreclosure application here:
http://wcgisweb.washoecounty.us:8888/Foreclosures/

This application is built from the same template and all the same symptoms apply. In addition, notice that the foreclosure overlay, which is a separate map service draped over the basemap, does not update after the query. It remains at the zoomed out scale and appears pixelated on the basemap. If you pan or zoom the map then it will properly reset.

I guess I need to review my code with a fine toothed comb to find out what is going on here. Any ideas you may have are greatly appreciated.

[StephenLead]

I guess I need to review my code with a fine toothed comb to find out what is going on here. Any ideas you may have are greatly appreciated.

I'm happy to take a look when time permits. In the meanwhile, start combing.... and good luck!

[JeffPace]

I tried the foreclosure one.  I get a 404 on

http://wcgisweb.washoecounty.us:8888/ArcGIS/rest/services/ForeclosuresWebMercator/MapServer/export?d...

when i zoom to an address that is causing the hang. It is a result of the
bboxSR=null&imageSR=null
parameters in the url.  If you remove them or set them properly it works.

[MatthewLawton]

Hey Jeff, what would be causing that? They should be set to 102100 (Web Mercator).

[JeffPace · Accepted solution]

for one, that service is 102113, not 102100

odd

and secondly,

according to the imageParameters when creating a ArcGISDynamicMapServiceLayer, you could try to specify the exportimageformat and SR

http://help.arcgis.com/EN/webapi/javascript/arcgis/help/jsapi/imageparameters.htm

so likely its is on your new esri.layers.ArcGISDynamicMapServiceLayer call.

And for some reason i remember having the same issue about the 1.6 to 2.0 api change.

[MatthewLawton]

This is interesting, but if this was really the root of my problem then wouldn't the overlaying map service not display at all? Why would it only lock up after zooming in after a query? Panning and zooming the map service is otherwise not a problem. Also, the first application doesn't have the overlaying map service, yet it contains the same bug.

I'm currently reviewing my identify parameters. I think there could be a problem with the map.extent variable getting improperly set after a query is performed. I feed my query directly into an identifyTask to return the property results. It is set up slightly differently than the identifyTask that runs when the map is clicked by the user although they perform the same basic purpose.

There is a listener for an extent change that updates an extent box to State Plane using the geometry service. This is how the coordinates get displayed in both lat/lon and State Plane. I am concerned that there could be some global extent variables that are stepping on each other when the query is performed.

I will let you know if I find anything.

[MatthewLawton]

I removed all of the coordinate display components and the extent recalculation functions from the app and I am still getting the same bug. So I think I can conclude that the extent probably doesn't have anything to do with it.

I'm really at a loss on this one.

Jeff, I did migrate from the 1.6 to the 2.x API earlier this year, so it is quite possible that the bug could be related to that migration and I just didn't notice it right away. I've reviewed your posting a couple of times and read through the image parameter page that you linked and I just can't see where I need to make an adjustment in my code if that is indeed the source of the problem. I am not directly requesting images from my services, they are being published to the map container that has been declared as follows:

  //Set initial extent and map projection to Web Mercator
  var initExtent = new esri.geometry.Extent(-13373700,4775288,-13310356,4828576, new esri.SpatialReference({wkid:102100}));
  
  //Set the map variable and assign it to the mapDiv box
  map = new esri.Map("mapDiv",{extent: initExtent, slider: true, nav: true });

I have loaded the following basemaps:

  //connects to Washoe County base layer service
  BaseLayersCarto = new esri.layers.ArcGISTiledMapServiceLayer("http://" + hostName + "/ArcGIS/rest/services/BaseLayersWebMercator/MapServer");

  //connects to Washoe County aerial photography service
  ImageryLayers2 = new esri.layers.ArcGISTiledMapServiceLayer("http://" + hostName + "/ArcGIS/rest/services/ImageryWebMercator/MapServer", {visible:false});
  
  //connects to Washoe County hillshade and topography service
  Topo = new esri.layers.ArcGISTiledMapServiceLayer("http://" + hostName + "/ArcGIS/rest/services/TopoWebMercator/MapServer", {visible:false});
  
  //connects to Washoe County base layer service for draping over photography
  BaseLayersPhoto = new esri.layers.ArcGISTiledMapServiceLayer("http://" + hostName + "/ArcGIS/rest/services/BaseLayersTransparentWebMercator/MapServer", {visible:false});
  
  //World base maps
  WorldStreets = new esri.layers.ArcGISTiledMapServiceLayer("http://services.arcgisonline.com/ArcGIS/rest/services/World_Street_Map/MapServer");
  WorldAerial = new esri.layers.ArcGISTiledMapServiceLayer("http://services.arcgisonline.com/ArcGIS/rest/services/World_Imagery/MapServer", {visible:false});
  WorldTopo = new esri.layers.ArcGISTiledMapServiceLayer("http://services.arcgisonline.com/ArcGIS/rest/services/USA_Topo_Maps/MapServer", {visible:false});

I'm pretty lost at this point. Any additional help would be much appreciated.

[MatthewLawton]

Holy Cow!!!

It was the extent. Apparently the spatial reference needed to be set in the identify parameters. Everything worked once I added this line of code:

  identifyParams.spatialReference = new esri.SpatialReference({ wkid: 102100});

Man, that was frustrating. Jeff, your response focused me on the extent and spatial reference. Have some points. Enjoy!