Kulkutietoviestit

[Solita / Jaakko]

Terve

AvoinDataan ollaan tuomassa junien kulkutietoviestit. Käytännössä tämä tarkoittaa tietoa siitä millä raideosuudella juna parhaillaan ajaa. Kun juna ajaa raiteella sijaitsevan sensorin päälle, syntyy "OCCUPY"-tyyppinen viesti, joka kertoo että raideosuudella sijaitsee juna. Sensorin vapautuessa junasta syntyy puolestaan "RELEASE"-tyyppinen viesti.

Ohessa speksi miltä rajapinta uusien toiminallisuuksien osalta näyttäisi.

Uudet URL:t

1. /train-tracking/344?departure_date=2015-09-24
   
2. /train-tracking?version=123456789
   
3. /metadata/track-sections
   

Esimerkkivastaukset:

/train-tracking

[

{

id: 1268984971,

version: 5305199154,

trainNumber: 344,

departureDate: "2015-09-23",

timestamp: "2015-09-23T16:50:24.000Z",

trackSection: "001",

station: "LPÄ",

type: "OCCUPY"

},

{

id: 1268985497,

version: 5305212515,

trainNumber: 344,

departureDate: "2015-09-23",

timestamp: "2015-09-23T16:52:02.000Z",

trackSection: "001",

station: "LPÄ",

type: "RELEASE"

},

{

id: 1268985607,

version: 5305212515,

trainNumber: 344,

departureDate: "2015-09-23",

timestamp: "2015-09-23T16:52:22.000Z",

trackSection: "166",

station: "LPÄ",

type: "OCCUPY"

},

....

]

/metadata/track-sections

[{

"station": "ASO",

"trackSection": "683",

"ranges": [{

"startLocation": {

"track": "123",

"kilometres": 31,

"metres": 660

},

"endLocation": {

"track": "123",

"kilometres": 32,

"metres": 518

}

}]

},

...

]

Raideosuudet (track-section) on määritelty ratakilometri-formaatissa eli kuinka monta kilometria ja metriä sijainti on radan alusta. GPS-koordinaatit pyritään tuomaan myöhemmin.

Herääkö teillä kommentteja datan muodosta, rajapinnan URL:sta tai muista asioista?

Yt. Jaakko / Solita Oy

[Teemu Peltonen]

- Toimisivatko version-parametri ja ilman junanumeroa tehdyn train-tracking kutsun aikarajoitus (4 tuntia nykyhetkestä molempiin suuntiin kulussa olevat junat) samalla tavalla kuin live-trainsissa?
- Onko kulkutiedoissa samanlaiset suodatukset näytettävien junien osalta kuin live-trainsissa, vai näytetäänkö myös esimerkiksi ilman aikataulua tehtävien vaihtotöiden kulkutiedot myös?
- Onko junanumerolla tehtyyn hakuun suunniteltu/ajateltu toteutettavan versiorajoitusta, äkkiä arvattuna datamäärät saattavat kasvaa yksittäistenkin junien osalta varsin suuriksi ja koko datasetin päivittäminen viimeisten muutosten saamiseksi ei välttämättä olisi tarpeellista?
- Olisiko kulkutietovastaukseen mahdollista saada tieto edellisestä ja seuraavasta liikennepaikasta, jolloin junan kulkusuuntaa ei välttämättä tarvitsisi päätellä muista tiedoista?


-TeemuP

[Teemu Sirkiä]

Hienoa, että kommentteja pyydetään jo tässä vaiheessa. Tässä tulevat omat pohdintani.

Pari yleistä kysymystä:

• Tulevatko kulkutietosanomat vain linjalta vai näkyvätkö sieltä myös kaikki ratapihoilta tulevat sanomat, joista voi nähdä esimerkiksi junan kulun liikennepaikan ensimmäiseltä vaihteelta koko vaihdekujan läpi määräraiteelle? Tällöin voi nähdä esimerkiksi, mille raiteelle juna on todellisuudessa saapunut (olettaen että raideosuuden nimen osaa tulkita). Näyttäisi siltä, että tuossa esimerkissä lähdetään Lempäälän raiteelta 1 suoraan linjalle ilman tietoa vaihteiden eristysosuuksien varautumisesta. Toisaalta vaihteiden tarkkuudella tuleva tieto ei välttämättä ole kovin tarpeellista, vaikka sen avulla saisi tehtyä esimerkiksi hienoja ratapihavisualisaatioita kaikkien raideosuuksien tiloista. Kenties tuohonkin voisi vaikuttaa jollain tapaa, tuleeko tietoa vähän vai paljon?
  
• Liitetäänkö raideosuuksien metadatatieto tulevaisuudessa myöhemmin julkaistavaan rataverkon malliin? Sellaiseen verkkomalliin siis, jossa on selvillä kunkin solmun naapurit, jotka olisivat tässä tapauksessa raideosuuksia.

Pari detailikysymystä:

• Miksi metadatassa on ranges-lista? Mikseivät startLocation ja endLocation ole suoraan vain tuon elementin ominaisuuksia? Liittyykö tämä kenties vaihteisiin, joilla on useampia alkamis- ja päättymispisteitä tai ratakilometrijärjestelmän "kierouksiin" tietyissä paikoissa, joissa samassa kohtaa voi olla useamman järjestelmän mukaisia kilometrejä?
• Onko train-tracking-vastauksessa näkyvä id tarpeellinen? Olettaen siis, että se on kulkutietosanoman yksilöivä tunnus.
  

Ehdotuksia:

• Voisiko metadataan liittää kunkin raideosuuden pituuden, mikäli se on tiedossa? Ratakilometrijärjestelmässä kilometri on usein jotakin muuta kuin täsmälleen 1000 metriä.
• Voisiko train-tracking-viesteissä olla ARRIVAL- ja DEPARTURE-tieto liikennepaikoille? Tällöin liikennetilanteen kokonaiskuvaa voisi seurata näiden viestien avulla ja live-trains-rajapintaa voisi kutsua huomattavasti nykyistä harvemmin, vaikka vain kerran minuutissa tai parissa. (Sivuhuomio: live-trainsin cache-aika versionumerolla on kaksi minuuttia, sen voisi pudottaa vaikka puoleen minuuttiin. Tällöin harvemmin pyydetty live-trains olisi edes puolen minuutin tarkkuudella ajan tasalla.) Tämä olisi datan siirtämisen kannalta huomattavasti tehokkaampaa, koska ei tarvitse siirtää jatkuvasti liikkuneiden junien koko aikataulua. Tähän toteutukseen olisi ainakin kaksi eri vaihtoehtoa:
• OCCUPY-viesteihin liitetään esim. event-niminen lisätieto, jossa on ARRIVAL tai DEPARTURE sen mukaan, jos kyseinen varaustieto laukaisee tiedon junan saapumisesta liikennepaikalle tai lähtemiselle sieltä. Tällöin voisi olla myös eventTime, jossa on aikakorjattu tieto ko. tapahtumalle.
  
• Luodaan kaksi uutta typeä, ARRIVAL ja DEPARTURE, joissa on aikoina suoraan aikakorjattu aika. Noissa voisi tietysti näkyä myös se raideosuus, joka tuon tiedon on laukaissut.

Sitten hieman radikaalimpi muutosehdotus:

• Tässä liikkuu dataa niin paljon, ettei minusta ole mielekästä pitää kulkutietosanomien rajapintaa puhtaasti HTTP-muotoisena endpointtina, jota pollataan vähän väliä. Olisi paljon tehokkaampaa toteuttaa tuo yllä esitetty train-tracking versionumerolla vaikka WebSocket-muotoisena siten, että soketin läpi tulisi noita täsmälleen samanlaisia JSON-viestejä virtana niitä haluaville sitä mukaa, kun niitä tulee järjestelmään. Tällöin data ei ole purskeista ja vältytään erilaisilta välimuistitus- ja versionumero-ongelmilta suoraan. Tähän liittyen muuttaisin esitettyjä URLeja seuraavasti:
• train-tracking pelkällä versionumerolla poistuisi kokonaan
• train-tracking junan numerolla ja lähtöpäivällä säilyy ennallaan
• train-tracking ilman parametreja palauttaa kunkin liikkeellä olevan junan viimeisimmän kulkutietosanoman. Tässä voisi olla vaikkapa samanlainen puolen minuutin cache.
  

