Saimme Gispolla hiljattain olla mukana kehittämässä todella mahtavaa QGIS-lisäosaa Unfoldedin visualisointialustalle. Työkalu mahdollistaa entistä helpommin interaktiivisten karttojen tuottamisen ja jakamisen osana QGIS-työnkulkua.
Unfolded on amerikkalainen paikkatietoalan start-up jonka perustajat ovat lähtöisin Uberilta. Unfoldedin toimintamalli on ns. Open core, jonka myötä he ovat vahvasti mukana erityisesti niiden avoimen lähdekoodin projektien kehityksessä, jotka tukevat heidän omaa tuotekehitystään. Tällaisia ovat esimerkiksi kepler.gl, H3 ja deck.gl, joiden kaikkien pääkehittäjät ovat Unfoldedilla töissä.
Unfolded tarjoaa Unfolded Studio-nimistä visualisointialustaansa palveluna. Kuka tahansa voi tehdä sinne ilmaisen tilin. Tiliin sisältyy peräti gigan verran ilmaista tilaa kartoille ja datoille. Unfolded Studion keskeinen ajatus on datan käsittelyn helppous ja visualisointien näyttävyys. He halusivat tehdä datan julkaisusta Unfolded Studioon entistä helpompaa. Tämän vuoksi kehitimme heille lisäosan, jonka avulla QGIS-käyttäjät voivat julkaista omat paikkatietoaineistonsa ja projektinsa Unfolded Studioon.
Lisäosan käyttö kulkee pähkinänkuoressa seuraavasti.
- Lisäosa asennetaan QGISin lisäosavalikosta
- QGIS-projektiin lisätään vektoriaineistoja ja tyylitellään ne
- Unfolded-niminen lisäosa löytyy omasta ikonistaan tai web-valikon alta
- Määritellään lisäosan valikossa interaktiivisen kartan visualisointityylit ja muokataan esimerkiksi otsikot ja kuvaustekstit kuntoon
- Klikkaamalla Export map lisäosa tallentaa valitut datat ja tyylit yhdeksi ZIP-paketiksi käyttäjän omalle koneelle
- Viedään ZIP-paketti omalle Unfolded Studio-tilille import map valikon kautta
- Tehdään mahdolliset lisäviilaukset Unfolded Studion puolella ja kartta voidaan julkaista kaikkein nähtäville yhdellä klikkauksella!

Tällä hetkellä lisäosa tukee perustason tyylejä (täyttövärit, reunat, luokittelut) vektoriaineistoille. Aineisto voi olla missä tahansa koordinaattijärjestelmässä ja missä tahansa QGISin tukemassa vektoriformaatissa. Normaalisti Unfolded Studioon vietävä paikkatietoaineisto on pitänyt olla WGS84-koordinaattijärjestelmässä ja tuetut vektoriformaatit ovat olleet rajallisia. Kehittämämme työkalu helpottaa tätä huomattavasti ja mahdollistaa Unfolded Studioon vietävän datan monipuolisen esikäsittelyn, suodatuksen sekä analyysin kaikilla QGISin monipuolisilla menetelmillä.
Osana projektia tuotimme muutaman esimerkkivisualisoinnin lisäosan mahdollisuuksista. Tässä alla Helsingin seudun rakennukset väritettynä rakennusvuoden mukaan. Väripaletti on QGISin oma.
Lisäosa on kaikkein ladattavissa QGISin virallisesta repositoriosta, eli se löytyy QGISin lisäosavalikosta. Lisäosan lähdekoodi on julkaistu GitHubissa. Voit lukea lisää työkalun käytöstä ja sen mahdollisuuksista Unfoldedin omille sivuille englanniksi kirjoittamastamme blogikirjoituksesta.
Pienimmän kustannuksen polun määrittäminen perustuu kustannusetäisyystietoa tuottaviin paikkatietoanalyyseihin. Tämä kaksiosainen blogisarja tarkastelee tätä paikkatietoanalyysiä avoimen lähdekoodin työkalujen näkökulmasta, Tässä blogisarjan ensimmäisessä osassa syvennytään hieman aiheen teoriaan ja seuraavassa tarkastellaan ongelmaa ratkovia työkaluja.

Kustannusetäisyysanalyyseja voidaan soveltaa kaikkiin sellaisiin tilanteisiin, joissa etsittävä reitti on vapaasti muotoiltavissa (ei ole olemassa mitään listaa kohteista, joiden kautta tuloksena saatavan polun tulee välttämättä kulkea). Käytännön esimerkkejä pienimmän kustannuksen polun sovelluskohteista ovat niin maastossa tapahtuvan kulkureitin optimointi, maastoon rakennettavan polkumaisen infrastruktuurin (teiden / voimalinjojen) verkostosuunnittelu kuin eläinten liikkeidenkin mallintaminen. Esimerkiksi kuitukaapelien reititys on yksi käytännön esimerkeistä jossa analyysiä voidaan hyödyntää. Tyypillisesti rasterianalyysi astuu kuvioihin silloin, kun vektorireititykseen tarvittavan topologian muodostaminen osoittautuu liian monimutkaiseksi. Kaikkein yksinkertaisin esimerkki minimikustannuspolkuongelmasta on lyhimmän polun etsiminen pisteestä A pisteeseen B.
Usein kustannuksella viitataan kuitenkin pelkkää etäisyyttä monimutkaisempiin asiakokonaisuuksiin. Sen lisäksi, mikä etäisyys tiettyyn sijaintiin kertyy polun lähtöpisteestä, tiettyyn lokaatioon liitettävään kustannukseen saattaa vaikuttaa myös se, miten paljon rahaa / aikaa / vaivaa ko. lokaatioon pääsemiseen kuluu tai miten paljon negatiivisia ympäristövaikutuksia matkan kulkemisesta kertyy. Esimerkiksi jyrkän mäen kiertävä pyöräilyreitti saattaa kustannuksilla mitattuna osoittautua mäen suoraan ylittävää pyöräreittiä optimaalisemmaksi vaihtoehdoksi.
Minimaalisen kustannuksen tuottavaa polkua ei voida tuottaa ilman tietoa polun ääripisteistä ja siitä, miten kustannus kehittyy liikuttaessa kuhunkin suuntaan. Tämän vuoksi kustannusetäisyysanalyyseissa maailma kuvataan tyypillisesti jatkuvana rasterimuotoisena kustannuspintana, jossa jokaiseen rasterisoluun liittyy positiivinen kustannus. Välitön seuraus tästä on se, että jokainen tämän rasteriavaruuden läpi kulkeva polku kerryttää kustannuksia.
Tässä blogissa tulemme tutustumaan niin vähemmän kuin enemmän tehokkaisiin minimikustannuspolun löytämiseen kehitettyihin avoimen lähdekoodin kustannuspolkualgoritmeihin sekä siihen, millaista aineistoa ne tarvitsevat toimiakseen.
Rakennuspalikat ongelman ratkomiseksi
Optimaalisen minimikustannuspolun tuottaminen koostuu tyypillisesti kolmesta vaiheesta:
1. Kustannuspinnan luominen
- Kustannuspinnan muodostaminen konseptualisoi tutkittavan avaruuden kentäksi
- Kustannuksella viitataan tarkasteltavaan ilmiöön vaikuttavien tekijöiden yhteisvaikutukseen (mittarina käytettävään suureeseen ei yleensä voida liittää mitään järkeenkäypää yksikköä), jonka suuruus voidaan mitata missä tahansa sijainnissa
- Rasteriruudukko luonnissa hyödynnetään usein indeksimalleja ja kartta-algebraa
- Lopputuloksena syntyy kustannustiedon sisältävä rasterimuotoinen ruudukko, jonka jokainen ruutu saa kyseisen ruudun sisällä liikkumisesta aiheutuvaa kustannusta vastaavan arvon


2. Kustannusetäisyystiedon tuottaminen
- Tarvitaan: edellisessä vaiheessa luotu kustannuspinta ja tieto aloituspisteestä
- Kustannusetäisyys kuuluu vaihtoehtoisten etäisyysmetriikoiden perheeseen, sillä sen määrittämisessä hyödynnetään maantieteellistä etäisyyden kitkan -periaatetta, jonka mukaan yksikköliikkeen toteuttamiseen liittyy aina tietty sijainnin mukaan vaihtuvan suuruinen kustannus
- Kustannusetäisyysanalyysissa arvioidaan jatkuvassa avaruudessa tapahtuvan liikkeen kustannusta (muuttujaksi voidaan ajatella kulkeminen tietyn sijainnin kautta)
- Toisilla poluilla on toisia korkeampi kustannus ja pienempään kustannukseen liittyvää reittiä voidaan aina pitää suuremman kustannuksen tuottavaa polkua parempana valintana
- Kahden pisteen välinen etäisyys tiettyä polkua pitkin on kerrytetty summa kaikista polun varrelle osuvien pisteiden kustannuksista
- Tarkoituksena on etsiä pienin painotettu summa kustannuksia, jonka kautta voidaan matkustaa kuhunkin ruutuun aloitusruudusta (etäisyyttä mitataan maantieteellisten yksiköiden sijaan kustannusyksiköissä)
- Lopputuloksena syntyy kustannusetäisyystiedon sisältävä rasterimuotoinen ruudukko, jonka jokainen ruutu sisältää kyseiseen lokaatioon pääsemiseksi kertyvän kustannuksen
- Käytännössä tämä arvo saadaan selville erkanemalla säteittäin lähtöpisteestä ja tunnistamalla pienimmän kerrytetyn kustannuksen omaavan naapuriruudun ja lisäämällä sen kerrytetty kustannus tarkasteltavan ruudun kustannukseen (diagonaalisten pienimmän kustannuksen naapuriruutujen tapauksessa käytetään kertoimena kakkosen neliöjuurta)

- Kerrytetyn kustannusetäisyysruudukon lisäksi tuotetaan myös toinen, erillinen ruudukko (backlink rasteritiedosto), johon talletetaan tieto suunnasta, mistä löytyy kunkin ruudun pienimmän kerrytetyn kustannuksen omaava naapuriruutu
- Toisin sanoen tallennetaan tieto siitä, mistä suunnasta pienimmän kustannuksen polku tulee kuhunkin ruutuun

