Aloitin jo pitkään mietintämyssyssä ollutta projektia eli wx-tietokannan uudelleenrakennuksen ;)
Suurin syy tähän on muutamat arvot jotka haluan että käyttävät samaa laskentatapaa mitä FMI:kin mistä en ollut varma miten WD tekee ne, eli päivän keskilämpötila, Lämpösumma (GDD), sekä Lämmitys- ja viilennystarve (HDD ja CDD).
Ja, yllätys, yllätys, kaikki muuttuivat.
Suluissa mistä infot niihin nappasin, tavoite oli että FMI:ltä mutta kaikkiin ei löytynyt vastausta.
- Päivän keskilämpötila käyttää 8 arvoa jotka otettu 3 tunnin välein ja jaettuna 8:lla. (FMI).
- GDD, päivän keskilämpö - 5 astetta, jos keskiarvo ollut yli tuon +5 asteen. (FMI)
- HDD, raja-arvona 17 astetta käyttäen vuorokauden keskilämpötilaa kun WD:ssä oletuksena 18.3 astetta eikä hajua mitä lukemaa se käyttää (FMI & Wikipedia)
- CDD raja-arvona 18 astetta, ei hajuakaan mitä WD:ssä on oletus. (Wikipedia)
Väsäsin kätevän pikkurikkisen php-häkkyrän joka selasi WD:n xxxxlg.txt-filut läpi ja puski ulos tuotoksen .sql-filuna jossa INSERT-komennot, 1 filu per vuosi. Jotta siitä ei tullut aivan mahdottoman suurta otin lukemat 10 min välein, siltikin rivejä kertyi yhteensä 280K. :P
Sen lisäksi se puski ulos yhden .sql-filun jossa yksi rivi peri päivä jossa maksimit/minimit ja keskiarvot käyttäen yllä olevia laskentatapoja.
Normi 92011lg.txt:in lisäksi skripti parsi myös 92011vantagelog.txt ja 92011lgsun.txt-filut läpi.
Nuo 7 filua (66 MB) uppasin dedille ja ajoin sisään dumpit mysliin ssh:lla, violá.
Kyseistä php-häkkyrää en suosittele ajettavaksi live-serverillä, sen verran hidasta ja raskasta oli tuo parsiminen :P ::)
Muutokset oli joskin seuraavat jos etusivua katselee, joka nyt toimii uudella kannalla. (Tilasto/vertailu-sivut toimii vielä vanhalla kannalla):
- kuukauden/vuoden keskilämpötila pitäisi nyt toimia myös kuukauden ensimmäisenä päivänä eikä näyttää mitä sattuu kuten WD:n customtagi tekee.
- GDD & HDD laskivat
- CDD nousi hitusen
Tuo FMI tapa mitata päivän keskilämpötila ei ole se tarkin mahdollinen, mutta he tekevät tuon todennäköisesti siksi, että aikoinaan on mittauksia tehty huomattavasti harvemmin ja silloin ollaan todennäköisesti käytetty tuota 3 tunnin välein otettua arvoa. Nykyään käytetään samaa, jotta pystytään tekemään vertailuja vanhoihin tilastoihin.
En tiedä tarkalleen miten WD keskilämpötilan laskee, mutta luulisi laskevan yksinkertaisesti siten, että jos tietoja tallennetaan minuutin välein logiin, niin tällöin lasketaan nämä kaikki minuutit ja jaetaan niiden määrällä. Näin saadaan todella tarkka vuorokauden keskilämpötila, kun mittauksia tehdään noin tiheesti :)
Itselläkin oli alkuun pitkään lämmitystarvelukuna tuo 18.3 mikä on vakiona WD:ssa. Nykyään kaikki tilastot on mitattu tuolla virallisella 17. Ainakin kaikki vähänkään virallisemmat mittaukset oli tehty juurikin tuolla 17 luvulla, joten sitä päädyin käyttämään itsekin.
Viilennystarveluvusta en tiedä, sillä sitä ei tietääkseni pääse WD:sta muuttamaan ollenkaan, ainakaan itse en ole löytänyt sellaista kohtaa, josta sitä voisi muuttaa.
Tein pientä reaserchia tuon keskilämpötilan suhteen ja itse asiassa FMI:n on yksi niistä tarkimmista virallisista mitä tutkailin.
Yksi yleisesti käytetty on niinkin utooppinen kun max + min / 2.
yr.no/met.no tais käyttää 4 lukemaa 6 tunnin välein / 4
näin myös sellaista kun max + min + x lukemaa y tunnin väelin / z määrällä
jne.
Mietin vain sitä, että eikö se periaatteessa ole aina tarkempi mitä useammin noita mittauksia tehdään? Tällöin vuorokauden keskilämpötilaan pääsee vaikuttamaan nopeat hyppäykset ja laskut päivän aikana, mutta jos mittauksia tehdää vaikka vain neljän tunnin välein, niin tällöin tuollaiset jäävät kokonaan huomiotta. Mutta toisaalta hyvä puoli tuossa että tekee oman kannan vastaamaan noita virallisia on se, että voi paremmin vertailla omia tuloksia virallisten kanssa :)
LainaaMietin vain sitä, että eikö se periaatteessa ole aina tarkempi mitä useammin noita mittauksia tehdään?
Noin munkin mielestä sen pitäisi olla, kaikki datarivit kasaan ja lopuksi jaetaan lukumäärällä.
LainaaMutta toisaalta hyvä puoli tuossa että tekee oman kannan vastaamaan noita virallisia on se, että voi paremmin vertailla omia tuloksia virallisten kanssa
Tuo oli juuri lähinnä munkin aatos tuossa että pystyisi paremmin vertailemaan virallisten kanssa kun laskentatapa on sama.
Tosin tein kokeen jossa käytin sekä tuota 8krt/päivä että kaikki rivit eikä se ero loppupeleissä kovin suurta ollut, joskin kyllä eroa on, mitä suurempi aikaväli sen pienempi ero, ylempi 8 lukemaa, alempi kaikki lukemat:
Eilen
13.47
13.94
Syyskuu
12.53
12.60
2011
6.89
6.88
No eipä tuo kyllä kovin merkittävältä erolta näytä, varsinkaan kuukauden ja vuoden osalta. Päivän osalta on vähän eroa, mutta ei tuo kyllä mikään hirmuinen ero siltikään ole.
Ei niin.
Pääasia mielestäni on kuitenkin se että koko sivu käyttää kauttaaltaan samaa laskentakaavaa, ei välttämättä se onko eroa 0.05 astetta siihen viralliseen. Mokoma erohan kuittaantuu moneen kertaan jo pelkälla anturin asennuspaikalla suuntas jos toiseen ;)
Se mitä huomasin tuossa kantaa rakennellessa on että on WD kyllä epeli..
Nuo xxxxlg.txt:it ovat kaikkea muuta kun "valiidit", on päällekkäisiä aikoja sekä sellainen kummallinen että monessa päivässä on klo 0:00-rivissä vielä edellisen päivän sademäärä.
Mysli huusi myös 4 kertaan tuota 5 vuoden dataa dumapttaessa aikaleimasta joka ei ollut valiidi (rakensin sen strtotime():lla).
Olisi todella kätevä jos joku kehittäis palikan jolla sais ne tsekattua ja korjattua.
Päällekkäiset ajat estää mm. Unique:n käyttöä myslin indexissä kunnes oon saanut siivottua ulos ne kun en kekannut mitään kätevää systeemiä saada ne parsittua ulos kun tein nuo sql-filut ilman että wamppi olisi mennyt ihan juntturaan. ;D
Kysmys lähialueen asemille:
Kuinka paljon satoi 1. ja 2. joulukuuta 2006? ;)
Mulla nuo 2 antaa yhteensä yli 180 mm :o
Lainaus käyttäjältä: weatherc - tiistai, 13.09.2011, 19:07
Kuinka paljon satoi 1. ja 2. joulukuuta 2006? ;)
Mulla nuo 2 antaa yhteensä yli 180 mm :o
Eipä tainnut silloin olla lämmitintä sadekipossa kun tuo vuotuinenkin sademäärä on noin pieni mutta aika lämmintä silloin näyttää olleen. :)
Lainaus käyttäjältä: weatherc - tiistai, 13.09.2011, 19:07
Päällekkäiset ajat estää mm. Unique:n käyttöä myslin indexissä kunnes oon saanut siivottua ulos ne kun en kekannut mitään kätevää systeemiä saada ne parsittua ulos kun tein nuo sql-filut ilman että wamppi olisi mennyt ihan juntturaan. ;D
Käytä joko INSERT IGNORE tai REPLACE.
http://dev.mysql.com/doc/refman/5.5/en/insert.html (http://dev.mysql.com/doc/refman/5.5/en/insert.html)
http://dev.mysql.com/doc/refman/5.5/en/replace.html (http://dev.mysql.com/doc/refman/5.5/en/replace.html)
Lainaus käyttäjältä: khyron - tiistai, 13.09.2011, 20:56
Käytä joko INSERT IGNORE tai REPLACE.
Niin joo, totta. Tosin, se ei paljoa lohduta kun WD:n logfilu voi näyttää tältä (se on suora kaappaus meikäläisen logista), siinä siis 20 riviä yhdelle 10 minuutin pätkälle...
1 9 2011 0 0 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 1 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 2 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 3 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 4 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 5 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 1 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 2 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 3 8.9 96 08.3 1003.6 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 0 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 6 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 7 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 8 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 9 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 10 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 6 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 7 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 8 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 5 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
Lainaus käyttäjältä: weatherc - keskiviikko, 14.09.2011, 01:47
Lainaus käyttäjältä: khyron - tiistai, 13.09.2011, 20:56
Käytä joko INSERT IGNORE tai REPLACE.
Niin joo, totta. Tosin, se ei paljoa lohduta kun WD:n logfilu voi näyttää tältä (se on suora kaappaus meikäläisen logista), siinä siis 20 riviä yhdelle 10 minuutin pätkälle...
1 9 2011 0 0 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 1 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 2 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 3 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 4 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 5 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 1 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 2 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 3 8.9 96 08.3 1003.6 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 0 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 6 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 7 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 8 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 9 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 10 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 6 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 7 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 8 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
1 9 2011 0 5 8.9 96 08.3 1003.7 0 0 270 0.0 0.0 0.0 368.8 8.9
Onko tuo siis muotoa:
mm dd yyyy hh mi ja loppu dataa?
Mikä siinä siis on se ongelma? Pitääkö kaikki data säilyttää ja saada jollain logiikalla eri aikaleimoille?
Mysqlimport ja LOAD DATA INFILE on muuten kans kätsyjä datan importointiin. http://dev.mysql.com/doc/refman/5.0/en/mysqlimport.html (http://dev.mysql.com/doc/refman/5.0/en/mysqlimport.html)
Lainaamm dd yyyy hh mi ja loppu dataa?
Juu.
Itse data-rivin parsiminen ei ole se ongelma vaan tuo että WD on tuossakin esimerkissä tuupannut kymmenen minuutin ajalle 20 riviä dataa kun niitä pitäisi olla se 10. Ja minuutit ovat ihan sekaisessa järjestyksessä.
Näin sellaisia kymmenminuuttisia jossa samalla minuutilla oli eri arvojakin.
Tuon lisäksi löytyy pätkiä jossa sama aikajakso voi olla kahteen kertaan. Siivosin jo ulos syyskuun alusta 2 tuntia 1.9 klo 00 - n 02 joka löytyi kahteen kertaan.
Eli tuo WD:n aikaansaama log-filu on kaikkea muuta kun valiidia. Ainakin oman kokemuksen mukaan WD:n ongelma ei välttämättä ole livedatan tallennus vaan silloin kun se purkaa loggeria, sen se tuuppaa ihan miten sattuu..
Siinä versiossa jonka puskin mysliin (jonka saan siis helposti vaihdettua uuteen versioon) niin otos on 1 rivi joka tasa 10-minuuttinen eli 00,10,20 jne. Mutta tuo sekaisuus aihetutti sen että samaa aikaa voikin löytyä useaan otteeseen.
Toisen taulukkona tein jossa 1 rivi per päivä jossa maksimit/minimit ja sen sellaiset. Siinä ongelman on päivävaihto ja se silly fakta että WD:n logissa edellisen päivän sade voi roikkua mukana vielä seuraavan päivän ensimmäisissä datoissa, varsinkin kuun vaihtuessa, jolloin kun käytin max(dayvals) eikä sinä päivänä satanut niin mysliin meni se edellisen päivän lukema.
Löysin ww-foorumilta LogFile-utilityn mutta kas vaan se ei toimi 64 bittisessä wintoosassa koska itse appi on 16 bittinen...
LainaaLöysin ww-foorumilta LogFile-utilityn mutta kas vaan se ei toimi 64 bittisessä wintoosassa koska itse appi on 16 bittinen...
Kopsasin filut usb-tikulle ja eikun emännän xp kehiin ;)
Jo ensimmäisestä kuukaudesta (2/2006) löytyi 55 erroria... heh... hmm...
EDIT: hehhe....ei juma kekka...
Format error: On line 22347 Date/Time 3/23 @ 18:60
Ja totta sieltä löytyy rivit "ajoille" 18:60 - 18:66...
EDIT2: No niin tsekattu kaikki logfilut tuolla utilityllä ja noita ihme minuutteja löytys aivan tolkuttomasti noista alun filuista, loppuivat suunnilleen 8/2007. Mutta ennen sitä sieltä löytyi parhaimillaan/pahimmillaan 1 per päivä tuollainen rypäs. Ei oikeen tiennyt itkeä vaiko nauraa kun minuutteja oli esim. 18:60-18:100 :P
Ei tuo että samoilla aikaleimoilla on useita rivejä, tai että ne on epäjärjestyksessä, pitäisi aiheuttaa mitään ongelmia myslille jois käytät noita INSERT IGNORE tai REPLACE lauseita, INSERT IGNORE jättää voimaan ekan löytyneen rivin ja REPLACE viimeisen. Jos taas ongelma on se että haluat keskiarvoja/summia/tms. kymmenen minuutin pätkistä niin mielestäni se kannattaisi tehdä kannassa.
Lainaus käyttäjältä: khyron - keskiviikko, 14.09.2011, 18:41
Ei tuo että samoilla aikaleimoilla on useita rivejä, tai että ne on epäjärjestyksessä, pitäisi aiheuttaa mitään ongelmia myslille jois käytät noita INSERT IGNORE tai REPLACE lauseita, INSERT IGNORE jättää voimaan ekan löytyneen rivin ja REPLACE viimeisen. Jos taas ongelma on se että haluat keskiarvoja/summia/tms. kymmenen minuutin pätkistä niin mielestäni se kannattaisi tehdä kannassa.
Totta, aatos on että muokkais tuota parsimis-skriptiä siten että se käyttää vain noita tasakymmenminuuttisia rivejä, tällöin tuo epäjärjestys ei haittane pahemmin sekä siihen komentoon lisätä tuo INSERT IGNORE. Pitää vaan laittaa checki siihen päivän vaihtoon ettei ota edellisen päivän sateita mukaan seuraavaan päivään sekä pakottaa vuosiluvun/kuukausiluvun siihen filun nimen lukuun eikä uskoa sitä mitä filussa on koska ainakin joissain on ensimmäiset lukemat edellisen vuoden/kuukauden.
Sivulla esim kk ja vv-lämpötilakeskiarvot jotka ovat etusivulla ovat suoraan kannasta avg(temp)-komennolla "FMI-tyylillä" eli käyttäen arvoja 3 tunnin välein.
No niin, nyt näyttää paljon paremmalta :)
Tuuppasin datat sisään uudestaan tuolla INSERT IGNORE:lla laittaen ensin aikaleiman indexin UNIQUE:ksi ja meni sisään kaikki 280K riviä heittämällä ;D
Samoin päivätaulu meni sisään ilman ongelmia. ;D
Uudet datat menee sisään cronilla 10 min välein sekä päivätauluun puolilta öin clientraw:ta ja testtag:ia käyttäen.
Sivulla on Memcache käytössä noille myslin datoille joten ne eivät välttämättä päivity ihan jokaisella päivityksellä.
Nyt toimii tilasto-sivun pikkukäyrätkin taas :)
Vaatii vielä pientä hienosäätöä koska esim. syyskuun keskilämpötila on eri riippuen miten sen ottanut (suoraan kannasta vs keskiarvo päivien keskiarvoista), eroa 0.1 astetta. :P
Toinen mikä sikinsokin on elo- ja syyskuun sateet. Nyt ei WD ja sivu puhu ollenkaan samaa kieltä niistä. Pitääpi tarkistaa kumpi nyt laskee väärin, eroa koko vuoden osalta on sellaiset 8 mm, jotenkin luotan enemmän myslin sum()-funktioon kun WD:seen jostain syystä... ::)
Nyt alkaa olemaan aika aksassa tuo uusistusprojekti, tilastosivujen latautuminenkin nopeutui huomattavasti ;)
Etusivujen käppyrätkin toimii taas ja lisäsin ne uupuvat siihen.
Vielä olisi pieni nikkarointi jäljellä hakea kannasta,
Esim: "Kuinka monta päivää vuodesta ollut Tmin < -20"
Jotain tällaista aattelin: SELECT count(Tmin) FROM db WHERE Tmiin < -20 GROUP by YEAR(DBTime).
Mutta onko keinoa millä saisi ulos useampi raja (-20, -10, 0 jne) samlla haulla? ;)
SELECT YEAR(DBTime),-20,count(Tmin) FROM db WHERE Tmiin < -20 GROUP by YEAR(DBTime)
UNION
SELECT YEAR(DBTime),-10,count(Tmin) FROM db WHERE Tmiin < -10 GROUP by YEAR(DBTime);
SELECT YEAR(db1.DBTime),count(db1.Tmin),count(db2.tmin)
FROM db db1,db db2
WHERE db1.Tmin < -20
AND db2.tmin<-10
and YEAR(db1.DBTime)=year(db2.dbtime)
GROUP by YEAR(db1.DBTime),year(db2.dbtime);
Noin ehkä lähtisin ite kokeileen, en o kyl ihan varma toimivuudesta, ainakaan ton toisen, ilman testausta.
Tattista.
Ainakin phpmyadminissa tuo ensimmäinen toimis oikeen hyvin :)
Tuo uusi versio siitä on kyllä aika kätevä ajax-hakuineen :)
Noin, kehissä on ;D
Nyt ainut manuaalinen toimi noissa kahdessa sivuissa on vuodenajat mutta sitä nyt ei tarvikkaan olla automaaginen. ;D
Lisäsin samalla pari uutta "kuinka monta päivää alle x astetta" rivin niin että nyt on 5 asteen väelin -20:sta +25:iin.
Seuraava onkin trendit-sivu :)
Sen jälkeen voikin harrastaa radikaalista siivoamaista WD:n testtags-filuun kun nuo kaikki tulee kannasta, se pitäisi nopeuttaa/keventää WD:n 5 minuutin välein olevaa raksutusta aika lailla :)
Tuotos oli seuraavanlainen (tein Tmaxit ja Tminit erillään koska oli helpompi parsia arraytä sillain)
DBTime on vvvv-kk-pp tt:mm:ss muodossa oleva aikaleima joka päiväkannassa on ajoitettu aikaan 23:58:00.
$memcache = new Memcache;
$memcache->connect('localhost', 11211) or die ("Could not connect");
$key = md5("howmanyday_min");
$get_result = $memcache->get($key);
if ($get_result) {
$hi = $get_result;
}else{
$query = "
SELECT YEAR(DBTime) as year, -20, count(Tmin) as Tmin FROM db WHERE Tmin < -20 GROUP BY YEAR(DBTime) UNION
SELECT YEAR(DBTime) as year, -15, count(Tmin) as Tmin FROM db WHERE Tmin < -15 GROUP BY YEAR(DBTime) UNION
SELECT YEAR(DBTime) as year, -10, count(Tmin) as Tmin FROM db WHERE Tmin < -10 GROUP BY YEAR(DBTime) UNION
SELECT YEAR(DBTime) as year, -5, count(Tmin) as Tmin FROM db WHERE Tmin < -5 GROUP BY YEAR(DBTime) UNION
SELECT YEAR(DBTime) as year, -0, count(Tmin) as Tmin FROM db WHERE Tmin < -0 GROUP BY YEAR(DBTime)
";
$result = mysql_query($query);
while ($row = mysql_fetch_assoc($result)) {$hi[] = $row;}
$memcache->set($key, $hi, MEMCACHE_COMPRESSED, 7200);
}
$memcache->close();