Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

Niin no, tälläsiä nää “lakiasiat” tuntuu olevan nykyään (pitäähän lakimiesten jostain saada palkkaa kun enää luetun ymmärtäminen ei riitä). …Kumma juttu muuten kun tuollaisia heittävät kaverit eivät koskaan muulloin miellä kuvia tietokannoiksi tai muuta älytöntä. Musta nykyään kaikki laintulkinta on mennyt juurikin tuollaiseen älyttömyyteen että laeissa, lisensseissä ja sopimuksissa, yms. sanat eivät enää tarkoitakaan mitä normaalisti tarkoittavat. Esim. suomessakin yksityistiet joille “on saatu valtion tai kunnan” rahoitusta voikin sulkea koska onkin olemassa kunnan tai valtion “avustus” “ei ollutkaan lain tarkoittama avustus” linjasi joku oikeusaste, yms.

Mutta nuo kyseiset kommentit kyllä sivuuttaisin ihan suoralta kädeltä. Onhan sitä näyttömuistikin lopulta aivan selvästi tietokanta eli parempi ettei pidä yhtäaikaa kahta ikkunaa auki tai laita vierekkäin sivulleen osm.png ja evilbadincompatible.png:tä jotka sattuvat sinne samaan tietokantaan toisiaan tönien piirtymään?


i.

Eli objektien historian voi valtavassa changesetissä hävittää ilomielin? …huolestuttavaa. Tiedän tiedän että historian trackkays ei ole esim. splittien tapauksessa täydellinen mutta silti se ei minusta oikeuta siihen että idt heitetään vaan kaikki mäkeen ja aloitetaan “puhtaalta pöydältä”!


i.

Onhan vielä olemassa radikaali “plan b”, eli ilmiannetaan osm:lle Kemijärven alueella tapahtunut ilkivalta - aiemman osm datan hävitys sekä lisenssien vastainen copyrightin alaisen datan massasyöttö samalle alueelle. :roll_eyes:
http://wiki.openstreetmap.org/wiki/Vandalism

Tai sitten myös radikaali “plan c”, eli pyydetään suunnitelman mukaisesti osm:ää laittamaan maininta MML:stä sinne copyright sivulle, ja kun se on siellä, ilmiannetaan MML:lle Kemijärven alueella tapahtunut MML lisenssin vastainen datan syöttö OSM:ään. Sen jälkeen saataneen MML:n kannanotto onko lisenssiä heidän mielestään rikottu. :sunglasses:

No, ehkä tuo ei MML:n osalta ollut tosissaan tarkoitettu, mutta sanonpa varmuuden vuoksi, että minusta tuo on huono ajatus, MML saattaisi joutua ikävään välikäteen “pakotetuksi” ottamaan kantaa lisenssiin. Vaikka periaatteessa kannanotto voisi olla hyvä, niin ei minusta kannata hakea sitä tällaisen sisäisen näkemyseron kautta, antaisi huonon kuvan.

Sen sijaan minusta tuota ensinmainittua vaihtoehtoa kyllä on syytä ihan vakavasti harkita jos homma ei muuten etene ja jos/kun riittävä konsensus palautuksen puolesta on. Mutta eiköhän tämä muutenkin etene.

