Layer groups

[cmantock]

I think a powerful feature that could be added to your application would be a concept of layer group.

This would simply be a way to group layers that can be rendered on the client as individual OpenLayer layers, that can be refreshed independently of each other. 

Let me give you a situation where this would be useful, I work for a utility company, and in using your product I use the google maps as my base layer.  Then I use my own layers to represent the poles and electric lines by putting them in the dynamic layer.  

I then added my own custom javascript to refresh only the dynamic layers on the client, giving a better user experience, to show for example when a user opens a line and disconnects some customers.

However you guys only have one layer that is dynamic.

Now i want to have a layer for our vehicle positions but want to refresh them withoth refreshing the base layer or the layers with the poles or electric lines. So i you implemented a layer group that I knew would be a separate layer on the client I could refresh it independently and improve the perfomance as i would only be drawing some layers at a time, and not all the layers of my map.  

You could extend this to include a layer that is implemented as  web feature service layer on the client so for example to show vehicle positions the rendering would be done on the client, and a timer could be added in javascript to refresh the layer every minute. the screen would not blink and uisers would like the richness and you would offlload some of the work of the server to have to redraw all the dynamic layers.

 

You guys are really on a path to create one of the best .NET mapping apis out there, the inclusion of the openlayers javascript api and your excellent server side map rendering and spatial analysis control opens up a lot of possibilities.  However I think you are missing some oppurtunities on the client side that could improve performance,  and the smoothness of the client UI. 

 

So just keep up the good work, can't wait to see your silverlight control.

 

[David]

Clava, 
  
   You beat me to my announcement!  I am about to release a blog post covering this issue.  I am going to paste it in here to give you a first look. 
  
   We have received many questions on why we limited the number of client side layers to to only three.  Let me first say that we are going to change this to remove the limitation, more on that a little later.    I would like to shed some light as to why we now only have a base map, static and dynamic layer system.   
  
   The  reason we limited the number of client side layers was to protect our users from performance issues.  Our client side library requests tiles as images and these images have to be requested and drawn separately.  For any given layer, such as the static layer, on the client side there may be around 32 images that have to be requested and drawn.  This means if you have 4 client side layers then your browser would be requesting 128 tiles per zoom-in or zoom-out.  This creates a lot of load on the server if these tiles are not already cached on the client or server side.  For the base layers we did not see an issue as these are requested from other providers such as Google, Yahoo, etc.  We were worried that if we gave our developers free license over creating client side layers then they would create lots of layers so their users could turn them on and off in the layer switcher on the client side.  Imagine a person creating 20 or 30 layers, it would generate 600 requests.  This would generate too many requests for any web server for one client action leading to slow performance and dissatisfied customers.  
  
   Drawing each tile as a separate request has considerable overhead versus drawing one large tile.  Each tile might have some part of a large feature in it and even though you do not see all of the feature such as a lake each point still has to be retrieved  and drawn.  This process is especially taxing on SQL based sources such as SQL 2008, Oracle Spatial and Postgre.  We tried clipping the feature but we found it was faster to draw the feature then to clip complex features and this did not get us around the problem of having to retrieve all the data.  We have in some ways overcome this problem with some creative measures which I wont go into here :-).  We do suggest however that if you do have many of these types of layers then you set them to draw as one tile and not as a grid of smaller tiles.  The effect on the client will not be a fancy as the small tiles loading  but the performance benefits I think outweigh them. 
  
   The other problem with a lot of image requests is that if you use IE then it is limited to creating only two connections to the same web server at one time, this means if you need 128 tiles then the most you will request at any one time is two.  For more information see support.microsoft.com/kb/282402 .  This causes the perceived client speed to be somewhat slow as the requests are serialized into groups of two.  Firefox does not have this limitation and is faster with this kind of load.  To mitigate this we are going to expose multi server functionality which allows you to designate multiple server from which to pull the images.  If you have static data such as our World Maps Kit that doesn’t change in your application then you will have the option of installing it on multiple servers so when our client requests the tiles it will request them simultaneously from the group of servers.  This allows you to scale up your performance to whatever degree you desire based on how many servers you can add to the group. 
  
   We have also implemented more advanced threading, on the server side, into the next beta so that we take better advantage of multi core processors.  In our testing environment this has shown large gains in throughput with many tile requests.  We feel this coupled with the multi server layer and other trick we have will net the performance we expect for a great user experience. 
  
   In the next beta we will also have tile stretching, this is the effect that when you zoom into a new region that we stretch the existing tiles and show them to you until the new tiles are finished loading.  In this way the screen does not go blank between refreshes and you are still able to see landmarks while you are moving about.  This also really help with the user experience and we think you will like the effect. 
  
    In the end we have decided to open up the layering system in OpenLayers due to many requests from our clients to solve real world scenarios.  Our new direction is to give server side developers almost complete access to the OpenLayers layer API without any client side code.  We will deal with the issues that this creates either though ingenious coding on our part or through more white papers and education.  The key we feel is to ensure that you are never bound by artificial limits and you have the full power of all the technologies we integrate with. 
  
   If you have suggestions or criticism on how we expose functionality we would greatly appreciate it.  Your input is the driving force behind what we do so if you see something is not right or have an idea that would make your life easier then let us know. 
  
 David