SELVITYSTYÖ:  

MASSIIVISTEN PISTEPILVIAINEISTOJEN HALLINTA  

JAKELUN NÄKÖKULMASTA 

 

Laatinut: 

Jonne Davidsson 

3point Oy 

Lapinlahdenkatu 16 

00180 Helsinki 

 

Tilaaja: 

Maanmittauslaitos 

 

 

Laadittu: 01/2019 

 

 

SISÄLLYSLUETTELO 

 

1. Johdanto 3 

2. Maanmittauslaitoksen tarpeet ja käyttökohteet 3 2.1. Yleistä Maanmittauslaitoksen tunnistetuista tarpeista 3 2.2. Pistepilviaineistojen lataaminen 4 2.3. Ladattavan aineiston valinta 5 2.4. Koordinaatti- ja formaattimuunnokset 6 2.5. Laskentapalvelu 8 2.6. Rajapintapalvelut 9 2.7. Pistepilviaineiston vertaaminen 3D-vektoriaineistoon 14 

3. Vertailtavat arkkitehtuurit 16 3.1. Johdanto arkkitehtuureihin 16 3.2. Tiedostopohjainen arkkitehtuuri 17 

3.2.1 Yleistä tiedostopohjaisesta arkkitehtuurista 17 3.2.2 Tiedostopohjaisen arkkitehtuurin komponentit 19 3.2.3 Tiedostopohjaisen arkkitehtuurin toiminnallisuudet 20 

3.3. Tietokanta-avusteinen arkkitehtuuri 23 3.3.1 Yleistä tietokanta-avusteisesta arkkitehtuurista 23 3.3.2 Tietokanta-avusteisen arkkitehtuurin komponentit 24 3.3.3 Tietokanta-avusteisen arkkitehtuurin toiminnallisuudet 25 

3.4. Tietokantapohjainen ratkaisu 25 3.4.1 Yleistä tietokantapohjaisesta arkkitehtuurista 25 3.4.2 Tietokantapohjaisen arkkitehtuurin komponentit 26 3.4.3 Tietokantapohjaisen arkkitehtuurin toiminnallisuudet 27 

4. Ratkaisuvaihtoehtojen nopeuden arviointi 28 4.1. Yleistä nopeuden arvioinnista 28 4.2. Pistepilven tallentaminen 29 4.3. Lukeminen monikulmion alueelta 33 4.4. Koordinaatti- ja formaattimuunnokset 35 4.5. Hakeminen metatietojen perusteella 35 

5. Arkkitehtuurien arviointi 35 5.1. Johdanto arviointiin 35 5.2. Yhtäaikaisten käyttäjien aiheuttama kuormitus 35 

1 

 

5.3. Pistepilvipalveluiden asettamat vaatimukset 36 5.4. Arkkitehtuurien skaalautuvuus 37 5.5. Jatkokehitys 38 5.6. Rajapinnat pistepilvipalveluille 38 5.7. Metatietojen hallinta 39 5.8. Arviointi 39 

6. Yhteenveto 39 

 

   

2 

 

1. Johdanto 

Tämän selvitystyön on tilannut Maanmittauslaitos osana pistepilvien hallintaan ja jakeluun 

liittyvää projektia. Selvitystyön tarkoituksena on helpottaa Maanmittauslaitoksen tulevan 

tarjouskilpailun valmisteluja. Selvitystyön pohjalta Maanmittauslaitokselle muodostuu 

yleiskuva eri arkkitehtuurien hyvistä ja huonoista puolista. Lisäksi selvitystyö toimii apuna, 

kun hankinnan tekninen määrittely tilataan palveluna ja auttaa mahdollisesti teknisen 

määrittelyn toteuttajaa. Erilliset teknistä määritystä tukevat käyttäjätarinat ovat tämän 

selvitystyön ulkopuolella. 

 

Selvitystyössä käydään läpi käyttötapauksia ja tarpeita Maanmittauslaitoksen 

näkökulmasta. Lisäksi työssä vertaillaan ja arvioidaan eri arkkitehtuureja 

Maanmittauslaitoksen tarpeiden näkökulmasta. Arkkitehtuurit on valittu siten, että niillä 

on mahdollista täyttää Maanmittauslaitoksen tarpeet. Jokaisessa arkkitehtuurissa on 

omat hyvät ja huonot puolensa toteutuksen eri vaiheissa, aloituksesta jatkokehitykseen 

ja ylläpitoon. 

2. Maanmittauslaitoksen tarpeet ja käyttökohteet 

2.1. Yleistä Maanmittauslaitoksen tunnistetuista tarpeista 

Maanmittauslaitos tulee alkuvaiheessa kehittämään pistepilvipalveluita ensisijaisesti 

tässä kappaleessa esitettyihin tarpeisiin. Maanmittauslaitos tuottaa vuosittain suuren 

määrän pääasiassa ilmasta käsin kerättyä laserkeilausaineistoa. Ensimmäinen koko maan 

kattava laserkeilausaineisto saadaan viimeisiltä puuttuvilta osin täydennettyä 2019. 

Ensimmäisen, koko maan kattavan, laserkeilausaineiston pistetiheys on noin puoli (0.5) 

pistettä neliömetrillä. Uudessa 2020 alkavassa, koko maan kattavassa, 1

1 "Laser2020 | Kansallinen maastotietokanta." Accessed December 10, 2018. http://kmtk.paikkatietoalusta.fi/projektit-ja-tyopaketit/laser2020. 

3 

 

laserkeilaushankkeessa määritetään pistetiheydeksi noin viisi (5 ) pistettä neliömetrille. 2

Pistepilviaineiston määrä tulee kasvamaan siten vähintään kymmenkertaiseksi edellisestä 

monivuotisesta hankkeesta. Tavoitteena on kerätä koko Suomen kattava aineisto kuuden 

vuoden kierrolla, siten, että aineistoa kertyy vuositasolla tasaisesti. Aineistomäärän voi 

olettaa kasvavan jälleen seuraavalla syklillä, kun uusi sukupolvi laserkeilaimia on 

käytössä ja pistetiheydet kasvavat entisestään. 

 

Maanmittauslaitoksen tavoitteena on saavuttaa suurin mahdollinen hyöty kertaalleen 

kerätystä, mutta monikäyttöisestä pistepilviaineistosta. Pistepilviaineiston hyödyt 

saavutetaan parhaiten silloin, kun aineisto on helposti saatavilla. Helppo saatavuus 

tarkoittaa tässä yhteydessä muun muassa aineiston lataamista tietyltä alueelta, tietyssä 

tiedostomuodossa ja oikeassa koordinaatistossa. Jotta pistepilviaineisto olisi helposti 

saatavilla eri käyttökohteisiin ja -sovelluksiin, tulee aineiston olla indeksoituna sijainnin ja 

muiden metatietojen osalta. Indeksoinnin lisäksi aineistoon tulee olla helppo pääsy 

esimerkiksi rajapintojen kautta. 

 

Tämä kappale on jaettu konkreettisten käyttöesimerkkien kautta omiin osioihin. Osiot 

etenevät siten, että ne rakentuvat edellisen osion käyttöesimerkin päälle. 

2.2. Pistepilviaineistojen lataaminen 

Ensimmäinen pistepilviaineiston tehokkaamman hyödyntämisen mahdollistava tekijä on 

sen helpompi saatavuus käyttäjän kiinnostuksen kohteena olevalta alueelta. Aineisto 

tulisi olla saatavilla karttalehdittäin ja monikulmion määrittämällä maantieteellisellä 

rajauksella. Aineiston lataaminen karttalehdittäin on mahdollista normalisoida 

monikulmiotapaukseksi, missä karttalehden nurkkapisteet määrittävät monikulmion. 

Karttalehdittäin tapahtuvan aineiston lataamisen voi optimoida riippuen taustalla 

2 "Laser2020 Juha Kareinen - Amazon AWS." Accessed December 10, 2018. https://pta-files-prod.s3.eu-west-1.amazonaws.com/pta-public/attachments/2018/09/Laser2020_GDPR.pdf?7aVmyuQuJmMQZNM8Naux7cTejai8s9cv. 

4 

 

käytetystä arkkitehtuurista. Tässä kappaleessa keskitytään kuitenkin yleistettävissä 

olevaan monikulmiotapaukseen ja sen kuvaamiseen. 

 

Aineistojen lataamiseen liittyvä käyttäjätapaus rakentuu Maanmittauslaitoksen nykyisen 

aineiston latauspalvelun kokemusten päälle. Nykyisellään palvelu mahdollistaa 

karttalehtipohjaisen tiedostolatauksen. Jatkossa tulisi olla mahdollista suorittaa 

aineistolataus käyttäjän vapaasti määrittämän monikulmion sisältä. 

 

Yleisellä tasolla latausprosessi menee siten, että käyttäjän syötteestä palvelimelle 

lähetetään kysely, missä kulkee monikulmiorajauksen lisäksi mahdollisesti myös muuta 

metatietoa ladattavasta aineistosta. Metatieto ladattavasta aineistosta voi olla esimerkiksi 

tiedonkeruun ajankohta. Kun kysely vastaanotetaan palvelimella, koostetaan aineiston 

latausta varten tarvittava, kriteerit täyttävä, pistepilviaineisto valmiiksi paketiksi ja 

käyttäjän päähän palautetaan yksilöllinen latauslinkki. Käyttäjän selain aloittaa tiedoston 

lataamisen automaattisesti, kun latauslinkki on vastaanotettu käyttäjän päässä. Mikäli 

kesken prosessin havaitaan, että aineistoa kertyy niin paljon, että latauslinkkiä ei ole 

mahdollista palauttaa riittävän nopeasti hyvän käyttökokemuksen säilyttämiseksi, 

voidaan linkki toimittaa käyttäjälle sähköpostitse. Vaihtoehtoisesti liian suurien 

aineistojen kysely voidaan estää, jotta säilytetään yhtenäinen tapa toimittaa aineisto 

käyttäjälle. Sähköpostitse toimitettava latauslinkki rajaa muut mahdolliset rajapinnan 

päälle kehitettävät integraatiot pois, kuten esimerkiksi aineiston avaaminen suoraan 

toiseen palveluun tai ohjelmistoon. 

2.3. Ladattavan aineiston valinta 

Aluerajauksen lisäksi on olennaista, että aineiston lataukseen liittyvään kyselyyn voidaan 

