Geneerisen paikkatietovälityspalvelimen

Transkriptio

1 Geneerisen paikkatietovälityspalvelimen kehittäminen Diplomityö Turun yliopisto Informaatioteknologian laitos Ohjelmistotekniikka Tammikuu 2012 Tapio Aali Ohjaajat: Jukka Teuhola Sami Hyrynsalmi

2 TURUN YLIOPISTO Informaatioteknologian laitos TAPIO AALI: Geneerisen paikkatietovälityspalvelimen kehittäminen Diplomityö, 57 s. Ohjelmistotekniikka Tammikuu 2012 Paikkatieto on tietoa kohteista tai ilmiöistä, joiden sijainti Maan suhteen tunnetaan. Yksittäinen paikkatietoelementti sisältää tietoa sijainnista ja siihen liittyvästä ominaisuudesta. Useasta toisiinsa jollain tavalla liittyvästä paikkatietoelementistä koottua kokonaisuutta kutsutaan paikkatietoaineistoksi. Erilaisia paikkatietoaineistoja on nykyään saatavilla Internetistä suunnaton määrä lukuisissa eri formaateissa. Työkalut aineistojen hyväksikäyttöön on käytännössä täytynyt aina toteuttaa sovellus- ja aineistokohtaisesti, sillä niiden soveltamiseen ei ole ollut yhtenäistä ratkaisua. Soveltamista olisi mahdollista yksinkertaistaa ja helpottaa kehittämällä erityinen geneerinen paikkatietovälityspalvelin, joka toimisi sovittimena aineistojen ja sovelluksen välillä. Toisin sanoen palvelinta voitaisiin käyttää geneerisenä paikkatietokerroksena sovelluksissa. Tässä tutkielmassa selvitetään, millainen tällainen palvelin voisi olla. Palvelimen suunnittelu aloitetaan luomalla siitä muutamaa kiinteää aineistoa käyttävä prototyyppi, josta tehtyjen havaintojen pohjalta aloitetaan geneerisen palvelimen suunnittelu. Palvelimesta päädytään kehittämään työkalu, jonka avulla erityyppisiä paikkatietoaineistoja voidaan käsitellä yhdenmukaisen rajapinnan kautta. Siihen kehitetään modulaarinen arkkitehtuuri, jonka avulla aineistoja ja niistä haettuja tuloksia voidaan käsitellä mahdollisimman vapaasti. Geneerinen paikkatietovälityspalvelin toteutetaan tässä työssä siten, että se tukee kahta eri aineistotyyppiä: WFS:ää ja WMS:n metatietoja. Tämän lisäksi palvelimeen toteutetaan joukko operaatioita, joiden avulla aineistoja voidaan käsitellä halutuilla tavoilla. Työn lopuksi tarkastellaan valmiin palvelimen käyttökelpoisuutta. Sen havaitaan toteuttavan sille asetetut vaatimukset ja täten olevan käyttökelpoinen tietyin rajoituksin, joista suurimmat seuraavat palvelimen perusideasta. Käytännössä geneerinen lähestymistapa aiheuttaa väkisinkin omia rajoituksiaan aineistojen käsittelyyn, vaikka se samaan aikaan laajentaa ja yksinkertaistaa niiden käyttöä luomalla yhdenmukaisen rajapinnan kaikkiin eri aineistoihin. Asiasanat: Paikkatieto, paikkatietoaineisto, geneerisyys, WFS, WMS

3 UNIVERSITY OF TURKU Department of Information Technology TAPIO AALI: 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

4 Sisältö Työssä käytetyt lyhenteet ii 1 Johdanto 1 2 Taustaa Museon informaatioportaalista Rakennusinventoinnin peruskäsitteet Ohjelmiston kehitys Käytetyt teknologiat Alustan tekninen toteutus Rakennusinventoinnin tietokantarakenne Paikkatietovälityspalvelimen suunnittelu Geneerisyys Palvelimen kehityksen tavoitteet Prototyypin suunnittelu Prototyypin toteutus Kohti geneerisyyttä prototyypin analyysi Tietokanta- ja luokkarakenteen suunnittelua Paikkatietovälityspalvelimen toteutus Järjestelmän arkkitehtuuri ja variaatiopisteet Tietokantarakenne

5 4.3 Luokkarakenne Aineistoluokkien toteutus Toiminnallisuuksien toteutus Palvelimen toiminta ja sen käyttö Tulokset ja niiden analyysi Geneerisyyden toteutuminen Kehitystavoitteissa onnistuminen Toteutuksen ongelmakohtia ja kehityskohteita Yhteenveto 51 Lähteet 54

6 Työssä käytetyt lyhenteet EPSG, European Petroleum Survey Group European Petroleum Survey Group oli järjestö, joka alkoi ylläpitää geodeettisten parametrien tietokantaa. Tietokantaan koottiin tiedot eri koordinaattijärjestelmistä, ja sen avulla koordinaatteja pystytään muuntamaan järjestelmästä toiseen. Nykyään tietokantaa ylläpitää International Association of Oil & Gas Producers Geomatics Committee, johon EPSG yhdistettiin vuonna 2005 [1]. Lyhenne EPSG on kuitenkin edelleen käytössä koordinaattijärjestelmille annettavissa tunnisteissa, joita kutsutaan EPSG-koodeiksi. Esimerkiksi GPS-järjestelmässä käytössä olevan WGS84-koordinaattijärjestelmän 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ärjestelmän suomalainen toteutus. ETRS89:ssä koordinaatit on lukittu Euraasian mannerlaattaan, joten ne eivät muutu mannerlaattojen liikkuessa. Järjestelmän koordinaattien yksikkö on metri, ja sen EPSG-koodi on [3] GIS, Geographical Information Systems (Paikkatietojärjestelmä) Paikkatietojärjestelmä on järjestelmä paikkatiedon tuottamiseen, hallintaan, analysointiin tai esittämiseen. Paikkatietojärjestelmään voi kuulua laitteita, ohjelmistoja, aineistoja ja ihmisiä.

7 GML, Geography Markup Language GML:n on OGC:n kehittämä paikkatiedon välittämiseen tarkoitettu XML:ään perustuva kieli. GML mahdollistaa esimerkiksi geometrioiden sekä erilaisten paikkatietoelementtien ja havaintojen välittämisen yhdenmukaisesti. [4] INSPIRE, Infrastructure for Spatial Information in Europe INSPIRE-direktiivin tavoitteena on luoda Eurooppaan yhtenäinen paikkatietoinfrastruktuuri, jossa kansalliset paikkatietoaineistot ja -palvelut yhdistyvät. [5] JHS, julkishallinnon suositus JHS-järjestelmä koostuu suosituksista, jotka koskevat valtion- ja kunnallishallinnon tietohallintoa. Esimerkiksi JHS 158 Paikkatiedon metatiedot määrittää, miten paikkatietoon liittyvä metatieto tulisi esittää Suomen julkisessa hallinnossa. [6] JSON, JavaScript Object Notation JSON on kevyt yleiskäyttöinen formaatti datan esittämiselle. Se on ihmisille helposti luettavaa, ja sen käsittely tietokoneella on esimerkiksi XML:ää nopeampaa ja yksinkertaisempaa. JSON perustuu JavaScript-kieleen ja sen ytimenä on kaksi rakennetta: järjestetty lista ja avain-arvo-kokoelma. [7] OGC, The Open Geospatial Consortium OGC on vuonna 1994 perustettu kansainvälinen vapaaehtoisuusperustainen standardisointijärjestö, joka kehittää standardeja muun muassa paikkatietosisällöille ja palveluille. [8]

8 PHP, PHP: Hypertext Preprocessor PHP on alun perin yksinkertaisena skriptikielenä kehitetty dynaamisten WWW-sivujen generointiin tarkoitettu palvelinpään ohjelmointikieli. Viidennen version myötä siihen on tullut myös laaja tuki oliopohjaiselle ohjelmoinnille. [9] Tässä tutkielmassa käytetään ohjelmointikielenä PHP:tä. SHP, Esri Shapefile SHP on Esrin ylläpitämä digitaalinen vektoripohjainen tiedostoformaatti paikkatiedon ja siihen liittyvän metatiedon tallentamiseen. [10] WFS, Web Feature Service OpenGIS Web Feature Service on OGC:n kehittämä rajapinta paikkatietoelementtien välittämiseen alustariippumattomasti. WFS:ssä käytetään GML-kieltä. [11] WMS, Web Map Service WMS on OGC:n kehittämä rajapinta karttakuvien ja niihin liittyvän metatiedon tarjoamiseen Internetin yli. [12]

