Skip to first unread message
Teemu Sirkiä
Jul 6, 2017, 6:39:15 PM7/6/17
to rata.digitraffic.fi
Olen yrittänyt saada rajapinnasta ulos raiteiden tietoja ja koordinaattipisteitä GeoJSON-muodossa. Linjaraiteiden osalta tämä vielä onnistui ja palvelin palautti n. 9 megaa olevan datamöykyn halutusti.
Liikennepaikan raiteita on kuitenkin ilmeisesti niin paljon, että rajapinta tukehtuu. Rajoittamalla testimielessä määrän tuhanteen vastaus vielä tulee, mutta mikähän olisi järkevä tapa saada dataa palasissa ulos, kun tuolla rajoituksella ei voi valita sitten enää, mistä kohtaa vastaus alkaa?
Lisäksi kun katsoo yksittäisen raiteen GeoJSON-määrittelyä, niin siinä MultiLineString-määrittelyssä on jostain syystä hyvin paljon toistoa. Aivan kuin elementin muoto olisi siinä tuplasti. Esimerkkeinä NM 362, NM 363 ja HEK V104-V103. Onko tässä jotain, mitä en hoksaa, vai paisuuko tuo määrittely tarpeettomasti jostain syystä?
Liikennepaikan raiteita on kuitenkin ilmeisesti niin paljon, että rajapinta tukehtuu. Rajoittamalla testimielessä määrän tuhanteen vastaus vielä tulee, mutta mikähän olisi järkevä tapa saada dataa palasissa ulos, kun tuolla rajoituksella ei voi valita sitten enää, mistä kohtaa vastaus alkaa?
Lisäksi kun katsoo yksittäisen raiteen GeoJSON-määrittelyä, niin siinä MultiLineString-määrittelyssä on jostain syystä hyvin paljon toistoa. Aivan kuin elementin muoto olisi siinä tuplasti. Esimerkkeinä NM 362, NM 363 ja HEK V104-V103. Onko tässä jotain, mitä en hoksaa, vai paisuuko tuo määrittely tarpeettomasti jostain syystä?
Solita / Jüppe
Jul 7, 2017, 4:22:42 PM7/7/17
to rata.digitraffic.fi
Moi,
tässä on parikin asiaa:
1) Pari rajapintametodia on todella hitaita koska ne tekevät "hieman" turhia kantahakuja. Raiteiden lisäksi ainakin Radat. Näitä saadaan kyllä helposti nopeutettua jahka ehditään.
2) Raide on todellisuudessa yhtenäinen haarautumaton viiva, mutta meillä ei tietomallissa ole vielä päällä rajoitetta tämän varmistamiseksi. Kun rajoite saadaan päälle, voidaan raiteet tarjota ulos Multilinestringin sijaan Linestringinä.
3) On myös mahdollista että raiteiden geometriat tulevat tuplana, laitan muistiin tarkistettavaksi samalla kun raiteita edistetään muutenkin. Kiitos huomiosta!
4) Count-parametri odottelee kaverikseen startIndex-parametria, jolloin dataa voi kysellä sivuttaen. Tuo pitäisi olla helppo lisätä, mutta odottelee edelleen toteuttamista.
5) Yleisesti ottaen propertyName-parametria kannattaa käyttää rajoittamaan datamäärä sarakkeittain mahdollisimman pieneksi jos vain pieni osa datasta kiinnostaa (tämä on toki tradeoff kaikkien käyttäjien kesken jaetun http-cachen osuvuuden kanssa). Tämä joskus nopeuttaa suoritusta jos pois jää jokin raskaasti laskettava sarake. Raiteiden tapauksessa ei tosin taida auttaa.
6) Voit rajata sisältöä myös spatiaalisesti, eli joko bbox-parametrilla (kuten etusivun karttaesimerkki tekee) tai nykyään myös polygonilla (cql_filterin kautta, kuten esimerkeissä). Bbox-parametrin arvoja ei enää ole rajoitettu, joten voit laittaa siihen mieluisasi rajauksen.
Saisitko tällä hetkellä haluamasi rajaamalla bboxilla vaikkapa kahteen laatikkoon?
Pahoittelut puutteista, jotka ilmiselvästi hankaloittavat jo peruskäyttöä. Näiden rajapintojen (infra-api ja jeti-api) kehittämiseen käytetään aikaa operatiivisten järjestelmien tarpeita seuraten, vaikkakin mielelläni käyttäisin niihin aikaa muutenkin.
Teemu Sirkiä
Jul 7, 2017, 5:43:29 PM7/7/17
to rata.digitraffic.fi
Kiitos seikkaperäisestä vastauksesta!
Kannattaa tosiaan tarkistaa, onko niissä muodoissa jotain kummaa, kun vastaus näyttää jotenkin hassulta. Ja LineString olisi varmasti mielekkäämpi muoto antaa vastaus, koska hypyt raiteen sisällä eivät ole junaliikenteessä kauhean toivottavia. :-)
Yritin rajata eilen liikennepaikkojen raiteita niiden pituuden perusteella, jolloin yksi raide olisi pakosti vain yhdessä datapaketissa mukana. Mutta vaikka otin pelkästään yli kilometrin mittaiset raiteet GeoJSON-muodossa ulos, niin ei onnistunut, vaikka niitä on vain muutamia. Tästä tuli ajatus, että tehdäänköhän suodatusta liian myöhään (vasta täydellisesti muodostetusta tulosjoukosta) vai kestääkö pelkkä suodatuskin niin tuhottoman pitkään. Toisaalta pelkässä JSON-muodossa ei vaikuta olevan mitään ongelmia. Täytyy kokeilla, saisiko tuolla aluerajauksella jotain tulosta aikaan. Aiemmin sen käyttäminen oli liian vaivalloista, kun vain tietyt arvot kelpasivat.
Tällä hetkellä on oikeastaan sama, millä vippaskonstilla ne tiedot saisi kertaalleen ulos. Raiteet voisi ottaa OSM:stäkin, mutta tällöin jää puuttumaan elementin ID, jota tarvitaan taas tietojen muuhun yhdistelyyn.
En tiedä, lasketaanko näitä minun puuhailujani enää peruskäytöksi, mutta kyllä nuo rajapinnat ovat muuten toimineet ihan hyvin. :-)
Kannattaa tosiaan tarkistaa, onko niissä muodoissa jotain kummaa, kun vastaus näyttää jotenkin hassulta. Ja LineString olisi varmasti mielekkäämpi muoto antaa vastaus, koska hypyt raiteen sisällä eivät ole junaliikenteessä kauhean toivottavia. :-)
Yritin rajata eilen liikennepaikkojen raiteita niiden pituuden perusteella, jolloin yksi raide olisi pakosti vain yhdessä datapaketissa mukana. Mutta vaikka otin pelkästään yli kilometrin mittaiset raiteet GeoJSON-muodossa ulos, niin ei onnistunut, vaikka niitä on vain muutamia. Tästä tuli ajatus, että tehdäänköhän suodatusta liian myöhään (vasta täydellisesti muodostetusta tulosjoukosta) vai kestääkö pelkkä suodatuskin niin tuhottoman pitkään. Toisaalta pelkässä JSON-muodossa ei vaikuta olevan mitään ongelmia. Täytyy kokeilla, saisiko tuolla aluerajauksella jotain tulosta aikaan. Aiemmin sen käyttäminen oli liian vaivalloista, kun vain tietyt arvot kelpasivat.
Tällä hetkellä on oikeastaan sama, millä vippaskonstilla ne tiedot saisi kertaalleen ulos. Raiteet voisi ottaa OSM:stäkin, mutta tällöin jää puuttumaan elementin ID, jota tarvitaan taas tietojen muuhun yhdistelyyn.
En tiedä, lasketaanko näitä minun puuhailujani enää peruskäytöksi, mutta kyllä nuo rajapinnat ovat muuten toimineet ihan hyvin. :-)
Solita / Jüppe
Jul 7, 2017, 6:00:10 PM7/7/17
to rata.digitraffic.fi
cql_filter tehdään vasta lopulliselle tulosjoukolle lukuunottamatta spatiaalirajausta joka rajaa koko käsiteltävää datamäärää samalla tavalla kuin bbox.
En usko että cql_filteriä tulee tässä suhteessa parannettua. Periaatteessa voisi rakentaa rajapinnan datasta valmis "samanmuotoinen" tietokanta ja käyttää sitä suoraan esimerkiksi geoserverin läpi, mutta sellainen ei kuulu enää näiden rajapintojen vastuualueelle.
Jos on joskus ylimääräistä aikaa ja osoittautuu teknisesti elegantiksi toteuttaa sellaisen datan cql_rajaukset jo tietokannassa jotka suoraan sieltä löytyvät (iso osa datasta on jossainmäärin laskennallista), toteutan sen toki mielelläni :)
En usko että cql_filteriä tulee tässä suhteessa parannettua. Periaatteessa voisi rakentaa rajapinnan datasta valmis "samanmuotoinen" tietokanta ja käyttää sitä suoraan esimerkiksi geoserverin läpi, mutta sellainen ei kuulu enää näiden rajapintojen vastuualueelle.
Jos on joskus ylimääräistä aikaa ja osoittautuu teknisesti elegantiksi toteuttaa sellaisen datan cql_rajaukset jo tietokannassa jotka suoraan sieltä löytyvät (iso osa datasta on jossainmäärin laskennallista), toteutan sen toki mielelläni :)
Teemu Sirkiä
Jul 7, 2017, 6:09:35 PM7/7/17
to rata.digitraffic.fi
Testasin nyt hakea INTERSECTS-haulla ja sopivalla polygonilla, niin sillä kyllä saa ongittua tiedot sopivissa lohkoissa, eli se ratkaisu on tällä hetkellä toimiva.
Kokeilin viedä vielä GeoJSON-möykyn QGIS-ohjelmaan, niin siellä voi ihan graafisesti todeta, että kaikki viivat ovat tuplasti aineistossa. Eli samalla kun konvertoi koordinaatit toiseen järjestelmään omassa päässä, niin voi heittää duplikaatit viivat pois, jolloin aineiston koko puolittuu.
Kokeilin viedä vielä GeoJSON-möykyn QGIS-ohjelmaan, niin siellä voi ihan graafisesti todeta, että kaikki viivat ovat tuplasti aineistossa. Eli samalla kun konvertoi koordinaatit toiseen järjestelmään omassa päässä, niin voi heittää duplikaatit viivat pois, jolloin aineiston koko puolittuu.
Heikki Kauppinen
Jul 12, 2017, 4:06:11 AM7/12/17
to rata.digitraffic.fi
Minä kaipasin tietoa raiteista tietyllä asemalla. Juna tulee raiteelle 3, mutta miten raiteet ja laiturit sijaitsevat toistensa suhteen?
Tein tällaisen haun
mutta tulos ei oikein auennut.
Käytin esimerkkinä omaa asemaani Leppävaaraa:
Tätä minä kaipaan:
Laituri
Raide 1
Raide 2
Laituri
Raide 3
Raide 4
Laituri
eli lyhyesti L12L34L.
Tuossa kyselyn vastauksessa (19.6MB) esiintyy Leppävaaran raiteet 300 jne. Muutenkin tulos on järkyttävän iso, kun olen kiinnostunut vain yhdestä liikennepaikasta.
Voinko tehdä jotenkin kyselyn tietyn liikennepaikan kaupallisista raiteista ja laitureista?
Eli kysely LPV palauttaisi "L12L34L" tai vastaavaa.
Solita / Jüppe
Jul 12, 2017, 5:56:21 AM7/12/17
to rata.digitraffic.fi
Moi,
Leppävaaran raiteet saat suodattamalla raiteita Leppävaaran tunnisteella:
Tuon tunnisteen saat esimerkiksi rautatieliikennepaikkalistauksesta:
HTML-muodon sijaan kannattaa toki käyttää jotakin muuta (json, csv...) jos tätä tekee koneellisesti.
Lisäksi kannattaa käyttää propertyName-parametria suodattamaan sarakkeita jos päätyy hakemaan pitkiä listauksia. Tosin tällöin http-cache-osuvuus mahdollisesti heikkenee.
Laiturien tiedot ovat tulossa rajapintaan, ja laitureilla tulee olemaan jonkinlainen suhde niiden vierestä kulkeviin raiteisiin. Toivottavasti lähitulevaisuudessa, mutta asiaa monimutkaistaa se, ettei "Raide" ole kovinkaan yksiselitteisesti määritelty kokonaisuus. Rajapinnan palauttamat raiteet tulevatkin jossain määrin muuttumaan, todennäköisesti ainakin niin ettei mikään raide ole sijoitettu joko liikennepaikalle tai linjalle, vaan se voi leikata useampia. Samaten kaupallinen numero ei tarkalleen ottaen ole Raiteen ominaisuus, vaan enemmänkin "Raiteen numero tietyllä Rautatieliikennepaikalla", mutta en osaa vielä sanoa miten tämä tulee rajapinnassa lopulta näkymään.
Lähitulevaisuudessa saamme rajapintaan myös Raideosuudet, joiden myötä saattaa tulla jossakin muodossa mukaan toinen raiteen käsite (ks Liikenneviraston Rato 6). Tämäkään raide ei ilmeisesti ole aina tarkalleen sama mitä ihminen ajattelee raiteena, joten se ei välttämättä helpota laitureiden ja kaupallisten numeroiden käsittelyä.
Kiitos mielenkiinnosta, ja kerrothan mikäli kaipaat lisää tietoja!
Kiitos mielenkiinnosta, ja kerrothan mikäli kaipaat lisää tietoja!
Heikki Kauppinen
Jul 13, 2017, 3:07:38 AM7/13/17
to rata.digitraffic.fi
Tuolla haulla saan kaupalliset raiteet 3, 4 ja 300-314. Niitä on seitsemän. Paikalla käytyäni voi vakuuttaa, että raiteita on neljä, ei 7. Raiteet 1 ja 2 puuttuvat. Saman datan löysin jo tuosta massahausta.
Kaipaan siis vain kaupallisia raiteita matkustajaliikennepaikalla.
Ja laituri siis puuttuu.
Käytännön merkitys tällä on se, että vaihdan junaa jossakin ja näen että saapuva juna tulee raiteelle 2 ja lähtevä on raiteella 3. Ovatko nämä raiteet laiturin molemmin puolin?
Solita / Jüppe
Jul 13, 2017, 5:23:26 AM7/13/17
to rata.digitraffic.fi
Moi,
"Raiteita" voi hyvinkin olla 7 tai enemmänkin. Tämä liittyy juuri siihen mitä Raide tarkoittaa. Jos huomioit vain "aikataulutettavat" raiteet niin saat ehkä vain ne mitä haluat?
Luulisin että mainitsemasi puuttuvat raiteet ovat linjaraiteina, eli ne saa toistaiseksi listaamalla sopivan liikennepaikkavälin raiteita (liikennepaikkavälit ovat tosin vielä osittain sekaisin historian painolastista, mikä korjaantuu lähitulevaisuudessa). Tämä liittyy juuri siihen että raiteet on jaettu keinotekoisesti (muös historian painolastia) aina joko rautatieliikennepaikalle tai linjalle. Tämä tulee siis myöhemmin muuttumaan niin että kukin raide tietää mitä rautatieiikennepaikkoja se leikkaa. Toinen vaihtoehto tällä hetkellä on rajata raiteita spatiaalisesti eli sopivalla bbox:lla tai polygonilla, jos haluamasi alue on jotenkin tiedossa.
Laiturit ovat tulossa rajapintaan. Vielä tuota dataa ei ole saatavila.
"Raiteita" voi hyvinkin olla 7 tai enemmänkin. Tämä liittyy juuri siihen mitä Raide tarkoittaa. Jos huomioit vain "aikataulutettavat" raiteet niin saat ehkä vain ne mitä haluat?
Luulisin että mainitsemasi puuttuvat raiteet ovat linjaraiteina, eli ne saa toistaiseksi listaamalla sopivan liikennepaikkavälin raiteita (liikennepaikkavälit ovat tosin vielä osittain sekaisin historian painolastista, mikä korjaantuu lähitulevaisuudessa). Tämä liittyy juuri siihen että raiteet on jaettu keinotekoisesti (muös historian painolastia) aina joko rautatieliikennepaikalle tai linjalle. Tämä tulee siis myöhemmin muuttumaan niin että kukin raide tietää mitä rautatieiikennepaikkoja se leikkaa. Toinen vaihtoehto tällä hetkellä on rajata raiteita spatiaalisesti eli sopivalla bbox:lla tai polygonilla, jos haluamasi alue on jotenkin tiedossa.
Laiturit ovat tulossa rajapintaan. Vielä tuota dataa ei ole saatavila.
Solita / Jüppe
Sep 19, 2017, 2:20:02 AM9/19/17
to rata.digitraffic.fi
Moi,
duplikaatit pitäisi nyt olla pois.
Solita / Jüppe
May 22, 2020, 3:47:45 PM5/22/20
to rata.digitraffic.fi
Moi,
jäänyt tähän kommentoimatta tilannetta:
Count-parametrin kaverina on nykyisin startIndex, eli sivutusta voi ajan, paikan, sarakkeiden ja rivien lisäksi tehdä myös "sivuttamalla".
Raiteet on korjattu siten, että vanha jako liikennepaikanraiteisiin ja linjaraiteisiin on poistettu. Jako ei toiminut käytännössä. Raiteiden pitäisi nykyisin olla LineStringejä vaikka rajapinta edelleen tyytyy speksissään MultiLineStringiin.
Rivisuodatusta (cql_filter) on kehitetty yleisesti siten, että jotkut rajausehdot menevät tietokantaan saakka. Tuurilla cql_filter-rajaus siis saattaa nopeuttaa kyselyitä huomattavasti.
Rajapinnasta löytyy nykyisin myös laiturit, ja niillä osuvatRaiteet-tieto. Vielä ei ole tietoa siitä mitkä laiturit ovat yhdessä esimerkiksi raiteiden välissä.
Rajapinnasta löytyy nykyisin myös Aikataulupaikat (paikat, jotka voivat esiintyä aikatauluissa), sekä näille linkitetyt "kapasiteetinhallintayksiköt" jotka muodostuvat aikataulupaikkojen raiteista ja raideosuuksista. Nämä kapasiteetinhallintayksiköt ovat niitä mitä monesti tarkoitetaan "raiteilla" puhuttaessa siitä minne junat pysähtyvät. "Kaupallinen numero" on kuitenkin laiturin ominaisuus (silloin kun raiteella on laituri).
Reply all
Reply to author
Forward
0 new messages