A suggestion for linking to model images in discussions...

Joined
Mar 21, 2005
Messages
1,191
Location
Kearney, NE
I made a suggestion in a forecast thread today regarding the limited usefulness of linking or posting to "so-many-hours-out" model images. Short description of the problem: The image you thought you were linking to changes on the next model run making the image no longer match the discussion point you were making.

Full description of my suggestion (and example of the problem) in this thread. We should not discuss my suggestion in the FORECAST thread, but rather discuss it here. Hopefully I made the forecast post follow the rules by re-linking to the images in the time frame that Tim was discussing.

Anyway, if you follow what I'm saying (or even if you don't) and want to discuss the suggestion, please do it here and not in the forecast thread. Thanks!

Darren Addy
Kearney, NE
 
I've been saving the images and pulling them from my web site to avoid this problem. It's a little inconvenient, but it does keep the images from becoming outdated as the new runs are released, and remains relevant to the post no matter how much time has elapsed. Some of the images, like the NCEP GFS ensemble maps

http://www.emc.ncep.noaa.gov/gmb/ens/fcsts...06_528_f264.gif

have date-and-run specific urls that don't become outdated, so these are safe to direct-link without fear of them getting overwritten by future runs.
 
This also holds true for NWS text products. If you link to a CoD page, please do not use the generic, 'most-recent' address (such as http://kamala.cod.edu/ok/latest.fxus64.KTSA.html ). Instead, hit "CLICK HERE TO GO TO PREVIOUS BULLETINS." and choose the specific product you want. For example, instead of the generic address given above, it' d better to link to http://kamala.cod.edu/offs/KTSA/0605181548.fxus64.html , which is a static link. The same goes for links from other sources, like the SRH Data page. In this case, hit the "[Printable]" link on top of the page, which will bring you to a static page. For example, instead of link to http://www.srh.noaa.gov/productview.php?pil=AFDOUN&max=51 , it'd be much better to link to http://www.srh.noaa.gov/printable.php?pil=...=20060518153519... If you link to the 'most-recent' product, the content of the page you are linking to will change as new products are issued.
 
I think a very large majority of us already have access to model data, be it on the web or locally... I think just saying "look at xxx on the yy-hr NAM" might be good enough, posting a page full of links or images we already look at just clutters up the thread.
 
I think a very large majority of us already have access to model data, be it on the web or locally... I think just saying "look at xxx on the yy-hr NAM" might be good enough, posting a page full of links or images we already look at just clutters up the thread.
[/b]

Well, one man's clutter is another man's meat.

While your comments certainly apply for those who already know what they are doing, I (for one) greatly appreciate the links and images because I'm still climbing the learning curve of meteorology/forecasting (and not going to school for it). Having somebody say: "here's what I'm seeing" with an explanitory image or link is greatly appreciated.

I don't think we should needlessly worry about "clutter" in a forecast thread. NOW threads that are being used (lowres) while on the road should certainly be free of unnecessary posts and images, but a FORECAST thread? I think they should be welcomed/encouraged there.

(my 2 cents)

Darren Addy
Kearney, NE
 
While your comments certainly apply for those who already know what they are doing, I (for one) greatly appreciate the links and images because I'm still climbing the learning curve of meteorology/forecasting (and not going to school for it).[/b]

Agreed. While I don't think we always need to imbed the images, the links themselves don't increase the bandwidth much and gives the reader the option to click on them (or not). While you might have access to the same/similar charts elsewhere, clicking on them directly in the message is certainly faster; especially in a mobile environment.
 
Back
Top