3. Pienimmän kustannuksen tuottavan polun löytäminen
- Tarvitaan: edellisessä vaiheessa luotu backlink rasteri ja tieto polun päätepisteistä
- Toimintaperiaate: algoritmi tunnistaa päätepisteeseen liittyvän backlink rasterin ruudun ja jäljittää polun päätepisteestä takaisin aloituspisteeseen liikkumalla kustakin ruudusta, johon ollaan saavuttu peruutuksen seurauksena, aina pienimmän kerrytetyn kustannuksen omaavaan naapuriruutuun
- Jokaista läpi peruutettua ruutua vastaava kustannus saadaan selville vaiheessa 2 muodostetusta kerrytetyn kustannusetäisyyden ruudukosta (näistä tiedoista lasketaan optimaalisen polun kokonaiskustannus)

Seuraavassa blogisarjan osassa päästään itse asiaan – eli syventymään erilaisiin keinoihin määrittää minimikustannuspolku!
QGISin attribuuttilomakkeiden muotoilutoiminto helpottaa arkista paikkatietotyöskentelyä huomattavasti. QGISin työtilan tasojen ominaisuustietolomaketta voi nimittäin kustomoida omiin tarkoituksiin todella helposti. Muille voit kehua koodanneesi QGISiin uuden lisäosan, jolla tietoja jatkossa hallitaan.
Lomakenäkymä voi olla perinteistä taulukkonäkymää mukavampi käyttää esimerkiksi kohteita digitoitaessa tai jos halutaan saada aineistosta näkyviin vain tiettyjä asioita. Myös kalenterinäkymä päivämäärätyyppisissä kentissä tai kuvamuotoisen linkin esittäminen lomakkeella voi olla kätevää.
Valitse ensin vektoriaineisto, jolle haluat tehdä lomakkeen. Huomaathan, että tekemäsi muutokset tallentuvat vain QGIS-projektiin eli muista tallentaa projekti aina lomakkeen muokkauksen jälkeen.
Klikkaamalla auki tason Ominaisuudet / Layer Properties -näkymän ja sieltä Attribuuttilomake, pääset muokkaamaan attribuuttitaulujen esitystapaa.

Automaattisessa näkymässä lomake näyttää kaikki kentät, joita aineisto sisältää sellaisenaan. Klikkaamalla auki ylävalikosta “Automaattinen” sijaan “Drag and Drop Designer”-näkymän, jolloin voit tehdä mm. seuraavaa:
- Klikata pois näkyvistä ne kentät, joita et tarvitse (esim. Fid-kenttä, joka generoituu automaattisesti)
- Voit antaa sarakkeille aliasnimen, joka kuvaa kenttää paremmin
- Widgetin avulla voidaan myös antaa saraketyypille lisäominaisuuksia, kuten alasvetovalikon, josta käyttäjä saa valita vain tiettyjä arvoja (arvoluettelo).
- Tai voit luoda lomakkeelle välilehtiä tai järjestellä kenttiä haluamallasi tavalla
Tässä esimerkissä “korkeus”-kenttään luodaan arvolista, jossa voi antaa vain 5 m välein arvoja. Arvoluettelon voi tuoda myös toisesta aineistosta tai csv-tiedostosta, jos halutaan käyttää olemassaolevaa koodilistaa.

Kun jatkossa luot kohteita tai klikkaat ne auki info-näppäimellä, avautuu muotoiltu lomake näkyviin. Lomake näyttää siis vain valitut kentät ja niiden aliasnimet, sekä helpottaa tietojen syöttöä esimerkiksi alasvetovalikkojen avulla.

Päivämäärämuotoinen (date)-kenttä näyttäytyy myös heti kalenterimerkintänä.

Jos haluat viedä lomakenäkymiä askeleen pidemmälle, voidaan ottaa käyttöön myös välilehdet tai palstajako, joiden avulla voidaan iso määrä attribuutteja esittää ryhminä.

Kuvan kaltaisen toteutuksen saa tehtyä attribuuttilomakkeen drag & drop-asettelusta luomalla Taitto-näkymään yläotsikoita tab-muotoisena (välilehti) tai ryhmitellä attribuuttien kenttiä allekkain (ryhmä säiliössä). Myös palstoitukseen voi vaikuttaa lisäämällä sarakkeiden lukumäärää.

PostGIS-tietokanta ja sen relaatiomahdollisuudet tuovat vielä yhden lisäherkun QGISin lomakkeisiin. Tässä esimerkissä on taustalla PostGIS-tietokanta, jossa paikkatietokohteeseen liittyy tekstimuotoisesta taulukosta tietoja. Lomakenäkymää muokkaamalla saa ensinnäkin raahattua lomakkeelle oikean relaation ja sen jälkeen voidaan määrittää saako käyttäjä lisätä lomakenäkymän kautta uusia rivejä kyseiseen taulukkoon vai ei. Relaatioita voi toki hyödyntää ilman PostGISiäkin, esim. GeoPackagen avulla. Relaatioiden tuottamisesta olemme kirjoittaneet aiemmin.

Eli sitten vaan lomakkeet kuntoon ja tehokkuutta tietojen tuottamiseen!
Lisäluettavaa tästä löytyy mm. QGISin ohjesivuilla sekä koulutamme myös aiheeseen.

Pääsin mukaan mentoriksi Planin ja Future Femalen järjestämään nuorten teknologiavaikuttajien kampanjaan, jossa yhdessä Tieken toiminnanjohtajan Hanna Niemi-Hugaertsin kanssa koitamme parhaamme mukaan antaa työelämän vinkkejä ihanalle nuorten ryhmälle.
Hannan kanssa yhteinen taival alkoi vuonna 2015, kun teimme töitä 6Aika avoin data -kärkihankkeessa ja pohdimme yhdessä miten ja mitä dataa kaupungeissa avataan. Siksi ryhmämme aiheena on kaupunkidata – joka yhdistää paikkatiedot, avoimen datan, my datan ja IoT-asiat käteväksi paketiksi. Nuorten kanssa pohdimme siis yhdessä mitä voisimme tehdä, jotta kaupungeista ei tulisi ihan älyttömiä ja miten he voivat jo nyt teoillaan vaikuttaa tasa-arvokysymyksiin ja samalla tulevaisuuden teknologioiden kehittämiseen. Kevään aikana ryhmä tuottaa jonkin vaikuttamistoimenpiteen ja jännityksellä odotan mitä saamme aikaan!
Lauantaina oli kickoff Planin ja Future Femalen kanssa ja tutustuimme mm. juuri tasa-arvoasioihin ja itse vähän jopa järkytyin siitä, että Suomessa on esimerkiksi edelleen IT-alan työntekijöistä 80 % miehiä. Ja vielä kamalampaa oli kuulla, että 45 % tytöistä kokee nettihäirintää eli melkein joka toinen kadulla kävelevä nainen on kokenut verkkohäirintää! Tällaiset asiat kuuluvatkin niihin älyttömiin kaupunkeihin, joissa kukaan meistä ei halua elää.
Paikkatietoalalla tasa-arvoasiat ovat suht hyvällä mallilla, mutta huomaan kyllä esimerkiksi rekrytointitilanteissa, että teknisemmin orientoituneita hakijoista on järjestäen pääosa miehiä. Esimerkiksi FOSS4G 2019 tapahtumassa Bukarestissa oli hienosti järjestetty tytöille oma sosiaalinen tapahtuma, joka joillekin oli ainoa tilaisuus päästä minglailemaan ja juttelemaan alan kehityksestä, sillä muuten he eivät kulttuurisista tai uskonnollisista syistä voineet osallistua tapahtumiin. Se oli itselle heräte siihen, että vielä on paljon tehtävää. Me suomalaiset paikkatietomuijat voidaan osaltaan myös näyttää mallia niin kotona kuin maailmalla.
Meillä Gispolla toivon, että tasa-arvosasiat näkyisivät kaikessa tekemisessä – meitä on melkein fifty-fifty naisia ja miehiä – tosin jokainen rekrytointi kallistaa aina kuppia puoleen ja toiseen. Mutta täysin tasa-arvoiseksi ja heterogeeniseksi sakiksi en voi meitä vielä hyvällä omatunnolla kutsua. Me kaikki olemme tällä hetkellä korkeakoulutettuja valkoisia 25-50-vuotiaita kantasuomalaisia. Se miksi meillä ei ole esimerkiksi muita kuin suomea pääkielenään puhuvia, johtuu pitkälti asiakaskeisseistä ja aineistoista, joita käytämme. Asian ei toki tarvitsisi olla näin.
Naistenpäivän kunniaksi toivotankin kaikille tasa-arvoista kevättä – otetaan toisemme huomioon, mietitään asioita myös sen toisen kantilta ja pohditaan miten voidaan ottaa myös teknologiassa tasa-arvoasiat huomioon ja vaikuttaa siihen, että asiat paranevat. Niin aion itse tehdä myös ja tämän kevään mentorointitehtävä on mahtava tilaisuus tehdä jotain konkreettista. Kiitos siitä Hanna ja Planin ja Future Femalen posse!
Parhaimmassa tapauksessa reittioptimoinnilla kyetään vastaamaan jokaiseen otsikossa esitetyistä kysymyksistä. Tässä blogissa pääset tutustumaan niin reittioptimoinnin, mallinnuksen, graafien, QGISin, PostGISin, CPLEXin kuin yleisen (ohjelmointi)logiikankin maailmoihin – lukuiloa!

Johdanto
Matemaattista optimointia voi osuvimmin kuvata parhaan ratkaisun etsimiseksi olemassaolevien vaihtoehtojen joukosta. Tyypillisesti etsitään sellaista ratkaisua, joka minimoi / maksimoi kohdefunktioksi kutsuttavan, vaihtoehtojen paremmuutta vertaavan kriteerin arvon. Optimoitavaa suuretta kutsutaan päätösmuuttujaksi. Päätösmuuttujien arvoja muuttamalla pyritään saavuttamaan mahdollisimman hyvin asetetun optimointiongelman tavoitteet. Optimointiongelman tavoitetta kutsutaan kohdefunktioksi. Kohdefunktiot koostuvat päätösmuuttujista, parametreista, vakioista sekä niiden välisistä relaatioista. Parametrien voidaan ajatella kuvaavan kyseessä olevan systeemin ominaisuuksia. Vakiot puolestaan voidaan nähdä parametreja muuttumattomampina, universaaleina ominaisuuksina.
Optimointimallia muodostettaessa tulee ottaa kohdefunktion lisäksi huomioon myös päätöksiä rajoittavat ehdot. Tällaisia ehtoja kutsutaan rajoitteiksi. Usein malleihin liittyy luonnollisia rajarajoitteita, jotka aiheutuvat päätösmuuttujalla kuvattavan suureen ominaisuuksista. Jos esimerkiksi yritetään minimoida aikaa, joka romaanin kirjoittamiseen tulee kulumaan, päivässä käytettävien työtuntien määrää kuvaavalle päätösmuuttujalle x täytyy asettaa alaraja x ≥ 0. Vuorokaudessa ei nimittäin ole mahdollista työskennellä negatiivista määrää tunteja. Rajoitefunktioiden avulla voidaan kuvata monimutkaisempia rajoitteita. Esimerkkinä tällaisesta voisi toimia vaikkapa rajoite, joka vaatii, että jokaista vuorokaudessa työskenneltävää kolmea tuntia kohti täytyy pitää yksi kahvitunti, nukkumiseen täytyy varata ainakin kuusi tuntia, ja näiden kolmen päätösmuuttujan summa ei saa ylittää 24 tuntia. Kahvitunnin pitämisestä ja nukkumisesta saatava hyöty voidaan kuvata kohdefunktiossa päätösmuuttujien välisenä relaationa. Kyseiseen relaatioon voi liittyä sekä parametrejä että vakioita, joiden avulla pystytään kuvaamaan monimutkaisempia vuorovaikutussuhteita.
Merkitään symbolilla N optimointimalliin liittyvien päätösmuuttujien lukumäärää. Mikäli päätösmuuttujien arvoista koostuva N-ulotteinen vektori toteuttaa kaikki optimointimallin rajoitteet, ollaan löydetty sallittu ratkaisu. Minimointi-tyyppisen optimointiongelman optimaaliseksi ratkaisuksi kutsutaan sellaista sallittua pistettä, jossa kohdefunktio saa pienimmän arvonsa.
Reittioptimointi on eräs optimoinnin alakategorioista. Reittioptimointi voidaan nähdä tieteenalana, jonka tavoitteena on löytää systemaattisia tapoja tunnistaa nopein / kustannustehokkain tapa järjestää jonkin resurssin kuljetus. Reittioptimoinnin keinoin voidaan reititysratkaisujen etsimisen lisäksi pyrkiä vastaamaan myös laajempiin yritysmaailman tavoitteisiin (esim. parantamaan asiakastyytyväisyyttä, vähentämään toiminnan kustannuksia tai optimoimaan työsuunnittelua). Yksi perinteisimmistä reittioptimoinnin ongelmista on Kauppamatkustajan ongelma (Travellling Salesman Problem), jossa tavoitteena on löytää pienimmän kustannuksen omaava reitti, joka kulkee usean kaupungin / kohteen kautta ja palaa takaisin lähtöpisteen [4]. Tässä blogissa tulemme kuitenkin etsimään vastausta hieman erityyppiseen reittioptimointi-ongelmaan, jota pääsimme tutkimaan yhteistyössä Tampereen Infra Oy:n kanssa.
Aurausongelman mallinnus
Toteutuneen hankkeen aikana tutkittiin monia tapoja mallintaa aura-auton ajoreitin valitsemiseen liittyvää problematiikkaa. Reittioptimointi yhdessä mielessä hyvin erityinen analysointitapa; on aivan samantekevää onko meillä käytettävissä aineistoa esimerkiksi aura-autojen liikkeistä. Sillä, miten asia on tavattu tehdä, ei ole juurikaan vaikutusta siihen, miten se oikeasti kannattaisi tehdä. Tässä työssä hyödynnettiin lähtöaineistoina ainoastaan Digiroadin tarjoamaa tieverkostodataa, tarkasteltavan alueen määrittävää aluerajausta ja tietoa kunnossapitoajoneuvojen varikon sijainnista. Haasteelliseksi optimoinnin tekee se, että tutkittava ilmiö onnistutaan mallintamaan realistisesti. Optimointi on aina tasapainoilua kehitetyn mallin validiteetin ja ratkeavuuden välillä.

Ihan ensimmäiseksi muokkasimme Digiroadin tieverkkoaineiston sellaiseen muotoon, jonka päälle pystytään rakentamaan matemaattinen ongelmanmuotoilu. Toisin sanoen loimme PostGIS:n avulla todellisesta tieverkosta topologisesti ehjän graafin. Graafi on verkosto, joka koostuu solmuista (kuvaavat tässä tapauksessa teiden risteyksiä) ja niitä yhdistävistä kaarista (vastaavat teitä). Graafit jaotellaan luokkiin niiden ominaisuuksien mukaan. Tärkeimmät graafeja määrittävät ominaisuudet liittyvät siihen, onko graafi suunnattu (jokaiseen kaareen liittyy suuntatieto → yksi lähtösolmu, yksi päätesolmu), kytketty (jokaiselle solmuparille (a,b) on olemassa yhtenäinen polku solmusta a solmuun b) tai painotettu (jokaiseen kaareen liittyy painokerroin, yksinkertaisimmillaan kaaren pituus).
Tavanomaisimmat graafiteorian mallit, kuten aiemmin mainittu kauppamatkustajaongelma, perustuvat ajatukselle, että tavoitteena on käydä jokaisessa graafin solmussa. Tämä tavoite ei kuitenkaan sovellu kunnossapidon tavoitteisiin, sillä solmuissa käymisen sijaan tavoitteena on kulkea jokainen kaari. Käsillä olevan ongelman mallintamiseen soveltui paremmin Chinese Postman Problem (CPP), jonka periaatteet voidaan tiivistää seuraavasti:
- Postimiehen tavoitteena on jakaa kaikki alueen postit kulkien mahdollisimman lyhyttä reittiä
- Kyetäkseen tekemään tämän, hänen tulee kulkea jokainen tienpätkä vähintään kertaalleen ja palata sen jälkeen lähtöpisteeseen
- Mikäli CPP saadaan ratkaistua, tuloksena saatua polkua voidaan pitää optimaalisena tapana kiertää tieverkosto (turhien ajokilometrien määrä minimoituu)
Yllä esitellyssä CPP-muotoilussa on kuitenkin yksi iso ongelma, joka asettaa koko mallin validiteetin kyseenalaiseksi: siinä kaikki tiet ymmärretään samanlaisiksi, kahta risteystä yhdistäväksi suuntaamattomaksi kaareksi. Toisin sanoen, perus-CPP:n avulla ei ole mahdollista ottaa huomioon ajosuuntaa ja sitä, että on olemassa sekä yksisuuntaisia että kaksisuuntaisia teitä. Siksipä hankkeessa kehitettiinkin muokattu versio CPP kokonaislukuoptimointiongelmasta, jonka periaatteet voidaan tiivistää seuraavasti:
- Minimoidaan kuljettavaa matkaa
- Jokaiseen tienpätkään liittyy yksi kokonaislukumuuttuja, joka kuvaa montako kertaa kyseinen tiepätkä optimaalisessa ratkaisussa kannattaisi ajaa
- Jokainen kaksisuuntainen tie tulee kulkea kuhunkin suuntaan vähintään kertaalleen
- Jokainen yksisuuntainen tie tulee kulkea sallittuun kulkusuuntaan vähintään kahdesti
- Aura-auton tulee lähteä varikolta ja optimaalisen reitin tulee päättyä varikolle
- Ratkaisuna saatavan optimaalisen polun tulee olla topologisesti ehjä (jokaisessa tieverkon risteyskohdassa tulee olla tasapainoehto voimassa)
Aurausongelman muodostus
Ongelman ratkaisuprosessi sisälsi seuraavat vaiheet:
1. Aineiston esikäsittely QGISillä
- Leikkaa Digiroad-aineistoa (DR_LINKKI_K) tutkittavan alueen määrittävällä aluerajauksella
- Muokkaa tarvittaessa aluerajauksen reunoja siten, ettei se katkaise yhtään tiesegmenttiä “keskeltä”
- Luo uusi tiesegmentti lähtöpisteestä lähimpään tiehen (jos sitä ei ole vielä olemassa)
- Tarkista, ettei leikkauksen tuloksena saatu verkosto sisällä multiedgejä (tilanne, jossa samaa pisteparia yhdistä kaksi eri tiesegmenttiä). Käytännössä tällainen tilanne voi muodostua “kaariteiden” yhteydessä
- Tarkista, ettei yksisuuntaisia teitä ole verkoston reunoilla (ulos alueelta / sisään alueelle), koska siellä ei tällöin voitaisi käydä kääntymässä → mahdotonta löytää topologisesti ehjää aurauspolkua
2. Graafin muodostaminen PostGISin pg_routing-laajennuksen avulla
- Luo PostGISiin tietokantaklusteri ja tietokanta (esim. pgAdminilla), jonne voit viedä tarkastelualueen tieverkoston
CREATE EXTENSION postgis; CREATE EXTENSION pgrouting; CREATE SCHEMA reititys;
- Vie esikäsitelty tieaineisto PostGISiin
ogr2ogr -update -append -a_srs EPSG:3067 -nlt LINESTRING -lco GEOMETRY_NAME=geom -lco FID=id -lco SCHEMA=reititys -f PostgreSQL "PG:host=port= user= dbname= password= " -nln reititys.tietPgis tietQgis.gpkg
3. Tiedon jalostaminen
ALTER TABLE reititys.tietPgis
ALTER COLUMN geom TYPE geometry(LineString,3067)
USING ST_Force2D(geom);
ALTER TABLE reititys.tietPgis
ADD COLUMN source integer;
ALTER TABLE reititys.tietPgis
ADD COLUMN target integer;
SELECT pgr_createTopology('reititys.tietPgis',0.0001,'geom','id');
ALTER TABLE reititys.tietPgis
ADD COLUMN pituus float;
UDATE reititys.tietPgis
SET pituus = ST_Length(geom);
- Luodaan uusi PostGIS-taulu, johon tallennetaan vain tarvittavat tiedot tienpätkistä
CREATE TABLE reititys.tiet( id BIGSERIAL, ajosuunta BIGINT, source BIGINT, target BIGINT, pituus FLOAT, geom text, temp1 BIGINT, temp2 BIGINT);
INSERT INTO reititys.tiet( id, ajosuunta, source, target, pituus, geom, temp1,temp2) select id, ajosuunta, source, target, pituus, ST_AsText(geom), source, target from reititys.tietPgis;
- Lisätään tauluun sarake, joka sisältää tiedon siitä, mihin tiesegmenttiin kukin tienpätkä liittyy
ALTER TABLE reititys.tiet ADD COLUMN tieid float; UPDATE reititys.tiet SET tieid = id;

- Lisätään jokaista kaksisuuntaista kaarta kohti myös digitointisuunnan suhteen vastainen rivi
INSERT INTO reititys.tiet( id, ajosuunta, source, target, pituus, geom, temp1, temp2, tieid) select id+kaarien_lkm, ajosuunta, source, target, pituus, ST_AsText(geom), source, target, id from reititys.tietPgis where ajosuunta=2;
- Muokataan näille lisätyille riveille source ja target toisinpäin
UPDATE reititys.tiet SET source = temp2, target = temp1 where id > kaarien_lkm;
- Muokataan digitointisuunnan vastaisesti tallennettujen kaarien osalta source ja target tiedot oikein päin
UPDATE reititys.tiet SET source = temp2, target = temp1 where ajosuunta = 3;
- Korvataan ajosuunnat 3 / 4 arvolla 1, joka kertoo, että kyseessä on yksisuuntainen tie
UPDATE reititys.tiet SET ajosuunta = 1 where ajosuunta = 3 or ajosuunta = 4;
- Viedään luodut tiedot pois PostGISista csv-tiedostoina psql avulla
\copy (select * from reititys.tiet order by id) TO '/tiet2.csv' CSV HEADER \copy (select id, ST_AsText(the_geom) from reititys.tiet_vertices_pgr order by id) TO ' /solmut.csv' CSV HEADER
4. Optimointiongelman muodostaminen
Edellisessä vaiheessa luodut csv-tiedostot pitävät sisällään kaiken tiedon, jota tarvitset optimointiongelman muodostamiseen (tiedon jokaisen tienpätkän lähtösolmusta, päätesolmusta ja painokertoimena toimivasta pituudesta).
Leluesimerkki:
minimize pituus1 x1+pituus2 x2+pituus3 x3+...+pituusN xN subject to
- Solmusta A lähteviin tienpätkiin liittyvät päätösmuuttujat – solmuun A päättyviin tienpätkiin liittyvät päätösmuuttujat = 0:
x2-x1-x4=0 x1-x3=0 ... bounds
- Yksisuuntaiseen tiehen liittyville päätösmuuttujille:
x1<=2
- Kaksisuuntaiseen tiehen liittyville päätösmuuttujille:
x2<=1 x3<=1 ... xN<=1 integer x1 ... xN end
- Huomaa, että tasapainoehtoja (subject to -osio) tulee yksi jokaista graafin solmua kohti ja rajarajoitteita (bounds-osio) yksi kutakin graafin kaarta kohti
- Huomaa myös, että tässä leluesimerkissä pituus1=pituus2, sillä päätösmuuttujat x1 ja x2 ovat saman tien kaksi vastakkaissuuntaista pätkää
- Optimointiongelman muodostaminen kannattaa automatisoida esimerkiksi luomalla lyhyt python skripti, joka hyödyntää csv-tiedostojen sisältöjä ja kirjoittaa niiden pohjalta optimointiongelman formuloinnin leluesimerkin mukaisessa muodossa tekstitiedostoon
- LP-tiedoston luomiseen liittyy omat avainsanansa ja oma syntaksinsa [2]
- Lopuksi tulostiedostosta (optongelma.txt) tulee ottaa kopio ja tallentaa se .lp-muodossa
Optimointiongelman ratkaiseminen
CPLEX on lineaaristen ja rajoitteellisten kokonaislukuoptimointiongelmien ratkaisemiseen soveltuva ohjelmisto. CPLEX-ohjelmisto on IBM ILOG:n akateemisiin tarkoituksiin avoimesti ladattavissa oleva optimointiohjelmistopaketti, joka koostuu algoritmeista, työkaluista ja rajapinnoista. Koska kokonaislukuoptimointitehtävien ratkaisemiseen ei ole olemassa yhtä ylivertaisen tehokasta algoritmia, CPLEX-ohjelmistokin sisältää useita vaihtoehtoisia optimointitekniikoita. Ohjelmisto osaa itse valita kuhunkin tilanteeseen parhaiten soveltuvan ratkaisumenetelmän. Kokonaislukumuuttujia sisältäviin optimointiongelmiin soveltuvia eksakteja (takaavat ratkaisun optimaalisuuden) menetelmiä ovat CPLEX-ohjelmiston optimoijista muun muassa Branch and Cut -menetelmä ja dynaamisen etsimisen menetelmä. CPLEX pystyy lukemaan ratkaistavana olevan optimointiongelman suoraan komentorivin kautta lp-tiedoston muodossa tallennetusta tekstitiedostosta:
read
Itse optimointitehtävän ratkaisu onnistuu yhdellä käskyllä:
optimize
Optimaaliset päätösmuuttujan arvot saa näkyviin syöttämällä CPLEX:n komentoriville:
display solution variables *
- CPLEX on todella tehokas tämän tyyppisten ongelmien ratkaisemisessa; yli 900 päätösmuuttujan ongelman ratkaisemiseen meni alle puoli sekuntia
Ratkaisusta käy ilmi, että optimaalinen reitti, joka kulkee jokaisen tutkitun alueen tien kautta optimointiongelman rajoitteet täyttäen, on 58.9 kilometriä pitkä. Kyseessä on ehdoton alaraja sille, kuinka monta kilometriä vähintään täytyy ajaa, jotta alueen tiet saadaan käytyä läpi. Tätä alarajatietoa voi hyödyntää esimerkiksi arvioitaessa alueen läpikäymiseen varattavan polttoaineen tai sepelin määrää.


