Problemen met de printwidget: imageryservices en dynamische services met labels worden niet afgedrukt

se2539

Ik heb twee problemen die enigszins met elkaar verband lijken te houden, omdat ze allebei te maken hebben met de standaardprintwidgets in de GUI-versie van Web AppBuilder en in ArcGIS Online.   

Probleem 1). Ik kan geen van mijn intern gehoste imageryservices afdrukken.  Mijn organisatie heeft 6 extern toegankelijke imageryservices; geen van deze services wordt weergegeven wanneer je de printfunctie in de AGOL-kaart of de printwidget in WAB Builder gebruikt.  Dit maakt niet uit of ik de service als laag of als basiskaart heb toegevoegd.  In de uitvoer worden alleen de andere objecten op de kaart weergegeven, bijvoorbeeld andere services/lagen en/of een andere basiskaart (indien van toepassing).  Het is interessant dat de credits van onze organisatie in de benedenhoek van de afdruk verschijnen (samen met de credits voor Esri, HERE, Garmin enz.), maar de beelden zelf ontbreken.

Ik heb onderzoek gedaan en een paar dingen geprobeerd om dit probleem op te lossen.  Ik kwam een technisch ondersteuningsartikel van ESRI tegen waarin stond dat ik de maximale X,Y-pixellimiet voor de imageryservice moest controleren.  Het artikel beschrijft echter niet hoe je dat doet ... bij de service-eigenschappen?  Ergens anders?  Ik heb geëxperimenteerd met de pixelgrootte van de uitvoerkaart, aangezien de standaardinstelling 670x500 px is met een DPI van 96.  Ik heb dit gewijzigd in een piepkleine 10 x 10, maar kreeg nog steeds een uitvoerkaart zonder de beelden.  

Een andere instelling die ik heb aangepast, is de maximale heapgrootte van de SOC; ik heb deze gewijzigd van de standaardwaarde van 64 MB naar 256 MB, zodat die overeenkomt met de limiet van de applicatieserver.  Geen effect.  Ook niet toen ik probeerde de uitvoer van 10x10 pixels af te drukken.  Ik denk niet dat dit de oplossing is.  Het is overigens interessant dat er geen aanbevolen limiet lijkt te zijn voor de maximale heapgrootte ... 

Probleem 2).  Ik lijk ook problemen te hebben met het afdrukken van intern gehoste dynamische kaartservices met ingeschakelde labels.  Als een label voor een laag is ingeschakeld, verschijnt in de afdrukuitvoer alleen het label.  Als er geen label is, wordt het object wel goed weergegeven.  Dit gebeurt zowel bij niet-beveiligde als bij beveiligde services.  Ik heb toegegeven nog niet veel onderzoek naar dit probleem gedaan (het is pas gisteren onder mijn aandacht gebracht), maar ik kon nergens anders informatie vinden over dit specifieke probleem ... dus ik weet eerlijk gezegd niet waar ik moet beginnen ... 

se2539

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.