liittää muutakin metatietoa, kuten vaikka päivämääräkriteeri. Yleisesti ottaen metatietojen 

avulla pyritään rajaamaan suuresta datamäärästä käyttäjälle olennainen osa. Lisäksi 

metatiedoissa voidaan määrittää koordinaattijärjestelmä ja tiedostomuoto ladattavalle 

aineistolle, eli samalla kyselyllä voidaan vaikuttaa latausta varten muodostettavaan 

5 

 

aineistoon. Samalla voidaan myös määrittää suodattimia, kuten esimerkiksi pistepilven 

luokitteluun perustuva valinta. Luokittelusuodattimien avulla voidaan valita esimerkiksi 

kaikki maanpinnan ja rakennusten kattojen pisteet. Esimerkin tapauksessa jätetään siten 

lataamatta muun muassa kaikki kasvillisuuteen luokitellut pisteet. 

 

Esimerkkejä latauskyselyihin liitettävistä metatiedoista: 

- Pistetiheys minimi/maksimi 

- Keräyspäivämäärä minimi/maksimi 

- Sensori 

- Koordinaattijärjestelmä 

- Tiedostomuoto 

- Luokittelu 

 

Olennaiset metatiedot saadaan määritettyä tämän selvityksen ulkopuolella laadittavista 

käyttäjätarinoista. Lisäksi Maanmittauslaitos kerää jo nykyisellään kattavasti metatietoja 

tuotetuista aineistoista. 

2.4. Koordinaatti- ja formaattimuunnokset 

Käyttäjälle on tärkeää, että tiedostot saadaan ladattua oikeassa koordinaatistossa ja 

käyttötarkoitukseen sopivassa tiedostomuodossa. 

 

Maanmittauslaitoksen käyttötapauksissa yleisimmin käytössä olevat 

koordinaattijärjestelmät ovat ETRS-TM35FIN (EPSG:3067 ) ja ETRS-GK[19 ...31 ]FIN 3 4 5

(EPSG:3873-3885) ja korkeusjärjestelmä N2000 . 6

 

3 "ETRS89 / TM35FIN(E,N) - Finland - EPSG:3067 - EPSG.io." Accessed November 30, 2018. https://epsg.io/3067. 4 "ETRS89 / GK19FIN - EPSG:3873 - EPSG.io." Accessed December 10, 2018. https://epsg.io/3873. 5 "ETRS89 / GK31FIN - EPSG:3885 - EPSG.io." Accessed December 10, 2018. https://epsg.io/3885. 6 "Koordinaatti- ja korkeusjärjestelmät | Maanmittauslaitos." Accessed December 10, 2018. https://www.maanmittauslaitos.fi/tutkimus/tutkimustoiminta/tutkimusryhmat/paattyneet-tutkimusryhmat/koordinaattijarjestelmat-ja-0. 

6 

 

Maanmittauslaitoksen pistepilviaineistot käsitellään ETRS-TM35FIN -koordinaatistossa ja 

LAZ -formaatissa. Aineistojen vieminen kuntatasolla osaksi kaupunkisuunnittelua hyötyy 7

mahdollisuudesta ladata aineistot kunnan käyttämässä Gauss-Krüger -kaistassa ja 8

suunnitteluohjelmistoon sopivassa tiedostomuodossa, kuten esimerkiksi tekstimuotoinen 

XYZ. Korkeusjärjestelmän vaihtaminen saattaa olla tarpeen, mutta lähtökohtaisesti se on 

tehtävä Maanmittauslaitoksen palvelun ulkopuolella. Joissain tapauksissa saatetaan vielä 

käyttää vanhentuneita koordinaattijärjestelmiä, kuten esimerkiksi Kansallinen 

kartastokoordinaattijärjestelmä (KKJ ). KKJ:n ja kuntien omien koordinaattijärjestelmien 9

tarkempi käyttäminen edellyttää erityisiä korjausparametrien laskemisia ja on siten 

perusteltavissa, että ne eivät ole osa Maanmittauslaitoksen tarjoamaa palvelua. Samalla 

Maanmittauslaitos edesauttaa siirtymistä uudempiin projektiopohjaisiin 

koordinaatistoihin. 

 

Latauspyynnön mukana tulisi siis kuljettaa tieto halutusta koordinaatistosta ja 

tiedostomuodosta. Samalla, kun palvelimen päässä koostetaan käyttäjän kyselemä 

aineisto voidaan suorittaa koordinaattimuunnokset pisteille ja kirjoittaa ne pyydettyyn 

muotoon.  

 

Yleisimpiä tiedostomuotoja ovat LAS ja LAZ. Näiden lisäksi saattaa olla hyödyllistä lisätä 10

muita tuettuja tiedostomuotoja, mikäli niitä nousee esille tämän selvityksen ulkopuolella 

laadittavissa käyttäjätarinoissa.  

7 "LASzip - free and lossless LiDAR compression — LASzip 3.2.8 ...." Accessed January 8, 2019. https://laszip.org/. 8 "Gauss–Krüger coordinate system - Wikipedia." Accessed December 16, 2018. https://en.wikipedia.org/wiki/Gauss%E2%80%93Kr%C3%BCger_coordinate_system. 9 "KKJ / Finland Uniform Coordinate System - EPSG:2393 - EPSG.io." Accessed December 10, 2018. https://epsg.io/2393. 10 "LASer (LAS) File Format Exchange Activities – ASPRS." Accessed December 10, 2018. https://www.asprs.org/Committee-General/LASer-LAS-File-Format-Exchange-Activities.html. 

7 

 

2.5. Laskentapalvelu 

Koordinaatti- ja tiedostomuunnosten lisäksi olisi hyödyllistä, että pistepilviaineistosta saisi 

kyseltyä erilaisia laskennallisia tuotteita. Yksinkertaisimmillaan käyttäjälle voitaisiin 

palauttaa esimerkiksi maanpinnan pisteistä muodostettu korkeusmalli  11

rasterimuotoisena, tai pintamalli kolmioverkkona . Esimerkiksi rasterimuotoisen 12

korkeusmallin saa auki paikkatieto-ohjelmistossa ja sen avulla voidaan tehdä vaikka 13 14

automaattista tulvakartoitusta käyttäjän toimesta. 

 

Laskentapalvelun avulla helpotetaan pistepilviaineistojen laajempaa käyttöönottoa 

tuomalla valikoima perustuotteita lähemmäksi eri tutkimus- ja teollisuudenaloja. 

Perustuotteiden avulla lähtöaineisto saadaan yleistettyä palvelemaan entistä laajempaa 

käyttäjäkuntaa. Käyttäjät pystyvät näin ollen keskittymään enemmän oman osaamisensa 

hyödyntämiseen rakentamalla kehittyneempiä analyyseja ja rutiineja perustuotteiden 

päälle. Perustuotteet tulisi olla tarjolla ensisijaisesti rajapintojen kautta. Tämä 

mahdollistaa perustuotteiden tuomisen osaksi eri sovelluksia, kuten esimerkiksi 

tiedostopalvelua. Lisäksi käyttäjien on mahdollista tehdä tiiviimpiä integraatioita omiin 

sovelluksiin hyödyntämällä rajapintoja. 

 

Esimerkkejä laskentapalvelun mahdollisista tuotteista: 

- Korkeusmalli XYZ - tai GeoTIFF -muodoissa 15 16

- Puuston korkeusmalli   17

 

11 "Digital elevation model - Wikipedia." https://en.wikipedia.org/wiki/Digital_elevation_model. Accessed 10 Dec. 2018. 12 "Triangulated irregular network - Wikipedia." https://en.wikipedia.org/wiki/Triangulated_irregular_network. Accessed 10 Dec. 2018. 13 "Welcome to the QGIS project!." Accessed December 16, 2018. https://qgis.org/. 14 "ArcMap | ArcGIS Desktop." Accessed December 16, 2018. http://desktop.arcgis.com/en/arcmap/. 15 "ASCII Gridded XYZ - GDAL." Accessed December 10, 2018. https://www.gdal.org/frmt_xyz.html. 16 "GTiff -- GeoTIFF File Format - GDAL." Accessed December 10, 2018. https://www.gdal.org/frmt_gtiff.html. 17 "What is a CHM, DSM and DTM? About Gridded, Raster LiDAR Data ...." Accessed December 10, 2018. https://www.neonscience.org/chm-dsm-dtm-gridded-lidar-data. 

8 

 

Kantavana ajatuksena laskentapalvelussa on, että tuotteet pystytään generoimaan 

luokitellusta pistepilviaineistosta kyselykohtaisesti ilman erillisiä esilaskentavaiheita. 

Esilaskentavaiheiden vähentyessä tai poistuessa kokonaan säästetään levytilaa, sillä 

kaikkia tuotteita ei tarvitse säilyttää levyillä. Jonkinlainen kevyt välimuistiratkaisu voi tulla 

kyseeseen, jolloin aktiivisimmat alueet pystytään tarjoilemaan nopeammin. Lisäksi, 

aineistopäivitykset ovat helpompia, kun voidaan päivittää ainoastaan laskentapalvelun 

lähtödata. 

 

Laskentapalvelun kautta tarjottavien tuotteiden perustaso määrittyy tämän selvityksen 

ulkopuolella. 

2.6. Rajapintapalvelut 

Rajapintapalveluilla katetaan kaikki tässä kappaleessa aiemmin esitetyt käyttökohteet. 

Rajapintapalveluiden ensisijainen tehtävä on tarjota ohjelmallinen pääsy aineisto- ja 

laskentapalveluun. Rajapinnat tulisi tarjota OGC :n ( Open Geospatial Consortium) 18

standardien mukaisesti.  

 

Latauspalvelun osalta pistepilviaineisto tulisi olla saatavilla WCS :n (Web Coverage 19

Service) yli, sillä kyseinen rajapintastandardi mahdollistaa pääsyn moniulotteiseen 

aineistoon. 

 

Laskentapalvelussa voidaan hyödyntää edellä mainittua WCS:ää tai erityisesti laskentaa 

varten laadittua WPS :ää ( Web Processing Service ). WPS mahdollistaa myös 20

laskentatöiden etenemisen seurannan. 

 

