GML-formaatti

[mikko]

GML on GIS-tiedonsiirtoon tarkoitettu XML-pohjainen formaatti, jota käytetään etenkin WFS-palvelun (viewtopic.php?f=16&t=61) yhteydessä. 3D-Win versiossa 5.5.1 on mukana alustava versio GML-formaatin luvusta. Kirjoitus ei ole vielä toiminnassa. Seuraavassa hieman taustaa ja teknistä tietoa formaatin toiminnasta.

Taustaa

Perus GML-muoto määrittelee vain kohteiden geometrian (pisteet, viivat, kaaret, alueet jne.) eli käytännössä sen päälle pitää muodostaa laajempi määrittely, joka sisältää myös ominaisuustiedot. Tällaisia formaatteja ovat esimerkiksi KuntaGML (http://www.paikkatietopalvelu.fi/gml/) ja Maanmittauslaitoksen kiinteistötietojen kyselypalvelun muoto (http://xml.nls.fi/XML/Schema/sovellus/k ... index.html).

Kunkin formaatin ominaisuustiedot määritellään erillisessä XSD-tiedostossa. Tiedosto on standardi XML schema-tiedosto, joka määrittelee tarkkaan tiedoston tietosisällön ja periytyy pohjana olevan yleisen GML-formaatin schemasta. Jos tätä tiedostoa ei ole saatavilla, voidaan GML-tiedostosta lukea vain geometria. WFS-palvelua käytettäessä XSD-tiedosto ladataan oletuksena automaattisesti datatiedoston kanssa.

XSD-tiedosto voi myös sisältää linkkejä muihin määrittelyihin. Esimerkiksi KuntaGML-formaattia tarjoavan palvelun XSD-tiedosto sisältää seuraavan rivin:

Koodi: Valitse kaikki

<xsd:import namespace="http://www.paikkatietopalvelu.fi/gml/kantakartta" schemaLocation="http://www.paikkatietopalvelu.fi/gml/kantakartta/1.1.0/kantakartta.xsd" />

Seuraavaksi on luettava ja tulkattava tuo KuntaGML:n kantakartta.xsd, josta puolestaan löytyy seuraavia määrittelyjä:

Koodi: Valitse kaikki

<xs:import namespace="http://www.opengis.net/gml" schemaLocation="http://schemas.opengis.net/gml/3.1.1/base/gml.xsd"/>
<xs:include schemaLocation="sahkoverkko.xsd"/>

Ja niin edelleen. Jokainen import- ja include-määrittely on siis luettava ja tulkattava rekursiivisesti. Laajoissa määrittelyissa kuten KuntaGML ja tietysti itse pohjana oleva GML, tulkkaus on aika hidasta ja riippuu tietysti myös käytettävissä olevasta nettiyhteydestä. Noista saadaan kuitenkin luettua lista koodeista (Feature) ja ominaisuustiedoista.

Kohdetyypit ja niiden sisältämät ominaisuudet on myös määritelty periytyvästi. Esimerkiksi KuntaGML-kohdetyyppi rajamerkki periytyy seuraavasti:

Koodi: Valitse kaikki

Rajamerkki
    _Kiinteistoyksikkokohde
        _Kantakarttakohde
            _Kantakohde
                gml:_Feature

Alaviivalla alkavat kohdetyypit ovat abstrakteja eli niitä ei varsinaisessa aineistossa esiinny, vaan ne toimivat rakenteellisena jakona. Kohdetyypillä rajamerkki voi olla ominaisuuksia, jotka on määritelty sille itselle (esim. rajamerkkilaji, numero, rakenne) tai mille tahansa kohdetyypille, josta se periytyy (esim. _Kantakohde: yksilointitieto, sijaintiepavarmuus, luontitapa). Jokaiselle ominaisuudelle on myös määritelty tyyppi (kokonaisluku, liukuluku, päivämäärä, teksti) ja mahdollisesti arvojoukko (minimi, maksimi, lista).

Eli kunhan nuo monimutkaiset XSD-tiedostot purkaa, niin homma on periaatteessa ihan perinteistä GIS-kamaa.

Toteutuksesta

Kun tuo ominaisuuksien tulkkaus XSD-tiedostojen kautta on käytännössä aika hidasta ja joskus jopa mahdotonta, on luku tehty niin, että kerran luetut koodi- ja ominaisuusmäärittelyt voidaan tallettaa tekstitiedostoihin ja lukea ne nopeasti sieltä.

GML-muuntimen asetuksissa on rasti Schema, joka on oletuksena päällä. Tällöin se lukee ja tulkkaa XSD-tiedoston. Tuloksena syntyy käyttäjän asetushakemistoon kaksi tiedostoa: auto_code_tag.txt ja auto_attr_tag.txt. Ensimmäinen sisältää listan koodeista ja toinen ominaisuuksista. Toistaiseksi on jätetty pois ominaisuuksien sitominen yksittäisiin kohdetyyppeihin eli ominaisuuslista sisältää yksinkertaisesti kaikkien kohdetyyppien ominaisuudet. Tulkkauksessa ohitetaan myös itse GML-schema, koska se on laaja ja hidas tulkattava eikä yleensä sisällä olennaisia ominaisuuksia. Koodeissa on mukana myös abstraktit perustyypit. Varsinaisessa datassa niitä ei periaatteessa pitäisi esiintyä, mutta jos jatkossa formaattia kirjoitetaan, niin silloin niille on käyttöä.

Esimerkkinä KuntaGML-palvelun koodilistan alku:

Koodi: Valitse kaikki

http://www.paikkatietopalvelu.fi/gml/asemakaava^AsemakaavaAineisto
http://www.paikkatietopalvelu.fi/gml/asemakaava^KaavamaaraysLinkki
http://www.paikkatietopalvelu.fi/gml/asemakaava^KayttotarkoitusalueLinkki
http://www.paikkatietopalvelu.fi/gml/asemakaava^MaarayskohdeLinkki
http://www.paikkatietopalvelu.fi/gml/asemakaava^_Kaavakohde
http://www.paikkatietopalvelu.fi/gml/kantakartta^Erityiskayttooikeusalue
http://www.paikkatietopalvelu.fi/gml/kantakartta^Erityisrakenne
http://www.paikkatietopalvelu.fi/gml/kantakartta^Hallintoalue
http://www.paikkatietopalvelu.fi/gml/kantakartta^Havupuu
...

Ja ominaisuuslistan alku:

Koodi: Valitse kaikki

http://www.paikkatietopalvelu.fi/gml/asemakaava^AlueSijainti
http://www.paikkatietopalvelu.fi/gml/asemakaava^Label
http://www.paikkatietopalvelu.fi/gml/asemakaava^Siirtyma
http://www.paikkatietopalvelu.fi/gml/asemakaava^Suunta
http://www.paikkatietopalvelu.fi/gml/asemakaava^aineistonnimi
http://www.paikkatietopalvelu.fi/gml/asemakaava^aineistotoimittaja
http://www.paikkatietopalvelu.fi/gml/asemakaava^alue
http://www.paikkatietopalvelu.fi/gml/asemakaava^aluesijainti
http://www.paikkatietopalvelu.fi/gml/asemakaava^arkistotunnus
...

Muutama sana noista ominaisuuksien nimistä. XML-nimiavaruuksien oikeat nimet ovat todella noin pitkiä URL osoitteita. Ne eivät välttämättä osoita mihinkään olemassa olevaan nettisivuun, vaan toimivat vain yksilöivinä määrittelyinä. Itse GML-tiedostossa käytetään lyhyempiä aliaksia. Esimerkiksi määrittely:

Koodi: Valitse kaikki

xmlns:kanta="http://www.paikkatietopalvelu.fi/gml/kantakartta"

Sana kanta toimii aliaksena ja nimi on silloin esimerkiksi kanta:havupuu. Ongelmana tässä on se, että alias on voimassa vain yksittäisessä tiedostossa ja jossain toisessa tiedostossa voi ainakin teoriassa olla käytössä toinen alias. Tämän takia noihin listoihin tallennetaan nimiavaruudeksi aito pitkä nimi. Kun GML-tiedostoa luettaessa tulee vastaan tagi (esim. <kanta:havupuu>) joka löytyy koodilistasta, tallennetaan se kohteen koodiksi ilman nimiavaruutta (havupuu). Vastaavasti ominaisuuslistasta löytyvä tagi talletetaan senhetkisen kohteen ominaisuudeksi.



Kun nuo listat on kerran saatu tulkattua, voidaan ne kopioida toiselle nimelle (esim. kunta_code_tag.txt ja kunta_attr_tag.txt). Sitten tehdään uusi GML- muunnin, laitetaan tiedostojen nimet muuntimen asetuksiin, poistetaan schema-rasti ja annetaan muutimelle nimeksi vaikkapa KuntaGML. Tämän jälkeen voidaan kaikkia KuntaGML-tiedostoja lukea tuolla muuntimella ilman scheman tulkkausta.

Käytännössä siis jokaista eri GML-versiota varten on määriteltävä oma muunnin. Jotta oikea muunnin saadaan käyttöön automaattisesti kullekin WFS-palvelulle, on WFS-asetuksissa formaatin vieressä kenttä, johon voidaan laittaa erillinen tiedostopääte. Tämä pääte lisätään automaattisesti luettuun GML-tiedostoon. Esimerkiksi KuntaGML-muotoa palauttavan palvelun asetuksiin laitetaan päätteeksi kunta, jolloin se tallentaa luetun tiedoston nimellä wfs.gml.kunta. Pääte voidaan sitten laittaa vastaavan muuntimen tiedostopäätteeksi ja lukea tiedosto automaattisesti oikealla muuntimella.

Koordinaattijärjestelmissä on pieni erikoisuus: käytettäessä TM35 tai WGS84 koordinaattijärjestelmiä kaikki palvelut palauttavat koordinaatit järjestyksessä itä-pohjoinen eli muuntimen asetuksissa on oltava päällä käännä XY. Kuitenkin jos maanmittauslaitoksen palvelusta pyytää koordinaatit KKJ-systeemissä, ne tulevat järjestyksessä pohjoinen-itä. Tämän ongelman voi kiertää tuolla tiedostopäätesysteemillä tekemällä maanmittauslaitosta varten kaksi erillistä muunninta ja palvelumäärittelyä eri päätteillä.

[mikko]

Päivitetty ohje löytyy nyt wikistä: http://www.3d-system.net/wiki/index.php ... tojen-luku

Keskustelu ja kysymykset jatkuvat edelleen tässä viestiketjussa.