9 Luku 1 Johdanto Paikkatiedolla tarkoitetaan tietoa kohteista tai ilmiöistä, joiden sijainti Maan suhteen tunnetaan [13]. Paikkatieto voi olla joko inhimillistä tai mittaustietoa. Niinpä esimerkiksi sekä Mynämäen lukio sijaitsee EUREF-FIN-koordinaattijärjestelmässä pisteessä , että Mynämäen lukio sijaitsee Mynämäen kirkon vieressä ovat molemmat paikkatietoa. Yksittäinen paikkatietoelementti sisältää vähintään ainakin tiedon sijainnista ja siihen liittyvästä ominaisuudesta. Elementeistä koostuvaa kokonaisuutta kutsutaan paikkatietoaineistoksi. Yksittäisen aineiston elementit liittyvät yleensä toisiinsa esimerkiksi siten, että ne sijaitsevat samalla maantieteellisellä alueella tai niitä yhdistää jokin ominaisuustieto. Paikkatietoaineistoihin liittyy yleensä metatietoa, joka kuvailee aineiston sisältöä tai kertoo siihen liittyviä lisätietoja. Tietokonepohjaisten paikkatietojärjestelmien yleistyttyä myös paikkatietoaineistoilla tarkoitetaan yleensä digitaalisessa muodossa olevaa tietoaineistoa. Internetissä on nykyään saatavilla suunnaton määrä erilaisia paikkatietoaineistoja. Niiden toteutusta on pyrkinyt yhdenmukaistamaan vuodesta 1994 toiminut The Open Geospatial Consortium, joka on kehittänyt erilaisia standardeja protokollia ja malleja paikkatietoaineistojen esittämiseen [8]. Aineistojen rakenteen yhdenmukaisuutta on puolestaan edistänyt Euroopan Unionin vuonna 2007 käyttöönottama INSPIRE-direktiivi, jonka tavoitteena on yhdenmukaistaa EU:n jäsenvaltioiden paikkatietoinfrastruktuureja. INSPIRE

10 LUKU 1. JOHDANTO 2 määrittää muun muassa, miten paikkatietoaineistojen metatiedot tulisi esittää ja miten aineistoihin liittyvät palvelut tulisi toteuttaa. [5] Standardien ja direktiivien myötä aineistot ovat nykyään pääosin saavutettavissa yhtenäisillä menetelmillä. Kuitenkaan niiden soveltamiseen ei ole ollut yhtenäistä ratkaisua, vaan käytännössä työkalut paikkatietoaineistojen hyväksikäyttöön eri sovelluksissa on täytynyt aina toteuttaa erikseen aineistokohtaisesti. Aineistojen hyväksikäyttöä olisi mahdollista helpottaa kehittämällä erityinen paikkatietovälityspalvelin, joka toimisi sovittimena aineistojen ja sovelluksen välillä. Palvelimeen olisi tallennettu aineistojen parametreja, ja se osaisi sijaintitiedon avulla hakea tietoa näistä aineistoista. Saadut tulokset palvelin osaisi esittää loogisina tietokokonaisuuksina, joita pystyttäisiin käsittelemään yhdenmukaisen rajapinnan kautta. Tällöin aineistoista voitaisiin helposti tuottaa juuri halutun kaltaisessa formaatissa olevia kokonaisuuksia halutussa koordinaattijärjestelmässä, eikä asiakkaan välttämättä tarvitsisi tietää tarkasti, mistä tai minkä tyyppisistä aineistoista tietoja tarkkaan ottaen haetaan. Palvelin toimisi siis käytännössä asiakassovelluksen geneerisenä paikkatietokerroksena. Paikkatietovälityspalvelimen toiminnan ideaa esitellään kuvassa 1.1. Tässä tutkielmassa selvitetään, miten tällainen paikkatietovälityspalvelin kannattaa toteuttaa. Yksi keskeinen kysymys palvelimen kehityksessä on luonnollisesti tietojen oikeellisuus, eli miten valitaan oikeat aineistot ja miten eri lähteistä saatuja tuloksia yhdistellään järkeviksi kokonaisuuksiksi. Keskeisin kysymys liittyy kuitenkin geneerisyyteen: miten kannattaa toteuttaa rajapinta, jonka kautta erityyppiset aineistot saadaan esitettyä yhdenmukaisesti. Lisäksi palvelin halutaan pitää mahdollisimman helposti laajennettavana, sillä niin uusien aineistotyyppien kuin myös uusien aineistoja käsittelevien operaatioiden lisääminen halutaan pitää yksinkertaisena. Esimerkkinä palvelimen käytöstä käytetään tässä työssä Museon informaatioportaalia (MIP), joka toimii samalla sekä generisöinnin lähtökohtana että tärkeimpänä sovelluskohteena. MIP on Varsinais-Suomen maakuntamuseolle kehitettävä selainpohjainen

11 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älityspalvelimen toimintaidea. inventointisovellus. Sen toteutuksesta vastaa Varsinais-Suomen liiton alaisuudessa toimiva Lounaispaikka, jonka päätuote on lounaispaikka.fi-osoitteessa toimiva varsinaissuomalaisille ja satakuntalaisille viranomaistahoille tarkoitettu karttapalvelu. MIP:n kehitys aloitettiin Opetus- ja kulttuuriministeriö tuella 2010, ja sen tuotantokäyttö aloitettiin syksyllä Sivustosta on tarkoitus kehittää kattava työkalu kaikenlaisen kulttuuriympäristöihin liittyvän inventointitiedon tallentamiseen ja esittämiseen; ensimmäisessä vaiheessa siihen on kehitetty työkaluja rakennusinventoinnin tarpeisiin [14]. Tämän tutkielman toisessa luvussa käydään läpi projektiin liittyvää taustatietoa. Luvussa esitellään rakennusinventointia ja sen peruskäsitteitä, Museon informaatioportaalia ja sen ominaisuuksia sekä sivuston teknistä toteutusta. Kolmannessa luvussa käsitellään paikkatietovälityspalvelimen suunnitteluprosessia. Luvussa käydään läpi palvelimelle asetetut tavoitteet ja niistä seuraavat vaatimukset. Aluksi eritellään vaatimuksia ja analysoidaan niitä, jonka jälkeen suunnitellaan ja toteutetaan palvelimen prototyyppi MIP:n vaatimuksista tehdystä käyttötapauksesta. Seuraavaksi luo-

12 LUKU 1. JOHDANTO 4 daan yleistys palvelimen toimintaperiaatteista prototyypistä tehtyjen havaintojen pohjalta. Lopuksi luvussa suunnitellaan palvelimen tietokanta- ja luokkarakennetta. Neljännessä luvussa käydään läpi palvelimen toteutusta. Aluksi luvussa käydään läpi palvelimen tietokanta- ja luokkarakenteet. Lopuksi tutustutaan tarkemmin eri ominaisuuksien, kuten protokollien, toteutuksiin. Viides luku on yhteenveto. Siinä tarkastellaan, auttaako palvelin ongelmaan, jonka takia sitä alettiin kehittää, vai luoko se uusia ongelmia. Lisäksi luvussa tutkitaan, täyttääkö palvelin sille asetetut vaatimukset, ja miten sitä voisi parantaa. Paikkatietovälityspalvelin on lisensoitu Creative Commons Nimeä 3.0 Muokkaamaton -lisenssillä 1, ja se on saatavilla osoitteesta GIProxy. 1 Creative Commons Attribution 3.0 Unported Licence ( licenses/by/3.0/)

13 Luku 2 Taustaa Museon informaatioportaalista Museon informaatioportaalin suunnittelu aloitettiin vuonna Tällöin tehtiin suunnitelma hankkeesta, jonka tavoitteena oli luoda kulttuuriympäristötietokanta, joka olisi suoraan yhteydessä paikkatietoon, yleisiin rakennettua kulttuuriympäristöä koskeviin perusrekistereihin, ja johon voisi liittää suoraan myös valokuvat ja muut liitetiedostot. Tavoitteena oli luoda sovellus, jonka avulla voitaisiin koota Turun maakuntamuseon hajallaan olevat kulttuuriympäristöihin liittyvät tiedot samaan paikkaan. [15] Hankkeelle saatiin rahoitus Opetus- ja kulttuuriministeriöltä vuoden 2009 lopulla, ja se käynnistettiin vuoden 2010 aikana. Projektia kehittämään valittiin Lounaispaikka Turun kaupungin ja Lounaispaikan muiden partnerien välisen yhteistyösopimuksen perusteella [16, 17]. Ensimmäisessä vaiheessa sovellukseen päätettiin kehittää työkalut rakennusinventoinnin tarpeisiin. 2.1 Rakennusinventoinnin peruskäsitteet Rakennusinventoinnissa on tarkoituksena kerätä tietoja rakennuksista, kiinteistöistä ja erilaisista aluekokonaisuuksista. Tyypillisesti tallennetaan tietoja esimerkiksi rakennusten rakennus- ja ympäristötyypeistä, rakennustavoista, rakennusten ulkoasusta ja niiden säilyneisyydestä. Inventoitaessa rakennuksille ja niiden kiinteistöille annetaan myös arvo-