18 "Welcome to The Open Geospatial Consortium | OGC." Accessed November 23, 2018. http://www.opengeospatial.org/. 19 "Web Coverage Service | OGC." Accessed December 10, 2018. https://www.opengeospatial.org/standards/wcs. 20 "Web Processing Service | OGC." Accessed December 10, 2018. https://www.opengeospatial.org/standards/wps. 

9 

 

OGC:n standardia noudattavia avoimen lähdekoodin rajapintatoteutuksia löytyy lukuisille 

eri ohjelmointikielille, kuten esimerkiksi Pythonille OWSLib . 21

 

OGC-standardien mukaiset rajapinnat ovat erityisen hyödyllisiä työpöytäohjelmistoissa, 

mutta niitä käytetään myös internet-sovelluksissa, jotka hyödyntävät avoimen 

lähdekoodin kirjastoja, kuten esimerkiksi Leaflet ja OpenLayers . Internet-sovelluksia 22 23

varten on kuitenkin mielekästä tarjota rajapinnat myös sovelluskehittäjille paremmin 

soveltuvassa REST -muodossa. REST-rajapinnat (Representational State Transfer) ovat 24

yleisesti käytettyjä. REST-rajapintojen avulla mahdollistetaan kehittäjille ja sovelluksille 

pääsy alustan eri toiminnallisuuksiin selkokielisillä rajapintaosoitteilla. 

Rajapintojen optimaalisen kattavuuden ja hyödyntämisen saavuttamiseksi olisi 

hyödyllistä, että kyselyt mahdollistetaan OGC:n määrittämien rajapintojen ja 

Maanmittauslaitoksen oman REST-rajapinnan kautta.  

 

Eri rajapintavaihtoehdot pystyvät hyödyntämään samoja taustarutiineja, kunhan 

abstraktiotaso ohjelmistokomponenteille on valittu oikein. Käytännössä taustarutiinit 25

toteutetaan kerran, minkä jälkeen niitä kutsutaan rajapintakomponenteista. 

 

Rajapinnat voidaan ryhmitellä käyttöoikeuksien mukaan ja käyttöä voidaan seurata 

rajapinta-avainten avulla ( eng. API key ). Rajapinta-avainten lisäksi pääsyä voidaan 26

rajoittaa käyttäjäkohtaisella kirjautumisella. Rajapinta-avain tai kirjautumisvaltuus (eng. 

access token ) kuljetetaan kyselyiden otsaketiedoissa ( eng. request headers ). 27 28

21 "GitHub - geopython/OWSLib: OWSLib is a Python package for client ...." Accessed December 14, 2018. https://github.com/geopython/OWSLib. 22 "Leaflet." Accessed December 14, 2018. https://leafletjs.com/. 23 "OpenLayers." Accessed December 14, 2018. https://openlayers.org/. 24 "Representational state transfer - Wikipedia." Accessed December 10, 2018. https://en.wikipedia.org/wiki/Representational_state_transfer. 25 "Abstraction principle (computer programming) - Wikipedia." Accessed December 16, 2018. https://en.wikipedia.org/wiki/Abstraction_principle_(computer_programming). 26 "Application programming interface key - Wikipedia." Accessed December 11, 2018. https://en.wikipedia.org/wiki/Application_programming_interface_key. 27 "Access token - Wikipedia." Accessed December 11, 2018. https://en.wikipedia.org/wiki/Access_token. 28 "List of HTTP header fields - Wikipedia." Accessed December 11, 2018. https://en.wikipedia.org/wiki/List_of_HTTP_header_fields. 

10 

 

 

Alla esitetään esimerkki pistepilviaineistoihin liittyvästä REST-rajapinnasta. Käyttäjän ja 

toimintojen todennukseen ei oteta kantaa esimerkkien puitteissa. Lopullinen rajapinta voi 

myös olla hyvin erilainen. 

 

Ylätason päätepiste (eng. endpoint) rajapinnalle sijaitsee osoitteessa: 

https://api.maanmittauslaitos.fi/v1/ 

Pistepilvien rajapinta sijaitsee osoitteessa: 

https://api.maanmittauslaitos.fi/v1/pointcloud/ 

Pistepilviin liittyvät operaatiot voidaan esittään yleistetysti seuraavasti: 

https://api.maanmittauslaitos.fi/v1/pointcloud/ <action>/<uuid> 

Missä <action> on pistepilviaineistolle suoritettava toiminto ja <uuid> on pistepilven 

yksilöllinen UUID -tunniste (Universally unique identifier ). UUID voi olla esimerkiksi 29

tuotantoaluekohtainen, tai tiedostokohtainen. Riippuen toiminnosta <action> ja/tai <uuid> 

jätetään pois. 

 

REST-rajapintaan tehtävät kyselyt ovat HTTP -standardin mukaisia 30

GET/PUT/POST/DELETE -menetelmiä.  31

 

GET-menetelmää käytetään, kun halutaan lukea rajapinnasta esimerkiksi kaikkien 

pistepilvien aluerajaukset: 

GET https://api.maanmittauslaitos.fi/v1/pointcloud/boundaries 

 

Palautteena saadaan GeoJSON -muotoinen lista pistepilvistä, metatiedoista ja niiden 32

aluerajauksista: 

29 "Universally unique identifier - Wikipedia." Accessed December 12, 2018. https://en.wikipedia.org/wiki/Universally_unique_identifier. 30 "RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 - IETF Tools." Accessed December 12, 2018. https://tools.ietf.org/html/rfc2616. 31 "HTTP/1.1: Method Definitions." Accessed December 12, 2018. https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html. 32 "GeoJSON." Accessed December 12, 2018. http://geojson.org/. 

11 

 

[ 

{ 

"type": "Feature", 

"geometry": { 

"type": "Polygon", 

"coordinates": [ [ 

[24.0, 60.0], 

[24.0, 60.1], 

[24.1, 60.1], 

[24.1, 60.0], 

[24.0, 60.0] 

]] 

}, 

"properties": { 

“uuid”: “7fcde80b-87b3-40fc-b83b-7ec794a0e725”, 

“acquisition_dates”: [ 

“2008-10-05T14:48:00.000Z” 

], 

“average_point_density”: 0.55 

“sensor”: “Leica ALS50-II S/N 058” 

} 

} 

] 

 

Vastaavasti, jos halutaan vain tietyn monikulmion sisälle jäävät pistepilviaineistot 

suoritetaan GET-kysely, missä lähetetään osana kyselyä GeoJSON-muotoinen aluerajaus: 

GET https://api.maanmittauslaitos.fi/v1/pointcloud/inside 

Palautteena saadaan lista GeoJSON-objekteja. 

  

Yleisesti ottaen PUT-kyselyä käytetään, kun halutaan luoda uusi pistepilviaineisto: 

PUT https://api.maanmittauslaitos.fi/v1/pointcloud 

12 

 

Palautteena saadaan JSON -objekti, missä on luotavalle pistepilvelle UUID ja tiedostojen 33

siirto-osoite: 

{ 

“uuid”: “7fcde80b-87b3-40fc-b83b-7ec794a0e725”, 

“upload_endpoint”: 

“https://storage.maanmittauslaitos.fi/v1/pointclouds/7fcde80b-87b3-40fc-b83b-7ec794a0e725?accessToke

n=123456” 

} 

 

Tiedostot siirretään PUT-komennolla valitun kokoisina paketteina (eng. range requests ), 34

kunnes koko tiedosto on siirtynyt. Paketteina tapahtuva siirto on vikasietoinen, sillä se 

mahdollistaa epäonnistuneen paketin uudelleen siirtämisen. 

 

POST-kyselyä käytetään, kun halutaan muokata olemassa olevaa tietuetta, kuten vaikka 

sensoria millä pistepilvi on kerätty: 

POST 

https://api.maanmittauslaitos.fi/v1/pointcloud/meta/7fcde80b-87b3-40fc-b83b-7ec794a0e

725 

Kyselyn rungossa kuljetaan JSON-objekti muokattavista tietueista: 

{ 

“sensor”: “Leica ALS50-II MPiA SN058” 

} 

 

DELETE-kyselyllä poistetaan koko pistepilvi ja siihen liittyvät metatiedot: 

DELETE 

https://api.maanmittauslaitos.fi/v1/pointcloud/7fcde80b-87b3-40fc-b83b-7ec794a0e725 

Palautteena saadaan tieto onnistumisesta: 

{ 

33 "JSON." Accessed December 12, 2018. https://www.json.org/. 34 "HTTP range requests | MDN." Accessed December 12, 2018. https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests. 

13 

 

“success”: true 

} 

 

REST-rajapinta mahdollistaa uusien toiminnallisuuksien viemisen tuotantoon nopealla 

päivitysrytmillä. Samalla pystytään säilyttämään rajapinnan rakenne siten, että ylätason 

rajapinnan alle voidaan tuoda uusia toimintoja. 

 

Tarkempi rajapintojen määrittely on tämän selvitystyön ulkopuolella. 

2.7. Pistepilviaineiston vertaaminen 3D-vektoriaineistoon 

Maanmittauslaitoksen näkökulmasta olennainen yksittäinen käyttökohde selvitystyön 

kirjoitushetkellä on 3D-vektoriaineiston päivittäminen ja tarkistaminen pistepilviaineiston 

pohjalta. Tarve aineistojen väliseen vertailuun liittyy KMTK -hankkeeseen (Kansallinen 35

maastotietokanta ) ensisijaisesti rakennusten näkökulmasta. 

 

Ensimmäisessä vaiheessa vertailu 3D-vektoriaineiston ja pistepilviaineiston välillä 

tehdään visuaalisesti mittaustyökaluja käyttäen. Jatkoa varten olisi hyvä olla valmiudet 

tehdä vertailut ohjelmallisesti, minkä jälkeen tietyt reunaehdot ylittävät havainnot 

varmennetaan vielä visuaalisesti. Reunaehtoja voi olla esimerkiksi vektoriaineiston 

kierron ja siirron suuruus sovitettuna pistepilveen. Lisäksi tutkitaan tilanteet missä kiertoa 

ja siirtoa ei saada ratkaistua ollenkaan. Yleisesti käytetty ja hyvin tunnettu algoritmi 

kahden pistepilviaineiston välillä on nimeltään ICP ( Iterative Closest Point ). ICP:tä 36

voidaan hyödyntää automatisoinnissa, sillä vektorimuotoiset 3D-mallit on palautettavissa 

pisteiksi. 

 

