selvitystyÖ: massiivisten pistepilviaineistojen ......m ä ä r ä n p ä äa s ia s s a ilm a sta...
TRANSCRIPT
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