Maanmittauslaitoksen maastotietokannan GML-tiedostomuodon haltuunotto

Päivitetty 17. heinäkuuta 2013

Maastotietokanta ja sen virallinen GML-tiedostomuoto - ei amatööreille eikä köyhille

Maanmittauslaitoksen maastotietokanta on saatavilla GML-muodossa.  Tuntuu hyvältä, koska GML kuulostaa yleiseltä tiedostomuodolta paikkatietojen välittämiseen.  Ikävä kyllä maastotietokannan skeema on sellainen, ettei juuri mikään ohjelma maailmassa osaa avata sitä ja muuntaa tietoja esimerkiksi PostGIS-tietokantaan tai shapefile-muotoon yksinkertaisesti antamalla komento "Avaa ja muunna".  Verkosta läytyy kyllä muutama linkki MTK-GML:n avaamisesta ja käsittelystä.  Eräs niistä kertoo, että FME-ohjelmistoon on lisätty MTK-GML-tuki keväällä 2013, ja eräs toinen osoittaa, että se joka osaa ohjelmoida, voi muuntaa kohteita maastotietokannan GML:stä esimerkiksi PostGIS:iin.

http://gissiajapaikkatietoa.wordpress.com/2013/03/
https://blogs.aalto.fi/jreini/

Ne, jotka eivät osaa ohjelmoida ja joilla ei ole rahaa tai halua hankkia FME-lisenssiä on ilmeisesti jätetty oman onnensa nojaan.

MTK-GML-tuki GDAL:ssa - myös amatööreille ja köyhille

GDAL-developer-postituslistalla 28. toukokuuta alkaneen keskustelun http://thread.gmane.org/gmane.comp.gis.gdal.devel/34871 innoittamana Latuviitta.org päätti antaa suomalaisille paikkatiedon harrastajille kesälomalahjan ja tilasi ja maksoi kehitystyön, jolla lisättiin GDAL/OGR-kirjastoon tuki maastotietokannan GML-muodon lukemiseksi.  Kiitokset inspiraatiosta kuuluvat siis aakkosjärjestyksessä Ari Jolmalle, Lauri Kajanille ja Pekka Sarkolalle.

Ensimmäinen yhteydenotto kehittäjään tapahtui 1. heinäkuuta 2013 ja kahden päivän kuluttua tästä Even Rouault oli analysoinut lähtöaineiston ja teki ehdotuksen toteutustavasta.  Tarjous hyväksyttiin, ja heinäkuun 6. päivä työ oli valmis.  MTK-GML-tuki on nyt kenen tahansa käytettävissä, kunhan lataa GDAL:in kehitysversion (r26140 tai suurempi).  Muutokset, jotka GDAL:in GML-ajuriin tehtiin, löytyvät tästä muutossarjasta
http://trac.osgeo.org/gdal/changeset/26140

MTK-GML:n lukeminen GDAL:lla

MTK-GML-tiedostomuodon tuki sisältyy nyt automaattisesti GML-ajurin ominaisuuksiin, joten esimerkiksi orginfo- ja ogr2ogr-ohjelmia voidaan käyttää maastotietokannan GML-muodon lukemiseen aivan samoin, kuin niitä muutenkin käytetään.  Tässä esimerkiksi ogrinfo yhden karttalehden GML-tiedostosta, josta löytyy kaikkiaan 60 eri karttatason kohteita.

C:\temp\mtk-gml>ogrinfo P5411L.xml
Had to open data source read-only.
INFO: Open of `P5411L.xml'
      using driver `GML' successful.
