Ogr2osm.py osaa ottaa lähtöaineistoksi vain kokonaisen OGR-tietolähteen, mutta ei yksittäistä OGR-karttatasoa. MTK-GML:ssä on kuitenkin mukana kymmeniä karttatasoja, joista valtaosaa ei varmasti haluta muuntaa OSM-muotoon. Tästä syystä olisi kiva pystyä poimimaan maastotietokannan XML-tiedostoista vain halutut tasot.
Yksi vaihtoehto olisi muokata ogr2osm.py skriptiä. Muokattava kohta olisi noin riviltä 317 alkaen, kohdassa, jossa nyt luetaan tietolähteen nimi ja etsitään kaikki siitä löytyvät tasot ja tehdään jatkotoimenpiteet niille kaikille. Tässä varmaankin voisi käyttää GetLayerByName-menetelmää ja poimia tason nimi komentorivillä annetusta parametristä http://gdal.org/python/osgeo.ogr.DataSource-class.html.
Yksinkertaisempaa, erityisesti jos ei osaa ohjelmoida, on kuitenkin käyttää OGR-virtuaalitiedostosysteemiä ja tehdä uusi OGR-tietolähde, jossa ei ole mukana kuin vain ne halutut karttatasot. Se käy näin:
Kirjoitetaan OGR-VRT-määrittelytiedosto, esimerkiksi “karsittu.xml”
SrcDataSource on lähtötiedoston nimi ja polku SrcLayer on edellisestä löytyvän karttatason nimi; nimen voi löytää ogrinfo-työkalulla “ogrinfo M5222R.xml” OGRVRTLayer name on se nimi, jolla taso näkyy kun tätä uutta virtuaaliaineistoa käytetään. Tason nimeä ei kannata muuttaa muuksi kuin mitä MTK-XML:ssä käytetään, koska sitten keimon ogr2osm:ia varten tekemät mappaukset eivät enää toimisi.
Testataan virtuaalinen karsittu.xml-tiedosto käyttämällä ogrinfo:a
C:\temp>ogrinfo -ro karsittu.xml
INFO: Open of `karsittu.xml'
using driver `VRT' successful.
1: Jarvi (3D Polygon)
Hyvältä näyttää, joten nyt voidaan muuntaa alkuperäisestä MTK-GML-tiedostosta pelkät järvet OSM-muotoon komennolla
Erinomainen vinkki. Virtuaalitasoilla voi tosiaan pienentää importoinnissa tarvittavan skriptauksen ja säätämisen määrää huomattavasti.
Tason nimellä ei muuten MTK-datan ogr2osm importissa pitäisi olla väliä. Tagimappaukset tehdään featuren kohdeluokka-numeron mukaan, ei layerin nimellä.
Samaa teemaa jatkaen, virtuaalitasoilla voidaan myös yhdistää useampi tiedosto yhteen käyttämällä OGRVRTUnionLayer:iä.
OGR:n vsizip ajuria käyttämällä ei myöskään kapsista (tms.) imuroituja zip-tiedostoja tarvitse edes purkaa ennen importtia, kunhan zip-tiedoston nimeen lisätään ‘/vsizip/’ alkuun. Tähän tapaan:
Eikä tässä vielä kaikki, sillä zippejä ei tarvitse edes imuroida, jos lisää OGR-tietolähteen nimeen vielä /vsicurl/.
Tässä ogrinfo-testikomento, jonka pitäisi listata näytölle yhden karttalehden järvet suoraan kapsin palvelimella makaavasta zipistä. Komento voi olla joskus kätevä, sillä zippi todellakin avataan siellä kapsin päässä ja sieltä lähetetään vain murto-osa koko MTK_GML-paketin biteistä.
kokeilin ja näyttäisi toimivan. Jos joku haluaa kokeilla tätä Windows:ssa, uusimman kehitysversion voi ladata itselleen osoitteesta (kuten JRA jossain mainostitkin) http://www.gisinternals.com/sdk/, josta sivun ylhäältä löytyy “development” versioita. Itse valitsin niistä “release-1600-x64-gdal-mapserver” (itsellä 64bit windows) ja sieltä asensin “gdal-110-1600-x64-core.msi” (generic core) ja “GDAL-1.10.0.win-amd64-py3.2.msi” (Installer for the GDAL python bindings, itsellä Python 3.2).
Edeltä kannattaa huomata se, että uusi GDAL asentuu vanhan päälle, jos sellainen koneella on.
En vaan oikein usko tuota väittämää “zippi todellakin avataan siellä kapsin päässä”. Jos niin tehtäisiin, Kapsin http-palvelimen pitäisi tietää, että niin halutaan tehdä, eikä vaan lähettää zip-tiedosto asiakkaalle (joka on edellisessä tapauksessa ‘ogrinfo’. Jotta niin tapahtuisi, pitäisi jonkilaista makiikkaa olla sekä client- että server-päässä. Tuo “makiikka” voisi olla jonkinlainen zip-laajennos.
Jos tavalliselta http-palvelimelta pyytää zip-tiedostoa, niin zip-tiedostohan sieltä tulee. Enkä tiedä mitään, vaikkapa Apachen laajennosta, joka, jos zip-tiedoston nimen perään laittaa zipissä olevan tiedoston, lähettää vain kyseisen tiedoston.
Kyllähän se uskomattomalta tuntuu, mutta siitä huolimatta on totta. Olen testannut tuota käyttämällä Fiddler 2 -ohjelmaa paikallisena välityspalvelimena ja katsomalla lokitiedoista kuinka paljon dataa liikkuu, eikä haluttujen tiedostojen lisäksi ylimääräisiä bittejä kovin paljon tarvita.
Kokeile lukea pelkkä tasoluettelo, ei todellakaan tule koko zippitiedosto koneellesi tuossa ajassa
Zip-tiedostossahan on tiedostoluettelo yhdessä pötkössä, muistaakseni tiedoston lopussa. Siihen saattaa olla viittaus tiedoston alussa.
Voisin kuvitella osittaisen latauksen toimivan niin, että ensin haetaan HTTP Range -pyynnöllä zip-tiedoston alusta ja lopusta sen verran tavaraa, että voidaan lukea tiedostoluettelo, josta selviää, minkä tavun kohdalta mikäkin zip-tiedoston sisällä oleva tiedosto alkaa ja mihin se loppuu. Sitten vain haetaan tarvittavat pätkät uusilla HTTP Range -pyynnöillä. Koska samalla TCP/IP-yhteydellä voi nykyään esittää monta HTTP-pyyntöä, yksittäisten pätkien lataamisen pitäisi käydä nopeasti.
Sama asia vähän toisinpäin on Debianin jigdo-työkalu, joka muodostaa iso-imagen yksittäisistä verkosta ladatuista tiedostoista.
Olet tässä kyllä oikeassa. Itse asiassa GDAL pystyy pyytämään tietyn tiedoston zipin sisältä jos se saa zipin hakemiston avulla selville tarvittavan “range”:n. MTK-GML-zipeissä on vain yksi tiedosto joten GDAL joutuu hakemaan koko zipin. Tämä näyttää tapahtuvan useassa palassa rangea liu’uttamalla, mikä ilmeisesti auttaa GDAL:ia säästämään muistia. GML:stä ei muutenkaan ole mahdollista tietää, mille alueella tiedostoa joku tietty taso on tallennettuna, joten se on joka tapauksessa aina pakko lukea kokonaan. Testasin /vsizip/vsicurl:ia aikoinaan MTK:n shapefile-zipeillä, joissa tasot olivat jokainen omassa shapefilessä, ja muistelin noita kokemuksia. Hieno systeemi joka tapauksessa.
Millä sovelluksella voisi visuaalisesti verrata ogr2osm.py:n tuottamaa .osm -tiedostoa OpenStreetMapin tietoihin? Kokelin JOSM:lla: avasin sillä yhdestä karttalehdestä tekemäni .osm -tiedoston ja sen jälkeen hain OSM-tiedot jonkin verran karttalehteä pienemmältä alueelta. Ongelmana on se, että näistä kahdesta ei tule erillistä “layer”:ia vaan menevät samaan, eli en voi muuttaa esim. kuvaustekniikkaa tai laittaa välillä toista pimeäksi.