14 LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA 6 tuksia, jotka ohjaavat aluesuunnittelijoita rakennuskannan ja maiseman suojelussa. [18] Lisäksi eri inventointikohteille tehdään kulttuurihistoriallista arvottamista, jonka tarkoituksena on määrittää alueen, kiinteistön tai rakennuksen kulttuurihistoriallinen arvo ja merkitys [19]. Rakennusinventoinnissa keskeisin inventoitava kohde on kiinteistö. Kiinteistönmuodostamislain mukaan kiinteistöllä tarkoitetaan maanmuodostuksen yksikköä, joka merkitään kiinteistörekisteriin kiinteistönä [20]. Tällaisia yksiköitä ovat tilat, tontit, yleiset alueet, valtion metsämaat, suojelualueet, lunastusyksiköt, yleisiin tarpeisiin erotetut alueet, erilaiset vesijätöt 1 sekä yleiset vesialueet [21]. Jokaisella kiinteistöllä on neliosainen 14-numeroinen kiinteistötunnus, joka koostuu kolminumeroisesta kuntanumerosta, kolminumeroisesta kylän tai kaupunginosan numerosta sekä nelinumeroisista ryhmä- ja yksikkönumeroista [23]. Tyypillinen rakennusinventoinnissa inventoitava kiinteistö on tila tai tontti. Jokaisesta inventoidusta kiinteistöstä pyritään tallentamaan sen osoite, nimi, päärakennuksen sijainti, tietoja sen historiasta ja ympäristöstä sekä rakennusten määrästä. Kiinteistöön voidaan myös merkitä sen kulttuurihistorialliset arvot ja antaa arvotus tarpeen mukaan. Lisäksi kiinteistön erilaiset kaava- ja muut suojelumerkinnät pyritään kirjaamaan sen tietoihin. Kiinteistöstä ja sen rakennuksista otetaan myös kuvia, jotka arkistoidaan muiden inventointitietojen mukana. Jokaiseen inventoituun kiinteistöön kuuluu yksi tai useampi rakennus tai rakennelma. Jokaisella rakennuksella tai rakennelmalla on rakennustunnus, joka koostuu kiinteistötunnuksesta ja kolminumeroisesta juoksevasta rakennusnumerosta [23]. Rakennuksen inventointitietoihin pyritään kirjaamaan esimerkiksi sen sijainti kartalla, rakennustyyppi (kuten kioski, leikkimökki tai talonpoikaistalo), suunnittelijat ja rakentajat, rakennusvuodet ja rakennusmateriaalit. Lisäksi kirjataan tarvittaessa ylös tietoja rakennuksen kulttuurihistoriallisesta merkittävyydestä, suojelusta sekä kuvaus sisätiloista ja erityispiirteistä. 1 Vesijättö on entistä vesialuetta, joka on pysyvästi muuttunut maa-alueeksi vedenpinnan laskun, liettymisen, umpeen kasvamisen tai maanpinnan kohoamisen seurauksena. [22]

15 LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA 7 Rakennuksella tai rakennelmalla on siis aina kiinteistö, johon se kuuluu. Vastaavasti inventoitu kiinteistö kuuluu aina kylään tai kaupunginosaan, joka puolestaan kuuluu kuntaan. Kunnilla on inventoinneissa merkitystä pelkästään tilastollisina kohteina, joten niistä tallennetaan vain kuntanumerot sekä nimet. Kylistä sen sijaan tehdään alueinventointeja. Alueinventoinneissa koostetaan yhdestä tai useammasta kylästä koostuva alue, jolle annetaan nimi, kuvaus sen historiasta, maisemasta ja nykytilasta. Lisäksi alueen sijainti voidaan tarpeen mukaan antaa joko pisteenä tai karttaan piirrettävänä alueena. Alueiden sisällä voi sijaita kulttuurihistoriallisesti merkittäväksi luettavia arvoalueita, joilla on nimi ja aluetyyppi sekä sijainti pisteenä tai alue. Lisäksi niille voidaan kiinteistöjen tapaan antaa erilaisia kulttuurihistoriallisia arvoja sekä määrittää arvotus ja suojelutiedot. Yhteen kokonaisuuteen kuuluvat inventoinnit kootaan inventointiprojektin alle. Inventointiprojektilla on sen sisältöä kuvaava nimi, tarkempi kuvaus, inventointiaika, toimeksiantaja ja tyyppi sekä inventoijat. Tyypillinen inventointiprojekti tehdään jollain rajauksella jonkin tietyn kunnan alueella. Esimerkiksi Turun Maakuntamuseon Varakum B -projektissa tehtiin vuonna 2007 Entisen Mietoisten alueen täydennysinventointi, jossa inventoitiin ennen vuotta 1940 rakennettuja nykyisin Mynämäkeen kuuluvan Mietoisten kunnan rakennuksia. 2.2 Ohjelmiston kehitys Kesäkuussa 2010 Pyry Liukas aloitti Museon informaatioportaalin kehityksen Lounaispaikassa. Aluksi hän tutustui vuonna 1998 käyttöönotettuun Microsoft Access 97 -pohjaiseen InveTMM-sovellukseen ja sen tietokantarakenteeseen. Ohjelmistosta kerätyn tiedon ja käyttäjien haastattelun perusteella hän aloitti MIP:n suunnittelun. Alusta asti uuden sovelluksen päätavoitteet olivat selkeitä. Yksi olennainen ominaisuus ohjelmistossa tulisi olemaan joustavuus, sillä InveTMM-ohjelmisto oli yli kymmenen vuoden käytön aikana osoittautunut kankeaksi ja rajoittuneeksi. MIP:sta haluttiin kehittää

16 LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA 8 helposti muokattava ja moniin käyttötarkoituksiin soveltuva. Lisäksi MIP:iin haluttiin luoda järjestelmä, jossa voitaisiin inventoitaessa syntynyt tekstidata ja siihen liittyvät paikkatieto, kuvat ja liitetiedostot tallentaa yhteen paikkaan ja esittää yhdessä helposti ymmärrettävässä näkymässä: teksti selkeästi jaoteltuna, paikkatieto karttaikkunassa sekä kuvat ja liitetiedostot selailtavina. Paperiset tulosteet olivat ainoa tapa jakaa tietoa ulkopuolisille tahoille InveTMM:stä. Tähän haluttiin parannusta, joten MIP:sta päätettiin kehittää WWW-pohjainen ohjelmisto, johon tulisi mahdollisuus luoda erilaisia käyttäjätasoja, joille voitaisiin asettaa erilaisia rajoituksia niin tietojen näkyvyyteen kuin myös ohjelmiston käyttöoikeuksiin. Tietojen arkistointia ja laadukkaita tulosteita varten MIP:iin haluttiin myös mahdollisuus PDFtiedostojen luomiseen. Sivuston toteutus aloitettiin Lounaispaikassa vuoden 2010 loppupuolella. Ensimmäisinä kuukausina Pyry Liukas, Tapio Aali ja Heikki Ylitalo kehittivät yhteistyössä sivustoa. Vuoden 2011 helmikuusta sivuston suunnittelusta ja toteutuksesta on vastannut Tapio Aali yksinään Pyry Liukkaan satunnaisella avustuksella. Ensimmäiseksi käsiteltiin vanhat tietokannat. Vanhoista inventoinneista digitoitu Inventoinnit ennen 1998, InveTMM-ohjelmistolla luotu Inventoinnit , matkaraporttitietokanta Matkaraportit, Turussa tehtyjä rakennusinventointeja sisältävä Turku MySQL sekä porrashuoneinventointeja sisältävä Porrashuone yhdistettiin yhteen Postgre- SQL-tietokantaan omiksi skeemoikseen. Tammikuussa 2011 kehitettiin geneerinen työkalu, jolla vanhoja tietokantoja pääsi selailemaan ja tarvittaessa muokkaamaan suoraan MIP:n omasta käyttöliittymästä. Työkaluun kehitettiin myös yksinkertainen hakukone, jolla voitiin etsiä halutun ilmauksen sisältäviä rivejä. Lopuksi hakukoneeseen lisättiin mahdollisuus rajata haku tiettyihin skeemoihin tai tauluihin. Tammi-helmikuussa 2011 otettiin käyttöön erillinen kuvapalvelin, johon rakennettiin järjestelmä kuvien automaattiseen koon muuttamiseen ja uusien kuvien lisäämiseen. Samalla kehitettiin MIP:n sivustomoottoriin järjestelmä, jossa palvelimen kuvatiedostot

17 LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA 9 voitiin liittää mihin tahansa tietokannan riviin. Myöhemmin samaa järjestelmää laajennettiin siten, että kuvien lisäksi sen kautta pystyttiin jakamaan myös erilaisia liitetiedostoja. Seuraavaksi kehitettiin työkalu, joka tutki läpi Turun maakuntamuseon rakennusinventointien kuva-arkiston. Kuvien metatiedoista etsittiin kiinteistö- ja rakennustunnuksia, joita verrattiin Inventoinnit skeeman tietoihin. Täsmänneet kuvat indeksoitiin palvelimelle kuvauspäivämäärän mukaan ja linkitettiin vastaavaan riviin. Viimeisenä työvaiheena ennen uuden tietokantaskeeman käyttöönottoa kehitettiin prototyyppi MIP:n hyvin keskeisestä ominaisuudesta, kiinteistöselaimesta (kuva 2.1), joka vastaa inventoijien aikaisemmin paperille tekemää inventointikorttia. Työkalun tavoitteena oli tutkia, miten yksittäisen kiinteistön tiedot, siihen liitetyt kuvat ja paikkatieto sekä sen rakennukset saadaan esitettyä selkeästi yhdessä näkymässä. Käytännössä työkalua varten piti kehittää erikseen vain geneerinen kuvapaneeli, joka kykeni hakemaan tiettyyn tietokannan riviin linkitetyt kuvat ja yksinkertainen karttaikkuna, joka piirsi pohjakartan päälle kiinteistön karttakohteet pisteinä. Kiinteistön tiedot ja listaus sen rakennuksista saatiin suoraan aiemmin kehitetystä tietokantaselaimesta. Kuva 2.1: Kiinteistöselaimen prototyyppi.

