Skip to first unread message
Pasi Salenius
Dec 16, 2017, 8:11:26 AM12/16/17
to rata_digi...@googlegroups.com
Hei,
Kyselin tästä aiemmin Twitterin puolella ja ohjattiin tänne pulisemaan.
Puuhaan harrastuksena Transporter reittiopasta iPhonelle, joka käyttää MQTT-feedejä eri lähteistä. Lisäsin uusimpaan version myös jonkinlaisen tuen tälle uudelle rata.digitraffic.fi MQTT-feedille.
Lisää tietoa sovelluksesta esim. täällä
Malliksi tähän MQTT topic ja payload jollaisia olen nähnyt
train-locations/2017-12-15/9552
{
"trainNumber": 9552,
"location": {
"coordinates": [
25.0489666774804,
60.3020973895208
],
"type": "Point"
},
"speed": 29,
"departureDate": "2017-12-15",
"timestamp": "2017-12-15T17:50:53Z"
}
Tuolla datalla saa helposti rakennettua sovelluksen joka näyttää junan numeron kartalla, mutta miten saisin haettua tämän perusteella mikä juna (InterCity jne), mihin aikaan se lähti, minne se on menossa ja mikä sen reitti on kartalla? Haluan siis pystyä yksilöimään minkä linjan mikä lähtö on kyseessä.
Lähinnä haen tässä GTFS-RT feedin tyyppisiä tietoja, esim reitti id:n avulla linkittäminen aikataulutietoihin olisi helppoa. Onko näitä tulossa tämän MQTT-API:n seuraaviin versioihin?
Junan linjan nimi & tyyppi ja kohde olisi tosi kiva saada suoraan MQTT topicissa/payloadeissa, ilman esim. REST-kutsujen käyttöä, jotta tietoa voisi näyttää puhelimen kartalla nopeasti.
Pasi
Teemu Sirkiä
Dec 17, 2017, 5:56:09 PM12/17/17
to rata.digitraffic.fi
Kommentoin tätä asiaa nyt ihan puhtaasti kehittäjän näkökulmasta.
Tässä tasapainotellaan sen kanssa, kuinka "kehittynyttä" tietoa rajapinnasta pitäisi saada suoraan ulos. Pitäisikö sovelluskehittäjän voida toteuttaa sovelluksensa niin, että siihen ei tarvita mitään omaa palvelintoteutusta, vaan kaikki data pitäisi saada suoraan rajapinnasta täysin käyttökelpoisessa muodossa. Tällöin tarvitaan erittäin rikkaat rajapinnat, joiden pitäisi pystyä palvelemaan kaikenlaisia mahdollisia käyttötarkoituksia.
Itse olen ainakin lähtenyt toteuttamaan Julia-palveluani niin, että asiakassovellus ei koskaan kommunikoi suoraan avoimen rajapinnan kautta, vaan oma palvelimeni hoitaa kaiken liikenteen rajapinnan kanssa. Näin vastaan itse siitä kuormasta, jota sovellukseni käyttö aiheuttaa ja toisaalta pystyn yhdistelemään kaikkia datalähteitä täsmälleen haluamallani tavalla. Rajapinta antaa raakamuodossa ne oleelliset tiedot, joita tarvitsen, ja voin itse jatkojalostaa niitä eteenpäin ja antaa palvelimelta sovellukselle käyttökelpoisessa muodossa. Rajapinnan näkökulmasta on sama, käyttääkö palveluani kymmenen vai tuhat käyttäjää, sillä Julia aiheuttaa aina vakiokuorman avoimeen rajapintaan.
En tokikaan kiellä, etteikö noista pyydetyistä tiedoista olisi hyötyä. Tämä kuitenkin samalla myös kasvattaa aina liikkuvan datan määrää ja tuottaa mahdollisesti tarpeetonta tietoa muille hyödyntäjille. Toisaalta se tekee toteutuksesta aina myös avoimen rajapinnan päässä hieman mutkikkaampaa.
Itse en ainakaan täysin avoimesti kannata ideologiaa, jossa tehdään mahdollisesti kaupallinen sovellus, jonka ylläpitämisestä ei koidu kehittäjälle mitään kustannuksia esimerkiksi oman palvelinympäristön muodossa, vaan kaikki tieto halutaan suoraan rajapinnasta valmiiksi pureskeltuna ulos ja kaikki dataliikenne ohjataan suoraan avoimen datan rajapintoihin, joita ei alun perin ole varmaan edes tehty suoraan vaikkapa mobiili-client -käyttöä varten suurten aineistomöykkyjen vuoksi.
Tässä tasapainotellaan sen kanssa, kuinka "kehittynyttä" tietoa rajapinnasta pitäisi saada suoraan ulos. Pitäisikö sovelluskehittäjän voida toteuttaa sovelluksensa niin, että siihen ei tarvita mitään omaa palvelintoteutusta, vaan kaikki data pitäisi saada suoraan rajapinnasta täysin käyttökelpoisessa muodossa. Tällöin tarvitaan erittäin rikkaat rajapinnat, joiden pitäisi pystyä palvelemaan kaikenlaisia mahdollisia käyttötarkoituksia.
Itse olen ainakin lähtenyt toteuttamaan Julia-palveluani niin, että asiakassovellus ei koskaan kommunikoi suoraan avoimen rajapinnan kautta, vaan oma palvelimeni hoitaa kaiken liikenteen rajapinnan kanssa. Näin vastaan itse siitä kuormasta, jota sovellukseni käyttö aiheuttaa ja toisaalta pystyn yhdistelemään kaikkia datalähteitä täsmälleen haluamallani tavalla. Rajapinta antaa raakamuodossa ne oleelliset tiedot, joita tarvitsen, ja voin itse jatkojalostaa niitä eteenpäin ja antaa palvelimelta sovellukselle käyttökelpoisessa muodossa. Rajapinnan näkökulmasta on sama, käyttääkö palveluani kymmenen vai tuhat käyttäjää, sillä Julia aiheuttaa aina vakiokuorman avoimeen rajapintaan.
En tokikaan kiellä, etteikö noista pyydetyistä tiedoista olisi hyötyä. Tämä kuitenkin samalla myös kasvattaa aina liikkuvan datan määrää ja tuottaa mahdollisesti tarpeetonta tietoa muille hyödyntäjille. Toisaalta se tekee toteutuksesta aina myös avoimen rajapinnan päässä hieman mutkikkaampaa.
Itse en ainakaan täysin avoimesti kannata ideologiaa, jossa tehdään mahdollisesti kaupallinen sovellus, jonka ylläpitämisestä ei koidu kehittäjälle mitään kustannuksia esimerkiksi oman palvelinympäristön muodossa, vaan kaikki tieto halutaan suoraan rajapinnasta valmiiksi pureskeltuna ulos ja kaikki dataliikenne ohjataan suoraan avoimen datan rajapintoihin, joita ei alun perin ole varmaan edes tehty suoraan vaikkapa mobiili-client -käyttöä varten suurten aineistomöykkyjen vuoksi.
Solita / Jaakko
Dec 18, 2017, 12:56:06 AM12/18/17
to rata.digitraffic.fi
Junan tyypin ja muut tiedot saa tosiaan REST-pyynnöllä osoitteesta https://rata.digitraffic.fi/api/v1/trains/2017-12-09/1914 kuten mainitsit. Voit pistää tiedot välimuistiin, joten REST-kutsuja tarvitsee tehdä yksi per juna. Vaihtoehtoisesti voit hakea kaikki päivän junat osoitteesta https://rata.digitraffic.fi/api/v1/trains/2017-12-09/, jolloin sinun ei tarvitse tehdä kuin yksi hieman isompi REST-kutsu. Tai vielä vaihtoehtoisemmin voit hakea junatyypit GTFS-datasta https://rata.digitraffic.fi/api/v1/trains/gtfs-all.zip ja luottaa siihen, että tiedot eivät ihan heti muutu.
On mielestäni tärkeää, että train-location -malli pysyy pienenä, koska se vie kaistaa ja CPU:ta paljon. En lisäksi usko, että kaikki kehittäjät tarvitsevat esim. junatyyppia. Eli datan lisäjalostaminen jää valitettavasti kehittäjän harteille.
Yt. Jaakko / Solita
Pasi Salenius
Dec 18, 2017, 2:03:38 AM12/18/17
to rata_digi...@googlegroups.com
Jaakko, onko tämä MQTT-API tarkoitettu suoraan client-sovellusten käyttöön? Näin ymmärtääkseni yleensä on, ainakin HSL:n MQTT-feedien tapauksessa. Vai onko API-käyttäjien tarkoitus tilata feedi palvelimelleen ja jaella itse siitä eteenpäin?
Transporter sovellukselle on kyllä oma palvelin ja voin periaatteessa tehdä tämän kummin vaan. En vaan olettanut että joidenkin kymmenien clientien MQTT-tilausten kuorma olisi tässä mikään issue. Jos kaistankäytöstä on huolta, niin eikö tätä MQTT payloadin rakennetta kannattaisi vähän optimoida nykyisestä? Vaikkapa "trainNumber" > "tn" tms.
Mielestäni siihen kannattaisi pakata kuitenkin edes se minimaalinen määrä hyödyllistä tietoa, juuri junan tyyppi, kohdeasema, routeId, tripId tyyppisiä kenttiä. Tällä tavalla tälle datalle tulisi varmasti myös enemmän käyttöä.
--
Sait tämän viestin, koska olet tilannut seuraavan Google-ryhmän: rata.digitraffic.fi.
Jos haluat peruuttaa tämän ryhmän tilauksen ja sen sähköpostiviestien vastaanottamisen, lähetä sähköpostia osoitteeseen rata_digitraffic_fi+unsub...@googlegroups.com.
Käy tässä ryhmässä osoitteessa https://groups.google.com/group/rata_digitraffic_fi.
Jos haluat tarkastella tätä keskustelua verkossa, siirry osoitteeseen https://groups.google.com/d/msgid/rata_digitraffic_fi/b391d2a5-34c9-49ae-8d1c-874de8c7663e%40googlegroups.com.
Pasi Salenius
Dec 18, 2017, 4:05:12 AM12/18/17
to rata_digi...@googlegroups.com
Teemu, ymmärrän näkökulmasi vaikka en ole ihan samoilla linjoilla :-) Mobiili-reittioppaat ovat perinteisesti käyttäneet suoraan esim. HSL:n Reittiopas- tai Liikenneviraston Matka.fi -rajapintoja. Reittioppaiden liikennekuormat voivat olla aika reiluja, ja näillä tahoilla on nimenomaan ollut halua tarjota tietoa tässä mittakaavassa myös API:en ylitse. Täytyy tähän väliin huomauttaa että omalla sovelluksella käyttäjiä on todella rajallinen määrä eikä samanaikaisia käyttäjiä ole montaa kappaletta :-)
Mobiilisovellus voisi tietysti hakea kaiken datansa kehittäjän omalta palvelimelta, joka toimii välikätenä muihin julkisiin rajapintoihin. Mielestäni on kuitenkin turhaa asettaa pullonkaulaksi kehittäjän resursseja. Iso juttu tässä on myös mobiilisovellusten yllättävän pitkä elinkaari senkin jälkeen kun sovellus on mahdollisesti lopetettu ja otettu pois myynnistä. Monet haluavat edelleen käyttää kerran lataamaansa appia. Jollei sen käyttö riipu kehittäjän palvelinympäristöstä, näin myös tehdä niin kauan kuin julkiset rajapinnat ovat pystyssä. Webisivustojen tapauksessa käyttö loppuu kun sivusto suljetaan.
Reaaliaikaisen datan kanssa kapasiteetti voi olla iso kysymys, mutta olen sillä kannalla että API:n tarjoajalla pitäisi myös olla resursseja sen laajamittaiseen käyttöön. Tai vaihtoehtoisesti ilmoittaa selkeästi ehdoissa että käyttö on rajattu esim. yhteen samanaikaiseen yhteyteen per user-tokeni.
2017-12-18 9:03 GMT+02:00 Pasi Salenius <pa...@freshbits.fi>:
Jaakko, onko tämä MQTT-API tarkoitettu suoraan client-sovellusten käyttöön? Näin ymmärtääkseni yleensä on, ainakin HSL:n MQTT-feedien tapauksessa. Vai onko API-käyttäjien tarkoitus tilata feedi palvelimelleen ja jaella itse siitä eteenpäin?Transporter sovellukselle on kyllä oma palvelin ja voin periaatteessa tehdä tämän kummin vaan. En vaan olettanut että joidenkin kymmenien clientien MQTT-tilausten kuorma olisi tässä mikään issue. Jos kaistankäytöstä on huolta, niin eikö tätä MQTT payloadin rakennetta kannattaisi vähän optimoida nykyisestä? Vaikkapa "trainNumber" > "tn" tms.Mielestäni siihen kannattaisi pakata kuitenkin edes se minimaalinen määrä hyödyllistä tietoa, juuri junan tyyppi, kohdeasema, routeId, tripId tyyppisiä kenttiä. Tällä tavalla tälle datalle tulisi varmasti myös enemmän käyttöä.
2017-12-18 7:56 GMT+02:00 Solita / Jaakko <jaakko.pa...@solita.fi>:
Junan tyypin ja muut tiedot saa tosiaan REST-pyynnöllä osoitteesta https://rata.digitraffic.fi/api/v1/trains/2017-12-09/1914 kuten mainitsit. Voit pistää tiedot välimuistiin, joten REST-kutsuja tarvitsee tehdä yksi per juna. Vaihtoehtoisesti voit hakea kaikki päivän junat osoitteesta https://rata.digitraffic.fi/api/v1/trains/2017-12-09/, jolloin sinun ei tarvitse tehdä kuin yksi hieman isompi REST-kutsu. Tai vielä vaihtoehtoisemmin voit hakea junatyypit GTFS-datasta https://rata.digitraffic.fi/api/v1/trains/gtfs-all.zip ja luottaa siihen, että tiedot eivät ihan heti muutu.On mielestäni tärkeää, että train-location -malli pysyy pienenä, koska se vie kaistaa ja CPU:ta paljon. En lisäksi usko, että kaikki kehittäjät tarvitsevat esim. junatyyppia. Eli datan lisäjalostaminen jää valitettavasti kehittäjän harteille.Yt. Jaakko / Solita
--
Sait tämän viestin, koska olet tilannut seuraavan Google-ryhmän: rata.digitraffic.fi.
Jos haluat peruuttaa tämän ryhmän tilauksen ja sen sähköpostiviestien vastaanottamisen, lähetä sähköpostia osoitteeseen rata_digitraffic_fi+unsubscribe...@googlegroups.com.
Käy tässä ryhmässä osoitteessa https://groups.google.com/group/rata_digitraffic_fi.
Pasi Salenius
Dec 18, 2017, 4:15:41 AM12/18/17
to rata_digi...@googlegroups.com
Ja edelleen, Liikennevirasto teetti 2016 selvityksen reaaliaikaisen datan tarjoamisesta ja käytöstä
Siinä suositellaan että reaaliaika-feedissä pitäisi olla nuo mainitsemani linjoja ja lähtöjä yksilöivät tiedot mukana, jotta dataa voisi käyttää modernien reittioppaiden tarpeisiin ja se toimisi joustavasti eri sovelluksissa. Voi olla etten nyt ole tietoinen jostain toisesta kattavammasta GTFS-RT feedistä joka junaliikenteelle on tarjolla. Käytän sellaista jos mahdollista.
Muutoin olisi todella vahinko jos tämä MQTT GPS-sijaintidata jätettäisiin näin kevyeksi sisällöltään, varsinkin kun ollaan aika lähellä todella käyttökelpoista API-toteutusta.
Pasi Salenius
Dec 18, 2017, 7:30:12 AM12/18/17
to rata_digi...@googlegroups.com
Teemu,
Vaikka katsoisin tätä sinun kannaltasi, ja päätyisin tekemään samalla tavalla datan rikastamisen omalla palvelimellani, mitä jos haluat joskus jatkossa näyttää omassa palvelussasi kunkin kartan junan lähtöajan ensimmäiseltä asemalta ja saapumisajan kohteeseen? En näe miten se on nykyisillä tiedoilla mahdollista. Eikö nämä tiedot olisi hyödyksi sinunkin palvelullesi?
Tämä on vain mielestäni se kiinnostavin asia koko GPS-sijainti API:ssa eikä puhuta "kaikesta datasta täysin käyttökelpoisessa muodossa" vaan aivan perusjutuista.
Pasi
--
Sait tämän viestin, koska olet tilannut seuraavan Google-ryhmän: rata.digitraffic.fi.
Jos haluat peruuttaa tämän ryhmän tilauksen ja sen sähköpostiviestien vastaanottamisen, lähetä sähköpostia osoitteeseen rata_digitraffic_fi+unsub...@googlegroups.com.
Käy tässä ryhmässä osoitteessa https://groups.google.com/group/rata_digitraffic_fi.
Jos haluat tarkastella tätä keskustelua verkossa, siirry osoitteeseen https://groups.google.com/d/msgid/rata_digitraffic_fi/ff4ea1d7-9db9-47e3-9ff2-f30a64e66aa6%40googlegroups.com.
Teemu Sirkiä
Dec 18, 2017, 7:38:01 AM12/18/17
to rata.digitraffic.fi
maanantai 18. joulukuuta 2017 14.30.12 UTC+2 Pasi Salenius kirjoitti:
Teemu,Vaikka katsoisin tätä sinun kannaltasi, ja päätyisin tekemään samalla tavalla datan rikastamisen omalla palvelimellani, mitä jos haluat joskus jatkossa näyttää omassa palvelussasi kunkin kartan junan lähtöajan ensimmäiseltä asemalta ja saapumisajan kohteeseen? En näe miten se on nykyisillä tiedoilla mahdollista. Eikö nämä tiedot olisi hyödyksi sinunkin palvelullesi?Tämä on vain mielestäni se kiinnostavin asia koko GPS-sijainti API:ssa eikä puhuta "kaikesta datasta täysin käyttökelpoisessa muodossa" vaan aivan perusjutuista.
Tällöinhän voin tuottaa itse clientille omalta palvelimelta sellaista feediä, jossa yhdistän GPS-tiedot sekä junan numeron ja lähtöpäivän perusteella aikataulusta aikatiedot. En näe tässä mitään ongelmaa. Molemmat tiedot saa rajapinnasta. /api/v1/trains/latest/1234 tuottaa aikataulutiedot ko. junalle tai koko päivän aikataulut voi ladata itselle talteen /api/v1/trains/2017-12-18 Nämäkin rajapinnat on suunnattu selvästi palvelimelta palvelimelle kulkevaan kommunikointiin, koska tietomäärät ovat suuria etenkin tuossa koko päivän aikataulut käsittävässä nipussa.
Haluan nyt vielä korostaa, ettei tarkoitus ollut mitenkään kritisoida esittämääsi pyyntöä, vaan herättää keskustelua vähän toisesta näkökulmasta. Itse ainakin yritän minimoida vaikka tuolta GPS-sijaintitiedoista ladattavan datan määrän ja tällöin olisi turhaa, jos sieltä tulisi sijaintitiedon mukana aina esimerkiksi junan kokonainen aikataulu tai muuta staattista tietoa, joka ei muutu sillä tiheydellä kuin juna kulkee.
Tomi Lapinlampi / Liikennevirasto
Dec 18, 2017, 7:56:26 AM12/18/17
to rata.digitraffic.fi
Hei,
hyvää keskustelua ja mielenkiintoisia näkökulmia!
Vastauksena Pasin kysymyksiin ja ideoihin:
MQTT-API on tarkoitettu suoraan sovellusten, ei pelkästään backendien käyttöön kuten Digitrafficin muutkin rajapinnat. On totta, että HSL on Suomessa edelläkävijä joukkoliikenteen reaaliaikaisen sijaintitiedon keräämisessä, esittämisessä ja erityisesti jakelussa.
Olen varma, että Jaakon kuvailemat tekniset haasteet (resurssi-intensiivisyys rajapintapalvelussa) ovat ratkaistavissa tavalla tai toisella tulevan vuoden aikana. Eräs mahdollinen tekninen toteutus voisi olla GTFS-RT, kunhan ensin saamme nykyisen GTFS-toteutuksen hyvään kuntoon.
Olin aiemmin tänä vuonna mukana reaaliaikapilotti-projektissa ja olen samaa mieltä projektiraportissa esitetyistä johtopäätöksistä, joihin Pasi tuossa jo linkkasikin.
Terveisin,
- Tomi / Liikennevirasto
Pasi Salenius
Dec 18, 2017, 8:09:01 AM12/18/17
to rata_digi...@googlegroups.com
En siis halua junan koko aikataulua jokaiseen MQTT payloadiin. Mielestäni täydellinen payload voisi mukailla HSL:n speksiä (https://digipalvelutehdas.hackpad.com/HSL-MQTT-API-draft) vaikkapa jotenkin näin:
{
"nbr": 9552,
"trainType": "HL",
"desi": "K", ← linjan nimi
"head": "Kerava", ← kohde ehkä lukee junan kyljessä
"line": "HSL:3001K", ← GTFS-dataan linkittävä routeId
"trip": "HSL:3001K:0:01", ← GTFS-dataan linkittävä tripId
"dir": 1,
"coord": [
25.0489666774804,
60.3020973895208
],
"spd": 29,
"dep": 1513600000, ← lähtöaika timestamp
"del": 30, ← viivästynyt aikataulusta
"tsi": 1513601248, ← päivityksen timestamp GPS-paikantimessa
}
--
Sait tämän viestin, koska olet tilannut seuraavan Google-ryhmän: rata.digitraffic.fi.
Jos haluat peruuttaa tämän ryhmän tilauksen ja sen sähköpostiviestien vastaanottamisen, lähetä sähköpostia osoitteeseen rata_digitraffic_fi+unsub...@googlegroups.com.
Käy tässä ryhmässä osoitteessa https://groups.google.com/group/rata_digitraffic_fi.
Jos haluat tarkastella tätä keskustelua verkossa, siirry osoitteeseen https://groups.google.com/d/msgid/rata_digitraffic_fi/21754cd6-0169-4db8-bc3f-1f6122ee70c9%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages