phpweather-devel — General development talk and discussions.

Re: Does the list still work?

[Martin G. <gim...@gi...>]

Martin Geisler <gim...@gi...> writes:

> Hello everybody...
>
> I seem to be having trouble posting to the list?!  Let's see if this
> one get's through...

Sorry about the spam, the list obviously works.  But SourceForge has
made some kind of new check that meant that I couldn't post via my
normal SMTP server, mail.bolignet-aarhus.dk, so I'm now posting
through my own :-/

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather:   Shows the current weather on your webpage and
PHP Shell:     A telnet-connection (almost :-) in a PHP page.

Does the list still work?

[Martin G. <gim...@gi...>]

Hello everybody...

I seem to be having trouble posting to the list?!  Let's see if this
one get's through...

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather:   Shows the current weather on your webpage and
PHP Shell:     A telnet-connection (almost :-) in a PHP page.

Does the list still work?

[Martin G. <gim...@gi...>]

Hello everybody...

I seem to be having trouble posting to the list?!  Let's see if this
one get's through...

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather:   Shows the current weather on your webpage and
PHP Shell:     A telnet-connection (almost :-) in a PHP page.

Does the list still work?

[Martin G. <gim...@gi...>]

Hello everybody...

I seem to be having trouble posting to the list?!  Let's see if this
one get's through...

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather:   Shows the current weather on your webpage and
PHP Shell:     A telnet-connection (almost :-) in a PHP page.

Re: Using DB to cache METARs ?

[Phil P. <phi...@sw...>]

I turned on *everything* for verbosity, and here's what it says....



Debug: get_location(): Looking for location in the database.

Debug: The METAR is not set, I'll try to find the METAR in the database..

Debug: Returning this row from the DBA database:
YSSY 040627Z 03021G34KT CAVOK 27/19 Q1007 NOSIG:1073197620.

Debug: get_metar_from_db(): Found the METAR in the database.

Debug: get_location(): Using old location: Sydney Airport, Australia.

Debug: get_metar_from_db(): The METAR for Sydney Airport, Australia was 
1073114715 seconds too old..

Debug: get_location(): Using old location: Sydney Airport, Australia.

Debug: get_metar_from_web(): Updating METAR for Sydney Airport, Australia.

Debug: Updating this row in the DBA database:
YSSY 040627Z 03021G34KT CAVOK 27/19 Q1007 NOSIG:1073197620.

Debug: get_location(): Looking for location in the database.

Debug: The METAR is not set, I'll try to find the METAR in the database..

Debug: Returning this row from the DBA database:
YSSY 040627Z 03021G34KT CAVOK 27/19 Q1007 NOSIG:1073197620.

Debug: get_metar_from_db(): Found the METAR in the database.

Debug: get_location(): Using old location: Sydney Airport, Australia.

Debug: get_metar_from_db(): The METAR for Sydney Airport, Australia was 
1073114720 seconds too old..

Debug: get_location(): Using old location: Sydney Airport, Australia.

Debug: get_metar_from_web(): Updating METAR for Sydney Airport, Australia.

Debug: Updating this row in the DBA database:
YSSY 040627Z 03021G34KT CAVOK 27/19 Q1007 NOSIG:1073197620.

Debug: get_location(): Using old location: Sydney Airport, Australia.

Debug: The METAR was set - I'll just use that..

Debug: get_location(): Using old location: Sydney Airport, Australia.

Debug: The METAR was set - I'll just use that..


FYI: the METAR timestamp is 040627Z, ie 06:27 UTC on the 4th.
Time now is 07:23UTC on the 4th, so it should have decided it was within 
the cache-timeout and not gone to the web.


Hopefully someone out there can gimme a hand to work this one out.

Thanks,
PhiL P

