Päivitetty 17. heinäkuuta 2013
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.
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-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)
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
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".
================================= 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.