18 LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA 10 Helmikuussa 2011 aloitettiin uuden inventointityökalun, Rakennusinventoinnit 2011, tekninen toteutus. Ensimmäiseksi tietokantaskeema viimeisteltiin käyttöönottoa varten. Työvaiheesta teki erityisen se, että tietokannan suunnitelmaa oli käytetty portaalin kehityksen esittelyssä ohjausryhmissä, joten se oli tehty mahdollisimman helposti luettavaksi. Niinpä ensimmäiseksi tietokantaskeema täytyi muuntaa paremmin tekniseen käyttöön soveltuvaksi. Lisäksi entiteettien attribuutit piti tarkistaa ennen uuden tietokannan käyttöönottoa. Viimeistelyprosessia esitellään kuvassa 2.2. Alkuperäinen Lopullinen kunta kunta kuntanumero Character varying(3) NN (PK) id Serial NN (PK) nimi NN kuntanumero Character varying(3) NN nimi NN kunnissa_on_kylänosia kylänosa kuntanumero Character varying(3) NN (PFK) kylänumero Integer NN (PK) nimi NN postinumero Numeric(5,0) NN maisema Text historia Text nykytila Text lisätiedot Text lähteet Text kylänosissa_on_kiinteistöjä kiinteistö kiinteistötunnus NN (PK) kuntanumero Character varying(3) NN (FK) kylänumero Integer NN (FK) kiinteistönumero Integer NN nimi katuosoite postinumero paikkakunta aluetyyppi NN (AK2) historiallinen_tilatyyppi NN (AK3) kiinteistön_sijainti geometry arvotus NN kunnissa_on_kyliä kylä id Serial NN (PK) kunta_id Integer NN (FK) kylänumero NN nimi NN kylissä_on_kiinteistöjä kiinteistö id Serial NN (PK) kylä_id Integer NN (FK) kiinteistötunnus nimi osoite postinumero paikkakunta aluetyyppi arvotus historiallinen_tilatyyppi 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ä, jota uudelle tietokannalle tehtiin ennen sen käyttöönottoa kuntien, kylien ja kiinteistöjen osalta. Vaikka kunta- ja kylänumerot sekä kiinteistötunnukset ovat selkeästi yksilöllisiä tunnisteita, ne voivat kuitenkin muuttua esimerkiksi kuntaliitoksissa, joten kohteet tarvitsevat erillisen identifioivan sarjanumeron. Alkuperäisessä versiossa esiintyvä termi kylänosa on vanhasta ohjelmistosta periytyvä virheellinen käsite. Tietokannan käyttöönoton jälkeen aloitettiin tietojen syöttämisessä käytettävien lomakkeiden kehitys. Tässä työvaiheessa muunnettiin siis periaatteessa tietokannasta kahdeksan eri entiteettiä lomakkeiksi, joita käytetään rakennusinventoinnissa kerättävien tietojen tallentamiseen. Erilliset lomakkeet tarvittiin inventointiprojekteille, kunnille ja niiden kylille

19 LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA 11 tai kaupunginosille, kiinteistöille ja niiden rakennuksille sekä inventoiduille alueille ja niiden alla oleville arvoalueille. Syöttölomakkeiden jälkeen kehitettiin vielä työkalut kaikkien kohteiden selailuun, muokkaamiseen ja poistoon. Tällöin saatiin myös valmiiksi uusi kiinteistöselain (kuva 2.3), jossa oli kiinnitetty erityistä huomiota tekstidatan jäsentelyyn ja selkeään esitykseen. Samalla myös muille kohdetyypeille tehtiin vastaava näkymä. Kuva 2.3: Uusi kiinteistöselain. Huhtikuussa 2011 inventointiskeema saatiin lopulliseen muotoonsa. Tällöin voitiin aloittaa vanhojen inventointien muunto uuteen järjestelmään. Tätä operaatiota varten kehitettiin erillinen skripti, joka haki rivejä vanhoista tietokannoista ja sovitti uuteen sopivaksi. Kesällä 2010 aloitettiin sovelluksen testikäyttö, kun rakennusinventoijat alkoivat syöttää tietoja uusista kohteista MIP:iin. Tuotantokäyttöön sivusto otettiin syksyllä 2011.

20 LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA Käytetyt teknologiat Museon informaatioportaali perustuu kokonaisuudessaan avoimen lähdekoodin teknologioihin. Kaikissa sivuston palvelimissa on käyttöjärjestelmänä Ubuntu Server, httppalvelimena käytetään lighttpd-ohjelmistoa. Tietokantapalvelinohjelmistona käytetään PostgreSQL:ää, jota on laajennettu paikkatietoaineistojen käsittelyä helpottavalla PostGISlisäosalla. Sivuston pohjana on alun perin Lounaispaikkaa varten kehitetty LouGISohjelmisto, josta Museon informaatioportaalia varten karsittiin ominaisuudet, joita MIP:ssa ei tarvita. Tämän jälkeen alustaa on jatkokehitetty MIP:ia varten omassa projektissaan. Palvelintoteutus on tehty kokonaisuudessaan PHP-kielellä. Toteutuksen ytimen muodostaa PHP:tä 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ä skeeman rakennusinventointi taulusta kiinteistö rivi, jonka id on 3245 ja vaihtaa sen postinumeroksi 20810, operaatio onnistuu muutamalla funktiokutsulla ja olion ominaisuuksia muuttamalla: 1 $Kiinteistö = new Rakennusinventointi_2011_kiinteisto(); 2 $Kiinteistö->id = 3245; 3 $Kiinteistö->find(); 4 $Kiinteistö->fetch(); 5 $Kiinteistö->postinumero = 20810; 6 $Kiinteistö->update(); Myös suorien SQL-komentojen ajaminen dataolioiden kautta onnistuu. Alla olevassa esimerkissä haetaan kaikki järjestelmän kylät siten, että kylän nimen jälkeen tulee kylänumero suluissa. 1 $query = "SELECT 2 kylä.nimi ( kylä.kylänumero ) AS nimi 3 FROM rakennusinventointi_2011.kylä AS kylä ORDER BY kylä.nimi"; 4 $Kylä = new Rakennusinventointi_2011_kyla(); 5 $Kylä->query($query); Tyypillisesti dataoliot generoidaan etukäteen omiksi tiedostoikseen, minkä jälkeen niihin voidaan kirjoittaa taulukohtaisia funktioita. Perinnän ansiosta dataolioita pystyy laajentamaan helposti.

21 LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA 13 Sivuston käyttöliittymä on toteutettu Ext JS:llä, joka on JavaScript-kirjasto interaktiivisten www-ohjelmistojen luomiseen. Ext JS:n ideana on luoda HTML-elementeistä, kuten lomakkeen tekstikentästä tai napista, erilaisia komponentteja, joita voidaan yhdistellä halutulla tavalla erityisiin säiliötyyppisiin komponentteihin. Valmiina säiliökomponentteina Ext JS tarjoaa esimerkiksi paneelin ja ikkunan. [24] MIP:n karttaikkunan käyttöliittymässä käytetään OpenLayers-nimistä JavaScript-kirjastoa. Sen luoma karttanäkymä kapseloidaan Ext JS -yhteensopivaksi komponentiksi GeoExt-kirjaston avulla. Museon informaatioportaalilla ei tällä hetkellä ole omaa karttapalvelinta. Sivuston kartat tulevat Lounaispaikan Mapserver-ohjelmistoa käyttävältä karttapalvelimelta. 2.4 Alustan tekninen toteutus Museon informaatioportaalin pohjalla olevan LouGIS-moottorin tietokantarakenne esitellään kuvissa 2.4, 2.5 ja 2.6. Kuvaan 2.4 on koottu tietokantarakenteesta taulut, jotka liittyvät käyttäjiin, ryhmiin, sessioihin tai käyttöoikeuksiin. Sen keskeisin taulu on käyttäjätietoja sisältävä user. Käyttäjän kirjautuessa sisään sivustolle käynnistetään sessio, jonka tiedot tallentuvat user session-tauluun. Käyttäjäryhmät ovat taulussa group. Teknisesti olisi mahdollista, että käyttäjä voisi kuulua useampaan ryhmään (group users) tai ryhmä toisiin ryhmiin (group - subgroup). Käytännössä kuitenkin MIP:ssa on tällä hetkellä rajattu selkeyden vuoksi käyttäjäsysteemi siten, että käyttäjä kuuluu tasan yhteen ryhmään. Myöskään ryhmillä ei voi olla aliryhmiä. MIP:n käyttöoikeusjärjestelmä perustuu ryhmille annettaviin oikeuksiin. Taulu action sisältää erilaisia toimintoja, joihin ryhmillä voi olla oikeuksia. Taulussa action group ovat eri ryhmät, joihin toiminto voi kuulua. Nämä yhdistetään taulussa group privilege, johon tallennetaan ryhmän, toiminnon ja toimintoryhmän tunnisteet. Siihen voidaan tallentaa myös oikeuden tarkempi kohde, jos oikeus halutaan rajata