[Solita / Jaakko]

Kiitos paljon kommenteistanne!

Teemu Peltola:

- Toimisivatko version-parametri ja ilman junanumeroa tehdyn train-tracking kutsun aikarajoitus (4 tuntia nykyhetkestä molempiin suuntiin kulussa olevat junat) samalla tavalla kuin live-trainsissa?

> Kyllä, samalla tavalla.

versio-kutsussa timestamp-attribuutti rajattu +- x tuntia nykyhetkestä. Varmaankin tunnin tai vähemmän rajoitus, koska neljän tunnin rajalla json-dataa tulee 18MB.

junanumero-kutsussa ei timestamp-attribuuttirajoituksia

- Onko kulkutiedoissa samanlaiset suodatukset näytettävien junien osalta kuin live-trainsissa, vai näytetäänkö myös esimerkiksi ilman aikataulua tehtävien vaihtotöiden kulkutiedot myös?

> Tällä hetkellä ajateltu julkaistavan kaikki junat, joilla on numeerinen junanumero. Tämä saattaa vielä muuttua.

- Onko junanumerolla tehtyyn hakuun suunniteltu/ajateltu toteutettavan versiorajoitusta, äkkiä arvattuna datamäärät saattavat kasvaa yksittäistenkin junien osalta varsin suuriksi ja koko datasetin päivittäminen viimeisten muutosten saamiseksi ei välttämättä olisi tarpeellista?

> Tutkin tilastoja ja eniten kulkutietoviestejä päivältä 2015-09-16 löytyi junalle 865. Tämän junan train-tracking vastaus oli kooltaan 428kB pakkaamattomana.

Toteutan tämän.

- Olisiko kulkutietovastaukseen mahdollista saada tieto edellisestä ja seuraavasta liikennepaikasta, jolloin junan kulkusuuntaa ei välttämättä tarvitsisi päätellä muista tiedoista?

> Tämä tieto tulee mukaan. Kuten myös edellinen ja seuraava raideosuus.

Teemu Sirkiä:

• Tulevatko kulkutietosanomat vain linjalta vai näkyvätkö sieltä myös kaikki ratapihoilta tulevat sanomat, joista voi nähdä esimerkiksi junan kulun liikennepaikan ensimmäiseltä vaihteelta koko vaihdekujan läpi määräraiteelle? Tällöin voi nähdä esimerkiksi, mille raiteelle juna on todellisuudessa saapunut (olettaen että raideosuuden nimen osaa tulkita). Näyttäisi siltä, että tuossa esimerkissä lähdetään Lempäälän raiteelta 1 suoraan linjalle ilman tietoa vaihteiden eristysosuuksien varautumisesta. Toisaalta vaihteiden tarkkuudella tuleva tieto ei välttämättä ole kovin tarpeellista, vaikka sen avulla saisi tehtyä esimerkiksi hienoja ratapihavisualisaatioita kaikkien raideosuuksien tiloista. Kenties tuohonkin voisi vaikuttaa jollain tapaa, tuleeko tietoa vähän vai paljon?

> Myös ratapihat ovat mukana. Ajatus on julkaista kaikkien rataosuuksien tiedot.

• Liitetäänkö raideosuuksien metadatatieto tulevaisuudessa myöhemmin julkaistavaan rataverkon malliin? Sellaiseen verkkomalliin siis, jossa on selvillä kunkin solmun naapurit, jotka olisivat tässä tapauksessa raideosuuksia.

> Tulevaisuudessa julkaista rataverkon malli on parempi ratkaisu, koska data on tarkkaa ja laajempaa. Meillä olevasta datasta puuttuu raideosuuksia ja verkkomallia ei tällä hetkellä ole saatavilla.

