1. No category

Geneerisen paikkatietov¨alityspalvelimen
kehitt¨aminen
Diplomity¨o
Turun yliopisto
Informaatioteknologian laitos
Ohjelmistotekniikka
Tammikuu 2012
Tapio Aali
Ohjaajat:
Jukka Teuhola
Sami Hyrynsalmi
TURUN YLIOPISTO
Informaatioteknologian laitos
TAPIO A ALI: Geneerisen paikkatietov¨alityspalvelimen kehitt¨aminen
Diplomity¨o, 57 s.
Ohjelmistotekniikka
Tammikuu 2012
Paikkatieto on tietoa kohteista tai ilmi¨oist¨a, joiden sijainti Maan suhteen tunnetaan.
Yksitt¨ainen paikkatietoelementti sis¨alt¨aa¨ tietoa sijainnista ja siihen liittyv¨ast¨a
ominaisuudesta. Useasta toisiinsa jollain tavalla liittyv¨ast¨a paikkatietoelementist¨a
koottua kokonaisuutta kutsutaan paikkatietoaineistoksi. Erilaisia paikkatietoaineistoja on
nyky¨aa¨ n saatavilla Internetist¨a suunnaton m¨aa¨ r¨a lukuisissa eri formaateissa.
Ty¨okalut aineistojen hyv¨aksik¨aytt¨oo¨ n on k¨ayt¨ann¨oss¨a t¨aytynyt aina toteuttaa sovellus- ja
aineistokohtaisesti, sill¨a niiden soveltamiseen ei ole ollut yhten¨aist¨a ratkaisua. Soveltamista
olisi mahdollista yksinkertaistaa ja helpottaa kehitt¨am¨all¨a erityinen geneerinen
paikkatietov¨alityspalvelin, joka toimisi sovittimena aineistojen ja sovelluksen v¨alill¨a.
Toisin sanoen palvelinta voitaisiin k¨aytt¨aa¨ geneerisen¨a paikkatietokerroksena sovelluksissa.
T¨ass¨a tutkielmassa selvitet¨aa¨ n, millainen t¨allainen palvelin voisi olla. Palvelimen
suunnittelu aloitetaan luomalla siit¨a muutamaa kiinte¨aa¨ aineistoa k¨aytt¨av¨a prototyyppi,
josta tehtyjen havaintojen pohjalta aloitetaan geneerisen palvelimen suunnittelu.
Palvelimesta p¨aa¨ dyt¨aa¨ n kehitt¨am¨aa¨ n ty¨okalu, jonka avulla erityyppisi¨a paikkatietoaineistoja
voidaan k¨asitell¨a yhdenmukaisen rajapinnan kautta. Siihen kehitet¨aa¨ n modulaarinen
arkkitehtuuri, jonka avulla aineistoja ja niist¨a haettuja tuloksia voidaan k¨asitell¨a
mahdollisimman vapaasti.
Geneerinen paikkatietov¨alityspalvelin toteutetaan t¨ass¨a ty¨oss¨a siten, ett¨a se tukee
kahta eri aineistotyyppi¨a: WFS:¨aa¨ ja WMS:n metatietoja. T¨am¨an lis¨aksi palvelimeen
toteutetaan joukko operaatioita, joiden avulla aineistoja voidaan k¨asitell¨a halutuilla tavoilla.
Ty¨on lopuksi tarkastellaan valmiin palvelimen k¨aytt¨okelpoisuutta. Sen havaitaan
toteuttavan sille asetetut vaatimukset ja t¨aten olevan k¨aytt¨okelpoinen tietyin
rajoituksin, joista suurimmat seuraavat palvelimen perusideasta. K¨ayt¨ann¨oss¨a geneerinen
l¨ahestymistapa aiheuttaa v¨akisinkin omia rajoituksiaan aineistojen k¨asittelyyn, vaikka
se samaan aikaan laajentaa ja yksinkertaistaa niiden k¨aytt¨oa¨ luomalla yhdenmukaisen
rajapinnan kaikkiin eri aineistoihin.
Asiasanat: Paikkatieto, paikkatietoaineisto, geneerisyys, WFS, WMS
UNIVERSITY OF TURKU
Department of Information Technology
TAPIO A ALI: Developing a Generic Geographic Information Proxy Server
Master of Science in Technology Thesis, 57 p.
Software Engineering
January 2012
Geographic information is information about objects or phenomena that are associated
with a location relative to the surface of the Earth. A geographic information element
contains data about a location and properties related to it. A collection of geographic
information elements that relate in some way is called a geographic information dataset. A
vast number of geographic information datasets are available in several different formats
in the Internet.
Since there has not been a uniform solution for the utilization of the datasets, the
tools for their usage must always have been implemented separately for every application.
The utilization of the datasets could be made simpler and easier by developing a generic
geographic information proxy server that could be used as an adapter between the datasets
and the application. In other words, the server would be a generic geographic information
layer for the application.
In this thesis, we examine how this kind of server would function. The development of
the server is started by creating a prototype that utilizes two datasets selected upfront.
From the operation of the prototype, we observe that the server should be a tool whereby
different types of datasets can be operated via a uniform interface. We decide that it will
be based on a modular architecture that enables us to process datasets and results fetched
from them as freely as possible.
In this study, the generic geographic information server is implemented with a
support for two different dataset types: WFS and WMS metadata. Several different
operations for processing of the datasets are also implemented into the server.
Finally, the usefulness of the proxy is analyzed. We observe that it fulfills the
requirements that we gave it and thus it is useful. However, the generic approach inevitably
causes some limitations to the usage of the datasets while it simplifies and expands their
utilization by creating a uniform interface to all different datasets.
Keywords: Geographic information, geographic information dataset, genericity, WFS,
WMS
Sis¨alt¨o
Ty¨oss¨a k¨aytetyt lyhenteet
ii
1
Johdanto
1
2
Taustaa Museon informaatioportaalista
5
2.1
Rakennusinventoinnin perusk¨asitteet . . . . . . . . . . . . . . . . . . . .
5
2.2
Ohjelmiston kehitys . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3
K¨aytetyt teknologiat . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.4
Alustan tekninen toteutus . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.5
Rakennusinventoinnin tietokantarakenne . . . . . . . . . . . . . . . . . .
18
3
4
Paikkatietov¨alityspalvelimen suunnittelu
22
3.1
Geneerisyys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.2
Palvelimen kehityksen tavoitteet . . . . . . . . . . . . . . . . . . . . . .
24
3.3
Prototyypin suunnittelu . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.4
Prototyypin toteutus . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.5
Kohti geneerisyytt¨a – prototyypin analyysi . . . . . . . . . . . . . . . . .
30
3.6
Tietokanta- ja luokkarakenteen suunnittelua . . . . . . . . . . . . . . . .
32
Paikkatietov¨alityspalvelimen toteutus
35
4.1
J¨arjestelm¨an arkkitehtuuri ja variaatiopisteet . . . . . . . . . . . . . . . .
36
4.2
Tietokantarakenne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
5
6
4.3
Luokkarakenne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.4
Aineistoluokkien toteutus . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.5
Toiminnallisuuksien toteutus . . . . . . . . . . . . . . . . . . . . . . . .
42
4.6
Palvelimen toiminta ja sen k¨aytt¨o . . . . . . . . . . . . . . . . . . . . . .
44
Tulokset ja niiden analyysi
47
5.1
Geneerisyyden toteutuminen . . . . . . . . . . . . . . . . . . . . . . . .
47
5.2
Kehitystavoitteissa onnistuminen . . . . . . . . . . . . . . . . . . . . . .
48
5.3
Toteutuksen ongelmakohtia ja kehityskohteita . . . . . . . . . . . . . . .
49
Yhteenveto
L¨ahteet
51
54
Ty¨oss¨a k¨aytetyt lyhenteet
EPSG, European Petroleum Survey Group
European Petroleum Survey Group oli j¨arjest¨o, joka alkoi yll¨apit¨aa¨ geodeettisten parametrien tietokantaa. Tietokantaan koottiin tiedot eri koordinaattij¨arjestelmist¨a, ja sen avulla
koordinaatteja pystyt¨aa¨ n muuntamaan j¨arjestelm¨ast¨a toiseen. Nyky¨aa¨ n tietokantaa yll¨apit¨aa¨
International Association of Oil & Gas Producers Geomatics Committee, johon EPSG
yhdistettiin vuonna 2005 [1]. Lyhenne EPSG on kuitenkin edelleen k¨ayt¨oss¨a koordinaattij¨arjestelmille annettavissa tunnisteissa, joita kutsutaan EPSG-koodeiksi. Esimerkiksi
GPS-j¨arjestelm¨ass¨a k¨ayt¨oss¨a olevan WGS84-koordinaattij¨arjestelm¨an EPSG-koodi on
EPSG:4326 [2].
EUREF-FIN, European Reference Frame Finland
EUREF-FIN-koordinaatisto on EU:n suositteleman ETRS89 (European Terrestrial Reference System 1989) -koordinaattij¨arjestelm¨an suomalainen toteutus. ETRS89:ss¨a koordinaatit on lukittu Euraasian mannerlaattaan, joten ne eiv¨at muutu mannerlaattojen liikkuessa.
J¨arjestelm¨an koordinaattien yksikk¨o on metri, ja sen EPSG-koodi on 3067. [3]
GIS, Geographical Information Systems (Paikkatietoj¨arjestelm¨a)
Paikkatietoj¨arjestelm¨a on j¨arjestelm¨a paikkatiedon tuottamiseen, hallintaan, analysointiin
tai esitt¨amiseen. Paikkatietoj¨arjestelm¨aa¨ n voi kuulua laitteita, ohjelmistoja, aineistoja ja
ihmisi¨a.
GML, Geography Markup Language
GML:n on OGC:n kehitt¨am¨a paikkatiedon v¨alitt¨amiseen tarkoitettu XML:¨aa¨ n perustuva
kieli. GML mahdollistaa esimerkiksi geometrioiden sek¨a erilaisten paikkatietoelementtien
ja havaintojen v¨alitt¨amisen yhdenmukaisesti. [4]
INSPIRE, Infrastructure for Spatial Information in Europe
INSPIRE-direktiivin tavoitteena on luoda Eurooppaan yhten¨ainen paikkatietoinfrastruktuuri, jossa kansalliset paikkatietoaineistot ja -palvelut yhdistyv¨at. [5]
JHS, julkishallinnon suositus
JHS-j¨arjestelm¨a koostuu suosituksista, jotka koskevat valtion- ja kunnallishallinnon tietohallintoa. Esimerkiksi JHS 158 Paikkatiedon metatiedot m¨aa¨ ritt¨aa¨ , miten paikkatietoon
liittyv¨a metatieto tulisi esitt¨aa¨ Suomen julkisessa hallinnossa. [6]
JSON, JavaScript Object Notation
JSON on kevyt yleisk¨aytt¨oinen formaatti datan esitt¨amiselle. Se on ihmisille helposti luettavaa, ja sen k¨asittely tietokoneella on esimerkiksi XML:¨aa¨ nopeampaa ja yksinkertaisempaa.
JSON perustuu JavaScript-kieleen ja sen ytimen¨a on kaksi rakennetta: j¨arjestetty lista ja
avain-arvo-kokoelma. [7]
OGC, The Open Geospatial Consortium
OGC on vuonna 1994 perustettu kansainv¨alinen vapaaehtoisuusperustainen standardisointij¨arjest¨o, joka kehitt¨aa¨ standardeja muun muassa paikkatietosis¨all¨oille ja palveluille. [8]
PHP, PHP: Hypertext Preprocessor
PHP on alun perin yksinkertaisena skriptikielen¨a kehitetty dynaamisten WWW-sivujen
generointiin tarkoitettu palvelinp¨aa¨ n ohjelmointikieli. Viidennen version my¨ot¨a siihen on
tullut my¨os laaja tuki oliopohjaiselle ohjelmoinnille. [9] T¨ass¨a tutkielmassa k¨aytet¨aa¨ n
ohjelmointikielen¨a PHP:t¨a.
SHP, Esri Shapefile
SHP on Esrin yll¨apit¨am¨a digitaalinen vektoripohjainen tiedostoformaatti paikkatiedon ja
siihen liittyv¨an metatiedon tallentamiseen. [10]
WFS, Web Feature Service
OpenGIS Web Feature Service on OGC:n kehitt¨am¨a rajapinta paikkatietoelementtien v¨alitt¨amiseen alustariippumattomasti. WFS:ss¨a k¨aytet¨aa¨ n GML-kielt¨a. [11]
WMS, Web Map Service
WMS on OGC:n kehitt¨am¨a rajapinta karttakuvien ja niihin liittyv¨an metatiedon tarjoamiseen Internetin yli. [12]
Luku 1
Johdanto
Paikkatiedolla tarkoitetaan tietoa kohteista tai ilmi¨oist¨a, joiden sijainti Maan suhteen
tunnetaan [13]. Paikkatieto voi olla joko inhimillist¨a tai mittaustietoa. Niinp¨a esimerkiksi
sek¨a ”Myn¨am¨aen lukio sijaitsee EUREF-FIN-koordinaattij¨arjestelm¨ass¨a pisteess¨a 226 576,
6 737 422” ett¨a ”Myn¨am¨aen lukio sijaitsee Myn¨am¨aen kirkon vieress¨a” ovat molemmat
paikkatietoa.
Yksitt¨ainen paikkatietoelementti sis¨alt¨aa¨ v¨ahint¨aa¨ n ainakin tiedon sijainnista ja siihen
liittyv¨ast¨a ominaisuudesta. Elementeist¨a koostuvaa kokonaisuutta kutsutaan paikkatietoaineistoksi. Yksitt¨aisen aineiston elementit liittyv¨at yleens¨a toisiinsa esimerkiksi siten, ett¨a
ne sijaitsevat samalla maantieteellisell¨a alueella tai niit¨a yhdist¨aa¨ jokin ominaisuustieto.
Paikkatietoaineistoihin liittyy yleens¨a metatietoa, joka kuvailee aineiston sis¨alt¨oa¨ tai kertoo
siihen liittyvi¨a lis¨atietoja. Tietokonepohjaisten paikkatietoj¨arjestelmien yleistytty¨a my¨os
paikkatietoaineistoilla tarkoitetaan yleens¨a digitaalisessa muodossa olevaa tietoaineistoa.
Internetiss¨a on nyky¨aa¨ n saatavilla suunnaton m¨aa¨ r¨a erilaisia paikkatietoaineistoja.
Niiden toteutusta on pyrkinyt yhdenmukaistamaan vuodesta 1994 toiminut The Open
Geospatial Consortium, joka on kehitt¨anyt erilaisia standardeja protokollia ja malleja paikkatietoaineistojen esitt¨amiseen [8]. Aineistojen rakenteen yhdenmukaisuutta on puolestaan
edist¨anyt Euroopan Unionin vuonna 2007 k¨aytt¨oo¨ nottama INSPIRE-direktiivi, jonka tavoitteena on yhdenmukaistaa EU:n j¨asenvaltioiden paikkatietoinfrastruktuureja. INSPIRE
LUKU 1. JOHDANTO
2
m¨aa¨ ritt¨aa¨ muun muassa, miten paikkatietoaineistojen metatiedot tulisi esitt¨aa¨ ja miten
aineistoihin liittyv¨at palvelut tulisi toteuttaa. [5]
Standardien ja direktiivien my¨ot¨a aineistot ovat nyky¨aa¨ n p¨aa¨ osin saavutettavissa yhten¨aisill¨a menetelmill¨a. Kuitenkaan niiden soveltamiseen ei ole ollut yhten¨aist¨a ratkaisua,
vaan k¨ayt¨ann¨oss¨a ty¨okalut paikkatietoaineistojen hyv¨aksik¨aytt¨oo¨ n eri sovelluksissa on
t¨aytynyt aina toteuttaa erikseen aineistokohtaisesti.
Aineistojen hyv¨aksik¨aytt¨oa¨ olisi mahdollista helpottaa kehitt¨am¨all¨a erityinen paikkatietov¨alityspalvelin, joka toimisi sovittimena aineistojen ja sovelluksen v¨alill¨a. Palvelimeen
olisi tallennettu aineistojen parametreja, ja se osaisi sijaintitiedon avulla hakea tietoa n¨aist¨a
aineistoista. Saadut tulokset palvelin osaisi esitt¨aa¨ loogisina tietokokonaisuuksina, joita
pystytt¨aisiin k¨asittelem¨aa¨ n yhdenmukaisen rajapinnan kautta. T¨all¨oin aineistoista voitaisiin
helposti tuottaa juuri halutun kaltaisessa formaatissa olevia kokonaisuuksia halutussa koordinaattij¨arjestelm¨ass¨a, eik¨a asiakkaan v¨altt¨am¨att¨a tarvitsisi tiet¨aa¨ tarkasti, mist¨a tai mink¨a
tyyppisist¨a aineistoista tietoja tarkkaan ottaen haetaan. Palvelin toimisi siis k¨ayt¨ann¨oss¨a
asiakassovelluksen geneerisen¨a paikkatietokerroksena. Paikkatietov¨alityspalvelimen toiminnan ideaa esitell¨aa¨ n kuvassa 1.1.
T¨ass¨a tutkielmassa selvitet¨aa¨ n, miten t¨allainen paikkatietov¨alityspalvelin kannattaa
toteuttaa. Yksi keskeinen kysymys palvelimen kehityksess¨a on luonnollisesti tietojen
oikeellisuus, eli miten valitaan oikeat aineistot ja miten eri l¨ahteist¨a saatuja tuloksia yhdistell¨aa¨ n j¨arkeviksi kokonaisuuksiksi. Keskeisin kysymys liittyy kuitenkin geneerisyyteen:
miten kannattaa toteuttaa rajapinta, jonka kautta erityyppiset aineistot saadaan esitetty¨a
yhdenmukaisesti. Lis¨aksi palvelin halutaan pit¨aa¨ mahdollisimman helposti laajennettavana,
sill¨a niin uusien aineistotyyppien kuin my¨os uusien aineistoja k¨asittelevien operaatioiden
lis¨aa¨ minen halutaan pit¨aa¨ yksinkertaisena.
Esimerkkin¨a palvelimen k¨ayt¨ost¨a k¨aytet¨aa¨ n t¨ass¨a ty¨oss¨a Museon informaatioportaalia (MIP), joka toimii samalla sek¨a generis¨oinnin l¨aht¨okohtana ett¨a t¨arkeimp¨an¨a sovelluskohteena. MIP on Varsinais-Suomen maakuntamuseolle kehitett¨av¨a selainpohjainen
LUKU 1. JOHDANTO
3
Asiakas
- koordinaatit
- koordinaattijärjestelmä
- muita parametreja
- tulosten formaatti
- tulosten koordinaattijärjestelmä
tulokset loogisina kokonaisuuksina
halutussa formaatissa ja
koordinaatijärjestelmässä
Paikkatietovälityspalvelin
- aineistoille sovitetut koordinaatit
- muut aineistokohtaiset parametrit
tulokset
Eri lähteissä sijaitsevat paikkatietoaineistot
Kuva 1.1: Paikkatietov¨alityspalvelimen toimintaidea.
inventointisovellus. Sen toteutuksesta vastaa Varsinais-Suomen liiton alaisuudessa toimiva
Lounaispaikka, jonka p¨aa¨ tuote on lounaispaikka.fi-osoitteessa toimiva varsinaissuomalaisille ja satakuntalaisille viranomaistahoille tarkoitettu karttapalvelu. MIP:n kehitys aloitettiin
Opetus- ja kulttuuriministeri¨o tuella 2010, ja sen tuotantok¨aytt¨o aloitettiin syksyll¨a 2011.
Sivustosta on tarkoitus kehitt¨aa¨ kattava ty¨okalu kaikenlaisen kulttuuriymp¨arist¨oihin liittyv¨an inventointitiedon tallentamiseen ja esitt¨amiseen; ensimm¨aisess¨a vaiheessa siihen on
kehitetty ty¨okaluja rakennusinventoinnin tarpeisiin [14].
T¨am¨an tutkielman toisessa luvussa k¨ayd¨aa¨ n l¨api projektiin liittyv¨aa¨ taustatietoa. Luvussa esitell¨aa¨ n rakennusinventointia ja sen perusk¨asitteit¨a, Museon informaatioportaalia
ja sen ominaisuuksia sek¨a sivuston teknist¨a toteutusta.
Kolmannessa luvussa k¨asitell¨aa¨ n paikkatietov¨alityspalvelimen suunnitteluprosessia.
Luvussa k¨ayd¨aa¨ n l¨api palvelimelle asetetut tavoitteet ja niist¨a seuraavat vaatimukset. Aluksi eritell¨aa¨ n vaatimuksia ja analysoidaan niit¨a, jonka j¨alkeen suunnitellaan ja toteutetaan
palvelimen prototyyppi MIP:n vaatimuksista tehdyst¨a k¨aytt¨otapauksesta. Seuraavaksi luo-
LUKU 1. JOHDANTO
4
daan yleistys palvelimen toimintaperiaatteista prototyypist¨a tehtyjen havaintojen pohjalta.
Lopuksi luvussa suunnitellaan palvelimen tietokanta- ja luokkarakennetta.
Nelj¨anness¨a luvussa k¨ayd¨aa¨ n l¨api palvelimen toteutusta. Aluksi luvussa k¨ayd¨aa¨ n l¨api
palvelimen tietokanta- ja luokkarakenteet. Lopuksi tutustutaan tarkemmin eri ominaisuuksien, kuten protokollien, toteutuksiin.
Viides luku on yhteenveto. Siin¨a tarkastellaan, auttaako palvelin ongelmaan, jonka
takia sit¨a alettiin kehitt¨aa¨ , vai luoko se uusia ongelmia. Lis¨aksi luvussa tutkitaan, t¨aytt¨aa¨ k¨o
palvelin sille asetetut vaatimukset, ja miten sit¨a voisi parantaa.
Paikkatietov¨alityspalvelin on lisensoitu Creative Commons Nime¨a 3.0 Muokkaamaton -lisenssill¨a1 , ja se on saatavilla osoitteesta https://github.com/tjkaal/
GIProxy.
1
Creative Commons Attribution 3.0 Unported Licence (http://creativecommons.org/
licenses/by/3.0/)
Luku 2
Taustaa Museon informaatioportaalista
Museon informaatioportaalin suunnittelu aloitettiin vuonna 2008. T¨all¨oin tehtiin suunnitelma hankkeesta, jonka tavoitteena oli luoda kulttuuriymp¨arist¨otietokanta, joka olisi suoraan
yhteydess¨a paikkatietoon, yleisiin rakennettua kulttuuriymp¨arist¨oa¨ koskeviin perusrekistereihin, ja johon voisi liitt¨aa¨ suoraan my¨os valokuvat ja muut liitetiedostot. Tavoitteena
oli luoda sovellus, jonka avulla voitaisiin koota Turun maakuntamuseon hajallaan olevat
kulttuuriymp¨arist¨oihin liittyv¨at tiedot samaan paikkaan. [15]
Hankkeelle saatiin rahoitus Opetus- ja kulttuuriministeri¨olt¨a vuoden 2009 lopulla,
ja se k¨aynnistettiin vuoden 2010 aikana. Projektia kehitt¨am¨aa¨ n valittiin Lounaispaikka Turun kaupungin ja Lounaispaikan muiden partnerien v¨alisen yhteisty¨osopimuksen
perusteella [16, 17]. Ensimm¨aisess¨a vaiheessa sovellukseen p¨aa¨ tettiin kehitt¨aa¨ ty¨okalut
rakennusinventoinnin tarpeisiin.
2.1
Rakennusinventoinnin perusk¨asitteet
Rakennusinventoinnissa on tarkoituksena ker¨at¨a tietoja rakennuksista, kiinteist¨oist¨a ja
erilaisista aluekokonaisuuksista. Tyypillisesti tallennetaan tietoja esimerkiksi rakennusten rakennus- ja ymp¨arist¨otyypeist¨a, rakennustavoista, rakennusten ulkoasusta ja niiden
s¨ailyneisyydest¨a. Inventoitaessa rakennuksille ja niiden kiinteist¨oille annetaan my¨os arvo-
LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA
6
tuksia, jotka ohjaavat aluesuunnittelijoita rakennuskannan ja maiseman suojelussa. [18]
Lis¨aksi eri inventointikohteille tehd¨aa¨ n kulttuurihistoriallista arvottamista, jonka tarkoituksena on m¨aa¨ ritt¨aa¨ alueen, kiinteist¨on tai rakennuksen kulttuurihistoriallinen arvo ja
merkitys [19].
Rakennusinventoinnissa keskeisin inventoitava kohde on kiinteist¨o. Kiinteist¨onmuodostamislain mukaan kiinteist¨oll¨a tarkoitetaan maanmuodostuksen yksikk¨oa¨ , joka merkit¨aa¨ n kiinteist¨orekisteriin kiinteist¨on¨a [20]. T¨allaisia yksik¨oit¨a ovat tilat, tontit, yleiset
alueet, valtion mets¨amaat, suojelualueet, lunastusyksik¨ot, yleisiin tarpeisiin erotetut alueet, erilaiset vesij¨at¨ot1 sek¨a yleiset vesialueet [21]. Jokaisella kiinteist¨oll¨a on neliosainen 14-numeroinen kiinteist¨otunnus, joka koostuu kolminumeroisesta kuntanumerosta,
kolminumeroisesta kyl¨an tai kaupunginosan numerosta sek¨a nelinumeroisista ryhm¨a- ja
yksikk¨onumeroista [23].
Tyypillinen rakennusinventoinnissa inventoitava kiinteist¨o on tila tai tontti. Jokaisesta
inventoidusta kiinteist¨ost¨a pyrit¨aa¨ n tallentamaan sen osoite, nimi, p¨aa¨ rakennuksen sijainti,
tietoja sen historiasta ja ymp¨arist¨ost¨a sek¨a rakennusten m¨aa¨ r¨ast¨a. Kiinteist¨oo¨ n voidaan
my¨os merkit¨a sen kulttuurihistorialliset arvot ja antaa arvotus tarpeen mukaan. Lis¨aksi
kiinteist¨on erilaiset kaava- ja muut suojelumerkinn¨at pyrit¨aa¨ n kirjaamaan sen tietoihin.
Kiinteist¨ost¨a ja sen rakennuksista otetaan my¨os kuvia, jotka arkistoidaan muiden inventointitietojen mukana.
Jokaiseen inventoituun kiinteist¨oo¨ n kuuluu yksi tai useampi rakennus tai rakennelma. Jokaisella rakennuksella tai rakennelmalla on rakennustunnus, joka koostuu kiinteist¨otunnuksesta ja kolminumeroisesta juoksevasta rakennusnumerosta [23]. Rakennuksen
inventointitietoihin pyrit¨aa¨ n kirjaamaan esimerkiksi sen sijainti kartalla, rakennustyyppi
(kuten kioski, leikkim¨okki tai talonpoikaistalo), suunnittelijat ja rakentajat, rakennusvuodet
ja rakennusmateriaalit. Lis¨aksi kirjataan tarvittaessa yl¨os tietoja rakennuksen kulttuurihistoriallisesta merkitt¨avyydest¨a, suojelusta sek¨a kuvaus sis¨atiloista ja erityispiirteist¨a.
1
Vesij¨att¨o on entist¨a vesialuetta, joka on pysyv¨asti muuttunut maa-alueeksi vedenpinnan laskun, liettymisen, umpeen kasvamisen tai maanpinnan kohoamisen seurauksena. [22]
LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA
7
Rakennuksella tai rakennelmalla on siis aina kiinteist¨o, johon se kuuluu. Vastaavasti
inventoitu kiinteist¨o kuuluu aina kyl¨aa¨ n tai kaupunginosaan, joka puolestaan kuuluu kuntaan. Kunnilla on inventoinneissa merkityst¨a pelk¨ast¨aa¨ n tilastollisina kohteina, joten niist¨a
tallennetaan vain kuntanumerot sek¨a nimet. Kylist¨a sen sijaan tehd¨aa¨ n alueinventointeja. Alueinventoinneissa koostetaan yhdest¨a tai useammasta kyl¨ast¨a koostuva alue, jolle
annetaan nimi, kuvaus sen historiasta, maisemasta ja nykytilasta. Lis¨aksi alueen sijainti
voidaan tarpeen mukaan antaa joko pisteen¨a tai karttaan piirrett¨av¨an¨a alueena. Alueiden
sis¨all¨a voi sijaita kulttuurihistoriallisesti merkitt¨av¨aksi luettavia arvoalueita, joilla on nimi
ja aluetyyppi sek¨a sijainti pisteen¨a tai alue. Lis¨aksi niille voidaan kiinteist¨ojen tapaan antaa
erilaisia kulttuurihistoriallisia arvoja sek¨a m¨aa¨ ritt¨aa¨ arvotus ja suojelutiedot.
Yhteen kokonaisuuteen kuuluvat inventoinnit kootaan inventointiprojektin alle. Inventointiprojektilla on sen sis¨alt¨oa¨ kuvaava nimi, tarkempi kuvaus, inventointiaika, toimeksiantaja ja tyyppi sek¨a inventoijat. Tyypillinen inventointiprojekti tehd¨aa¨ n jollain
rajauksella jonkin tietyn kunnan alueella. Esimerkiksi Turun Maakuntamuseon Varakum
B -projektissa tehtiin vuonna 2007 Entisen Mietoisten alueen t¨aydennysinventointi, jossa
inventoitiin ennen vuotta 1940 rakennettuja nykyisin Myn¨am¨akeen kuuluvan Mietoisten
kunnan rakennuksia.
2.2
Ohjelmiston kehitys
Kes¨akuussa 2010 Pyry Liukas aloitti Museon informaatioportaalin kehityksen Lounaispaikassa. Aluksi h¨an tutustui vuonna 1998 k¨aytt¨oo¨ notettuun Microsoft Access 97 -pohjaiseen
InveTMM-sovellukseen ja sen tietokantarakenteeseen. Ohjelmistosta ker¨atyn tiedon ja
k¨aytt¨ajien haastattelun perusteella h¨an aloitti MIP:n suunnittelun.
Alusta asti uuden sovelluksen p¨aa¨ tavoitteet olivat selkeit¨a. Yksi olennainen ominaisuus
ohjelmistossa tulisi olemaan joustavuus, sill¨a InveTMM-ohjelmisto oli yli kymmenen
vuoden k¨ayt¨on aikana osoittautunut kankeaksi ja rajoittuneeksi. MIP:sta haluttiin kehitt¨aa¨
LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA
8
helposti muokattava ja moniin k¨aytt¨otarkoituksiin soveltuva. Lis¨aksi MIP:iin haluttiin
luoda j¨arjestelm¨a, jossa voitaisiin inventoitaessa syntynyt tekstidata ja siihen liittyv¨at
paikkatieto, kuvat ja liitetiedostot tallentaa yhteen paikkaan ja esitt¨aa¨ yhdess¨a helposti
ymm¨arrett¨av¨ass¨a n¨akym¨ass¨a: teksti selke¨asti jaoteltuna, paikkatieto karttaikkunassa sek¨a
kuvat ja liitetiedostot selailtavina.
Paperiset tulosteet olivat ainoa tapa jakaa tietoa ulkopuolisille tahoille InveTMM:st¨a.
T¨ah¨an haluttiin parannusta, joten MIP:sta p¨aa¨ tettiin kehitt¨aa¨ WWW-pohjainen ohjelmisto,
johon tulisi mahdollisuus luoda erilaisia k¨aytt¨aj¨atasoja, joille voitaisiin asettaa erilaisia
rajoituksia niin tietojen n¨akyvyyteen kuin my¨os ohjelmiston k¨aytt¨ooikeuksiin. Tietojen
arkistointia ja laadukkaita tulosteita varten MIP:iin haluttiin my¨os mahdollisuus PDFtiedostojen luomiseen.
Sivuston toteutus aloitettiin Lounaispaikassa vuoden 2010 loppupuolella. Ensimm¨aisin¨a kuukausina Pyry Liukas, Tapio Aali ja Heikki Ylitalo kehittiv¨at yhteisty¨oss¨a sivustoa.
Vuoden 2011 helmikuusta sivuston suunnittelusta ja toteutuksesta on vastannut Tapio Aali
yksin¨aa¨ n Pyry Liukkaan satunnaisella avustuksella.
Ensimm¨aiseksi k¨asiteltiin vanhat tietokannat. Vanhoista inventoinneista digitoitu Inventoinnit ennen 1998, InveTMM-ohjelmistolla luotu Inventoinnit 1998–2010, matkaraporttitietokanta Matkaraportit, Turussa tehtyj¨a rakennusinventointeja sis¨alt¨av¨a Turku
MySQL sek¨a porrashuoneinventointeja sis¨alt¨av¨a Porrashuone yhdistettiin yhteen PostgreSQL-tietokantaan omiksi skeemoikseen.
Tammikuussa 2011 kehitettiin geneerinen ty¨okalu, jolla vanhoja tietokantoja p¨aa¨ si selailemaan ja tarvittaessa muokkaamaan suoraan MIP:n omasta k¨aytt¨oliittym¨ast¨a. Ty¨okaluun
kehitettiin my¨os yksinkertainen hakukone, jolla voitiin etsi¨a halutun ilmauksen sis¨alt¨avi¨a
rivej¨a. Lopuksi hakukoneeseen lis¨attiin mahdollisuus rajata haku tiettyihin skeemoihin tai
tauluihin. Tammi-helmikuussa 2011 otettiin k¨aytt¨oo¨ n erillinen kuvapalvelin, johon rakennettiin j¨arjestelm¨a kuvien automaattiseen koon muuttamiseen ja uusien kuvien lis¨aa¨ miseen.
Samalla kehitettiin MIP:n sivustomoottoriin j¨arjestelm¨a, jossa palvelimen kuvatiedostot
LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA
9
voitiin liitt¨aa¨ mihin tahansa tietokannan riviin. My¨ohemmin samaa j¨arjestelm¨aa¨ laajennettiin siten, ett¨a kuvien lis¨aksi sen kautta pystyttiin jakamaan my¨os erilaisia liitetiedostoja.
Seuraavaksi kehitettiin ty¨okalu, joka tutki l¨api Turun maakuntamuseon rakennusinventointien kuva-arkiston. Kuvien metatiedoista etsittiin kiinteist¨o- ja rakennustunnuksia,
joita verrattiin Inventoinnit 1998–2010 -skeeman tietoihin. T¨asm¨anneet kuvat indeksoitiin
palvelimelle kuvausp¨aiv¨am¨aa¨ r¨an mukaan ja linkitettiin vastaavaan riviin.
Viimeisen¨a ty¨ovaiheena ennen uuden tietokantaskeeman k¨aytt¨oo¨ nottoa kehitettiin
prototyyppi MIP:n hyvin keskeisest¨a ominaisuudesta, kiinteist¨oselaimesta (kuva 2.1), joka
vastaa inventoijien aikaisemmin paperille tekem¨aa¨ inventointikorttia. Ty¨okalun tavoitteena
oli tutkia, miten yksitt¨aisen kiinteist¨on tiedot, siihen liitetyt kuvat ja paikkatieto sek¨a
sen rakennukset saadaan esitetty¨a selke¨asti yhdess¨a n¨akym¨ass¨a. K¨ayt¨ann¨oss¨a ty¨okalua
varten piti kehitt¨aa¨ erikseen vain geneerinen kuvapaneeli, joka kykeni hakemaan tiettyyn
tietokannan riviin linkitetyt kuvat ja yksinkertainen karttaikkuna, joka piirsi pohjakartan
p¨aa¨ lle kiinteist¨on karttakohteet pistein¨a. Kiinteist¨on tiedot ja listaus sen rakennuksista
saatiin suoraan aiemmin kehitetyst¨a tietokantaselaimesta.
Kuva 2.1: Kiinteist¨oselaimen prototyyppi.
LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA
10
Helmikuussa 2011 aloitettiin uuden inventointity¨okalun, Rakennusinventoinnit 2011,
tekninen toteutus. Ensimm¨aiseksi tietokantaskeema viimeisteltiin k¨aytt¨oo¨ nottoa varten.
Ty¨ovaiheesta teki erityisen se, ett¨a tietokannan suunnitelmaa oli k¨aytetty portaalin kehityksen esittelyss¨a ohjausryhmiss¨a, joten se oli tehty mahdollisimman helposti luettavaksi.
Niinp¨a ensimm¨aiseksi tietokantaskeema t¨aytyi muuntaa paremmin tekniseen k¨aytt¨oo¨ n
soveltuvaksi. Lis¨aksi entiteettien attribuutit piti tarkistaa ennen uuden tietokannan k¨aytt¨oo¨ nottoa. Viimeistelyprosessia esitell¨aa¨ n kuvassa 2.2.
Alkuperäinen
kunta
kuntanumero Character varying(3)
nimi
Varchar
Lopullinen
kunta
id
Serial
kuntanumero Character varying(3)
nimi
Varchar
NN (PK)
NN
kunnissa_on_kylänosia
kylänosa
kuntanumero Character varying(3)
kylänumero Integer
nimi
Varchar
postinumero Numeric(5,0)
maisema
Text
Text
historia
nykytila
Text
lisätiedot
Text
Text
lähteet
kunnissa_on_kyliä
NN (PFK)
NN (PK)
NN
NN
id
kunta_id
kylänumero
nimi
kiinteistö
Varchar
Character varying(3)
Integer
Integer
Varchar
Varchar
Varchar
Varchar
Varchar
Varchar
geometry
Varchar
kylä
Serial
Integer
Varchar
Varchar
NN (PK)
NN (FK)
NN
NN
kylissä_on_kiinteistöjä
kylänosissa_on_kiinteistöjä
kiinteistötunnus
kuntanumero
kylänumero
kiinteistönumero
nimi
katuosoite
postinumero
paikkakunta
aluetyyppi
historiallinen_tilatyyppi
kiinteistön_sijainti
arvotus
NN (PK)
NN
NN
NN (PK)
NN (FK)
NN (FK)
NN
NN
NN
NN
(AK2)
(AK3)
kiinteistö
id
Serial
NN (PK)
kylä_id
Integer
NN (FK)
kiinteistötunnus
Varchar
nimi
Varchar
osoite
Varchar
postinumero
Varchar
paikkakunta
Varchar
aluetyyppi
Varchar
arvotus
Varchar
historiallinen_tilatyyppi Varchar
lisätiedot
Text
asutushistoria
Text
lähiympäristö
Text
pihapiiri
Text
omistajatiedot
Text
perustelut_yhteenveto Text
lähteet
Text
kiinteistön_sijainti
geometry
Kuva 2.2: Esimerkki viimeistelyst¨a, jota uudelle tietokannalle tehtiin ennen sen k¨aytt¨oo¨ nottoa
kuntien, kylien ja kiinteist¨ojen osalta. Vaikka kunta- ja kyl¨anumerot sek¨a kiinteist¨otunnukset ovat
selke¨asti yksil¨ollisi¨a tunnisteita, ne voivat kuitenkin muuttua esimerkiksi kuntaliitoksissa, joten
kohteet tarvitsevat erillisen identifioivan sarjanumeron. Alkuper¨aisess¨a versiossa esiintyv¨a termi
kyl¨anosa on vanhasta ohjelmistosta periytyv¨a virheellinen k¨asite.
Tietokannan k¨aytt¨oo¨ noton j¨alkeen aloitettiin tietojen sy¨ott¨amisess¨a k¨aytett¨avien lomakkeiden kehitys. T¨ass¨a ty¨ovaiheessa muunnettiin siis periaatteessa tietokannasta kahdeksan
eri entiteetti¨a lomakkeiksi, joita k¨aytet¨aa¨ n rakennusinventoinnissa ker¨att¨avien tietojen tallentamiseen. Erilliset lomakkeet tarvittiin inventointiprojekteille, kunnille ja niiden kylille
LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA
11
tai kaupunginosille, kiinteist¨oille ja niiden rakennuksille sek¨a inventoiduille alueille ja
niiden alla oleville arvoalueille. Sy¨ott¨olomakkeiden j¨alkeen kehitettiin viel¨a ty¨okalut kaikkien kohteiden selailuun, muokkaamiseen ja poistoon. T¨all¨oin saatiin my¨os valmiiksi uusi
kiinteist¨oselain (kuva 2.3), jossa oli kiinnitetty erityist¨a huomiota tekstidatan j¨asentelyyn
ja selke¨aa¨ n esitykseen. Samalla my¨os muille kohdetyypeille tehtiin vastaava n¨akym¨a.
Kuva 2.3: Uusi kiinteist¨oselain.
Huhtikuussa 2011 inventointiskeema saatiin lopulliseen muotoonsa. T¨all¨oin voitiin
aloittaa vanhojen inventointien muunto uuteen j¨arjestelm¨aa¨ n. T¨at¨a operaatiota varten
kehitettiin erillinen skripti, joka haki rivej¨a vanhoista tietokannoista ja sovitti uuteen
sopivaksi.
Kes¨all¨a 2010 aloitettiin sovelluksen testik¨aytt¨o, kun rakennusinventoijat alkoivat sy¨ott¨aa¨
tietoja uusista kohteista MIP:iin. Tuotantok¨aytt¨oo¨ n sivusto otettiin syksyll¨a 2011.
LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA
2.3
12
K¨aytetyt teknologiat
Museon informaatioportaali perustuu kokonaisuudessaan avoimen l¨ahdekoodin teknologioihin. Kaikissa sivuston palvelimissa on k¨aytt¨oj¨arjestelm¨an¨a Ubuntu Server, httppalvelimena k¨aytet¨aa¨ n lighttpd-ohjelmistoa. Tietokantapalvelinohjelmistona k¨aytet¨aa¨ n
PostgreSQL:¨aa¨ , jota on laajennettu paikkatietoaineistojen k¨asittely¨a helpottavalla PostGISlis¨aosalla. Sivuston pohjana on alun perin Lounaispaikkaa varten kehitetty LouGISohjelmisto, josta Museon informaatioportaalia varten karsittiin ominaisuudet, joita MIP:ssa
ei tarvita. T¨am¨an j¨alkeen alustaa on jatkokehitetty MIP:ia varten omassa projektissaan.
Palvelintoteutus on tehty kokonaisuudessaan PHP-kielell¨a. Toteutuksen ytimen muodostaa PHP:t¨a laajentavan PEAR-kirjaston DB DataObject-paketti. Dataolioiden ideana
on generoida tietokannan tauluista luokkia, joiden kanssa voidaan suorittaa kaikenlaisia
tietokantaoperaatioita oliopohjaisesti. Yksinkertaiset operaatiot onnistuvat ilman SQLkomentojen kirjoittamista; esimerkiksi, jos halutaan etsi¨a skeeman rakennusinventointi taulusta kiinteist¨
o rivi, jonka id on 3245 ja vaihtaa sen postinumeroksi
20810, operaatio onnistuu muutamalla funktiokutsulla ja olion ominaisuuksia muuttamalla:
1
2
3
4
5
6
$Kiinteist¨
o = new Rakennusinventointi_2011_kiinteisto();
$Kiinteist¨
o->id = 3245;
$Kiinteist¨
o->find();
$Kiinteist¨
o->fetch();
$Kiinteist¨
o->postinumero = 20810;
$Kiinteist¨
o->update();
My¨os suorien SQL-komentojen ajaminen dataolioiden kautta onnistuu. Alla olevassa esimerkiss¨a haetaan kaikki j¨arjestelm¨an kyl¨at siten, ett¨a kyl¨an nimen j¨alkeen tulee
kyl¨anumero suluissa.
1
2
3
4
5
$query = "SELECT
kyl¨
a.nimi || ’ (’ || kyl¨
a.kyl¨
anumero || ’)’ AS nimi
FROM rakennusinventointi_2011.kyl¨
a AS kyl¨
a ORDER BY kyl¨
a.nimi";
$Kyl¨
a = new Rakennusinventointi_2011_kyla();
$Kyl¨
a->query($query);
Tyypillisesti dataoliot generoidaan etuk¨ateen omiksi tiedostoikseen, mink¨a j¨alkeen
niihin voidaan kirjoittaa taulukohtaisia funktioita. Perinn¨an ansiosta dataolioita pystyy
laajentamaan helposti.
LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA
13
Sivuston k¨aytt¨oliittym¨a on toteutettu Ext JS:ll¨a, joka on JavaScript-kirjasto interaktiivisten www-ohjelmistojen luomiseen. Ext JS:n ideana on luoda HTML-elementeist¨a, kuten
lomakkeen tekstikent¨ast¨a tai napista, erilaisia komponentteja, joita voidaan yhdistell¨a halutulla tavalla erityisiin s¨aili¨otyyppisiin komponentteihin. Valmiina s¨aili¨okomponentteina
Ext JS tarjoaa esimerkiksi paneelin ja ikkunan. [24] MIP:n karttaikkunan k¨aytt¨oliittym¨ass¨a
k¨aytet¨aa¨ n OpenLayers-nimist¨a JavaScript-kirjastoa. Sen luoma karttan¨akym¨a kapseloidaan
Ext JS -yhteensopivaksi komponentiksi GeoExt-kirjaston avulla.
Museon informaatioportaalilla ei t¨all¨a hetkell¨a ole omaa karttapalvelinta. Sivuston
kartat tulevat Lounaispaikan Mapserver-ohjelmistoa k¨aytt¨av¨alt¨a karttapalvelimelta.
2.4
Alustan tekninen toteutus
Museon informaatioportaalin pohjalla olevan LouGIS-moottorin tietokantarakenne esitell¨aa¨ n kuvissa 2.4, 2.5 ja 2.6. Kuvaan 2.4 on koottu tietokantarakenteesta taulut, jotka liittyv¨at k¨aytt¨ajiin, ryhmiin, sessioihin tai k¨aytt¨ooikeuksiin. Sen keskeisin taulu on
k¨aytt¨aj¨atietoja sis¨alt¨av¨a user. K¨aytt¨aj¨an kirjautuessa sis¨aa¨ n sivustolle k¨aynnistet¨aa¨ n sessio, jonka tiedot tallentuvat user session-tauluun.
K¨aytt¨aj¨aryhm¨at ovat taulussa group. Teknisesti olisi mahdollista, ett¨a k¨aytt¨aj¨a voisi kuulua useampaan ryhm¨aa¨ n (group users) tai ryhm¨a toisiin ryhmiin (group subgroup). K¨ayt¨ann¨oss¨a kuitenkin MIP:ssa on t¨all¨a hetkell¨a rajattu selkeyden vuoksi
k¨aytt¨aj¨asysteemi siten, ett¨a k¨aytt¨aj¨a kuuluu tasan yhteen ryhm¨aa¨ n. My¨osk¨aa¨ n ryhmill¨a ei
voi olla aliryhmi¨a.
MIP:n k¨aytt¨ooikeusj¨arjestelm¨a perustuu ryhmille annettaviin oikeuksiin. Taulu
action sis¨alt¨aa¨ erilaisia toimintoja, joihin ryhmill¨a voi olla oikeuksia. Taulussa
action group ovat eri ryhm¨at, joihin toiminto voi kuulua. N¨am¨a yhdistet¨aa¨ n taulussa
group privilege, johon tallennetaan ryhm¨an, toiminnon ja toimintoryhm¨an tunnisteet. Siihen voidaan tallentaa my¨os oikeuden tarkempi kohde, jos oikeus halutaan rajata
LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA
14
users_start_sessions
user
id
Serial
enabled
Boolean
firstname
Varchar
lastname
Varchar
default_email Varchar
password
Varchar
nickname
Varchar
phone
Varchar
mobile
Varchar
www
Varchar
image
Varchar
street1
Varchar
street2
Varchar
zip
Varchar
city
Varchar
session_id
user_id
lifetime
created
updated
ended
ip
hostname
user_agent
session_data
NN (PK) (AK1)
NN
NN
NN
NN
NN
user_session
Serial
Integer
Timestamp with time zone
Timestamp with time zone
Timestamp with time zone
Timestamp with time zone
Varchar
Varchar
Varchar
Text
a_user_belongs_to_groups
group_users
group_id Integer NN (PFK)
user_id Integer NN (PFK)
Boolean NN
admin
action_group
identifier
Varchar NN (PK)
title
Varchar
description Text
groups_have_users
users_create_groups
id
founder_id
accepted
accepted_by
public
confirm_join
system
name
description
NN (PK)
NN (PFK)
admins_accept_groups
group
Serial
Integer
Timestamp with time zone
Integer
Boolean
Boolean
Boolean
Varchar
Text
NN (PK) (AK1)
NN (FK)
privileges_are_in_action_groups
group_privilege
id
Serial
NN
group_id
Integer NN
action
Varchar NN
action_group Varchar NN
target
Varchar
own_only
Boolean
(FK)
NN
NN
NN
groups_have_privileges
groups_are_parents
groups_are_childs
group_subgroup
parent_id Integer NN (PFK)
child_id Integer NN (PFK)
(PK)
(FK)
(FK)
(FK)
privileges_are_for_actions
action
identifier
Varchar NN (PK)
title
Varchar
description Text
Kuva 2.4: MIP:n tietokantarakenne k¨aytt¨ajille, ryhmille, sessioille ja k¨aytt¨ooikeuksille.
koskemaan esimerkiksi vain jotain tietty¨a entiteetti¨a. Lis¨aksi taulu sis¨alt¨aa¨ totuusarvoisen attribuutin own only, jolla voidaan m¨aa¨ ritt¨aa¨ oikeus koskemaan vain k¨aytt¨aj¨an itse
luomia kohteita.
T¨all¨a systeemill¨a voitaisiin esimerkiksi luoda jonkin ryhm¨an k¨aytt¨ajille oikeus poistaa itse luomiaan inventointiprojekteja. T¨all¨oin tauluun group privilege lis¨att¨aisiin
kyseisen ryhm¨an tunniste, toiminnon tunniste muokkaa, toimintoryhm¨a inventoinnit sek¨a
kohde inventointiprojekti. K¨aytt¨ooikeuksien lis¨aksi j¨arjestelm¨all¨a voidaan luoda my¨os
rajoituksia k¨aytt¨aj¨aryhmille. Esimerkiksi inventoijien t¨aytyy valita aktiivinen inventointiprojekti ennen kuin he voivat tallentaa uusia inventointeja, joten heill¨a on aktiivisena
toiminto pakota valinta kohteella inventointiprojekti.
LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA
15
K¨aytt¨ooikeusj¨arjestelm¨a on toteutettu user-tauluun perustuvassa luokassa Lougis user. Siin¨a on kaksi funktiota, staattinen ja dynaaminen, joita k¨aytet¨aa¨ n sen
mukaan, halutaanko tiet¨aa¨ vain sis¨aa¨ n kirjautuneen k¨aytt¨aj¨an oikeus johonkin
toimintoon vai k¨aytt¨aa¨ erillist¨a luokasta luotua oliota. Esimerkiksi funktiokutsu Lougis user::isAllowed("delete", "entities") palauttaa totuusarvon sen mukaan, onko nykyisell¨a k¨aytt¨aj¨all¨a oikeus poistaa rivej¨a tietokannasta.
Vastaava kutsu teht¨aisiin dynaamisesti Lougis user-tyyppiselle oliolle funktiolla
hasPrivilege().
Kuvaan 2.5 on koottu LouGIS-alustaan MIP:ia varten lis¨attyjen ominaisuuksien tietokantarakenne. Niihin kuuluvat lomakemuisti, muutoshistoria sek¨a liitetiedosto- ja kuvalinkitysj¨arjestelm¨at. Kaikkia n¨ait¨akin yhdist¨aa¨ k¨aytt¨aj¨atietoja sis¨alt¨av¨a user-taulu.
id
user_id
date
form_type
name
data
form_memory
Serial
Integer
Timestamp with time zone
Varchar
Varchar
Text
NN (PK)
NN (FK)
NN
modification_history_data
history_id Integer NN (PFK)
attribute Varchar
value
Text
a_user_saves_forms
id
enabled
firstname
lastname
default_email
password
nickname
phone
mobile
www
image
street1
street2
zip
city
user
Serial
Boolean
Varchar
Varchar
Varchar
Varchar
Varchar
Varchar
Varchar
Varchar
Varchar
Varchar
Varchar
Varchar
Varchar
user_adds_an_attachment
id
user_id
ref_schema
ref_table
ref_primary_keys
ref_row_ids
filename
path
original_filename
title
description
date_added
mip_attachment
Serial
Integer
Varchar
Varchar
Varchar
Varchar
Varchar
Varchar
Varchar
Varchar
Text
Timestamp with time zone
NN (PK)
NN (FK)
NN (PK) (AK1)
NN
NN
NN
NN
NN
a_modification_history_entry_may_have_data
id
user_id
ref_table
ref_keys
ref_values
ref_action
source
modification_time
comments
modification_history
Serial
Integer
Varchar
Varchar
Varchar
Varchar
Varchar
Timestamp with time zone
Text
NN (PK)
(FK)
NN
NN
NN
NN
a_user_makes_modifications
user_adds_a_photo
id
user_id
ref_schema
ref_table
ref_primary_keys
ref_row_ids
filename
path
original_filename
title
description
date_shot
date_added
mip_photo
Serial
Integer
Varchar
Varchar
Varchar
Varchar
Varchar
Varchar
Varchar
Varchar
Text
Timestamp with time zone
Timestamp with time zone
NN (PK)
NN (FK)
Kuva 2.5: MIP:n tietokantarakenne lomakemuistille, muutoshistorialle sek¨a kuville ja liitetiedostoille.
LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA
16
Sivusto sis¨alt¨aa¨ t¨aysin geneerisen toiminnallisuuden, jonka avulla mik¨a tahansa keskener¨ainen lomake voidaan tallentaa ja my¨ohemmin palauttaa. Lomakemuistia k¨aytett¨aess¨a
k¨aytt¨aj¨alt¨a kysyt¨aa¨ n lomakkeelle my¨ohemp¨aa¨ tunnistusta helpottava nimi (kuten ”Kiinteist¨o 006-425-0008-0008”), jonka j¨alkeen palvelimelle l¨ahetet¨aa¨ n nimen lis¨aksi lomakkeen ennalta m¨aa¨ r¨atty tyyppi (esim. ”Kiinteist¨o”) ja lomakkeen sis¨alt¨o JSON-koodattuna
assosiatiivisena taulukkona. Tiedot palvelin tallentaa form memory-tauluun yhdess¨a
tallennuksen tehneen k¨aytt¨aj¨an tunnisteen ja p¨aiv¨am¨aa¨ r¨an kanssa.
Toinen
geneerinen
toiminto
on
tauluihin
modification history
ja
modification history data perustuva muutoshistoria. Normaalisti muutoshistoria toimii siten, ett¨a ennen muutoksen tekoa luodaan modification historytauluun rivi, johon tallennetaan muutoksen tehneen k¨aytt¨aj¨an tunniste, kohdetaulu, taulun
avainsarakkeiden nimet ja niiden arvot sek¨a tehty toiminto (p¨aivitys vai alkuper¨ainen
lis¨ays). T¨am¨an j¨alkeen luodaan tauluun modification history data jokaiselle
muuttuneelle arvolle rivi, johon tulee sarakkeen nimi ja uusi arvo.
Kun vanhoja tietokantoja muunnettiin uuteen j¨arjestelm¨aa¨ n, muutoshistoriaan lis¨attiin
viel¨a mahdollisuus merkit¨a muutoksen l¨ahde selv¨akielisen¨a tekstin¨a ja kommentit tapahtumalle. Lis¨aksi lis¨attiin uusi toiminto, muunto. N¨ain muutoshistoriaan pystyttiin tallentamaan esimerkiksi tieto siit¨a, ett¨a kiinteist¨o tunnisteella 37249 on tuotu 11.5.2011
tietokannasta Inventoinnit ennen 1998 ja ett¨a alkuper¨aisen inventoinnin on tehnyt K. K.
elokuussa 1996.
L¨ahdett¨a voidaan k¨aytt¨aa¨ my¨os kertomaan selv¨akielisen¨a muutoksen tekij¨an nimi,
jos h¨anell¨a ei ole tunnuksia j¨arjestelm¨aa¨ n. T¨am¨a oli tilanne, kun tietokannan Inventoinnit 1998–2010 inventointeja tuotiin uuteen j¨arjestelm¨aa¨ n. Kyseisess¨a tietokannassa on
jokaisessa inventoinnissa tieto siit¨a, kuka on kohteen tietoja viimeksi muokannut ja koska. P¨aiv¨am¨aa¨ r¨at voitiin muuntaa suoraan uuden j¨arjestelm¨an vastaavaan kentt¨aa¨ n, mutta
useimmilla henkil¨oill¨a ei luonnollisesti ollut tunnuksia uuteen j¨arjestelm¨aa¨ n. Niinp¨a heid¨at
merkittiin muutoksen l¨ahteiksi.
LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA
17
MIP:n kuva- ja liitetiedostoj¨arjestelmien ideana on se, ett¨a mihin tahansa tietokannan
riviin voidaan liitt¨aa¨ miten monta kuvaa tai liitetiedostoa tahansa. Liitetiedostojen tiedot
tallennetaan mip attachment-tauluun. Jokaisesta tiedostosta tallennetaan muutoksen
tehneen k¨aytt¨aj¨an tunniste, kohdeskeema ja -taulu, avaimet sis¨alt¨avien sarakkeiden nimet
ja niiden arvot, tiedoston nykyinen nimi ja sen polku kuvapalvelimella sek¨a alkuper¨ainen
tiedostonimi ja lis¨aysp¨aiv¨a. Lis¨aksi tallennetaan tiedoston otsikko ja kuvaus, jos k¨aytt¨aj¨a
on sellaiset tiedostoa lis¨atess¨aa¨ n antanut. Kuvien tiedot sis¨alt¨av¨a mip photo-taulu on
muuten samanlainen, mutta siihen tallennetaan lis¨aksi kuvan kuvausp¨aiv¨am¨aa¨ r¨a.
Kuvien ja liitetiedostojen k¨ayt¨on helpottamiseksi MIP:n dataolioita on laajennettu geneerisill¨a funktioilla getAttachments() ja getImages(). Niiden avulla jokaiseen
dataolioon linkitetyt kuvat ja liitetiedostot pystyt¨aa¨ n hakemaan automaattisesti.
Portaali tukee monikielisyytt¨a tietokantapohjaisella j¨arjestelm¨all¨a, jonka taulurakennetta esitell¨aa¨ n kuvassa 2.6. J¨arjestelm¨ass¨a tallennetaan kaikki k¨aa¨ nnett¨av¨at tekstit ja
niiden kielet ui translate key-tauluun. Vastaavasti tekstien k¨aa¨ nn¨okset tallennetaan ui translate text-tauluun. Siihen voidaan merkit¨a my¨os k¨aa¨ nn¨oksen tekij¨a
source-kohtaan. Tauluun language tallennetaan sivustolla k¨ayt¨oss¨a olevat kielet.
language
id
Varchar NN (PK) (AK1)
name
Varchar NN
order_id Integer
a_translation_key_is_in_a_language
ui_translate_key
id
Serial
NN (PK)
site_id Varchar NN (FK)
lang_id Varchar NN (FK)
text
Varchar
keys_have_translations
a_translation_has_a_language
ui_translate_text
id
Serial
NN (PK)
key_id
Integer NN (FK)
translation_lang Varchar NN (FK)
translation_text Text
source
Varchar
a_translation_belongs_to_a_site
cms_site
id
Varchar NN (PK)
name Varchar
url
Varchar
Kuva 2.6: MIP:n tietokantarakenne kieli- ja k¨aa¨ nn¨ostuelle. LouGIS-alustan CMS- ja moniportaalituen takia sivustolla on j¨aa¨ nteen¨a my¨os cms site-taulu, jota MIP:ss¨a ei k¨aytet¨a.
LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA
2.5
18
Rakennusinventoinnin tietokantarakenne
Museon informaatioportaaliin kehitetty uusi rakennusinventointiskeema esitell¨aa¨ n kuvissa
2.7, 2.8 ja 2.9. Kuvaan 2.7 on koottu kuntien, kylien, kiinteist¨ojen ja rakennusten taulut.
Kunta ja kyl¨a m¨aa¨ ritt¨av¨at kiinteist¨on sijainnin siten, ett¨a kiinteist¨o kuuluu aina johonkin kyl¨aa¨ n, joka kuuluu johonkin kuntaan. Koska kuntia ja kyli¨a ei sin¨ans¨a inventoida,
niist¨a tallennetaan vain kunta- tai kyl¨anumero ja nimi. Kiinteist¨ost¨a sen sijaan pyrit¨aa¨ n
tallentamaan kyl¨an ja kiinteist¨otunnuksen lis¨aksi paljon muitakin tietoja, kuten sen sijainti
pisteen¨a ja sen omistajatiedot sek¨a kuvailevia tekstej¨a esimerkiksi sen asutushistoriasta,
l¨ahiymp¨arist¨ost¨a ja sen pihapiirist¨a.
kunta
id
Serial
kuntanumero Character varying(3)
nimi
Varchar
NN (PK)
NN
NN
kunnissa_on_kyliä
id
kunta_id
kylänumero
nimi
kylä
Serial
Integer
Varchar
Varchar
NN (PK)
NN (FK)
NN
NN
kylissä_on_kiinteistöjä
kiinteistöillä_on_rakennuksia
kiinteistö
id
Serial
NN (PK)
kylä_id
Integer
NN (FK)
kiinteistötunnus
Varchar
nimi
Varchar
osoite
Varchar
postinumero
Varchar
paikkakunta
Varchar
aluetyyppi
Varchar
arvotus
Varchar
historiallinen_tilatyyppi Varchar
lisätiedot
Text
asutushistoria
Text
lähiympäristö
Text
pihapiiri
Text
omistajatiedot
Text
perustelut_yhteenveto Text
lähteet
Text
kiinteistön_sijainti
geometry
rakennus_rakentaja
id
Serial
NN (PK)
rakennus_id
Integer NN (FK)
rakentajan_nimi
Varchar
rakentajan_ammatti_arvo Bigint
rakentajan_tyyppi
Varchar
rakentajan_laji
Varchar
lisätiedot
Text
rakennuksilla_on_rakentajia
rakennus
id
Serial
NN (PK)
kiinteistö_id
Integer
(FK)
rakennusnumero
Varchar
rakennustunnus
Varchar
rakennustyyppi
Varchar
kerroslukumäärä
Varchar
rakennusvuosi
Varchar
muutosvuodet
Varchar
alkuperäinen_käyttö Varchar
nykykäyttö
Varchar
perustus
Varchar
runko
Varchar
vuoraus
Varchar
ulkoväri
Varchar
katto
Varchar
kate
Varchar
kunto
Varchar
erityispiirteet
Text
rakennushistoria
Text
sisätilakuvaus
Text
muut_tiedot
Text
rakennuksen_sijainti geometry
Kuva 2.7: MIP:n rakennusinventointien tietokantarakenne kunnalle, kyl¨alle, kiinteist¨olle ja rakennukselle.
LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA
19
Kiinteist¨oll¨a on yksi tai useampia rakennuksia, joista jokaisesta pyrit¨aa¨ n tallentamaan
juoksevan rakennusnumeron lis¨aksi sen teknisi¨a tietoja, kuten rakennusvuodet, perustuksen materiaali ja sen kunto. Lis¨aksi voidaan tallentaa kuvailevat tekstit rakennuksen
erityispiirteist¨a, rakennushistoriasta ja sen sis¨atilasta. Tiedot rakennusten rakentajista ja
suunnittelijoista tallennetaan rakennus rakentaja-tauluun.
Kuvaan 2.8 on koottu inventointiprojektiin ja alueeseen liittyv¨at taulut. Inventointiprojekti on kokonaisuus, jonka m¨aa¨ r¨aa¨ mill¨a m¨aa¨ reill¨a rakennusinventointia tehd¨aa¨ n. Siihen
kuuluu kokonaisuutta kuvaava nimi ja pidempi kuvaus. Inventointiaika voitaisiin periaatteessa jakaa kahdeksi p¨aiv¨am¨aa¨ r¨a-tyyppiseksi kent¨aksi: inventoinnin alku ja inventoinnin
loppu. Kuitenkaan k¨ayt¨ann¨oss¨a n¨ain ei toimita, koska kyseiseen kentt¨aa¨ n kirjataan usein
ep¨am¨aa¨ r¨aisi¨a aikav¨alej¨a, kuten ”Kes¨a 2001”.
inventointiprojekti
id
Serial
NN (PK)
nimi
Varchar NN
kuvaus
Text
inventointiaika Varchar
toimeksiantaja Varchar
tyyppi
Varchar
inventointiprojektit_liittyvät_alueisiin
alue_inventointiprojekti
alue_id
Integer NN (PFK)
inventointiprojekti_id Integer NN (PFK)
kiinteistö_inventointiprojekti
inventointiprojekti_id Integer
kiinteistö_id
Integer
inventoija
Varchar
kenttäpäivä
Timestamp with time zone
NN (PFK)
NN (PFK)
inventointiprojektit_liittyvät_kiinteistöihin
inventointiprojekti_inventoija
id
Integer NN (PK)
inventointiprojekti_id Integer NN (PFK)
inventoija_id
Integer
inventoija_nimi
Varchar NN
inventoija_arvo
Varchar
inventointiprojekteilla_on_inventoijia
alue_kylä
alue_id Integer NN (PFK)
alueita_inventoidaan_inventointiprojekteissa
kylä_id Integer NN (PFK)
alue
id
Serial
NN (PK)
nimi
Varchar
alueet_sisältävät_kyliä
maisema Text
arvoalue
historia
Text
id
Serial
NN (PK)
nykytila
Text
alue_id
Integer
NN (FK)
lisätiedot
Text
nimi
Varchar
(AK1)
lähteet
Text
aluetyyppi Varchar NN
keskipiste geometry
arvotus
Varchar
aluerajaus geometry
kuvaus
Text
keskipiste geometry
alueet_sisältävät_arvoalueita
aluerajaus geometry
Kuva 2.8: MIP:n rakennusinventointien tietokantarakenne inventointiprojektille, alueelle ja arvoalueelle.
LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA
20
Tyypillisess¨a inventointiprojektissa yksi henkil¨o on tehnyt kaikki kyseisen projektin
inventoinnit. Kuitenkin on my¨os inventointiprojekteja, joiden inventointeja on tehnyt
useampi henkil¨o. Niinp¨a tiedot yhden projektin inventoijista ker¨at¨aa¨ n erilliseen inventointiprojekti inventoija-tauluun. Koska kaikilla inventoijilla ei ole tunnuksia
MIP:iin, inventoijista ei voida kirjata vain heid¨an tunnistettaan, vaan inventoijan nimi
tallennetaan aina erikseen.
Inventointiprojektit liittyv¨at suoraan kiinteist¨oihin (kiinteist¨
o inventointiprojekti) ja alueisiin (alue inventointiprojekti). Molempien kohdalla tarvitaan k¨ayt¨ann¨oss¨a monesta moneen -relaatiota, koska yht¨a aluetta tai kiinteist¨oa¨ voidaan
inventoida monessa inventointiprojektissa, ja vastaavasti yhdess¨a inventointiprojektissa voidaan inventoida monia alueita tai kiinteist¨oj¨a. Kiinteist¨on kohdalla voidaan lis¨aksi kirjata,
kuka kyseisen kiinteist¨on on inventoinut ja min¨a p¨aiv¨an¨a.
Rakennusinventoinnissa alue on yhden tai useamman kyl¨an (alue kyl¨
a) alueella
sijaitseva kokonaisuus, joka on jostain syyst¨a inventoinnin kannalta kiinnostava. Alueesta
pyrit¨aa¨ n tallentamaan tekstimuotoisten perustietojen lis¨aksi sen kattama ala (aluerajaus) pistejoukkona, jossa ensimm¨ainen ja viimeinen piste ovat samoja. Jos alan tallennus
ei ole jostain syyst¨a mahdollista, voidaan alueesta tallentaa vain sen keskipiste. Aluerajaus
ja keskipiste tallennetaan molemmat PostGIS:n erityist¨a geometrioiden tallennukseen
tarkoitettua tietotyyppi¨a geometry k¨aytt¨aen.
Jokaisen alueen alla voi olla yksi tai useampia arvoalueita. Ne ovat yhdest¨a alueesta
rajattuja pienempi¨a kokonaisuuksia, joilla on vaikkapa kulttuurihistoriallista merkityst¨a.
Alueen tapaan arvoalueen aluerajaus tai keskipiste voidaan tallentaa geometriana.
Kiinteist¨oille, rakennuksille ja arvoalueille voidaan antaa my¨os erilaisia kulttuurihistoriallisia arvoja ja suojelumerkint¨oj¨a. Niiss¨a tarvittavaa taulurakennetta esitell¨aa¨ n kiinteist¨ojen ja arvoalueiden osalta kuvassa 2.9. MIP:ssa erilaisia kulttuurihistoriallisia arvoja
on yhteens¨a 15, ja ne on koottu tauluun kulttuurihistoriallinen arvo. Kun
kohteelle annetaan erilaisia arvoja, niille voidaan my¨os antaa kuvaus tai perustelu, miksi
LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA
21
kyseinen arvo kyseiselle kohteelle on annettu. Suojelumerkinn¨oiss¨a on k¨ayt¨oss¨a vastaava
j¨arjestelm¨a, jossa tosin perustelun sijaan merkinn¨an kohteen valinnan j¨alkeen kerrotaan,
mik¨a merkint¨a kohteessa on ja lis¨aksi annetaan selite kyseiselle merkinn¨alle. Esimerkiksi rakennuksella voi olla asemakaavassa merkint¨a SR, jonka selitteen¨a on ”s¨ailytett¨av¨a
rakennus”.
kulttuurihistoriallinen_arvo
kulttuurihistoriallinen_arvo Varchar NN (PK)
selite
Varchar NN
järjestysnumero
Integer
ryhmä
Varchar
arvoalueiden_kulttuurihistoriallisilla_arvoilla_on_nimi
arvoalue_kulttuurihistoriallinen_arvo
arvoalue_id
Integer NN (PFK)
kulttuurihistoriallinen_arvo Varchar NN (PFK)
kuvaus
Text
arvoalueilla_on_kulttuurihistoriallisia_arvoja
id
alue_id
nimi
aluetyyppi
arvotus
kuvaus
keskipiste
aluerajaus
arvoalue
Serial
NN (PK)
Integer
NN (FK)
Varchar
(AK1)
Varchar NN
Varchar
Text
geometry
geometry
kiinteistöjen_kulttuurihistoriallisilla_arvoilla_on_nimi
kiinteistö_kulttuurihistoriallinen_arvo
kiinteistö_id
Integer NN (PFK)
kulttuurihistoriallinen_arvo Varchar NN (PFK)
kuvaus
Text
kiinteistöillä_on_kulttuurihistoriallisia_arvoja
kiinteistö
id
Serial
NN (PK)
kylä_id
Integer
NN (FK)
kiinteistötunnus
Varchar
nimi
Varchar
osoite
Varchar
postinumero
Varchar
paikkakunta
Varchar
aluetyyppi
Varchar
arvotus
Varchar
historiallinen_tilatyyppi Varchar
lisätiedot
Text
asutushistoria
Text
lähiympäristö
Text
pihapiiri
Text
omistajatiedot
Text
perustelut_yhteenveto Text
lähteet
Text
kiinteistön_sijainti
geometry
arvoalueilla_on_suojelumerkintöjä
kiinteistöillä_on_suojelumerkintöjä
arvoalue_suojelumerkintä
arvoalue_id
Integer NN (PFK)
kohde
Varchar NN (PFK)
merkintä
Varchar
merkinnän_selite Text
arvoalueen_suojelumerkinnällä_on_kohde
kiinteistö_suojelumerkintä
kiinteistö_id
Integer NN (PFK)
kohde
Varchar NN (PFK)
merkintä
Varchar
merkinnän_selite Text
kiinteistön_suojelumerkinnällä_on_kohde
suojelumerkintä_kohde
kohde Varchar NN (PK)
nimi
Varchar NN
kuvaus Text
seqnum Integer
Kuva 2.9: MIP:n rakennusinventointien arvoalueiden ja kiinteist¨ojen kulttuurihistoriallisten arvojen
ja suojelumerkint¨ojen tietokantarakenne. Vastaava rakenne on k¨ayt¨oss¨a my¨os rakennuksilla.
Luku 3
Paikkatietov¨alityspalvelimen
suunnittelu
T¨ass¨a ty¨oss¨a on siis tavoitteena kehitt¨aa¨ geneerinen paikkatietov¨alityspalvelin, joka helpottaisi paikkatietoaineistojen hallintaa ja k¨asittely¨a projektien sis¨all¨a tarjoamalla yleisk¨aytt¨oisen rajapinnan eri aineistojen soveltamiseen. Tarkoituksena olisi se, ett¨a luotava j¨arjestelm¨a
osaisi yhdistell¨a eri l¨ahteist¨a saatavia paikkatietoaineistoja sek¨a tarjota asiakkaalle j¨arkev¨aa¨
tietoa halutusta kohteesta halutussa formaatissa ja koordinaattij¨arjestelm¨ass¨a ilman, ett¨a
asiakkaan tarvitsee suoraan tiet¨aa¨ , mist¨a aineistoista tietoa haetaan.
Keskeinen kysymys j¨arjestelm¨an kehityksess¨a on luonnollisesti tietojen oikeellisuus.
K¨ayt¨ann¨oss¨a ongelmana ei siis ole vain se, miten valitaan oikeat l¨ahteet hakea tietoa, sill¨a
lis¨aongelma muodostuu tulosten yhdistelyst¨a. Toinen keskeinen kehityskysymys liittyy
geneerisyyteen ja sen yll¨apit¨amiseen.
Geneerisyytt¨a ja sen roolia t¨ass¨a ty¨oss¨a kehitett¨av¨ass¨a paikkatietov¨alityspalvelimessa
k¨asitell¨aa¨ n tarkemmin seuraavassa kohdassa. Sen j¨alkeen aloitetaan paikkatietov¨alityspalvelimen suunnitteluprosessin esittely analysoimalla palvelimelle asetettuja vaatimuksia
ja tavoitteita. Samalla k¨ayd¨aa¨ n l¨api my¨os Museon informaatioportaalin asettamat erityisvaatimukset, ja esitet¨aa¨ n niiden pohjalta kaksi k¨aytt¨otapausta palvelimelle, joista toisen
¨
LUKU 3. PAIKKATIETOVALITYSPALVELIMEN
SUUNNITTELU
23
pohjalta suunnitellaan ja toteutetaan palvelimen prototyyppi. Lopuksi prototyypin toteutus
puretaan vaiheisiin ja analysoidaan, jonka j¨alkeen tehtyjen havaintojen pohjalta aloitetaan
varsinaisen paikkatietov¨alityspalvelimen tietokanta- ja luokkarakenteen suunnittelu.
3.1
Geneerisyys
Geneerinen ohjelmointi perustuu periaatteeseen, jonka mukaan ohjelmisto voidaan jakaa komponenteiksi, jotka pyrkiv¨at tekem¨aa¨ n mahdollisimman v¨ah¨an oletuksia muista
komponenteista, jolloin niiden yhdistely onnistuu mahdollisimman joustavasti [25]. Geneerisyys sin¨ans¨a on termin¨a jossain m¨aa¨ rin vaikeasti m¨aa¨ ritelt¨av¨a, koska moni m¨aa¨ ritys
riippuu k¨ayt¨oss¨a olevasta ohjelmointikielest¨a. Usein l¨ahdet¨aa¨ n liikkeelle esimerkiksi C++:n
templaattij¨arjestelm¨an kaltaisesta tietorakenteiden parametrisoinnista tyypeill¨a [26], mik¨a
ei oikein sovi t¨ah¨an projektiin, koska palvelin tullaan toteuttamaan luonteeltaan dynaamisella PHP-kielell¨a [27].
Er¨as yleisesti hyv¨aksytty m¨aa¨ ritelm¨a geneeriselle ohjelmoinnille on niin sanottu Musser-Stepanovin m¨aa¨ ritelm¨a. Sen mukaan geneerisen ohjelmoinnin ideana on aloittaa k¨ayt¨ann¨ollisest¨a ja k¨aytt¨okelpoisesta algoritmista, jota aletaan abstrahoida. Tavoitteena on
l¨oyt¨aa¨ algoritmien ja tietorakenteiden konsepti, niiden abstrakti m¨aa¨ ritelm¨a. K¨ayt¨oss¨a
olevien algoritmien tulisi olla t¨aysin riippumattomia datasta, jota ne k¨asittelev¨at. [28]
T¨ast¨a n¨ak¨okulmasta palvelimesta voidaan kehitt¨aa¨ ensin prototyyppi, joka tuottaa
etuk¨ateen p¨aa¨ tetyist¨a aineistoista aina samantyyppist¨a sis¨alt¨oa¨ . Sen pohjalta voidaan
alkaa etsi¨a yleisemp¨aa¨ versiota, ty¨okalua, jossa erilaisia paikkatietoaineistoja p¨aa¨ sisi
k¨asittelem¨aa¨ n yhten¨aisen rajapinnan kautta. Rajapinnan pit¨aisi olla sellainen, ett¨a uusien,
hyvinkin erilaisten aineistotyyppien lis¨aa¨ minen j¨arjestelm¨aa¨ n onnistuu mahdollisimman
yksinkertaisesti ja vapaasti.
Aineistoille teht¨avien operaatioiden osalta geneerisyys tarkoittaa sit¨a, ett¨a yksitt¨aisen
aineiston tyypin tai operaatioiden keskin¨aisen suoritusj¨arjestyksen ei pit¨aisi vaikuttaa
¨
LUKU 3. PAIKKATIETOVALITYSPALVELIMEN
SUUNNITTELU
24
palvelimen toimintaan. N¨ain eri operaatioita suorittavat luokat voisivat toimia vapaahkosti
v¨alitt¨am¨att¨a toisistaan. T¨all¨oin luokkia m¨aa¨ ritt¨av¨ast¨a rajapinnasta tulee v¨akisinkin hyvin
yksinkertainen.
J¨arjestelm¨an arkkitehtuurin kannalta geneerisyydell¨a pyrit¨aa¨ n siihen, ett¨a se on helposti
yll¨apidett¨av¨a ja laajennettava sek¨a siihen, ett¨a sen komponentit ovat uudelleenk¨aytett¨avi¨a
[29]. K¨ayt¨ann¨oss¨a t¨allaisen tietoa v¨alitt¨av¨an ja k¨asittelev¨an palvelimen tapauksessa geneerisyyden merkitys korostuu siis ennen muuta siin¨a, ett¨a datan k¨asittelyst¨a vastaavien
luokkien pit¨aa¨ olla helposti muokattavia, ja niit¨a t¨aytyy pysty¨a ongelmitta korvaamaan toisilla. Toisin sanoen tiedon k¨asittelyprosessista pit¨aa¨ tehd¨a sellainen, ett¨a sen eri vaiheiden
muuttaminen onnistuu yksinkertaisesti.
3.2
Palvelimen kehityksen tavoitteet
Paikkatietov¨alityspalvelimen tavoitteena on tarjota ohjelmistoille geneerinen paikkatietosovelluskerros, jonka avulla voitaisiin esimerkiksi yhdist¨aa¨ paikallisia entiteettej¨a kolmannen
osapuolen paikkatietoaineistoihin ilman, ett¨a k¨aytt¨aj¨an t¨aytyy t¨asm¨alleen tiet¨aa¨ , mist¨a paikkatietoaineistoista tietoa haetaan. K¨ayt¨ann¨oss¨a t¨am¨a tarkoittaa sit¨a, ett¨a palvelin kykenee
sille annetun sijainti- ja siihen liittyv¨an metatiedon perusteella valitsemaan tuntemistaan
aineistoista kyseiseen tapaukseen soveltuvat, ja osaa hakea niist¨a tietoa.
MIP:ss¨a ensisijainen k¨aytt¨okohde palvelimelle olisi uusien kohteiden lis¨aa¨ misen helpottaminen. Esimerkiksi kiinteist¨ojen ja rakennusten muokkauksessa k¨aytett¨aviin lomakkeisiin
on toivottu toimintoa, jonka avulla k¨aytt¨aj¨a voisi hakea Maanmittauslaitoksen rajapintapalveluista tietoa kohteesta klikkaamalla sit¨a kartalta. Palvelimelle teht¨aisiin esimerkiksi
kysely ”Kerro mit¨a pystyt tarjoamaan tietokannan entiteetille kiinteist¨o pisteess¨a 226576,
6737422 (EPSG:3067) JSON-formaatissa”, mink¨a j¨alkeen palvelin osaisi tuntemistaan
aineistoista hakea kiinteist¨otietoja, yhdist¨aa¨ niit¨a j¨arkeviksi kokonaisuuksiksi, ja lopulta
palauttaa lopputuloksen k¨aytt¨aj¨alle JSON-enkoodattuna assosiatiivisena taulukkona.
¨
LUKU 3. PAIKKATIETOVALITYSPALVELIMEN
SUUNNITTELU
25
Toinen MIP:iin toivottu toiminnallisuus on palvelusta saatavien tietojen n¨aytt¨aminen
k¨aytt¨aj¨alle sellaisenaan. T¨allaiselle ominaisuudelle olisi k¨aytt¨oa¨ esimerkiksi uusien rakennusten lis¨ayksess¨a, sill¨a vaikka Maanmittauslaitoksen tarjoamat rakennustiedot ovat
erinomainen l¨ahde rakennustietojen sy¨ott¨amiseen, ne ovat usein ep¨at¨asm¨allisi¨a ja jossain
m¨aa¨ rin ep¨aluotettavia. Niinp¨a lomakkeen kentti¨a ei voida automaattisesti t¨aytt¨aa¨ , vaan
palvelun tarjoamat tiedot pit¨aisi tarjota k¨aytt¨aj¨alle helposti luettavassa formaatissa.
N¨aiden vaatimusten perusteella palvelimelle voidaan tehd¨a kaksi k¨aytt¨otapausta. Ensimm¨ainen kattaa palvelimen l¨oyt¨amien tietojen n¨aytt¨amisen k¨aytt¨aj¨alle sellaisenaan.
K¨aytt¨otapaus 1: Palauta HTML-taulukkona rakennuksiin liittyvi¨a tietoja annetusta pisteest¨a.
1. Haetaan rakennustietoja sis¨alt¨av¨at aineistot.
2. Muunnetaan annettu piste aineiston asetuksiin m¨aa¨ ritetyn kokoiseksi neli¨on muotoiseksi aluerajaukseksi.
3. Haetaan tuloksia aineistoista aluerajauksilla.
4. Ker¨at¨aa¨ n tulokset yhteen ja muutetaan ne yhdenmukaiseen formaattiin.
5. K¨asitell¨aa¨ n tuloksista luettavampia.
6. Palautetaan tulokset k¨aytt¨aj¨alle HTML:n taulukkona.
K¨ayt¨ann¨oss¨a ongelmia voi tuottaa viides kohta, jossa palveluista saatava mahdollisesti
monitasoinen data pit¨aa¨ jotenkin ”litist¨aa¨ ” mahdollisimman selke¨aksi, avain-arvo-pareista
koostuvaksi, mielell¨aa¨ n yksiulotteiseksi taulukoksi. Toinen toiminnallisuuskuvaus on ensimm¨aist¨a jonkin verran monimutkaisempi, koska siin¨a yhdistell¨aa¨ n eri l¨ahteist¨a saatavia
tuloksia. Kuvaus kattaa lomakkeiden automaattisen t¨aydent¨amisen.
K¨aytt¨otapaus 2: Palauta JSON-koodattuna taulukkona annettuun pisteeseen liittyvi¨a
tietoja Museon informaatioportaalin kiinteist¨olomakkeelle sovitettuna.
1. Haetaan aineistot, jotka tarjoavat kiinteist¨otietoja.
2. Muunnetaan annettu piste aineiston asetuksiin m¨aa¨ ritetyn kokoiseksi neli¨on muotoiseksi aluerajaukseksi.
¨
LUKU 3. PAIKKATIETOVALITYSPALVELIMEN
SUUNNITTELU
26
3. Haetaan tuloksia aineistoista aluerajauksilla.
4. Muunnetaan aineistoista saatavat tiedot j¨arjestelm¨an sis¨aiseen formaattiin.
5. Yhdistet¨aa¨ n eri aineistoista kiinteist¨okohtaisia kokonaisuuksia.
6. Haetaan yhdistellyist¨a tuloksista kent¨at, joille l¨oytyy vastaava kohta kiinteist¨olomakkeesta, nimet¨aa¨ n ja j¨alkik¨asitell¨aa¨ n kukin kentt¨a lomakkeen vaatimusten mukaisesti.
7. Palautetaan tulokset JSON-koodattuna.
Ensimm¨aisen kuvauksen tapaan tulosten j¨alkik¨asittely muodostanee ongelmia t¨ass¨akin
kohtaa. Kuitenkin suurempi kysymys liittyy tulosten yhdistelyyn. Palvelimen toteutuksessa
ei riit¨a viel¨a se, ett¨a se osaa saamiensa parametrien perusteella valita oikeat aineistot,
vaan lis¨aksi siihen t¨aytyy kehitt¨aa¨ logiikka, jonka avulla se osaa muodostaa eri l¨ahteist¨a
saaduista tuloksista j¨arkevi¨a kokonaisuuksia. Yksinkertaisesti t¨am¨a onnistuisi tallentamalla
palvelimelle aineistojen parametrien lis¨aksi tieto siit¨a, mist¨a kentist¨a eri l¨ahteiden tuloksia
voi liitt¨aa¨ toisiinsa.
3.3
Prototyypin suunnittelu
Paikkatietov¨alityspalvelimesta teht¨av¨aksi prototyypiksi valittiin kohdan 3.1 toiminnallisuuskuvauksen 2 mukainen Museon informaatioportaaliin toivottu toiminto kiinteist¨olomakkeen automaattisesta t¨aydent¨amisest¨a. Prototyypin avulla oli tavoitteena tutkia
muutaman aineiston avulla, miten saatuja tuloksia t¨aytyy k¨asitell¨a, jotta niist¨a saadaan
halutun kaltaisia.
Prototyypin ty¨ost¨aminen aloitettiin tutustumalla Maanmittauslaitoksen viranomaisk¨aytt¨oo¨ n tarjoamiin rajapintapalveluihin [30]. Niist¨a kiinnostaviksi osoittautuivat tietoa
kiinteist¨ojen rajoista, nimist¨a ja kiinteist¨otunnuksista tarjoava Kiinteist¨otietojen kyselypalvelu ja erilaisia rakennustietoja sis¨alt¨av¨a Rakennustietojen kyselypalvelu. Kiinteist¨otietojen
kyselypalvelun avulla selvitett¨aisiin, mit¨a kiinteist¨oa¨ k¨aytt¨aj¨a on tarkoittanut karttaa klikatessaan, jonka j¨alkeen Rakennustietojen kyselypalvelusta haettaisiin kyseisen kiinteist¨on
¨
LUKU 3. PAIKKATIETOVALITYSPALVELIMEN
SUUNNITTELU
27
p¨aa¨ rakennuksen tiedoista kiinteist¨olle postinumero, osoite ja omistajatiedot sek¨a kiinteist¨on
sijainti1 .
Maanmittauslaitos tarjoaa niin kiinteist¨ojen kuin rakennustenkin kattamat alat monikulmioina. T¨aten tietoja haettaessa voidaan olla melko varmoja siit¨a, ett¨a k¨aytt¨aj¨a on klikannut
kartalta oikeaa kiinteist¨oa¨ , joten pisteest¨a luotava karttarajaus voidaan asettaa melko pieneksi. Sen sijaan rakennustietoja haettaessa halutaan l¨oyt¨aa¨ juurikin oikean kiinteist¨on
p¨aa¨ rakennus, joten aluerajaus t¨aytyy asettaa huomattavasti suuremmaksi.
Molemmat palvelut implementoivat OGC:n OpenGIS Web Feature Service (WFS)
-protokollan version 1.1.0. WFS:n ideana on tarjota paikkatietoaineistoja GML-muodossa.
Kyselyt WFS-palveluihin tehd¨aa¨ n HTTP-protokollaa k¨aytt¨aen joko URL-parametreina tai
XML-muotoisina kyselyin¨a. Eri kyselytyyppeihin kuuluvat palvelun ominaisuustietokysely GetCapabilities, kohdetyyppien XML-skeemakuvauksen tarjoava DescribeFeatureType sek¨a varsinaisia paikkatietoelementtej¨a parametrien perusteella tarjoava
GetFeature. [11]
Periaatteessa GetFeature-kyselyss¨a tarvittavat parametrit olisi mahdollista muodostaa ajon aikana muiden kyselyiden avulla, mutta viiveen minimoimiseksi prototyyppiin
kannattanee tallentaa suurin osa parametreista suoraan. Kiinteist¨otietojen kyselypalveluun
teht¨avien WFS-kyselyjen parametreja k¨ayd¨aa¨ n l¨api taulukossa 3.1. Parametreista ainoastaan kyselyn koordinaattirajaus, BBOX, on pakko m¨aa¨ ritt¨aa¨ ajon aikana, koska se t¨aytyy
muodostaa k¨aytt¨aj¨alt¨a tulevasta pisteest¨a. Muut parametrit voidaan asettaa kiinte¨asti.
3.4
Prototyypin toteutus
Prototyypin toteutus p¨aa¨ tettiin pit¨aa¨ mahdollisimman yksinkertaisena ja suoraviivaisena,
eik¨a siit¨a ollut tavoitteena kehitt¨aa¨ sin¨ans¨a geneerist¨a. Geneerisyys oli kuitenkin toteutusratkaisuja teht¨aess¨a keskeisess¨a osassa, sill¨a prototyypiss¨a teht¨av¨at ratkaisut haluttiin kui1
Rakennusinventoinnissa kiinteist¨on sijainniksi m¨aa¨ ritet¨aa¨ n sen p¨aa¨ rakennuksen sijainti.
¨
LUKU 3. PAIKKATIETOVALITYSPALVELIMEN
SUUNNITTELU
28
Taulukko 3.1: Kiinteist¨otietojen kyselypalveluun teht¨avien WFS-kyselyjen parametreja selityksineen. Kyselyt tehd¨aa¨ n lis¨aa¨ m¨all¨a palvelun WFS-osoitteen j¨alkeen parametreja muodossa ?parametri1=arvo1&parametri2=arvo2 jne. Rakennustietojen kyselypalveluun
teht¨avien kyselyjen parametrit ja niiden arvot ovat suurimmalta osalta samat, ainoastaan parametreilla NAMESPACE ja TYPENAME k¨aytet¨aa¨ n eri arvoja.
Parametri
Arvo
SERVICE
WFS
K¨aytetty protokolla
VERSION
1.1.0
Protokollan versio
REQUEST
GetFeature
Kyselyn tyyppi
NAMESPACE
xmlns(ktjkiiwfs=http://xml.nls.fi/ktjkiiwfs/2010/02)
Kyselyn XML-nimiavaruus
TYPENAME
ktjkiiwfs:RekisteriyksikonTietoja
Kohdetyypin nimi, eli mit¨a tietoja palvelulta halutaan
PROPERTYNAME ktjkiiwfs:kiinteistotunnus,ktjkiiwfs:nimi
Tiedot, jotka palvelulta halutaan
BBOX
esim. 240678,6710891.5,240682,6710895.5,EPSG:3067
Koordinaattirajaus laatikkona muodossa xMax,yMax,xMin,yMin,koordinaattij¨arjestelm¨a
SRSNAME
EPSG:3067
Tuloksilta haluttu koordinaattij¨arjestelm¨a
MAXFEATURES
esim. 3
Suurin sallittu tulosten m¨aa¨ r¨a
RESULTTYPE
results
Tulosten tyyppi. Vaihtoehtoisella arvolla ”hits” palauttaisi tulosten m¨aa¨ r¨an
tenkin pit¨aa¨ sellaisina, ett¨a ne olisi mahdollista yleist¨aa¨ geneerisemmiksi. Yhden aineiston
sis¨alt¨oo¨ n tai rakenteeseen perustuvia ratkaisuja piti siis v¨altt¨aa¨ .
Toteutuksen idea on sin¨ans¨a yksinkertainen: haetaan kiinteist¨o- ja rakennustietoja sopivalla aluerajauksella, jonka j¨alkeen k¨ayd¨aa¨ n l¨api tuloksena saadut kiinteist¨ot, joihin
yhdistet¨aa¨ n rakennusten joukosta mahdollisesti l¨oydettyjen p¨aa¨ rakennusten tiedot. Tuloksista haetaan sopivat kent¨at, jotka sovitetaan kiinteist¨olomakkeen vastaaviin. Sovelluksen
toimintalogiikkaa esitell¨aa¨ n kuvassa 3.1.
Prototyypin suoritus alkaa, kun siihen sy¨otet¨aa¨ n pisteen x- ja y-koordinaatit EUREFFIN-koordinaatistossa. Koordinaattien pohjalta muodostetaan 25 m2 kokoinen neli¨onmuotoinen karttarajaus, jonka keskikohta annettu piste on. Yhdess¨a t¨am¨an karttarajauksen
¨
LUKU 3. PAIKKATIETOVALITYSPALVELIMEN
SUUNNITTELU
29
1
2
Käyttöliittymä
x- ja y-koordinaatit
kiinteistöjen tiedot rakennustiedoilla
laajennettuna ja lomakkeelle
sovitettuna assosiatiivisena taulukkona
Paikkatietovälityspalvelimen prototyyppi
aluerajaus 25 m2,
keskipisteenä (x,y)
alueella olevien
kiinteistöjen nimet ja
kiinteistötunnukset
Kiinteistötietojen kyselypalvelu (WFS)
aluerajaus 250 m2,
keskipisteenä (x,y)
alueella olevien
rakennusten tiedot
Rakennustietojen kyselypalvelu (WFS)
Kuva 3.1: Paikkatietov¨alityspalvelimen prototyypin toimintalogiikka.
ja prototyyppiin kiinte¨asti tallennettujen parametrien kanssa muodostetaan URL, jonka
avulla tehd¨aa¨ n WFS-kysely Kiinteist¨otietojen kyselypalveluun. Kyselyn tuloksena saatu
tekstimuotoinen XML-data muunnetaan PHP:n SimpleXML-olioksi.
Sama operaatio toistetaan Rakennustietojen kyselypalvelun kanssa, tosin k¨ayt¨oss¨a
olevan karttarajauksen koko kymmenkertaistetaan 250 neli¨ometriin. Suuri kokoero selittyy
osittain sill¨a, ett¨a kiinteist¨on ala on yleens¨a huomattavasti rakennuksen alaa suurempi,
joten pisteen voidaan melko varmasti olettaa olevan oikean kiinteist¨on alueella. Suurin
syy erilaisiin karttarajauksiin tulee kuitenkin siit¨a, miten prototyyppi k¨asittelee palveluista
saamiaan tuloksia.
WFS-kyselyjen valmistuttua aloitetaan Kiinteist¨otietojen kyselypalvelujen tulosten
l¨apik¨aynti. Yksi kerrallaan kunkin kiinteist¨on tiedot haetaan tulosjoukosta ja muunnetaan
¨
LUKU 3. PAIKKATIETOVALITYSPALVELIMEN
SUUNNITTELU
30
PHP:n assosiatiiviseksi taulukoksi. T¨am¨an j¨alkeen tietoja koetetaan t¨aydent¨aa¨ etsim¨all¨a
kiinteist¨on p¨aa¨ rakennusta rakennushaun tuloksista. K¨ayt¨ann¨oss¨a prototyyppi etsii siis
rakennuksista XML:n XPath-haulla sellaista, jonka rakennusnumero on 001, ja jonka
kiinteist¨otunnus t¨asm¨aa¨ k¨asittelyss¨a olevan kiinteist¨on kanssa. Jos oikea rakennus l¨oytyy,
sen tiedot muunnetaan assosiatiiviseksi taulukoksi, joka yhdistet¨aa¨ n kiinteist¨otietoihin.
Koska eri palvelut k¨aytt¨av¨at eri XML-nimiavaruuksia, mahdolliset samannimiset kent¨at
eiv¨at tuota ongelmatilanteita.
Lopputuloksena saadusta kiinteist¨on ja mahdollisesti sen p¨aa¨ rakennuksen tiedot sis¨alt¨av¨ast¨a taulukosta k¨asitell¨aa¨ n Museon informaatioportaalin kiinteist¨olomakkeelle sopiva.
Kiinteist¨otiedoista haettavia kentti¨a ovat kiinteist¨otunnus ja kiinteist¨on nimi; rakennustiedoista otetaan postinumero, l¨ahiosoite, omistajatiedot ja kiinteist¨on sijainti. Osa kentist¨a k¨asitell¨aa¨ n MIP:n k¨ayt¨ant¨ojen mukaisiksi, esimerkiksi kiinteist¨otunnukseen lis¨at¨aa¨ n
v¨aliviivat ja suuraakkosilla kirjoitettu kiinteist¨on nimi muunnetaan ensimm¨aist¨a kirjainta
lukuun ottamatta pienell¨a kirjoitetuksi.
Lopulliseen muotoonsa k¨asitellyt tiedot ker¨at¨aa¨ n tulostaulukkoon. Kun kaikki kiinteist¨ot on saatu k¨asitelty¨a, tulostaulukko palautetaan asiakkaalle JSON-koodattuna.
3.5
Kohti geneerisyytt¨a – prototyypin analyysi
Edellisiss¨a kohdissa kehitetty prototyyppi ei siis sin¨ans¨a ole mill¨aa¨ n tasolla geneerinen
ty¨okalu, vaan ennemminkin yksinkertainen skripti, joka kykenee suorittamaan yksinkertaisen ennalta m¨aa¨ ritetyn operaation ennalta m¨aa¨ ritetyille aineistoille. Kuitenkin prototyyppi
havainnollistaa palvelimen toimintaa ja toisaalta tarjoaa selke¨an testitapauksen. Varsinaisen
paikkatietov¨alityspalvelimen pit¨aisi kyet¨a tuottamaan t¨asm¨alleen samanlaisia aineistoja
geneeristen ty¨okalujen avulla.
Prototyypist¨a havainnollistaa, millaisia vaiheita palvelimen toiminnassa voisi olla.
Toiminnan kulku voidaan jakaa nelj¨aa¨ n vaiheeseen:
1. Valitaan ja alustetaan aineistot.
¨
LUKU 3. PAIKKATIETOVALITYSPALVELIMEN
SUUNNITTELU
31
2. Tehd¨aa¨ n haut aineistoihin, ja muunnetaan saadut tulokset j¨arjestelm¨an sis¨aiseen
formaattiin ja tuloksilta haluttuun koordinaattij¨arjestelm¨aa¨ n.
3. Lajitellaan ja yhdistet¨aa¨ n saadut tulokset ja tuotetaan uusi, yhten¨ainen tulosjoukko.
4. J¨alkik¨asitell¨aa¨ n tulokset ja palautetaan ne asiakkaan haluamassa formaatissa.
Ensimm¨aist¨a vaihetta varten palvelimeen tarvitaan j¨arjestelm¨a, jonka avulla se osaa
valita sopivat aineistot k¨aytt¨aj¨an antamien tietojen perusteella. Aineistojen valinnan j¨alkeen
palvelimen t¨aytyy kyet¨a luomaan kunkin aineiston tyyppi¨a vastaavat oliot ja alustamaan ne
oikeilla parametreilla. Se, mit¨a koordinaattien muuntamisen kaltaisia operaatioita parametreille t¨aytyy tehd¨a, jotta varsinainen aineistojen haku onnistuu, on selke¨asti aineistotyypin
mukaisen luokan teht¨avi¨a.
My¨os toiseen vaiheeseen kuuluva hakujen tekeminen on aineistotyypin mukainen teht¨av¨a. Sen sijaan j¨arjestelm¨an sis¨aisesti k¨aytt¨am¨a formaatti on kaikkia aineistoluokkia koskeva
kysymys. Prototyypiss¨a k¨aytetty PHP:n assosiatiivinen taulukko osoittautui hankalaksi,
koska sill¨a ei voi luontevasti esitt¨aa¨ XML:n tietokokonaisuuksia, joissa yhdell¨a elementill¨a
on monta samannimist¨a lapsielementti¨a. Koska XML vaikuttaa olevan yleisin k¨ayt¨oss¨a
oleva formaatti, t¨ass¨akin palvelimessa kannattanee k¨aytt¨aa¨ sis¨aisen¨a formaattina XML:¨aa¨ .
T¨all¨oin pystyt¨aisiin tarvittaessa esimerkiksi palauttamaan tiedot alkuper¨aiseen formaattiin
ja vaikkapa tallentamaan levylle siten, ett¨a tietoa ei varmasti h¨avi¨a miss¨aa¨ n kohtaa.
XML:n k¨aytt¨amisest¨a olisi hy¨oty¨a my¨os kolmannessa vaiheessa. Aineistoja lajiteltaessa
niihin mahdollisesti teht¨av¨at haut voitaisiin tehd¨a XML:n XPath-kielen avulla. Samoin
aineistojen v¨aliset linkit voitaisiin tallentaa tavalla, joka ainakin l¨aheisesti muistuttaisi
XML:n XPath-kielt¨a.
Tulosten j¨alkik¨asittely tulee v¨akisinkin olemaan palvelimen v¨ahiten geneerinen osio,
sill¨a tyypillisesti j¨alkik¨asittelij¨alt¨a haluttu toiminnallisuus riippuu t¨aysin l¨ahdeaineistosta
ja halutusta lopputuloksesta. J¨alkik¨asittelij¨oist¨a pit¨anee koostaa staattinen luokka, johon
tulee kokoelma kentt¨akohtaisia ty¨okaluja, joita kutsutaan tarpeen mukaan, kun aineisto
muunnetaan asiakkaan vaatimalle rakenteelle. J¨alkik¨asittelyn asetuksia varten tarvitaan
oma tietokantataulu.
¨
LUKU 3. PAIKKATIETOVALITYSPALVELIMEN
SUUNNITTELU
3.6
32
Tietokanta- ja luokkarakenteen suunnittelua
Geneeriseen paikkatietov¨alityspalvelimeen pit¨aa¨ voida tallentaa erilaisten aineistojen parametreja siten, ett¨a se osaa luoda niihin merkityn tyypin perusteella oikeanlaisen luokan
hoitamaan aineiston k¨asittely¨a. Koska erityyppisill¨a aineistoilla voi olla t¨aysin erilaisia
parametreja, niille annettavat asetukset t¨aytyy tallentaa omaan tietokantatauluunsa. T¨all¨oin
varsinaiseen aineistot sis¨alt¨av¨aa¨ n tauluun tulisi vain aineiston yksil¨oiv¨a tunniste sek¨a sen
nimi ja tyyppi. N¨aiden lis¨aksi tarvitaan mekanismi, jonka avulla palvelin osaa valita oikeat
aineistot k¨aytt¨aj¨an antamien tietojen perusteella. Yksinkertaisin tapa t¨ah¨an on luoda omaksi
taulukseen asiasanalista, jossa erilaiset hakusanat linkitet¨aa¨ n aineistoihin.
Aineistojen valinnan j¨alkeen palvelimen pit¨aa¨ luoda niiden tyypin mukaiset oliot.
Olioiden luonti onnistuu Tehdas-nimist¨a (Factory) suunnittelumallia hy¨odynt¨am¨all¨a. Mallin
ideana on luoda erityinen tehdasluokka, joka osaa sille annettujen parametrien perusteella
luoda oikeanlaisia olioita [29]. Aineistotehtaaseen voitaisiin eriytt¨aa¨ kaikki logiikka, joka
tarvitaan, kun tietokannasta l¨oytyvien tietojen perusteella haluttaisiin luoda aineiston
tyyppi¨a vastaava luokka, ja alustaa se sopivilla parametreilla.
Aineistojen yhten¨aist¨a esitt¨amist¨a varten palvelimeen tarvitaan rajapinta, jonka erityyppiset aineistot toteuttavat. Selke¨asti jokaiselle erilaiselle aineistotyypille tarvitaan oma,
t¨am¨an rajapinnan toteuttava luokka. Lis¨aksi tarvitaan yksi yleinen aineistoluokka, jota
palvelin voi k¨aytt¨aa¨ muodostaessaan uusia aineistoja muualta haetuista. Aineistoluokkien
toteutus onnistuu Edustaja-nimisen (Proxy) suunnittelumallin avulla. Mallissa on ideana
k¨aytt¨aa¨ erityisi¨a edustajaluokkia, jotka hoitavat esimerkiksi verkkoliikenteen k¨asittely¨a
l¨apin¨akyv¨asti. Sis¨aisesti edustajaluokat k¨asittelev¨at edustamansa luokan olioita, ja kutsuvat
esimerkiksi sen funktioita erilaisissa operaatioissa [31]. Edustajan toimintaideaa ja k¨aytt¨oa¨
t¨ass¨a tapauksessa esitell¨aa¨ n kuvassa 3.2.
Palvelimen halutaan toimivan oikein my¨os silloin, kun aineiston l¨ahde ei tue asiakkaan
haluamaa koordinaattij¨arjestelm¨aa¨ . K¨ayt¨ann¨oss¨a siis palvelimen pit¨aa¨ kyet¨a tekem¨aa¨ n
asiakkaalle l¨apin¨akyv¨asti muunnoksia eri koordinaattij¨arjestelmien v¨alill¨a. Muunnosta
¨
LUKU 3. PAIKKATIETOVALITYSPALVELIMEN
SUUNNITTELU
33
Asiakas
«interface»
Aineisto
+haeTulokset()
Aineisto
+haeTulokset()
WMSAineisto
WFSAineisto
-aineisto : Aineisto
-aineisto : Aineisto
+haeTulokset()
+haeTulokset()
Kuva 3.2: Periaatekuva edustaja-suunnittelumallin k¨ayt¨ost¨a aineistoluokissa. T¨ass¨a mallissa luokat
WMSAineisto ja WFSAineisto ovat edustajia, jotka sis¨aisess¨a toteutuksessaan hakevat tietoa
protokollansa vaatimalla tavalla ja alustavat sis¨alt¨am¨ans¨a Aineisto-luokan olion saadulla datalla.
Asiakkaan kutsuessa haeTulokset()-funktiota edustajaluokat kutsuvat Aineisto-luokan
toteutusta.
voidaan tarvita kahdessa kohdassa: palvelimen tehdess¨a kyselyj¨a aineistoihin k¨aytt¨aj¨an
antamien koordinaattien perusteella sek¨a tuloksia vastaanotettaessa. N¨aiden molempien
muunnosten tekeminen on selke¨asti edustajaluokan teht¨av¨a, sill¨a suunnittelumallin idean
mukaisesti kyseisen luokan olio on ainoa j¨arjestelm¨an kohta, joka tiet¨aa¨ mit¨aa¨ n aineiston
l¨ahteest¨a. J¨arjestelm¨an sis¨all¨a toimittaessa koordinaatit olisi hyv¨a pit¨aa¨ aina yhdenmukaisessa j¨arjestelm¨ass¨a, jotta ep¨am¨aa¨ r¨aisi¨a tiloja ei voisi synty¨a esimerkiksi eri aineistoja
yhdistett¨aess¨a. T¨aten luokan kannattaa tehd¨a muunnos v¨alitt¨om¨asti tulosten vastaanottamisen j¨alkeen. Varsinaisessa koordinaattimuunnoksessa tarvittavat ty¨okalut voidaan erist¨aa¨
omaan luokkaansa, joka k¨aytt¨aa¨ esimerkiksi PostGIS:iin kuuluvia muunnosfunktioita.
XML:n k¨aytt¨aminen j¨arjestelm¨an sis¨aisen¨a formaattina tekisi my¨os koordinaattidatan
etsimisest¨a tuloksista helppoa, sill¨a koordinaatteja sis¨alt¨av¨at kohdat voitaisiin hakea yksinkertaisilla XPath-hauilla. Vastaavasti aineistojen yhdist¨aminen yhten¨aisen tulosjoukon
luomiseksi onnistuisi niin ik¨aa¨ n XPath-hakujen avulla. Kahden aineiston v¨alinen yhteys
voitaisiin toteuttaa yksinkertaisesti tallentamalla tietokantaan kahtena XPathina tieto siit¨a,
mitk¨a kent¨at aineistoja yhdist¨av¨at.
Tulosten j¨alkik¨asittelyss¨a teht¨av¨at operaatiot riippuvat luonnollisesti t¨aysin siit¨a, mihin
k¨aytt¨oo¨ n tuloksia halutaan. Koska j¨alkik¨asittelyss¨a teht¨av¨at operaatiot voivat vaihdella
hyvinkin paljon, j¨alkik¨asittelij¨amoduulit tulevat olemaan j¨arjestelm¨an n¨ak¨okulmasta yk-
¨
LUKU 3. PAIKKATIETOVALITYSPALVELIMEN
SUUNNITTELU
34
sinkertaisia luokkia, jotka ainoana julkisena operaationaan palauttavat vastaanottamansa
tulosjoukon k¨asiteltyn¨a.
Esimerkiksi MIP:n kiinteist¨olomakkeen automaattisessa t¨aydent¨amisess¨a on tarkkaan
ottaen kyse tulosten muuntamisesta rakennusinventointien tietokannan taulun kiinteist¨
o kenttien mukaisiksi. T¨at¨a toimintoa varten tarvitaan oma tietokantataulu, johon tallennetaan tieto siit¨a, mik¨a tulosaineiston kentt¨a vastaa mit¨akin paikallisen tietokannan
kohtaa. Kenttien nimien sovittamisen lis¨aksi operaatiota suorittavan j¨alkik¨asittelyluokan
t¨aytyy osata k¨asitell¨a my¨os niiden arvoja, sill¨a esimerkiksi kiinteist¨otunnukseen pit¨aa¨ lis¨at¨a
v¨aliviivat. N¨am¨a toiminnot voidaan koostaa yhteen luokkaan funktiokokoelmaksi, ja kunkin kent¨an kohdalla kutsuttavan funktion nimi voidaan tallentaa kenttien nimi¨a linkkaavaan
tauluun omaksi kent¨akseen.
J¨alkik¨asittelyn j¨alkeen palvelimen t¨aytyy viel¨a muuntaa data asiakkaan haluamaan
formaattiin ennen sen palauttamista. T¨ass¨a vaiheessa suoritetaan prototyypin XML-olioita
PHP:n assosiatiiviseksi taulukoksi muuntavan funktion kaltaisia yksinkertaisia operaatioita,
jotka nekin kannattaa erist¨aa¨ omiin luokkiinsa.
Kaikkia palvelimen toimintoja yhdist¨aa¨ liukuhihnamainen ajattelu, jossa tietoa etenee dynaamisesti valittavalta moduulilta toiselle. K¨ayt¨ann¨oss¨a eri moduulit voivat toimia
itsen¨aisesti v¨alitt¨am¨att¨a siit¨a, mit¨a aikaisemmat aineistojoukon k¨asittelij¨at ovat sille tehneet, joten niiden ei tarvitse olla tietoisia toisistaan. Moduulien ulkopuolisen palvelintoteutuksen teht¨av¨aksi j¨aa¨ siis k¨ayt¨ann¨oss¨a oikeiden moduulien ja niiden asetusten sek¨a
suoritusj¨arjestyksen alustus kulloinkin haluttua operaatiota varten.
Luku 4
Paikkatietov¨alityspalvelimen toteutus
T¨ass¨a ty¨oss¨a kehitett¨av¨alle ty¨okalulle annettiin englanniksi paikkatietov¨alitt¨aj¨aa¨ tarkoittava nimi: Geographic Information Proxy, lyhyemmin GIProxy. Integroinnin helpottamiseksi palvelin p¨aa¨ tettiin toteuttaa samoilla tekniikoilla kuin Museon informaatioportaali.
Niinp¨a ohjelmisto on toteutettu kokonaisuudessaan PHP 5.3:lla. Tietokantapalvelimena
k¨aytet¨aa¨ n PostgreSQL:¨aa¨ , ja yhteys tietokantaan abstrahoidaan luokiksi PEAR-kirjaston
DB DataObject-luokilla.
Seuraavissa kohdissa k¨ayd¨aa¨ n l¨api palvelimen toteutusta. Ensin k¨ayd¨aa¨ n l¨api palvelimen arkkitehtuuria ja variaatiopisteit¨a yleisell¨a tasolla. Sitten esitell¨aa¨ n palvelimen
k¨aytt¨am¨aa¨ tietokantarakennetta ja sen j¨alkeen luokkien rakennetta yleisesti. Seuraavaksi k¨ayd¨aa¨ n tarkemmin l¨api aineistoluokkien ja erilaisia toiminnallisuuksia kapseloivien
moduulien toteutusta. Lopuksi esitell¨aa¨ n palvelimen k¨aytt¨oa¨ ja sen toimintaa k¨ayt¨ann¨oss¨a.
Paikkatietov¨alityspalvelin on lisensoitu Creative Commons Nime¨a 3.0 Muokkaamaton -lisenssill¨a1 , ja se on saatavilla osoitteesta https://github.com/tjkaal/
GIProxy.
1
Creative Commons Attribution 3.0 Unported Licence (http://creativecommons.org/
licenses/by/3.0/)
¨
LUKU 4. PAIKKATIETOVALITYSPALVELIMEN
TOTEUTUS
4.1
36
J¨arjestelm¨an arkkitehtuuri ja variaatiopisteet
J¨arjestelm¨an suunnittelun mallina on k¨aytetty tietovuoarkkitehtuuria (Pipes and Filters),
jonka ideana on jakaa suoritettava teht¨av¨a pienempiin kokonaisuuksiin, jotka voidaan ratkoa erikseen. Tietovuoarkkitehtuuri soveltuu hyvin t¨am¨an palvelimen kaltaisiin tietovirran
j¨asent¨amiseen ja jalostamiseen tarkoitettuihin j¨arjestelmiin. Mallissa j¨arjestelm¨a koostuu
dataa k¨asittelevist¨a toisistaan riippumattomista komponenteista (filters) ja niiden v¨alill¨a
tietoa kuljettavista putkista (pipes). Tietoa on tarkoituksena kuljettaa jatkuvana virtana
komponenttien l¨api siten, ett¨a seuraava komponentti voi aloittaa datan k¨asittelyn jo ennen kuin edellinen on saanut omaa suoritustaan t¨aysin valmiiksi. Suorituksessa voi olla
my¨os useita haaroja, sill¨a yhdelt¨a komponentilta saatu data voidaan ohjata usealle muulle
komponentille. [32]
Palvelimen toteutus perustuu tietovuoarkkitehtuurin yksinkertaistettuun versioon, liukuhihna-arkkitehtuuriin (pipeline architecture), jossa tietovirta etenee haarautumatta [29].
J¨arjestelm¨ass¨a suodattimia vastaavat operaatiot, joita avoimena olevien aineistojen joukolle
tehd¨aa¨ n. Mallin perusajatuksesta poiketen tietoa ei k¨asitell¨a virtana, vaan seuraavan operaation suorittaminen aloitetaan vasta kun edellinen on saatu valmiiksi. T¨aten palvelimessa ei
ole my¨osk¨aa¨ n k¨ayt¨oss¨a varsinaisia putkia, vaan tieto kulkee suoraan eri operoijien v¨alill¨a.
Palvelimen yleist¨a arkkitehtuuria esitell¨aa¨ n kuvassa 4.1.
Palvelimen keskeinen variaatiopiste liittyy moduuleiksi kutsuttuihin luokkiin, jotka
vastaavat erilaisten avoimena olevien aineistojen joukolle teht¨avien operaatioiden kapseloinnista. Suoritusvaiheessa yksitt¨aiselle moduulille annetaan parametreina k¨aytt¨aj¨alt¨a
tulleet asetukset ja avoimien aineistojen joukko, jonka j¨alkeen moduuli voi periaatteessa
tehd¨a mit¨a tahansa operaatioita – j¨arjestelm¨an arkkitehtuuri ei sin¨ans¨a rajoita niiden toteutusta lainkaan. Moduulit voivat esimerkiksi lis¨at¨a uusia aineistoja k¨asitelt¨aviin, hakea tietoa
aineistoista, muokata niit¨a ja palauttaa tietoa asiakkaalle erilaisissa formaateissa. Koska
moduulit toimivat toisistaan riippumattomasti, yksitt¨aist¨a moduulia on helppo muokata tai
se voidaan korvata kokonaan ilman, ett¨a muiden moduulien toiminta h¨airiintyy.
¨
LUKU 4. PAIKKATIETOVALITYSPALVELIMEN
TOTEUTUS
Asiakas
Moduulien suorituskutsuja,
asetuksia
37
Tuloksia halutussa
formaatissa
GIProxy
Moduulit
Kapseloivat erilaisia avoimien aineistojen joukolle tehtäviä
operaatioita: avaavat aineistoja, tekevät hakuja, käsittelevät tuloksia
Parametrikyselyt
AineistojenAineistojen
käsittelyssä
tarvittaviaparametreja
parametreja
Hakuparametreja,
tuloskyselyjä
Aineistoluokat
Tietokantaluokat
Toteuttavat tietokanta-abstraktion oliopohjaisesti
Vastaavat erityyppisten aineistojen esittämisestä
yhdenmukaisessa formaatissa
PostGIS
SQL-kyselyt
Tuloksia
SHP
WFS
WMS
Tulokset
PostgreSQL-tietokanta
WWW
Palvelimen
tiedostojärjestelmä
Kuva 4.1: Paikkatietov¨alityspalvelimen arkkitehtuurikuvaus. Kuvaan on merkitty potentiaalisina
aineistotyyppein¨a my¨os PostGIS ja SHP, joita ei kuitenkaan ole t¨am¨an ty¨on laajuudessa toteutettu
palvelimeen.
Toisen keskeisen variaatiopisteen muodostavat erilaiset aineistoluokat. Ne on toteutettu Edustaja-suunnittelumallia k¨aytt¨aen siten, ett¨a eri aineistotyyppej¨a edustavat luokat
k¨aytt¨av¨at sis¨aisess¨a toteutuksessa hyv¨akseen j¨arjestelm¨an paikallista aineistoa edustavaa
luokkaa. Suunnittelumalli yksinkertaistaa uusien aineistotyyppien lis¨aa¨ mist¨a: uutta aineistotyyppi¨a lis¨att¨aess¨a siihen tarvitsee k¨ayt¨ann¨oss¨a toteuttaa vain toiminnallisuudet, jotka
hakevat tietoa ja muuntavat sit¨a j¨arjestelm¨an sis¨aiseen formaattiin.
Vaikka palvelimen nykyinen toteutus perustuu PostgreSQL-tietokantaan, sit¨a ei sin¨ans¨a
ole mitenk¨aa¨ n erityisen vahvasti sidottu mihink¨aa¨ n tiettyyn tietokantaj¨arjestelm¨aa¨ n tai
-rakenteeseen. Esimerkiksi aineistoluokat ovat itsess¨aa¨ n t¨aysin tietokantariippumattomia,
sill¨a kunkin aineiston parametrien hakemisen ja sit¨a vastaavan luokan alustamisen hoi-
¨
LUKU 4. PAIKKATIETOVALITYSPALVELIMEN
TOTEUTUS
38
taa oma tehdasluokkansa, joka nykytoteutuksessaan hakee n¨am¨a tiedot tietokantaluokilta.
N¨aihin luokkiin on eristetty kaikki tietokantoihin liittyv¨a toiminnallisuus, joten jos tietokantaan tai tietokantaj¨arjestelm¨aa¨ n halutaan tehd¨a muutoksia, se onnistuu vain n¨ait¨a
luokkia muuttamalla.
4.2
Tietokantarakenne
Palvelimen tietokantarakennetta esitell¨aa¨ n kuvassa 4.2. Tietokanta muodostuu aineistojen
tietoja sis¨alt¨avist¨a tauluista ja eri moduulien tarvitsemista tauluista.
dataset_link
primary_dataset_id
Integer
Varchar
primary_dataset_xpath
secondary_dataset_id
Integer
secondary_dataset_xpath Varchar
NN (PFK)
NN
NN (PFK)
NN
the_primary_dataset_links_to_the_second
the_secondary_dataset_is_linked_to_the_primary
a_dataset_has_settings
a_dataset_is_categorized_by_keywords
dataset_settings
dataset_id Integer NN (PFK)
category Varchar NN (PK)
name
Varchar NN (PK)
value
Varchar NN
id
identifier
name
type
dataset
Serial
NN (PK)
Varchar NN
(AK1)
Varchar NN
Varchar NN
dataset_keyword
dataset_id Integer NN (PFK)
keyword
Varchar
(PK)
Integer NN
priority
the_features_of_a_dataset_are_wrapped
dataset_feature_wrap
dataset_id
Integer NN
feature_xpath
Varchar NN
target_identier
Varchar NN
target_feature
Varchar NN
post_processor Varchar
(PFK)
(PK)
(PK)
(PK)
Kuva 4.2: Paikkatietov¨alityspalvelimen tietokantarakenne. Taulun dataset settings attribuutissa value k¨aytet¨aa¨ n yksiulotteista taulukkoa.
Tietokannan keskeisin taulu on aineistojen yleiset tiedot sis¨alt¨av¨a dataset. Jokaisesta aineistosta tallennetaan sen selv¨akielinen nimi ja tyyppi, jota k¨aytet¨aa¨ n esimerkiksi
edustajaluokkaa valittaessa. Lis¨aksi aineistoista tallennetaan j¨arjestelm¨an teknisess¨a toteutuksessa k¨aytett¨av¨a juokseva sarjanumero id sek¨a lyhyt selv¨akielinen uniikki tunniste
identifier, jota voidaan k¨aytt¨aa¨ esimerkiksi silloin, kun aineistoja halutaan valita
suoraan tai vaikkapa lokitiedostoissa.
¨
LUKU 4. PAIKKATIETOVALITYSPALVELIMEN
TOTEUTUS
39
Aineistokohtaiset asetukset tallennetaan dataset settings-tauluun. Jokaisella aineiston asetuksella on nimi ja mahdollisesti monta eri arvoa. Kohtaa category k¨aytet¨aa¨ n
asetusten luokitteluun niiden k¨aytt¨okohteen mukaan. T¨aten esimerkiksi WFS-tyyppisiss¨a
aineistoissa asetukset on jaettu luokkiin wfs ja system sen mukaan, tarvitaanko niit¨a
WFS-kyselyiss¨a vai ovatko ne aineiston yleisi¨a asetuksia.
Muita tietokannan tauluja k¨aytet¨aa¨ n moduulikohtaisten toiminnallisuuksien toteutuksessa. Taulu dataset keyword sis¨alt¨aa¨ aineistoja haettaessa k¨aytett¨av¨at asiasanat ja
niiden prioriteetit. Asiasanojen prioriteetin asettaminen on t¨arke¨aa¨ ; esimerkiksi MIP:ssa
kiinteist¨otietoja etsitt¨aess¨a halutaan l¨oyt¨aa¨ ensin Kiinteist¨otietojen kyselypalvelu ja vasta
sen j¨alkeen Rakennustietojen kyselypalvelu, kun taas rakennustietoja etsitt¨aess¨a tilanne on
p¨ainvastainen. J¨arjestyksell¨a on v¨ali¨a muun muassa aineistoja yhdistett¨aess¨a, sill¨a kahden
aineiston keskin¨ainen j¨arjestys m¨aa¨ r¨aa¨ niiden ensi- ja toissijaisuuden.
Aineistojen v¨aliset yhteydet tallennetaan dataset link-tauluun XPath-hakuina.
Taulua dataset feature wrap k¨aytet¨aa¨ n, kun aineistot halutaan sovittaa halutunlaisiksi. Tauluun tallennetaan XPath-hakuna aineiston kentt¨a, kohteen tunniste (kuten kiinteist¨olomake), kohteen ominaisuuden nimi. Lis¨aksi tallennettaan mahdollisesti j¨alkik¨asittelyss¨a k¨aytett¨av¨an funktion nimi. Palvelimen nykytoteutuksessa t¨am¨a viittaa j¨alkik¨asittelyst¨a
vastaavan luokan staattiseen funktioon, joka saa parametrinaan kent¨an sis¨all¨on, jonka se
muuntaa kohteelle sopivaksi.
4.3
Luokkarakenne
Paikkatietov¨alityspalvelimen ytimen muodostaa GIProxy-niminen luokka, jonka hallinnoi avoimena olevien aineistojen joukkoa ja vastaa muiden palvelimeen kuuluvien
luokkien operoinnista. Erilaiset toiminnallisuudet on eristetty moduuleiksi kutsuttuihin,
nimiavaruudessa GIProxy\module sijaitseviin luokkiin, erityyppisten aineistojen luokat sijaitsevat GIProxy\dataset-nimiavaruudessa ja vastaavasti tietokantayhteydest¨a
¨
LUKU 4. PAIKKATIETOVALITYSPALVELIMEN
TOTEUTUS
40
vastaavien luokkien nimiavaruus on GIProxy\db. N¨aiden lis¨aksi palvelimeen kuuluu
yleisk¨aytt¨oisi¨a luokkia, jotka kuuluvat suoraan GIProxy-nimiavaruuteen. Palvelimen
luokkarakennetta esitell¨aa¨ n kuvassa 4.3.
J¨arjestelm¨ass¨a on kolme yleisk¨aytt¨oist¨a luokkaa. Luokka Config tarjoaa koko palvelimen laajuudella tarvittavien asetusten hallinnan staattisten funktioiden avulla. Asetusluokan lis¨aksi kahta tehdasta, aineistojen luonnissa k¨aytett¨av¨aa¨ luokkaa DatasetFactory
ja moduuleja luovaa luokkaa ModuleFactory pystyy k¨aytt¨am¨aa¨ n mist¨a tahansa.
Erilaiset aineistoille teht¨av¨at operaatiot on eristetty omiin rajapinnan ModuleInterface toteuttaviin luokkiinsa, joita kutsutaan moduuleiksi. J¨arjestelm¨an moduulit
ovat toisistaan t¨aysin riippumattomia; ne suorittavat operaationsa toisistaan erill¨aa¨ n, eiv¨atk¨a
ne voi kutsua toisiaan ajon aikana. Moduulit eiv¨at my¨osk¨aa¨ n mist¨aa¨ n saa tietoa siit¨a, mit¨a
operaatioita aineistoille on suoritettu aikaisemmin.
4.4
Aineistoluokkien toteutus
Eri aineistoluokat vastaavat erityyppisten aineistojen hakemisesta ja muuntamisesta palvelimen sis¨aiseen formaattiin, joksi valittiin esimerkiksi WFS-protokollan k¨aytt¨am¨a GML. Jokainen aineistoluokka toteuttaa DatasetInterface-nimisen rajapinnan, joka m¨aa¨ ritt¨aa¨
julkiset funktiot, joilla moduulit operoivat aineistoja.
Aineistoluokkien toteutuksen ydin on j¨arjestelm¨an sis¨aist¨a aineistoa edustava Dataset,
jota k¨aytet¨aa¨ n muista aineistoluokista Edustaja-nimisen suunnittelumallin kautta. K¨ayt¨ann¨oss¨a t¨am¨a tarkoittaa sit¨a, ett¨a Dataset-luokan olio ei itsen¨aisesti pysty hakemaan
tuloksia eik¨a yksik¨aa¨ n tietokannasta haettava aineisto voi olla suoraan sen tyyppinen.
Sen sijaan tarkoituksena on, ett¨a eri aineistoluokat k¨aytt¨av¨at sis¨aisesti Dataset-luokan
oliota. T¨all¨oin aineistotyypin mukaisen luokan t¨aytyy t¨aysin itsen¨aisesti toteuttaa vain rajapinnan fetchResults()-funktio. Lis¨aksi luokan t¨aytyy luonnollisesti osata muuntaa
hakemansa tulokset palvelimen sis¨aiseen formaattiin.
¨
LUKU 4. PAIKKATIETOVALITYSPALVELIMEN
TOTEUTUS
GIProxy
ModuleFactory
«interface»
module\ModuleInterface
+run()
-datasets
+__construct()
+run()
41
+create()
module\FetchResultsByCoordinates
1
*
module\FindDatasetsByKeyword
«interface»
dataset\DatasetInterface
+__construct()
+fetchResults()
+getAllResults()
+addResults()
+getDatasetId()
+getSettings()
+getSetting()
+transformCoordinates()
DatasetFactory
module\LoadDataset
+create()
+createByIdentifier()
-loadClass()
module\MergeDatasets
-createMergedDataset()
-mergeResults()
dataset\Dataset
-settings
-results
dataset\WFS
-dataset
dataset\WMS
module\OutputHTML
-dataset
#boundingBoxStringFromPoint()
-simpleXMLToArray()
-flattenArray()
-readableArray()
-prettyTitle()
-utf8_ucfirst()
-htmlArray()
-outputArray()
+doOffset()
«uses»
«uses»
module\OutputJson
-simpleXMLToArray()
Config
module\SetOutputCoordinateSystem
-outputCoordinateSystem
+get()
+set()
module\WrapDatasets
-wrapDataset()
-itemToString()
-addHyphensToEstateIdentifier()
-prettyName()
-parseGMLPoint()
-parseRHRAddress()
-parseRHROwner()
db\Dataset
+getSettings()
+getType()
+getById()
+getByIdentifier()
db\DatasetSettings
+getSettingsByDatasetId()
+valueToArray()
db\DatasetLink
db\DatasetKeyword
+getLinksOfDataset()
+findDatasetsByKeyword()
db\DatasetFeatureWrap
+getWrapsOfDataset()
+getXPath()
Kuva 4.3: Paikkatietov¨alityspalvelimen luokkarakenne. P¨aa¨ luokkaa lukuun ottamatta kaikki luokat kuuluvat GIProxy-nimiavaruuteen. Moduuliluokat k¨asittelev¨at
dataset\DatasetInterface-rajapinnasta perittyj¨a olioita, mutta selkeyden vuoksi
sit¨a ei ole merkitty t¨ah¨an kuvaan. Kuvaan ei ole my¨osk¨aa¨ n merkitty rajapinnoista toteutettuja
funktioita.
¨
LUKU 4. PAIKKATIETOVALITYSPALVELIMEN
TOTEUTUS
42
Palvelimeen toteutettiin kaksi varsinaista aineistoluokkaa, WFS ja WMS. Jotta tuloksien hakeminen pelk¨an pisteen avulla onnistuisi, WFS-luokkaan toteutettiin apufunktio,
joka muuntaa pisteen neli¨onmuotoiseksi karttarajaukseksi tietokantaan asetetun pinta-alaasetuksen mukaisesti. WMS-protokollasta toteutettiin vain aineistojen metatietoja tarjoava
GetFeatureInfo-kysely, sill¨a palvelin k¨asittelee nykytoteutuksessaan vain tekstimuotoista dataa; karttakuvien v¨alityst¨a ei t¨ass¨a ty¨oss¨a k¨asitell¨a.
Aineistojen luonnissa palvelin k¨aytt¨aa¨ DatasetFactory-nimist¨a tehdasta, joka
osaa luoda sille sy¨otetyn aineiston sarjanumeron tai selv¨akielisen tunnisteen perusteella
oikeantyyppisen aineistoluokan. Tehdas vastaa my¨os aineistokohtaisten asetusten hakemisesta.
Koordinaattien muunnos tehd¨aa¨ n Dataset-luokassa. Vaikka muunnos saattaa olla
h¨avi¨ollinen, se p¨aa¨ tettiin tehd¨a aina tuloksia haettaessa ja ulostulokoordinaattij¨arjestelm¨aa¨
vaihdettaessa. N¨ain v¨altet¨aa¨ n ep¨am¨aa¨ r¨aiset tilat, joita voisi synty¨a esimerkiksi silloin, kun
kahta eri j¨arjestelm¨ass¨a olevaa aineistoa koetetaan yhdist¨aa¨ .
4.5
Toiminnallisuuksien toteutus
Palvelun kaikki aineistoille teht¨av¨at operaatiot on toteutettu ModuleInterface-rajapinnan toteuttavissa luokissa, joita siis kutsutaan moduuleiksi. Niiden toteutuksessa on
tarkoituksena se, ett¨a yksitt¨ainen moduuli tekee aineistoilla yhden yksinkertaisen, nimens¨a
mukaisen operaation. K¨ayt¨ann¨oss¨a t¨at¨a varten rajapinta tarjoaa yhden funktion, joka
saa parametreinaan asiakkaan moduulille antamat parametrit ja palvelimen k¨asittelyss¨a
olevat aineistot. T¨at¨a ty¨ot¨a varten palvelimeen toteutetut moduulit listataan taulukossa 4.1
lyhyiden kuvausten kanssa.
Moduuleja suoritetaan siis toisistaan riippumattomasti, eik¨a yksitt¨ainen moduuli tied¨a
mit¨a operaatioita aineistoille on aikaisemmin tehty. Luonnollisesti moduulien suoritusj¨arjestys vaikuttaa kuitenkin siihen, mit¨a operaatioita ne pystyv¨at aineistoille tekem¨aa¨ n
¨
LUKU 4. PAIKKATIETOVALITYSPALVELIMEN
TOTEUTUS
43
Taulukko 4.1: Palvelimen moduulit ja niiden kuvaukset.
Moduuli
FetchResultsByCoordinates
FindDatasetsByKeyword
LoadDataset
MergeDatasets
OutputHTML
OutputJson
SetOutputCoordinateSystem
WrapDatasets
Kuvaus
Hakee avoimista aineistoista tietoja koordinaattien perusteella.
Etsii aineistoja hakusanan perusteella.
Hakee aineiston sen tunnisteen perusteella.
Yhdist¨aa¨ aineistoja.
Tuottaa avoimista aineistoista HTML:n taulukon.
Tuottaa avoimista aineistoista JSON-taulukon.
Asettaa palvelimen ulostulokoordinaattij¨arjestelm¨an,
muuntaa aikaisemmin haetut tulokset uuteen
j¨arjestelm¨aa¨ n.
Sovittaa aineistoja halutulle kohteelle.
– esimerkiksi kiinteist¨olomakkeelle sovittamisen j¨alkeen aineistoja tuskin pystyy en¨aa¨
yhdistelem¨aa¨ n.
Suoritusvaiheessa moduulille annetaan parametreita palvelimen k¨asittelyss¨a olevien
aineistojen joukko ja asiakkaalta saadut parametrit. Tyypillinen moduuli k¨ay yksi kerrallaan aineistoja l¨api ja suorittaa nimens¨a mukaisia operaatioita niille. Esimerkiksi SetOutputCoordinateSystem kutsuu yksi kerrallaan jokaisen aineiston transformCoordinates()-funktiota.
Muut palvelinta varten toteutetut moduulit voidaan jaotella aineistoja sek¨a tuloksia
hakeviin, tuloksia k¨asitteleviin ja tuloksia palauttaviin. Tyypillisesti ensimm¨aisen¨a ajetaan
moduuleja, joilla haetaan aineistoja. T¨allaisia moduuleita palvelimessa ovat aineistoja
hakusanalla hakeva FindDatasetsByKeyword ja yksitt¨aisen aineiston sen tunnisteen perusteella avaava LoadDataset. Molemmat moduulit lis¨aa¨ v¨at uudet aineistot jo
k¨asittelyss¨a olevien aineistojen joukon loppuun.
Tulosten hakemista varten palvelimessa on yksi moduuli, FetchResultsByCoordinates, jolle annetaan parametreina pisteen x- ja y-koordinaatit sek¨a koordinaattij¨arjestelm¨a. Moduuli k¨ay yksitellen l¨api kaikki avoimet aineistot, ja kutsuu jokaisen
aineistoluokan tietojen hausta vastaavaa funktiota. Jos aineistoista on haettuna tuloksia jo
ennest¨aa¨ n, uudet lis¨at¨aa¨ n niiden j¨alkeen.
¨
LUKU 4. PAIKKATIETOVALITYSPALVELIMEN
TOTEUTUS
44
Aineistojen ja tulosten k¨asittely¨a varten palvelimeen toteutettiin kolme moduulia. Niist¨a
MergeDatasets yhdist¨aa¨ aineistoja palvelimeen etuk¨ateen tallennettujen tietojen perusteella. Yksi kerrallaan moduuli ottaa k¨asittelyyns¨a kunkin aineiston ja tarkistaa, l¨oytyyk¨o
siit¨a linkki¨a johonkin muista avoimista aineistoista. Jos yhdistyskohta l¨oytyy, moduuli k¨ay
l¨api molempien aineistojen tulokset ja yhdist¨aa¨ niist¨a uuden aineiston. Oletuksena aineistot
yhdistet¨aa¨ n siten, ett¨a ensisijaisesta aineistosta otetaan kaikki tulokset, ja toissijaisesta vain
ne, jotka t¨asm¨aa¨ v¨at ensisijaisen tietoihin. Lopuksi alkuper¨aiset aineistot poistetaan avoimien aineistojen joukosta ja korvataan yhdistetyll¨a. Jos aineistolle ei l¨oydy paria muista
aineistoista, se j¨atet¨aa¨ n tulosjoukkoon sellaisenaan.
Toinen tuloksia k¨asittelev¨a moduuli WrapDatasets tuottaa aineistoista asiakkaan
haluamalle kohteelle sovitettuja kokonaisuuksia. Se etsii aineistojen tuloksista etuk¨ateen
m¨aa¨ ritettyj¨a kentti¨a sek¨a nime¨aa¨ ja j¨alkik¨asittelee niit¨a kohteen vaatimusten mukaisesti
luoden n¨ain uusia aineistoja.
Tulosten palauttamista varten palvelimessa on kaksi moduulia, joista OutputJson
yksinkertaisesti muuntaa XML-datan JSON-taulukoksi. OutputHTML:n toteutus sen sijaan on hieman monimutkaisempi, sill¨a se yritt¨aa¨ muuntaa tuloksia helpommin luettavaan
muotoon. K¨ayt¨ann¨oss¨a moduuli k¨ay rekursiivisesti tietorakennetta l¨api tavoitteenaan ”litist¨aa¨ ” moniulotteisia rakenteita yksinkertaiseksi yksiulotteiseksi avain-arvo-taulukoksi,
jotta siit¨a voitaisiin helposti luoda HTML:n table-elementti¨a k¨aytt¨av¨a selke¨a taulukko.
4.6
Palvelimen toiminta ja sen k¨aytt¨o
Palvelimen toimintaa ohjataan kutsumalla eri moduuleja sen nimikkoluokasta luodun instanssin kautta halutussa j¨arjestyksess¨a halutuilla parametreilla. Esimerkiksi tiedon hakeminen JSON-muodossa Kiinteist¨otietojen kyselypalvelusta pisteest¨a 100, 200 (EPSG:3067).
1
2
3
4
5
$proxy = new GIProxy();
$proxy->run("LoadDataset", array(
"identifier" => "mml_kiinteistotiedot"
));
$proxy->run("FetchResultsByCoordinates", array(
¨
LUKU 4. PAIKKATIETOVALITYSPALVELIMEN
TOTEUTUS
6
7
8
9
10
11
12
45
"type" => "point",
"coordinateSystem" => "EPSG:3067",
"coordinates" => array(100, 200)
));
$proxy->run("OutputJson", array(
"writeHeader" => true
));
Listauksen suoritus palvelimessa on kuvattuna kuvan 4.4 sekvenssikaaviossa. Kuten kuvasta voidaan havaita, GIProxy-luokan run()-funktio kutsuu ensimm¨aiseksi
ModuleFactory-nimist¨a tehdasluokkaa, joka tarvittaessa lataa oikean luokan muistiin
ja sen j¨alkeen luo siit¨a olion. Luodun olion tehdas palauttaa p¨aa¨ luokalle.
Asiakas
new
GIProxy
run('LoadDataset', settings)
ModuleFactory
create(moduleName)
module\LoadDataset
DatasetFactory
dataset\WFS
new
module
run(settings, datasets)
createByIdentifier(ident)
datasets
dataset
response
new
module\FetchResults
run('FetchResults', settings)
create(moduleName)
new
module
run(settings, datasets)
fetchResults(settings)
datasets
response
module\OutputJson
run('OutputJson', settings)
create(moduleName)
new
module
response
run(settings, datasets)
getAllResults()
datasets
results
Kuva 4.4: Oheisen listauksen sekvenssikaavio. Selkeyden vuoksi kuvaan ei ole merkitty sit¨a,
miten DatasetFactory hakee aineistojen tiedot db\Dataset-luokalta. Kuvasta puuttuu my¨os
luokka dataset\Dataset, jota dataset\WFS k¨aytt¨aa¨ sis¨aisess¨a toteutuksessaan.
Seuraavaksi kutsutaan moduulin run()-funktiota, joka saa parametreikseen asiakkaalta aikaisemmin tulleet asetukset ja palvelimella avoimena olevat aineistot sis¨alt¨av¨an
taulukon. Listauksessa ensimm¨aisen¨a suoritettava moduuli LoadDataset siis lis¨aa¨ aineistoja k¨asitelt¨avien joukkoon niiden tunnisteen perusteella. Luokka kutsuu aineistoja
¨
LUKU 4. PAIKKATIETOVALITYSPALVELIMEN
TOTEUTUS
46
luovaa DatasetFactory-tehdasluokkaa, joka hakee aineiston tiedot tietokantaluokalta
db\Dataset, jonka j¨alkeen se moduulitehtaan tapaan lataa tarvittaessa aineistoluokan
muistiin ja luo oikeilla tiedoilla alustetun olion. Luotu olio palautetaan moduulille, joka
lis¨aa¨ sen aineistojoukon loppuun.
Seuraavaksi ajettava moduuli FetchResultsByCoordinates hakee tuloksia pisteest¨a kutsuen jokaisen avoimen aineiston fetchResults()-funktiota. Saadut tulokset
tulostetaan k¨aytt¨aj¨alle viimeisen¨a ajettavalla OutputJson-moduulilla, joka hakee tulokset avoimista aineistoista ja muuntaa ne JSON-taulukoksi.
Erilaisia virhetilanteita palvelin k¨asittelee nykytoteutuksessa siten, ett¨a se pyrkii ohittamaan ne. Esimerkiksi, jos yritet¨aa¨ n luoda aineistoa tai moduulia, jota ei ole olemassa,
suoritus luonnollisesti keskeytyy silt¨a osin. Muilta osin palvelimen toiminta ei t¨allaisessa
tilanteessa kuitenkaan h¨airiinny, vaan seuraavien moduulien suoritusta yritet¨aa¨ n jatkaa
normaalisti.
Luku 5
Tulokset ja niiden analyysi
T¨ass¨a ty¨oss¨a on siis ollut tavoitteena kehitt¨aa¨ paikkatietov¨alityspalvelin, joka tarjoaisi
geneeriset ty¨okalut paikkatietoaineistojen hallintaan ja k¨asittelyyn. Keskeisimm¨aksi tutkimuksen kohteeksi valittiin aineistojen toteutus, eli se, miten erityyppiset aineistot pystyt¨aa¨ n
esitt¨am¨aa¨ n yhten¨aisen rajapinnan kautta. Lis¨aksi palvelimen haluttiin osaavan yhdist¨aa¨ ja
sovittaa aineistoja k¨aytt¨okohteen vaatimusten mukaisesti.
T¨ass¨a luvussa tarkastellaan, miten eri tavoitteisiin on p¨aa¨ sty. Ensin pohditaan, miten
geneerisyyden tavoittelu on onnistunut palvelimessa. Sen j¨alkeen k¨ayd¨aa¨ n tarkemmin
l¨api yksitt¨aisi¨a kehitystavoitteita ja niiss¨a onnistumista. Lopuksi k¨ayd¨aa¨ n l¨api palvelimen
toteutuksen ongelmakohtia ja teknisi¨a rajoitteita sek¨a pohditaan, millaisia kehityssuuntia
palvelimella voisi olla. Lis¨aksi tarkastellaan rajoituksia, joita palvelimen nykyinen toteutus
aineistojen k¨asittelyyn aiheuttaa.
5.1
Geneerisyyden toteutuminen
Musserin ja Stepanovin m¨aa¨ ritelm¨ass¨a [28] puhuttiin algoritmien ja tietorakenteiden konseptista, eli niiden abstraktista m¨aa¨ ritelm¨ast¨a. Erilaisia paikkatietoaineistoja yhdist¨av¨aa¨
konseptia, geneerist¨a rajapintaa niiden esitt¨amist¨a varten, l¨ahdettiin etsim¨aa¨ n luomalla
yksinkertainen, kahta eri WFS-protokollaan perustuvaa aineistoa k¨aytt¨av¨a prototyyppi.
LUKU 5. TULOKSET JA NIIDEN ANALYYSI
48
Prototyyppi osoitti ennen muuta sen, miten aineistoja t¨aytyy pysty¨a k¨asittelem¨aa¨ n,
jotta niist¨a saadaan halutun kaltaisia. N¨aiden havaintojen pohjalta kehitettiin rajapinta
aineistoille ja lis¨aksi paikallinen aineistoluokka, jota eri aineistotyyppien mukaiset luokat
k¨aytt¨av¨at Edustaja-suunnittelumallin avulla sis¨aisess¨a toteutuksessaan.
Lis¨aksi prototyypist¨a havaittiin se, ett¨a aineistoille teht¨avi¨a operaatioita yhdist¨aa¨ se, ett¨a
ne kaikki vuoroon per¨aa¨ n k¨asittelev¨at palvelimessa auki olevien aineistojen joukkoa. N¨ain
saatiin yksinkertainen konsepti palvelimen moduuleille, jotka yksi kerrallaan vastaanottavat
kulloinkin avoimena olevan aineistojoukon ja suorittavat sill¨a parametriensa mukaiset
operaatiot. Moduulit toimivat toisistaan t¨aysin riippumattomasti, eik¨a niiden toimintaan
vaikuta, mit¨a operaatioita aineistojoukolle on aikaisemmin tehty.
J¨arjestelm¨ass¨a k¨ayt¨oss¨a oleva sovellettu liukuhihna-arkkitehtuuri tukee hyvin geneerisyytt¨a. Itsen¨aisi¨a moduuleja on helppo muuttaa, niiden j¨arjestyst¨a voidaan vaihtaa vapaasti
ja uusien moduulien lis¨aa¨ minen on yksinkertaista. Koska tyypillisesti eri moduulit suorittavat selkeit¨a, pienehk¨oj¨a operaatioita, niiden uudelleenk¨aytt¨o onnistuu helposti osana
erilaisia k¨asittelyoperaatioita.
5.2
Kehitystavoitteissa onnistuminen
Palvelimella oli kaksi yleist¨a kehitystavoitetta: niin uusien aineistotyyppien kuin moduulienkin lis¨aa¨ minen tahdottiin tehd¨a mahdollisimman yksinkertaiseksi. Lis¨aksi Museon
informaatioportaali asetti omia vaatimuksia palvelimelle. Haluttiin, ett¨a palvelin osaisi
valita sopivia aineistoja automaattisesti, yhdistell¨a niist¨a loogisia kokonaisuuksia ja lopuksi
tuottaa m¨aa¨ ritetylle kohteelle sovitettuja uusia aineistoja oikeassa formaatissa.
Uusien aineistotyyppien lis¨aa¨ minen j¨arjestelm¨aa¨ n on yksinkertaista. Edustaja-suunnittelumallin avulla aineistotyyppikohtainen luokka vastaa vain tietojen hausta ja niiden
muuntamisesta j¨arjestelm¨an sis¨aiseen formaattiin – esimerkiksi PostGIS-aineistojen tuen
lis¨aa¨ misess¨a suurin haaste olisi tietokantahakujen muuntaminen GML-muotoon.
LUKU 5. TULOKSET JA NIIDEN ANALYYSI
49
Museon informaatioportaalin erityisvaatimuksia pyrittiin l¨ahestym¨aa¨ n mahdollisimman
yksinkertaisesti. Niinp¨a palvelimeen l¨ahdettiin luomaan ty¨okaluja, jotka k¨aytt¨av¨at tietokantaan etuk¨ateen tallennettuja tietoja. Aineistoja voidaan hakea hakusanojen perusteella,
yhdist¨aa¨ valmiiksi m¨aa¨ ritetyist¨a kohdista ja sovittaa eri kohteille etuk¨ateen m¨aa¨ ritetyill¨a
tavoilla. K¨ayt¨ann¨oss¨a nykytoteutus tarjoaa siis ty¨okaluja, joiden avulla aineistojen yll¨apitoa
voidaan yksinkertaistaa. Mink¨aa¨ nlaista automaattista ty¨okalustoa tiedon louhintaan palvelin ei tarjoa.
5.3
Toteutuksen ongelmakohtia ja kehityskohteita
Palvelimen toteutuksen suurin potentiaalinen ongelmakohta liittyy suoraan sen perusideaan,
sill¨a kaikkien erityyppisten aineistojen esitt¨amisest¨a yhdenmukaisen rajapinnan kautta
seuraa luonnollisesti rajoituksia aineistojen soveltamiseen. Koska palvelimessa ei ole
mahdollisuutta erotella eri aineistotyyppien tukemia toimintoja, aineistorajapintaan voidaan
lis¨at¨a vain sellaisia toiminnallisuuksia, joita kaikki eri aineistotyypit tukevat. Lis¨aksi
aineistojen muuntamisessa yhdenmukaiseen formaattiin sis¨altyy aina tiedon muuttumisen
tai h¨avi¨amisen riski.
Toinen ongelma liittyy moduulien toteutukseen. Koska ne toimivat t¨aysin itsen¨aisesti,
eik¨a niiden suoritusta ole rajoitettu oikeastaan mitenk¨aa¨ n, voi synty¨a tilanteita, joissa
esimerkiksi v¨aa¨ r¨all¨a suoritusj¨arjestyksell¨a tuloksia h¨avi¨aa¨ tai ne k¨asitell¨aa¨ n k¨aytt¨okelvottomiksi. T¨allaisten tilanteiden est¨amiseksi moduuleille pit¨aisi mahdollisesti kehitt¨aa¨
tarkemmin m¨aa¨ ritelty rakenne, joka selkeytt¨aisi ja rajoittaisi niiden toimintaa.
Moduulij¨arjestelm¨an parantaminen onnistuisi esimerkiksi siten, ett¨a palvelimen toteutusta kehitett¨aisiin l¨ahemmin tietovuoarkkitehtuurin mukaiseksi. Esimerkiksi, jos moduulien v¨alinen kommunikaatio hoidettaisiin mallin mukaisilla putkilla, niiden tuottamien
tulosten arvottamiseen olisi mahdollista kehitt¨aa¨ erilaisia metriikoita. Samalla palvelimen
toimintaa olisi mahdollista tehostaa, sill¨a monessa tapauksessa moduuli voisi l¨ahett¨aa¨ yk-
LUKU 5. TULOKSET JA NIIDEN ANALYYSI
50
sitt¨aisi¨a tuloksia seuraavalle k¨asittelij¨alle heti niiden valmistuttua. T¨all¨oin useampi moduuli
voisi k¨asitell¨a aineistoja yhtaikaa.
Yksi selke¨a kehityskohde palvelimelle olisi WFS-protokollan t¨aydellinen tukeminen
siten, ett¨a palvelin kykenisi vastaanottamaan WFS-kyselyj¨a ja tuottamaan oikeanlaisia
GML-muotoisia vastauksia niihin. T¨all¨oin sit¨a voisi k¨aytt¨aa¨ vaikkapa v¨aa¨ r¨ass¨a karttaprojektiossa olevien aineistojen muuntamiseen l¨apin¨akyv¨asti. T¨all¨oin olisi my¨os mahdollista
luoda vaikkapa virtuaalisia aineistoja, kuten Maanmittauslaitoksen Kiinteist¨o- ja Rakennustietopalveluista suorituksen aikana yhdistettyj¨a kokonaisuuksia.
Toinen mahdollinen kehityskohde olisi laajentaa tulosten hakumahdollisuuksia. Nykyisell¨aa¨ n palvelimessa on mahdollista tehd¨a hakua aineistoihin vain koordinaattien perusteella, vaikka esimerkiksi WFS-protokolla tukee my¨os aineistojen ominaisuuksiin perustuvia hakuja. T¨allaisen hakumahdollisuuden lis¨aa¨ misest¨a kuitenkin seuraisi aikaisemmin
mainittu geneerisyyteen liittyv¨a ongelma, sill¨a kaikki eri aineistotyypit eiv¨at niit¨a tue –
esimerkiksi WMS:n GetFeatureInfo-kysely tehd¨aa¨ n aina pisteen perusteella [12].
Ominaisuuspohjaisen haun avulla palvelinta olisi luonnollisesti mahdollista kehitt¨aa¨ tukemaan my¨os muita kuin paikkatietoaineistoja. T¨all¨oin vaikkapa kalkkihiekkakivest¨a rakennetun rakennuksen tietoja voitaisiin t¨aydent¨aa¨ eri rakennusmateriaaleista tietoa sis¨alt¨av¨all¨a
aineistolla.
Museon informaatioportaalin erityisominaisuudet luovat my¨os omanlaisensa kehitysmahdollisuuden, miss¨a tutkittaisiin, voisiko palvelinta kehitt¨aa¨ itsen¨aisemmin toimivaksi
datan louhijaksi. Palvelin voisi esimerkiksi tutkia aineistoja ja luoda niist¨a hakusanatietokantaa sek¨a etsi¨a niiden v¨alisi¨a yhteyksi¨a automaattisesti. T¨all¨oin tiedon oikeellisuuden
takaamisesta tulisi kuitenkin eritt¨ain vaikeaa.
Luku 6
Yhteenveto
T¨ass¨a tutkielmassa l¨ahdettiin selvitt¨am¨aa¨ n, miten erilaisten paikkatietoaineistojen soveltamista voisi helpottaa ja yhdenmukaistaa. Ratkaisuna alettiin kehitt¨aa¨ erityist¨a ty¨okalua, geneerist¨a paikkatietov¨alityspalvelinta, jota voitaisiin k¨aytt¨aa¨ sovelluksissa yleisk¨aytt¨oisen¨a
paikkatietokerroksena. Paikkatietov¨alityspalvelin osaisi hakea tietoa erityyppisist¨a paikkatietoaineistoista, k¨asitell¨a saatuja tuloksia ja palauttaa niit¨a asiakkaalle halutussa formaatissa.
Palvelimen generis¨oinnin l¨aht¨okohtana sek¨a t¨arkeimp¨an¨a sovellus- ja t¨aten my¨os esimerkkik¨aytt¨okohteena k¨aytettiin Museon informaatioportaalia, joka on Varsinais-Suomen
maakuntamuseon selainpohjainen ty¨okalu rakennusinventointiin. Museon informaatioportaalin taustoja k¨asiteltiin tarkemmin tutkielman toisessa luvussa, jossa esiteltiin rakennusinventoinnin perusk¨asitteit¨a, sivuston kehitysprosessia ja sen teknist¨a toteutusta.
Kolmannessa luvussa aloitettiin palvelimen suunnittelu k¨asittelem¨all¨a geneerisyytt¨a ja
sen merkityst¨a. Kehityksen l¨aht¨okohdaksi otettiin m¨aa¨ ritelm¨a, jonka mukaan geneerisess¨a
ohjelmoinnissa on ideana l¨ahte¨a liikkeelle k¨aytt¨okelpoisesta algoritmista, jota abstrahoimalla yritet¨aa¨ n l¨oyt¨aa¨ algoritmien ja tietorakenteiden konsepti [28]. Niinp¨a palvelimesta
p¨aa¨ tettiin kehitt¨aa¨ ensin yksinkertainen prototyyppi, joka tuottaisi etuk¨ateen p¨aa¨ tetyist¨a
aineistoista aina samantyyppist¨a sis¨alt¨oa¨ . T¨at¨a prototyyppi¨a analysoimalla voitaisiin sitten
etsi¨a varsinaisen palvelimen perusperiaatteet.
LUKU 6. YHTEENVETO
52
Ennen prototyypin suunnittelua ja toteuttamista k¨aytiin l¨api varsinaiselle palvelimelle
asetettuja kehitystavoitteita. Museon informaatioportaalin kautta palvelimelle tuli erityisvaatimuksia: haluttiin, ett¨a se osaisi valita aineistoja hakusanan perusteella sek¨a yhdistell¨a
ja sovittaa saatuja tuloksia asiakkaan haluamalla tavalla. N¨aiden vaatimusten perusteella palvelimelle esitettiin kaksi k¨aytt¨otapausta, joista toisen pohjalta p¨aa¨ tettiin kehitt¨aa¨
palvelimen prototyyppi.
Prototyypist¨a kehitettiin suoraviivainen ty¨okalu, joka haki sille sy¨otetyn pisteen perusteella tietoa Maanmittauslaitoksen kahdesta WFS-protokollaan perustuvasta aineistosta,
Kiinteist¨o- ja Rakennustietojen kyselypalveluista. N¨aist¨a aineistoista saatuja tuloksia prototyyppi k¨asitteli siten, ett¨a jokaisen Kiinteist¨otietojen kyselypalvelun kautta l¨oydetyn
kiinteist¨on tietoja laajennettiin sen p¨aa¨ rakennuksen tiedoilla, jonka j¨alkeen tiedot sovitettiin MIP:n kiinteist¨otietoja sy¨otett¨aess¨a k¨aytetylle lomakkeelle ja palautettiin asiakkaalle
JSON-koodattuna.
Prototyypist¨a havaittiin, ett¨a erilaiset aineistoille teht¨av¨at operaatiot voidaan esitt¨aa¨
itsen¨aisesti toimivina komponentteina, moduuleina, jotka liukuhihnamaisesti k¨asittelev¨at
palvelimessa avoimena olevien aineistojen joukkoa yksi kerrallaan. T¨am¨an lis¨aksi prototyyppi havainnollisti sit¨a, miten eri aineistoja t¨aytyy p¨aa¨ st¨a k¨asittelem¨aa¨ n, jotta niist¨a
saadaan halutun kaltaisia. T¨alt¨a pohjalta voitiin aloittaa palvelimen ytimen, aineistoluokkien, toteutuksen suunnittelu. Aineistoluokissa p¨aa¨ dyttiin k¨aytt¨am¨aa¨ n Edustaja-nimist¨a
suunnittelumallia, jonka avulla uusien aineistoluokkien lis¨aa¨ minen onnistuu yksinkertaisesti.
Seuraavaksi aloitettiin varsinaisen palvelimen toteutus. Palvelimen toiminta p¨aa¨ tettiin
perustaa tietovuoarkkitehtuurin yksinkertaistettuun versioon, liukuhihna-arkkitehtuuriin.
K¨ayt¨ann¨oss¨a se toimii siten, ett¨a asiakas kutsuu eri moduuleita sen p¨aa¨ luokasta luodun
instanssin kautta. Parametreikseen moduulit saavat kulloinkin k¨asittelyss¨a olevien aineistojen joukon ja asiakkaalta saadut asetukset. Moduulien toteutusta ei sin¨ans¨a rajoiteta,
mutta tyypillisesti ne k¨asittelev¨at avoimena olevien aineistojen joukkoa jollain tavalla –
LUKU 6. YHTEENVETO
53
ne voivat esimerkiksi avata uusia aineistoja, hakea niist¨a tietoa, muokata saatuja tuloksia
tai muuntaa tuloksia eri formaatteihin ja palauttaa asiakkaalle. Liukuhihna-arkkitehtuurin
ansiosta moduulien lis¨aa¨ minen ja muokkaaminen saatiin pidetty¨a yksinkertaisena.
Tutkielman lopuksi pohdittiin, miten hyvin palvelimen toteutuksessa p¨aa¨ stiin tavoitteisiin, millaisia ongelmia toteutuksessa on ja miten palvelinta voisi kehitt¨aa¨ . Geneerisyyden
osalta havaittiin, ett¨a palvelimeen onnistuttiin l¨oyt¨am¨aa¨ n yleisk¨aytt¨oinen konsepti sek¨a
aineistoille ett¨a niihin kohdistuville operaatioille. Geneerisyydest¨a tosin seuraa my¨os
toteutuksen pahimmat ongelmat, sill¨a kaikkien erityyppisten aineistojen esitt¨aminen yhdenmukaisen rajapinnan kautta v¨akisinkin rajoittaa my¨os niiden soveltamista.
Moduulien l¨ahes t¨aysin vapaan toiminnan todettiin antavan paitsi paljon mahdollisuuksia palvelimen toimintaan, niin my¨os luovan omia ongelmiaan, sill¨a esimerkiksi v¨aa¨ r¨ass¨a
j¨arjestyksess¨a ajettaessa moduulit voivat tuottaa k¨aytt¨okelvottomia tuloksia. Yhten¨a ratkaisuna t¨ah¨an ehdotettiin tietovuoarkkitehtuurin laajempaa noudattamista, miss¨a moduulien
v¨alinen kommunikaatio hoidettaisiin erillisill¨a putkilla. T¨all¨oin niiden tuottamia tuloksia
voitaisiin esimerkiksi arvottaa erilaisilla metriikoilla.
Muiden kehitystavoitteiden osalta palvelimen havaittiin olevan onnistunut, sill¨a se kykenee suoriutumaan sille asetetuista vaatimuksista. Samalla tosin todettiin, ett¨a esimerkiksi
aineistojen etsimiseen tai yhdist¨amiseen tarkoitetut moduulit soveltuvat nykytoteutuksella
l¨ahinn¨a yll¨apidon helpottamiseen. T¨ast¨a saatiinkin yksi mahdollinen kehityskohde: palvelimesta voitaisiin kehitt¨aa¨ itsen¨aisemmin toimiva tiedon louhija, mik¨a tosin tekisi tiedon
oikeellisuuden toteamisesta eritt¨ain vaikeaa.
Muina mahdollisina kehityskohteina palvelimelle todettiin WFS-protokollan t¨aydellinen
tukeminen ja ominaisuuspohjaisen haun lis¨aa¨ minen. Hakumahdollisuuksien laajentamisen tosin havaittiin aiheuttavan aikaisemmin mainitun geneerisyyteen liittyv¨an ongelman,
sill¨a kaikki aineistotyypit eiv¨at tue ominaisuuksien perusteella hakemista. T¨allaista toiminnallisuutta varten palvelimeen tarvittaisiinkin j¨arjestelm¨a, jonka avulla aineistoja voisi
luokitella sen mukaan, mit¨a toiminnallisuuksia ne tukevat.
L¨ahteet
[1] International Association of Oil & Gas Producers Geomatics Committee, OGP Geomatics Committee. http://nsidc.org/data/atlas/epsg_4326.html. Viitattu 29.8.2011.
[2] The National Snow and Ice Data Center, EPSG:4326. http://nsidc.org/
data/atlas/epsg_4326.html. Viitattu 29.8.2011.
[3] H¨akli, P., Puupponen, J., Koivula, H., Poutanen, M., Suomen geodeettiset koordinaatistot ja niiden v¨aliset muunnokset. Geodeettinen laitos, Masala, 2009.
[4] International Organization for Standardization, ISO 19136:2007. Geographic information – Geography Markup Language (GML). http://www.iso.org/iso/
iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=
32554, 2010.
[5] Euroopan komissio, About INSPIRE. http://inspire.jrc.ec.europa.eu/
index.cfm/pageid/48. Viitattu 25.8.2011.
[6] Julkisen hallinnon tietohallinnon neuvottelukunta, JHS-suositukset. http://www.
jhs-suositukset.fi/. Viitattu 29.8.2011.
[7] Crockford, D., Request for Comments: 4627. The application/json Media Type for JavaScript Object Notation (JSON). http://www.ietf.org/rfc/rfc4627.txt,
2006.
¨
LAHTEET
55
[8] The Open Geospatial Consortium, OGC Vision, Mission, & Goals. http://www.
opengeospatial.org/ogc/vision. Viitattu 25.8.2011.
[9] The PHP Group, PHP Manual: General Information. http://fi2.php.net/
manual/en/faq.general.php. Viitattu 8.9.2011.
[10] Esri, ESRI Shapefile Technical Description. ESRI, 1998.
[11] Vretanos, P. A. (toim.), Web Feature Service Implementation Specification version
1.1.0. Open Geospatial Consortium Inc, 2005.
R Web Map Server Implementation Specification
[12] Beaujardiere, J. (toim.), OpenGIS
version 1.3.0. Open Geospatial Consortium Inc, 2005.
[13] Maanmittauslaitos,
Paikkatietotekniikan
sanasto.
http://www.nls.fi/
ptk/pyk-kasikirja/sanasto/sanasto.htm/#paikkatieto.
Viitattu
25.8.2011.
[14] Saarento,
P.,
Museoiden
inventointiportaalin
kehitt¨aminen
aloitettu.
http://www.turku.fi/Public/default.aspx?contentid=
253271&nodeid=16927. Viitattu 25.8.2011.
[15] Saarento, P., Turun maakuntamuseon kulttuuriymp¨arist¨otietokannan kehitt¨aminen:
hankesuunnitelma. Turun Maakuntamuseo, 2008.
[16] Turun kaupunki/Kulttuurilautakunta, Paikkatietokeskus Lounaispaikan tarjouksen
hyv¨aksyminen. P¨oyt¨akirja 19.05.2010 § 106, 2010.
[17] Varsinais-Suomen maakuntahallitus, Yhteisty¨osopimuksen allekirjoittaminen
Varsinais-Suomen maakuntamuseon kulttuuriymp¨arist¨otietokantapilotin kehitt¨amisest¨a.
P¨oyt¨akirja 26.4.2010 § 77, 2010.
[18] Turun maakuntamuseo, Rakennusinventointi. http://www05.turku.fi/
museo/Sarakum/rakennus.htm. Viitattu 25.8.2011.
¨
LAHTEET
56
[19] Forsius, J., Arvottamisesta osana rakennetun ymp¨arist¨on kulttuurihistoriallista inventointia. Teoksessa (Elo T., Magga P. (toim.)) Eletty, koettu maisema - n¨ak¨okulmia
saamelaiseen kulttuurimaisemaan. Lapin ymp¨arist¨okeskus, Rovaniemi, 2007.
[20] Kiinteist¨onmuodostamislaki 12.4.1995/554, 2 § (12.4.1995/554), 1995.
[21] Kiinteist¨orekisterilaki 16.5.1985/392, 2 § (12.4.1995/559), 1995.
[22] Maanmittauslaitos,
Toimitusmenettelyn
k¨asikirja.
http://www.
maanmittauslaitos.fi/toimitusmenettelynkasikirja.
Viitattu
2.8.2011.
[23] Julkisen hallinnon tietohallinnon neuvottelukunta, JHS 138 Kiinteist¨otunnus,
m¨aa¨ r¨aalatunnus ja k¨aytt¨ooikeusyksikk¨otunnus (versio 31.9.2005). http://docs.
jhs-suositukset.fi/jhs-suositukset/JHS138/JHS138.pdf, 2005.
[24] Sencha, Ext JS 3.4 Cross-Browser Rich Internet Application Framework. http:
//www.sencha.com/products/extjs3/. Viitattu 31.8.2011.
[25] Dehnert, J. C., Stepanov, A. A., Fundamentals of Generic Programming. International
Seminar on Generic Programming, Schloss Dagstuhl, Leibniz, Saksa, 1998.
[26] Dos Reis, G., J¨arvi J., What Is Generic Programming?. Object-Oriented Programming, Systems, Languages and Applications -konferenssi, San Diego, Kalifornia, 2005.
[27] Bergmann, S., Kniesel, G., GAP: Generic Aspects for PHP. Third European Workshop on Aspects in Software, Universiteit Twente, Enschede, Alankomaat, 2006.
[28] Musser, D. R., Stenov, A. A., Generic Programming. First International Joint Conference of ISSAC-99 and AAECC-6, Rooma, Italia, 1988.
[29] Koskimies, K., Mikkonen, T., Ohjelmistoarkkitehtuurit. Talentum, Helsinki, 2005.
¨
LAHTEET
57
[30] Maanmittauslaitos, Rajapintapalvelut. http://www.maanmittauslaitos.
fi/aineistot-palvelut/rajapintapalvelut. Viitattu 6.9.2011.
[31] Martin, R. C., Agile Software Development. Principles, Patterns, and Practices.
Prentice Hall, Upper Saddle River, NJ, USA, 2003.
[32] Garlan, D., Shaw, M., An Introduction to Software Architecture. Carnegie Mellon
University Pittsburgh, PA, USA, 1994.