Print widget issues: image services and dynamic services w/ labels not printing

2107
2
Jump to solution
07-17-2018 08:57 AM
Brownschuh
Occasional Contributor II

I have two issues that seem to be somewhat related in that the revolve around the default print widgets available in the GUI version of Web App Builder as well as in ArcGIS Online.   

Issue 1). I cannot print any of my internally hosted image services.  My organization has 6 externally facing image services; none of the services will appear if you try using the print functionality in the AGOL map or using the print widget in WAB builder.  This is regardless of whether I've placed the service as a layer or as a basemap.  The output will only show the other features in the map, eg. other services/layers and/or another basemap (if applicable).  Interestingly, the credits for our organization appear in the bottom corner of the print out (along w/ credits for Esri, HERE, Garmin, etc.) but the imagery fails to appear.

I've researched and tried a few things to fix this issue.  I stumbled upon an ESRI Technical Support article that mentioned to check the maximum X,Y pixel limit for the imagery service.  However, the article does not describe how this is done ... service properties?  Somewhere else?  I did experiment with output map pixel size, as the default it 670x500 px w/ a DPI of 96.  Changed it to a tiny 10 x 10 and was still left an output map sans the imagery.  

Another item I've tweaked is the SOC maximum heap size; changed it from the default 64MB to 256MB to match the application server limit.  No affect.  Even with attempting to print the 10x10 pixel output.  I'm thinking this might not be the remedy.  Although, it is interesting to note there doesn't seem to be a best practices limit to what this max heap size should be set to ... 

Issue 2).  I also seem to be having difficulty printing from internally hosted dynamic map services that have labels enabled.  When a label is enabled on a layer, only the label appears in the print output.  On the flip-side, if no label is present, the feature will appear just fine.  Note this is both with unsecured and secured services.  Admittedly, I have not done too much troubleshooting with this problem (it was just brought to my attention yesterday), however, I was unable to find any other sources out there describing this particular issue ... so I honestly don't know where to begin ... 

0 Kudos
1 Solution

Accepted Solutions
Brownschuh
Occasional Contributor II

Ok, think I've got a solution to issue #1.  It was due to the way our organization had originally created the source mosaic datasets that the image services were pointed to.  My hunch is that they were created 'incorrectly', or at least, not in the best practices manner.   

Our organization maintains a series of mosaic datasets for our various orthoimagery flights; they are all divvied up by year (eg. 1995, 2004, 2013, etc) then further divided into two types:  clipped to our city limits and the non-clipped mosaics (you know, the grid-like orthos that have boxy look which 'leaches' into surrounding counties outside the typical AOI).  For the creation of the non-clipped mosaic datasets, we simply pointed them to the source tile images and created the dataset.  But for the 'clipped' mosaics, we pointed the source imagery to the non-clipped mosaic dataset and manipulated the boundary to only show imagery within the city limits.  In other words a mosaic dataset was pointed to another mosaic dataset as its source imagery; probably not the best approach, but it seemed to work well until this print issue was discovered.  

After much trial and error I narrowed it down to these city limits clipped mosaics.  Every time I tried to create a new, test image service, it would fail during cache creation (ERROR 0001456: Failed to update tiles).  This error would only occur on these particular 'clipped' mosaics.  Unfortunately it was extremely difficult to narrow this issue down because all our image services were pointed to these city limits clipped mosaic datasets, so they were all uniformly incorrect.  Just took a lot of trail and error with sample/test datasets.   

Additionally, I am unsure how we were even able to create the original image services years ago given all of the difficult I encountered with testing.  But right now I am creating all of our source mosaic datasets and rebuilding the image services too.  Time-consuming, but at least it's being done right.

As for issue #2, still working on troubleshooting this problem.  Got an ESRI ticket open right now.

View solution in original post

0 Kudos
2 Replies
KellyGerrow
Esri Frequent Contributor

Are you using a local ArcGIS Server printing service or the print service that comes with ArcGIS Online. If using the ArcGIS Online print service and your internal layers are not exposed to the internet, the ArcGIS Online print service can't access your services. Adding a local print service for your organization should fix this.

Issue 2, I'm not too sure what is happening. I think getting in touch with support will be a good first step.

-Kelly  

0 Kudos
Brownschuh
Occasional Contributor II

Ok, think I've got a solution to issue #1.  It was due to the way our organization had originally created the source mosaic datasets that the image services were pointed to.  My hunch is that they were created 'incorrectly', or at least, not in the best practices manner.   

Our organization maintains a series of mosaic datasets for our various orthoimagery flights; they are all divvied up by year (eg. 1995, 2004, 2013, etc) then further divided into two types:  clipped to our city limits and the non-clipped mosaics (you know, the grid-like orthos that have boxy look which 'leaches' into surrounding counties outside the typical AOI).  For the creation of the non-clipped mosaic datasets, we simply pointed them to the source tile images and created the dataset.  But for the 'clipped' mosaics, we pointed the source imagery to the non-clipped mosaic dataset and manipulated the boundary to only show imagery within the city limits.  In other words a mosaic dataset was pointed to another mosaic dataset as its source imagery; probably not the best approach, but it seemed to work well until this print issue was discovered.  

After much trial and error I narrowed it down to these city limits clipped mosaics.  Every time I tried to create a new, test image service, it would fail during cache creation (ERROR 0001456: Failed to update tiles).  This error would only occur on these particular 'clipped' mosaics.  Unfortunately it was extremely difficult to narrow this issue down because all our image services were pointed to these city limits clipped mosaic datasets, so they were all uniformly incorrect.  Just took a lot of trail and error with sample/test datasets.   

Additionally, I am unsure how we were even able to create the original image services years ago given all of the difficult I encountered with testing.  But right now I am creating all of our source mosaic datasets and rebuilding the image services too.  Time-consuming, but at least it's being done right.

As for issue #2, still working on troubleshooting this problem.  Got an ESRI ticket open right now.

0 Kudos