Issues encountered and solved while building a comprehensive web-based map printing solution

Web-based map printing has been one of those problems that, so far, doesn’t have a COMPLETE solution that meets all the needs of the different users out there. We had created various solutions in the past to meet web-based printing needs on a per-project basis. But, we didn’t have one single comprehensive solution that was capable enough to meet all requirements regardless of the unique complexities involved in each of them. A little while ago, we set out to build one such comprehensive web-based map printing solution and ran into some issues along the way that I thought might be worth sharing here. I am not going to go into what we built here, but just the issues/oddities we encountered…

Here are the issues we faced while developing the printing component and some details into how we worked-around them.

• Printing token secure layers – This is a problem that we initially didn’t see coming because we were using the Silverlight client api to print. When using token layers, the client (which is the browser) requests a token from the GIS server using it’s IP address (or a web address) as the optional ClientID. When using a token generated with a ClientID, the AGS server checks for the origin of the request to confirm identity. So, when we tried to use the token generated by the client browser with it’s IP address as the ClientID in the server-side printing component, the requests were denied by AGS as it rightfully should since the server’s IP address doesn’t match the one in the token. We did not initially see this problem with Silverlight clients because, Silverlight clients currently request tokens without the optional ClientID. To work around this, we had to request token without the ClientID or had to spoof the Referrer in the HTTP request for the image.
• Max Image Size constraints – The size of map image requests that need to be made can get quite large depending on the size of the map on the print layout and also on the DPI required on the map print output. AGS has default max image size limits set to 2048 X 2048. Bing maps maximum image size is around ~800. Increasing the maximum image size limit in AGS will only take you so far. Eventually, your image size requests can be big enough (think plotter size) to either cause AGS to crash or just take an unacceptably long time to return. So, to work around this limitation, we had to resort to cutting the big image requests into a series reasonably sized tile requests. Once all the tiles to cover the big area arrive, the tiles can be stitched back together using GDI+ to produce a seamless big image that the map print layout needs.
• Bing logo – The above solution to split big image requests into works for AGS MapServices and WMS services, but Bing map layers add another twist to the problem. Image responses from Bing contain the Bing logo on the bottom right corner of the image. This caused the Bing logo to appear multiple times on the map when the numerous smaller tile images were stitched together. To solve this issue, we had to get special permission from Bing to access their tile images directly which do not have the Bing logo on them and stitch those together to produce the seamless image required.
• Custom legends – The swatches for legend image for an AGS MapService can be obtained pretty easily using the AGS SOAP API. But more custom work is needed to stitch together the swatch and legend text information from multiple map services. Also, to add to it, there was no easy way to generate swatches for graphics layers. So, we ended up writing a custom Server Object Extension (we call it LegendServer) exposed over SOAP that takes in the information needed to produce swatches for the graphics layers and produces swatch images. The legend service consumed the swatches information from the AGS MapService and the custom SOE and stitched them together into one legend image handling the font styles etc and wrapping as necessary. We still have the issues here that ArcObjects is not able to generate the swatches at the required DPI. For e.g. we can’t request for swatches in 300 DPI etc.
• Missing legend symbol markers in AGS – When writing the custom Server Object Extension described above to produce legend swatches, we discovered that ArcObjects doesn’t support triangle markers. But triangle markers were supported on the client-side APIs. So, to overcome that limitation, we can handle just the triangle markers as picture marker symbols and handle it with a special image service that produces a triangle image in the required dimensions, fill and border color.
• Overflowing legends – Sometimes the legend for a map just can’t fit on a single page. In those cases, we had to make sure that we build the legend in parts that can fit on the page and stick the overflowing legend into new pages as needed. The trick here is to not build one single legend image and chop it to overflow to the next page. Because, we decide to chop off the legend at an arbitrary height, we might end up chopping the text or swatch on the legend. So, we will have to build the legend in parts and then assemble them into the different pages.
• Printing Graphics layers – Printing graphics layers on the map turned out to be a little tricker than expected. We went down the path of rendering the graphic layers as PDF graphics on top of the map. It seemed to do everything we needed until we had to print polygons with holes in it. Then we used the AGS SOAP API to generate an image for the graphics on the map and overlay it on top of the map. We ended up pulling back that solution because that technique did not support transparency in graphics. So, eventually, we ended up writing a custom Server Object Extension (we call it GraphicsServer) that produces images from the graphics layer geometries and symbology respecting their transparency.
• Overview Map – Printing overview map doesn’t sound too complicated until you consider the fact that we might have a totally different set of layers on the overview map than we do on the map itself. Also, the overview map can be static or dynamic, meaning it can always be at the same extent (world extent for example) or it may have it’s extent set at levels that closely follow the extent of the map itself. Also, keep in mind that the overview map will also need to have a small rectangle graphic inside it that highlights to current extent of the map.
• Print Rendering – In most cases, we will want to have the option of being able to render to PDF or an image as the user requires. When implementing these renderers, please keep in mind that the co-ordinates axis for the PDF and the image GDI graphics are reversed. PDF is bottom-up and image GDI graphics is top-down.

I am pretty sure that I am leaving out some more. I will add them to the list above as and when I remember them. But I am happy to say that we did solve/work-around all the problems that came our way and have been re-using the printing component in various projects with great success. The printing component is also being used by all Silverlight, Flex and Javascript clients.

