Latest Contributions by NathanaelVaughan

I apologize in advance - I don't post code much (also note that it is an old application and thus is not written with AMD-style references). The premise for my fix is that the built-in zoom functions work well - the problem manifests when using a secondary function to zoom by a large degree. In my case, zooming to a selected feature/graphic. This function is an intermediate tool that uses map.centerAndZoom to zoom to the indicated extent, but only if the extent is within a zoom threshold, otherwise, it will still center the extent, but only take the level down 3 more levels (I know this part is arbitrary). If you wanted to do a REALLY good job, you would put an interval object in to zoom partially, wait a second, and then zoom again until reaching the full-zoom. My application didn't require that much zooming though. function zoomThrottle (myFeatureExtent) {   // limits the change in level to prevent zoom animation menory leak problems   var zoomFactorX = (map.extent.xmax - map.extent.xmin)/(myFeatureExtent.xmax - myFeatureExtent.xmin);   var zoomFactorY = (map.extent.ymax - map.extent.ymin)/(myFeatureExtent.ymax - myFeatureExtent.ymin);   var newCenterPoint = new esri.geometry.Point((myFeatureExtent.xmin + myFeatureExtent.xmax)/2, (myFeatureExtent.ymin + myFeatureExtent.ymax)/2, new esri.SpatialReference({wkid: myFeatureExtent.spatialReference.wkid}))   var newScaleFactor = 0;   if (zoomFactorX > zoomFactorY) {   newScaleFactor = map.getScale()/zoomFactorX;   } else {   newScaleFactor = map.getScale()/zoomFactorY;   }   var newLevel = lods[lods.length-1].level;   for (var ii = 0; ii < boundingLods.length; ii ++) {   if (newScaleFactor < boundingLods[ii].ceiling && newScaleFactor > boundingLods[ii].floor) {   newLevel = boundingLods[ii].level;   break;   }   }   // lookup level   var scaleFactorCeiling = 100;   if (lods[map.getLevel()].scale/lods[newLevel].scale > scaleFactorCeiling) {   newLevel = map.getLevel() + 3;   }   map.centerAndZoom(newCenterPoint, newLevel);    } ... View more

I have experienced the issue in separate applications running API v. 3.5 and 3.12. Based upon this, I would expect the issue to be present in all releases of the API >v 3.5 (if not all).  I wrote a zoomThrottle function to limit the amount of zooming that could be generated in a single action - I set the zoom scale threshold at 100x and everything is working appropriately. I did not experiment extensively to see how much I could "push" the threshold prior to failure, although the zoom appears to be close to breaking at my current threshold (it pauses just long enough to make me think it has failed and then completes). The function is fairly unique to my setup, otherwise I would share it. If you are concerned about the speed of an official fix, I suggest adopting a similar approach. ... View more

No dice for my applications. I have a version using an older version of the api and another using 3.12 (also not current) and get the same "seizing" behavior on both. Clearly it works in the jsFiddle though. Since it appears to be associated with "rapid" zooms, I'll probably write an intermediate function to zoom incrementally based upon some trial-and-error sensitivity testing. Anyone have a better idea? ... View more

This is wonderful and elegant in Chrome, but does not work in IE - anyone have another suggestion for IE? I attmpted to set the "glow" attribute, but haven't had any luck so far. ... View more

As with most things in my life, understanding why something doesn't work doesn't mean you can't find the solution. When I reference the esri-hosted files, the page loads without a problem (version 3.11 and 3.12). When I reference the locally hosted version, I get the weird error. On a side note, I wrote a little python script to access the draw.js file that is causing the problems and when I run it on a computer which swaps in the asterisks, *surprise* python doesn't see asterisks. This leads me to believe it's some stupid browser/AV security issue (and specific to my "locally" hosted draw.js file). Behavior is the same for locally hosted v 3.10, 3.12 Thanks for the help. ... View more

It's been awhile, but based upon feedback from others with similar configurations, I opted to abandon the ESRI pdf export function and write something from scratch. I opted to download individual export images from each service requested, manually apply transparency to each individual image and then overlay them into a single, composite image (this was necessary as the PDF library I used did not support real image transparency). With that image, I created a PDF canvas using ReportLabs and decorated the remainder of the page with elements drawn via code, such as a scale bar and over view map. Ultimately, I modified the routine to read an MXD print layout similar to the original ESRI function. Most of the formatting options available for objects in the print layout are not exposed via the python API, so I had to add some functions to parse object names to look for formatting tags which the user must insert. Since the code uses the ESRI export function for image exporting, this at least allowed for a single MXD to be used to format both output types. I also added a GDAL/OGR function to clip any polygon graphics to the view extent. There are other kinds of graphics out there, but not currently in the client webviewer. Without this function, some graphics would be drawn outside the extents of the map window. The final element added was a download time limit in the image download routine. One server in particular tends to "hang up" and was slowing down the pdf generation due to long export generation/transfer times. I addressed this by reducing the sampling density (dpi) for the image export and adding a timeout function in the parallel downloads using Greenlet/eventlet. When nothing is returned by the end of the timeout period, the script continues without the delayed image. PDF generation times on the server went from 1.5-2 minutes to about 20-30 seconds. The script is around 900 lines, so I don't recommend undertaking something like this lightly (and my implementation is specific to the target application). ... View more

I've gone "medieval" on the problem in a sense. I went ahead and wrote my own custom (based on the ESRI example) print service and added logging at each major step. From there, it was apparent that my biggest bottleneck was in the PDF (or whatever other format) export. Times up to that point were on the order of 1 or 2 seconds and I would routinely see times of 20 seconds in the export. I could handle 20 seconds for an 8.5x11 plot. Upon publishing to the ArcGIS server instance, my plot times went up to roughly 2 minutes. With the log file, I was able to get the JSON export to see if I could isolate the lag to the server. When the script is run from a workstation (and not high powered workstation), performance is much improved. So I moved on to inspecting the server conifguration - which is something of a black box. Looking at performance monitoring, there are two distinct "spikes" in activity for each print job with a fairly consistent lag between. The first spike appears to be associated with processing the webmap data, while the second is associated with the export process. RAM appears to be spiking (I can't tell if file paging is being invoked, which would be a performance killer). I'm going to try to request some additional RAM on the server and see what that does for performance. CPU performance on the server peaks around 50% (2 CPUs), but the RAM usage is definitely a concern. Thanks for the help and tips - hopefully all of this is useful for others. I will update if I can get some more RAM allocated. EDIT: I should probably have mentioned that there are two ArcGIS server nodes in play here - one is outside of my control and is used for a couple of serivces. Everything else (print service, dynamic and cached map services) are run off of one server. Baseline load is pretty low. ... View more