35 "Kansallinen maastotietokanta - Paikkatietoalusta." Accessed November 26, 2018. http://kmtk.paikkatietoalusta.fi/. 36 "Iterative closest point - Wikipedia." Accessed December 13, 2018. https://en.wikipedia.org/wiki/Iterative_closest_point. 

14 

 

Työnkulku visuaalisessa tarkastelussa vaatii sen, että käytössä oleva alusta, eli 

työpöytäohjelmisto, tai web-sovellus kykenee avaamaan 3D-vektoriaineiston, joko 

suoraan tietokannasta, tai rajapinnan yli. Rajapintana voi toimia esimerkiksi OGC:n WFS-T

(Web Feature Service Transactional), tai REST-rajapinta.  37

Vektoriaineiston lisäksi käytössä olevan alustan tulee kyetä lukemaan pistepilviaineistoa, 

joko automaattisesti käyttäjän näkymän sisältä tai erikseen käyttäjän antamalla 

komennolla valitun 3D-kohteen ympäriltä. Rajapintavaihtoehtoina pistepilvien 

dynaamiselle lataamiselle ovat OGC:n WCS, WFS, tai REST. Pistepilvien tapauksessa 

WFS voi osoittautua kuitenkin raskaaksi, sillä siinä kuljetetaan paljon ylimääräistä tietoa, 

mitä ei pisteiden kanssa tarvita. 

 

Kun käyttäjällä on molemmat aineistot näkyvillä, voi käyttäjä hyväksyä 3D-kohteen ilman 

muutoksia, muokata 3D-kohdetta vastaamaan pistepilven määrittämää muotoa ja sijaintia, 

poistaa 3D-kohteen tai luoda kokonaan uuden 3D-kohteen. 

 

Maanmittauslaitoksen rajapintojen näkökulmasta edellä mainitun mukainen kokonaisuus 

vaatii ainakin seuraavat toiminnot: 

- 3D-vektoriaineiston lukeminen maantieteellisen rajauksen sisältä 

- 3D-vektoriaineiston luominen, päivittäminen ja poistaminen 

- Pistipilviaineiston lukeminen maantieteellisen rajauksen sisältä siten, että 

huomioidaan myös muu oleellinen metatieto, kuten esimerkiksi pistepilviaineiston 

tiedonkeruupäivä 

 

Pistepilvien hallintajärjestelmä ja vektoriaineiston hallintajärjestelmä voivat olla toisistaan 

irrallisia. 

 

Rajapintavaihtoehtojen valintaan vaikuttaa Maanmittauslaitoksen valitsema alusta, millä 

3D-vektoriaineistoa ja pistepilviä vertaillaan keskenään. Vektoriaineistolle valinta on 

37 "Web Feature Service - Wikipedia." Accessed December 12, 2018. https://en.wikipedia.org/wiki/Web_Feature_Service. 

15 

 

selkeämpi WFS-T:n ollessa yleinen standardi. Pistepilvien osalta käytettävyys ja latauksen 

tehokkuus riippuu pitkälti siitä, mitä Maanmittauslaitoksen valitsema alusta tukee. 

3. Vertailtavat arkkitehtuurit 

3.1. Johdanto arkkitehtuureihin 

Maanmittauslaitos harkitsee pistepilvipalveluiden toteutusta kolmen eri arkkitehtuurin 

välillä. Vertailtavat arkkitehtuurit ovat tiedostopohjainen, tietokanta-avusteinen ja 

tietokantapohjainen arkkitehtuuri. Kirjoitushetkellä Maanmittauslaitoksen latauspalvelu ja 

sisäinen jakelu noudattavat pitkälti tiedostopohjaista arkkitehtuuria. Rajat eri 

arkkitehtuurien välillä eivät välttämättä ole aina täysin selkeitä, vaan lopullinen malli 

saattaa löytyä myös jostain välimaastosta. 

 

Arkkitehtuurin valintaan vaikuttaa useita tekijöitä ja matka lopulliseen arkkitehtuurin voi 

kulkea toisen arkkitehtuuri kautta. Riippuen valitusta kehitysmenetelmästä voi olla 

järkevää julkaista palvelusta kehitysversio rajatuilla toiminnallisuuksilla, kerätä palautetta 

testikäyttäjiltä ja ottaa palaute huomioon kehitettäessä palvelua eteenpäin. Osana 

tiheämpää kehityssykliä saatetaan välimallin versioissa turvautua yksinkertaisempaan 

arkkitehtuuriin ennen, kuin lopullista arkkitehtuuria päästään testaamaan käyttäjillä. 

 

Valitun arkkitehtuurin tulisi mahdollistaa jatkuva kehitystyö toimittajasta riippumatta. On 

myös realistista olettaa, että valittu arkkitehtuuri tulee muuntumaan vuosien varrella 

tarpeiden kehittyessä johonkin tiettyyn suuntaan. 

 

Yleinen tapa hahmottamaan kokonaisuutta on jakaa kokonaisarkkitehtuuri selain- ja 

palvelinpuoleen (eng. front-end ja back-end ). Riippuen valitusta arkkitehtuurista, 

toteutuksen monimutkaisuuden erot sijoittuvat pääasiasssa palvelinpuolelle, sillä 

selainpuoli on kaikille pitkälti sama. Selainpuolella toimitaan yleisellä tasolla saman 

16 

 

logiikan mukaan ja tehdään samoja tai vastaavanlaisia rajapintakyselyitä palvelinpuolesta 

riippumatta. Tässä kappaleessa tarkastellaan arkkitehtuuria enemmän palvelinpuolen 

näkökulmasta. 

 

Palvelinpuolella olisi hyvä hyödyntää ohjelmistokontteja ( eng. containers ), jolloin uudet 38

aineiston käsittelyrutiinit saadaan vietyä tuotantoon ilman konekohtaista asetusten 

säätämistä. Lisäksi kontit mahdollistavat palvelinten lisäämisen, tai laskentaklusterin 

perustamisen pienemmällä vaivalla. Esimerkki ohjelmistokontit mahdollistavasta 

ohjelmistosta on Docker . 39

3.2. Tiedostopohjainen arkkitehtuuri 

3.2.1 Yleistä tiedostopohjaisesta arkkitehtuurista 

Tiedostopohjaisessa arkkitehtuurissa pistepilviaineistot ja metatiedot tulisi olla 

tallennettuna avoimissa tiedostomuodoissa. Pistepilviaineistoille avoin ja hyvin 

pakkautuva tiedostomuoto on LAZ . Metatiedoissa voidaan hyödyntää monia 40 41

vaihtoehtoja, kuten XML tai JSON. Ottaen huomioon nykyisten päätelaitteiden 42

laskentatehon ja hyvän JavaScript -tuen, on luontevaa hyödyntää tässä tapauksessa 43

JSON-muotoista metatietoa, minkä saa luettua suoraan JavaScript-objektiksi. JSON on 

myös hyvin tuettu muissa ohjelmointikielissä ja ympäristöissä, kuten esimerkiksi Node.js44

, Python ja Go . 45 46

 

38 "Operating-system-level virtualization - Wikipedia." Accessed December 16, 2018. https://en.wikipedia.org/wiki/Operating-system-level_virtualization. 39 "Docker." Accessed December 16, 2018. https://www.docker.com/. 40 "hobu/laz-perf - GitHub." Accessed November 23, 2018. https://github.com/hobu/laz-perf. 41 "GitHub - LASzip/LASzip." Accessed November 23, 2018. https://github.com/LASzip/LASzip. 42 "XML - Wikipedia." Accessed December 13, 2018. https://en.wikipedia.org/wiki/XML. 43 "JavaScript - Wikipedia." Accessed December 13, 2018. https://en.wikipedia.org/wiki/JavaScript. 44 "Node.js." Accessed December 13, 2018. https://nodejs.org/. 45 "Python.org." Accessed December 13, 2018. https://www.python.org/. 46 "The Go Programming Language." Accessed December 13, 2018. https://golang.org/. 

17 

 

Mikäli pistepilviä halutaan visualisoida käyttäjän internet-selaimessa dynaamisesti (eng. 

streaming ) tarvitaan tiedostojen säilytysmuotojen lisäksi indeksoitu tiedosto- ja 47

hakemistorakenne. Pistepilviaineiston sijaintiin perustuvalle indeksoinnille hyviä 

vaihtoehtoja ovat nelipuu - ja oktettipuu -rakenteet. Nelipuun etuna on 48 49

yksinkertaisempi toteutus, sillä pistepilviaineisto indeksoidaan ainoastaan XY-tasossa. 

Nelipuurakenne on samalla rajoittuneempi aineistoissa missä on paljon kerroksia tai 

vaihtelua korkeudessa. Esimerkiksi sisätiloista, tai katutasolta kerättyyn aineistoon 

nelipuu ei ole hyvä vaihtoehto. Oktettipuun etuna on sen soveltuminen useampaan eri 

aineistotyyppiin. Oktettipuun voi mieltää nelipuun 3D-laajennuksena. Oktettipuuhun 

perustuvia avoimia indeksointiratkaisuja on lukuisia, kuten esimerkiksi 3D-tiles , Entwine50

ja Potree . Neli- ja oktettipuuindeksointi mahdollistavat myös dynaamisen LOD51 52 53

-näkymän (Level of detail ) laskennan, jolloin käyttäjän näkymää lähellä olevia pisteitä 

ladataan enemmän ja vastavuoroisesti kauempana olevia pisteitä vähemmän. 

 

Neli- tai oktettipuuindeksointi voidaan myös laskea säilytysmuodossa olevalle datalle, 

jolloin tarvitaan ainoastaan erillinen indeksitiedosto jokaista tiedostoa kohden. Erillinen 

indeksi ei nykyisellään mahdollista suoraan selainkäyttöä, mutta nopeuttaa huomattavasti 

osajoukon hakemista pistepilvitiedostosta.  

 

Laskentatarpeita varten voi olla hyödyllistä käyttää erillistä K-d-puu -tietorakennetta. 54

K-d-puu voidaan muodostaa myös muistissa osana laskentaprosessia. K-d-puun avulla 

voidaan tehdä nopeita lähimmän naapuripisteen -kyselyitä . 55

47 "Data stream - Wikipedia." Accessed December 13, 2018. https://en.wikipedia.org/wiki/Data_stream. 48 "Quadtree - Wikipedia." Accessed December 13, 2018. https://en.wikipedia.org/wiki/Quadtree. 49 "Octree - Wikipedia." Accessed December 13, 2018. https://en.wikipedia.org/wiki/Octree. 50 "GitHub - AnalyticalGraphicsInc/3d-tiles: Specification for streaming ...." Accessed December 13, 2018. https://github.com/AnalyticalGraphicsInc/3d-tiles. 51 "connormanning/entwine - GitHub." Accessed December 13, 2018. https://github.com/connormanning/entwine. 52 "GitHub - potree/potree: WebGL point cloud viewer for large datasets." Accessed December 13, 2018. https://github.com/potree/potree. 53 "Level of detail - Wikipedia." https://en.wikipedia.org/wiki/Level_of_detail. Accessed 23 Jan. 2019. 54 "k-d tree - Wikipedia." Accessed December 13, 2018. https://en.wikipedia.org/wiki/K-d_tree. 55 "k-nearest neighbors algorithm - Wikipedia." Accessed December 13, 2018. https://en.wikipedia.org/wiki/K-nearest_neighbors_algorithm. 

18 

 

3.2.2 Tiedostopohjaisen arkkitehtuurin komponentit 

Tiedostopohjaisessa arkkitehtuurissa päästään nopeasti liikkeelle, mutta suurista 

tietomääristä johtuen eteen tulee nopeasti hidasteita. Tiedostopohjaisen arkkitehtuurin 

hidasteet tulevat vastaan käyttäjä- ja tietomäärien kasvaessa. Esimerkiksi aluerajauksiin 

perustuvat kyselyt vaatisivat hakemistorakenteen läpikäymisen ja aluerajaustiedostojen 

lukemisen ja vertailemisen kyseltävään aluerajaukseen. Kyselyn nopeuttamiseksi 

palvelimelle voidaan kehittää rutiinit, joilla olennainen tieto luetaan muistiin ja pidetään 

ajantasalla. Kyselykohtaiset vertailut suoritetaan siten valmiiksi muistissa oleviin 

aluerajauksiin. Parempi ratkaisu on kuitenkin hyödyntää tiedostopohjaista SQL56

-ratkaisua (Structured Query Language), kuten esimerkiksi SQLite . Tiedostopohjaiseen 57

SQL-kantaan tallennetaan pistepilviin liittyvä metatieto ja hakemistopolut. 

Tiedostopohjaisen tietokannan käyttäminen tiedostopohjaisessa ratkaisussa vie 

kokonaisuutta lähemmäksi myöhemmin tässä kappaleessa esitettävää 

tietokanta-avusteista ratkaisua. Suurin ero tässä on, että erillistä tietokantapalvelinta ei 

tarvita. Yksinkertaisimmillaan tietokannan sisällön ylläpitäminen ja kyseleminen ei lisää 

toteutuksen monimutkaisuutta, sillä pidemmän päälle päästään pienemmällä kehitystyön 

määrällä ominaisuuksien lisääntyessä. Tiedostopohjainen SQL-kanta on 

toiminnallisuuksiltaan paljon rajoittuneempi palvelinversioihin verrattuna. Rajoitteet 

liittyvät kuormituksen hallintaan ja edistyneempiin tietokantakyselyihin. 

Tiedostopohjainen SQL-kanta ei myöskään mahdollista muiden palvelimien 

keskustelemista suoraan tietokannan kanssa, jolloin esimerkiksi laskentaklusterin 

toteutuksessa tulee ongelmia vastaan, kun sama tieto ei ole saatavilla, kuin yhdessä 

paikassa. 

 

Mikäli kuitenkin halutaan pysytellä erossa tiedostopohjaisesta SQL-kannasta kokonaan, 

voidaan tukeutua kiinteisiin metatieto- ja hakemistorakenteisiin. Kiinteässä rakenteessa 

ongelmaksi muodostuu nopeasti ylläpidettävyys, varmuuskopiointi ja vikasietoisuus. 

56 "SQL Tutorial - W3Schools." Accessed December 14, 2018. https://www.w3schools.com/sql/. 57 "SQLite." Accessed December 14, 2018. https://www.sqlite.org/. 

19 

 

Suurille aineisto- ja käyttäjämäärille kiinteän rakenteen rajoitteet muodostavat nopeasti 

pullonkauloja, joiden ratkominen voi vaatia monimutkaisia ja häiriöalttiita viritelmiä. 

 

 

Kuva 1: Tiedostopohjaisen arkkitehtuurin komponentit 

 

Tiedostopohjaisen arkkitehtuurin peruskomponentit muodostuvat siis palvelimesta mikä 

tarjoilee rajapinnan ja suorittaa ainakin kevyemmät laskentatehtävät. Kuvassa 1 on 

esitetty tiedostopohjaisen arkkitehtuurin komponentit yleisellä tasolla. Raskaammat 

laskentatehtävät voi olla järkevää hajauttaa useammalle palvelimelle. Lisäksi tarvitaan 

hyvin skaalautuva levyjärjestelmä mihin palvelimella on pääsy. 

3.2.3 Tiedostopohjaisen arkkitehtuurin toiminnallisuudet 

Palvelimen on kyettävä ottamaan isoja latausmääriä vastaan ja tallentamaan tiedostot 

levyjärjestelmälle. Tiedostoille on rakennettava joko neli- tai oktettipuurakenne erilliseen 

tiedostoon. Indeksin ensisijainen funktio on nopeuttaa suorakulmaisen särmiön sisään 

osuvien pisteiden kyselyä. Suorakulmainen särmiö voidaan muodostaa esimerkiksi 

monikulmion nurkkapisteistä. Särmiön nurkkapisteet valitaan siten, että monikulmiosta 

20 

 

lasketaan laatikko mikä sulkee monikulmion sisäänsä. Mikäli kysellään monikulmion 

sisään osuvia pisteitä, voidaan ne suodattaa omana vaiheenaan särmiön sisään osuneista 

pisteistä. Lisäksi saatetaan tarvita erillinen indeksoitu kopio datasta internet-käyttöä 

varten, mikäli toiminnallisuus katsotaan tarpeelliseksi. Hyvänä ratkaisuna indeksoidusta 

kopiosta käy hakemisto- ja tiedostopohjainen oktettipuurakenne. Internet-käyttöön 

sopivan puurakenteen voi myös tarvittaessa laskea tapauskohtaisesti. Pidemmän 

aikavälin tavoitteena oktettipuurakenne voi olla joka tapauksessa hyvä ratkaisu, sillä siinä 

saadaan samalla pistepilviaineisto internet-selaimiin sopivaan muotoon ja nopeat 

sijaintiin perustuvat kyselyt laskentapalveluita varten. Kuvassa 2 on hahmoteltu 

pistepilvitiedostoista erikseen muodostettavia indeksejä ja metatietoja. Kuvan 2 

oktettipuurakenne viittaa internet-käyttöön soveltuvaan tiedosto- ja 

hakemistorakenteeseen. 

 

 

Kuva 2: Tiedostomassasta muodostettavia metatietoja ja indeksoituja rakenteita 

21 

 

 

Palvelimen on siis kyettävä indeksoimaan ja koostamaan dataa kyselykohtaisesti niin 

latauspalvelua, kuin laskentapalvelua varten. Tämän lisäksi pistepilvitiedostoista ja 

metatiedoista on pidettävä kirjaa tiedostopohjaisessa tietokannassa, tai kiinteässä 

tiedostopohjaisessa rakenteessa. Kuvassa 3 on esitetty metatietojen päivitys 

pistepilvitiedostoista.  

 

 

Kuva 3: Metatietojen päivitys 

 

Pääsy tiedostoihin ja sallitut toiminnot rajataan palvelimella käyttäjärooleihin perustuen. 

Käyttäjäkohtaisten roolien lisäksi tarvitaan API-avaimiin perustuva todennus. 

Operaatioista tulee jäädä jälki palvelimen lokitiedostoihin.  

 

22 

 

Latauspalvelua varten koostettu pistepilviaineisto tulee olla ladattavissa eri 

tiedostomuodoissa ja koordinaattijärjestelmissä.  

Laskentapalvelua varten koostetut pistepilvijoukot on kyettävä hajauttamaan 

palvelinklusterin laskettavaksi, minkä jälkeen tulokset tulee olla käyttäjälle ladattavissa eri 

tiedostomuodoissa ja koordinaattijärjestelmissä.  

 

Mikäli lataus- tai laskentakyselyn tuloksena syntyy useita tiedostoja on ne kyettävä 

pakkaamaan ZIP -muotoon ja tuotava saataville yksilöllisen latauslinkin kautta. 58

 

Palvelimen on lisäksi kyettävä täyttämään kappaleessa 2 kuvatut Maanmittauslaitoksen 

tarpeet rajapintojen kautta. 

3.3. Tietokanta-avusteinen arkkitehtuuri 

3.3.1 Yleistä tietokanta-avusteisesta arkkitehtuurista 

Tietokanta-avusteinen arkkitehtuuri on komponenttitasolla hyvin lähellä tiedostopohjaista 

arkkitehtuuria, etenkin vaihtoehdossa missä käytetään tiedostopohjaista SQL-tietokantaa. 

Tietokanta-avusteisella arkkitehtuurilla pystytään kuitenkin suorittamaan useita 

paikkatietokyselyitä suoraan tietokannan puolella, mitkä jouduttaisiin 

tiedostopohjaisesssa SQL:ssä hoitamaan palvelimen puolella. Useissa 

tietokantaohjelmistoissa on mahdollista suorittaa paikkatietokyselyjä muun muassa 

sijaintitietojen ja erityisesti monikulmioiden avulla. Esimerkiksi PostgreSQL:ään on 

saatavilla PostGIS -laajennus, mikä mahdollistaa tehokkaat sijaintiin perustuvat 59

operaatiot. Useissa muissa tietokantaohjelmistoissa paikkatietotuki on sisäänrakennettu 

tai laajennettavissa. Mainittakoon, myös että tiedostopohjaiselle SQLite:lle on saatavilla 

SpatiaLite -paikkatietolaajennus. SpatiaLite on kuitenkin ominaisuuksiltaan 60

58 "Zip (file format) - Wikipedia." Accessed December 15, 2018. https://en.wikipedia.org/wiki/Zip_(file_format). 59 "PostGIS — Spatial and Geographic Objects for PostgreSQL." Accessed December 15, 2018. https://postgis.net/. 60 "SpatiaLite: SpatiaLite." Accessed December 15, 2018. https://www.gaia-gis.it/fossil/libspatialite. 

