tommi_gi ,
If things have changed in the past year as to how these scripts work, forgive the oversight, I kinda gave up and moved on. When I was pondering it for my own work, I thought maybe that data collection could occur at the developer level, and then could be disseminated to the end user via a more efficient feed, like a database query.
For instance, a central server could spider the NOAA site periodically for the major metropolitan areas of every state. If you figure 3 to 5 queries per state, this would only be 150-250 queries for the US. Then the gathered data could be inserted into a database by area, efficiently, translated into data more readable by the scripts ( a single hash for current conditions and forecast, etc ) .
The actual polling of the weather source would take place only once per update period, per locale polled, instead of once for every end-user. Users would simply ping the developer's database to check for an update, and then get the bare minimum of what is needed, and only when there is new data. Much less traffic for weather sites, and much more efficient data for the end-user's software to manage. i.e. decoding a small string instead of parsing HTML.
Developers would essentially be mirroring the information, but in a much more useful and efficient form than HTML. Also, when the HTML format of the weather site changed, only the developer's spider would be effected, instead of breaking the end-users' scripts.
Again, this suggestion may be outdated, since it is based on the various solutions I worked on about a year ago. My apologies if so.
[Message Edited]