There is no way in OpenLayers to have vector data transform or reproject after a chance in base layer built into the library. OpenLayers Ticket #1249 is related to this, and this is one of the areas that we expect to improve in OpenLayers 3.0.
In the mean time, if you want this functionality, registering for a changebaselayer event and doing what you need to with that -- reprojecting the data, or whatever else makes sense -- is what you will need to do if you want to change the projection of your base layer / map.
The degradation of performance depends on the client's machine - how much memory is available to render DOM elements in the browser, and how fast the CPU can work to redraw these elements when the map changes.
In my experience 144 tiles (each of which will be a new DIV element) should be fine. IE handles several hundred DIVs and FireFox a few 1000 (although if you have FireBug installed that may not be the case).
Testing
It could be useful for you to determine the minimum machine spec you are going to support, and then see how the browser performs with your tiles. This could be done on a virtual machine or using IEThrottle and FireFox Throttle
One way to check how many elements you are dealing with at any one time is to paste the following JavaScript lines in your browser's address bar:
This shows total DIV elements in the page:
Javascript:alert(document.getElementsByTagName("div").length);
This shows number of DIVs in your OpenLayers map, assuming it has an ID of mymap (just change this if it is not the case):
Javascript:alert(document.getElementById("mymap").getElementsByTagName("div").length);
Tile Benefits
The use of cached tiles is likely to far outweigh any negative impacts of using 20 tiles as opposed to one large dynamically generated WMS image.
As you pointed out in your post, performance is likely to be negatively impact due to the maximum number of requests to a single domain, before number of DOM elements causes issues.
Tile Performance
To speed up tile performance you have a number of options, the key ones you have already listed:
- Using multiple DNSs
- grouping layers together
- merging cached tiles together on the server (if you have the PIL installed with TileCache then this should happen automatically
- increase tile sizes to reduce requests (though you will need to recalculate resolutions etc.)
- cache tiles on the client by setting the right request headers
Great examples and FireBug performance logging can be found at http://ol-performance.appspot.com/
Training Users
As well as technical solutions, the UI should also be geared up to limiting the number of tiles a user requests. I hope to implement this in the next round of development for http://maps.seai.ie/wind which uses several tiles (and you can see how it performs when all layers are switched on - use the above JavaScript to see how many tiles are loaded). With just three layers there are 160 DIVs in the map, but performance is fine in most setups.
Two things to implement:
- use radio buttons to switch continuous layers on and off - as these would cover up the other layers anyway there is no point having the DOM elements if they are invisible
- remove the "Select All" checkboxes - this will force a user to only turn on layers they really want to see
I'd be interested to hear your results on how many tiles you managed to load in different browsers.
Best Answer
With software like maptiler you can export images to a TMS-compatible format and keep georeferencing, so you can combine this with OSM or Google background images. Maybe you can get better results with this.