Live trains rajapinta

[Pasi Salenius]

Lähdin nyt kehittämään eteenpäin junien tietojen esittämistä Transporter-sovelluksessani.

Tässä muutama huomioita:

Juuri kun tätä kirjoitan tämä API-kutsu ei palauta yhtäkään junaa

https://rata.digitraffic.fi/api/v1/live-trains?arrived_trains=0&arriving_trains=1&departed_trains=0&departing_trains=1&station=HKI

Sen sijaan tämä kutsu, jossa arriving_trains=5 ja departing_trains=5 palauttaa yhden junan

https://rata.digitraffic.fi/api/v1/live-trains?arrived_trains=0&arriving_trains=5&departed_trains=0&departing_trains=5&station=HKI

Eivätkö nuo parametrit määritä maksimimäärät, eli arvolla 1 pitäisi tulla se yksi juna? Nyt näen että esim. junat.net kutsuu toistuvasti arriving_trains=100 ja departing_trains=100 parametreilla junia, ehkä jotta saa ainakin jotain vastauksia takaisin. Haluaisin rajoittaa haut esim. 10 tai 20 seuraavaan lähtevään junaan, käyttämättä turhaan verkkoa isojen graphQL JSON-vastausten lataamiseen.

GraphQL-API on nykyisellään aivan toivottoman hankala käyttää. Sen objektit näyttävät REST API -kutsujen perusteella autogeneroiduilta, esim. getTrainsFromDepartureToArrivalStationUsingGET_items_timeTableRows_items_trainReady on yhden objektin nimi.

Kuten GraphQL rajapinnoissa yleensä on tapana, aliobjekteja ja niiden variableja haetaan toistensa sisältä, vrt. HSL Digitransit GraphQL-rajapinta. Digitraffic API:ssa tämä ei onnistu koska mitään yleisiä objekteja (esim. Train, Station tai TimetableRow) ei edes ole olemassa. Hyvin yleinen use case olisi pyytää GraphQL:ää käyttäen junan timetable rivit ja kunkin sisällä juna-aseman nimi. Nyt se ei ole mahdollista ilman usean erillisen queryn käyttöä.

Lopuksi, olisin odottanut voivani halutessani tehdä Digitraffic GraphQL:ssä vaikkapa jotain tämän kaltaista:

{

  train(commuterLineID: "A") {

    trainNumber

    stations {

      name

      scheduledArrival

      trains {

        trainNumber

      }

    }

  }

}

[Solita / Jaakko]

Terve

Ensinnäkin suuret pahoittelut, että en tähän vastannut aiemmin. Viesti meni minulta ohi.

Kyseessä näyttäisi olevan puhdas bugi. Palaan asiaan kun tilanne on ratkennut.

GraphQL on tosiaan autogeneroitu REST API-kutsujen perusteella. Muunlainen lähestymistapa olisi ollut huomattavasti työläämpi. Keskustelemme tuosta vielä sisäisesti ja palaan asiaan.

Yt. Jaakko / Solita

[Solita / Jaakko]

Bugin pitäisi olla nyt korjaantunut. Ongelmana oli kauan sitten peruttujen junien (train.deleted) virheellinen käsittely. Kiitoksia kun raportoit tämän suhtkoht ison bugin

Yt. Jaakko / Solita

[Pasi Salenius]

Kiitokset, nyt näyttäisi live-trains kutsu toimivan kuten pitää, myös GraphQL muodossaan 👍🏻

Sain tällä erää kaiken tarvitsemani tehtyä nykyisellä GraphQL API:lla ja julkaisin sovelluksen päivitykseni, mutta noin yleensä tuli sellainen olo että tämä on hyvinkin köyhän miehen versio GraphQL:stä.

HSL:n API:n kanssa toimiessa on tottunut joustavasti hakemaan tarvitsemiaan tietoja melkeinpä minkä vaan objektin sisältä, josta aliobjektien tulisi löytyä aina kun se vaan loogisesti vaan on mahdollista. Kuinka tämä käytännössä toteutetaan palvelinpuolella, en tiedä. Kokemusta on lähinnä API:n käyttäjänä 🙂

Pasi

[Pasi Salenius]

Tämä seuraava kutsu, jota lähinnä käytän, tukee vain juuri nyt saapuvien ja lähtevien junien hakua:

Liikennepaikan saapuvat ja lähtevät junat (lukumäärärajoitus)

Voisiko ajatella että tässä olisi yhtenä parametrina aika, jotta aikataulun mukaiset lähdöt voisi hakea vaikka huomiselle tai muutaman viikon kuluttua?

Pasi

[Pasi Salenius]

Haluaisin myös jotenkin kysyä kaikki junat, jotka nykyisen aikataulun mukaisesti koko viikolla pysähtyvät tietyllä asemalla. Nyt voin kai kysyä tätä tietylle päivälle tai nykyhetkelle. Mutta olisi kiva saada kooste kaikista junista, jotka asemalle saapuvat ylipäätään.

Pasi

[Solita / Jaakko]

1) Kappalerajoitus

Tämä on mielestäni hyvä idea. Tein tästä tiketin DPO-867

2) Viikon kooste

Ongelmaksi muodostuu vastauksen suuri koko, jos oletetaan, että vastaus annetaan perusformaatissa. En ole kovin innokas suunnitelemaan uusia formaatteja.

Voisiko tämän hoitaa siten, että hakee itse monen päivän junat ja muodostaa niistä koosteen?

3) MQTT-parannukset

