Sääohjelmien datatiedostojen formaatit? (realtime.txt, pywwsdata.txt, etc.)

[khyron]

Mistähän löytyis noitten yleisesti datan siirtoon käyttyjen fileitten dokumentit? Harkinnassa on siis josko oman sääaseman dataa vois jossain vaiheessa johonkin verkoon julkaista, ni tarttis generoida generoida joku noista. Onko kellään mitään komenttie onko jokin formaatti järkevämpi mitä joku toinen? Esim. käyttää celsius asteikkoa ja muutenkin järkeviä yksiköitä, eikä muutu kovin usein, ainakaan niin että yhtensopivuus menee rikki.

Ja mullahan ei siis tällä hetkellä ole käytössä mitään yleisesti käytössä olevaa sääsoftaa, vaan owfs ja vähän omia scriptejä.

[djmake]

Nyt ollaan muuten asian ytimessä... Siis joku järkevä, yhteinen formaatti olisi todella mukava olemassa. Mutta sitä tuskin koskaan saadaan, niin silloin omien juttujen kanssa on pakko käyttää jotain olemassaolevaa ainakin ulospäin lähtevän osalta. Eikä ole oikein mieltäylentävää kirjoittaa scriptejä jatkuvasti uudestaan, joten joku sellainen tiedostomuoto pitäisi olla, mikä ei muutu joka toinen viikko.

Siihen en osaa vastata, löytyykö mistään mitään järkevää dokumenttia. Ehkäpä jollakin on sellaisia linkata, kiinnostaa nimittäin itseäkin. On jokseenkin rasittavaa mennä jälleen kerran sinne puuhun väärin päin ja selvitellä itse filujen rakennetta sensijaan, että se olisi jotenkin dokumentoitu.

Nii joo... Samaa ketjua ja asiaa lainatakseni. Tekeekö mikään sääohjelma suoraan esimerkiksi metaria tai synoppia? En sano järkevimmäksi, mutta ainakin synoppiin saa jos jonkinlaista dataa ja sen rakenne ei varmasti tule ihan heti muuttumaan.

[weatherc]

Mistähän löytyis noitten yleisesti datan siirtoon käyttyjen fileitten dokumentit?

Kyllähän nuo clientraw.txt (WD) ja realtime.txt (Cumulus) dokkarit löytyy joko ohjelman mukana tai kyseiseltä sivulta. Niiden rakenne kun on vakio eikä muutu juuri sen takia että niitä vois käyttääkin. Jos jotain uutta tulee niin se tuupataan molemmissa tapauksissa aina sinne loppuun. Esim. NWN:ssä on useampikin asema jolla ei ole WD:tä mutta datatiedoston pohjana on tuo WD:n clientraw.txt. Jollei jotain dataa löydy niin laittaa vaan etukäteen sovitun merkin tilalle, kuten "-". Niissä kun se tärkeä on että arvot ovat aina samassa kohtaa tiedostoa ja välimerkit samat.
Jos rakentaa "custom-asemaa" niin helpoiten saa verkkoihin kun käyttää jotain sellaista pohjana.

Tekeekö mikään sääohjelma suoraan esimerkiksi metaria tai synoppia?

WD tekee. En nyt muista kumpaa se on mitä sen saa puskemaan ulos jos haluaa.  

[khyron]

Pistetääs tähän semmosia dokumenttejä mitä kuitenkin löysin.

Cumulus realtime.txt http://wiki.sandaysoft.com/a/Realtime.txt
Mutta toi jättää ainakin seuravia kysymyksiä, wind speed (average) keskiarvo miltä ajalta? wind run (today)? Paineen ja lämpötilan trendi, ilmeisesti muutos joltakin ajalta? current rain rate (per hour) ja rainfall last hour, mikä ero? Mitä tyhjile kentille laitetaan?

WD clientraw.txt http://www.tnetweather.com/nb-0100.php Ulkopuolisen dokumentaatio, luotettavuus? Ainakin osa aikakenttien formaatista riippuu wd:n asetuksista? Trendi miltä ajalta? Useista arvoista on useita kenttiä 01, 02, 03 jne.

Pywws:n formaatin sais varmaan varmimmin kun siitä saa lähdekoodin, mutta mieluummin joku järkevä dokumentti.

[angle]

Tuo pywwsdata.txt ei taida olla niin kovin yleinen ja muotokin tuli Laihon kanssa sovittua ihan keskenään. Tässä viimeisin pywwsdata.txt ennekuin siirryin clientraw.txt malliin. Tätä TNET:n sivua käytin apuna kun hioin omaa pywws clientraw.txt mallia.

[weatherc]

WD clientraw.txt http://www.tnetweather.com/nb-0100.php Ulkopuolisen dokumentaatio, luotettavuus? Ainakin osa aikakenttien formaatista riippuu wd:n asetuksista? Trendi miltä ajalta? Useista arvoista on useita kenttiä 01, 02, 03 jne.

