Haasteen muotoileminen

[pe3]

Sovittiin, että mahdollisimman laaja, mutta katsotaan tilanneviestinnän näkökulmasta. Esim. tilastodatasta voisi tehdä vuodenajasta ja muista tekijäistä riippuvia ajassapysymisennusteita.

[spqs]

@JariHonkonen , @tuukka, @haphut , apujanne tarvitaan haasteen muotoilussa.

Ehdotan seuraavaa:

1. Viime tapaamisessamme keskustelimme kahdesta eri haasteideasta, poikkeustilanneviestinnästä
   ja historiadatan käytöstä (yhdisteltynä johonkin toiseen datalähteeseen, esim. Ilmatieteenlaitoksen dataan).
   Selvyyden vuoksi noudatetaan "jokainen haaste omassa repossaan", eli avataan HSL:n historiadata -idean
   kehittelyyn erillinen repo. @pe3:n kanssa päädyttiin siihen, että Appsissä voi yhdellä haastekumppanilla olla
   mahdollisesti useampiakin haaste-ehdotuksia, joten jos intoa riittää myös historiadatahaasteen kehittelyyn niin
   se otetaan myös mukaan.
2. Tarvitsemme lisää infoa poikkeustilanneviestintä-haasteen muotoilua varten. Tavoitteena on saada tähän
   repoon vähintäänkin selkeät linkit (mieluummin koodinpätkät), jotka tarvitaan datan lukemista ja lähettämistä
   varten. Tämä siksi, että yritämme laajentaa ratkaisijayhteisöjä kokoneiden koodaripiirien ulkopuolellekin, joten
   perusteellisempi ohjeistus on paikallaan. Nyt tarvitaan vastauksia kysymyksiin
   
   (a) mikä nykytilanteessa on vialla yleisesti? (Poikkeustilannetiedotteet eivä mene perille, koska syy-1, syy-2, ...)
   
   (b) HSLn jaottelun nykyisen viestikäytännön (päivityslogiikan) selittäminen liittyen siihen, mitkä muutokset näkyvät reittioppaassa, mitkä eivät ja miksi. Hyvä olisi varmaan selittää myös se palaverissämme mainittu seikka, että tietyt pidempiaikaiset liikennejärjestelyjenmuutokset (esim-1, esim-2,...) tulevat tallentumaan joihinkin HSLn palveluhin (mihin?) mutta nopeat, lyhytaikaiset muutokset eivät (syystä, että ...)
   
   (c) Mihin HSL palveluihin haluaisi poikkeustilaviestien välittyvän?
   
   (d) Miten poikkeustilaviestit saadaan luettua HSLn rajapinnasta? Tähän Tuukka jo postasikin dokumentaatiota, mutta kaipailisin pientä koodinpätkää, jonka voi testata helposti omalla koneella. Voisiko joku auttaa muokkaamaan sopivan lukijan esim. http://www.w3schools.com/dom/dom_http.asp -osoitteesta löytyvien perusteella? Mitään hienostunutta muotoilua tai parseria ei ole tarkoitus tehdä, koska onhan kilpailijoille omaakin tekemistä jätettävä, mutta esimerkinomaisesti voisi xml-viestistä lukea vaikka linjanumeron, jota muutos koskee.
   
   (e) Mitä teknologioita tulee käyttään kun viesti välitetään kohdepalveluihin (esim. tekstiviestit liian kalliita, joten niitä ei suositella?). Samaan tapaan kuin kohdassa (d) olisi hyvä jos reposta löytyisi esimerkinomainen koodinpala, joka havainnollistaa jollain yleisellä tekniikalla, kuinka viestiä voi puske eteenpäin. Tarkoitus ei siis ole ratkaista koko ongelmaa valmiiksi vaan antaa vinkkejä siitä kuinka eri rajapintojen kanssa toimitaan. Kaipaan siis esimerkkejä tähän, ja voin täsmentää rajapintakommunikoinitesimerkkejä jahka saan teiltä ensin tietoa, siitä miten mahdollisesti tätä osaongelmaa kannattaisi lähestyä.

[haphut]

1. Ymmärsin, että tavoitteenamme oli yksi haaste, jota myös historiadata tukisi. Ajatuksena oli, että ehkä joku kykenisi povaamaan melko luotettavasti toimintahäiriöitä historiallisen datamme ja muiden lähteiden perusteella.
2. Olitteko miettineet jotakin formaattia haasteiden muotoilemiselle ja mihin vastauksia kysymyksiisi rustataan? Mitä kirjoitetaan README:hen, mitä wikiin, mitä erillisille sivuille? Onko tarkoitus käyttää Github Pagesia?