BigJacko
Tourist
Reged: 09/17/05
Posts: 70
|
|
Thanks to both of you for an EXCELLENT submission - this is a really fascinating tool, and I've been transfixed by it for days now... it's rapidly forming part of my life!
Having said that, being a 'never-satisfied' geek, I delved deeper into the 'Rita Radar' package that pdchawaii kindly donated to pseabury's project, and found a few things which caused me to raise an eyebrow.
It seemed to me that the coordinates of the LatLonBox on the overlay were very slightly 'off', when I compared them with current images.
Specifically, I went into the data at the NWS site (where the images are fetched from, on the RIDGE Radar experimental pages), and found that alongside each radar image, there is a corresponding GFW file, which denotes the bounding box for EACH separate picture. I have been looking carefully to see if these are changing much - and it doesn't appear that they have... but certainly, when I calculated the exact viewport positions, the numbers I got for some radar-sites where very slightly different to those already stored in pdchawaii's overlays. This made me wonder if some of them have changed in the intervening days, as radars are 'boosted' or otherwise tweaked, and thus the resulting image coefficients change when the final picture is 'squeezed' into a standard 600x550 pixel image.
What assumptions (if any) did you make, with regard to the GFW files, pdchawaii? Do you know if these change? And what was your approach to calculating the LatLonBox from these files? I have a slight feeling you may have applied the 600 and 550 multipliers to the wrong coordinate, possibly (either that, or the radar datasets DID change at some point recently).
Aside from all this, I have begun the process of creating an overlay set for ALL the RIDGE Radar sites, and for ALL their data products (they deliver seven: 3 types of reflectivity, 2 wind overlays and 2 for rainfall, plus a warning layer, and legends for all seven). So far, it's going very well, and I have developed a reasonably sensible set of sub-folders per site and type. My only worry at this point, is it is possible to unwittingly turn them ALL on at once, which would put massive load on the NWS servers, I reckon... (potentially 2325 refreshes per 5 mins!!!!) so I am trying to find ways to limit this possibility (ie, have one radar and only one product-type displayed at once, maybe).
And of course, the other concern is how best to 'scrape' the GIS positioning data from the GFW file on each refresh (if it turns out this is necessary - certainly NWS advise it), so that the overlay is correctly stretched over Google Earth. At the moment, KML doesn't allow this to be done in-situ on the client-side, and I thought it would be pointless me writing my own server-code to do this, if, ultimately, the end-result might be re-incorporated back into pseabury's package which is tied to his own server already (I know that is perhaps presumptive, but I'm sure once Rita is fully passed, we'll need these radar stations again, and perhaps having all data accessible from all the nearby sites on the coast will be useful - I just thought I'd save someone a job, and get the ball rolling).
|
pseabury
Tourist
Reged: 04/14/05
Posts: 241
|
|
The Rita Radar was a temporary addition to this link, although a much appreciated one. I wil remove it shortly though.
You bring up a good point that I've been looking at for quite some time....a coastal radar addition to this link. I looked at fetching the raw radar data from the NWS gateways, and producing my own images, but time contraints haven't permitted me to learn the file format and write my own parsing code (like I do for the SST).
The other good point you bring up is the probalem with properly geolocation image overlays. I've tried to be very careful with this, and I don't want to deploy something that degrades over time, or otherwise needs a lot of babysitting. That's why I'm also dissatisfied with the GOES floater images...it'd be nice if they'd either geoencode these for us, or at least provide bounding coordinates.
I'm not bent on keeping everything in this package solely my work, in fact I'd like to be able to include as much as possible (within reason) as long as it's quality stuff. If you want to make a sollid coastal radar for this package, I think we'd all be grateful....and it certainly would save me some time. Remember, less is more in some senses. There are other layers that provide entire CONUS coverage...what I think we're interested in here is Gul/Atlantic coast first (maybe expand to pacific storms and other Pacific stuff later). If we could more than just base reflectivity that would be nice as well. Radial velocity, rainfall rate, stormtop heights etc could prove useful for analysis.
The problem with limitations as far as the GE client and it's ability (or inability) to group and limit information is also something to tke into account. I've tried to make it easier to only turn on so much information at once, but the inherent mechanisms that the GE client has to limit information with folders and checkboxes leaves a little to be desired. I hate (as I'm sure others do) when I accidentally click a top level folder and then start pulling Megs of data accidentally.
Anyway, keep me posted if you come up with something and we'll work to integrate it if that's what you want. If you have any suggestion regarding the data that's already there feel free to comment as well.....better is better whether it comes from me or someone else.
Paul
|
BigJacko
Tourist
Reged: 09/17/05
Posts: 70
|
|
Quote:
I looked at fetching the raw radar data from the NWS gateways, and producing my own images, but time contraints haven't permitted me to learn the file format and write my own parsing code (like I do for the SST).
No problem there then... I've done it all, pretty much. I have a 'stock' folder arrangement for a given radar, with each legend+product pair, plus a generic warnings overlay. You're welcome to that bit, if it's of use.
Quote:
...geolocation image overlays. ... I don't want to deploy something that degrades over time, or otherwise needs a lot of babysitting.
Wholeheartedly agree there! That's kinda why I mentioned this at all, really. Without wishing to cast any aspersions on the work pdchawaii did, I was a tad worried that if the GFW/GIS files weren't regularly taken too, then things might drift.
Quote:
If you want to make a sollid coastal radar for this package, I think we'd all be grateful....and it certainly would save me some time. Remember, less is more in some senses. There are other layers that provide entire CONUS coverage...what I think we're interested in here is Gul/Atlantic coast first (maybe expand to pacific storms and other Pacific stuff later).
Agreed totally. It also limits the potential damage that could be done by having everything turned on at once (at least, to a degree).
I'm thinking of:
Brownsville, TX
Corpus Christi, TX
Houston/Galveston, TX
Lake Charles, TX (when it comes back online - sods law dictates that this is the one I did already, before it got blown over)
New Orleans/Baton Rouge, LA
Mobile, AL
NW Florida
Tallahassee, FL
one or all of Tampa Bay, Keywest, Jacksonville, Melbourne & Miami, FL (or some representative set - these seem like they must surely overlap a lot)
Charleston, SC
Wilmington, NC
Morehead City, NC
Wakefield, VA
Any point in going much higher?
Quote:
If we could more than just base reflectivity that would be nice as well. Radial velocity, rainfall rate, stormtop heights etc could prove useful for analysis.
The platter of offerings from the NWS RIDGE appears to be:
Short-range Reflectivity
Long-range Reflectivity
Composite Reflectivity
Storm Relation (wind) Motion
(wind) Velocity
1-hr Precipitation
Total Precipitation
and of course, the tornado/flood warning overlay. All templates done already... all I have to work on next is the GIS/GFW geolocation-file fetch. What language/system are you using to do your current parsing and fetching? I was going to knock something up in VB, but I can talk C++ and PHP (when pushed!  ). At the very least, I can knock something up that would be fairly simple to reapply elsewhere, if that'd save you some dev-time?
Quote:
...the inherent mechanisms that the GE client has to limit information with folders and checkboxes leaves a little to be desired. I hate (as I'm sure others do) when I accidentally click a top level folder and then start pulling Megs of data accidentally.
Oh yes! I've raised this in the KML discussion forum, in the hope that someone takes note - it IS a little silly to force developers to write programs that allow users to be hopeless inefficient, and I really hope they can change that.
Likewise, same grief with the 'View-Based Refresh' almost-but-not-quite being useful - that would make a great deal of difference too.
And of course, the inability of the language to cope with variables, maths, or separate URL-fetches (which would mean all the geo-location could be client-driven, and perfect).
Still - it's early doors, and I'm not complaining - just suggesting. Rome wasn't built in a day, and GE is better than anything else I've seen in this field.
Quote:
Anyway, keep me posted if you come up with something and we'll work to integrate it if that's what you want. If you have any suggestion regarding the data that's already there feel free to comment as well.....better is better whether it comes from me or someone else.
Nice attitude  Man after me own heart. I'll knock these up over the next day or two, and send it over to you as a PM or something. Then if it meets the standard, you're welcome to use it, if you like it.
|
Frank4
Master Blogger
Reged: 07/10/05
Posts: 1024
Loc: Cary, North Carolina, USA
|
|
Paul, I found this radar collection useful when I've watched hurricanes. I was able to see Rita well into the gulf with this collection.
It's from the U of Oklahoma.
--------------------
Frank Taylor - Author of Google Earth Blog (also available in Spanish)
All about Google Earth news, features, tips, technologies, and applications.
(If you have story ideas, please send me a private message.)
|
pseabury
Tourist
Reged: 04/14/05
Posts: 241
|
|
Big Jacko,
Quote:
I'm thinking of:
Brownsville, TX
Corpus Christi, TX
Houston/Galveston, TX
Lake Charles, TX (when it comes back online - sods law dictates that this is the one I did already, before it got blown over)
New Orleans/Baton Rouge, LA
Mobile, AL
NW Florida
Tallahassee, FL
one or all of Tampa Bay, Keywest, Jacksonville, Melbourne & Miami, FL (or some representative set - these seem like they must surely overlap a lot)
Charleston, SC
Wilmington, NC
Morehead City, NC
Wakefield, VA
Yessir, maybe even up to New York Area...occasionally get an Atlantic storm up that way. The problem with the NSSL CONUS link (Like the one Frank attached below, which I'll reply to in a second) is that it's too much, and it's too big. I think for our purposes we want to focus in (and use resources) on what we are interested in only. I like the idea of using the Ridge Radars (NWS Nexrad)...BUT.
I toyed with the idea of adding the Ridge Radars myself when pdchawaii gave the Rita Radar coverage, but I found a couple of problems that I didn't particularly like about it so I didn't put forth the effort and jsut used what he provided. These may be nit-picks, but I've tried to keep this link as nice as possible and maybe I'm just being unrealistic. First, I noticed that at some points in time certain sites (Corpus Christi for example) weren't consistent with the other sites. For instance, CC's ground clutter had a totally different return signal strength for ground clutter than the rest. This made CC red while everything else was blue (50db vs 5db return strength via the scale provided). I'm not sure this is a common occurance, but it was annoying nonetheless. Along the same lines, the ground clutter from these sites is excessive isn't it? Now for me, and probably a lot of you that understand radar this isn't a problem, but for the layperson that is looking at the overlay and doesn't understand how radar works I can imagine them thinking that it's wrong, or broken, or just stupid. I mean if a normal user that expects to turn on the radar layer and expects to see only weather, turns it on and the coast lights up like a Christmas tree.....they may get turned off and/or confused by it. This is one area where the NSSL and other radar images that are somewhat post-processed are better. Again, maybe being too picky, but just trying to convey the point. This also may be the best we can do, and that's fine also......I guess I just don't know for sure and so would raise the question.
Quote:
The platter of offerings from the NWS RIDGE appears to be:
Short-range Reflectivity
Long-range Reflectivity
Composite Reflectivity
Storm Relation (wind) Motion
(wind) Velocity
1-hr Precipitation
Total Precipitation
Maybe the compostite solves the problem I described above? I should have fully investigated before responding. But all-in-all, most of those are what would be nice. Basically anything that would prove useful in following a storm without duplicating data.
Quote:
Nice attitude Man after me own heart. I'll knock these up over the next day or two, and send it over to you as a PM or something. Then if it meets the standard, you're welcome to use it, if you like it.
First off, that's awesome. I look forward to seeing what you come up with.
Secondly, I'm not setting standards here per se, but like you would like to provide the most amount of information that is useful AND, to be blunt, not just trash to say that it's in there. I basically don't want to just shoehorn stuff in there just because we can....you know what I mean. I'd also like to make this as much of a community effort as possible.....I may have started this but am not stupid enough to think that someone can't do something better or provide something different that would be of use. Next storm season this could be 1000x better than I made it this year, and I hope it is. The only reason I've kept a little bit of control over what has been in it so far is because #1 my name has been on it so far, and #2 I've had to limit it to what my resources can handle as far as time, ability, and bandwidth are concerned.
Also, from a technical standpoint, this is mostly implemented on top of the .NET framework in C#...only because I'm good at it, and it's super easy to rapidly develop in it. I used a fairly quick and dirty approach to the code because I basically started this while storm season was in full swing. I need to spend an entire weekend going back and cleaning up the code before I let anyone see it. Kinda like cleaning up the house before company arrives lol.
Hopefully as the GE Client API evolves, and more data becomes available from people who see the benefit of making it geo-friendly, we can shine this link up to something much better than it is now.
Paully
|
pseabury
Tourist
Reged: 04/14/05
Posts: 241
|
|
Frank,
Like I said above.....I like that layer,and admit that I've used it from time to time for macro views of what's going on, but there are a couple reasons that I'm not sure we want it.
First, the files it loads are big.......maybe not a problem in the future, but as of now it takes forever to load and is a bit unwieldly for what we want I think. It also covers the entire CONUS, which is great, but not something that is in the scope of this link. I think we'd rather go smaller with both coverage and file size. This is something that we should discuss and be on the lookout for so that we can find the data that best fits our needs. Quality over quantity is one of my mottos  .
Considering that this link and the other data files that it encompasses got hit over 1,000,000 times in the past week or two........size and efficiency is something that we should definitely keep in mind.
Paully
|
BigJacko
Tourist
Reged: 09/17/05
Posts: 70
|
|
Quote:
Yessir, maybe even up to New York Area...occasionally get an Atlantic storm up that way.
Okeydokey - will extend up to NY then. Being a Limey, I'm not too familiar with how far up these hurricanes regularly go - so, if in doubt, my policy is to ask!
Quote:
First, I noticed that at some points in time certain sites (Corpus Christi for example) weren't consistent with the other sites. For instance, CC's ground clutter had a totally different return signal strength for ground clutter than the rest. This made CC red while everything else was blue (50db vs 5db return strength via the scale provided). I'm not sure this is a common occurance, but it was annoying nonetheless.
Yup, I've noticed this myself. That was the main motivation behind me deciding to add in the Legend overlay too - that way, even if the image returned is 'unusual', the user can at least see that the legend is referring to a different range of return strengths, and (hopefully) apply logic thereafter to what they are seeing. No guarantee, of course, but it's what the NWS themselves do (and if it's good enough for them...)
Quote:
Along the same lines, the ground clutter from these sites is excessive isn't it? Now for me, and probably a lot of you that understand radar this isn't a problem, but for the layperson that is looking at the overlay and doesn't understand how radar works I can imagine them thinking that it's wrong, or broken, or just stupid. I mean if a normal user that expects to turn on the radar layer and expects to see only weather, turns it on and the coast lights up like a Christmas tree.....they may get turned off and/or confused by it. This is one area where the NSSL and other radar images that are somewhat post-processed are better. Again, maybe being too picky, but just trying to convey the point. This also may be the best we can do, and that's fine also......I guess I just don't know for sure and so would raise the question.
I see the problem, but like you, don't have a solution for it. I guess really it just behoves the layperson to WISE UP and take the time to learn something they don't understand. We can do this with maybe judicious use of URLs linking to the 'Idiot's guide to radar-returns' (if there is such a document ) or maybe just the NWS FAQs?
My mission here is "enablement" primarily - giving people who know what they need, the ability to access it via one clean and handy interface in Google Earth. Educating people is a secondary consideration, really - and I expect them to take at least the most-basic steps to further their own learning. In a nutshell, that basically means I think we should give them the pointers, but responsibility for usage and development of their own brains, lies with them.
Quote:
Also, from a technical standpoint, this is mostly implemented on top of the .NET framework in C#...only because I'm good at it, and it's super easy to rapidly develop in it. I used a fairly quick and dirty approach to the code because I basically started this while storm season was in full swing. I need to spend an entire weekend going back and cleaning up the code before I let anyone see it. Kinda like cleaning up the house before company arrives lol.
LOL - I know exactly what you mean (especially having spent time this morning doing exactly that myself, in terms of tidying up the attached KMZ!) Anyway, cool - I may be able to pseudocode the logic for "how to fetch and apply the GIS files", in such a way that when you rebuild it in .NET/C# that it's a quick job. We'll see. I really ought to get more involved with .NET.... I've tended to shun it, because it looks like M$ hold all my code remotely by the short-and-curlies, and I'm not 100% sure I like that. But I've probably got the wrong end of the stick... it wouldn't be the first time
Quote:
Hopefully as the GE Client API evolves, and more data becomes available from people who see the benefit of making it geo-friendly, we can shine this link up to something much better than it is now.
Sure we can! It's pretty darned useful already, and looks good, and it's a credit to you and the other folks who have submitted stuff for inclusion. On a personal level, it provided a HUGELY exciting and entertaining insight into Rita's visitation, which is not something I would normally expect to see so clearly, from this far off, UK-based perspective. It struck me then how seriously useful this tool could be, for folks that (unlike me) weren't necessarily sitting in their comfortable living-rooms looking at drama vicariously unfolding thousands of safety-giving miles away, and who actually NEEDED to know this stuff, and NOW, so they could call up Mom to tell her when to get out. It's quite humbling, really.
This was backed up a bit when I found myself on the www.hurricanecity.com website watching a RealAudio live stream coming from somewhere in that area. Not only did it heighten the drama, and the sense of the scope of this ordeal, the guy running the show happened to use the old Keyhole program at one point, and brought up some very basic views of certain towns he thought would be most affected. Meanwhile, he was having to switch between programs and clumsily try and compare those maps, with the radar maps he had available in a different, NWS-specific program. I thought to myself... "How come he hasn't got Paul's overlay, and why isn't he using Google Earth?" Maybe next time, he will - and people may benefit from it, as a result?
Anyway - enough of my blather.... attached is ONE example NWS RIDGE radar set up as I envisage all the others would be. It features Brownsville, Texas, and all the products associated therein.
Points to note...
1 - you can probably tell just from this, why I think there are risks in providing TOO many radar folders in one package. There's just too much likelihood of someone ticking the top-folder, and selecting EVERYTHING for display, which would be as pointless as it is stupid, but GE's system currently doesn't enable me to prevent it. I do hope they change this in time.
2 - Brownsville's Velocity maps (at the time of writing) are currently not displaying transparency on their backgrounds. This is a fault their end - it's doing it on the NWS official site, too. Dunno why - maybe it'll fix itself again later - but the important thing is, it's not the KML at fault here - it's the returned image itself. [EDIT: This problem appears to have gone away now...]
3 - There are currently no warnings in force, so you can't see anything when you click this layer. In normal circumstances, if there WAS a warning, you'd see what the zoned areas meant, by looking at any of the Legends for any of the sub-products. They all carry that (even if they are different for the radar-return types and scales, on a per-product basis).
4 - GFW/GIS geo-location data being used for this current set, is the same as I was using a couple of days ago, in my own tests. It was calibrated perfectly then, but I have NOT checked today to see if the GFW data is different this time. I will be doing so later, and trying (again) to work out how pdchawaii's numbers became different, if it turns out the GFW has remained static all this time. This is the one area which worries me, slightly - but like I said, I know the algorithm to make it work - I just wish I could make it client-side, rather than have to force you or me to run a separate server just to calculate this 'munge' on each 5-minute fetch. Give us variables, GE, please [EDIT: I have now checked... Bad news.. The BRO GIS data for the N0R coefficients is different today than it was at the weekend. Darn. This means that the GFW files really DO need to be collected and parsed on EVERY fetch of the radar-image. I'll go write that code now!]
Any comments, feedback greatly appreciated. If you think it needs a different organisational approach, please let me know, and I'll start thinking - but this seems to me the most complete and accessible approach, given the limitations of GE. I'm open to ideas, though!
Note - I will probably remove this KMZ fairly shortly after I know you've received it, Paul. Sorry everyone else - you will get to see it in the long-run... but we want it to be right, and (most-especially) I couldn't live with myself if I 'killed' the NWS servers by releasing the full KMZ in haste. Please bear with us! Thanks...[EDIT: The KMZ has been removed now - updated & improved version for testing is posted later in this thread]
Edited by BigJacko (09/27/05 02:31 PM)
|
pseabury
Tourist
Reged: 04/14/05
Posts: 241
|
|
Quote:
I see the problem, but like you, don't have a solution for it. I guess really it just behoves the layperson to WISE UP and take the time to learn something they don't understand. We can do this with maybe judicious use of URLs linking to the 'Idiot's guide to radar-returns' (if there is such a document ) or maybe just the NWS FAQs?
My mission here is "enablement" primarily - giving people who know what they need
I hear ya, and still agree that it's a problem, but if we can't come up with an obvious answer, then all we can do is what we can do......until and unless we find a better way.
Quote:
LOL - I know exactly what you mean (especially having spent time this morning doing exactly that myself, in terms of tidying up the attached KMZ!) Anyway, cool - I may be able to pseudocode the logic for "how to fetch and apply the GIS files", in such a way that when you rebuild it in .NET/C# that it's a quick job. We'll see. I really ought to get more involved with .NET.... I've tended to shun it, because it looks like M$ hold all my code remotely by the short-and-curlies, and I'm not 100% sure I like that. But I've probably got the wrong end of the stick... it wouldn't be the first time
You ought to give C# a look definitely.......the ability to rapidly develop is unrivaled. And in fact, you aren't tied down to MS because C# is an open spec and currently has implementations for *nixes included Mac, Linux, etc via the Mono Project.
Now to comment on your points 1 by 1.
1.) Agree totally......like I said before, that's one of my biggest worries with a large dataset. I guess the only thing we can do is group the stuff as smartly as possible.
2.) Good to go.
3.) Good to go.
4.) Why in the heck does it change? Am I missing something here or is the radar moving? I haven't looked into it properly yet, but I don't understand why this would change periodically. Not a huge deal if we have to fetch it, but it violates my "keep it simple" policy lol.
Sorry it took me awhile to get back to you on this, but I had a lot of paying work to do today. In any case, it's very nicely done. A lot of data mind you, but a very nice start. We may want to think about how we group it in order to mitigate #1 above. Maybe a top level folder with all base reflectivities, and another folder with all relative velocities, and another with all 1hr precips etc. Just something to think about how it would be most useful for people using it...maybe the arrangement you currently have it in is best.....I just don't know until we talk about it and/or get some feedback.
Paully
|
BigJacko
Tourist
Reged: 09/17/05
Posts: 70
|
|
Quote:
Why in the heck does it change? Am I missing something here or is the radar moving? I haven't looked into it properly yet, but I don't understand why this would change periodically. Not a huge deal if we have to fetch it, but it violates my "keep it simple" policy lol.
Yeah - pain in the a&&, and no mistake! I'm guessing, but I wondered if it had something to do with radar strength. Like, if one day, the radar was running at a higher power, it would theoretically 'reach' further afield - and because the resulting image is ALWAYS a 600x550 pixel picture, there would be a change in the coefficient (ie, the ground-area size per pixel).
I haven't worked out (yet) exactly what size of variations we're seeing (in terms of ground size) - and it may not prove to be that much, even. But until I know, I'm wary of just lumping all images with a stock set of coordinates, in case someone is affected by that error one day in the future, and something bad happens as a result. People might well rely on this stuff, so I'm being careful!
However, I'm slowly starting to work out how it might be addressed. I had some luck today with a PHP experiment (thanks to another GE user on this thread here.
For a VERY short while, I've put it up as a PHP program here which does a synchronized GFW/GIS fetch and then gives you a KMZ file for that radar (so that you then pull down the image and it's geo-located appropriately)
Give it a play-around, by all means.
It doesn't yet feature the warnings overlays, nor the legends (but I only have one pair of coding hands, see ). I did it more to find out how easily I could generate KMZ, and parse the geo-location files, rather than this be an 'end-product'... so expect that link to disappear in a few days, when I've cracked the right approach for the final version.
Quote:
Sorry it took me awhile to get back to you on this, but I had a lot of paying work to do today. In any case, it's very nicely done. A lot of data mind you, but a very nice start. We may want to think about how we group it in order to mitigate #1 above. Maybe a top level folder with all base reflectivities, and another folder with all relative velocities, and another with all 1hr precips etc. Just something to think about how it would be most useful for people using it...maybe the arrangement you currently have it in is best.....I just don't know until we talk about it and/or get some feedback.
Thanks for the compliments - and don't worry about the delay. I had a lot of paid work on today, too... but I managed to get it done and still have time for a play-around. Tomorrow I may not be so lucky
I think I'm in agreement with your idea for the hierarchy, because it reduces the number of overlaps that would be mutually exclusive, if the user ticked a high-level folder. Obviously, there's nothing we can do if they tick the very top one - but it makes more sense to have them 'bagged together' in terms of data-product. That way, if someone ticks '1-Hour Precipitation', at the high-levels, they'll see all coastal radars' rainfall images, plastered next to each other along the coast.
This is better than my original approach (to put them all in groups of each radar station) - which would mean if someone ticked a 'Lake Charles' tickbox at the high-levels, they would see all of Lake Charles' 7 data-products on top of each other (and thus mostly an unreadable mess).
Convenience-wise, I guess it all depends whether people tend to 'hunt by product-type' or 'hunt-by-radar-station' for their info, as to which is the best approach.
But 'safety-wise', it's probably more sensible to group things by data-type, rather than location, because at least then what's returned will usually make more sense.
Anyway - probably more to report tomorrow, if all goes well! Ta-ta for now!
|
BigJacko
Tourist
Reged: 09/17/05
Posts: 70
|
|
EDIT: This Network Link has now been updated, and moved to this post here. Please read the warnings below anyway, before jumping to get the new file! Thanks
Well, I think I've done it... pretty much!
Attached is a KMZ file containing a Network Link to a remote KMZ file which holds all the coastal radar stations and all of the products they offer.
WARNING!!!!
There is a huge amount of data in this collection. DO NOT tick the top-level folders in either the Network Link itself, or the NWS RIDGE Radar Folder below it, or you will cause a huge pullback of data from the NOAA/NWS servers and possibly stall them.
When you first download and install the attached KMZ file, it SHOULD automatically fetch the sub-folders from my server. If this doesn't happen, try refreshing the Network Link (called Coastal Radar, at the very top level), by right-clicking on it, and then selecting Refresh from the drop-down menu.
When the folders have loaded, use the black arrows to open them and navigate downwards to the radar data-types you're interested in. Once again, DO NOT tick the high-level checkboxes!
When you finally get inside a 'data type' folder (such as Short-Range Reflectivity, or 1-hr Precipitation), you can safely select a few radar station names using their nodes. (Eg, put a tick next to Brownsville, TX, to overlay the chosen data-type, the warnings in force at that station, and the Legend).
You can, if you desire, go one level deeper inside each station, and turn off the warnings or the legend, if you prefer a clearer display.
Don't go nuts.... don't select too many radar-stations at once, and certainly, don't have multiple data-types showing for the same stations, if you're looking at more than two or three. Do the math... if you choose too many, it is possible to end up causing HUNDREDS of SEPARATE file-fetches from the same poor NOAA/NWS server, ok? Each station has 7 different types of data, plus 7 Legends, and 7 Warnings (which are actually the same files anyway). With all 21 stations & everything else on, you would be doing 441 file-fetches every 5 minutes!!!
Other information:
The Network Link is set to refresh every 4 hours, in order to get a replacement set of sub-folders from my server, and thus keep the geo-location data fairly fresh. This seemed more sensible than having EVERYBODY refresh the geo-location files via my poor server, every five minutes! It may, however, result in the occasional overlay not being pixel perfect in its position. Such is life. I'll be monitoring and tweaking this as we go forward, depending on what bandwidth gets eaten.
The radar stations themselves are set to refresh automatically from the NOAA/NWS site, every five minutes, so apart from chosing the stations you want to see, you should NOT need to manually refresh those (and you are advised against it, really). Every five minutes, your copy of Google Earth will pull back new images for each station selected, for each data-type selected, PLUS the warnings overlay and Legend files (because even the Legend files regularly change). That is QUITE enough potential for inundating NOAA/NWS as it is, so PLEASE don't keep refreshing the station-entries manually. NOAA/NWS only update their files once every 5 minutes anyway, so banging it won't actually get you anything new, ok?
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.
Edited by BigJacko (09/29/05 06:58 AM)
|
|
Previous
Index
Next
Threaded
[Re: 
Edit
Reply
Quote
View in Google Earth
