On Sat, Jul 28, 2007 at 02:29:13PM +0100, Ludwig M Brinckmann wrote: > > > > > > In general, I would advise against having 11 seperate layers on a map. > > It's possible that this really is neccesary, but in general, 11 layers > > is more likely to confuse the user: You're the map maker, make some > > decisions about how the map should look, and combine some of the layers. > > > Well, I think there are many situations where one would want to give a user, > which might not be the general public, a _lot_ of layers and I would argue > that OL should should support this.
The primary issues with supporting this are not issues that can be solved on the client side. Take 10 layers as an example, and a map viewport of 1000x800 pixels. This results in a 4 x 4 tile viewport. Buffer around that of 2 in each direction -- 6 x 6. 6 x 6 * 10 -> 360 tiles. 360 tiles at 30k apiece: 10.8MB of data. 10.8MB of data over 512kbps connection: 172s, plus .1s latency per tile, divided by two (the number of connections a browser will open to the server at once) 36s / 2 -> 18s. So, if you want to load 10 layers in a typical map setup, you're dealing with 190s of load time, *assuming that tile generation is instant*. Since we all know that with the exception of TileCache, tile generation isn't instant, we need to take that into account: even assuming that each tile only takes .5s to load (a pretty conservative estimate, given the state of many WMS servers on the web), the data takes an additional 90s (360 * .5, divided by the same 2 above, 360 / 2 / 2 -> 90). 280s to load data, and that's not a particularly good case: even with a *single* layer I've occasionally seen cases where loading data takes up to 30s, much less in the massively layered case. Now, I understand that there are a number of optimizations that can be done, but in general, there are limitations of working in the browser that make loading many tiled layers from the same server unrealistic in the browser environment. That said, I'm not claiming that OpenLayers should abandon this use case: the response I made was only in response to the question from the original poster, who was being afflicted by slow load times. There's only so much that can be done on the clientside for that. As far as user interface for management of layers, I admit that OpenLayers is lacking, and there are people working to improve that -- Lorenzo Becchi's WMS Manager code is an example of that -- and if there were to be an effort put together to manage layers better on the client side as far as visual interface goes, I'd be behind it. There have, in fact, been several efforts by various users and developers, but in general, they are rather limited in how much they provide, and what they expect -- not 'general' enough, in my opinion -- and have not been developed to the neccesary extent for inclusion in trunk. > I have found that with mapserver vector layers it is often better to just > have a single tile as the effort creating the tile lies in the DB or > shapefile access and because Mapserver will, depending on setting, either > discard elements at the edges of tiles (which would be in the middle of an > OL tiled window), or the symbols do not line up well or a duplicated on more > than one tile. For the record, this is exactly the kind of thing which TileCache, with meta tiles, or ka-Map, are meant to solve. Regards, -- Christopher Schmidt MetaCarta _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
