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.
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.
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  .
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!
|
Previous
Index
Next
Flat
Re: Coastal Radar Network Link (v1.0)
Edit
Reply
Quote