Pari detailikysymystä:

• Miksi metadatassa on ranges-lista? Mikseivät startLocation ja endLocation ole suoraan vain tuon elementin ominaisuuksia? Liittyykö tämä kenties vaihteisiin, joilla on useampia alkamis- ja päättymispisteitä tai ratakilometrijärjestelmän "kierouksiin" tietyissä paikoissa, joissa samassa kohtaa voi olla useamman järjestelmän mukaisia kilometrejä?

> Raideosuus voi välillä sijaita kahdella eri ratanumerolla.

Meillä on määritelty 7312 raideosuutta. Raideosuuksilla on yhteensä 7354 sijaintia. On siis harvinaista, että raideosuudella on useita sijainteja.

• Onko train-tracking-vastauksessa näkyvä id tarpeellinen? Olettaen siis, että se on kulkutietosanoman yksilöivä tunnus.

> Tämä on kiva käyttötapauksiin, jossa koodaaja miettii "onko minulla jo tämä objekti".

Ehdotuksia:

• Voisiko metadataan liittää kunkin raideosuuden pituuden, mikäli se on tiedossa? Ratakilometrijärjestelmässä kilometri on usein jotakin muuta kuin täsmälleen 1000 metriä.

> Ei valitettavasti ole saatavilla. "Tulevaisuuden mallissa" tämä tieto on.

• Voisiko train-tracking-viesteissä olla ARRIVAL- ja DEPARTURE-tieto liikennepaikoille? Tällöin liikennetilanteen kokonaiskuvaa voisi seurata näiden viestien avulla ja live-trains-rajapintaa voisi kutsua huomattavasti nykyistä harvemmin, vaikka vain kerran minuutissa tai parissa. (Sivuhuomio: live-trainsin cache-aika versionumerolla on kaksi minuuttia, sen voisi pudottaa vaikka puoleen minuuttiin. Tällöin harvemmin pyydetty live-trains olisi edes puolen minuutin tarkkuudella ajan tasalla.) Tämä olisi datan siirtämisen kannalta huomattavasti tehokkaampaa, koska ei tarvitse siirtää jatkuvasti liikkuneiden junien koko aikataulua. Tähän toteutukseen olisi ainakin kaksi eri vaihtoehtoa:

o OCCUPY-viesteihin liitetään esim. event-niminen lisätieto, jossa on ARRIVAL tai DEPARTURE sen mukaan, jos kyseinen varaustieto laukaisee tiedon junan saapumisesta liikennepaikalle tai lähtemiselle sieltä. Tällöin voisi olla myös eventTime, jossa on aikakorjattu tieto ko. tapahtumalle.

o Luodaan kaksi uutta typeä, ARRIVAL ja DEPARTURE, joissa on aikoina suoraan aikakorjattu aika. Noissa voisi tietysti näkyä myös se raideosuus, joka tuon tiedon on laukaissut.

> Eli haluaisit tiedon siitä, onko raideosuuden kulkutietoviesti aiheuttanut toteuman junan aikatauluun. Tieto on saatavilla, mutta ei tehdä tätä vielä ensimmäisesä versiossa. Tein tästä kehitysehdotuksen. LIIKEAVOI-85.

Sitten hieman radikaalimpi muutosehdotus:

• Tässä liikkuu dataa niin paljon, ettei minusta ole mielekästä pitää kulkutietosanomien rajapintaa puhtaasti HTTP-muotoisena endpointtina, jota pollataan vähän väliä. Olisi paljon tehokkaampaa toteuttaa tuo yllä esitetty train-tracking versionumerolla vaikka WebSocket-muotoisena siten, että soketin läpi tulisi noita täsmälleen samanlaisia JSON-viestejä virtana niitä haluaville sitä mukaa, kun niitä tulee järjestelmään. Tällöin data ei ole purskeista ja vältytään erilaisilta välimuistitus- ja versionumero-ongelmilta suoraan. Tähän liittyen muuttaisin esitettyjä URLeja seuraavasti:

o train-tracking pelkällä versionumerolla poistuisi kokonaan

o train-tracking junan numerolla ja lähtöpäivällä säilyy ennallaan

o train-tracking ilman parametreja palauttaa kunkin liikkeellä olevan junan viimeisimmän kulkutietosanoman. Tässä voisi olla vaikkapa samanlainen puolen minuutin cache.

> Jos haen kulkutietoviesteista kannasta isoimman versionumeron ja haen hetken kuluttua sillä train-tracking?version, niin vastauksen koko on luokkaa 150kB. Muutaman minuutin päästä vielä 350kB. Pakkaamattomana. En usko, että suorituskyvystä tulee ongelma.

Äkkiseltään versiohaku on mielestäni yksinkertaisempi, koska socket-katkoja ja siinä välissä menetettyä dataa ei tarvitse miettiä. Mutta tutkimme tätä vielä tarkemmin: LIIKEAVOI-84. Käsittääkseni jossain ulkomailla tälläinen socket-ratkaisu on käytössä.

Yt. Jaakko

[Teemu Peltonen]

Kiitos hyvistä vastauksista.

Jonkinlainen pub/sub tyyppinen rajapinta olisi varmasti hyvä lisä jatkuvan pollauksen sijaan/kylkeen.

[Teemu Sirkiä]

> Jos haen kulkutietoviesteista kannasta isoimman versionumeron ja haen hetken kuluttua sillä train-tracking?version, niin vastauksen koko on luokkaa 150kB. Muutaman minuutin päästä vielä 350kB. Pakkaamattomana. En usko, että suorituskyvystä tulee ongelma.

Äkkiseltään versiohaku on mielestäni yksinkertaisempi, koska socket-katkoja ja siinä välissä menetettyä dataa ei tarvitse miettiä. Mutta tutkimme tätä vielä tarkemmin: LIIKEAVOI-84. Käsittääkseni jossain ulkomailla tälläinen socket-ratkaisu on käytössä.

HTTP-ratkaisu on toki jossain määrin yksinkertaisempi, mutta WebSocket-ratkaisussa dataa tulisi suoraan ilman, että sitä tarvitsee itse koko ajan pyytää ja hakea. Tuossa WebSocket-ratkaisussa ei minusta olisi kovin haitallista, vaikka sieltä jäisi välistä pari viestiä saamatta. Mutta voihan tämän toteuttaa myöhemminkin tuon esitetyn speksin lisäksi, jos idea vaikuttaa toimivalta. HSL:ltä tulee jotakin dataa ihan TCP-paketteina, mutta WebSocket olisi nykymaailmassa paljon kivempi vaihtoehto toteutukseen.

[Teemu Peltonen]

HSL:llä on tosiaan käytössä IBM:n ratkaisu ja sitä myöten MQTT-protokolla, joka toki kulkee myös WebSocketin yli.

[Solita / Jaakko]

Unohtui vielä vastata, että lasketaan live-trainsin cache-aikaa.

[Teemu Sirkiä]

perjantai 25. syyskuuta 2015 11.42.56 UTC+3 Solita / Jaakko kirjoitti:

Unohtui vielä vastata, että lasketaan live-trainsin cache-aikaa.

Kiva!

Eikä tuo WebSocket-ajatuskaan välttämättä ole pelkästään siis tehokkuusnäkökulmista johtuva, vaan enemmänkin tiedon luonteesta. Kun tietoa tulee jatkuvasti, niin on jotenkin käytännöllisempää, että sitä työnnetään halukkaille sen sijaan, että jokainen käy jatkuvasti kyselemässä, onko uutta dataa saatavilla. WebSocketien käyttäminen client-päässä on myös varsin helppoa, kun avaa vain yhteyden ja alkaa vastaanottaa tietoa sieltä ilman huolta versionumeroista, pollauksesta yms. Se toimii myös kaikilla uusilla selaimilla suoraan eikä hyödyntäminen palvelinpäässä ole sen hankalampaa.