22 LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA 14 id enabled firstname lastname default_ password nickname phone mobile www image street1 street2 zip city users_start_sessions user Serial NN (PK) (AK1) session_id user_session Serial NN (PK) Boolean NN user_id Integer NN (PFK) NN lifetime Timestamp with time zone NN created Timestamp with time zone NN updated Timestamp with time zone NN ended Timestamp with time zone ip hostname user_agent session_data Text a_user_belongs_to_groups group_users group_id Integer NN (PFK) user_id Integer NN (PFK) admin Boolean NN groups_have_users action_group users_create_groups identifier NN (PK) admins_accept_groups title description Text group id Serial NN (PK) (AK1) founder_id Integer NN (FK) privileges_are_in_action_groups accepted Timestamp with time zone group_privilege accepted_by Integer (FK) id Serial NN (PK) public Boolean NN group_id Integer NN (FK) confirm_join Boolean NN action NN (FK) system Boolean NN action_group NN (FK) name target description Text own_only Boolean groups_have_privileges privileges_are_for_actions groups_are_parents groups_are_childs identifier action NN (PK) title group_subgroup description Text parent_id Integer NN (PFK) child_id Integer NN (PFK) Kuva 2.4: MIP:n tietokantarakenne käyttäjille, ryhmille, sessioille ja käyttöoikeuksille. koskemaan esimerkiksi vain jotain tiettyä entiteettiä. Lisäksi taulu sisältää totuusarvoisen attribuutin own only, jolla voidaan määrittää oikeus koskemaan vain käyttäjän itse luomia kohteita. Tällä systeemillä voitaisiin esimerkiksi luoda jonkin ryhmän käyttäjille oikeus poistaa itse luomiaan inventointiprojekteja. Tällöin tauluun group privilege lisättäisiin kyseisen ryhmän tunniste, toiminnon tunniste muokkaa, toimintoryhmä inventoinnit sekä kohde inventointiprojekti. Käyttöoikeuksien lisäksi järjestelmällä voidaan luoda myös rajoituksia käyttäjäryhmille. Esimerkiksi inventoijien täytyy valita aktiivinen inventointiprojekti ennen kuin he voivat tallentaa uusia inventointeja, joten heillä on aktiivisena toiminto pakota valinta kohteella inventointiprojekti.

23 LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA 15 Käyttöoikeusjärjestelmä on toteutettu user-tauluun perustuvassa luokassa Lougis - user. Siinä on kaksi funktiota, staattinen ja dynaaminen, joita käytetään sen mukaan, halutaanko tietää vain sisään kirjautuneen käyttäjän oikeus johonkin toimintoon vai käyttää erillistä luokasta luotua oliota. Esimerkiksi funktiokutsu Lougis user::isallowed("delete", "entities") palauttaa totuusarvon sen mukaan, onko nykyisellä käyttäjällä oikeus poistaa rivejä tietokannasta. Vastaava kutsu tehtäisiin dynaamisesti Lougis user-tyyppiselle oliolle funktiolla hasprivilege(). Kuvaan 2.5 on koottu LouGIS-alustaan MIP:ia varten lisättyjen ominaisuuksien tietokantarakenne. Niihin kuuluvat lomakemuisti, muutoshistoria sekä liitetiedosto- ja kuvalinkitysjärjestelmät. Kaikkia näitäkin yhdistää käyttäjätietoja sisältävä user-taulu. form_memory id Serial NN (PK) user_id Integer NN (FK) date Timestamp with time zone form_type NN name data Text a_user_saves_forms modification_history_data history_id Integer NN (PFK) attribute value Text id user Serial NN (PK) (AK1) enabled Boolean NN firstname NN lastname NN default_ NN password NN nickname phone mobile www image street1 street2 zip city a_modification_history_entry_may_have_data modification_history id Serial NN (PK) user_id Integer (FK) ref_table NN ref_keys NN ref_values NN ref_action NN source modification_time Timestamp with time zone comments Text a_user_makes_modifications user_adds_an_attachment user_adds_a_photo id user_id ref_schema ref_table ref_primary_keys ref_row_ids filename path original_filename title description date_added mip_attachment Serial NN (PK) Integer NN (FK) Text Timestamp with time zone 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 NN (PK) Integer NN (FK) Text Timestamp with time zone Timestamp with time zone Kuva 2.5: MIP:n tietokantarakenne lomakemuistille, muutoshistorialle sekä kuville ja liitetiedostoille.

24 LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA 16 Sivusto sisältää täysin geneerisen toiminnallisuuden, jonka avulla mikä tahansa keskeneräinen lomake voidaan tallentaa ja myöhemmin palauttaa. Lomakemuistia käytettäessä käyttäjältä kysytään lomakkeelle myöhempää tunnistusta helpottava nimi (kuten Kiinteistö ), jonka jälkeen palvelimelle lähetetään nimen lisäksi lomakkeen ennalta määrätty tyyppi (esim. Kiinteistö ) ja lomakkeen sisältö JSON-koodattuna assosiatiivisena taulukkona. Tiedot palvelin tallentaa form memory-tauluun yhdessä tallennuksen tehneen käyttäjän tunnisteen ja päivämäärän kanssa. Toinen geneerinen toiminto on tauluihin modification history ja modification history data perustuva muutoshistoria. Normaalisti muutoshistoria toimii siten, että ennen muutoksen tekoa luodaan modification historytauluun rivi, johon tallennetaan muutoksen tehneen käyttäjän tunniste, kohdetaulu, taulun avainsarakkeiden nimet ja niiden arvot sekä tehty toiminto (päivitys vai alkuperäinen lisäys). Tämän jälkeen luodaan tauluun modification history data jokaiselle muuttuneelle arvolle rivi, johon tulee sarakkeen nimi ja uusi arvo. Kun vanhoja tietokantoja muunnettiin uuteen järjestelmään, muutoshistoriaan lisättiin vielä mahdollisuus merkitä muutoksen lähde selväkielisenä tekstinä ja kommentit tapahtumalle. Lisäksi lisättiin uusi toiminto, muunto. Näin muutoshistoriaan pystyttiin tallentamaan esimerkiksi tieto siitä, että kiinteistö tunnisteella on tuotu tietokannasta Inventoinnit ennen 1998 ja että alkuperäisen inventoinnin on tehnyt K. K. elokuussa Lähdettä voidaan käyttää myös kertomaan selväkielisenä muutoksen tekijän nimi, jos hänellä ei ole tunnuksia järjestelmään. Tämä oli tilanne, kun tietokannan Inventoinnit inventointeja tuotiin uuteen järjestelmään. Kyseisessä tietokannassa on jokaisessa inventoinnissa tieto siitä, kuka on kohteen tietoja viimeksi muokannut ja koska. Päivämäärät voitiin muuntaa suoraan uuden järjestelmän vastaavaan kenttään, mutta useimmilla henkilöillä ei luonnollisesti ollut tunnuksia uuteen järjestelmään. Niinpä heidät merkittiin muutoksen lähteiksi.

25 LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA 17 MIP:n kuva- ja liitetiedostojärjestelmien ideana on se, että mihin tahansa tietokannan riviin voidaan liittää miten monta kuvaa tai liitetiedostoa tahansa. Liitetiedostojen tiedot tallennetaan mip attachment-tauluun. Jokaisesta tiedostosta tallennetaan muutoksen tehneen käyttäjän tunniste, kohdeskeema ja -taulu, avaimet sisältävien sarakkeiden nimet ja niiden arvot, tiedoston nykyinen nimi ja sen polku kuvapalvelimella sekä alkuperäinen tiedostonimi ja lisäyspäivä. Lisäksi tallennetaan tiedoston otsikko ja kuvaus, jos käyttäjä on sellaiset tiedostoa lisätessään antanut. Kuvien tiedot sisältävä mip photo-taulu on muuten samanlainen, mutta siihen tallennetaan lisäksi kuvan kuvauspäivämäärä. Kuvien ja liitetiedostojen käytön helpottamiseksi MIP:n dataolioita on laajennettu geneerisillä funktioilla getattachments() ja getimages(). Niiden avulla jokaiseen dataolioon linkitetyt kuvat ja liitetiedostot pystytään hakemaan automaattisesti. Portaali tukee monikielisyyttä tietokantapohjaisella järjestelmällä, jonka taulurakennetta esitellään kuvassa 2.6. Järjestelmässä tallennetaan kaikki käännettävät tekstit ja niiden kielet ui translate key-tauluun. Vastaavasti tekstien käännökset tallennetaan ui translate text-tauluun. Siihen voidaan merkitä myös käännöksen tekijä source-kohtaan. Tauluun language tallennetaan sivustolla käytössä olevat kielet. id name order_id language NN (PK) (AK1) NN Integer a_translation_key_is_in_a_language ui_translate_key id Serial NN (PK) site_id NN (FK) lang_id NN (FK) keys_have_translations text a_translation_has_a_language ui_translate_text id Serial NN (PK) key_id Integer NN (FK) translation_lang NN (FK) translation_text Text source a_translation_belongs_to_a_site cms_site id NN (PK) name url Kuva 2.6: MIP:n tietokantarakenne kieli- ja käännöstuelle. LouGIS-alustan CMS- ja moniportaalituen takia sivustolla on jäänteenä myös cms site-taulu, jota MIP:ssä ei käytetä.

