ThinkGeo.com    |     Documentation    |     Premium Support

Drawing WMS on PDF?

Hi,


I'm attempting to create a (server-side) PDF with the current map image included. I'm using the PdfSharp and PdfExtension for this.


This works fine for normal vector layers, but I cannot seem to get my WMS to being drawn onto the PDF.


First of all, I create a new WmsRasterLayer, as WmsOverlay doesn't have a Draw method, transfer the server URI and all parameters from the overlay to the layer object, and set its OutputFormat and Crs to correct values. Then I call the WmsRasterLayer Open method, call its Draw, and finally call Close.


All seem to work, but the WMS image never appears in my PDF page.


I've used Fiddler when debugging, and it seems that the WmsRasterLayer.Draw method never issues any GetMap requests to the server, which would explain the missing imagery.


But why is this ? What am I doing wrong ? Are there any special pitfalls here when dealing with WMS ?


I'm aware of the recent thread (gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/12/aft/9898/afv/topic/Default.aspx) and the samples, but neither touches on WMS.


Please advise me on how to proceed.


 


 



Hi again,


Ah, a closer study of the Fiddler log exposed the real truth.


The request was indeed sent, but failed. The reason is due to an inconsistency between WmsOverlay and WmsRasterLayer.


I'm utilizing a commercial WMS service, that requires additional parameters, namely LOGIN and PASSWORD. Neither WmsOverlay nor WmsRasterLayer has any provision for such extra required but non-standard parameters implicitly, and the way to handle it in the two classes are apparently different.


In WmsOverlay one needs to add them as parameters within the ServerUri, otherwise the GetCapabilities request fails. This is carried over from the GetCapabilities request to the GetMap requests, so I don't need to do anything more.


In WmsRasterLayer however, the parameters are stripped from the URI when performing GetMap request, which made this request fail. To make it work I needed to retrieve the parameters manually from the ServerUri, i.e. "wmslyr.Uri.AbsoluteUri.Split("?").Last", and add them to wmslyr.Parameters() before issuing any GetMap request (i.e. activating Draw()).


I think you ought to remove this "parameter stripping" in WmsRasterLayer to make the handling consistent in future releases. Use of required non-standard vendor specific parameters are not a rarity, rather than the rule, imho.


 



Lars,


  Thank you for your feedback and pointing out some inconsistency that our API may have in relation to Wms. I will pass that to the Development team. We appreciate your involvement in helping us better our products.



 Hi Lars,


 
The WmsOverlay is actually a wrapper of the client layer; it only gathers user settings and creating web DOM tree node (eg. Image tag), then let web browser retrieve the image stream, it isn't responsible for requesting images. While the WmsRasterLayer is responsible for everything including retrieve images by itself. So here is the difference so that we cannot sync everything between them.
 
On the other hand, we can successfully make it work with our existing APIs. First of all, we can check the requesting server is fine. Sometimes, the Wms capability’s service address is not in sync to the exposed server, if this first step is incorrect, the entrance of this feature won’t work. 
 
Secondly, we need transfer layers and styles into the layer parameters.
 
Thirdly, we implement the SendingWebRequest event (this is a new API which is available after 5.5.62.0), in this event, we can remerge the web request.
 
Please check my attached sample which used every point I mentioned above; if you still have the issue, please show us the WmsService Uri and an available uri to retrieve an image, we will check out.
 
Thanks,
Howard

WebPost9941.zip (22.5 KB)

Hi Howard,


Thanks for your response. However, I'll just add some quick comments, just to make sure you understand what I'm doing.


I'm NOT trying to make WmsOverlay behave like WmsRasterLayer, or vice-versa. At least not behind the scenes, as I do know that overlays are just server-side wrappers for OpenLayers layers on the client.


I AM trying to construct a WmsRasterLayer (to enable server-side generation of a PDF with map) based upon the information in an existing WmsOverlay, that works nicely in the web app itself.


The inconsistency is present in how the two objects logically handles non-standard parameters, like LOGIN and PASSWORD for use with a commercial WMS. Such non-standard parameters are not an oddity, but a usual requirement here.


It would be nice to have both objects handle such parameters identically, or even better, introduce (in both) a standardized way to add all non-standard parameters. The latter could be implemented as an additional collection, e.g. an OptionalParameters collection, alongside the normal Parameters collection.


Cheers.


 



 Thanks for the feeback Lars!


I will discuss this with our API designer and see if there are any pitfalls to the approach of not stripping the Server URI on the WMSRasterLayer so there is more consistency between how you set the non standard parameters between the WmsRasterLayer and WMSOverlay.


Thank you for letting us know your findings and sharing your suggestion!


 


 


 



Lars, 
  
   I have been reading this and also ticket 6156 and will answer everything here.  This is a bit complicated as there are a few moving parts so I will do my best to unpack and explain what is going on.   
  
 Uniformity of Layers & Overlays 
 I agree with you that this needs to be done.  We have started down this road and will continue to bring all of the WMS and HTTP style layers and Overlays into a uniform look.  Of course the Web WMS Overlay is a bit special since it gets defines server side but then all of the real work is done client side in JavaScript.  This is very different from the server side only stuff but doesn’t mean we should not strive to make them as uniform as possible. 
  
 Adding Option Parameters 
 1. I agree with you that we need a way to add option parameters and I believe that some of WMS layer and overlays do allow this but not in a uniform way.  We will look into this however for immediate relief we have implemented a nice set of events that fire whenever an HTTP request is kicked off which allows you hook and intercept the URI and modify it to meet you needs.  As an event it is easy to hookup and use and was added to all of the HTTP style layers and overlays we have barring Silverlight at the moment.  Check out the link below and scroll down to the “New Web Request Events and Methods” area and check it out.  Of course this will not work for the Web WMS Overlay as it is special as I said above.  I do think it does support optional parameters through through a collection.  Let me know what you think of the event. 
  
 gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/16/aft/9809/afv/topic/Default.aspx 
  
 Missing Images in PDF Part 1 
 I will look at the issue where the WmsRasterLayer never issues any web calls.  The only thing I can think of is that is is possibly related to a change we made where when you open and close a WmsRasterLayer it would not need to call the GetCapabilites each time.  We used to require that and it cased things to really slow down.  I will test it and advise.  
  
 Missing Images in PDF Part 2 
 I believe that one possible issue you are running into is a current shortcoming in the PdfGeoCanvas where one of the DrawImage APIs does not work.  I think if it drawn anything that is scaled the image will not show up.  This was a limitation of the PDF engine we are using and our work around was to add some code that resized the image first and then draw it using the API that draw images without scaling.  I think this had just not been done yet.  Let me look into this and see if we can just add this code quickly and test it out.   
  
 David

Lars, 
  
   Sorry for the confusion of the last post from me.  I am working on the issues these days and had my sort order oldest on top so I answered the very first post without reading through the rest of the posts.  In any event two things still stand.  First I suggest using the web events for the non standard items for now as they are uniform between both products.  In a week or two we will review the overall architecture of all of our WMS related layers and overlays and unify them to one nice standard. 
  
 David

Hi there

 I usually create pdf files using a pdf document toolkit.And it turns out to be helpful.If you want to drawing wms on pdf ,you can just refer to the pdf document drawing software,they have detailed tutorial.

Hi Abigail, 
  
 Thanks for your post and suggestion. If you have any more question , please feel free to let us know. 
  
 Best Regards 
  
 Summer