ThinkGeo.com    |     Documentation    |     Premium Support

WMS server side rendering?

#1

Hi,


I just had someone from outside my LAN test my demo web solution which uses one wms service as background for an inmemory layer of drawing shapes. He is routed in to my webserver, but the wms resides on another server (on the LAN) that's inaccessable to him. He experiences that the wms layer disappears.


Which leads me to assume that the wms request itself is pushed to the OpenLayers client for rendering, rather than being rendered server side. Is this assumption correct ?


I cannot find any setting in WmsOverlay that will allow me to force server side rendering, so I'll post this option as a feature request here.


Server side rendering of wms layers can be necessary for security reasons, and for routing reasons, e.g. if one maintains multiple virtual machines connected by an internal network, with only a few "fronts" being exposed to the user via another network.


Thanks



#2

Lars, 
  
   Most of the time users want the WMS requests to come from the Client as that removes load from the server.  Of course you bring up a good point of security and you may want everything channeled through the server and still have most of the load of building maps distributed to other places.   
  
   The good news is that we can cover that case.  What you need to do is use the WmsRasterLayer as a layer and place it in a LayerOverlay and add it to the web map.  The LayerOverlay will process on the server side and the WmsRasterLayer will process on the server side as well.  I think the API for the WmsRasterLayer is very similar to the WmsOverlay so you should be able to swap the items out quickly.  Try that out and let me know how it works.   
  
 Thanks for making the feature request.  If you can think of any other good ideas let us know. 
  
 David

#3

Hi David, 
  
 I’m getting curious. What you’re saying, is that WmsOverlay is always client-side rendered, while WmsRasterLayer is always server-side rendered ? 
  
 I assume this distinction goes for other layer constructs as well, like WFS ? 
  
 Are there any general rules of thumbs about this sort of behaviour of individual layer constructs ? 


#4

Lars, 
  
   The rule of thumb is that Overlays are generally platform specific and Layers are usually platform neutral.  The base class layer is in the MapSuiteCore and was designed to do drawing across all of our different versions.  99% of things that inherit from Layer were designed to be used across all of our products.  The Overlay base class is actually defined separately in each of our products like the Web & Desktop.  This means they are not compatible and will clash if referenced int he same project.  The idea of the overlay was to have product specific types of layers that could one one had utilize the specific features of the platform but also offer a high level of aggregation.  For example with WMS we wanted to have a web client side implementation so we designed the WmsOverlay.  Of course we want a WMS kind of layer that is universal across all of our products so we created a WmsLayer as well.  I hope this makes sense. 
  
 I think in the case of WFS I am not sure if we made a WFSOverlay for the web but that is the kind of thing we could do if we wanted to make the WFS client side.  I think all we have now is the WfsLayer which would happen server side.  Behind the scenes when we build a special purpose Overlay like the WmsOverlay we need to build a special piece on the client side to expose the functionality.  I don’t want you think if you just create a Overlay then it all happens on the client automatically, that is not the case, we have to code the special cases. 
  
 David 
  


#5

Hi,


I've now had a chance to debug the WmsRasterLayer server-side alternative (using Static/Dynamic/... instead of CustomOverlay), and the result is somewhat disappointing. The WMS layer works as such, but ...


The choice seems to be between being stuck with client-side rendering of WMS or a very limited layer control.


How come the layer control is limited to overlays only ? I would very much like to have the individual layers in StaticOverlay and DynamicOverlay shown individually. Is this a limitation in OpenLayers or the MS wrapping ?


 



#6

Lars,  
  
   The limitation is a little of both OpenLayers & Map Suite.  You can always create one overly per layer but I don’t think you would like the performance.  In OpenLayers each overlay is a separate request to a server somewhere for every tile so you would be dealing with hundreds or thousands of tile requests per page if you have a dozen or more layers.  Map Suite through the Overlay class allows you to consolidate the layers into more manageable groupings.  In my opinion, the OpenLayers layer switcher was not really designed for dozens of items. 
  
   The solution is to write your own layer switcher to allow users to turn layers on and off.  In this way you have total control over everything.  I think we might be able to whip one up as well as part of the code community that could read all the layers in the overlay and maybe group them in some web control.  I think the key is to have the source available so you can customize it.  If you can wait a but we can get someone to look into that control. 
  
 David

#7

Hi David,


Alrighty then, I've wrapped a WmsLayer in a LayerOverlay, and now have my server-side wms in my CustomOverlays collection. :-)


Thanks for the valuable pointers and explanations. It's all starting to make sense to me now :-)





#8

OK, Lars, please feel free to let us know if you have any more questions. 
  
 Thanks, 
  
 Sun