26 LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA Rakennusinventoinnin tietokantarakenne Museon informaatioportaaliin kehitetty uusi rakennusinventointiskeema esitellään kuvissa 2.7, 2.8 ja 2.9. Kuvaan 2.7 on koottu kuntien, kylien, kiinteistöjen ja rakennusten taulut. Kunta ja kylä määrittävät kiinteistön sijainnin siten, että kiinteistö kuuluu aina johonkin kylään, joka kuuluu johonkin kuntaan. Koska kuntia ja kyliä ei sinänsä inventoida, niistä tallennetaan vain kunta- tai kylänumero ja nimi. Kiinteistöstä sen sijaan pyritään tallentamaan kylän ja kiinteistötunnuksen lisäksi paljon muitakin tietoja, kuten sen sijainti pisteenä ja sen omistajatiedot sekä kuvailevia tekstejä esimerkiksi sen asutushistoriasta, lähiympäristöstä ja sen pihapiiristä. kunta id Serial NN (PK) kuntanumero Character varying(3) NN nimi NN kunnissa_on_kyliä id kylä Serial NN (PK) kunta_id Integer NN (FK) kylänumero NN nimi NN kylissä_on_kiinteistöjä kiinteistöillä_on_rakennuksia kiinteistö id Serial NN (PK) kylä_id Integer NN (FK) kiinteistötunnus nimi osoite postinumero paikkakunta aluetyyppi arvotus historiallinen_tilatyyppi 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 rakentajan_ammatti_arvo Bigint rakentajan_tyyppi rakentajan_laji lisätiedot Text rakennuksilla_on_rakentajia rakennus id Serial NN (PK) kiinteistö_id Integer (FK) rakennusnumero rakennustunnus rakennustyyppi kerroslukumäärä rakennusvuosi muutosvuodet alkuperäinen_käyttö nykykäyttö perustus runko vuoraus ulkoväri katto kate kunto erityispiirteet Text rakennushistoria Text sisätilakuvaus Text muut_tiedot Text rakennuksen_sijainti geometry Kuva 2.7: MIP:n rakennusinventointien tietokantarakenne kunnalle, kylälle, kiinteistölle ja rakennukselle.

27 LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA 19 Kiinteistöllä on yksi tai useampia rakennuksia, joista jokaisesta pyritään tallentamaan juoksevan rakennusnumeron lisäksi sen teknisiä tietoja, kuten rakennusvuodet, perustuksen materiaali ja sen kunto. Lisäksi voidaan tallentaa kuvailevat tekstit rakennuksen erityispiirteistä, rakennushistoriasta ja sen sisätilasta. Tiedot rakennusten rakentajista ja suunnittelijoista tallennetaan rakennus rakentaja-tauluun. Kuvaan 2.8 on koottu inventointiprojektiin ja alueeseen liittyvät taulut. Inventointiprojekti on kokonaisuus, jonka määräämillä määreillä rakennusinventointia tehdään. Siihen kuuluu kokonaisuutta kuvaava nimi ja pidempi kuvaus. Inventointiaika voitaisiin periaatteessa jakaa kahdeksi päivämäärä-tyyppiseksi kentäksi: inventoinnin alku ja inventoinnin loppu. Kuitenkaan käytännössä näin ei toimita, koska kyseiseen kenttään kirjataan usein epämääräisiä aikavälejä, kuten Kesä inventointiprojekti kiinteistö_inventointiprojekti id Serial NN (PK) inventointiprojekti_id Integer NN (PFK) nimi NN kiinteistö_id Integer NN (PFK) kuvaus Text inventoija inventointiaika kenttäpäivä Timestamp with time zone toimeksiantaja inventointiprojektit_liittyvät_kiinteistöihin tyyppi inventointiprojekti_inventoija inventointiprojektit_liittyvät_alueisiin id Integer NN (PK) inventointiprojekti_id Integer NN (PFK) alue_inventointiprojekti inventoija_id Integer alue_id Integer NN (PFK) inventoija_nimi NN inventointiprojekti_id Integer NN (PFK) inventoija_arvo inventointiprojekteilla_on_inventoijia alue_kylä alueita_inventoidaan_inventointiprojekteissa alue_id Integer NN (PFK) kylä_id Integer NN (PFK) id alue Serial NN (PK) nimi 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 (AK1) lähteet Text aluetyyppi NN keskipiste geometry arvotus aluerajaus geometry kuvaus Text alueet_sisältävät_arvoalueita keskipiste geometry aluerajaus geometry Kuva 2.8: MIP:n rakennusinventointien tietokantarakenne inventointiprojektille, alueelle ja arvoalueelle.

28 LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA 20 Tyypillisessä inventointiprojektissa yksi henkilö on tehnyt kaikki kyseisen projektin inventoinnit. Kuitenkin on myös inventointiprojekteja, joiden inventointeja on tehnyt useampi henkilö. Niinpä tiedot yhden projektin inventoijista kerätään erilliseen inventointiprojekti inventoija-tauluun. Koska kaikilla inventoijilla ei ole tunnuksia MIP:iin, inventoijista ei voida kirjata vain heidän tunnistettaan, vaan inventoijan nimi tallennetaan aina erikseen. Inventointiprojektit liittyvät suoraan kiinteistöihin (kiinteistö inventointiprojekti) ja alueisiin (alue inventointiprojekti). Molempien kohdalla tarvitaan käytännössä monesta moneen -relaatiota, koska yhtä aluetta tai kiinteistöä voidaan inventoida monessa inventointiprojektissa, ja vastaavasti yhdessä inventointiprojektissa voidaan inventoida monia alueita tai kiinteistöjä. Kiinteistön kohdalla voidaan lisäksi kirjata, kuka kyseisen kiinteistön on inventoinut ja minä päivänä. Rakennusinventoinnissa alue on yhden tai useamman kylän (alue kylä) alueella sijaitseva kokonaisuus, joka on jostain syystä inventoinnin kannalta kiinnostava. Alueesta pyritään tallentamaan tekstimuotoisten perustietojen lisäksi sen kattama ala (aluerajaus) pistejoukkona, jossa ensimmäinen ja viimeinen piste ovat samoja. Jos alan tallennus ei ole jostain syystä mahdollista, voidaan alueesta tallentaa vain sen keskipiste. Aluerajaus ja keskipiste tallennetaan molemmat PostGIS:n erityistä geometrioiden tallennukseen tarkoitettua tietotyyppiä geometry käyttäen. Jokaisen alueen alla voi olla yksi tai useampia arvoalueita. Ne ovat yhdestä alueesta rajattuja pienempiä kokonaisuuksia, joilla on vaikkapa kulttuurihistoriallista merkitystä. Alueen tapaan arvoalueen aluerajaus tai keskipiste voidaan tallentaa geometriana. Kiinteistöille, rakennuksille ja arvoalueille voidaan antaa myös erilaisia kulttuurihistoriallisia arvoja ja suojelumerkintöjä. Niissä tarvittavaa taulurakennetta esitellään kiinteistöjen ja arvoalueiden osalta kuvassa 2.9. MIP:ssa erilaisia kulttuurihistoriallisia arvoja on yhteensä 15, ja ne on koottu tauluun kulttuurihistoriallinen arvo. Kun kohteelle annetaan erilaisia arvoja, niille voidaan myös antaa kuvaus tai perustelu, miksi

29 LUKU 2. TAUSTAA MUSEON INFORMAATIOPORTAALISTA 21 kyseinen arvo kyseiselle kohteelle on annettu. Suojelumerkinnöissä on käytössä vastaava järjestelmä, jossa tosin perustelun sijaan merkinnän kohteen valinnan jälkeen kerrotaan, mikä merkintä kohteessa on ja lisäksi annetaan selite kyseiselle merkinnälle. Esimerkiksi rakennuksella voi olla asemakaavassa merkintä SR, jonka selitteenä on säilytettävä rakennus. kulttuurihistoriallinen_arvo kulttuurihistoriallinen_arvo NN (PK) selite NN järjestysnumero Integer ryhmä arvoalueiden_kulttuurihistoriallisilla_arvoilla_on_nimi kiinteistöjen_kulttuurihistoriallisilla_arvoilla_on_nimi arvoalue_kulttuurihistoriallinen_arvo kiinteistö_kulttuurihistoriallinen_arvo arvoalue_id Integer NN (PFK) kiinteistö_id Integer NN (PFK) kulttuurihistoriallinen_arvo NN (PFK) kulttuurihistoriallinen_arvo NN (PFK) kuvaus Text kuvaus Text arvoalueilla_on_kulttuurihistoriallisia_arvoja arvoalue id Serial NN (PK) alue_id Integer NN (FK) nimi (AK1) aluetyyppi NN arvotus kuvaus Text keskipiste geometry aluerajaus geometry arvoalueilla_on_suojelumerkintöjä arvoalue_suojelumerkintä arvoalue_id Integer NN (PFK) kohde NN (PFK) merkintä merkinnän_selite Text kiinteistöillä_on_kulttuurihistoriallisia_arvoja kiinteistö id Serial NN (PK) kylä_id Integer NN (FK) kiinteistötunnus nimi osoite postinumero paikkakunta aluetyyppi arvotus historiallinen_tilatyyppi lisätiedot Text asutushistoria Text lähiympäristö Text pihapiiri Text omistajatiedot Text perustelut_yhteenveto Text lähteet Text kiinteistön_sijainti geometry kiinteistöillä_on_suojelumerkintöjä kiinteistö_suojelumerkintä kiinteistö_id Integer NN (PFK) kohde NN (PFK) merkintä merkinnän_selite Text arvoalueen_suojelumerkinnällä_on_kohde kiinteistön_suojelumerkinnällä_on_kohde suojelumerkintä_kohde kohde NN (PK) nimi NN kuvaus Text seqnum Integer Kuva 2.9: MIP:n rakennusinventointien arvoalueiden ja kiinteistöjen kulttuurihistoriallisten arvojen ja suojelumerkintöjen tietokantarakenne. Vastaava rakenne on käytössä myös rakennuksilla.

