Another point on this that I can clarify in regards to generating our own images from raw return data is that the need for multiple legends would not be necessary. This is similar to how (and why) I did the SST data the way I did. Take all the data, and transform it via your own parameters so that's it's uniform across the board....then only 1 legend is neccesary. Again, this is the best solution, but likely the most difficult (not logically, but timewise investment). I think the entirety of the Gulf and Atlantic SST coverage results in less than 100KB of image data at (.25 x .25) degree resolution. This includes ALL of the SST folders. SO you can see the advantage to that now that we sort of have a benchmark for the way of aggregating premade imagery.
Still not saying that doing it ourself is the answer, but just trying to paint a full picture so that we can weight our options carefully.
Yup - I understand - trouble is, the sheer amount of data that I or you would be required to fetch from the NWS every five minutes, if we did it that way. I don't think my systems could take it, frankly! Especially when coupled with that fact that once we'd grabbed and reorganised that bitmap data, we ALONE would then be responsible for shipping it back up to however many clients were using the Network Link, plus the KML itself! It could become an extremely heavy load, very quickly.
I suppose if we were going to do a 're-sampled' set of overlays, for GE users, we could limit the number of updates to one every hour, or something - but then the whole project starts to be come less useful in the GE environment... simply because people KNOW they can get the data from direct from the NWS website every 5 minutes....
Argh... this is such a great concept... but entirely banjaxed by the rather short-sighted limitations of KML. I do hope they fix it soon...
Quote:
Agree that further parrying down the data into chunks doesn't ultimately help because the top level is still a bastard....and the further it's divided, the more cumbersome the interface for the user becomes.
Well, I've given it a bash... I've reorganised the layout into Gulf and Atlantic layers - but all the problems about top-level check-boxes still remain, of course (Come on GE developers, at least acknowledge that you're aware this is a problem, per-lease! ).
Anyway - new version V1.1 of the placemark attached. Differences are...
a few more warnings, just in case people haven't twigged the issues already
reorganisation of the layers into Gulf & Atlantic folders
Network Link now set to refresh the underlying KMZ from my server once every HOUR now (instead of once every 4). This is an attempt to keep the geo-location data (which has to be hard-coded into the KMZ) more fresh. I will be monitoring to see what the effect of this is on my webserver!
As before - please heed the warnings contained within the placemark itself, and on this post here
Previous Topic
Index
Especially when coupled with that fact that once we'd grabbed and reorganised that bitmap data, we ALONE would then be responsible for shipping it back up to however many clients were using the Network Link, plus the KML itself! It could become an extremely heavy load, very quickly. 
