The more I think about this, it seems the best and perhaps only viable solution is to move the controller out of the checkboxes, back a step to the array of layers. That way, every time a layer option is changed (apart from opacity) the array can have its rules re-evaluated to make sure no further changes need to be made (e.g. displaying or hiding a merged-layer). The checkboxes would then be adjusted to simply reflect whatever settings the array currently holds.
But after about 72 hours of trying I'm really hitting a wall with how to actually make it work. On Aug 7, 6:48 pm, Kesuke <[email protected]> wrote: > Continued > from:http://groups.google.com/group/google-maps-js-api-v3/browse_thread/th... > (can't bump the old thread for some reason). > > A year on the project is very nearly complete, but I have a final > problem; > > Each diagram uses about ~130 layers/overlays. To improve performance, > when large numbers of layers are visible, there need to be special > layers (which I’ll call “merged-layers”). These are basically just > flattened versions of several layers, designed to decrease load time > and bandwidth. > > So in the example at:http://www.chiasm.co.uk under the layers tab > you will see one called “Abdominal MERGED”. This is just a flattened > version of the 4 layers above it (plus one hidden layer). > > But I’m having trouble finding a way to implement this smoothly. There > are several problematic areas; > > 1.) As far as the user is aware, these special layers don’t exist. So, > the checkboxes of those subordinate layers must remain ticked, even > though they aren’t really being displayed. If the user unchecks one of > them, the merged layer must be removed and the remaining ticked layers > added. > > 2.) There need to be several ‘tiers’ of merged layer. So for example > “Abdominal MERGED” is made up of those 4 muscles. But there might be a > ‘higher’ (in zIndex) merged-layer which covers the entire thorax, and > maybe one above that that covers all muscles. The system must pick the > ‘best/highest’ merged-layer to show. > > 3.) These merged layers will mess up any layer opacity settings, so if > layer opacity is < 100% they must not be used. > > Some of these problems arise because currently layer visibility is > directly derived from the checkboxes. I wonder whether we could shift > control back to the layers array? So we make changes to the array > rather than checkboxes (which merely ‘emulate’ the parts of the array > we want them to). -- You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.