30 Luku 3 Paikkatietovälityspalvelimen suunnittelu Tässä työssä on siis tavoitteena kehittää geneerinen paikkatietovälityspalvelin, joka helpottaisi paikkatietoaineistojen hallintaa ja käsittelyä projektien sisällä tarjoamalla yleiskäyttöisen rajapinnan eri aineistojen soveltamiseen. Tarkoituksena olisi se, että luotava järjestelmä osaisi yhdistellä eri lähteistä saatavia paikkatietoaineistoja sekä tarjota asiakkaalle järkevää tietoa halutusta kohteesta halutussa formaatissa ja koordinaattijärjestelmässä ilman, että asiakkaan tarvitsee suoraan tietää, mistä aineistoista tietoa haetaan. Keskeinen kysymys järjestelmän kehityksessä on luonnollisesti tietojen oikeellisuus. Käytännössä ongelmana ei siis ole vain se, miten valitaan oikeat lähteet hakea tietoa, sillä lisäongelma muodostuu tulosten yhdistelystä. Toinen keskeinen kehityskysymys liittyy geneerisyyteen ja sen ylläpitämiseen. Geneerisyyttä ja sen roolia tässä työssä kehitettävässä paikkatietovälityspalvelimessa käsitellään tarkemmin seuraavassa kohdassa. Sen jälkeen aloitetaan paikkatietovälityspalvelimen suunnitteluprosessin esittely analysoimalla palvelimelle asetettuja vaatimuksia ja tavoitteita. Samalla käydään läpi myös Museon informaatioportaalin asettamat erityisvaatimukset, ja esitetään niiden pohjalta kaksi käyttötapausta palvelimelle, joista toisen

31 LUKU 3. PAIKKATIETOVÄLITYSPALVELIMEN SUUNNITTELU 23 pohjalta suunnitellaan ja toteutetaan palvelimen prototyyppi. Lopuksi prototyypin toteutus puretaan vaiheisiin ja analysoidaan, jonka jälkeen tehtyjen havaintojen pohjalta aloitetaan varsinaisen paikkatietovälityspalvelimen tietokanta- ja luokkarakenteen suunnittelu. 3.1 Geneerisyys Geneerinen ohjelmointi perustuu periaatteeseen, jonka mukaan ohjelmisto voidaan jakaa komponenteiksi, jotka pyrkivät tekemään mahdollisimman vähän oletuksia muista komponenteista, jolloin niiden yhdistely onnistuu mahdollisimman joustavasti [25]. Geneerisyys sinänsä on terminä jossain määrin vaikeasti määriteltävä, koska moni määritys riippuu käytössä olevasta ohjelmointikielestä. Usein lähdetään liikkeelle esimerkiksi C++:n templaattijärjestelmän kaltaisesta tietorakenteiden parametrisoinnista tyypeillä [26], mikä ei oikein sovi tähän projektiin, koska palvelin tullaan toteuttamaan luonteeltaan dynaamisella PHP-kielellä [27]. Eräs yleisesti hyväksytty määritelmä geneeriselle ohjelmoinnille on niin sanottu Musser-Stepanovin määritelmä. Sen mukaan geneerisen ohjelmoinnin ideana on aloittaa käytännöllisestä ja käyttökelpoisesta algoritmista, jota aletaan abstrahoida. Tavoitteena on löytää algoritmien ja tietorakenteiden konsepti, niiden abstrakti määritelmä. Käytössä olevien algoritmien tulisi olla täysin riippumattomia datasta, jota ne käsittelevät. [28] Tästä näkökulmasta palvelimesta voidaan kehittää ensin prototyyppi, joka tuottaa etukäteen päätetyistä aineistoista aina samantyyppistä sisältöä. Sen pohjalta voidaan alkaa etsiä yleisempää versiota, työkalua, jossa erilaisia paikkatietoaineistoja pääsisi käsittelemään yhtenäisen rajapinnan kautta. Rajapinnan pitäisi olla sellainen, että uusien, hyvinkin erilaisten aineistotyyppien lisääminen järjestelmään onnistuu mahdollisimman yksinkertaisesti ja vapaasti. Aineistoille tehtävien operaatioiden osalta geneerisyys tarkoittaa sitä, että yksittäisen aineiston tyypin tai operaatioiden keskinäisen suoritusjärjestyksen ei pitäisi vaikuttaa

32 LUKU 3. PAIKKATIETOVÄLITYSPALVELIMEN SUUNNITTELU 24 palvelimen toimintaan. Näin eri operaatioita suorittavat luokat voisivat toimia vapaahkosti välittämättä toisistaan. Tällöin luokkia määrittävästä rajapinnasta tulee väkisinkin hyvin yksinkertainen. Järjestelmän arkkitehtuurin kannalta geneerisyydellä pyritään siihen, että se on helposti ylläpidettävä ja laajennettava sekä siihen, että sen komponentit ovat uudelleenkäytettäviä [29]. Käytännössä tällaisen tietoa välittävän ja käsittelevän palvelimen tapauksessa geneerisyyden merkitys korostuu siis ennen muuta siinä, että datan käsittelystä vastaavien luokkien pitää olla helposti muokattavia, ja niitä täytyy pystyä ongelmitta korvaamaan toisilla. Toisin sanoen tiedon käsittelyprosessista pitää tehdä sellainen, että sen eri vaiheiden muuttaminen onnistuu yksinkertaisesti. 3.2 Palvelimen kehityksen tavoitteet Paikkatietovälityspalvelimen tavoitteena on tarjota ohjelmistoille geneerinen paikkatietosovelluskerros, jonka avulla voitaisiin esimerkiksi yhdistää paikallisia entiteettejä kolmannen osapuolen paikkatietoaineistoihin ilman, että käyttäjän täytyy täsmälleen tietää, mistä paikkatietoaineistoista tietoa haetaan. Käytännössä tämä tarkoittaa sitä, että palvelin kykenee sille annetun sijainti- ja siihen liittyvän metatiedon perusteella valitsemaan tuntemistaan aineistoista kyseiseen tapaukseen soveltuvat, ja osaa hakea niistä tietoa. MIP:ssä ensisijainen käyttökohde palvelimelle olisi uusien kohteiden lisäämisen helpottaminen. Esimerkiksi kiinteistöjen ja rakennusten muokkauksessa käytettäviin lomakkeisiin on toivottu toimintoa, jonka avulla käyttäjä voisi hakea Maanmittauslaitoksen rajapintapalveluista tietoa kohteesta klikkaamalla sitä kartalta. Palvelimelle tehtäisiin esimerkiksi kysely Kerro mitä pystyt tarjoamaan tietokannan entiteetille kiinteistö pisteessä , (EPSG:3067) JSON-formaatissa, minkä jälkeen palvelin osaisi tuntemistaan aineistoista hakea kiinteistötietoja, yhdistää niitä järkeviksi kokonaisuuksiksi, ja lopulta palauttaa lopputuloksen käyttäjälle JSON-enkoodattuna assosiatiivisena taulukkona.

33 LUKU 3. PAIKKATIETOVÄLITYSPALVELIMEN SUUNNITTELU 25 Toinen MIP:iin toivottu toiminnallisuus on palvelusta saatavien tietojen näyttäminen käyttäjälle sellaisenaan. Tällaiselle ominaisuudelle olisi käyttöä esimerkiksi uusien rakennusten lisäyksessä, sillä vaikka Maanmittauslaitoksen tarjoamat rakennustiedot ovat erinomainen lähde rakennustietojen syöttämiseen, ne ovat usein epätäsmällisiä ja jossain määrin epäluotettavia. Niinpä lomakkeen kenttiä ei voida automaattisesti täyttää, vaan palvelun tarjoamat tiedot pitäisi tarjota käyttäjälle helposti luettavassa formaatissa. Näiden vaatimusten perusteella palvelimelle voidaan tehdä kaksi käyttötapausta. Ensimmäinen kattaa palvelimen löytämien tietojen näyttämisen käyttäjälle sellaisenaan. Käyttötapaus 1: Palauta HTML-taulukkona rakennuksiin liittyviä tietoja annetusta pisteestä. 1. Haetaan rakennustietoja sisältävät aineistot. 2. Muunnetaan annettu piste aineiston asetuksiin määritetyn kokoiseksi neliön muotoiseksi aluerajaukseksi. 3. Haetaan tuloksia aineistoista aluerajauksilla. 4. Kerätään tulokset yhteen ja muutetaan ne yhdenmukaiseen formaattiin. 5. Käsitellään tuloksista luettavampia. 6. Palautetaan tulokset käyttäjälle HTML:n taulukkona. Käytännössä ongelmia voi tuottaa viides kohta, jossa palveluista saatava mahdollisesti monitasoinen data pitää jotenkin litistää mahdollisimman selkeäksi, avain-arvo-pareista koostuvaksi, mielellään yksiulotteiseksi taulukoksi. Toinen toiminnallisuuskuvaus on ensimmäistä jonkin verran monimutkaisempi, koska siinä yhdistellään eri lähteistä saatavia tuloksia. Kuvaus kattaa lomakkeiden automaattisen täydentämisen. Käyttötapaus 2: Palauta JSON-koodattuna taulukkona annettuun pisteeseen liittyviä tietoja Museon informaatioportaalin kiinteistölomakkeelle sovitettuna. 1. Haetaan aineistot, jotka tarjoavat kiinteistötietoja. 2. Muunnetaan annettu piste aineiston asetuksiin määritetyn kokoiseksi neliön muotoiseksi aluerajaukseksi.

