Maastotietokannan shapefile-jakelua ei ole ihan helppo ottaa käyttöön yhtenä kokonaisuutena. Jotta kaikkien ei tarvitsisi tehdä samoja virheitä niin olisi hyvä koota ohjeita ja niksejä työn tekemiseksi oikein ja tehokkaasti. Merkistöjen käsittelystä olikin jo aikaisemmin hyvää kirjoittelua. Itse olen ehtinyt tehdä pari juttua:
Testasin K2-testiaineistolla komentojonoja, joilla saadaan puretuksi yhdellä kertaa kaikki zipit yhteen yhteiseen hakemistoon niin, että jokainen shapefile saa ikioman nimen josta selviää sen ikioma karttalehti. Minun mielestäni lopputulos on parempi noin kuin alkuperäinen kaikki-shapet-ovat-xxxxxx-shapeja -nimeämissysteemi. Kuvitettu ohje http://latuviitta.org/documents/Maastotietokannan_shape_zippien_tehokas_purkaminen_ja_haltuunotto.pdf
Komentojonot on tehty Windowsille, olisi kiva jos joku ensinkin testaisi toimivatko ne myös koko maan aineistolla, ja toisaalta tekisi niistä Linuxilla toimivat versiot.
Olisi hyvä koota infoa vaikka jollekin wikisivulle - mikähän olisi sopiva paikka, ehkä OSM-wikistä jokin sopiva sivu? (vaikka kaikin osin ei suoraan OSM:ään liitykään MML-aineistojen hyödyntäminen)
Kaikkia maastotietokannan tiedostoja ei minusta kannata purkaa ja nimetä uudelleen yhteen ja samaan hakemistoon. Tiedostoja on kuitenkin yhteensä 272640+3 kpl, mikä voi aiheuttaa vaikeuksia hakemiston käytössä. Kuitenkin on fiksua nimetä ne hakemistoissaan uudestaan.
Kaikki .prj-tiedostot lienevät identtisiä. Jos ne poistaa, tiedostomäärästä lähtee neljäsosa pois (jää 204480+3). Tällöin pitää jollain tavalla ilmoittaa sovellukselle käytettävä koordinaattijärjestelmä/projektio (SRS tai CRS); mtk:n SRS on “ETRS89 / ETRS-TM35FIN” eli koodina “EPSG:3067” (ja sen jokin ID on 1030). Esimerkiksi GDALiin sisältyvällä ogr2ogr-komentoriviohjelmalla pitää käyttää komento-optiota -s_srs EPSG:3067 ja QGisissä pitää varmistaa tason tuomisen jälkeen, että SRS on oikein (klikkaa oikealla tasoa, valitse “Set layer CRS”.
Nyttemmin testaan myös skriptiä, joka muuntaa mtk:n tekstit suoraan dbf:issä UTF-8:ksi.
Yhden hakemiston käyttämisen järkevyys riippuu vähän siitä, mihin aikoo käyttää purettuja shapefilejä. Minä tiedän jo etukäteen käyttäväni niitä vain pariin tarkoitukseen:
Välivaiheena PostGIS:iin ja Spatialiteen viemisessä. Tähän väliaikatietona yksi standardiaika, heikolla Windows-kannettavalla kesti 32 minuuttia viedä tiestö osoitteilla Spatialiteen, ja nyt minulla on tiestö yhtenä tiedostona. Tarkoitus on myös laittaa tuo aineisto ensimmäiseksi saataville WFS-palvelusta, mutta siihen kyllä menee aikaa, koska minulla on niin hidas linja kotoa vuokrapalvelimelle, ja jotkin ihme torrentit vielä varaavat siitä suurimman osan.
Mapserverin lähtöaineistona, jota luetaan ogrtileindex-systeemin kautta.
Kummatkaan noista tarpeista eivät vaadi, että tiedostot olisivat yhdessä hakemistossa, mutta ei niille ole siitä mitään haittaakaan.
Näihin tarkoituksiin minua miellyttää pitää kaikki shapet yhdessä hakemistossa. Mutta jos haluaisin avata shapen silloin ja toisen tällöin johonkin GIS-ohjelmaan, niin jättihakemiston lukeminen todellakin olisi epäkäytännöllisen hidasta.
Toivottavasti kaikki tietävät, että vasta GDAL 1.9.0 käyttää oikeita parametreja tuolla s_srs EPSG:3067 -systeemillä. Vanhemmilla se johtaa muunnosvirheeseen jos siirrytään esimerkiksi KKJ-systeemiin tai WGS84-koordinaatteihin. Aiheesta tekstiä täällä http://latuviitta.org/documents/YKJ-TM35FIN_muunnos_ogr2ogr_cs2cs.txt
Ai niin, QGis ei käytä GDAL 1.9 -versiota (en ole varma uusimmasta kehitysversiosta). Älkää tehkö summamutikassa projektiomuunnoksia sillä.
QGis pystyy muuten käyttämään mainiosti koko peruskarttarasteriaineistoa yhtenä ainoana maanlaajuisena tasona kunhan purkaa kaikki tiffit ensin yhteen hakemistoon ja tekee niistä sitten GDAL:in VRT-virtuaaliaineiston, joka on sisimmiltään XML-tiedosto jossa on linkit alkuperäisiin tiedostoihin. Avaaminen tosin on aika hidasta, kymmenenkään minuuttia ei ehkä riitä, mutta kun se on auki, niin kartalla liikkuminen on täysin normaalin nopeaa. Sitten vaan GPS kiinni koneeseen ja QGis on valmis “moving map” ohjelma. Näistä on tulossa ohjeita ja tehokkuusmittauksia ennemmin tai myöhemmin.
OSM:in kannalta tuota ohjetta kannattaa lukea silläkin mielellä, että VRT-virtuaalitasoa voidaan käyttää lähtötasona kaikille GDAL-ohjelmille, myös gdal2tiles-laattaleikkurille ja siitä jalostetulle MapTiler-ohjelmalle. Niiden käyttö on suoraviivaisin tapa pilkkoa hieno aineisto Web Mercartor -projektiossa oleviksi 256x256 pikselin palasiksi. Pikku ongelma on siinä, että tulos käyttää laatoille OSGeo:n TMS-standardin nimeämistä kun taas OSM-ohjelmat eivät taida tukea muuta kuin Googlen nimeämistapaa. TMS-nimien muuntamiseksi Google-nimiksi on kuitenkin olemassa valmiita ratkaisuja. Lisää tietoa ohjelmista http://www.gdal.org/gdal2tiles.html ja http://www.maptiler.org/
ja tekee niistä sitten GDAL:in VRT-virtuaaliaineiston, joka on sisimmiltään XML-tiedosto jossa on linkit alkuperäisiin tiedostoihin. Avaaminen tosin on aika hidasta, kymmenenkään minuuttia ei ehkä riitä, mutta kun se on auki, niin kartalla liikkuminen on täysin normaalin nopeaa. Sitten vaan GPS kiinni koneeseen ja QGis on valmis “moving map” ohjelma. Näistä on tulossa ohjeita ja tehokkuusmittauksia ennemmin tai myöhemmin.