Julian live-näkymät käyttävät Socket.IO:ta siten, että eri näkymissä tilataan joko junan tai tiettyjen liikennepaikkojen tietoja, jolloin Julia osaa työntää niitä reaaliajassa haluaville. Näin tiedot päivittyvät heti eikä palvelinta tarvitse pollata. Tuo on ollut äärimmäisen kätevä tapa hoitaa tuo tiedonvälitys.

[Juhani Pirttilahti]

Asiallista keskustelua. Tähän tiedon jakamiseen liittyen esimerkiksi Network Rail jakaa kulkutietoja ActiveMQ-palvelimelta. Viestit välitetään Stomp-protokollan muodossa ja saadut viestit voi siinä kuitata vastaanotetuksi ns. Heartbeat-viestillä. Palvelimen päässä on yhteyskatkojen varalta viiden minuutin aikaraja, jonka puitteissa lähteviä viestejä pidetään puskurissa ja näin ne eivät katoa mihinkään mikäli yhteys saadaan uudelleen.

Tämä on siellä käytössä myös kiireellisesti luotujen aikataulujen jakamisessa.

Etuna tässä toimintamallissa on hyvin reaaliaikainen tiedonvälitys ja vikasietoisuus tiettyyn rajaan saakka. Haittapuolena on kenties hieman vaativampi toteutus molemmille puolille ja toisaalta myös sen tuntemattomuus. Toki käyttövalmiit kirjastot on olemassa useille ohjelmointikielille.

[Teemu Sirkiä]

maanantai 28. syyskuuta 2015 2.43.09 UTC+3 Juhani Pirttilahti kirjoitti:

Viestit välitetään Stomp-protokollan muodossa ja saadut viestit voi siinä kuitata vastaanotetuksi ns. Heartbeat-viestillä. Palvelimen päässä on yhteyskatkojen varalta viiden minuutin aikaraja, jonka puitteissa lähteviä viestejä pidetään puskurissa ja näin ne eivät katoa mihinkään mikäli yhteys saadaan uudelleen. Etuna tässä toimintamallissa on hyvin reaaliaikainen tiedonvälitys ja vikasietoisuus tiettyyn rajaan saakka. Haittapuolena on kenties hieman vaativampi toteutus molemmille puolille ja toisaalta myös sen tuntemattomuus. Toki käyttövalmiit kirjastot on olemassa useille ohjelmointikielille.

Tuo on hyvin raskas toteutus sen sijaan, että JSON-viestejä tulisi vain WebSocketin kautta sellaisenaan läpi, jolloin käsittely on äärimmäisen helppoa. Toki tuon protokollan hankaluus tuo ja mahdollistaa siihen sitten lisäominaisuuksia kuten välittämättä jääneiden viestien välitys. Mutta tuollakin on tiedostettu striimipohjaisen välityksen edut, jolloin ei tarvitse pollata uutta tietoa.

[tomi.lapinlampi]

Kiitoksia kaikille arvokkasta palautteesta, tältä pohjalta lähdemme viemään WebSocket-toteutusta eteenpäin.

- Tomi / Liikennevirasto

[Tuukka Hastrup]

HSL:n ja Digitransitin käyttämä MQTT olisi tosiaan yksi kevyt standardi sille, miten yhden WebSocket-yhteyden sisällä voi tilata ja julkaista viestejä (jokainen WebSocket-yhteys kuitenkin maksaa palvelimella). Jokaisella viestillä on hierarkinen topic, ja tilaajat ovat ilmoittaneet, mihin topiceihin tulevat viestit he haluavat vastaanottaa. Tilauksissa voi myös käyttää wildcardeja: + kattaa yhden tason, # kaikki alitasot. Tässä esimerkkinä miten käytämme topiceja:

