Creating a Print Service for High-quality Web GIS Output

Clients with Web GIS projects commonly ask to include high-quality print output. It’s a challenging requirement because the browser is not natively a platform for high-quality printing (try thinking of a non-GIS website out there with such a feature). The latest print task in the ArcGIS Server Web ADF does reasonably good output, but clients familiar with ArcGIS Desktop layouts want something comparable in their websites.

Clients most often want PDF output for printing, and it’s possible to create PDFs in code using one of the many PDF generators out there. That option is certainly flexible. But the MXD-based ArcGIS layout offers other advantages. One key advantage is the ability for clients themselves to create and modify print templates. They can add and remove features like titles, north arrows, and scalebars. They can also rearrange and resize the elements in the layout.

The task is to employ the ArcGIS components (ArcObjects) for layouts in the context of a server-based application. A few efforts are out there already, such as the Layout Server Object Extension (SOE), available on the ArcGIS Server user-supplied Code Gallery/ArcScripts. This sample works with the ArcGIS Server .NET Web ADF. We’ve used that code successfully, but found some reasons to look for a different approach. Some clients claimed the Layout SOE impacted the overall performance of their website. More importantly, we needed a solution that would work for multiple platforms, such as the JavaScript and Flex APIs for ArcGIS Server. Those are client-side applications, which require an entirely different approach from a server-side component.

The obvious solution is a Web service, one that both browser clients and server-based applications could call. We developed such a Web service in the last few months through the efforts of several of our staff. The client application passes in parameters such as the map services to include on the layout, the map extent, the path of the MXD template to use, and the GIS server that will perform the export. The service then connects to the GIS server and uses ArcObjects to build the request for the layout export. The service passes the URL of the output file back to the client, which allows the user to download and display it. The output format can of course be any that ArcObjects supports, such as PDF, JPEG, PNG, EPS or SVG.

We were able to make the service flexible so that map services could be plugged into the layout template dynamically. In other words, the layers in the print were not pre-set in the map document (MXD), but instead were dynamically pulled in from one or more map services. At first we used “local” connections to the map server, but soon realized we needed to also print web service-based map services, such as ArcGIS Online services. We were able to implement the GIS client components (IAGSServerConnection and IMapServerLayer) to make the connection to the map services.

Another challenge was to add graphics dynamically onto the map. Graphics, such as user markup on the map, are implemented differently in each client API, and each of those is different from graphics in ArcObjects. We had to create our own structures for passing graphics to the print service, so that client applications could take their own graphic types and translate them to something our web service could use. In some cases the capabilities do not match across APIs, which causes some issues for applications. For instance, ArcObjects doesn’t support partial transparencies (e.g., alpha transparency) in polygon fills for graphics. So client applications could not add such graphics to the map and expect them to be reproduced in the exported layout.

Since we started using the service in client applications, we’ve had requests for enhancements, not surprisingly. We’ve added support for ArcGIS Image Services, the ability to update text elements on the layout (title, author, etc.), and options to set the overview map extent and north arrow style, among others. One aspect we are still working on is displaying legends. Since the service dynamically displays multiple map services with potentially many layers, the legend can grow beyond its designated container. But we’ve been pretty successful in generating output that clients like and that is flexible for various applications and APIs.