Quote:

---

Any comments or feedback welcome. Ultimately (if Paul is still up for it), we'll probably integrate this sub-set with the main Storm Tracking set that Paul's kindly provided. It may take us a while to get it right (and thus, this KMZ/Network Link is very much a beta-test). As such, it may disappear overnight, or be altered or cut-down dramatically in the next few days (depending on how stupid the bandwidth numbers turn out to be, or whether we get told to quit it, by NOAA!) Therefore, please bear with us, and use commonsense when playing with this tool. Thanks.

---

The KMZ of the whole network link was usually around 4-5KB (pretty small !), but I ended up using over 8GB and almost 9GB this last month. I think part of this was due to people setting refresh rates to small intervals and/or forcefully updating it hoping that something had changed. Unfortunately, we can't alter the behavior of the users to not do this ( can we? ) , but I/we'd ask that you not do this as it could mean the difference between having this tool and not if the costs become prohibitive.

I'll get back to you in a bit.

Paul

Post Extras:

Quote:

---

Ok, first impressions.

1.) We need to break down the radards into smaller groups still. Being a programmer, I decided to try and break it like most good programmer would do. Anyway, long story short, ouch lol . I checked one group of radars (Short Range Reflectivity) and watched my v0.616 Client grow to well over 1GB in size. I think too many people will do that (or worse), and that's a bad thing. Even with warning and such, we either need to mitigate that risk even further, or dissallow them from doing that (currently impossible I think).

---

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.

Quote:

---

2.) Can we make the legend layer so that it requires explicit turn-on to be visible? I know that if people go through and set it like they want it with regards to legends on or not, those will keep their state even over refreshes....but it might be nice to maybe separate them completely from the actual radar to declutter, and make the legends a separate folder to be able to turn them on if the need arises.

---

Quote:

---

3.) Maybe further separate the radars by Coast (ie. Atlantic & Gulf) to further reduce the possibility of a catastrophic checkbox?

---

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.

Quote:

---

This is one reason why I wish that we could get the raw reflectivity data and display it as we wish by generating our own images from it etc......but I still think this is a mountain of work and probably not the right course. Let me know what you think and thanks for the work Jacko .

---

Post Extras:

Quote:

---

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.

---

Quote:

---

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.

---

Quote:

---

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!

---

Post Extras:

Quote:

---

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

Edited by BigJacko (09/29/05 06:57 AM)

Post Extras: