AGSJS Symbology Issues

Question

Hello!  We are using the AGSJS widget for legends on several ArcGIS JSAPI solutions and really like it!

I sometimes see strange behavior though related to the symbology on polygon layers not being correct.  On one server the issue is "intermittent" and seems to occur across browsers, whereas on another server (which should have a duplicate code base) the issue always occurs.

See the screen shot.  The image on the left represents the appropriate symbology from this map service. The one on the right is the odd behavior that we see sometimes.  It especially affects the hatching patters as you'll note.

Has anyone seen this before?  Thanks!

KevinMacLeod1 · Answer

An issue I see with legend symbology in AGS JS TOC is it does not work in IE for secured services.  We a service on ArcGIS Server 10.0 coming in to the JS API 3.3 viewer with newest AGS JS TOC widget code and see this. I called ESRI, they know about it, it has a NIM. It's something about how IE can't get bitmaps as pieces of text or something obscure, I forget.  But it works in all other browsers.  Just wondering if anyone found a way around this IE bug?   Perhaps it will work if we put the service on Server 10.1 with the legend features?  Although we'll be on 10.0 for a while.

Nianwei thank you again, your code and the documentation are great.  I would love to see ESRI officially include your AGS JS TOC widget into the API!!

GregConiglio · Answer

Not positive what exactly cause this (could be a racing situation), but the left side's symbol is rendered on server (result of a legend operation), and right side symbol is rendered on client by dojo using the renderer information of the layer.

Server symbol should be used whenever possible because they are more faithfully representing the mxd than browser renderered. However, there are certain cases the client symbols are used either because server symbol not returned in an async request queue, or not available.

It is possible to force the order of /layers/ and /legend/ call in the TOC code, but it could get messy when trying to handle older version of AGS server when /legend/ operation is not possible and need to use arcgis.com's SOAP utility. And that's not the good solution anyway. It should be solved at REST API level. The /legend/ and /layers/ operations have many redundancy and overlapping, and not consistent even for server symbol rendering. I have a few bugs reported and enhancement for the REST API to combine legend and layers operation for several years, but nothing has happened yet.

Thanks for your response!!  That is interesting that the rendering is being done differently on the two servers.  The code is theoretically the same on each server.  I can try and verify that.  What do you mean by racing situation?  Is there something we can do about that? Is there something else I can try?  This is so strange when the code is the same.  It was basically copied from one serer (the one working) to the next (not working) and just had the URL updated....

NianweiLiu · Answer

Oops!  Here it is sorry!

Not positive what exactly cause this (could be a racing situation), but the left side's symbol is rendered on server (result of a legend operation), and right side symbol is rendered on client by dojo using the renderer information of the layer.

Server symbol should be used whenever possible because they are more faithfully representing the mxd than browser renderered. However, there are certain cases the client symbols are used either because server symbol not returned in an async request queue, or not available.

It is possible to force the order of /layers/ and /legend/ call in the TOC code, but it could get messy when trying to handle older version of AGS server when /legend/ operation is not possible and need to use arcgis.com's SOAP utility. And that's not the good solution anyway. It should be solved at REST API level. The /legend/ and /layers/ operations have many redundancy and overlapping, and not consistent even for server symbol rendering. I have a few bugs reported and enhancement for the REST API to combine legend and layers operation for several years, but nothing has happened yet.