1: HarvaLouhikko (3D Point)
2: Hietikko (3D Polygon)
3: Jyrkanne (3D Line String)
4: KallioAlue (3D Polygon)
5: KallioSymboli (3D Point)
6: Kivi (3D Point)
7: Kivikko (3D Polygon)
8: Louhos (3D Polygon)
9: Luiska (3D Line String)
10: Lahde (3D Point)
11: MaaAineksenottoalue (3D Polygon)
12: MaastokuvionReuna (3D Line String)
13: Maatalousmaa (3D Polygon)
14: MetsamaanKasvillisuus (3D Point)
15: Niitty (3D Polygon)
16: Pato (3D Line String)
17: Soistuma (3D Polygon)
18: Suo (3D Polygon)
19: UrheiluJaVirkistysalue (3D Polygon)
20: Vesikuoppa (3D Point)
21: Jarvi (3D Polygon)
22: VedenpinnanKorkeusluku (Point)
23: VirtavesiKapea (3D Line String)
24: VirtavesiAlue (3D Polygon)
25: Virtausnuoli (3D Point)
26: Muuntaja (3D Point)
27: Sahkolinja (3D Line String)
28: SahkolinjanSymboli (3D Point)
29: Rakennus (3D Polygon)
30: Rakennusreunaviiva (3D Line String)
31: Allas (3D Polygon)
32: Nakotorni (3D Point)
33: PistolaituriViiva (3D Line String)
34: Tulentekopaikka (3D Point)
35: Maasto2kuvionReuna (3D Line String)
36: Kaislikko (3D Point)
37: MaatuvaVesialue (3D Polygon)
38: MuuAvoinAlue (3D Polygon)
39: Varastoalue (3D Polygon)
40: Vesikivi (3D Point)
41: Vesikivikko (3D Polygon)
42: Korkeuspiste (Point)
43: Syvyyspiste (Point)
44: Korkeuskayra (3D Line String)
45: KorkeuskayranKorkeusarvo (Point)
46: Syvyyskayra (3D Line String)
47: SyvyyskayranSyvyysarvo (Point)
48: Viettoviiva (3D Point)
49: Tieviiva (3D Line String)
50: Tienroteksti (Point)
51: Tiesymboli (3D Point)
52: Luonnonsuojelualue (3D Polygon)
53: SuojelualueenReunaviiva (3D Line String)
54: Kolmiopiste (Point)
55: Korkeuskiintopiste (Point)
56: Karttasymboli (3D Point)
57: Paikannimi (Point)
58: Selite (Point)
59: Kunta (3D Polygon)
60: Osoitepiste (Point)

Mikä siinä muka oli niin vaikeaa?

Vaikeutena on se, että MTK-GML esittää esimerkiksi yhden harvan louhikon tiedot näin:

<HarvaLouhikko gid="172274894" dimension="3">
            <sijaintitarkkuus>30000</sijaintitarkkuus>
            <korkeustarkkuus>100001</korkeustarkkuus>
            <aineistolahde>1</aineistolahde>
            <alkupvm>2003-10-10</alkupvm>
            <suunta>0</suunta>
            <sijainti>
                <Piste>
                    <gml:pos srsDimension="3">602613.370 7007870.869 235.145</gml:pos>
                </Piste>
            </sijainti>
            <kohderyhma>13</kohderyhma>
            <kohdeluokka>34200</kohdeluokka>
</HarvaLouhikko>

Vakio-ohjelmistot eivät ymmärrä, mitä merkitsee esimerkikfi "HarvaLouhikko", "sijainti" ja "Piste.  Sen sijaan vakio-ohjelmistot kyllä ymmärtäisivät mistä on kyse, jos sama asia olisi esitetty jotenkin tähän tapaan:

<ogr:featureMember>
    <ogr:HarvaLouhikko gml:id="HarvaLouhikko.0">
      <ogr:geometryProperty>
      <gml:Point srsName="urn:ogc:def:crs:EPSG::3067"><gml:pos>602613.37 7007870.869 235.145</gml:pos></gml:Point>
      </ogr:geometryProperty>
      <ogr:gid>172274894</ogr:gid>
      <ogr:sijaintitarkkuus>30000</ogr:sijaintitarkkuus>
      <ogr:korkeustarkkuus>100001</ogr:korkeustarkkuus>
      <ogr:aineistolahde>1</ogr:aineistolahde>
      <ogr:alkupvm>2003-10-10</ogr:alkupvm>
      <ogr:suunta>0</ogr:suunta>
      <ogr:kohderyhma>13</ogr:kohderyhma>
      <ogr:kohdeluokka>34200</ogr:kohdeluokka>
    </ogr:HarvaLouhikko>
  </ogr:featureMember>

MTK-GML:ssä ei ole mitään periaatteellista vikaa vaan se on täysin kelvollista XML:ää, ja kaikkien elementtien merkitykset kyllä selviävät, kunhan selvittää ne Maanmittauslaitoksen skeemoista.  Käytännön ongelmat johtuvat siitä, että vakio-ohjelmistot eivät tahdo kyetä selvittämään mutkikkaita skeemaviittauksia.  Jos uteliaisuutta riittää, niin voitte itse yrittää selvittää skeemojen avulla mitä merkitsee "Piste".  Lähtökohtana on tämä skeema:
http://xml.nls.fi/XML/Schema/Maastotietojarjestelma/MTK/201202/Maastotiedot.xsd

Huomautuksia muutamista MTK-GML-tiedostomuodon erikoisuuksista

Alla olevasta Even Rouaultin analyysistä selviää, että MTK-GML:ssä on eräitä piirteitä, joita GDAL/OGR:n sisäinen tietomalli ei täysin tue.  Näihin kuuluu muun muassa se, että MTK-GML:ssä maastotietokannan kohteilla voi olla useita geometrioita, esimerkiksi sekä piste- että aluemuotoinen geometria.  GML:ssä esiintyy myös sekaisin 2D- ja 3D-geometrioita, mikä estää muuntamisen joihinkin tiedostomuotoihin, ellei kaikkia geometrioita erikseen pakoteta käyttämään samoja ulottuvuuksia käyttämällä "-dim 2" tai "-dim 3" -parametriä.  Lisäksi aineistossa on StringList-tyyppisiä ominaisuustietoja, eli kohteelle saatetaan luotella esimerkiksi useita href-viittauksia.  Useimmat tiedostomuodot eivät tue StringList-tyyppiä, jolloin muunnos on tehtävä käyttämällä "-splitlistfields" -parametria, joka luo uusia ominaisuustietokenttiä tarpeen mukaan, esimerkiksi "vedenpinnanKorkeusluvutViittaus_href1" ja "vedenpinnanKorkeusluvutViittaus_href2".


Määrittely MTK-GML-tuen lisäämiseksi GDAL:iin