34 LUKU 3. PAIKKATIETOVÄLITYSPALVELIMEN SUUNNITTELU Haetaan tuloksia aineistoista aluerajauksilla. 4. Muunnetaan aineistoista saatavat tiedot järjestelmän sisäiseen formaattiin. 5. Yhdistetään eri aineistoista kiinteistökohtaisia kokonaisuuksia. 6. Haetaan yhdistellyistä tuloksista kentät, joille löytyy vastaava kohta kiinteistölomakkeesta, nimetään ja jälkikäsitellään kukin kenttä lomakkeen vaatimusten mukaisesti. 7. Palautetaan tulokset JSON-koodattuna. Ensimmäisen kuvauksen tapaan tulosten jälkikäsittely muodostanee ongelmia tässäkin kohtaa. Kuitenkin suurempi kysymys liittyy tulosten yhdistelyyn. Palvelimen toteutuksessa ei riitä vielä se, että se osaa saamiensa parametrien perusteella valita oikeat aineistot, vaan lisäksi siihen täytyy kehittää logiikka, jonka avulla se osaa muodostaa eri lähteistä saaduista tuloksista järkeviä kokonaisuuksia. Yksinkertaisesti tämä onnistuisi tallentamalla palvelimelle aineistojen parametrien lisäksi tieto siitä, mistä kentistä eri lähteiden tuloksia voi liittää toisiinsa. 3.3 Prototyypin suunnittelu Paikkatietovälityspalvelimesta tehtäväksi prototyypiksi valittiin kohdan 3.1 toiminnallisuuskuvauksen 2 mukainen Museon informaatioportaaliin toivottu toiminto kiinteistölomakkeen automaattisesta täydentämisestä. Prototyypin avulla oli tavoitteena tutkia muutaman aineiston avulla, miten saatuja tuloksia täytyy käsitellä, jotta niistä saadaan halutun kaltaisia. Prototyypin työstäminen aloitettiin tutustumalla Maanmittauslaitoksen viranomaiskäyttöön tarjoamiin rajapintapalveluihin [30]. Niistä kiinnostaviksi osoittautuivat tietoa kiinteistöjen rajoista, nimistä ja kiinteistötunnuksista tarjoava Kiinteistötietojen kyselypalvelu ja erilaisia rakennustietoja sisältävä Rakennustietojen kyselypalvelu. Kiinteistötietojen kyselypalvelun avulla selvitettäisiin, mitä kiinteistöä käyttäjä on tarkoittanut karttaa klikatessaan, jonka jälkeen Rakennustietojen kyselypalvelusta haettaisiin kyseisen kiinteistön

35 LUKU 3. PAIKKATIETOVÄLITYSPALVELIMEN SUUNNITTELU 27 päärakennuksen tiedoista kiinteistölle postinumero, osoite ja omistajatiedot sekä kiinteistön sijainti 1. Maanmittauslaitos tarjoaa niin kiinteistöjen kuin rakennustenkin kattamat alat monikulmioina. Täten tietoja haettaessa voidaan olla melko varmoja siitä, että käyttäjä on klikannut kartalta oikeaa kiinteistöä, joten pisteestä luotava karttarajaus voidaan asettaa melko pieneksi. Sen sijaan rakennustietoja haettaessa halutaan löytää juurikin oikean kiinteistön päärakennus, joten aluerajaus täytyy asettaa huomattavasti suuremmaksi. Molemmat palvelut implementoivat OGC:n OpenGIS Web Feature Service (WFS) -protokollan version WFS:n ideana on tarjota paikkatietoaineistoja GML-muodossa. Kyselyt WFS-palveluihin tehdään HTTP-protokollaa käyttäen joko URL-parametreina tai XML-muotoisina kyselyinä. Eri kyselytyyppeihin kuuluvat palvelun ominaisuustietokysely GetCapabilities, kohdetyyppien XML-skeemakuvauksen tarjoava Describe- FeatureType sekä varsinaisia paikkatietoelementtejä parametrien perusteella tarjoava GetFeature. [11] Periaatteessa GetFeature-kyselyssä tarvittavat parametrit olisi mahdollista muodostaa ajon aikana muiden kyselyiden avulla, mutta viiveen minimoimiseksi prototyyppiin kannattanee tallentaa suurin osa parametreista suoraan. Kiinteistötietojen kyselypalveluun tehtävien WFS-kyselyjen parametreja käydään läpi taulukossa 3.1. Parametreista ainoastaan kyselyn koordinaattirajaus, BBOX, on pakko määrittää ajon aikana, koska se täytyy muodostaa käyttäjältä tulevasta pisteestä. Muut parametrit voidaan asettaa kiinteästi. 3.4 Prototyypin toteutus Prototyypin toteutus päätettiin pitää mahdollisimman yksinkertaisena ja suoraviivaisena, eikä siitä ollut tavoitteena kehittää sinänsä geneeristä. Geneerisyys oli kuitenkin toteutusratkaisuja tehtäessä keskeisessä osassa, sillä prototyypissä tehtävät ratkaisut haluttiin kui- 1 Rakennusinventoinnissa kiinteistön sijainniksi määritetään sen päärakennuksen sijainti.

36 LUKU 3. PAIKKATIETOVÄLITYSPALVELIMEN SUUNNITTELU 28 Taulukko 3.1: Kiinteistötietojen kyselypalveluun tehtävien WFS-kyselyjen parametreja selityksineen. Kyselyt tehdään lisäämällä palvelun WFS-osoitteen jälkeen parametreja muodossa?parametri1=arvo1&parametri2=arvo2 jne. Rakennustietojen kyselypalveluun tehtävien kyselyjen parametrit ja niiden arvot ovat suurimmalta osalta samat, ainoastaan parametreilla NAMESPACE ja TYPENAME käytetään eri arvoja. Parametri Arvo SERVICE WFS Käytetty protokolla VERSION Protokollan versio REQUEST GetFeature Kyselyn tyyppi NAMESPACE xmlns(ktjkiiwfs= Kyselyn XML-nimiavaruus TYPENAME ktjkiiwfs:rekisteriyksikontietoja Kohdetyypin nimi, eli mitä tietoja palvelulta halutaan PROPERTYNAME ktjkiiwfs:kiinteistotunnus,ktjkiiwfs:nimi Tiedot, jotka palvelulta halutaan BBOX esim , ,240682, ,EPSG:3067 Koordinaattirajaus laatikkona muodossa xmax,ymax,xmin,ymin,koordinaattijärjestelmä SRSNAME EPSG:3067 Tuloksilta haluttu koordinaattijärjestelmä MAXFEATURES esim. 3 Suurin sallittu tulosten määrä RESULTTYPE results Tulosten tyyppi. Vaihtoehtoisella arvolla hits palauttaisi tulosten määrän tenkin pitää sellaisina, että ne olisi mahdollista yleistää geneerisemmiksi. Yhden aineiston sisältöön tai rakenteeseen perustuvia ratkaisuja piti siis välttää. Toteutuksen idea on sinänsä yksinkertainen: haetaan kiinteistö- ja rakennustietoja sopivalla aluerajauksella, jonka jälkeen käydään läpi tuloksena saadut kiinteistöt, joihin yhdistetään rakennusten joukosta mahdollisesti löydettyjen päärakennusten tiedot. Tuloksista haetaan sopivat kentät, jotka sovitetaan kiinteistölomakkeen vastaaviin. Sovelluksen toimintalogiikkaa esitellään kuvassa 3.1. Prototyypin suoritus alkaa, kun siihen syötetään pisteen x- ja y-koordinaatit EUREF- FIN-koordinaatistossa. Koordinaattien pohjalta muodostetaan 25 m 2 kokoinen neliönmuotoinen karttarajaus, jonka keskikohta annettu piste on. Yhdessä tämän karttarajauksen

37 LUKU 3. PAIKKATIETOVÄLITYSPALVELIMEN SUUNNITTELU Käyttöliittymä x- ja y-koordinaatit kiinteistöjen tiedot rakennustiedoilla laajennettuna ja lomakkeelle sovitettuna assosiatiivisena taulukkona Paikkatietovälityspalvelimen prototyyppi aluerajaus 25 m 2, keskipisteenä (x,y) alueella olevien kiinteistöjen nimet ja kiinteistötunnukset aluerajaus 250 m 2, keskipisteenä (x,y) alueella olevien rakennusten tiedot Kiinteistötietojen kyselypalvelu (WFS) Rakennustietojen kyselypalvelu (WFS) Kuva 3.1: Paikkatietovälityspalvelimen prototyypin toimintalogiikka. ja prototyyppiin kiinteästi tallennettujen parametrien kanssa muodostetaan URL, jonka avulla tehdään WFS-kysely Kiinteistötietojen kyselypalveluun. Kyselyn tuloksena saatu tekstimuotoinen XML-data muunnetaan PHP:n SimpleXML-olioksi. Sama operaatio toistetaan Rakennustietojen kyselypalvelun kanssa, tosin käytössä olevan karttarajauksen koko kymmenkertaistetaan 250 neliömetriin. Suuri kokoero selittyy osittain sillä, että kiinteistön ala on yleensä huomattavasti rakennuksen alaa suurempi, joten pisteen voidaan melko varmasti olettaa olevan oikean kiinteistön alueella. Suurin syy erilaisiin karttarajauksiin tulee kuitenkin siitä, miten prototyyppi käsittelee palveluista saamiaan tuloksia. WFS-kyselyjen valmistuttua aloitetaan Kiinteistötietojen kyselypalvelujen tulosten läpikäynti. Yksi kerrallaan kunkin kiinteistön tiedot haetaan tulosjoukosta ja muunnetaan