JHS XXX Paikkatiedon yksilöivät tunnisteet Liite 1: Käyttötapauksia

Transkriptio

1 JHS XXX Paikkatiedon yksilöivät tunnisteet Liite 1: Käyttötapauksia Versio: Luonnos keskustelutilaisuutta varten (huhtikuu 2014) Julkaistu: - Voimassaoloaika: - Työryhmän kommentti: Tässä liitteessä on kuvattu suositusluonnoksen pohjalle tehtyjä käyttötapauksia. Käyttötapausten kuvauksia muokataan jatkotyössä. Mahdollisesti myös muitakin laadittuja käyttötapauksia tuodaan mukaan. 1 Avoimen datan kehittäjät 1.1 Käyttötapaus avoimien paikkatietotuotteiden löytämisestä ja käyttöönottamisesta Tampereen kaupunki avasi ensimmäisiä paikkatietotuotteita avoimen datan lisenssin alaisena joulukuussa Avoimien paikkatietotuotteiden jakelu tapahtuu kyselypalvelurajapinnan (WFS) kautta, jossa tuotteita tällä hetkellä jaossa 32 kpl. Avoimien paikkatietoaineistojen käyttäjäryhmiä on useita, mutta tässä käyttötapauksessa keskitytään kuvaamaan avoimen datan käyttöön saamista avoimen datan kehittäjän näkökulmasta. Avoimia paikkatietoaineistoja voidaan etsiä kahdesta palvelusta, Tampereen omasta avoimen datan datakatalogista tai kansallisesta paikkatietohakemistosta ( Paikkatietohakemistossa on tällä hetkellä kuvailtuna metatiedoilla vain osa avoimista paikkatietoaineistoista, mutta Tampereen datakatalogista löytyvät kaikki tuotteet. Tampereen datakatalogissa metatietoelementit eivät perustu mihinkään metatietostandardiin. 1.2 Avoimien paikkatietotuotteiden hakeminen paikkatietohakemiston kautta Kehittäjä kirjautuu paikkatietohakemistoon verkko-osoitteella Avoimien aineistojen haku aloitetaan kirjoittamalla hakukenttään esimerkiksi Avoin data, jolloin palvelu listaa kaikki ne metatietokuvailut, joissa Avoin data esiintyy. Metatietokuvailuista löytyvät avoimen datan lisenssin sekä fyysisen kyselypalvelun URL -osoitteet. Kehittäjä hyödyntää kyselyrajapintaa tuotteiden lataamiseen. Kyselyrajapinnan käyttö edellyttää kuitenkin teknistä osaamista, joka saattaa koitua esteeksi tuotteiden käyttöönotolle. Online-viittauksia kyselyrajapintojen ohjeistuksiin ei metatietokuvailuissa tällä hetkellä ole. Metatietokuvailusta löytyy resurssista vastaavan tahon sähköpostiosoite, josta kehittäjä voi tiedustella lisätietoja avoinna oleviin kysymyksiinsä. Hakutulokset ovat myös riippuvaisia hakukenttään syötetystä sanamuodosta ja kirjainkoosta. Paikkatietohakemistossa tiedontuottaja yksilöi tuotteet Inspire-ID:llä, joka tällä hetkellä ainoa tuotekohtainen yksilöivä tunnus. Tuotteet sisältävät tiedontuottajan käsin ylläpitämiä kohdekohtaisia yksilöiviä tunnisteita ja tietojärjestelmien hallitsemia järjestelmien sisäisiä yksilöiviä tunnisteita. Käsin ylläpidettävät kohdekohtaiset tunnisteet käsittävät inhimillisen virheen mahdollisuuden, ja ovatkin näin riski pysyvyyden ja elinkaarisääntöjen hallinnoinnin näkökulmasta. Tietojärjestelmien kohdalla tulee kuitenkin huomata tunnistemekanismien tuottamien avaimien olevan vain tietojärjestelmien sisäiseen toimintaan tarkoitettuja avaimia. Vain ihminen voi hallita reaalimaailman kohteiden elinkaarisääntöjä ja ylläpitää näitä reaalimaailman avaimia tietojärjestelmissä. 1/6

2 Tampereen kaupungilla on tarve lähteä kuvailemaan luokiteltuja yhteiskäyttöön soveltuvia paikkatietoaineistoja paikkatietohakemistoon, jolloin ylläpidonprosessissa tulisi tiedontuottajan pystyä liittämään tuotteita ja palveluita paikkatiedon ontologiaan URI -mekanismiin perustuen. Lisäksi paikkatietohakemistossa tulisi pystyä hakemaan tietotuotteiden ja palveluiden metatietokuvauksia lisenssin perusteella (avoimen datan / palvelun lisenssi), joka edellyttäisi, että tuotteet ja palvelut pystyttäisiin lisensoimaan koneluettavasti. Näin ollen paikkatiedon lisenssipalvelun (attribute provider) kytkeminen tuotteiden ja palveluiden metatietoihin olisi tärkeää. Näillä hakuyhdisteillä mahdollistettaisiin kansallisesti tehokas avoimen paikkatiedon löytäminen metatietoihin ja ontologiaan perustuen. 1.3 Avoimien paikkatietotuotteiden hakeminen Tampereen avoimen datan datakatalogista Kehittäjä menee osoitteeseen Avoimien tietotuotteiden haku aloitetaan kirjoittamalla hakukenttään haettavan tuotteen nimi tai avainsana. Vaihtoehtoisesti aineistoja voidaan selailla Seuraava -painikkeella sivun alalaidasta. Palvelu listaa hakutuloksia, jotka sisältävät tuotteen nimen, kuvauksen sekä latauslinkin, josta tuote voidaan ladata SHAPE-ZIP -formaatissa. Tuotteen nimeä klikkaamalla voidaan katsella tarkempia tuotteen metatietoja. Metatiedot sisältävät linkkejä tuotteen lataamiseksi myös muissa kyselypalvelun tarjoamissa formaateissa: JSON, GML2, GML32 ja CSV. Kehittäjä lataa aineiston joko kertairroituksella tai käyttää kyselyrajapintaa oman sovelluksensa tietolähteenä online-kyselyperiaatteella. Kyselyrajapinnan käyttö edellyttää kuitenkin teknistä osaamista, joka saattaa koitua esteeksi tuotteiden käyttöönotolle. Metatietokuvailuista löytyy online-viittaus kyselyrajapintojen ohjeistuksiin. Metatietokuvailusta löytyy resurssista vastaavan tahon sähköpostiosoite, josta kehittäjä voi tiedustella lisätietoja avoinna oleviin kysymyksiinsä. Sidoshankkeina tuleva kansallinen avoimen datakatalogin hanke /VM. 1.4 Avoimen datan kehittäjän tietoarkkitehtuurinäkökulma Tietotuotteiden metatietokuvailut ja tietotuoteselosteet tärkeitä soveltuvuuden arvioinnissa Vaihtoehtoisesti tuotteiden attribuuttikohtaiset metatiedot selkeä ja nopea tapa ymmärtää tuotteen sisältöä Tietotuotteissa tulee olla pakollisena tiedontuottajan hallitsema kohdekohtainen pysyvä GML - featureid (fid). Fid toimii yhdistävänä tekijänä tiedontuottajan ja avoimen datan kehittäjän välillä kohteen elinkaaren hallinnassa. JSON tällä hetkellä suosituin formaatti tuotteiden latauksessa 1.5 Vaiheet T2 T3 Avoimen datan kehittäjälle tulee tarve saada osaksi uutta palveluaan Tampereen pyöräilyverkostoaineistoa. Kehittäjä tekee vapaan tekstihaun paikkatietohakemisto.fi -palvelussa, ja löytää hakua vastaavan aineiston metatiedot. Metatiedoista selviää, että aineisto on Tampereen pyörätiet tietotuote, joka lisensoitu avoimen datan lisenssillä. Metatiedoista selviää myös fyysinen rajapintaosoite tuotteen käyttöönottoon. Kehittäjää kiinnostaa myös mitä muita tuotteita olisi saatavilla kevyenliikenteenväyliin liittyen. Käyttäjä tekee ontologiaperusteisen haun jossa käyttää kevyenliikenteenväylä ontologiaa. Käyttäjä löytää myös liikennevalolaitteet, liikennevalo-ohjatut liittymät ja liikennevaloilmaisimet tietotuotteet. 2/6

3 T4 Kehittäjä lataa kyselypalvelurajapinnan (WFS) kautta tietotuotteet omaan tietokantaansa. Jatkossa kehittäjä päivittää tiedontuottajan tietotuotteissa tapahtuneet muutokset pysyvän ID:n perusteella ajastetusti. Tietojärjestelmäriippumaton pysyvä ID on näin ollen pakollinen, jotta muutoksia voidaan hallita tietojärjestelmien välillä (kts. huomioita seuraavalla sivulla) Ontologiapalvelun käsitteet on linkitetty tiedontuottajan toimesta tuotteille paikkatietohakemistossa Tiedontuottaja hallitsee tuotteiden ja palveluiden käyttöoikeuksia lisenssipalvelussa, jotka linkitetty paikkatietohakemiston tuotteiden ja palveluiden metatietoihin. Replikointi vaatii lisäksi ominaisuuden tuotteeseen (esim. pvm-tietoja), jonka perusteella voidaan muuttuneet kohteet tunnistaa, jollei tehdä koko datamassan uudelleen latausta. Koko datamassan lataus saattaa kuitenkin olla yksinkertaisin ja järkevin tapa tehdä muuttuneiden kohteiden päivitys. 3/6

4 2 Tietojärjestelmien väliset yhteydet Paikkatietokohteeseen esim. mineraaliesiintymään liittyy muutakin kuin tietokantaan tallennettua dataa esim. kuvia, raportteja, skannattuja karttoja tai muuta täydentävää materiaalia, joka on tallennettu hakemistoon. Liitemateriaali halutaan linkittää paikkatietokohteeseen niin, että linkki on tallennettu tietokantaan. Samaa liitemateriaalia voidaan hyödyntää useissa eri järjestelmissä tai palveluissa. Näihin eri järjestelmiin tai palveluihin tallennetut linkit eivät saa muuttua esim. palvelinten muuttuessa tai hakemistorakenteita uudistettaessa, sillä on hyvin työlästä käydä päivittämässä linkit kaikkiin eri paikkoihin. Jos jokaiselle kuvalle, raportille tms. liitemateriaalille annetaan yksilöivä tunniste, jonka kautta linkitys järjestelmä- ja palvelutasolla hoidetaan, muutostenhallinta on helpompaa. Käyttäjälle asia ei muutoin näy kuin, että hän avaa itseään kiinnostavan liitemateriaalin ja linkki toimii. 2.1 Esimerkki mineraalivaroihin liittyvästä palvelusta Käyttäjä zoomaa kartalla Pohjois-Suomeen ja avaa info-työkalulla XX kaivoksen ominaisuustiedot saadakseen lisätietoja esim. varantoarvioon liittyen. Häntä kiinnostaa myös kaivokseen liittyvää muu materiaali kuten geologiset kartat. Info-työkalussa on attribuuttien lisäksi linkit muuhun materiaaliin. Klikkaamalla geologisen kartan linkkiä, käyttäjälle avautuu alueen yksityiskohtainen geologinen kartta. 2.2 Vaiheet T2 T3 T4 T5 Käyttäjä löytää haluamansa kohteen karttasovelluksen hakutyökaluilla tai liikkumalla kartalla. Käyttäjä ottaa sovelluksen info-työkalun käyttöönsä ja klikkaa hiirellä kohdetta, jonka ominaisuustiedoista on kiinnostunut Sovellus palauttaa käyttäjälle kohteen ominaisuustiedot info-ikkunaan. Näissä tiedoissa on mukana myös linkki liitemateriaaliin Palvelun käyttäjä avaa linkin takana olevan dokumentin (esim. pdf-tiedosto) klikkaamalla linkkiä Palvelimelle tallennettu liitedokumentti avautuu käyttäjälle. 3 Hydrografia teema ja dokumenttien linkittäminen Hydrografia -teemaan liittyvää tietosisältöä ylläpidetään useissa eri organisaatioissa. Maanmittauslaitoksen (MML) Maastotietokanta (MTK) sisältää yksityiskohtaisimman koko maan kattavan kuvauksen vesistöjen fyysisistä ominaispiirteistä. Aineisto kuvaa mm. järvet, lammet, joet, ojat, kosket, padot ja altaat. Pääpaino aineistossa on vesistökohteiden geometrian kuvaamisessa. Suomen Ympäristökeskus (SYKE) puolestaan ylläpitää laajaa aineistokokonaisuutta, joka sisältää runsaasti vesitöihin liittyvää ominaisuustietoa. SYKE käyttää omien aineistojensa lähtötietona MTK:n mukaisia geometrioita. SYKE on muokannut MTK:n aineistoja niin, että vesistöihin liittyvän ominaisuutiedon kohteittainen hallinta on tullut mahdolliseksi. Lisäksi SYKE on muodostanut ehyen vesistöjärjestelmää kuvaavan uomaverkostomallin, jossa mm. järvien kohdalle on lisätty ns. pseudouoma verkoston eheysvaatimuksen takia. Myös Liikennevirasto (LiVi) ylläpitää hydrografiaan liittyviä tietoja, erityisesti vesireitteihin ja - liikenteeseen liittyen. Tietoja siirrettäessä niitä ylläpitävien organisaatioiden ja tietojärjestelmien välillä olisi tarpeen, että vesistökohteita voitaisiin käsitellä pysyviin yksilöllisiin tunnisteisiin perustuvilla mekanismeilla. Tämä on 4/6

5 tarpeen erityisesti kohteiden geometrioihin liittyvän päivitystiedon välittämisessä MML:sta SYKE:en. Kohteittaisen muun ominaisuustiedon siirtäminen SYKE:sta MML:en olisi myös hyödyllistä. Kohteiden tunnisteet olisivat tarpeen erityisesti eri tietolähteitä hyödyntävien älykkäiden käyttösovellusten näkökulmasta. Seuraavassa esimerkki hydrografiaan liittyvästä käyttötapauksesta, jossa tarvitaan tiettyyn maastokohteeseen liittyvää tietoa eri organisaatioista. 3.1 Myrkkypäästön hallinta Käyttäjä haluaa hyödyntää hydrografiatietoja simuloidessaan merkittävän, vesistön varrella sijaitsevan tehtaan ihmiselle haitallisen päästön vaikutusta tai yrittäessään reagoida jo tapahtuneeseen päästöön. Tärkeitä lähtötietoja ovat mm: vesialueet ja niiden syvyystiedot, vesiuomat ja näiden virtaamat, satamapaikat, uimapaikat, olemassaolevat veneilyreitit jne. SYKE:n uomaverkosto virtaamatietoineen muodostaa lähtökohdan päästön leviämisen mallintamiselle. Uomiin liittyvät, fyysistä ympäristöä kuvaavat kohteet geometrioineen puolestaan määrittävät päästön vaikutusalueen tarkemmin. Merkittävyys evakuoinnin kannalta korostuu veneily- ja uimapaikkojen kohdalla. Tehtävän onnistuu, koska käyttäjä pystyy linkittämään relevantit SYKE:n uomat tunnistepohjaisesti MML:n ajantasaiseen tietoon vesialueiden ulottuvuuksista. Tieto veden lämpötilasta saadaan liitettyä mukaan analyysiin SYKE:n havaintoverkostosta vesistökohteiden tunnisteiden avulla. Lisäksi tarvitaan veneilyreittien ja uimapaikkojen kytkemistä näihin vesistökohteisiin, mikä onnistuu luotettavimmin tunnuspohjaisesti. 3.2 Vaiheet T2 T3 T4 T5 Käyttäjä (myrkkypäästöön liittyvää evakuointisuunnitelmaa tekevä pelastuslaitoksen operaatiovastaava) paikallistaa päästökohdan karttapohjaisessa sovelluksessa. Kohtaan liittyvien hydrografisten kohteiden (järvet, joet jne.) URI-muotoiset tietokohdetunnisteet haetaan spatiaalista rajausta käyttäen taustajärjestelmästä. Kriittisimmät kohteet löydetään kulkemalla uomaverkostossa veden virtaamasuuntaan. Käyttäen hyväksi em. tietokohteita vastaavan reaalimaailman kohteen kohdetunnistetta, käyttäjä käynnistää haun, joka palauttaa kunkin kohteen osalta päävastuullisen organisaation resoluutiopalvelusta ao. reaalimaailman kohteeseen liittyvät kaikki tiedossa olevat paikkatietokohteiden tunnisteet. Palautuvien tunnisteiden joukosta käyttäjä poimii käsillä olevan tehtävän kannalta relevantit kohteet, kuten uimapaikat ja venesatamat. Käyttäen löydettyjen yksittäisten paikkatietokohteiden tunnisteita käyttäjä käynnistää haun, joka tuo sovellukseen näiden kohteiden yksityiskohtaiset tiedot. Kohdetiedoista selviää mm. uimapaikoista ja satamista vastuullisten tahojen tiedot ja käyttäjä voi näin tehdä tarvittavat hälytykset. Huom! T2 edellyttää, että reaalimaailman kohteen tunniste on löydettävissä kustakin ao. kohteeseen liittyvästä tietokohteesta. 5/6

6 4 Tietoresurssien yhteiskäyttö Tampereen kaupungin käyttäjä haluaa siirtää operatiivisesta pysäkkijärjestelmästään (Winbus) tietoja Digiroad2-järjestelmään. 4.1 Vaiheet Tampereen pysäkkitietoja ylläpidetään Winbus-järjestelmässä (SQL-server) T2 Tampereen ETL-prosessi 1 krt/ 24h: 1. Lukee Winbus -järjestelmän tietoja SQL-server kannasta 2. Muuntaa ne DR2 skeeman mukaiseksi 3. Tekee koordinaatiston muunnoksen ETRS-GK24 järjestelmään 4. Kopio muunnetun datan Oracle-palvelimelle T3. Oracle taulu on liitetty jaeltavaksi WFS-rajapinnalle Oracle (DR2) skeeman mukaisesti T4. Käyttäjä pyytää uudet ja muuttuneet tiedot Digiroad2-järjestelmään WFS-rajapinnalta. Pysäkkien tunnistaminen perustuu lähdejärjestelmän yksilöivään tunnisteeseen TRE+ADMIN_STOP-ID (lähdejärjestelmän tunnus). DR2-järjestelmä antaa kohteille yksilöivän STOP_ID (valtakunnallinen tunnus, joka on InspireID). Muutokset tallentuvat DR2-kantaan. Hyödyntäjät käyttävät DR2 järjestelmää primaarijärjestelmänä tarkoituksen mukaisesti, ei tiedontuottajan lähdejärjestelmää. 6/6