Topic-rakenne: /hfp/journey/type/id/line/direction/headsign/start_time/next_stop/geohashlevel/geohash...
Esimerkkitopic: /hfp/journey/bus/67bf46c0/1055/1/Koskela/1105/1020169/2/60;24/19/74/03
Tilauksia:
/hfp/journey/# (kaikki viestit)
/hfp/journey/+/+/1055/1/# (linja 55 Koskelan suuntaan)
/hfp/journey/+/+/+/+/+/+/+/+/60;24/19/# (geohash-karttaruutu lat 60.1 lon 24.9)

Kulkutietoviestien tapauksessa kiinnostavia tilausperusteita olisivat ainakin junatyyppi, junanumero, lähijunakirjain, määränpää, liikennepaikka, raideosuus, geohash-karttaruutu.

HSL:llä yksi suunnitteluperiaate oli, että viesti tulee suoraan kulkuneuvosta "tyhmälle" MQTT-palvelimelle, joka vain välittää viestin matkustajien puhelimiin (minimiviive, minimikuorma). Siksi pysäkkikohtainen näkymä ei ollut mahdollinen, mutta periaatteessa viesti voitaisiin monistaa reitillä tulossa olevien pysäkkien pysäkkikohtaisiin topiceihin, tyyliin /hfp/stop/type/id/timehash... missä timehash mahdollistaa rajauksen asemalle tietyssä aikaikkunassa saapuviin juniin. Jos ei haluta rajoittua MQTT:n malliin, lisäisin mahdollisuuden tilata kerralla suoraan useita junia/asemia id-luettelolla, "10 seuraavaksi saapuvaa junaa",  yms.

[Andreas Lundberg]

Millä tavoin kulkutietoviesteissä näkyviä aikataulua omaamattomia vaihtotyöliikkeitä rajataan? Sikäli kun voin havaita, niin vain pieni osa aikatauluttomista PAI-tyypin vaihtotyöliikkeistä näkyy, mutta SAA-tyyppiset näkyvät ilmeisesti kaikki. Miten lienee MUV-vaihtotöiden laita?

Olisi kieltämättä selvää lisäarvoa tuovaa, jos kaikki vaihtotyöt voitaisiin näyttää kulkutietoviesteissä.

[Solita / Jaakko]

Terve

Tuukka Hastrup:

Pahoittelut että vastaus on venynyt. Wildcard-idea ja rajoittaminen liikennepaikan ym. mukaan on mielestäni loistava idea. Tein asiasta kehitysehdotuksen LIIKEAVOI-88.

Andreas Lundberg:

Rajaus tapahtuu seuraavasti
1) Kulkutietoviestillä pitää olla lähtöpäivämäärä, joka poimitaan junan haetusta aikataulusta. Tämä rajaa vaihtotyöjunat aika hyvin pois.
2) Junanumero pitää olla numeerinen. Tämä rajaa pois testi yms. junat

Tutkin vähän dataa ja pyrin tuomaan AvoinDataan puuttuvatkin junat. LIIKEAVOI-89

MUV-junia (66151,66050,66051,66053,66252,66251,66052) löytyy päivältä 25.9.2015.

Yt. Jaakko / Solita Oy

[Solita / Jaakko]

Terve

AvoinData käyttää Spring Boottia, joka tarjoaa http- ja websocket-rajapinnat.

Koitin tutkia, miten tähän ympäristöön voisi ympätä "MQTT over websocket"-tuen, mutta hankalaa on.

Teillä on ilmeisesti käytössä sovelluksesta erillinen MQTT-broker (IBM WebSphere?).

* Onko teillä erilliset domainit websocketille ja perus http-rest -rajapinnoille?
* Tarjoaako käyttämänne broker suoraan WebSocket-tuen?
* Onko ideoita miten MQTT olisi paras toteuttaa Java-ympäristössä?

Yt. Jaakko

keskiviikko 30. syyskuuta 2015 19.20.04 UTC+3 Tuukka Hastrup kirjoitti:

[Teemu Sirkiä]

Luultavasti implementaatio olisi paljon helpompi, jos laittaisi ympäristöön pienen Node-kilkkeen väliin. Se kuuntelisi tuota nykyistä sokettia ja laittaisi viestejä MQTT-protokollalla eteenpäin.