Agreed - but how? I've racked my brains thinking about ways it can be organised so that, on the one hand, it gives quick and easy functionality to those that want specific things, but which, on the other hand, doesn't make it dead-simple for a clueless noob to whack NOAA with a big stick.

Alas, because GE doesn't allow 'exclusive options' (radio-buttons, effectively), you're right - it's impossible to disallow dumbness. The best we can do is make 'dumbness more difficult' (by obscurity)... which limits the usefulness to those with brains.

Tough call...but I'm all ears.

Technically, the Legend DOES need explicit turn-on to be visible. At least, to the same degree that everything else does! It's shipped 'off'... its just that if you select the tick-box for (say) Brownville, then the triplet of 'image, warnings & legend' below it is turned on - same as any other node, really.

Moving it to a separate 'Legends' folder (and similarly, one for Warnings, maybe) makes life difficult. First, the Legends - moving them to a separate folder would mean that someone who'd pulled up (say) 'Short-Range Reflectivity' for Lake Charles, and who wanted to see what colour scale was being used today, would then have to go shuffling off to the Legends folder, open that, then drill down till they found Lake Charles, then turn on the Legend. All a bit long-winded and inconvenient - purely for the sake of 'stopping stupid things from happening when stupid people are in control'... which, chances are, ain't them.

Similarly, with Warnings - I had thought about making them (effectively) a separate 'data-product' and giving them a folder of their own. But here we run into another wrinkle... the Warnings overlay is different for the Long-Range image (because it's bigger). This would mean that the Warnings folder would contain sub-folders for all 21 radar sites, each containing two Warnings overlays. People would have to remember that when looking at the Long-Range Reflectivity, they'd need to use the right warnings overlay, or else the geo-location will be completely off. Again, functionality would be impaired, I think - and certainly convenience would take a big hit.

Yeah, I was thinking about this one too. Might be enough, perhaps. Or even divide them by state, maybe? Again, it doesn't physically STOP some idiot clicking the top-node... but nothing will, quite frankly. This might be a good halfway-house.

Something else I'd thought of was shipping a root-level KMZ which contained several Network Links, and somehow making the selection of one 'remove' the sub-trees on the others. Haven't quite worked out if that's possible - but gave up when I realised that it would mean people fetching the KMZ each time they changed their minds about what data-type they wanted to see... I don't think my humble 400MHz webserver would cope, quite frankly!

I'm still working on a few other thoughts which might help, but really, I think it's a GoogleDev topic for consideration. As the program becomes evermore popular, the chances of this kind of 'massive attack' KMZ becomes more evident, and I think they really will need to give us developers the ability to make certain selections mutually-exclusive, and prevent alteration of things like refresh times, etc. Or the program will simply get a bad reputation as a webserver rapist, worst-case.

Anytime - it's been fun... a good challenge and a worthy cause. I'm sure we can come up with something that'll suit everyone's need, sooner or later! Keep those ideas coming... I'll put up a new version tomorrow if I get some time (my paying clients have a busy day planned for me on other things tomorrow, so there may not be a huge amount of changes, but we'll see).

Night all!