On luotettava, yksi aktiivisimmista WD-käyttäjistä sen takana. Tosin näyttää olevan mallia 10.37f eli on jo pikkasen ikää siinä mutta noin pitkälle se pätee 100%:sesti.
Aikamuoto pp/kk/vvvv taitaa tosiaan riippua käyttäjän koneesta mutta sitä ei ole clientraw:ssa montaa, clientrawn ajat kun ovat yleisesti menossa olevan päivän aikoja hh:mm
Trendit riippuu arvosta.
01,02,03-tyyliset ovat sama arvo useammalta ajalta, eli tunti sitten, 2 tuntia sitten jne. (en ole varma että päivttyvätkö kuinka usein)
Kannattaa muistaa että vaikka tuossa lukee "Optional" tms niin ne on oltava mukana vaikka 0.0-arvona muuten menee parserit sekaisin.

[khyron]

Kannattaa muistaa että vaikka tuossa lukee "Optional" tms niin ne on oltava mukana vaikka 0.0-arvona muuten menee parserit sekaisin.

Onko yleistä että täytyy käyttää jotain magic-arvoa? Kun 0.0 on kuitenkin täysin validi arvo vaikka lämpötilalle, järkevämpä olisi käyttää vaikka tyhjää, tietty jos parserit hyväksyy erottimeksi yhden tai useamman välilyönnin toi ei toimi.

Yleisesti ottaen csv-tyyppiset siirtotiedostot on vähän harmillisia, varsinkin laajennettavuuden kannalta.

[weatherc]

Onko yleistä että täytyy käyttää jotain magic-arvoa? Kun 0.0 on kuitenkin täysin validi arvo vaikka lämpötilalle, järkevämpä olisi käyttää vaikka tyhjää, tietty jos parserit hyväksyy erottimeksi yhden tai useamman välilyönnin toi ei toimi.

WD taitaa käyttää 100 tai -100 noissa. Noita "valiideja virhelukuja" on muutenkin useampi (lue: liikaa) jotka oikeastaan pitää laittaa roskiin jossain verkossa (kuten 0.0 ja -20.0). Välilyönti ei toimi koska clientraw käyttää välilyöntiä erottajana eikä parserit osaa erottaa niitä.

Yleisesti ottaen csv-tyyppiset siirtotiedostot on vähän harmillisia, varsinkin laajennettavuuden kannalta.

Sekä realtime.txt että clientraw.txt ovat perus txt-tiedostoja eikä csv:tä nähneetkään joten ei ole onglmia lisätä mitään sinne loppuun. Clinetrawssa on AINA lopussa se

Record End (WD Ver)             Label (Exampe: !!C10.37f!! )

Eli mahdolliset uudet arvot tulevat aina sen yläpuolelle

[angle]

Kannattaa muistaa että vaikka tuossa lukee "Optional" tms niin ne on oltava mukana vaikka 0.0-arvona muuten menee parserit sekaisin.

Onko yleistä että täytyy käyttää jotain magic-arvoa? Kun 0.0 on kuitenkin täysin validi arvo vaikka lämpötilalle, järkevämpä olisi käyttää vaikka tyhjää, tietty jos parserit hyväksyy erottimeksi yhden tai useamman välilyönnin toi ei toimi.

Yleisesti ottaen csv-tyyppiset siirtotiedostot on vähän harmillisia, varsinkin laajennettavuuden kannalta.

Minulla on käytössä  - merkki "tyhjissä" kohdissa, joita riittääkin eniten.

[khyron]

Onko yleistä että täytyy käyttää jotain magic-arvoa? Kun 0.0 on kuitenkin täysin validi arvo vaikka lämpötilalle, järkevämpä olisi käyttää vaikka tyhjää, tietty jos parserit hyväksyy erottimeksi yhden tai useamman välilyönnin toi ei toimi.

WD taitaa käyttää 100 tai -100 noissa. Noita "valiideja virhelukuja" on muutenkin useampi (lue: liikaa) jotka oikeastaan pitää laittaa roskiin jossain verkossa (kuten 0.0 ja -20.0). Välilyönti ei toimi koska clientraw käyttää välilyöntiä erottajana eikä parserit osaa erottaa niitä.

Puhuinkin tyhjästä enkä välilyönnistä, siis esim. 1<välilyönti>-10<välilyönti><välilyönti> tossa kolmas arvo on tyhjä. Olettaa toki että parseri ei tulkitse useampaa välilyöntiä yhdeksi, mikä ei ole mitenkään sanottu.

Mutta noi validit virheluvut on kuitenkin dokumentoitu ja löytyy wd:n asennuspaketista?

Yleisesti ottaen csv-tyyppiset siirtotiedostot on vähän harmillisia, varsinkin laajennettavuuden kannalta.

Sekä realtime.txt että clientraw.txt ovat perus txt-tiedostoja eikä csv:tä nähneetkään joten ei ole onglmia lisätä mitään sinne loppuun. Clinetrawssa on AINA lopussa se

Record End (WD Ver)             Label (Exampe: !!C10.37f!! )

Eli mahdolliset uudet arvot tulevat aina sen yläpuolelle

Csv-tyyppiset, ts. tiedostot jossa on yksi tietue per rivi ja jollain erotinmerkillä erotettuina. Ongelma tuleekin siitä että niitä arvoja pitää kuitenkin olla tietty määrä, tietyssä järjestyksessä ja niille arvoille joita ei ole pitää keksiä joku merkitsemään tyhjää.

Niin, just tämmösten takia ajattelinkin kysyä mikä olis simppelein formaatti:)