Kuvassa 1 on visualisoitu optimaalisen ratkaisun ajokerrat. Ensinnäkin on hieman yllättävää, että suurin osa kaksisuuntaisista teistä pystyttäisiin periaatteessa ajamaan vain kertaalleen molempiin suuntiin. Se taas on täysin odotettua, että yksisuuntaisia teitä ei kannata ajaa kuin minimimäärä eli kahdesti kulkusuuntaan (havainnollistettu nuolella). Mielenkiintoisin osa ratkaisua lienee se, että kuvasta nähdään mitä teitä pitkin kannattaa reitin kokonaismatkan minimoinnin kannalta kulkea ne pakolliset kierrokset, jotka välttämättä joudutaan suorittamaan, jotta verkoston jokainen kaksisuuntainen tie voidaan kulkea vähintään kerran molempiin suuntiin ja jokainen yksisuuntainen tie voidaan kulkea topologisesti ehjää reittiä pitkin vähintään kahdesti rikkomatta liikennesääntöjä.
Kiertojärjestyksen määrääminen optimaalisen ratkaisun pohjalta
Huolimatta siitä, että kokonaislukuoptimointiongelmaan on jo saatu määritettyä “ratkaisu”, emme silti vielä pysty vastaamaan otsikossa esitettyyn mistä, minne ja miten -kysymykseen. Pystyäksemme vastaamaan tähän kysymykseen, meidän on vielä selvitettävä missä järjestyksessä aura-auton tulee tieverkkoa kuvaavan graafin solmuissa käydä, jotta aura-auto pystyy lähtemään varikolta ja palaamaan sinne siten, että aura-auto on kulkenut läpi koko tieverkkoa vastaavan graafin ajamalla kutakin tienpätkää täsmälleen niin monta kertaa kuin CPLEXillä löydetty optimaalinen ratkaisu ohjeistaa.
Ajojärjestyksen määräämiseen kehitettiin toinen python skripti. Tämä python ohjelma tarvitsee kuitenkin toimiakseen huomattavan määrän valmiita “aliratkaisuja”. Python ohjelman logiikka on seuraava:
- Hyödynnetään CPP ongelman ratkaisemiseen kehitettyä kokeellista QGIS pluginia Chinese Postman Solver
- Tarkastellaan pluginin palauttamaa ratkaisua karttapohjalla ja jaetaan tarkasteltava verkosto alialueisiin sen mukaan, että jokainen alialue sisältää yhden yhtenäisen, pluginin palauttamassa ratkaisussa vain kertaalleen toiseen suuntaan kuljettavan polun, josta poiketaan muille teille vain edestakaisilla pistoilla
- Tallennetaan alialueet omiksi karttatasoikseen ja valitaan “porttisolmut”, joiden kautta siirrytään alialueelta toiselle (tämä solmu voi olla mikä tahansa kahta alialuetta yhdistävä edestakaisen “pistotien”solmu)
- Samalla tulee miettiä järkevä järjestys edetä alialueelta toiselle (tärkeää, että polku “sisimpään” alialueeseen kulkee kaikkien muiden alialueiden kautta)
- Ratkaistaan CPP ongelma uudelleen jokaiselle alialueelle em. QGIS pluginin avulla
- Tuloksena saadaan lista tieverkoston solmujen ID:itä, joka määrittää optimaalisen kiertojärjestyksen alialueelle
- Luodaan python skripti, joka noudattaa näitä alialueiden optimaalisia ratkaisupolkuja siihen asti, että kyseinen ratkaisupolku kulkee jonkin toisen alueen porttisolmun kautta → edetään suorittamaan seuraavan alialueen ratkaisupolkua
- Edetään eteenpäin verkostossa aina siihen asti, että päädytään sisimmän alialueen yhtenäisen polun päähän
- Tämän jälkeen lähdetään peruuttamaan yhtenäistä polkua takaisin päin aina siihen asti kunnes palataan sisimmän alialueen porttisolmulle
- Porttisolmulle palaamisen jälkeen jatketaan toiseksi sisimmän alialueen optimaalisen ratkaisupolun suorittamista, kunnes päädytään kyseisen alialueen ratkaisupolun päähän → aletaan jälleen peruuttaa kohti toiseksi ja kolmanneksi sisimmän alialueen välistä porttisolmua
- Tällä logiikalla palaamme lopulta takaisin varikolle siten, että jokaista verkoston tienpätkää on kuljettu kertaalleen molempiin kulkusuuntiin
Kuten tarkkasilmäisimmät saattoivat huomatakin, edellä mainittu logiikka perustuu ajatukselle, että jokaista tietä tulisi kulkea tasan kerran molempiin suuntiin. Jo pelkästään ongelmanmuotoilu (yksisuuntaisten teiden huomioonottaminen) määrittää, ettei tällaista oletusta voida tehdä. Lisäksi tiedämme CPLEXin tuottaman ratkaisun perusteella, että osaa kaksisuuntaisista teistä joudutaan ajamaan useamman kerran toiseen kulkusuuntaan. Syy, miksi voimme hyödyntää kiertojärjestyksen määräämisessä yllä kuvatun kaltaista logiikkaa on se, että eristimme tieverkostograafista ensin ne tienpätkät, joille ei päde se, että optimaalisessa ratkaisussa ko. tiesegmentti tulisi ajaa täsmälleen kerran molempiin kulkusuuntiin.
Tästä saatiin ensimmäinen alialue, jonka optimaalinen kiertojärjestys määrättiin manuaalisesti karttapohjaa katsomalla ja miettimällä minne seuraavaksi etenemällä pystyn kiertämään kaikki tiet täsmälleen niin monesti kuin optimaalinen ratkaisu ohjeistaa. Myös tälle “looppialueelle” määritettiin porttisolmu vastaavalla tavalla kuin muille alialueille, ja python skriptin näkökulmasta se oli samanlainen alialue kuin kaikki muutkin. Ainoa ero on se, että looppialueen ratkaisupolun tuottamiseen ei voitu hyödyntää QGIS pluginia, vaan se määritettiin loogisen päättelyn avulla.
Prosessiputken rakentamisen kannalta oli keskeistä oivaltaa, että looppialue kannattaa eristää ja että sille voidaan loogisesti päätellä järkevä kiertojärjestys. Ensinnäkin tämä mahdollisti kiertojärjestyksen ongelman redusoitumisen sen kokoiseksi, että ihmisaivot pystyivät looppialueen ratkaisujärjestyksen määrittämään. Toisekseen tällä tavalla saimme ensiarvoisen tärkeää tietoa siitä, miten moni asia vaikuttaa kiertojärjestyksen määräytymiseen. Kolmanneksi saimme muun tutkimusalueen muovattua sellaiseen muotoon, joka on hyvin lähellä perus-CPP:n ongelmanmuotoilua. Toki me tiesimme CPLEXin ratkaisun perusteella jo, että jokainen tie tulisi kulkea edestakaisin ja tätä ei perus-CPP:ssä vaadita. Kuitenkin, perus-CPP:ssä vaaditaan, että jokainen tie kuljetaan läpi ainakin kertaalleen. Todennäköisesti siis pystyisimme pluginilla tuottamaan sellaisen ratkaisun tälle verkoston loppuosalle, josta saisimme selville jotain hyödyllistä. Osa teistä varmasti tulisi pluginin ratkaisussa käytyä edestakaisesti, jolloin ratkaisu olisi näiden osalta jo valmis. Ja vaikka osa teistä käytäisiin vain kertaalleen läpi, eikö olisi mahdollista kulkea tällainen yhtenäinen polku (matkalle osuvissa “pussinperissä” poiketen) aluesta loppuun asti ja peruuttaa sitten takaisin, jolloin kaikki tiet tulisi ajettua täsmälleen kerran molempiin kulkusuuntiin?
Suoritettuani pluginin koko “ykkösverkostolle” (koko verkosto – looppialue), havaitsin, että saatu ratkaisu oli pitkälti toivomani kaltainen. Ainoana isona ongelmana näytti olevan se, ettei tällaista yhtä yhtenäistä yhden kulkusuunnan polkua näyttänyt muodostuvan, vaan niitä oli muodostunut useita ympäri ykkösverkostoa. Niinpä päätin rajata ykkösverkoston alialueisiin sen mukaan, että jokainen alialue sisältää täsmälleen yhden tällaisen yhtenäisen yhteen suuntaan pluginin ratkaisussa kuljettavan polun + kasan pussinperäksi luokiteltavia visiittejä sivuteille. Tarve uuden alialueen muodostamiselle syntyi siis aina, kun yhtenäinen polku katkesi tiellä, joka pluginin ratkaisussa haluttiin ajaa edestakaisin.
Python skriptiin ohjelmoitiin myös tarkistusproseduuri siltä varalta, ettei plugin ole kaikilta osin tehnyt samoja valintoja kuin CPLEXillä tuotettu optimaalinen ratkaisu edellyttäisi. Jos näin on, joitakin tienpätkiä jää kulkematta. Tällaiset tilanteet ratkottiin manuaalisesti katsomalla karttapohjasta, että tässä kohtaa ollaan toisen kerran käytetty samaa kaarta, mutta samat solmut voi yhdistää myös kiertämällä useampia solmuja pitkin (nämä ovat juuri niitä solmuja, jotka ovat jääneet kulkematta). Kaiken kaikkiaan voisi sanoa, että osittamalla ongelma järkevällä tavalla alialueisiin, päästiin niin lähelle, että perus-CPP:n ratkaisemiseen kykenevää QGIS pluginia hyödyntämällä pystyttiin päättelemään loput ja löytämään kiertojärjestys, joka noudattaa täsmälleen CPLEXillä määrätyn optimaalisen ratkaisun ajokertoja.
Lopputulos
On ilmeistä, että skaalautuvuus on kehitetyn prosessiputken haaste. Tieverkoston graafin rakentaminen ja optimointiongelman ratkaiseminen on nopeaa, kiertojärjestyksen määrääminen taas monilta osin manuaalista ja virhealtista. Hyvä puoli kehitetyssä menetelmässä on, että se mallintaa ongelman realistisesti, löydetyn ratkaisun optimaalisuus on taattu ja ratkaisu on otettavissa käyttöön sellaisenaan. Ratkaisu määrittää suoran toimintaohjeen, joka on validi niin pitkään, kun tieverkkoon ei tule muutoksia.
Alla olevista videoista näet, miten Tampereen Pispalan kadut kannattaisi aurata. Ratkaisusta käy ilmi, että toteuttamalla reittioptimointi edellä kuvatun prosessiputken kautta on mahdollista vastata kysymykseen, miten jonkin alueen tiet kannattaisi ajaa läpi, jos halutaan minimoida aura-auton ajamaan kokonaismatkaa. Tavoite ajoreitin kokonaispituuden minimoinnista on perusteltu, sillä tällöin ajoaika ja sitä kautta ilmakehään päätyvät päästötkin minimoituvat.
Valitettavasti projektin aikana tuotettua tulosta ei voitu suoraan ottaa käyttöön. Digiroad-aineiston sisältövirheiden vuoksi muutama portaikko oli digitoitu teiksi, joita pitkin optimaaliset aurauspolutkin sitten kulkivat. Huolimatta harmittavasta takaiskusta, projektissa onnistuttiin luomaan prosessiputki, jonka avulla todellisesta tieverkosta (virheineen) voidaan luoda graafi, jolle voidaan luoda muokattu reaalimaailman ongelmaa todenmukaisesti mallintava optimointiongelma, joka kyetään ratkaisemaan ja jonka ratkaisu kyetään muuntamaan niin suoraksi toimintaohjeeksi, että siitä voidaan muutamassa minuutissa nähdä, mitä ratkaisu käytännössä ehdottaa. Valitettavasti virheellisyydetkin ovat tällöin helpommin tunnistettavissa kuin kokonaislukuoptimointiongelmaa minimoivaan tulosvektoriin piilotettuina arvoina.
Lisäksi, taisin näyttää tässä projektissa todeksi eräässä toisessa blogissa näkemäni hieman maagisen määritelmän reittioptimoinnille. Jos optimoimalla voi saada aurat lentämään portaiden yli niin maybe there really is some magic in the air?
Lähteet
[1] P. Mäkinen: Ambulanssien optimaaliseen sijoittamiseen ohjaava monitavoitemalli. Pro gradu -tutkielma, Turun yliopisto, 2018.
[2] IBM Knowledge Center: Using the LP format. https://www.ibm.com/support/knowledgecenter/en/SSSA5P_12.6.1/ilog.odms.cplex.help/CPLEX/GettingStarted/topics/tutorials/InteractiveOptimizer/usingLPformat.html
[3] M. P.L. Haslbeck: Algorithms for the Mixed Chinese Postman Problem. Final Report for an Interdisciplinary Project, Technische Universität Munchen, 2015.
[4] Informaatiota Travelling Salesman Problem historiasta, sovelluksista ja ajankohtaisista aiheeseen liittyvistä tutkimuksista:
Kerroimme aiemmin syksyllä Gispon blogissa FMI2QGIS-projektista, jonka päämääränä oli kehittää QGISiin oma lisäosa Ilmatieteen laitoksen avointen datojen helpompaan käsittelyyn ja lataamiseen. Alunperin fokus oli erityisesti ilmanlaatudatan (esimerkiksi ENFUSER-ennustedatan) saamiseen QGISin käyttöön, mutta muidenkin Ilmatieteen laitoksen avointen aineistojen mukaanotto lisäosaan varmasti lisää näiden datojen käyttäjäkuntaa ja hyödynnettävyyttä.
Loppuvuosi onkin kulunut paljolti meteorologisten paikkatietoaineistojen ja niiden erityispiirteiden kanssa ahertaessa. Erilaisten havainto- ja ennustedatojen määrä ja koko, lukuisine erilaisine parametreineen on aiheuttanut omat haasteensa, ja uutena tuttavuutena on tullut myös mm. aineiston käsittely NetCDF-formaatissa. Näistä myöhemmin varmasti vielä lisää, kuten muistakin lisäosan ns. konepellin alaisista komponenteista.
Nyt kun alustava versiojulkaisu (versio 0.1.0) on ajankohtainen, lienee paikallaan kertoa kuitenkin yleisemmin mitä ollaan tähän asti saatu aikaan, ja esitellä hieman lisäosan toiminnallisuutta. Julkaistu lisäosa löytyy suoraan QGISin plugin-repositoriosta (https://plugins.qgis.org/plugins/FMI2QGIS/, kirjoitushetkellä vielä versio 0.0.1) ja on asennettavissa QGISin omalla lisäosien hallintatyökalulla. GitHubista puolestaan löytyy viimeisimmät koodimuutokset ja ohjeet pluginin käyttöön.
Lisäosan graafinen käyttöliittymä helpottaa siis karttatasojen lataamista ja lisäämistä QGISiin Ilmatieteen laitoksen WFS- ja WMS-rajapinnoista, hyödyntäen rajapintojen tallennettuja kyselyjä (stored query). WFS:n tallennettuja kyselyjä löytyi kirjoitushetkellä 141 kappaletta erilaista havainto- tai ennustedataa, esimerkiksi pitemmän ajan lämpötilatilastoista salamahavaintoihin. Lisäosan avulla on ensinnäkin mahdollista listata nämä saatavissa olevat tasot ja niihin liittyvät parametrit. Parametrit vaihtelevat tallennetusta kyselystä toiseen, ja kaikille tasoille ei vielä tässä vaiheessa löydy tukea. Lisäosan käyttöä on havainnollistettu alla, ENFUSER-datan ilmanlaatuindeksin yhteydessä:

Olipa kyse sitten havainnoista tai ennustedatasta, meteorologisille aineistoille on olennaista aikariippuvuus. Aiemmin aikariippuvuuden käsittely QGISissa on hoitunut erillisen lisäosan avulla, mutta versiosta 3.14 lähtien vastaava toiminnallisuus tulee perusasennuksen mukana Temporal Controller -työkalun muodossa. Tämä onkin integroitu FMI2QGIS-lisäosan käyttöön mukaan siten, että se käynnistyy automaattisesti lisäosan kanssa ja osaa lukea ladattavien aineistojen aikaleimat suoraan:

Lisäosasta löytyy myös oma osionsa WMS-tasojen lisäykseen QGISin karttaikkunaan katseltavaksi. Avoimia aineistoja löytyy valittavana listasta jälleen runsaasti, Suomen tutkahavainnoista, laajempiin säätila- ja tuuliennusteisiin. Tässäkin löytyy oma parametrien valinta -osio, mutta yleisesti käyttö on WFS-tasoja suoraviivaisempaa, ja meteorologisten datojen aikakehityksen seuranta onnistuu jälleen myös automaattisesti:

Kunhan lisäosan alustava julkaisu saadaan ulos ja käyttäjille testattavaksi, toiveissa olisi jatkossa pystyä kehittämään lisäosaa pidemmälle. Mukavaa olisi, jos löytyisi resursseja kehittää lisää esimerkiksi erilaisten parametrien tukea, aineistojen visualisointia ja lisäosan yleistä käytettävyyttä. Eli ei muuta kuin testaamaan ja tulevia säätiloja havainnoimaan! Käyttäjäpalautetta ja mahdollisesti havaittuja bugeja voi ilmoittaa yllämainittuun Github-repositorion Issueihin tai suoraan sähköpostitse osoitteeseen jaakko@gispo.fi.
Gispon Sanna ja Anniina kokeilivat graafisen kartan tekoa. Liekö Topin karttahaaste innoittanut tähän vai mikä heihin iski. Tässä ajatuksia graafisen kartan tuotannosta.
Kuvankäsittelyohjelmistot matkailukartan tuotannossa
Anniina Kovalainen
Olen harrastanut digitaidenäpertelyä ja graafista suunnittelua jo pitkään, joten kun Topin 30DayMapChallenge-karttahaasteessa oli 12. päivän kohdalla “Map not made with GIS software”, tunsin hetkeni koittaneen. Päätin tehdä graafisen matkailukartan muutamasta nähtävyydestä kotikaupungissani Kajaanissa (tarkoitukseni oli tehdä useampi nähtävyys, mutta kun kello lähestyy uhkaavasti puolta yötä, päätin tyytyä hyvin niukkaan otokseen, heh). Graafinen matkailukartta on tuotettu Adobe Photoshopilla, mutta kartan referenssipohja on kasattu QGISissä (mm. MML:n maastotietokanta datapohjana). Työstin dataa ensin paikkatietopohjaisesti, jonka jälkeen otin datan ulos PNG:nä vein Photoshoppiin. Siellä alkaa kartan varsinainen graafinen työstö.
Graafinen suunnittelu ja työstö vaatii todellisuudessa aikaa ja useita iterointikertoja – mielellään myös silmien ja aivojen nollaustaukoa iterointien välissä. Koska tässä karttahaasteessa aika oli erittäin rajallinen, päätin ottaa lähestymistavaksi “piirretyn oloisen kartan”. Linjojen ei tarvitse olla suoria tai viimeisen päälle huoliteltuja, vaan ne saavat olla hieman rosoisia ja “lapsenomaisia”. Nähtävyyksien työstö vei yllättävän paljon aikaa, sillä en halunnut kadottaa nähtävyyksien tunnusmerkkejä pelkistämällä niitä liikaa. Mitä monimutkaisemmat piirteet, sitä kauemmin sen käsittelyyn meni aikaa. Lopputuloksen näettekin alla!

Miksi graafisia karttoja?
Graafiset kartat ovat oivallisia viestintäelementtejä käytettäväksi esimerkiksi juuri matkailussa, opasteissa, verkkosivuilla, tulosteina, esitteissä ja niin edelleen – vain mielikuvitus on rajana! Jos tarvitset staattisen kartan joka päräyttää ja ponnahtaa esiin tai on visualisoitu organisaation graafisen ilmeen mukaan, QGIS + Photoshop -kombinaatiolla tuotettu graafinen kartta on oivallinen valinta.
Opaskartta QGISillä
Sanna Jokela
Osallistuin matkailualan webinaariin Turussa muutama viikko sitten ja webinaarissa käytiin läpi matkailuyritysten monikanavaisuuden haastetta: mihin kaikkialle esimerkiksi aukioloaikatietoja pitää kirjata, missä olla läsnä, mihin osoitetiedot kirjata. Aikamoinen hässäkkä tästä syntyy. Matkailijan näkökulmasta tärkeää olisi, että tiedot löytyvät oikein joka paikasta. Ja helposti. Tästä aiheesta voisin avautua loputtomiin. Mutta sitten tilaisuuden lopuksi Turun AMK:n lehtori Telle Tuominen totesi, että on se paperikarttakin aika hyvä väline vielä nykyaikana. Ja siitä idea sitten lähti.
Olen asunut Turun edustan saarilla ensin lapsuuteni ja paluumuuttajanakin jo 6 vuotta. Mutta en todellakaan tiedä mitä kaikkea hauskaa saarilta löytyy. Korona-aikana metsäpolkuja ja muinaismuistoja on tullut koluttua ihan eri tavalla. Kyselin meidän saarten Facebook-ryhmässä mitä kaikkea kartalle haluttaisiin ja sain liudan kohteita ja palveluita, joista en oikeasti tiennyt yhtään mitään. Osa tiedoista löytyi OpenStreetMapin, Varsinais-Suomen palvelutietoaineiston (joka oli aika vanhentunut), Postin karttapalvelun ja Museoviraston aineistorajapintojen avulla (WFS-rajapinnat eivät näyttäneet kohteita ollenkaan) ja LIPAS-palvelun avulla. Suurin osa kohteista ja web-linkeistä tuli siskon avustuksella (hän on googletuksen mestari) sekä FB-ryhmän avustuksella.
Taustakartan sain helposti tehtyä MML:n maastotietokannan tietoja yhdistävän ja visualisoivan QGIS-plugarin avulla, joka tehtiin pari vuotta sitten asiakkaan kanssa yhteistyössä. Vähän visualisointeja modaamalla sain aika kivan taustakartan. QGISin default-symbolit palveluille saivat tällä kertaa riittää (Anniina on meillä paras tekemään kustomoituja symboleita). Laskin, että kokonaisuudessaan opaskartan tekoon meni ehkä 2 henkilötyöpäivää aikaa, suurin työ oli kohteiden metsästys ja tarkastus.
Havaitsin myös jännän ilmiön. Kartta on aika vahva väline viestintään ja se, että kohteet on kartalla, tekee asiasta jotenkin erityisen virallista. Facebook-ryhmässä käytiin vähän kiivastakin keskustelua kohteista. Toiset pyysivät seurakunnan rantaa kartalle, toiset kauhistuivat että se laitettaisiin sinne. Toiset halusivat kaikki muinaismuistokohteet ja luontokohteet kartalle, toiset pelkäsivät että ne turmellaan sitten heti. Toinen haaste on polut ja reitit. Metsät täynnä polkuja ja maastokartoiltakin ne löytyvät, mutta ei niitä uskaltanut laittaa tämän tyyppiseen toteutukseen, kun eivät ole ns. virallisia. Tavallaan itse yllätyin tästä reaktiosta, koska käytin vain avointa dataa kohteiden ja reittien valitsemiseen ja ne löytyvät muutenkin jo kymmenistä palveluista…
Nyt kartta on julkaistu avoimesti saarelaisten käyttöön ja joku ehti niitä printata ja laminoida jaettavaksi. Uusia versiota varmasti vielä tulee. Tästä iltapuhdeprojektista jäi hyvä mieli ja näitä tekisi mielellään lisääkin!

Jos graafiset kartat kiinnostavat ja tarvitsisit vaikkapa kotisivuillesi tai matkailusivuille näyttävän karttavisualisoinnin, ota yhteyttä info@gispo.fi!
Lakimaantiede (tai oikeusmaantiede) on käsitteenä monelle vieras, mikä ei sinällään ole mikään ihme: lakimaantiede on suhteellisen nuori käsite eikä se varsinaisesti ole oma tieteenalansa. Lakimaantiede on suuntaus, joka yhdistelee mm. oikeustieteen ja maantieteen ilmiöitä, teorioita, käsitteitä ja metodologioita toisiinsa. Fakta nimittäin on se, ettei lakia tai siihen liittyviä prosesseja voida irrottaa maantieteestä. Koko lain instituutio on maantieteellinen ilmiö ja lakeja tuotetaan aina jonkinlaisessa maantieteellisessä kontekstissa, johon niiden oikeutus tai velvoittavuus yleensä myös sitoutuu; lailla on aina jokin alue, paikka ja/tai tila, missä se on tuotettu ja mihin se vaikuttaa. Ehkä helpoin tapa ymmärtää lainsäädännön maantieteellisyys on valtiolliset rajat, jotka erottavat juridiset entiteetit toisistaan; Suomen lainsäädäntö ei ole voimassa Ruotsissa, eikä toisinpäin.
Lakimaantiede tutkii muun muassa lakiin, lakijärjestelmään, laillisuuteen, oikeuteen ja oikeudenmukaisuuteen liittyviä teemoja maantieteen käsitteiden ja metodologian keinoin. Lakimaantieteellinen tutkimus on keskittynyt enimmäkseen valtioiden instituutioiden juridiseen toimintaan, mutta tutkimusta on tehty myös esimerkiksi valtiosta riippumattomista toimijoista, ilmiöistä sekä erilaisista lakien ilmenemismuodoista.
Lain tulkinta ja käytäntö vaihtelevat alueellisesti, paikallisesti ja tilallisesti
Lainsäädäntö ja sen ilmeneminen tulkinnoissa ja sosiaalisessa kanssakäymisessä ei ole alueellisesti, paikallisesti tai tilallisesti identtistä, vaikka sama lainsäädäntö koskisikin kaikkia toimijoita. Eroja voi synnyttää esimerkiksi lain erilaiset tulkintatavat, epäselvyydet, tietämättömyys, käytännön määrittelyn avoimuus ja/tai noudattamisen mahdollisuudet. Suomessa esimerkiksi asema- ja yleiskaavoitus ovat yksi mielenkiintoinen esimerkki lain alueellisesta vaihtelusta: vaikka lainsäädäntö on kaikille sama, laki jättää avoimeksi paljon käytännön asioita, jolloin lakia sovelletaan käytännössä hyvin eri tavoin eri alueilla.

Lakitila
Lakitila on omasta mielestäni yksi mielenkiintoisimmista tavoista tutkia lain ilmenemistä käytännössä, sillä se mahdollistaa hyvin tarkan lakimaantieteellisen analyysin esimerkiksi vaikkapa työpaikan sisällä. Lailliset toimijat (työpaikalla esimerkiksi työntekijät) tuottavat lakitilaa sosiaalisen käyttäytymisen kautta – lait vaikuttavat siihen, miten yksilö toimii eri tilanteissa ja minkälaista tilaa tuotetaan. Tehdään läpivalaisu työhuoneestasi, joka sisältää valtavan määrän erilaisia lakeja, jotka vaikuttavat tuotettuun lakitilaan. Työhuoneesi sijaitsee luultavasti työpaikkasi tiloissa, joka on rakennettu valtion rakennuslakia ja siihen kytkeytyviä lakeja noudattaen. Jos työhuoneessasi ilmenee esimerkiksi jokin rakenteellinen terveyteen negatiivisesti vaikuttava ongelma, sinulla on oikeus vaatia toimenpiteitä asian korjaamiseksi ja luultavasti rakennusyhtiöllä tai työnantajalla on velvollisuus korjata työhuoneesi terveydellesi turvalliseksi: jos mitään ei tehdä, siitä seuraa rangaistus. Fyysisen ympäristön lisäksi voidaan tarkastella muita toimijoita, jotka vaikuttavat lakitilaan – kuten sinua itseäsi tai työtovereitasi. Sinuun itseesi piiloutuu paljon oikeuksia ja velvollisuuksia, mutta työpaikalle tullessasi saat vielä uuden kaavun yllesi, mihin liittyy työpaikkaan sidotut oikeudet ja velvollisuudet. Sama pätee työtovereihisi ja työpaikalla tapahtuvaan kanssakäymiseen. Tässä on pintaraapaisu erilaisista laeista, mitkä luultavasti vaikuttavat sinun työhuoneessasi ja tuottavat sosiaalisessa vuorovaikutuksessa tietynlaista lakitilaa. Lait vaikuttavat tilassa normeihin, arvoihin ja yleiseen mielenmaisemaan, mitkä ohjaavat käyttäytymistä.
Laki ja maantiede vaikuttavat toinen toisiinsa jatkuvasti
Lain ja maantieteellisten ilmiöiden suhde on dynaaminen ja vastavuoroinen: lait vaikuttavat jatkuvasti maantieteellisiin ilmiöihin ja toisinpäin. Suomessa lailla esimerkiksi määritellään erilaisia valtion sisäisiä alueita, joille annetaan omia oikeuksia ja velvollisuuksia. Toisaalta taas esimerkiksi lain tilallisten tulkintojen ja käytäntöjen kautta voidaan havaita kehitystarpeita lainsäädäntöön, jolloin maantieteelliset ominaisuudet taas vaikuttavat vastavuoroisesti lain säätämiseen.

Lakimaantiede on kriittisen analysoinnin työkalu, joka paljastaa näkymättömiä rakenteita ja toimintamalleja
Lakimaantiede on hyödyllinen tieteellinen tulokulma yhteiskunnallisiin teemoihin, sillä sen avulla voidaan mm. kriittisesti analysoida lain juridista perustaa ja sen toimivuutta erilaisten maantieteellisten käsitteiden keinoin sekä tunnistaa lainsäädännön tuottamia näkymättömiä yhteiskunnan rakenteita ja ilmiöitä ja niiden syntymisen syitä. Lainsäädäntöä ja sen toimivuutta voidaan analysoida kriittisesti esimerkiksi tutkimalla lakitiloja tai lain käytäntöjen alueellisia eroja. Tiettyjen lakien kohdalla on löydetty merkittäviä eroja lain käytännöissä esimerkiksi pienten ja suurten kuntien välillä. Syitä käytännön eroihin voi löytyä itse laissa (selvyys, tulkinnanvaraisuus, ohjeistukset), lain täytäntöönpanoprosesseissa, lain valvonnassa tai lain tulkitsijassa (resurssipula…). Lain alueellinen eriarvoisuus voi aiheuttaa myös sen, että kaikilla laillisilla toimijoilla, kuten pienillä kunnilla, ei välttämättä ole samanlaisia mahdollisuuksia toteuttaa lainsäädäntöä kuin toisilla. Tästä johtuen lakia voidaan tulkita sen rakenteesta riippuen paljon laveammin toisilla alueilla kuin toisilla.
Teimme jo aikaisemmin pienen läpileikkauksen työhuoneeseesi vaikuttavista laeista, mikä ilmentää hyvin sitä, miten lakimaantieteen avulla voidaan tunnistaa lain näkymättömämpiä rakenteita ja ilmiöitä. Monesti näkymättömän lain rakenteen läsnäolon huomaa vasta sitten, kun jotain on pielessä – esimerkiksi jos vaikkapa työhuoneen katosta tippuu vettä tai jos työkaveri käyttäytyy asiattomasti. Silloin tulee tietoiseksi omista oikeuksistaan sekä työkavereiden ja työnantajan velvollisuuksista. Yhteiskunnassa laki on läsnä jokaisessa tilassa, oli se sitten näkyvä tai ei.
Voidaan olla ehkä yhtä mieltä siitä, että monien erilaisten näkökulmien huomioiminen parantaa mahdollisuuksia siihen, että laki on toimiva myös käytännön tasolla. Lakimaantiede on yksi tällainen näkökulma, jonka pitäisi olla vahvemmin mukana lainsäädäntöprosesseissa, sillä maantiede ja paikkatieto ovat kaikkialla. Lainsäädäntöprosessin aikana on kuitenkin hankala ellei jopa mahdoton tietää, miten laki todellisuudessa käyttäytyy ja onko se selvityksistä huolimatta toimiva. Yksi tapa on tehdä teoreettista ja loogista testausta esimerkiksi tulevaisuudentutkimuksen menetelmien avulla: Delfoi-menetelmän ja tulevaisuusverstaiden avulla voidaan kartoittaa nykytilan ja tulevaisuuden arvoja ja normeja, joita testataan useampien eri skenaarioiden avulla.
Tämä artikkeli on vain pintaraapaisu lakimaantieteen moniulotteiseen ja alati kehittyvään maailmaan. Jos kaipaat selvitystä, tutkimusta tai jotakin muuta lakimaantieteeseen liittyvää konsultointia, ota ihmeessä yhteyttä anniina@gispo.fi tai info@gispo.fi!
QGIS paikkatieto-ohjelmistona ja OpenStreetMap (OSM) “avoimena maailmankarttana” ovat kaksi hyvin tunnettua ja menestynyttä avoimen lähdekoodin ja avoimen tiedon projektia. Molemmat juontavat juurensa 2000-luvun alkupuolelle, ja ovat nousseet ominaisuuksiensa ja aktiivisten yhteisöidensä ansiosta suosituiksi vaihtoehdoiksi suljettujen ratkaisujen tilalle.
Vaan kuinka QGIS ja OSM sitten toimivat yhteen, vai toimivatko? Ja pystyykö OSM:n dataa hyödyntämään helposti QGISissa esimerkiksi erilaisten paikkatietoanalyysien tekoon? Tässä artikkelissa esitellään lyhyesti QGISista löytyvät perustyökalut OpenStreetMapin aineistojen hyödyntämiseen eri tarkoituksiin.
Taustakarttana
Ehkä yleisin tai ainakin yksinkertaisin tapa käyttää OSM:in dataa QGISin projekteissa on suoraan taustakarttana. Tämän voi tehdä kahdellakin tapaa. Ensinnäkin QGISin selain-ikkunasta löytyvä XYZ Tilesin avulla voi määritellä eri palveluja karttatiilien noutamiseksi, ja OSM:lle tämä on tehty vieläkin helpommaksi, sillä se löytyy lisättynä XYZ Tiles -valikkoon oletuksena. Perustyylisen OpenStreetMap-kartan saakin lisättyä projektiin kuin projektiin todella helposti, riittää vain raahata se hiiren avulla karttaikkunaan!

Toinen tapa on käyttää lisäosia. Tarkastellaanpa aluksi samalla mitä kaikkea lisäosia QGISille on OSM:iin liittyen olemassa. Avataan siis Lisäosat-valikko ja sieltä “Hallitse ja asenna lisäosia…” ja kirjoitetaan sitten hakukenttään esimerkiksi “osm”, jolloin löydetään kaikki QGISin lisäosat joilla on kyseinen tägi. Huomataan, että näitä erilaisia OpenStreetMap:iin liittyviä lisäosia löytyy kirjastosta noin kymmenen kappaletta.
Valitaan asennettavaksi QuickMapServices-lisäosa, joka tarjoaa suuren määrän taustakarttoja. Vaikka lisäosan listauksesta löytyviä palveluja taustakartoiksi selaillessa voikin viettää pitkän tovin, OSM löytyy helposti, ja lisäosa mahdollistaa OSM:n perustyylin lisäksi myös eri karttateemojen käyttämisen (Cycle Map, Landscape, Outdoors, Transportation ja Veloroad).


OSM-datan lataus
Jos sen sijaan haluaa päästä käsiksi suoraan OSM:n dataan ja tuomaan sen QGIS-projektiin muokattavaksi vaikkapa vektoritasona, on tämänkin toteuttamiseksi jälleen useampi vaihtoehtoinen tapa. Tässä kohtaa huomio saattaa kiinnittyä OSM:n ja QGISin datan hieman erilaisiin rakenteisiin. Siinä missä OSM-kohteetkin ovat pisteitä, viivoja tai alueita, näitä kuvataan elementeillä nodes/ways/relations ja niihin saattaa liittyä lukematon määrä ominaisuustietoja, jotka kuvataan eri tunnisteilla (tags). Muunnos OSM:n ja QGISin avulla kuitenkin onnistuu tässäkin tapauksessa ilman lisäponnisteluja ja OSM-kohteet saa ladattua QGISiin GDAL-kirjaston suosiollisella avustuksella.
Yksi tapa OSM-datan lataamiseen on käyttää Geofabrikin latauspalvelimia ja noutaa data jostain isommasta alueesta kokonaisuudessaan (menemällä web-selaimella osoitteeseen https://download.geofabrik.de/ ja sieltä downloads > maanosa > maa > osa-alueet). Kuitenkin esimerkiksi Suomesta on ladattava koko alue kerralla, pienempiä osa-alueita ei löydy. Tyypillisesti päivittäin päivittyvä data on ladattavissa joko pbf- tai Shapefile-formaateissa ja se sisältää lisäksi kaiken OSM-kohteiden datan kyseiseltä alueelta, tiettyjä metatietoja kuten muokkausten käyttäjätietoja lukuunottamatta.
Mikäli kiinnostuksen kohteena oleva alue tai data on vähänkään rajoitetumpaa, kätevämpi tapa on käyttää lisäosaa nimeltä QuickOSM. Tämä mahdollistaa alueen rajaamisen ja myös noutamaan vain tietyntyyppiset kohteet eri kyselyillä. Lisäosa käyttää Overpass APIa ja sen omaa kyselykieltä, mutta pikakyselyitä pystyy helposti muodostamaan myös suoraan pudotusvalikkoja käyttämällä. Tällöin voi valita alueeksi tietyn paikannimen, sen ympäristön, karttanäkymän tai tason, ja noutaa sieltä tietyt kohteet vain tägien tiettyjen arvojen perusteella. Tulokset saadaan ns. Väliaikaisina luonnostasoina geometrioittain, jotka on siis vielä erikseen tallennettava.

Toinen työkalu OSM-datan lataamiseen on OSMDownloader-lisäosa, jonka avulla voi valita tarkasteltavaksi alueeksi nelikulmion, josta kohteet haetaan. Se mahdollistaa myös vektoritason suoran lisäyksen QGISiin.
Geokoodaus
QGISiin on saatavissa kätevä hakutoiminto kohteiden hakemiseen paikannimen tai osoitteen perusteella. Asennuksen jälkeen Nominatim Locator Filter -geokoodauslisäosa löytyy QGISin pääikkunan vasemmasta alakulmasta klikkaamalla ja valitsemalla:

Käänteiseen geokoodaukseen kykenee puolestaan OSM Place Search. Kannattaa kuitenkin huomata, että tämä on ns. kokeellinen lisäosa, ja QGIS ei erityisesti suosittele niiden käyttöä muuta kuin testaustarkoituksiin. Tämän vuoksi lisäosa ei myöskään aiemmin näkynyt hakutuloksissa etsiessämme erilaisia lisäosia osm-hakusanalla. Myös kokeelliset lisäosat saa kuitenkin näkyviin, kun rastittaa Lisäosat-ikkunan Asetukset-kohdasta tarvittavan kohdan:

Reititys
Reittien suunnitteluun ja optimointiin OSM-dataan perustuen löytyy lisäosa ORS Tools. Käyttö vaatii API-avaimen (on annettava lisäosalle Provider Settings -kohdassa), jollaisen saa rekisteröitymällä ilmaiseksi osoitteessa: https://openrouteservice.org/
Perusreitityksen voi tehdä monen pisteen kautta ja perustuen joko matkan tai matka-ajan optimoimiseen. Valittavana on eri kulkuvaihtoehtojen (auto, polkupyörä, jalan, rullatuoli) lisäksi kullekin vielä eri moodeja (esimerkiksi cycling-regular/road/safe/mountain/electric). Lisävalinnoista voi valita myös joko vältettäviä tägejä tai monikulmio-taso. Lisäosalla on mahdollista ratkoa optimaalista reittiä kauppamatkustajan ongelmalle.

Batch Jobs -välilehdeltä löytyy lisäksi työkalut esimerkiksi laskemaan kuinka laaja alue on mahdollista tavoittaa tietyn ajan sisällä (isochrones) eri matkustustavoilla.

Datan ajallinen muutos
OSM-kohteiden ajallista muuttumista kartalla voi tutkia Animate OSM -lisäosalla. Alunperin Humanitarian OpenStreetMap Teamin (https://www.hotosm.org/ ) tehtävien edistymisen seurantaan kehitetty lisäosa, joka tällä hetkellä mahdollistaa ainoastaan rakennus-datan tarkastelun.
Lopuksi
Tässä artikkelissa annetut esimerkit ovat vain pintaraapaisu tavoista, joilla OSM-dataa voi hyödyntää QGISissä. Parasta onkin siis ottaa lisäosista kiinnostavimmat omaan testaukseen ja hyödyntää tätä koko maailman kattavaa avointa dataa omissa projekteissa.
Nyt sitä riittää, paikkatietodataa nimittäin. On satelliittikuvadataa ja on tarkkaakin tarkempia pistepilviaineistoja – osaajia on kuitenkin vähässä.
Maanmittauslaitos (MML) julkaisee piakkoin tarkkaa laserkeilausaineistoa, kun taas European Space Agency (ESA) jakaa satelliittikuvadataa terabiteittäin. Varsinaisia toimialamurroksia tai merkittäviä tuottavuushyötyjä synnyttäviä paikkatietoratkaisuja näkee kuitenkin vähän suhteessa dataan liittyvään hyötypotentiaaliin. Viimeisen viiden vuoden aikana datan määrä on kasvanut huimasti – reilusti yli sen osaamiskapasiteetin, jolla dataan liittyvä hyötypotentiaali voitaisiin lunastaa.
Strategisella tasolla kehitystä voisi ohjata seuraavilla ohjenuorilla:
- Jalkauta paikkatiedot organisaation tiedonhallinnan, data-analytiikan ja tietojohtamisen prosesseihin
- Sijoita osaamiseen, unohda hype

Elämme kaukana siitä ajasta, jolloin paikkatietojen käsittely vaati organisaatioilta paikkatietotehtävien keskittämistä vain muutamalle henkilölle. Rajattu määrä käyttölisenssejä paikkatieto-ohjelmistojen käyttöön sekä hitaat, manuaaliset tiedostopohjaiset paikkatietoprosessit ohjasivat organisaatiot “GIS-yksikköjen” luomiseen. Paikkatietojen käyttö siiloutui ja jäi suurelta massalta käyttämättä.
Nykypäivänä paikkatietoteknologiat mahdollistavat datan helppokäyttöisyyden. Paikkatieto-osaamisen kerryttäminen organisaatioissa ei kuitenkaan tapahdu itsestään, vaan osaamista pitää systemaattisesti kasvattaa. Ilman tätä paneutumista ei voida olettaa, että jokin musta laatikko, kuten lohkoketjut tai koneoppiminen ratkaisee kaiken ja innovoi ihmisten puolesta.
Käytännön tasolla voisi potkua syntyä seuraavista ajatuksista:
- Mahdollista paikkatietojen integrointi sovelluksiin, ohjelmistoihin ja järjestelmiin keskitettyjen ydintietovarantojen avulla
- Rikasta olemassa olevia tietotuotteita paikkatiedoilla,
- Tuo organisaation ulkopuolista dataa organisaation tietovarantoihin
Keskittämällä organisaation paikkatiedot helposti ydintietovarantoihin saadaan paikkatiedot tehokkaimmassa muodossaan pois “GIS-siilosta” ja mahdollistetaan samanaikainen datan käyttö sekä myös tehokkaat analyysit. Avoimen lähdekoodin johtava tietokantaympäristö PostgreSQL ja sen paikkatietolaajennos PostGIS ovat tähän erinomainen ratkaisu.
Rikastamalla organisaation sisäisiä tietotuotteita paikkatiedoilla syntyy käyttäjille konkreettinen kokemus siitä, kuinka helppoa nykypäivänä paikkatietojen hyödyntäminen onkaan.
Organisaation ulkopuolinen data, kuten mainitut avoimen datan tuotteet MML:ltä tai ESA:lta, antavat toimialasta riippuen aivan uusia mahdollisuuksia yrityksille tai julkishallinnolle.
Ensin siis puretaan GIS-linnakkeet organisaation sisältä, sitten tuodaan data pois siiloista ja lopuksi yhdistetään se muuhun dataan. Minkälaisia palveluita me Gispossa siten tarjoamme näiden ongelmien ratkomiseen? Olemme asiakkaidemme apuna niin strategisella kuin teknisellä tasolla. Toimitamme paikkatietokoulutuksia myös laaja-alaisesti ihan aloittelijoista paikkatiedon erityisasiantuntijan työtehtäviin asti.