================================= OGR read support for Finnish MTKGML Technical and financial proposal ================================= Document reference : ROUAULT-2013-07-RAHKONEN-01-v1 Issue date : 03-July-2013 Proposal -------- To enhance read support in the GML driver of the GDAL/OGR software (http://gdal.org) to read XML files originating from Finnish National Land Survey and published in the MTKGML format. Technical details ----------------- The work covered by this proposal consists : o recognizing the SRS advertized in the "srsName" attribue of the top Maastotiedot element, and attaching it to each OGR layer. In case the attribue is missing, the default value (as advertized by the XML schema) will be EPSG:3067. Note: most files advertize "EPSG:3067, EPSG:5717", i.e. EPSG:3067 as the 2D CRS, plus EPSG:5717 as the "N60 height" vertical datum. OGR has somme support for such compounded SRS, but this is not widely supported, so by default, only the horizontal datum will be reported. This can be altered by setting the GML_REPORT_COMPD_CS configuration option to YES. o recognizing the specific structure of features in MTKGML ( e.g. <autoliikennealueet><Autoliikennealue>...</Autoliikennealue></autoliikennealueet> ) as a valid GML featureMember structure. o exposing the "gid" attribute of features in MTKGML as an OGR field (of type String) o recognizing the <Murtoviiva> element as a <gml:LineString>, recognizing the <Alue> element as a <gml:Polygon>, recognizing the <Piste> element as a <gml:Point> o for <teksti> elements that have a "kieli" attribute, giving the language of the string of the teksti element, an OGR field "teksti_kieli" will be added with the value of the kieli attribute. e.g. : OGRFeature(Paikannimi):0 gid (String) = 324910259 sijaintitarkkuus (Integer) = 0 aineistolahde (Integer) = 1 teksti (String) = Lillträskbacken teksti_kieli (String) = swe suunta (Integer) = 0 dx (Integer) = -115738 dy (Integer) = 8433 kohderyhma (Integer) = 16 kohdeluokka (Integer) = 35040 ladontatunnus (Integer) = 6111 versaalitieto (Integer) = 0 nrKarttanimiId (Integer) = 70702388 alkupvm (String) = (null) POINT (297689.831 7049199.69699999969) Note: other elements have a "kieli" attribute, but the element name contains itself the language. e.g. <nimi_suomi kieli="fin"> will be reported just as a "nimi_suomi" OGR field. o adding a -addmissingfields option of the ogr2ogr utility. The effect of that option is to enhance the capabilities of the existing -append option of the ogr2ogr utility, to be able to merge several mapsheets of MTKGML files into a single datasource (e.g. PostGIS, Spatialite, ...). -append will keep the existing field structure of an existing layer, without adding new fields found in the new source datasource. For example, let's imagine that layer "layerFoo" of out.sqlite has one field "field1". One tries to do : "ogr2ogr -append out.sqlite in.xml" where in.xml has also a "layerFoo", but with 2 fields "field1" and "field2". Currently, -append will not create the "field2" in out.sqlite. -addmissingfields will do it. The rationale for this addition is that some MTKGML mapsheets might not contain some optional attributes in some layers, but other mapsheets will have them. The GML driver will report the field structure based on the inspection of the fields actually found in the XML file (to be opposed to what is declared in the XML schema). Hence the need for -addmissingfields to be able to merge all mapsheets while preserving the union of all fields. o mentionning in the GML driver documentation that MTKGML mapsheets will be recognized by the new GDAL/OGR version. o documenting the -addmissingfields option of the ogr2ogr utility. o enhancing the GDAL/OGR autotest suite (regression tests), to check the non-regression of the above work. Hypothesis and Restrictions --------------------------- - The MTKGML files must conform to the XML schemas available at http://xml.nls.fi/XML/Schema/Maastotietojarjestelma/MTK/201202/ - The GML parser will not use (neither need access) the schemas at http://xml.nls.fi/XML/Schema/Maastotietojarjestelma/MTK/201202/, but it will have a few hard-coded assumptions (described in the "Technical details" section) based on the content of those files. Because the XML schema will not be used, the first time the driver encounters a MTKGML file it will do a first pre-scan to generate a .gfs file with the detected structure of layers and fields (standard behaviour of the GML driver). - Some MTKGML layers have 2 geometries per feature, e.g. <Piste> and <Alue>, or <Piste> and <Murtoviiva>. In such cases, the default behaviour of the GML driver will keep the secondly found geometry, <Alue> and <Murtoviiva> as the geometry to take into account (which makes sense in most situations). This could be altered by hand-editing the generated .gfs file to define a <GeometryElementPath> (as described in the GML driver documentation). - Some MTKGML layer have a mix of 3D and 2D features (typically points) in them. The GML driver will advertize such layers as 3D layers. But when converting to formats that have strict dimension checks (e.g. PostGIS or Spatialite), the conversion will fail when encoutering a 2D only geometry. When converting to such formats, using the "-dim 2" or "-dim 3" option of ogr2ogr might be necessary. Intellectual Property --------------------- All code will be licensed under the existing GDAL X/MIT style open source license.