23 

 

rajoittuneempi. Rajoitteet liittyvät pääasiassa monimutkaisempien sijaintiin perustuvien 

kyselyiden suorittamiseen, niin nopeuden, kuin tuettujen toiminnallisuuksien osalta. 

 

Lisäksi, erillinen tietokantapalvelin mahdollistaa pääsyn suoraan tietokantaan eri 

ympäristöistä ja ohjelmistoista. Erillinen tietokantapalvelin myös poistaa kuormaa 

rajapintapalvelimelta. 

 

Tietokanta-avusteisessa mallissa kaikki metatieto ja aluerajaukset tallennetaan 

tietokantaan. Pistepilviaineistot tallennetaan levyjärjestelmään ja niille luodaan samaan 

tapaan indeksit, kuin tiedostopohjaisessa arkkitehtuurissa. Tietokanta-avusteisessa 

arkkitehtuurissa pyritään siihen, että tietokantakyselyillä saadaan rajattua 

rajapintakyselyn täyttämistä varten tarvittavien tiedostojen joukko mahdollisimman 

pieneksi ilman ylimääräistä rajapintapalvelimen ohjelmistologiikkaa. 

 

Palvelimella tehtäviä SQL-kyselyitä ei kannata toteuttaa tietyn SQL-syntaksin mukaan 

suoraan, vaan välissä kannattaa hyödyntää valitusta ohjelmointikielestä riippuen 

SQL-tulkkia. Esimerkiksi NodeJS:lle hyvä valinta on Knex.js ja Pythonille vastaavasti 61

SQLAlchemy . SQL-tulkin käyttäminen mahdollistaa tietokannan vaihtamisen esimerkiksi 62

tiedostopohjaisesta SQLite:stä palvelinpohjaiseen PostgreSQL :ään ilman, että 63

lähdekoodiin tarvitaan ainakaan suuria muutoksia. 

3.3.2 Tietokanta-avusteisen arkkitehtuurin komponentit 

Tietokanta-avusteisen arkkitehtuurin komponentit ovat samat, kuin tiedostopohjaisessa, 

sillä erotuksella, että tietokantaa ylläpidetään erillisellä palvelimella. Tietokantapalvelin 

voisi olla sama mistä rajapinta tarjoillaan. Oma palvelin tietokannalle antaa kuitenkin 

paremman lähtökohdan skaalautuvuuden, paremman vikasietoisuuden ja ylläpidon 

näkökulmista. Tietokantapalvelin voi toki olla sama missä ylläpidetään muutakin 

61 "Knex.js - A SQL Query Builder for Javascript." Accessed December 14, 2018. http://knexjs.org/. 62 "SQLAlchemy." Accessed December 14, 2018. https://www.sqlalchemy.org/. 63 "PostgreSQL." Accessed December 14, 2018. https://www.postgresql.org/. 

24 

 

Maanmittauslaitoksen paikkatietoaineistoa. Kuvassa 4 on esitetty tietokanta-avusteisen 

ratkaisun komponentit yleisellä tasolla. 

 

 

Kuva 4: Tietokanta-avusteinen arkkitehtuuri 

3.3.3 Tietokanta-avusteisen arkkitehtuurin toiminnallisuudet 

Tietokanta-avusteisen arkkitehtuurin komponenttien vaaditut toiminnallisuudet ovat hyvin 

pitkälti samat, kuin tiedostopohjaisessa arkkitehtuurissa, sillä erotuksella, että suurempi 

osa rajapintakyselyiden tarvitsemasta ohjelmistologiikasta hoidetaan SQL-tulkilla tai 

suoraan SQL-kielellä. 

3.4. Tietokantapohjainen ratkaisu 

3.4.1 Yleistä tietokantapohjaisesta arkkitehtuurista 

Tietokantapohjaisessa arkkitehtuurissa myös pistepilviaineisto tallennetaan tietokantaan. 

Suurien pistepilviaineistojen tallentaminen tietokantaan vaatii tietokantaohjelmistolta 

25 

 

erikseen tuen pistepilville. Pelkkä tuki pistemäisille kohteille tai koordinaateille ei riitä 

massiivisten pistepilviaineistojen tapauksessa. Esimerkiksi PostgreSQL:n laajennus 

pgpointcloud tai Oracle :n Point Clouds mahdollistavat pistepilviaineistojen 64 65 66

tallentamisen aluemaisina ja tietokantaohjelmisto huolehtii alueen sisäisestä 

indeksoinnista. 

 

Siinä, missä tiedostopohjaisessa ja tietokanta-avusteisessa arkkitehtuurissa selvitetään 

ensin aluerajauksen sisään osuvat pistepilvitiedostot ja muodostetaan niistä pisteiden 

osajoukko, saadaan tietokantapohjaisessa arkkitehtuurissa suoraan aluerajauksen sisään 

jäävät pisteet kyselyn tuloksena. 

 

Tietomäärät ja kyselyiden palautteena saatavien pisteiden lukumäärät asettavat omat 

tehovaatimuksensa tietokantapohjaiselle arkkitehtuurille.  

 

Latauspalvelun toiminnallisuuksien näkökulmasta tietokantapohjainen arkkitehtuuri 

täyttää tarpeet suoraan tietokannan puolella koordinaatistomuunnoksineen. Jotkin 

tiedostomuodot saattavat vaatia muunnoksen, ellei lukua ja muunnoksia putkiteta siihen 

soveltuvalla ohjelmalla, kuten esimerkiksi PDAL . Laskentapalvelu kuitenkin vaatii 67

pisteiden hakemista väliaikaiseen levytilaan ja samojen laskentarutiinien ajamisen, kuin 

mitä tiedosto- ja tietokanta-avusteisessa arkkitehtuurissa olisi tarpeen. 

3.4.2 Tietokantapohjaisen arkkitehtuurin komponentit 

Tietokantapohjaisen arkkitehtuurin komponentit ovat identtiset tietokanta-avusteisen 

arkkitehtuurin kanssa. Tietokantapohjaisessa ratkaisussa pistepilviaineisto tallennetaan 

sekä levyjärjestelmään, että tietokantaan. Pelkkään tietokantaan tallentaminen ei riitä, 

64 "GitHub - pgpointcloud/pointcloud: A PostgreSQL extension for storing ...." Accessed December 16, 2018. https://github.com/pgpointcloud/pointcloud. 65 "Database - Oracle." Accessed December 16, 2018. https://www.oracle.com/database/. 66 "SDO_PC_PKG Package (Point Clouds) - Oracle Docs." Accessed December 16, 2018. https://docs.oracle.com/cd/B28359_01/appdev.111/b28400/sdo_pc_pkg_ref.htm. 67 "PDAL - Point Data Abstraction Library ...." Accessed December 16, 2018. https://pdal.io/. 

26 

 

sillä lähtöaineisto tulee olla tallella joka tapauksessa. Kyselyt kuitenkin suoritetaan 

tietokantaan tallennetuille pisteille siten, että tarvittavat operaatiot, kuten eri aineistojen 

yhdistämiset suoritetaan tietokannan puolella vaatien näin ollen vähemmän 

ohjelmistologiikkaa palvelinpuolella. Kuvassa 5 on esitetty tietokantapohjaisen 

arkkitehtuurin rakenne. 

 

 

Kuva 5: Tietokantapohjainen arkkitehtuuri 

3.4.3 Tietokantapohjaisen arkkitehtuurin toiminnallisuudet 

Komponenttien toiminnallisuudet ovat pitkälti samat, kuin tietokanta-avusteisessa sillä 

erotuksella, että osa tiedostopohjaisista operaatioista pystytään hoitamaan suoraan 

tietokannan puolella. Tietokantapalvelimen levytilan on oltava myös helposti 

skaalattavissa, mikäli aiotaan tallentaa teratavuja pistepilviaineistoa yhteen tietokantaan. 

 

Tietokantapohjaisessa arkkitehtuurissa tarvitaan samat toiminnallisuudet käsitellä 

tiedostotasolla aineistoja, kuin tietokanta-avusteisessa ja tiedostopohjaisessa 

arkkitehtuurissa. Suurien alueiden ajaminen laskentaprosessien läpi tuskin onnistuu 

27 

 

pelkän keskusmuistin varassa ja siinä samalla menetettäisiin hyödyt mahdollisesta 

laskennan hajauttamisesta erilliselle klusterille. 

4. Ratkaisuvaihtoehtojen nopeuden arviointi 

4.1. Yleistä nopeuden arvioinnista 

Arkkitehtuurivaihtoehtojen välisiä eroja arvioitaessa on syytä kiinnittää huomiota eri 

prosessien nopeuseroihin arkkitehtuurien välillä (eng. benchmarking ). Nopeuseroilla 68

tarkoitetaan saman toiminnallisuuden suorittamista eri arkkitehtuureilla. Tässä 

kappaleessa prosessien nopeutta arvioidaan kirjallisuuslähteisiin nojautuen. 

 

Eroja arvioidaan yleistämällä tiedostopohjainen ja tietokanta-avusteinen yhdeksi 

tapaukseksi. Yleistys on mahdollinen tässä tapauksessa, sillä kumpikin, 

tiedostopohjainen ja tietokanta-avusteinen arkkitehtuuri, nojaavat samoihin 

ohjelmistokomponentteihin toteutuksessaan. Tiedostopohjaisessa ja 

tietokanta-avusteisessa arkkitehtuurissa yhteiset ohjelmistokomponentit liittyvät 

tiedostojen lukemiseen ja kirjoittamiseen. Tässä kappaleessa verrataan siis yleistettynä 

tiedostopohjaista ja tietokantapohjaista arkkitehtuuria. 

 

Tietokantapohjaisessa arkkitehtuurissa pisteet on mahdollista tallentaa litteästi (eng. flat 69

model ) tai alueittain (eng. block model). Litteässä mallissa jokainen piste tallennetaan 70

omana tietonaan tietokantaan. Tämän selvityksen puitteissa tarkastellaan litteää mallia 

tehokkaampaa aluepohjaista mallia. Aluepohjaisessa mallissa pisteet tallennetaan 