Sekä CC BY-SA 2.0:n (vanha lisenssi) että ODbL:n (uusi lisenssi) periaatteita ovat attribution ja se että aineistoa jaetaan (seuraava kaveri) saman tai riittävän yhteensopivan (ei rajoittavamman) lisenssin alla. Nähdäkseni attributionin ei tarvitse yltää edellistä pidemmälle. Kunhan uuden aineiston lisenssi pysyy riittävän samanlaisena. Eli jos käytän OSM-aineistoa, voin (luullakseni) hävittää siitä kaikki “erityis-attributionit” kunhan vaan muistan “attributoida” OSM:ia. Mutta MML vaatii minun “attributoivan” heidän aineistoaan ja tässä on se ongelma. Jotenkin näin se menee. Olen pahoillani kielestä, en jaksa nyt aamutuimaan etsiä hyvää suomenkielistä sanaa tuolle “attribution” (olisiko “nimeäminen”? http://creativecommons.org/licenses/by-sa/2.0/deed.fi))

Yrittäkää ajatella asiaa OSM:n kannalta ei MML:n kannalta. OSM haluaa, että tietokannassa oleva aineisto on maailmanlaajuisesti “laillisesti” hankittua (älkää ajatelko tuota “laillisesti” liian ahtaasti). Muistakaa myös, että USA:n käytännöt (miksei myös Iso-Britannian) ovat olleet merkittävässä osassa mietittäessä miten suojataan OSM aineisto, mutta toisaalta mahdollistetaan sen laaja käyttö. Olette varmaan tömänneet useita kertoja elämässänne lisenssiehtoihin, klikanneet accept sen enempää miettimättä (tl;dr). No, niillä sanoilla on merkitystä. Ongelma ei edelleenkään ole siinä, etteikö MML:lle kävisi aineistonsa lukeminen OSM:iin vaan siinä, voiko OSM ottaa MML:n ehdoilla (==lisenssillä) aineistoa vastaan.

Tämä oli varmaankin sarkasmia, mutta yritetään pysyä aiheessa. Juurikin tietokanta ja sen käsite on aiheuttanut OSM:n (tietokannan) siirtymisen CC BY-SA 2.0 lisenssistä ODbL -lisenssiin. OSM karttapalat (map tiles) ovat edelleen CC BY-SA 2.0 lisenssin alaisia (kts. http://wiki.openstreetmap.org/wiki/OpenStreetMap_License ja sieltä “OpenStreetMap map tiles and other map images can be used freely under the terms of the Creative Commons Attribution-ShareAlike 2.0 license”).

Yksi ratkaisu tähän ongelmaan olisi se, että MML itse lataisi aineistonsa OSM:iin. He omistavat aineistonsa ja saavat tehdä sillä mitä haluavat. Voisiko MML ulkoistaa lataamisen OSM-vapaaehtoisille?

Käytin “plan b:n” sekä “plan c:n” yhteydessä määritelmää radikaali. Ja syystä. Molemmat esimerkkejä äärimmäisistä ja pakottavista keinoista edetä haluttuun suuntaan.

Missä minä niin ehdotin? Poistetun kohteen voi palauttaa vanhasta versiosta samalla ID:llä. Tein kerran niin Mikkelin rautatieaseman katokselle, kun joku ei ollut pitänyt siitä, että amenity=shelter näkyi hänen kartallaan leirintäalueena.

Ajattelin, että seuraavalla tuontiyrityksellä olisi nähty enemmän vaivaa esimerkiksi teiden yhdistämisessä olemassa oleviin käyttäen sopivia algoritmeja. Silloin ID:t säilyisivät.

Tässä:

“Ehdotetut korjaukset” eivät ole missään muodossa ainakaan tähän astisessa “korjauslistassa” jonka teollisuus on esitelly käsittäneet ID avaruuteen liittyviä fiksauksia?

Minusta myös tuo 4. kohta ei sovi kuin niiltä osilta missä overlappiä osmissa jo olleeseen aineistoon ei ole. Overlapit tulisi käsitellä pienemmissä palasissa jotka ovat oikeasti varmennettavia helpohkosti (ei siis sellasisessa massiivisessa changesetissä).

Minusta seuraavan tuontiyrityksen perusedellytykset ovat minimissään nämä:

  1. Import kuvaus löytyy wikistä, siitä on keskusteltu ja import toteutetaan kunnioittaen yhteisöä vaikka se vaatisi importaajalta enemmän työtä (ja sitä se todella vaatii, eikä varmasti kaikilla työkaluilla edes onnistukaan järkevästi)
  2. Lisenssiasiat ovat oikeasti järjestyksessä
  3. Jos jotain olemassaolevaa poistetaan, se tehdään ihmisharkinnan jälkeen (esim. ne unclassified+landsat tiet ovat luultavasti roskaa mutta tätä ei ole taidettu silti oikeasti varmentaa vaikkapa ilmakuvista tms vaan on vaan oletettu että ne on kökköä).

Jättäisin itse yhdistelyn II-vaiheeseen, eli sitten kun selvät puutteet esim. tiestöstä on importattu harkitusti, pelkkä “rajapinta” mml:n ja osm:n välillä tarvitsee sitten katsoa käsin/varovaisemmin ja nuo olemassaolevat tiet käydä vaikkapa sillä conflation työkalulla läpi myös semi-käsityönä. Sillä tavoin päästäisiin hyvin “vauhtiin” ilman suuria riskejä ja ehkä vältettäisiin tapauksia joissa joku muu kokee välttämätöntä tarvetta importata lähes valkoiselle alueelle mml:ää poistaen harvassa olevat aiemmat data, koska valkoiset alueet on jo käsitelty/täytetty I-vaiheessa.


i.

Minä olen kokoajan tässä toivonut että teollisuus ymmärtäisi itse hoitaa revertoinnit mutta alkaapi näyttämään siltä ettei kaverilla ole aikomusta perääntyä.


i.

Katos vaan, ei välttämättä olekaan maailman yksinkertaisin juttu tuo revertti ku tuolla on tollanen 50k noden monsteri changesettikin joukossa, API antaa niistä avuliaasti out-of-memoryä. Pitänee kaivaa se changeset minutelyistä sitten näemmä.


i.

Minä en ole importtien ystävä ollenkaan, mutta kyllä minun mielestäni on silti parempi, että Kemijärven importti on tehty kuin jos sitä ei olisi tehty. Keskustelua syntyi ja ongelmia löytyi, eikä maailma vielä ole tuohon kokeiluun kaatunut.

Latuviitan Latuviitan WFS-palvelussa MML mainitaan lähteenä ainoastaan palvelun metadatassa, jonka saa pyynnöllä

http://188.64.1.61/cgi-bin/tinyows?service=WFS&version=1.0.0&request=GetCapabilities

Vastauksen XML:n seassa lukee

WFS-palvelusta tosin saa dataa ulos ilman, että koskaan käy lukemassa moisia metadatoja

http://188.64.1.61/cgi-bin/tinyows?service=WFS&version=1.1.0&request=GetFeature&typeName=lv:mml_paikannimet20&maxFeatures=20

MML:n mielestä lähteen ilmoittaminen palvelun GetCapabilities-metadatassa on välineelle eli WFS-palvelulle ominainen tapa ja se tyydyttää heitä, kuten minuakin (tämä kerrottiin sähköpostissa, jonka olen hävittänyt, mutta se ei tullut lakimiehiltä eikä ylijohtajalta, joten se ei täyttäisi OSM-virallisuusvaatimuksia, vaikka olisikin tallessa).

Kemijärven koepalassa joka kohteelle on annettu “source” ja “mml:class” joten lähdeviittaukset ovat vahvemmat kuin latuviitan WFS:ssä, joten kyllä ne riittävät MML:lle, ja vielä varmemmin sitten kun OSM-wikissä on maininta tuosta tietolähteestä. Lisenssin takia tuonnin peruminen on ylimitoitettu reaktio. Jos tuonti kuitenkin perutaan, niin otetaan sekin sitten harjoittelun kannalta ja opiksi tulevaisuutta varten, niin että jatkossa tietoja osataan sekä tuoda että tunteja perua tehokkaalla tavalla.

Valitettavasti se vaan taitaa olla niin että isot määrät dataa on liian helppoa importata suhteessa siihen työmäärään mitä niiden revertoiminen vaatii. On aivan selvää että tuo importti pitää kokonaisuudessaan perua ja toteuttaa kunnolla. Valitettavasti en ole kovin vakuuttunut kyllä siitä että vastaisuudessakaan tulos tulee olemaan kovin hyvä jos tuon kaverin asenne muiden keräämää dataa kohtaan ei muutu. Ja siksi osmissa on ne import säännötkin ja myös mml:n datojen kohdallakin on toimintatavoista puhuttu “yhteisössä” aivan selvästi ettei dataa vaan lähdetä poistelemaan kuten tuossa tapauksessa on tehty. Miksi tämä tuntuu niin vaikealta käsittää kun tuntuu että kovasti jossitellaan vaikka homma tehty yksinkertaisesti väärin ja vastoin toimintaperiaatteita? Siksikö että se on niin kivannäköinen katsella?!? Kyllä se tulee kivannäköiseksi myös oikein tehtynä mutta silloin myös ne mapnikissa näkymättömät tuhot jäävät aiheuttamatta. Tai se vaatii työtä? Niin se tekee juu, ja sen välttämiseksi olisi ollut ne import ohjeistukset mutta minkäs sille mahtaa jossei niistä piitata.


i.

Koeimporttauksen perusteella suurimmaksi kynnyskysymykseksi on näköjään noussut yhä enemmän vanhan ja uuden datan integrointi. Mielestäni teiden säilytyksessä/poistossa tulisi pyrkiä säilyttämään toisten tekemä työ mikäli
tiet ovat tarkkuudeltaan riittäviä. Useassa tapauksessa Landsat aineiston yhteenliittäminen MML:n aineistoon ei tullut kysymykseen, koska tiet olivat yli sata metriä väärässä paikassa ja halkoivat maastoalueita tavalla, joka ei vastannut todellisuutta(tavalla joka olisi johtanut kartankäyttäjän harhaan maastossa). MML:n aineiston tiet ovat mitattu silmälläpitäen hälytysajoneuvoliikennettä, ja niiden tarkkuus on todella hyvä(alle puoli metriä). Taas voimme ottaa kantaa siihen kuinka tarkasti haluamme OSM:n vastaavan todellisuutta? GPS laitteen kanssa mitoitetut tiet kuuluvat mielestäni riittävällä tarkkuudella tehtyihin teihin ja ne tulisi säilyttää.

Ennakkotapauksen ajatus on mielestäni hyvä, sillä saisimme tiedon kuinka kehittää attribuutiota/lisensointia eteenpäin myös itse Maanmittauslaitokselta. En näe asiaa kovin radikaalina, sillä kyseessä on lainvoimanen viranomaistaho, jolta asiaa on kysyttävä kuitenkin. Mikäli näin ei haluta kuitenkaan tehdä, voisin aloittaa revertoinnin jo tänäiltana, sillä aineistoa on tullut riittävästi importoinnin kehitysehdotuksiksi.

Et ole sisäistänyt openstreetmapin syvintä olemusta. Vähän sama kuin jos ehdottaisi Wikipedian sisällön hävittämistä ja korvaamista Encyclopedia Britannican sisällöllä.

.

PS:

+1.

Uskon toki, että tie joka on landsatistä piirretty voi hyvinkin olla 50-100m sivussa tai koko tietä ei edes ole vaan tilalla on joku oja tai mikä lie metsään leikattu aukko tai jotain. Mutta tarkastiko asiaa sen enempää esim. objektien historiasta (kaikkien poistettujen)? Se että arvataan että niin on ei ole tyydyttävä toimintatapa. Joku niistä saattaisi olla jälkeenpäin myös gps:llä kartoitettu.

Itse olen sitä mieltä että pääosa mml:n geometrioista on parempaa laatua kuin gps pohjaisetkin tiet, mutta asia kannattaa aina tarkistaa ilmakuvaa apuna käyttäen ennen päätöksen tekemistä (jotain tarkkuusanalyysiäkin voisi virittää mml vs osm way virheestä jos saisi noita jotenkin järkevästi yhdistettyä kannassa toisiinsa ja todeta että osmissa on kökköä koko tie “algoritmi suosittelee tämän tien geometria korvausta - yes no?” tms, joku sellanen hyppää seuraavaan kohtaan plugini josmille ilmeisesti olisi jota voisi ehkä hyödyntää nopetuttamaan tuollaista editointia). Hyvin kohdilleen prosessoiduista ilmakuvasta pystyy yleensä piirtämään mml:n tasoisesti ja jopa paremmin, koska mml:llä olen havainnut ainakin jonkun verran oikomista jotka ovat ilmakuvaan verrattaessa ilmeisiä tarkkuusvirheitä.

Alle puolta metriä en usko, eikä usko mml:kään itse vaan ilmoittaa tarkkuudeksi huomattavasti suurempiakin numeroita (toki osa teistä on <0.5m tasoa toki, kadut luultavasti ovat aina ns. riittävän tarkkoja mutta jo vierellä kulkevissa pyöräteissä on oikomista näkynyt). Siitä huolimatta ne ovat silti niin hyvin kohdillaan että selvää on että pääosa osmin geometrioista kannattaa korvata mml:n geometrioilla. Mutta osmissa on muutakin kuin geometrioita, ja se muu tieto+sen tiedon historia tulisi säilyttää. Eli way säilytetään mutta sen nodet korvautuvat käytännössä mml:stä kaivetuilla vastineilla. En tiedä kuinka hyvin nuo conflation työkalut osaavat tuon säilytyksen tehdä, asia tulisi selvittää (muutoin kuin suurilla testeillä, mielellään pelkälle .osm tasolle jääviä kokeita). Tai jos tyydyttäviä työkaluja ei löydy niin täytyy itse tehdä operaatiot kannassa.

Mitä revertiin tulee katsoin asiaa tuossa itse ja totesin että se ei välttämättä ole myöskään aivan triviaali operaatio, arvostan kuitenkin sitä että olet siihenkin nyt valmis :slight_smile: (näyit itseasiassa jo aloittaneenkin).

Tärkeä juttu muuten changesettien koosta: älkää laittako 50k objektia samaan changesettiin, API ei pysty palauttamaan sitä vaan muisti loppuu jossain kohtaa ja tulee vaan virhettä (siksi yhden noista changeseteistä .osc tiedoston downaaminen ei onnistu lainkaan, tuo .osc ongelma saattaa tuottaa harmaita hiuksia revert työkaluillekin). Importtien tiukat vastustajat itseasiassa haluaisivat limitin jonnekin 10k-5k luokkaan joka ehkä olisi järkevän oloinen arvo jota ei kannata yhdessä changesetissä ylittää.


i.

Tätä mieltä olen minäkin. Tietääkö kukaan, antaako MML aineistossaan arvioita kohteen geometrian tarkkuudesta? Jos antaa, sitä voisi hyödyntää. Joka tapauksessa jonkinlainen geometrian vertailu MML<->OSM pitäisi aina MML kohdetta vietäessä. Jos sillä kohdalla ei ole mitään vastaavaa geometriaa (jollain puskurilla tarkistettuna), MML-kohteen voinee viedä huoletta. Jos kohdalla on vastaava geometria ja voidaan jollain syyllä olettaa, että MML geometria on tarkempi, viedään geometria ja yhdistetään jollain nerokkaalla algoritmilla MML ja olemassaolevan koheen ominaisuustiedot.

Kuulostaa yksinkertaiselta ja sitä se ei varmasti ole. Lisäksi pitää harkita seuraavia operaatioita viennin ohessa:

  • MML aineiston yksinkertaistaminen ja yleistäminen (OSM on tiekartta ja sen tarkkuus ainakin harvemmin asutuilla alueilla voi varmaankikn olla MML tarkkuutta huonompi, tai siis yleistetympi)
  • Relaatioiden automaatinen muodostaminen (en osaa antaa esimerkkejä, en ole asiantuntija relaatioden suhteen)

Minusta kannattaisi viedä aineistoa sekä alue että karttataso kerrallaan, aloittaen kenties joistain “helpoista” kohteista tai sellaisista, joita on vähän OSM:ssa tällä hetkellä. Yksi mieleentuleva helpoista kohteista saattaisi olla rakennukset.

Lisäksi voisi harkita jonkinlaista OSM-aineiston “suojaamista” siten, että joitain alueita rajattaisiin MML-aineiston tuonnilta kokonaan pois.

Revertti on tosiaankin käynnissä(saadaan sitten tästäkin vaiheesta dokumentaatiota). Käytännössä palautus tapahtuu käyttämällä JOSMin Reverter-pluginia, jolla muutoskokoelmat voidaan kumota yksi kerrallaan. Skelan ohjeiden mukaisesti Kemijärvi ympäristöineen löytyy tältä koneelta tallesta kaikessa maastotietokantaloistossaan mikäli se myöhemmin halutaan takaisin. Toivon saavani alueen ennalleen viimeistään huomenna. Jätän ensimmäisen tuomani mökin kuitenkin ennalleen siltä varalta että sitä voidaan käyttää MML:n mielipiteen kysymiseen.

MML:llä on se joku tarkkuusluku, en nyt muista avaimen nimeä mutta se on suht oikean suuntainen TAR jotainkin taisi olla ihan nimessäkin. Erittäin vähän olen niihin perehtynyt mutta vaikutelmani oli se että tiet olivat pääsääntöisesti <10m tarkkuusluvulla, paljolti muistaakseni 3m ja 5m annettu vaikka käytännössä ne ovat kyllä paremmin. Jotain peakkeja mitä katsoin joskus aiemmin oli sitten suuremmillakin luvuilla, 30m ja 50m ainakin taisi olla (eivät ehkä kaikille vähemmän merkitseville huipuille ole kiivenneet niin tarkkaan mittaamaan, tosin luulisi LAS aineistosta saavan aika hyvin <30m tarkkuuksiakin :-)).

Nämä sinun puskuriajatukset ovat varsin lähellä sitä mitä olen jo hiukan kehitellytkin. Laskin jo Suomen laajuisesti 30-50m bufferilla täysin overlappaamattomia teitä olevan 46%-60% mml:n pätkityistä teistä (en nyt enää muista tarkkoja arvoja). Ajattelin että niitä voisi ruutu kerrallaan alkaa importtaamaan kuhan lisenssiasiat ovat selviä. Myös vesistä laskin jotain arvoja ja ne olivat samansuuntaisia (tosin tarkastelin vain yhdessä ruudussa kokonaan sijaitsevia kohteita, joten numero vois olla vielä isompikin). Samanlaisia juttuja kannattaa virittää toki taloillekin. Käytännössä tuota varten tarvitsee kannan jossa on suomen .osm ja mml:n tavarat sisällä. Itselläni on osm2pgsql:llä importattuna nyt myös versiot ja userid:t mukana niin pystyy miettimään olemassaoleviin juttuihin yhdistelyäkin kun pystyy generoimaan oikein versioidut .osm:t yhtymäkohtiin (pitäisi vielä importata uusiksi hstoren kanssa kaikki avaimet niin voisi toistaa keyval datatkin täydellisesti niille olemassaoleville objekteille kun niihin tarvitsee joku jännä yhdistysoperaatio suorittaa, vaikkapa vieresten ruutujen saman tagisten teiden yhdistys yhdeksi wayksi (kun se toinen ruutu tuli jo aiemmin upittua)).

Tuota tarkkuuslukua ajattelin koittaa myös sillä lailla että luon sen kokoisen puskurin ja vertaan onko osm way sillä kohtaa kauniisti jolloin voidaan siirtää geometrian korvausta hamaan tulevaisuuteen jos sitä ikinä tarvitsee edes tehdä, mutta en ole vielä koittanut mitään toteuttaa. Nimi ja ref pohjaista vastinpari etsintää/tietojen täydennystä en ole vielä lähtenyt säätelemään. Tähän liittyä haaste on vakio-offsetit, esim. porvoossa oli pitkään suuri alue tasan korttelin verran sivussa joten algoritmit helposti erehtyisivät kuvittelemaan että kuljetaan vieresellä kadulla jos nimiä yms. tietoja tai topologiaa ei tarpeeksi syvälle lähdetä analysoimaan (siksi ne oikeat conflation algorithmit olisivat ehkä turvallisempia kun ne ilmeisesti ovat enemmän topologia kuin sijainti perustaisia matchejä tuottavia).

En ymmärtänyt mitä ajoit takaa tällä kommentilla? Minkä tyyppisistä relaatioista oli tässä puhe?

Kannatan ajatustasi työn jakamista objektityyppeihin: rakennukset, tiet, meren saariston rantaviivat, vedet (järvet ja joet varmaan samalla), sähkölinjat. Käytännössä nuohan ovat varsin hyvin toisistaan riippumattomia. Tosin rantaviivoihin ja vesiin saattaa liittyä joitain muita maastokohteita kiinni (tietääkö teollisuus tai joku muu miten ne käytännössä menee?), joka tarvitsee sitten myöhemmässä vaiheessa kaivaa osmista yhteenliittämistä varten. Sähkölinjoja on varsin paljon jo piirrettynäkin, vaihtelevalla tarkkuudella joten se voi olla kaikkein haasteellisin noista koska osa on osmissa jo paremmin tai ainakin riittävän hyvin (mml:n tarkkuudesta ei minulla ole käsitystä niiden osalta). Myös huippuja joku voisi koittaa katsoa, minä en ainakaan heti keksinyt miten niiden nimet liitetään itse kohteisiin (en itseasiassa tainnut edes löytää vielä niitä nimiä).

Rautatiet on pääosin jo osmiin piirretty vaikkakin sijaintitarkkuus voi olla mml:llä parempi moninpaikoin. Risteämiset ovat haasteellisempia hoitaa nätistä tiestön kanssa, erityisesti jos molempia käsitellään samaan aikaan, joten jättäisin ratojen säätelyt myöhemmäksi.


i.