Tutustumme HSL:n GraphQL-toteutukseen ja tehdään päätöksiä sen jälkeen. Et ole ensimmäinen, joka ylistää HSL:n GraphQL-toteutusta :-) Erityisesti kiinnostaa miten tiedon cachetus on hoidettu. Tiketti DPO-868

[Pasi Salenius]

Vielä selvennyksen vuoksi 🙂

Kappalerajoitus siis nyt toimii arrived_trains ja arriving_trains tyyppisten parametrien avulla.

Mutta haluan kysyä nuo vaikka ensi viikon torstaille klo 16.30, siten kun junat aseman aikataulun mukaan olisivat kulkemassa. Eli tarvitsisin getStationsTrainsUsingGET kutsuun myös date tai timestamp parametrin, jolla voi asettaa tarkan haluamansa ajan. Nykyisellä kutsulla saan junat aina tälle hetkelle.

Pasi

[Solita / Jaakko]

Jep, valitsin epäselvästi #1 kohdan otsikon

[Pasi Salenius]

Koska tämä getStationsTrainsUsingGET kutsu on ainakin minulle niin olennainen, niin pyytäisin vielä että haun voisi rajoittaa isPassengerTrain booleanilla. Nyt täytyy tehdä pyyntö esim. 30 seuraavalle junalle, joista puolet voikin olla tavarajunia tms. joita ei halua näyttää sovelluksessa.

Pasi

[Pasi Salenius]

Ongelmaksi muodostuu vastauksen suuri koko, jos oletetaan, että vastaus annetaan perusformaatissa. En ole kovin innokas suunnitelemaan uusia formaatteja.

Tässä juuri piilee GraphQL:n kauneus. "Perusformaatti" junalle voi sisältää junan numeron lisäksi monia muita tietoja (esim. aikataulurivit). Tässä kyseisessä use casessa hakisin aseman kaikille junille vaikkapa vain trainTypet ja trainNumberit. Sillä ei ole niinkään väliä millainen koko junan objekti kokonaisuudessaan on, pyydän siitä vaan tarvitsemani tiedot ja näin vastaus pysyy pienenä.

Eli kuvitteellisesti jotenkin näin:

{

  viewer {

    getStationsUsingGET(where: "[*stationShortCode=HKI]") {

      stationShortCode

      train {

        trainType

        trainNumber

      }

    }

  }

}

Käytännössä juna-objektissa voisi olla tarjolla kaikki tiedot, mitä sille vaan on mahdollista palauttaa. Rajapinnan käyttäjä kuitenkin pyytää näistä tiedoista vaan tarvitsemansa.

Vastausten kokoa tai monimutkaisuutta voi ehkä joutua pohtimaan vasta, jos client esim. pyytää monia sisäkkäisiä listoja.

[Pasi Salenius]

Kovasti myös tykkäisin, että train-locations MQTT feedi julkaisisi junien päivityksiä tiheämmin kuin nykyisen yli 10s välein.

Varsinkin kun vertaa HSL:n MQTT-dataan, joka päivittää kaikkia (!) liikennevälineitä 1s välein ja jokaisessa payloadissa on paljon kattavammin dataa. Tämä train-locations MQTT-feedi ei myöskään sisällä junien suuntaa (bearing) eli niiden suuntanuoli kartalla näyttää väärin kunnes ensimmäinen päivitys tulee 10s kuluttua.

Tässä mitä olen viimeksi saanut tehtyä Digitraffic-datan avulla (saa jakaa :)

https://twitter.com/Transporter_iOS/status/1161590860028534784

Pasi

[Solita / Jaakko]

> Koska tämä getStationsTrainsUsingGET kutsu on ainakin minulle niin olennainen, niin pyytäisin vielä että haun voisi rajoittaa isPassengerTrain booleanilla. Nyt täytyy tehdä pyyntö esim. 30 seuraavalle junalle, joista puolet voikin olla tavarajunia tms. joita ei halua näyttää sovelluksessa.

Hyvä idea tämäkin. Lisäsin tiketille

> Kovasti myös tykkäisin, että train-locations MQTT feedi julkaisisi junien päivityksiä tiheämmin kuin nykyisen yli 10s välein.

Ehkä tämäkin vielä onnistuu. Rajoite on tällä hetkellä lähdejärjestelmän puolella

> Tässä juuri piilee GraphQL:n kauneus

Jep. Hyvällä GraphQL-toteutuksella pitkien aikavälien koostehaut olisivat mahdollisia (etenkin suorituskykymielessä)

[Pasi Salenius]

Onko train-locations MQTT-feedin frekvenssiin tulossa korjausta?

Nyt kun juna-asemat ja niiden junien näyttö on ollut Transporter-sovelluksessani kotvasen tarjolla, on käyttäjäpalaute lähinnä liittynyt junien hitaaseen liikkumiseen kartalla. Tuo nykyinen 10 - 15 sekunnin frekvenssi on kuitenkin melko kaukana junan reaaliaikaisen sijainnin seuraamisesta.

Voiko tämän edistymisestä seurata jotain julkista tikettiä?

[Solita / Jaakko]

Terve

Tästä ei valitettavasti ole julkista tikettiä. Sisäinen tiketti on KUPLA-1533, mikäli siitä on jotakin iloa

Seuraavassa veturin päätelaitepäivityksessä menee ominaisuus, jolla päivitysväliä voidaan säätää etänä. Tämän jälkeen päivitysnopeutta voidaan pikkuhiljaa nopeuttaa ja katsoa miten systeemit kestävät kuorman. Asiat siis edistyvät pikkuhiljaa

Yt. Jaakko