Aikaikkuna myös liukuvan aikavälin sensoreille

[Teemu K]

Hei,

Olisiko mahdollista saada tieto aikaikkunasta myös LAM-asemien liukuvan aikavälin sensoreille (sensori-id:t 5116, 5119, 5122, 5125, 5158, 5161, 5164, 5168)? Tällä hetkellä aikaikkuna on vain kiinteän aikavälin sensoreilla (kentät timeWindowStart ja timeWindowEnd).

Pohjustuksena ja jonkinlaisena motivaationa viittaan Digitraffic-palvelun esittelyssä(http://digitraffic.liikennevirasto.fi/palvelun-esittely/) mainittuun VTT:n ja TKK:n projektiin(http://virtual.vtt.fi/virtual/proj6/fits/julkaisut/hanke3/FITS_30.pdf). Selvityksen sivun 23 yläosassa mainitaan liikenneverkon tilan mallintamisen yhteydessä, että anturitieto on jo vanhaa siinä vaiheessa, kun se on palveluiden käytettävissä. Tämän kerrotaan johtuvan tiedon keruu- ja välitysviiveestä, joka voi olla useita minuutteja.

Tältä pohjalta vaikuttaisi siltä, että esimerkiksi nykyhetken tilaa varten olisi hyödyllistä tietää, milloin sensoriarvo on oikeasti päivittynyt.

HTTP-rajapinnan vastausviestissä tosin on jo ilmoitettu jokin mittausaika (measuredTime) asemakohtaisesti, mutta WebSocketilla tätä tietoa ei ole. Voidaanko HTTP-vastauksen aikaa käyttää kaikkien kyseisen LAM-aseman liukuvan aikavälin sensorien kanssa? Oletettavasti tämä tarkoittaisi 5 minuutin aikaikkunan loppuhetkeä? Jos voidaan, niin sama tieto tarvittaisiin myös WebSocketin puolelle.

Aikaikkuna voisi olla hyödyllinen myös häiriötilanteissa, joissa sensoriarvo ei päivitykään (kuten https://groups.google.com/d/msg/roaddigitrafficfi/Wrg37RSDfX0/ja8y7hDSAwAJ).

[Solita / Teemu]

Hei,

Valitettavasti liukuvan aikavälin sensoreille ei ole tarjolla tietoa mittauksen aikaikkunasta. 

Tämän hetken toteutuksessa mittausasema palauttaa vain yhden aikaleiman. Tämä aika edustaa viimeisintä mittausaikaa ko. asemalla. Tästä johtuen yksittäisten sensoreiden päivittymisen seuraaminen voi olla haastavaan. Ongelman korjaamiseksi tulemme lisäämään sensoreille aikaleiman omasta päivittymisestä. Tiedot tullaan lisäämään niin http- kuin websocket-rajapintaan. Olethan huomannut tiedotteen websocket-rajapinnan loppumisesta: https://groups.google.com/forum/#!category-topic/roaddigitrafficfi/rajapinnan-versiot/xDyQUPjlKLU

Ystävällisin terveisin / Best regards

– Digitraffic asiakastuki / Digitraffic support –

[Teemu K]

Hei,

rajapintaan on näköjään lisätty tuo mainittu aikaleima sensorin päivittymisestä, kiitos tästä. Sen avulla sain selvitettyä, kuinka pitkä aika kuluu kiinteiden sensorien aikaikkunan loppumisesta sensoriarvon päivittymiseen. Mielenkiintoisesti sain ainakin yhden ajanhetken tms-data-tiedostolla reaaliaikaisten asemien aikaerojen keskiarvoksi 2,5 sekuntia ja ajantasaisten puolestaan 230 sekuntia.Tämä tarkoittaa, että useilla ajantasaisilla asemilla kestää noin 3-4 minuuttia ennen kuin edellisen aikaikkunan tiedot ovat käytettävissä. Muutamilla yksittäisillä asemilla kesti yli 400 sekuntia.

Harmi, ettei liukuville sensoreille ole saatavilla ikkunaa, joten vastaavaa tarkastelua ei ole mahdollista tehdä. Koska aikaikkuna on liukuva, niin sen todellinen alku ja loppu jäävät hyvin epämääräisiksi, jos viive voi vaihdella jopa 0-5 minuutin välillä. Tämä takia oikeastaan alunperin teinkin tämän aiheen, ja näillä lisätiedoilla liukuvan ajanhetken luotettavuus pienenee entisestään. Reaaliaikaisilla asemilla asemilla viive on varmaan ihan kelvollinen niilläkin.

Miksiköhän ajantasa-asemilla kestää näin kauan päivittyä? Ja onko jotain erityistä syytä, miksi kaikki asemat eivät ole reaaliaikaisia? Onko syy tekninen vai taloudellinen (eli liian kallista)? Nämä kysymykset tosin taitavat koskea enemmänkin taustajärjestelmää kuin käyttäjille näkyvää rajapintaa.

Jos kiinnostaa tarkastella viiveitä, niin alla on pieni jq-skripti (tässä ei ole eroteltu eri tyyppejä, koska se vaatii metatiedon käyttämistä). Laskee erotuksen (measuredTime - timeWindowEnd) ja sen lisäksi listaa muita tietoja. Testattu toimivaksi Linuxilla ja toimimattomaksi Windowsilla.

 

curl 'https://tie.digitraffic.fi/api/v1/data/tms-data?lastUpdated=false' | jq -r '[
        .tmsStations[].sensorValues[]
        | select(.timeWindowEnd)
        | [
                .roadStationId,
                .id,
                .timeWindowStart,
                .timeWindowEnd,
                .measuredTime,
                (.measuredTime | fromdateiso8601) - (.timeWindowEnd | fromdateiso8601)
        ]
]
| sort_by(.[5])
| .[]
| @csv'