Phil Pierotti wrote:
> Supposedly using a DB of some kind to cache METARs makes things faster.
> Is there any to DEBUG this?
> Because I'm finding it's simply not any faster at all.
> 
> (and FYI I don't have shell access to the machine, so any debug will 
> have to be via PHP scripting or something)
> 
> Page generation takes anywhere from 1.4 to 1.9 seconds.
> When I use NO DB, *and* when I use Sleepycat DB3.
> 
> The METAR was generated less than 1 hour ago, so after I've refreshed 
> the page a couple of times, in theory the data should be in the 
> database, right?
> 
> Lemme know if you have any ideas where I can look to fit it and get the 
> caching working. As obviously ~1.5 seconds per page is simply not 
> accceptable.
> 
> Thanks
> Phil P
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> PHPWeather-devel mailing list
> PHP...@li...
> https://lists.sourceforge.net/lists/listinfo/phpweather-devel
> 
> 

Using DB to cache METARs ?

[Phil P. <phi...@sw...>]

Supposedly using a DB of some kind to cache METARs makes things faster.
Is there any to DEBUG this?
Because I'm finding it's simply not any faster at all.

(and FYI I don't have shell access to the machine, so any debug will 
have to be via PHP scripting or something)

Page generation takes anywhere from 1.4 to 1.9 seconds.
When I use NO DB, *and* when I use Sleepycat DB3.

The METAR was generated less than 1 hour ago, so after I've refreshed 
the page a couple of times, in theory the data should be in the 
database, right?

Lemme know if you have any ideas where I can look to fit it and get the 
caching working. As obviously ~1.5 seconds per page is simply not 
accceptable.

Thanks
Phil P

Re: Report Time in 2.2.0?

[Phil P. <phi...@sw...>]

After a little searching, I found where the 'decode the time from the 
METAR data' was *commented out* from decode_metar(). UnCommenting it 
returned the time decoded from the METAR itself.

I'd still be interested to learn where (else/oherwise) it was getting 
time from, and why it was done that way. (I'm new to this, so maybe 
there's a good reason for it?)

Thanks,
PhilP

Phil Pierotti wrote:

> mmm , time passes, Sydney issues a new METAR report.
> 
> The time displayed from PHPweather hasn't changed, (ie still showing 
> 'The report was made a moment ago, at 03:14 UTC. ') even though the raw 
> METAR data says 030000Z, and the other data in the displayed report are 
> updated.
> 
> I'd be interested to hear someone explain why the text display of the 
> time of the report bears no relationship to the reality of the actual 
> METAR timestamp, and how/where in the code I can fix that.
> 
> Thanks,
> Phil P
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> PHPWeather-devel mailing list
> PHP...@li...
> https://lists.sourceforge.net/lists/listinfo/phpweather-devel
> 
> 

Report Time in 2.2.0?

[Phil P. <phi...@sw...>]

mmm , time passes, Sydney issues a new METAR report.

The time displayed from PHPweather hasn't changed, (ie still showing 
'The report was made a moment ago, at 03:14 UTC. ') even though the raw 
METAR data says 030000Z, and the other data in the displayed report are 
updated.

I'd be interested to hear someone explain why the text display of the 
time of the report bears no relationship to the reality of the actual 
METAR timestamp, and how/where in the code I can fix that.

Thanks,
Phil P

Re: bug in 2.2.0 ?

[Phil P. <phi...@sw...>]

I printed it out, it's empty.
(ie enclosed in single quotes, prints out consecutive single quotes)

[ugh]

Yeah, the last 1.?? version (I have no idea which, it was a while ago) I 
played with worked fine. 2.2 comes with TAF decoding, so I thought I'd 
play with that. Unfortunately, either it's broken or I've not 
uploaded/installed it correctly.

Thanks,
Phil P

KISS wrote:

> Morning Phil,
> quick dumb question, what have you got in $cc_temp ?
> For your else statement
> $cc = $cc_temp;
> Just to clear things up as to if/else statement for return of info. I am 
> not personally using version 2.2.0 as I was happy with version 1.62 and 
> have had no need to update, but have to start with the basics to help you.
>  
> cheers and regards
> Gregg
> Cairns, Queensland
> 
>     ----- Original Message -----
>     *From:* Phil Pierotti <mailto:phi...@sw...>
>     *To:* php...@li...
>     <mailto:php...@li...>
>     *Sent:* Saturday, January 03, 2004 9:07 AM
>     *Subject:* bug in 2.2.0 ?
> 
>     I've just downloaded 2.2.0
>     Unpacked it on my web server
>     Configured it through the configuration webpage
> 
>     HTTP to index.php
>     Select country
>     Select Airport/ICAO
>     Click SUBMIT
> 
>     returns back to the default form - no METAR data displayed.
> 
>     Turned on Warnings as well as errors.
>     No warnings/errors displayed.
> 
>     Ran the test program, no problem.
>     Ran the 'speed test' program, no problem (though, obviously slow, as
>     I'm
>     not using a database).
> 
>     I added the following lines into the output, for debugging.
>     (after echo output)
> 
>       echo "<br>Here's the RAW output data<br><pre>\n";
>     print_r($data);
>     echo "</pre>\n";
> 
> 
>     NO data displayed.
> 
>     I added many and various 'debug comment' lines in odd places, appended
>     to $output.
> 
>     It *always* and *for every country/ICAO* says "ICAO was invalid".
> 
>     if ($icao != '') {
>     $output .= "<br>we got an ICAO<br>\n";
>        $weather->set_icao($icao);
>        /* icao was passed, we resolve country code */
>        $cc_temp = $weather->get_country_code();
>        if ($cc_temp === false) {
>          /* turn icao off, it is not valid */
>          $icao = '';
>          $output .= "<br>ICAO was invalid<br>\n";
>        } else {
>          /* use resolved country code */
>          $cc = $cc_temp;
>        }
>     }
> 
>     Thanks,
>     Phil P
> 
> 
> 
> 
>     -------------------------------------------------------
>     This SF.net email is sponsored by: IBM Linux Tutorials.
>     Become an expert in LINUX or just sharpen your skills.  Sign up for
>     IBM's
>     Free Linux Tutorials.  Learn everything from the bash shell to sys
>     admin.
>     Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
>     <http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click>
>     _______________________________________________
>     PHPWeather-devel mailing list
>     PHP...@li...
>     <mailto:PHP...@li...>
>     https://lists.sourceforge.net/lists/listinfo/phpweather-devel
> 
>      
> 
>     ---
>     Outgoing mail is certified Virus Free.
>     Checked by AVG anti-virus system (http://www.grisoft.com).
>     Version: 6.0.557 / Virus Database: 349 - Release Date: 30/12/2003

Other Questions/Issues with 2.2.0

[Phil P. <phi...@sw...>]

I tried configuring PHPWeather to use MySQL (which I'm using quite 
happily for a variety of things).

PHPWeather refused to create the tables.

Of course, there's zero debug output (sigh).

My access to MySQL is 'localhost' (hosted by my ISP, as-is, no other 
options), and so I'm wondering if your script assumes/requires access 
via IP (ie refuses to use the local/unix socket access method).


Also:

I futz'd with your index.php and FORCED the $cc to 'AU', so it now 
downloads and decodes a METAR. Obviously there's something wrong 
somewhere (incorrect setup/missing file/permission??) but this lets me 
continue trying working on things.

I'm in Sydney, Australia.

A METAR that I decoded just now says "a moment ago, at 03:14 UTC".
Localtime 10:45am being GMT+10+1, so 03:14 UCT is not "a moment ago" 
(It's either 20 hours [and change] ago, or a little under 4 hours in the 
future).


Or am I missing something?

Thanks,
Phil P

bug in 2.2.0 ?

[Phil P. <phi...@sw...>]

I've just downloaded 2.2.0
Unpacked it on my web server
Configured it through the configuration webpage

HTTP to index.php
Select country
Select Airport/ICAO
Click SUBMIT

returns back to the default form - no METAR data displayed.

Turned on Warnings as well as errors.
No warnings/errors displayed.

Ran the test program, no problem.
Ran the 'speed test' program, no problem (though, obviously slow, as I'm 
not using a database).

I added the following lines into the output, for debugging.
(after echo output)

  	echo "<br>Here's the RAW output data<br><pre>\n";
	print_r($data);
	echo "</pre>\n";


NO data displayed.

I added many and various 'debug comment' lines in odd places, appended 
to $output.

It *always* and *for every country/ICAO* says "ICAO was invalid".

if ($icao != '') {
	$output .= "<br>we got an ICAO<br>\n";
   $weather->set_icao($icao);
   /* icao was passed, we resolve country code */
   $cc_temp = $weather->get_country_code();
   if ($cc_temp === false) {
     /* turn icao off, it is not valid */
     $icao = '';
     $output .= "<br>ICAO was invalid<br>\n";
   } else {
     /* use resolved country code */
     $cc = $cc_temp;
   }
}

Thanks,
Phil P

new question (celsius/farenheight formatting)

[Morgan N. <mor...@ho...>]

ok so i have a new question:

i figured out how to get my output almost how i want it. it currently reads:

10 °C (50 °F)

I would prefer it to read:

50°F/10°C

Any suggestions?

thank you,

Morgan

_________________________________________________________________
Send a QuickGreet with MSN Messenger 
http://www.msnmessenger-download.com/tracking/cdp_games

Farenheit temperature not printing

[Morgan N. <mor...@ho...>]

hello,

I have successfully stripped phpweather down to the level that i want, which 
is simply a weather icon and the current temperature, with no dew point. My 
only problem is that only celsius is printing out. This was the case even 
before I started stripping away features. Does anyone know why this might 
be?

_________________________________________________________________
Is your computer infected with a virus?  Find out with a FREE computer virus 
scan from McAfee.  Take the FreeScan now! 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

Re: Sorry! There's no data available for...

[Martin G. <gim...@gi...>]

"Eyvind Kjersem" <ey...@kj...> writes:

> There are currently no data available for several, probably all,
> metar stations using phpWeather ver 2..

As long as they're current weather reports on http://gimpster.com,
then it's working.

The problem with phpweather.net is that SourceForge has a firewall
that prevents us from showing live data there.

If someone wants to remake the site, then please say so.

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather:   Shows the current weather on your webpage and
PHP Shell:     A telnet-connection (almost :-) in a PHP page.

Sorry! There's no data available for...

[Eyvind K. <ey...@kj...>]

There are currently no data available for several, probably all, metar
stations using phpWeather ver 2.. I read this have occurred more frequently,
but accoring for previous postings data should be available within hours.
(Martin Geisler  wrote in august "We've seen problems with NOAA's site
before, but they're usually gone in a matter of hours."). I've tried
severeal times last three days, using www.phpweather.net, but only to be
meet by "Sorry! There's no data available for..."

Is there any fix to this...

Best regards
Eyvind Kjersem

[ phpweather-Feature Requests-824876 ] French version

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

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

Category: Localisation
Group: phpweather-2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Julien Delvat (julduck)
Assigned to: Nobody/Anonymous (nobody)
Summary: French version

Initial Comment:
Hi,

Is there a plan for a French version?

If not, I can help you ...

Julien
(jul...@fr...)

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

>Comment By: Martin Geisler (gimpster)
Date: 2003-10-16 20:47

Message:
Logged In: YES 
user_id=104098

No, I haven't heard that someone should be preparing a
French version --- a translation from you would be very nice!

(PHP Weather is a project where things seam to happen in
jumps when someone suddenly has some time to work on it ---
there isn't much planning ahead :-)

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

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

[ phpweather-Feature Requests-824876 ] French version

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

Feature Requests item #824876, was opened at 2003-10-16 16:51
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377955&aid=824876&group_id=23245

Category: Localisation
Group: phpweather-2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Julien Delvat (julduck)
Assigned to: Nobody/Anonymous (nobody)
Summary: French version

Initial Comment:
Hi,

Is there a plan for a French version?

If not, I can help you ...

Julien
(jul...@fr...)

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

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

playing around with the Raw Data, problems with 'weather' groups

[Sifu R. <php...@ha...>]

Hi, php newbie here.... downloaded and installed phpweather 2.1.2 
today with no problems at all.... trying to pick thru the Raw Data to 
write a super simple PHP script that simply returns weather and 
temperature info to me.  I've figured how to get it to give me back 
things like location and temperature from reading thru some of the 
posts in the Archives... but can not figure out the 'weather' thing. 
i went thru the user and reference guide, but still dont understand 
what it means to have an "array of weather groups".  What are these 
"groups"?  They're not like arrays, right?

So far I've been able to get the location and weather from the code below:

$weather = new phpweather();
$data = $weather->decode_metar();
$location = $weather->get_location();
$temp = $data['temperature']['temp_c'];

I've been trying to do this to get the weather's descriptor, 
precipitation, obscuration etc, but obviously it doesnt work:

$w    = $data['weather']['proximity'];

can someone give me some tips? thanks a lot... phpweather rocks
-SR

-- 

[ 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-10-01 00:59

Message:
Logged In: YES 
user_id=104098

Great work! I don't know about the time_start and time_end

variables --- I just imagined an extra (optional) argument

to get_metar(). The argument would be a timestamp and

get_metar() would then return the youngest report older than

the timestamp. If no timestamp is given, then just return

the youngest report as we do now.



But if you like the other way better, then please implement

it that way. Or perhaps we could sidestep the time issue and

just make a method that returns reports x to y, sorted by

their timestamps. That should be very easy to implement as a

'SELECT * from pw_metars SORTED BY timestamp LIMIT x, y-x'

query. We could even have both :-)



Oh, and I cannot see why we're having that extra key in the

tables, a PRIMARY KEY (icao) ought to be enough.

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

Comment By: Etienne Tourigny (etienne_t)
Date: 2003-09-30 21:57

Message:
Logged In: YES 
user_id=626224

I've added the insertion in the archive databases in CVS. 

We still have to modify data_retrieval.php, pw_*.php and

maybe phpweather.php for the retrieval portion.   Do we add

2 class members to data_retrieval such as time_start and

time_end or implicitly put them in the call of get_metar()

and get_taf()?  I would prefer the first solution, and the

addition of a set_time() function.



On another note, I think that there is an unnecessary key in

the MySQL pw_metars table:   UNIQUE KEY icao (icao). 

There's already PRIMARY KEY  (icao).  The same thing for

pw_stations and pw_tafs. Can I remove this from pw_db_mysql.php?



  

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

Comment By: Martin Geisler (gimpster)
Date: 2003-09-30 16:50

Message:
Logged In: YES 
user_id=104098

That sounds like a good way to do it. We could then extend

the retrieval functions so that they take an optional

argument which indicate when to fetch data from. If the

optional argument is lacking, then just fetch the most

recent data available, as we do it now.

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

Comment By: Etienne Tourigny (etienne_t)
Date: 2003-09-30 03:09

Message:
Logged In: YES 
user_id=626224

I think that the recording should be done simply by the

backend at each insert or update.  I've done this in my own

version.  I use a table pw_metars_arch (and pw_tafs_arch)

that has an extra column (time) which is a timestamp

YYYYMMDDhhmmss.



I use this to get the data, although I haven't used this

aside from consulting the table.



I would gladly put this in cvs.







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

Comment By: Jonathan Dewey (lifetap)
Date: 2003-07-31 18:02

Message:
Logged In: YES 
user_id=800627

I was thinking about this after submitting the feature 

request.  I'm thinking that it would need to be written as a 

seperate utility or plugin to collect and archive the data.  

Most likely with the data already decoded.  Then put in hooks 

to the database.  IE, user goes to page to get todays 

weather, php sub grabs the temp for the same month/day, 

just a year before...   It was a thought I had, never said it 

would be easy.  Thanks for the quick reply thou.

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

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

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

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

Feature Requests item #775781, was opened at 2003-07-22 14:17
Message generated for change (Comment added) made by etienne_t
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: Etienne Tourigny (etienne_t)
Date: 2003-09-30 15:57

Message:
Logged In: YES 
user_id=626224

I've added the insertion in the archive databases in CVS. 

We still have to modify data_retrieval.php, pw_*.php and

maybe phpweather.php for the retrieval portion.   Do we add

2 class members to data_retrieval such as time_start and

time_end or implicitly put them in the call of get_metar()

and get_taf()?  I would prefer the first solution, and the

addition of a set_time() function.



On another note, I think that there is an unnecessary key in

the MySQL pw_metars table:   UNIQUE KEY icao (icao). 

There's already PRIMARY KEY  (icao).  The same thing for

pw_stations and pw_tafs. Can I remove this from pw_db_mysql.php?



  

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

Comment By: Martin Geisler (gimpster)
Date: 2003-09-30 10:50

Message:
Logged In: YES 
user_id=104098

That sounds like a good way to do it. We could then extend

the retrieval functions so that they take an optional

argument which indicate when to fetch data from. If the

optional argument is lacking, then just fetch the most

recent data available, as we do it now.

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

Comment By: Etienne Tourigny (etienne_t)
Date: 2003-09-29 21:09

Message:
Logged In: YES 
user_id=626224

I think that the recording should be done simply by the

backend at each insert or update.  I've done this in my own

version.  I use a table pw_metars_arch (and pw_tafs_arch)

that has an extra column (time) which is a timestamp

YYYYMMDDhhmmss.



I use this to get the data, although I haven't used this

aside from consulting the table.



I would gladly put this in cvs.







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

Comment By: Jonathan Dewey (lifetap)
Date: 2003-07-31 12:02

Message:
Logged In: YES 
user_id=800627

I was thinking about this after submitting the feature 

request.  I'm thinking that it would need to be written as a 

seperate utility or plugin to collect and archive the data.  

Most likely with the data already decoded.  Then put in hooks 

to the database.  IE, user goes to page to get todays 

weather, php sub grabs the temp for the same month/day, 

just a year before...   It was a thought I had, never said it 

would be easy.  Thanks for the quick reply thou.

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

Comment By: Martin Geisler (gimpster)
Date: 2003-07-27 17: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

[ 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-09-30 16:50

Message:
Logged In: YES 
user_id=104098

That sounds like a good way to do it. We could then extend

the retrieval functions so that they take an optional

argument which indicate when to fetch data from. If the

optional argument is lacking, then just fetch the most

recent data available, as we do it now.

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

Comment By: Etienne Tourigny (etienne_t)
Date: 2003-09-30 03:09

Message:
Logged In: YES 
user_id=626224

I think that the recording should be done simply by the

backend at each insert or update.  I've done this in my own

version.  I use a table pw_metars_arch (and pw_tafs_arch)

that has an extra column (time) which is a timestamp

YYYYMMDDhhmmss.



I use this to get the data, although I haven't used this

aside from consulting the table.



I would gladly put this in cvs.







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

Comment By: Jonathan Dewey (lifetap)
Date: 2003-07-31 18:02

Message:
Logged In: YES 
user_id=800627

I was thinking about this after submitting the feature 

request.  I'm thinking that it would need to be written as a 

seperate utility or plugin to collect and archive the data.  

Most likely with the data already decoded.  Then put in hooks 

to the database.  IE, user goes to page to get todays 

weather, php sub grabs the temp for the same month/day, 

just a year before...   It was a thought I had, never said it 

would be easy.  Thanks for the quick reply thou.

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

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

[ phpweather-Feature Requests-722729 ] add support for FD text (winds aloft)

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

Feature Requests item #722729, was opened at 2003-04-16 16:52
Message generated for change (Comment added) made by etienne_t
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377955&aid=722729&group_id=23245

Category: Decoding
Group: phpweather-2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Etienne Tourigny (etienne_t)
Assigned to: Nobody/Anonymous (nobody)
Summary: add support for FD text (winds aloft) 

Initial Comment:
Greetings,



Are there any plans to get FD text data?  I would use

that for flight planning purpose.  I am a seaconed php

programmer so I have no qualms in getting my hands dirty.  



Do you know any public facilities for retrieving FD

text previsions (winds aloft) for international areas?

 The U.S. noaa web-site and ftp site give you that

information but for US areas only.

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

>Comment By: Etienne Tourigny (etienne_t)
Date: 2003-09-29 21:11

Message:
Logged In: YES 
user_id=626224

I've been doing some work in this direction.  I'll probably

just include it in my soon-to-be-ready-for-a-release php

flight planning project, which uses phpweather.  If anyone

sees a use for this in phpweather, please say so.

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

Comment By: Martin Geisler (gimpster)
Date: 2003-04-22 16:41

Message:
Logged In: YES 
user_id=104098

I don't have any plans to add this to PHP Weather, but

you're very welcome to do so :-) PHP Weather could use such

a new feature...



I'm not an aviator, so I don't really know all that much

about this stuff, neither do I know where you can get this

kind of information for European airports. But try asking

the NOAA, perhaps they know something.

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

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

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

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

Feature Requests item #775781, was opened at 2003-07-22 14:17
Message generated for change (Comment added) made by etienne_t
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: Etienne Tourigny (etienne_t)
Date: 2003-09-29 21:09

Message:
Logged In: YES 
user_id=626224

I think that the recording should be done simply by the

backend at each insert or update.  I've done this in my own

version.  I use a table pw_metars_arch (and pw_tafs_arch)

that has an extra column (time) which is a timestamp

YYYYMMDDhhmmss.



I use this to get the data, although I haven't used this

aside from consulting the table.



I would gladly put this in cvs.







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

Comment By: Jonathan Dewey (lifetap)
Date: 2003-07-31 12:02

Message:
Logged In: YES 
user_id=800627

I was thinking about this after submitting the feature 

request.  I'm thinking that it would need to be written as a 

seperate utility or plugin to collect and archive the data.  

Most likely with the data already decoded.  Then put in hooks 

to the database.  IE, user goes to page to get todays 

weather, php sub grabs the temp for the same month/day, 

just a year before...   It was a thought I had, never said it 

would be easy.  Thanks for the quick reply thou.

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

Comment By: Martin Geisler (gimpster)
Date: 2003-07-27 17: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

Installation/Customization

[Joanthan D. <fa...@ya...>]

Hey everyone. I have got phpWeather installed and working (the test page comes up and everything works). My problem is that i would like it so i could have a text entry box where the user enters the stations icao identifier, then clicks on the submit, and it shows the weather as normal (only without the graphics). I dont really know how to code in php, so i would really appreciate if we could keep the answer to as little "tech stuff" as possible! lol :-) Also, is there a way to do the same thing as above, only with the TAF? Thanks so much for any help!!! :-D


---------------------------------
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search

[ phpweather-Feature Requests-577808 ] TAF - Terminal Aerodrome Forecasts

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

Feature Requests item #577808, was opened at 2002-07-05 11:25
Message generated for change (Comment added) made by antipasto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377955&aid=577808&group_id=23245

Category: Decoding
Group: phpweather-2.x
Status: Open
Resolution: Later
Priority: 5
Submitted By: Fabrizio Di Meo (fdimeo)
Assigned to: Nobody/Anonymous (nobody)
Summary: TAF - Terminal Aerodrome Forecasts

Initial Comment:
Hi all,

 I think that would be really useful if phpweather were 

able to decode the TAF also, what do you think 

about? :o)

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

Comment By: Thomas Michael Winningham (antipasto)
Date: 2003-09-12 13:31

Message:
Logged In: YES 
user_id=101704

Did you look at:

http://www.srh.noaa.gov/ftproot/MSD/html/note7.html ?

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

Comment By: Etienne Tourigny (etienne_t)
Date: 2003-09-11 11:55

Message:
Logged In: YES 
user_id=626224

Must of the stuff there

(http://www.nws.noaa.gov/mdl/icwf/avnfps/editor.html#TAFDe

coder) is already in the cvs code.  What I think remains is :



- time consistency checks

- Consistency Checks Within a Group

- NSW (no significant weather)

- NIL( AMD) (augmented data) ??



When I did the basic decoding I used the regex's in

decode_matar() and I found that only wind shear was missing

(it's not in METARs).  



I think the issue that must be resolved is translating the

various time-periods (FM BECMG TEMPO PROB) into hour-by-hour

information.  Or we could just spew out the time periods

as-is.  Perhaps we want to have a way of getting the

complete forecast for given hour(s)?  The difficulty lies in

the fact that some periods such as BECMG only give some data

such as wind but not visi or clouds...  Such as this example:



CYVR 111438Z 111512 12008KT P6SM SCT010 BKN060 TEMPO 1519

6SM -SHRA SCT008 BKN030 BECMG 1921 25010KT BECMG 0002 29013KT



So we could go through the periods in chronological order

and keep the old values that haven't changed while updating

the values that have changed (except things like descriptive

weather).     Keeping in mind that a TEMPO period is only

temporary and has no effect on subsequent periods.



Does someone have a good link that describes precisely the

meaning of the period types?





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

Comment By: Thomas Michael Winningham (antipasto)
Date: 2003-09-09 15:41

Message:
Logged In: YES 
user_id=101704

Hey I'd love to speed up the availability of this feature! 

Anyone know anything about extrapolating this information 

into hour-by-hour information? 



I found some great regular expressions for TAF on the bottom 

of this page at:

http://www.nws.noaa.gov/mdl/icwf/avnfps/editor.html#TAFDe

coder

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

Comment By: Martin Geisler (gimpster)
Date: 2003-09-05 15:44

Message:
Logged In: YES 
user_id=104098

Okay, welcome aboard! :-)

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

Comment By: Etienne Tourigny (etienne_t)
Date: 2003-09-05 13:55

Message:
Logged In: YES 
user_id=626224

Sure i'm interested in having CVS access.  Please register

me as developper and give me the proper cvs access.  I'll

discuss integration issues on the devel mailing list.

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

Comment By: Martin Geisler (gimpster)
Date: 2003-09-05 13:36

Message:
Logged In: YES 
user_id=104098

Sounds great! I can give you CVS access and then you'll be

able to incorporate your changes into the existing code. I

don't know exactly how your extension should be integrated,

but perhaps you already have an idea?



Let me know if you're interested and I'll include you as a

developer on the project.

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

Comment By: Etienne Tourigny (etienne_t)
Date: 2003-09-05 12:53

Message:
Logged In: YES 
user_id=626224

I've written en extension to retreive and decode TAF

forecasts.  It's not complete yet but the basics are there.

  The parts remaining are: pretty output, translation, full

testing, other backends than mysql, plus others I might have

missed.  Please let me know how I can contribute.  

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

Comment By: Martin Geisler (gimpster)
Date: 2002-07-11 15:34

Message:
Logged In: YES 
user_id=104098

Yes, it would be great if PHP Weather could parse TAF

reports... but it can't do this at the moment, and it'll be

a while before it can - unless someone finds the time to

write the code that is :-)

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-07-07 11:29

Message:
Logged In: NO 

yes, id love it if i could get predictions too ;-) 

It would be well amazing, ontop of the already great current weather 

reports ;-)





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

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