[ phpweather-Feature Requests-775781 ] Long term historical data - sql

[SourceForge.net <no...@so...>]

Feature Requests item #775781, was opened at 2003-07-22 20:17
Message generated for change (Comment added) made by gimpster
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377955&aid=775781&group_id=23245

Category: Databases
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Dewey (lifetap)
Assigned to: Nobody/Anonymous (nobody)
Summary: Long term historical data - sql

Initial Comment:
I was wondering about adding in long term storage of 
fetched METAR data.  I think it could be useful to be 
able to pull up data from previous dates for comparison 
and/or be able to do trending.

There are many possible ways to do it, but I was 
thinking to have a selectable feature that enables a 
seperate module.  For example I want to enable trending 
for ICAO KRDU.  Using sql this would create a table 
Trend-KRDU or such, (would be same for flat file thou 
larger and slower).  The module would run on an hourly 
cron as to not miss any data, and would insert metar, 
timestamp, etc, into both the currently used cache table 
and the ICAO trend table.  It might be easier to put the 
decoded metar info into the trend table, that would 
make searching a little easier.

From there record highs and lows, strongest winds, you 
name it, would be available with basic searches.  

Just a thought, I have been trending my local weather 
using metar.pl and mrtg, but I can' look for a specific 
day, etc.  

This looks to be a great program so far, keep up the 
great work.

----------------------------------------------------------------------

>Comment By: Martin Geisler (gimpster)
Date: 2003-07-27 23:20

Message:
Logged In: YES 
user_id=104098

I agree that it would be cool to store the data for longterm
analysis and trending. The question is how to do it?

As it is now, then all the database backends offer the same
functionality --- I don't know if we can keep it this way if
we begin with these kind of features.

One way of handling this would be to give the backends
methods that give you an iterator to the data stored. The
iterator returned by the null backend would already be at
it's end since the null backend doesn't store any new data,
whereas the proper backends would return a proper iterator
that would run through the data. The amount of data could be
limited by given a start and/or end date.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377955&aid=775781&group_id=23245