Please let me know, if you ran across other issues when you implemented your print feature or if you solved any of the issues above in a different way.

Advertisement

CI Starter Kit

I have made the template following the project directory structure I described in my ESRI Developer Summit 2010 Continuous Integration Talk and the build scripts to along with it ready for download here. Couple that with VisualStudio shortcuts I described here and that should help any project get started quick. In latter posts, I will detail how you can get the above project & build scripts in the template setup on the TeamCity Continuous Integration server

One overlooked feature that is coming in ArcGIS Server 10

At the ESRI devsummit last week, there were a lot of new features in ArcGIS Server (AGS) version 10 that were getting a lot of attention. There was a lot of fan-dare around geodatabase editing over the web with the new Feature Service in AGS 10 and the flashy demos with all the new RIA clients for editing with the REST API. There are also a lot of articles & blog posts that have been written to cover those features in details. So, I thought I would stay off the beaten path and direct your attention towards a new feature in AGS 10 that is getting little to no attention. That new feature in AGS v10 is support for exporting PNG32 (32 bit PNG) map images from the REST API and other APIs offered by AGS. This should provide the complete support 8-bit transparency in PNGs and should help us avoid issues like the ones here. Printing maps functionality should also benefit from this new feature both in terms of quality and to avoid transparency issues when layering images.

Just check out the ‘Image Format’ drop-down here for proof of 32 bit PNG support . And as you can see here, AGS 9.3.1 only supported PNG24. Hope that helps someone… 🙂

Working with ESRI token secure services

At the ESRI developer summit this past week, I ran into some people that were either having a hard time with using the ESRI token authentication or were leaving their systems vulnerable to hacks given their use/abuse of long lived tokens. I thought it might be useful to share one way that we have been using ESRI token secured services in our web mapping applications.

Token secure services require the client to request a token with their username & password which should then be used/included in all other future requests to access the services. The token provided to the user by AGS is also valid only for the time period requested by the user. The AGS server also applies a upper limit to how long the token can be valid.

One of the main reasons for troubles with using such token secure services in a web mapping application is that the user logs into the web application that he is using and not actually the AGS server(s) that the web application is using map services from. So, in order to use the map services in the web application, the user has to log-in (again) to the AGS server also. Having the user log in again after they have already logged into the web application is highly undesirable. To prevent the user from having to enter in the credentials to access AGS services again, some may decide to use a long lived token and hard-code the token into the web application or hard-code the username & password to access AGS services in the mapping client application. I don’t think I need to explain why hard-coding the username & password in the client web mapping application is dangerous. But this still leaves the application highly vulnerable to hacks since anybody who can read the URL being used to access the services have access to the long-lived token. Using the long-lived token, anybody can obtain access to the AGS services since the only defense is the ClientID (or the HTTP Referrer header) and that can be spoofed easily since it is never verified. Also, the long-lived token doesn’t expire often and leaves the hackers a lot of time to get the token and access the secure AGS services

To get around this, there is an easy way to setup the web application to use and better secure the AGS services. We might have two main ways of sharing username & password between the web application and the web application. The first way is to have AGS and the web application share the membership/permission/roles datastore. In this case, the web application can use the same username & password combination to obtain a token from the AGS server. The second way is to have all users of the web application use the same name username & password to access the AGS services. The second way could work because the user has already been authenticated by the web application and so he can be trusted to access the AGS services also. In this case, the username & password that will be used to log-in all web application authenticated users can be stored in the web application configuration file (web.config). This credential can be used to obtain a token from AGS. This is generally how Bing map services are also handled. The Bing credentials are stored in the web.config and used to obtain a Bing token when the page with the map is loaded.

So, once the user logs into the web application, the username & password from the shared datastore/web.config can be used to make a request to the AGS ‘GetToken’ URL endpoint and obtain a short-lived token for AGS access. This token can then be sent down to the client as a part of the HTML / ASPX page. Another technique is to write a HTTPHandler that accepts a GET request without a username & password and uses credentials from the shared datastore/web.config to obtain a token to access AGS services and sends the token down to the web application client. Is method is secure because the HTTPHandler itself can be secured by either windows/forms authentication of the host web application.

Another thing to note about AGS tokens is that AGS does NOT require a ‘Referrer’ (IP address/ Site URL) to generate a short-lived token (long-lived tokens do require them). If you are generating a token from the AGS web page to generate a token, you will have an option to not specify the ‘Referrer’ (ClientID), but if you are just making a HTTP request to the GetTokens endpoint, you can obtain a short-lived token without the ClientID. When using short-lived tokens obtained without the ClientID, AGS does NOT enforce checks on where the calls are originating from. Actually, this is the reason why Silverlight clients are currently able to consume token secure map / AGS services. Silverlight 3 & under clients do not include the ‘Referrer’ HTTP Header for all outgoing HTTP requests, so ClientID origin checks are not enforced on Silverlight API clients. This issue has been fixed in Silverlight 4.

Unfortunately, the authentication tokens generated by ASP.NET to secure web applications and the ones generated by AGS are generated using different techniques. The key used to generate the token is different, ASP.NET uses the machineKey from web.config and AGS token uses a key from the AGS configuration file. If this wasn’t the case, we could technically have the ASP.NET web application and AGS share the same token…