68 "Benchmark (computing) - Wikipedia." https://en.wikipedia.org/wiki/Benchmark_(computing). Accessed 3 Jan. 2019. 69 "(PDF) Massive point cloud data management: Design, implementation ...." Accessed January 4, 2019. https://www.researchgate.net/publication/272373258_Massive_point_cloud_data_management_Design_implementation_and_execution_of_a_point_cloud_benchmark. 70 "(PDF) Massive point cloud data management: Design, implementation ...." Accessed January 4, 2019. https://www.researchgate.net/publication/272373258_Massive_point_cloud_data_management_Design_implementation_and_execution_of_a_point_cloud_benchmark. 

28 

 

ryhmittäin. Ryhmän sisällä olevien pisteiden tulee kuitenkin olla homogeenisia. Ryhmän 

pistemäärä asettuu satojen pisteiden suuruusluokkaan. Siten myös aluepohjaisessa 

mallissa tietokantaan tulee rivejä huomattava määrä koko maan kattavan aineiston 

tapauksessa. Tietokanta indeksoi jokaisen ryhmän ulkoiset ulottuvuudet ja pitää kirjaa 

sisäisestä rakenteesta. Tällä tavoin tietokantaan tallennettava tieto on lähellä 

rasteripohjaista lähestymistä. 71

 

Tämän kappaleen tulokset pohjautuvat Hollannissa tehtyyn tutkimukseen “Massive point 

cloud data management: Design, implementation and execution of a point cloud 

benchmark” . Tutkimuksessa vertailtiin useita eri tietokantavaihtoehtoja. Tähän 72

selvitystyöhön valittiin tutkimuksesta vertailun nopein aluepohjainen 

tietokantavaihtoehto. Vertailuvaihtoehdoista valittiin pistemäärältään lähimpänä 

Maanmittauslaitoksen käyttötapausta olevat 210 miljoonan ja 2201 miljoonan pisteen 

versiot.  

 

Tutkimuksessa suoritetut testit on myös mahdollista suorittaa omalla pistepilviaineistolla 

hyödyntämällä tutkimusryhmän julkaisemaa avoimen lähdekoodin kirjastoa . 73

4.2. Pistepilven tallentaminen 

Pistepilven tallentamisen päämääränä on saada aineisto sellaiseen muotoon, että siitä on 

mahdollista irrottaa nopeasti pienempiä osia. Pienempien osien irrottaminen edellyttää 

pisteiden sijaintiin perustuvaa indeksointia .  74

 

71 "Chapter 1 Raster Databases - Semantic Scholar." Accessed January 4, 2019. https://pdfs.semanticscholar.org/47b3/4f095557761f688690d7f1be0c3a673422e7.pdf. 72 "(PDF) Massive point cloud data management: Design, implementation ...." Accessed January 4, 2019. https://www.researchgate.net/publication/272373258_Massive_point_cloud_data_management_Design_implementation_and_execution_of_a_point_cloud_benchmark. 73 "GitHub - NLeSC/pointcloud-benchmark." Accessed January 4, 2019. https://github.com/NLeSC/pointcloud-benchmark. 74 "Spatial database - Wikipedia." Accessed January 4, 2019. https://en.wikipedia.org/wiki/Spatial_database. 

29 

 

Tiedostopohjaisessa arkkitehtuurissa suurempi joukko pienempiä tiedostoja voidaan 

järjestää ja koostaa yhdeksi isommaksi tiedostoksi esimerkiksi tiedonkeruuajankohdan 75

ja sensorin mukaan. Kyseiselle koostetulle tiedostolle lasketaan lopuksi esimerkiksi 

nelipuupohjainen indeksointi. Myös karttalehtipohjainen tiedostorakenne voidaan 

indeksoida vastaavalla tavalla. 

 

Tietokantapohjaisessa arkkitehtuurissa tietokantaan tallennetaan pistepilvialueita. 

Riippuen käytetystä tietokantaohjelmistosta tallennettavat alueet muodostetaan jo 

kirjoitusvaiheessa tai tietokanta luo alueet tallennuksen päätteeksi. 

 

Taulukoissa 6 - 9 on esitetty nopeus- ja kokoerot tiedostopohjaisen ja 

tietokantapohjaisen arkkitehtuurin välillä. Tiedostokoot on normalisoitu tutkimuksessa 

käytetystä LAS-muodosta LAZ-muotoon. Pakkaussuhteena LAS:n ja LAZ:n välillä 76

käytettiin suhdetta 8:1. 

 

 

75 "Sorting algorithm - Wikipedia." Accessed January 4, 2019. https://en.wikipedia.org/wiki/Sorting_algorithm. 76 "LASzip: lossless compression of LiDAR data - UNC Computer Science." Accessed January 4, 2019. https://www.cs.unc.edu/~isenburg/lastools/download/laszip.pdf. 

30 

 

 

Kuva 6: Tallentamisen kesto sekunneissa 210 miljoonaa pistettä 

 

Kuva 7: Tallentamisen kesto sekunneissa 2201 miljoonaa pistettä 

31 

 

 

Kuva 8: Tallentamiseen vaadittu kapasiteetti 210 miljoonaa pistettä (Mt) 

 

Kuva 9: Tallentamiseen vaadittu kapasiteetti 2201 miljoonaa pistettä (Mt) 

32 

 

 

 

Kuvista 6 ja 7 voidaan havaita, että tallentaminen tiedostopohjaisessa arkkitehtuurissa on 

huomattavasti nopeampaa pistemäärästä riippumatta. Lisäksi kuvista 8 ja 9 huomioitavaa 

on, että tiedostopohjaisen arkkitehtuurin tallentamiseen vaadittu kapasiteetti on 

pienempi, kuin tietokantapohjaisessa arkkitehtuurissa. 

4.3. Lukeminen monikulmion alueelta 

Lukeminen monikulmion alueelta tapahtuu tiedostopohjaisessa arkkitehtuurissa siten, 

että ensin koostetaan tiedostot, jotka ovat monikulmion alueella ja sen jälkeen 

tiedostoista koostetaan osajoukko pisteistä, jotka ovat monikulmion sisällä. 

 

Tietokantapohjaisessa arkkitehtuurissa monikulmio on osana tietokantakyselyä ja 

tietokanta osaa palauttaa suoraan osajoukon kyselyn täyttävistä pisteistä. 

 

Kuvista 10 ja 11 nähdään, että tiedosto- ja tietokantapohjaisten arkkitehtuurien välillä ei 

ole mainittavaa eroa. Kuvien 10 ja 11 arvoina käytettiin tutkimuksen taulukon neljä 77

kohtaa viisi sen vastatessa parhaiten Maanmittauslaitoksen käyttötapausta. 

 

77 "(PDF) Massive point cloud data management: Design, implementation ...." Accessed January 7, 2019. https://www.researchgate.net/publication/272373258_Massive_point_cloud_data_management_Design_implementation_and_execution_of_a_point_cloud_benchmark. 

33 

 

 

Kuva 10: Kysely monikulmion sisältä, 210 miljoonaa pistettä 

 

Kuva 11: Kysely monikulmion sisältä, 2201 miljoonaa pistettä 

34 

 

4.4. Koordinaatti- ja formaattimuunnokset 

Koordinaatti- ja formaattimuunnoksiin liittyvät nopeuserot eri arkkitehtuurien välillä ovat 

linjassa lukemisen ja kirjoittamisen kanssa. Molemmissa arkkitehtuureissa 

koordinaattimuunnokset pystytään suorittamaan osana luku- tai kirjoitusoperaatiota, 

jolloin niihin kuluva aika pysyy liki samana. Formaattimuunnoksia varten voidaan olettaa 

ajan pysyvän samana, niille formaateille mitkä ovat tuettuja käytetystä arkkitehtuurista 

riippuen. Tuetut formaatit määrittyvät käytetyn tietokantaohjelmiston ja tiedostopohjaisen 

prosessointikomponentin tuettujen tiedostomuotojen perusteella. 

4.5. Hakeminen metatietojen perusteella 

Haku metatietojen perusteella on verrannollinen monikulmiokyselyyn. 

Monikulmiokyselyssä itse monikulmio voidaan mieltää metatietona. Ajallisesti 

tietokantapohjaisen ja tiedostopohjaisen arkkitehtuurin välillä ei ole merkittävää eroa, 

sillä tilanne on miellettävissä lukuoperaatioon. 

5. Arkkitehtuurien arviointi 

5.1. Johdanto arviointiin 

Tässä kappaleessa vertaillaan kolmen eri arkkitehtuurivaihtoehdon välisiä eroja. Eroja 

arvioidaan Maanmittauslaitoksen pistepilvipalvelun toteutuksen, käyttötarpeiden ja 

jatkokehitysmahdollisuuksien näkökulmista.  

5.2. Yhtäaikaisten käyttäjien aiheuttama kuormitus 

Käyttäjien aiheuttama kuormitus ilmenee arkkitehtuurista riippuen eri kohdissa tallennus-, 

lataus- ja laskentapalveluita. 

 

35 

 

Tiedostopohjaisessa ja tietokanta-avusteisessa arkkitehtuurissa suurin kuormitus 

kohdistuu levyjärjestelmälle ja CPU :lle (Central Processing Unit). Tiedostojen 78

tallentamiseen ja lukemiseen ei tarvita suurta määrää keskusmuistia, sillä useimmat 

näihin toimenpiteisiin tarkoitetut ohjelmistot kykenevät lukemaan ja kirjoittamaan piste 

kerrallaan, jolloin koko lähtötiedostoa ei tarvitse lukea muistiin. 

 

Tietokantapohjaisessa arkkitehtuurissa suurin kuorma kohdistuu tietokantapalvelimelle ja 

vaatii enemmän keskusmuistia. Käytettävissä olevaa muistia tarvitaan sen verran, että 

kyselty pistepilvijoukko mahtuu kerrallaan muistiin, mistä se sitten voidaan kirjoittaa 

tiedostoon. Useita samanaikaisia kyselyitä voidaan suorittaa jonossa, jolloin kyselyiden 

yhtäaikainen kuormitus laskee, mutta samalla yksittäisten kyselyiden vaatima aika kasvaa 

ruuhkatilanteissa. 

5.3. Pistepilvipalveluiden asettamat vaatimukset 

Yksi pistepilvipalveluiden käyttötapaus on pistepilviaineiston vertaaminen 

3D-vektoriaineistoon. Vertailu on mahdollista suorittaa tarkasti rajatulta alueelta. 

