[Mapbender-users] Re: [Freegis-list] Have Geoportal's WMS requests in server or client?

Arnulf Christl arnulf.christl at wheregroup.com
Fri May 11 09:40:52 EDT 2007


Jan-Oliver Wagner wrote:
> Hello,
> 
> in the frame of security issues I came across the question what
> the particular reasons are why geo-portals (MapBender, iGeoPortal, p.mapper etc)
> do not execute WMS requests entirely on the client side (in JavaScript, like
> OpenLayers does) but rather do it on the server side
> (some do only GetCapabilities, some also GetMap).
> 
> The reasons I could imagine are:
> * it was easier t o implement it this way
> * with intensive JavaScript use we exclude some browsers.
> 
> I am extremely intersted if there are reasons beyond these
> and would be thankful for any feedback.
> 
> All the best
> 
> 	Jan

Hi,
Mapbender does it both ways depending on what you need. 

Standard GetMap requests are started directly from the client browser using JavaScript. This is faster as it does not involve an intermediary server to formulate the request. The map starts to build up once the first server has answered. If one of the services does not answer it does not block the others (as in a cascading architecture or with an intermediary proxy server). 

To do this the client needs to have a copy[1] of the Capabilities document to be able to formulate initial GetMap and FeatureInfo requests. Mapbender maintains a repository of Capabilities and ISO 19119 metadata describing them. CS-W 2.0 has been extended to allow loading single layers from a query result instead of having to always take the whole services. The copy of the Capabilites document that served to set this information can be updated manually or by a monitoring service [2]. The OGC WMS spec does not provide for a notification or push method yet (here rss could be used as a workaround). 

It is possible to preconfigure the initial request, select layers, image and query result format, initial start extent (if it is the first service), etc. 

In some cases it will be preferred or even required to request all images to one central point and merge / weld them. This is helpful when creating PDF print out files. PDFs regularly fail when different raster image formats with transparencies are overlayed, the result if often a solid black. FeatureInfo requests from different services will usually pop up each in a separate window, with different layout, etc.. To enhancement this one server can collect the results and merge them into one single window or iframe on a web page [3]. 

Another issue is security. If each request needs to be logged by a component that has authentication information (for example data with privacy relevant data) then the requests should be cascaded through a security proxy[4]. 

There will be many more application examples and for each an individual combination of server or client side requests can make sense. It will be interesting to implement everything again with WSDL. But this is still in the queue and nobody knows when it will be available as a spec and even less so whether people will actually want to use it. 

Best regards, 
Arnulf.

[1] http://www.mapbender.org/index.php/Add_new_maps_to_Mapbender
[2] http://www.mapbender.org/index.php/MonitorCapabilities
[3] http://www.mapbender.org/index.php/Modules#FeatureInfoRedirect 
[4] http://www.mapbender.org/index.php/Owsproxy


More information about the Mapbender_users mailing list