I like what you did with this module.. But I do have a few items I would like to see incorporated into this.

1) Ability to enter a zipcode and let it determine the GPS coordinates it requires for pulling the data.

2) Ability to create a "Users Local (x) Day Forecast" using the zipcode.

3) You mentioned in the documentation about enabling the extra data into the display.. Perhaps an option to turn this on/off in the configuration page?

4) Perhaps incorporate elements of the Weather module code to let it post Current Conditions, perhaps any weather alerts as well.. Along with the weather alerts, perhaps allow us to have an "Alerts" block where if there is a major weather alert (Severe Thunderstorm Warning, Tornado Warning, etc), it could post the NOAA Alert into that block until the Alert expires? (I know THAT would be a major bit of coding, but would also be a great addition to any weather modules.

Greywolf

Comments

dwaine’s picture

dwaine commented
Assigned: Unassigned » dwaine

Hi Greywolf,

Thank you for your interest in our module. I'll respond to your ideas by number.

1 and 2. The module is currently designed to serve data for just one location. But I believe you are suggesting a change that allows zip codes to be entered by users, converted automagically, and then the data presented to the user. This is a fine idea and if you take a look at our weather coding sandbox site www.raceonedesign.com/weather you will see we are familiar with the technology to make that happen. We would have enjoyed adding that additional feature set to this module. But we had to set limits. Our compromise was to present a limited 'out of the box' feature set but to also expose the nws_weather_NDFDgen() function, give coders an example on how to call it, and let them leverage the work we've done against the NOAA soap server.

3. Are you referencing this text in the README.txt file?
"Developers who would like to retrieve data for multiple points or who wish to retrieve more data (wind speed, wind direction, etc.) can..."
This is where weather data gets exciting and frustrating all at the same time. NWS offers just over 50 pieces of data. When they are returned from the SOAP server in an XML document they must be parsed. And there's the rub. Different data is XML encoded differently. Some is simple. Other is not. Some are hourly. Some are twice daily. Each variation can require new code. Instead of trying to build a module that did everything for everyone but wouldn't be done for months we chose the information that 99% of the population is likely to be interested in and offered it as the default. Again, we've tried to compromise by exposing nws_weather_NDFDgen() for those coders who want weather data for the remaining 1% of users. (I made up that 99%/1% split. But you get the idea that most folks aren't interested in Dew Point or Three-month Total Precipitation Above Median.)

4. From a usability stand point this sounds good. But when we start looking at some of the technical issues it starts to be a problem. The biggest road block is the concept of predicted (forecast) data which is available for any and all points on the map, and observational data, which is only available where someone has built a weather station. An additional factor is the number of 'products' available from NOAA. We believe that to keep the scope of these modules within reason we will probably have data from just one product per module for a while. I know that is not what everyone wants to hear, but weather data is complicated and BIG. We are doing our best to take one bite at a time to give back to the Drupal community just a little bit more weather data than what was available when we started.

Thanks for your interest in nws_weather.

dwaine’s picture

dwaine commented
Status: Active » Closed (won't fix)