Tarkasteltava alue voidaan rajata puskuroimalla monikulmiorajaus tarkasteltavan 

3D-rakennusvektorin ympärille. Tällä tavoin toteutettuna muistivaatimukset pysyvät 

maltillisina. 

 

Laskentapalvelun näkökulmasta laajojen alueiden prosessointi saattaa asettaa 

suuremmat tehovaatimukset tietokantapohjaiselle ratkaisulle. Tietokantakyselyitä on 

mahdollista suorittaa myös osakokonaisuuksina, jolloin muistivaatimukset ovat 

pienemmät, mutta toteutuksen monimutkaisuus lisääntyy. Osakokonaisuuksien käsittely 

vie tietokantapohjaista toteutusta lähemmäs tietokanta-avusteista, sillä pistejoukon 

koostaminen tapahtuu tietokannan ulkopuolella. 

 

78 "Central processing unit - Wikipedia." Accessed January 8, 2019. https://en.wikipedia.org/wiki/Central_processing_unit. 

36 

 

Yhteinen komponentti kaikkien arkkitehtuurien välillä liittyy lataus- ja laskentapalveluiden 

osalta käyttäjälle toimitettavaan aineistoon. Aineisto voidaan joutua toimittamaan 

sellaisessa muodossa, joka ei ole tuettu tietokantaohjelmistossa. Kyseisissä tapauksissa 

muunnokset joudutaan tekemään tietokannan ulkopuolella samoilla 

ohjelmistokomponenteilla arkkitehtuurista riippumatta. 

5.4. Arkkitehtuurien skaalautuvuus 

Arkkitehtuurien osalta olennainen kysymys on niiden soveltuvuus muuttuviin 

käyttäjämääriin. Ratkaisun tulisi olla sellainen, että se kykenee hoitamaan ennalta 

arvioidun tasaisen kuormituksen ja mahdolliset ruuhkapiikit. Lisäksi tallennuskapasiteetin 

olisi hyvä olla skaalautuva siten, että kapasiteettia on mahdollista kasvattaa 

aineistomäärän lisääntyessä. 

 

Tiedostopohjaisessa arkkitehtuurissa rajat tulevat nopeiten vastaan, sillä kuormitus 

kasautuu käytännössä yhdelle palvelimelle ja levyjärjestelmälle. Tietokanta-avusteisessa 

osa kuormituksesta kohdistuu tietokantapalvelimelle, osa jakautuu laskentapalvelimelle 

ja osa levyjärjestelmälle. Molemmissa arkkitehtuureissa laskentaa voidaan jakaa 

palvelinklusterille, jolloin skaalautuvuus ja vikasietoisuus paranevat. 

 

Tietokantapohjaisessa ratkaisussa suurin kuormitus kohdistuu tietokantapalvelimelle, 

minkä lisäksi kuormitus jakautuu laskentapalvelimelle, tai -palvelimille ja 

levyjärjestelmälle. 

Tietokantapohjaisessa arkkitehtuurissa menetetään paljon tietokantalähestymisestä 

muuten saatavia hyötyjä, sillä pistepilviaineisto on luonteeltaan hyvin staattista. 

Tietokannat on optimoitu usein suorittamaan transaktioita pelkkien lukuoperaatioiden 79

sijaan. 

 

79 "Database transaction - Wikipedia." https://en.wikipedia.org/wiki/Database_transaction. Accessed 11 Jan. 2019. 

37 

 

Kaikissa arkkitehtuurivaihtoehdoissa hyödyttäisiin nykyaikaisista palvelinratkaisuista, 

missä tehoja, muistia ja kapasiteettia voidaan skaalata tarpeen mukaan. 

5.5. Jatkokehitys 

Arkkitehtuurin ja ohjelmistokomponenttien osalta jatkokehitysmahdollisuudet ovat 

tärkeässä roolissa. Käyttötarpeet kehittyvät ja niitä tulee lisää palvelun käyttäjäkunnan 

laajentuessa. Näihin tarpeisiin olisi hyvä kyetä vastaamaan. 

 

Arkkitehtuurien osalta jatkokehitysmahdollisuuksiin vaikuttaa monta eri tekijää, kuten 

esimerkiksi valitut ohjelmointikielet, sekä käytettävät ohjelmistokomponentit. 

 

Arkkitehtuurien väliset rajat eivät ole aina täysin selviä ja ne saattavat muuttua projektin 

edetessä. Esimerkiksi tietokanta-avusteisesta arkkitehtuurista on mahdollista laajentaa 

eräänlaiseen välimalliin, missä osa pistepilviaineistosta on aktiivisena tietokannassa. 

 

Jatkokehityksen osalta arkkitehtuurien välillä ei ole mainittavia eroja, sillä niistä on 

mahdollista siirtyä toiseen osin tai kokonaan, mikäli se katsotaan tarpeelliseksi jossain 

vaiheessa kehityskaarta. 

5.6. Rajapinnat pistepilvipalveluille 

Rajapintojen osalta taustalla oleva arkkitehtuuri vaikuttaa siihen miten nopeasti 

rajapintakyselyt pystytään täyttämään. Valitusta arkkitehtuurista riippuen käyttäjien 

aiheuttama kuormitus näkyy pidempinä täyttymisaikoina. Vaihtoehdoista kuormitukselle 

alttein arkkitehtuuri on tiedostopohjainen arkkitehtuuri, sillä siinä kuorman jakaminen 

useammalle palvelimelle on hankalampaa. 

38 

 

5.7. Metatietojen hallinta 

Selkeimmän eron metatietojen hallintaan tekee tiedostopohjainen ratkaisu siinä 

tapauksessa, että metatietoja ei tallenneta tiedostopohjaiseen SQL-tietokantaan. 

Tällaisessa tapauksessa metatietoja ylläpidettäisiin erillisissä metatietotiedostoissa. 

Tämänkaltainen lähestyminen ajautuisi nopeasti hallinnan monimutkaisuuteen. 

 

Tietokantapohjaisessa metatietojen hallinnassa kyselyt, lisäykset, päivitykset ja poistot on 

helpompi pitää hallinnassa ohjelmallisesti. Tietokanta-avusteisen ja tietokantapohjaisen 

ratkaisun välillä ei ole mainittavia eroja metatietojen hallinnan suhteen. 

5.8. Arviointi 

Taulukossa 1 on arvioitu eri vaihtoehtojen soveltuvuutta tässä kappaleessa esitettyihin 

kohtiin asteikolla yhdestä viiteen. Lisäksi kullekin arkkitehtuurille on laskettu yhteen 

pisteet. Parhaat yhteispisteet sai tietokanta-avusteinen ja heikoimman tuloksen sai 

tiedostopohjainen arkkitehtuuri. 

 

Kuormitus Pistepilvi- palvelut

Skaalau- tuvuus

Jatko- kehitys

Raja- pinnat

Meta- tiedot Pisteet

Tiedosto- pohjainen 2 1 1 4 2 1 11

Tietokanta- avusteinen 5 4 5 5 4 5 28

Tietokanta- pohjainen 3 4 3 3 4 5 22

Taulukko 1: Arkkitehtuurien soveltuvuus asteikolla 1 - 5. Viisi on paras. 

6. Yhteenveto 

Selvitystyössä käytiin läpi Maanmittauslaitoksen tarpeita ja käyttökohteita 

pistepilvipalveluiden osalta. Käyttökohteet ja tarpeet on tunnistettu sisäisesti 

39 

 

Maanmittauslaitoksen toimesta, sekä Maanmittauslaitoksen laatiman kyselytutkimuksen 

perusteella. Yksi tärkeimmistä käyttökohteista on pistepilviaineiston vertaileminen 

3D-vektoriaineistoon. Jotta vertailu olisi mahdollista tarvitaan siihen soveltuva tekninen 

arkkitehtuuri ja rajapinnat. Rajapintojen olisi hyvä mahdollistaa pääsy pistepilviaineistoihin 

OGC:n standardeja noudattavilla rajapintakyselyillä ja REST-muotoisella rajapinnalla. 

Osana vertailun mahdollistavia rajapintoja tarvitaan taustalle lukuisia 

perustoiminnallisuuksia, kuten aineiston lataaminen ja laskentapalveluita. 

 

Rajapintojen tarjoilemiseen tarvitaan taustalle tehtävään soveltuva arkkitehtuuri. 

Selvitystyössä esiteltiin ja arvioitiin kolmea eri arkkitehtuuria, joista jokainen voisi 

soveltua aineistojen ylläpitoon ja tarjoilemiseen.  

 

Tiedostopohjaisella arkkitehtuurilla pääsee kehityksessä nopeasti eteenpäin, mutta siinä 

tulee nopeasti haasteita vastaan skaalautumisessa ja aineistojen metatietojen 

hallinnassa. Tietokanta-avusteiseen arkkitehtuuriin on helppo siirtyä tiedostopohjaisesta 

ja ne jakavatkin suuren osan komponenteista keskenään. Tietokanta-avusteisessa 

arkkitehtuurissa metatietojen hallinta ja ylläpito on kestävällä ja skaalautuvalla pohjalla. 

Tietokantapohjaisessa arkkitehtuurissa mahdollisimman suuri osa kyselyistä ja 

prosessoinneista pyritään suorittamaan tietokannan puolella, mikä asettaa 

tietokantapalvelimelle kuormitusta. Kyselyiden nopeuden osalta ei ylletä aivan 

tietokanta-avusteisen tasolle, sillä tietokantaohjelmistot on suunniteltu suorittamaan 

transaktioita, eikä pelkkiä lukuoperaatioita. 

 

Käyttäjien aiheuttama kuormitus eri arkkitehtuureissa on hallittavissa, kun resurssit 

kohdennetaan oikein arkkitehtuurille ominaisiin pullonkauloihin. Tiedostopohjaisessa ja 

tietokanta-avusteisessa painotus on laskentapalvelimessa, tai -palvelimissa ja 

levyjärjestelmässä. Tietokantapohjaisessa tarvitaan enemmän resursseja 

tietokantapalvelimelle. 

 

40 

 

Tämän selvitystyön tavoitteena on antaa hyvä yleiskuva eri arkkitehtuureista ja antaa 

siten puolueeton lähtökohta arkkitehtuurin valintaan. Lisäksi selvitystyö voi toimia apuna, 

kun laaditaan teknistä määrittelyä valitun arkkitehtuurin ympärille. 

 

 

41