wrapAround180 bug

[JoelBennett]

I've found that the map's wrapAround180 behavior will fail under certain circumstances where it should not.  When instantiating a map with wrapAround180 set to true, and the lods option specified, the map will create an internal TileInfo object based on WGS 84 (4326).  However, if you add a tiled layer based on Web Mercator (which all of mine are), the map will make some internal comparisons between the Web Mercator spatial reference and WGS 84 spatial reference definitions, and conclude wrapping is no longer possible.

The problem therefore lies with the default TileInfo created by the map, over which the user has no documented control, and which is created whether or not you have any layers based on WGS 84.  There is a workaround though.  After instantiating your map, create a new TileInfo object based on Web Mercator, and make a couple assignments:

var map = new Map("map", options);

var tileInfo = new TileInfo({

  dpi: 96,

  height: 256,

  lods: options.lods,

  origin: new Point(-20037508.342787, 20037508.342787, new SpatialReference(102100)),

  spatialReference: new SpatialReference(102100),

  width: 256

});

map._params.tileInfo = tileInfo;

map.__tileInfo = tileInfo;

I'm currently using version 3.13.

[JoelBennett]

This still hasn't been fixed in 3.15.  I've attached a document illustrating what's happening.

It is this line in the _coremap module that's causing the problem:

if (!b || Math.abs(c.origin[0] - b.origin.x) > c.dx) this.wrapAround180 = !1;

The comparison between origin values of WGS 84 and Web Mercator results in wrapAround180 being forced to false.

[JoelBennett]

ESRI did not fix this bug in version 3.16 of the ArcGIS API for JavaScript.

[KenBuja]

Have you reported this bug to Esri apart from posting it here?

[JoelBennett]

No, I would only do that if there was no way around a bug.  More than once, I have reported bugs to ESRI the official way, along with how to fix them, but in vain.  I'm not willing to do that anymore.

My purpose here is to keep other developers who run into these problems informed that (1) the problems do exist, (2) it's not their fault, and (3) there are known workarounds.

[KenBuja]

Some of the bugs I've encountered have not been remedied, but that doesn't stop my from reporting ones that I come across. If a bug isn't made known, then it won't be fixed in future releases. Also, when I've called in a bug that turned out to be already identified, Esri support will usually suggest that adding additional reports about a bug will give it a higher priority.

[JoelBennett]

I've missed a few releases here, but found the workaround is still necessary in 3.24.  I've also found the problem only appears to manifest if the first layer added to the map is not a tiled layer (e.g. an ArcGISDynamicMapServiceLayer)...this is probably true of previous versions as well.

Our workflow is to add a locally hosted layer first, and then add ESRI basemaps afterwards so that startup isn't dependent on a third party service.  That first layer could be tiled or dynamic, depending on different circumstances, and the problem happens for the latter, but not the former.