Print, in general, is a very slow operation because it has to be done serverside.  I customized my own printing, and it is still quite slow. Do you have any thoughts on improving consistency? What I am struggling with is the huge amount of variability in times for the same screen capture. If I could identify a process, maybe I could prioritize it in windows? I'm toying with the CSS concept mentioned in another post and simply printing using the browser function for an assumed paper size. There's a 3rd party software called "Geocortex" that has a REST print server that is much more efficient, but I have no idea what is behind it. ... View more

You need to set your proxy server in code a la: esri.config.defaults.io.proxyUrl = 'http://..../proxy.ashx'; If you don't have a proxy set up on your webserver, you need to add one. There are instructions here: https://developers.arcgis.com/javascript/jshelp/ags_proxy.html - this may take some trial and error on your part if you haven't set one up before. Google for help testing. This is pre-AMD code, but hopefully it helps - it won't tell you how to solve your proxy issues (which are essentially network related), but it is an example of dynamically pulling the options. There are two selections: export options (png, jpg, pdf, etc.) and layouts. Hopefully it helps. printRequest = esri.request({                               url: "http://.../rest/services/Geoprocessing/WebMapPDF/GPServer/Export%20Web%20Map",                               content: { f: "json" },                               callbackParamName: "callback",                               handleAs: "json"//,                           });                           printTypes = new Array();                           layoutTypes = new Array();                           printRequest.then(                               function (response, input) {                                   // load printType list                                   //printTypes, layoutTypes                                   for (var i = 0; i < response.parameters[2].choiceList.length; i++) {                                       printTypes.push(                                           {                                               label: response.parameters[2].choiceList,                                               value: response.parameters[2].choiceList                                           });                                   }                                   // load printLayout list                                   for (var i = 0; i < response.parameters[3].choiceList.length - 1; i++) { // use length -1 to omit "MAP_ONLY" option                                       // Build normal name of print option                                       layoutName = response.parameters[3].choiceList;                                       layoutTypes.push({ label: layoutName, value: response.parameters[3].choiceList });                                   }                                   select = dojo.byId("printExportType");                                   if (dojo.byId("printButton") == undefined || dojo.byId("printButton") == null) {                                       select = new dijit.form.Select(                                           {                                               id: "printExportType",                                               //name: "printExportType",                                               options: printTypes,                                               value: printTypes[0].value,                                               onChange: function () {                                                   printTemplate.format = dijit.byId("printExportType").get("value");                                                   dojo.byId("printButton").textContent = "Generate " + dijit.byId("printExportType").get("value");                                               }                                           });                                       dojo.place(select.domNode, dojo.byId("toolInput"), "last");                                       // Create combo button to select template                                       select = new dijit.form.Select(                                           {                                               id: "printLayoutTemplate",                                               name: "printLayoutTemplate",                                               options: layoutTypes,                                               value: layoutTypes[1].value,                                               onChange: function () {                                                   printTemplate.layout = dijit.byId("printLayoutTemplate").get("value");                                               }                                           }); ... View more

The viewer projection is: Spatial Reference: 3483 The service projection is: Spatial Reference: 102100 (3857). I don't expect this to be the problem as the projected features in the map would match the "misprojected" features from the parcel search (see the image in the original post). Unless the projection is handled differently between the two uses. ... View more

I modified the map settings to display the parcels at loading: Prints Okay w/ no visible layer adjustment Does not print parcels and layer visibility is modified Prints parcels and layer visibility is modified I read the response thoroughly enough to figure out the meaning. The problem is caused by the reference to the Group Layer when setting the visible layers. I have group layer 0 set to display which contains layers 1, 2, and 3. If I specify to display 0, 1, 2, and 3, the plot and display match. If I specify only the group layer, 0, the display shows 0, 1, 2, and 3, but the plot does not. Thanks for the help. I've posted three versions of the fiddle above with no visible layer modification, visible layer modification which prevents plotting, and visible layer modification that allows printing. ... View more