Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

Se on kyllä selkeää sillä tavalla. Vielä kun olisi käytössä joku user_enhanced=yes, jolla voisi erottaa kohteet, joita käyttäjät ovat myöhemmin parannelleet.

Ilmeisesti MML-lähteestä tuotu aineisto merkitään tuontiajankohdan vuosiluvun mukaan, tyyliin MML, 2012? MML:n ilmakuvissa on laaja vuosilukukirjo, vanhimmat jopa viime vuosituhannelta.

Otin pienen varaslähdön maastotietokannan käytössä ja kokeilin miten teoriassa olisi mahdollista tuoda dataa siitä Openstreetmappiin. PaITuli-paikkatietopalvelussa on ollut kauan saatavilla 2005-2010 maastotietokannat, mutta niiden lisenssi estää niiden käytön OSM:ssä joten en lähettänyt mitään serverille.

Yksinkertaisesti prosessi menee siten että .shp tiedostot ladataan koneelle ja avataan Merkaartor-ohjelmalla, jossa on siihen tiedostomuotoon tuki. Koska en erityisemmin pidä kyseisestä ohjelmasta exporttasin tiedostot osm:n xml muodossa JOSMiin.

Seuraavanlainen tagikenttä tulee esimerkkiviivasta, joka kuvaa varvikkoa:

AINLAHDE= 0
ALUEJAKOON= 0
ATTR1= 0
ATTR2= 0
ATTR3= 0
KARTOGLK= 0
KOHDEOSO= 877271012
KORARV= 0
KORTAR= 0
KULKUTAPA= 0
KUOLHETKI=
LUOKKA= 39120
RYHMA= 70
SIIRT_DX= 0
SIIRT_DY= 0
SUUNTA= 0
SYNTYHETKI=
TASTAR= 10000
TEKSTI=
VERSUH= 0

Tageista mielekkäitä on lähinnä luokka ja ryhmä. Mielestäni tässä vaiheessa kannattaisi luoda eri luokkien vastineet OSM tageissa ja kerätä ne johonkin. Luokkien selitykset löytyvät http://www.maanmittauslaitos.fi/sites/default/files/Maastotietokohteet.pdf kautta.

Oops,

Ei ruveta vielä mitään latailemaan. Meidän pitää ensin hieman miettiä mitä ladataan. Lähtökohtaisesti ajatus on kuvattu tuolla Wiki:ssä: http://wiki.openstreetmap.org/wiki/Fi:Maastotietokanta.

Seuraavat MTK:n kohdeluokat voitaisiin importoida osaksi OSM: rakennukset, liikenneverkot, maankäyttö (pelto, asuinalue), luontokohteet (suot, järvet, joet,yms). MUTTA tärkein asia: ei poisteta mitään OSM:n kohteita, viedään ainoastaan täydentäviä kohteita.

Kun nuo MML:n verkkosivut kaatuvat, niin ei tuo latauspalvelu varmaan ole kovinkaan paljon nopeampi / parempi. Torrent asiasta on keskusteltu jo aiemmin, toisaalla…

Olen samaa mieltä siinä, että jokainen lähetettävä kohde on manuaalisesti tarkastettava olemassaolevan datan alueelta ja poistettava ne tuotavat alueet, jotka ovat jo OSM tietokannassa. Tämä tarkoittaa käytännössä sitä, että massiivinen automatisoitu bulkkituonti kerralla ei onnistu.

En tuossa omassa Corine importissa tehnyt manuaalista tarkistusta, vaan käytin ihan yksinkertaista polygon overlay-analyysiä.

Samalla tavalla voidaan helposti luokitella MML:n aineisto siten, että ne kohteet, joita ei todennäköisesti ole OSM:ssä, ne jotka leikkaavat (ja manuaalisesti tarkistettava) ja ne kohteet jotka ovat jo OSM:ssä. Eli siis kolme (3) luokkaa.

Tämä automaattinen prosessi on jo minun päässä ja pääosin jo Python koodina. Ajot ovat aika massiivisia ja vaativat vielä testausta.

Onko tuossa yksilöivä id? Jos on, kannattaisiko sekin siirtää OSM:iin?

Sain varmistuksen viime viikolla MML:stä: maastotietokannassa ei ole kohteita yksilöivää ulkoista tunnistetta. Sisäistä tunnisteavaruutta on, mutta mitään GUID-tyyppistä ei ole. Yksi haaste näissä on ilmeisesti muutosten hallinta.

Esimerkki: On olemassa tieviiva A. Kun siihen tulee uusi risteys, niin kantaan tulee kolme viivaa: alkuperäinen A, uusi risteävä viiva B ja sitten risteyksen “jälkeinen” viiva C. Tämä tunnisteiden muodostuminen yms ei ole kovin selvää.

Joten ei ole uniikkejä ID:eitä maastotietokannassa. Toistaiseksi.

Aivan, KOHDEOSOn pitäisi olla yksilöivä yhdessä julkaisussa, mutta ilmeisesti ei pitkällä aikavälillä.
Itse olen käyttänyt tuota KOHDEOSOa eri tiedostoihin pilkkoutuneiden kohteiden takaisin yhdistämiseen.

“Maanmittauslaitoksen avoimen tietoaineiston lisenssi - versio 1.0 - 1.5.2012”:

http://www.maanmittauslaitos.fi/avoindata_lisenssi_versio1_20120501

josta kopio:

Siellä on edelleen tuo “vaadittava vastaavat maininnat luovuttaessaan kolmannelle oikeuksia aineiston kopioihin tai aineistoa sisältäviin tuotteisiin tai palveluihin ja
poistettava Lisenssinantajan nimi tuotteen tai palvelun yhteydestä, mikäli Lisenssinantaja sitä vaatii.”, josta OSM ei pidä (ei sovi yhteen OSM-lisenssin kanssa tai jotain sinne päin, vai oliko se juuri päinvastoin?)

Jos lisenssi kelpaa, pitäisi kenties muuttaa tuo “sisältää Maanmittauslaitoksen Maastotietokannan 06/2012 aineistoa” englanninkieliseksi ja lisäksi tehdä sama teksti kaikelle importoitavalle aineistolle (siis muulle kuin Maastotietokanta). Teksti sellaisenaan jonnekin wiki-sivulle ja itse aineistoon joku lyhyempi viittaus kaikkiin kohteisiin (olikos se “source-tag”). Nämä riittäisivät?

Jos lisenssi kelpaa, niin seuraavat taskit pitäisi toteuttaa:

Kaikki dokumentaatio pitäisi tehdä englanniksi ja täydentää suomeksi tarvittaessa.

MML:llä on infoa myös englanniksi, tässä on MML:n avoimen datan englanninkielinen lisenssi:
http://www.maanmittauslaitos.fi/en/NLS_open_data_licence_version1_20120501

Ja avoimen datan sivusto englanniksi
http://www.maanmittauslaitos.fi/en/opendata


Olen tehnyt (alun perin Paitulin kautta saatavalla aineistolla) skriptejä, jotka erottelevat yhden karttalehden alueen aineiston osaelementteihin. Tämä kuitenkin tekee satoja pienempiä tiedostoja, joten tätä ei voine hyödyntää kunnolla koko Suomen alueella. Osaan myös irrottaa aineistosta esim. järvivedet koko Suomen alueelta yhteen Spatialite-tietokantaan (jonka kooksi tulee noin 500 Mt). Tätä ei kuitenkaan kannata yrittää avata kokonaan esim QGisissä, sillä ellei ohjelma kaadu, se kestää ikuisuuksia.

Tämänhetkinen ajatukseni on, että voi olla järkevää tehdä erillisiä, koko Suomen kattavia Spatialite-kantoja, josta sitten voi irrottaa tietyn alueen kerrallaan tarkasteltavaksi. Mitä mieltä olette?

Nyt käsissä on maastotietokanta USB-tikulla. Mennee hetken aikaan kun pääsen kunnon verkon pariin. Ehkä tänään jotain ensimmäisiä kamoja torrentissa…

Ennen pitkää kannattaa tehdä koko maastotietokannasta Spatialite-versio, mutta nyt alkuun voitaisiin yrittää olla hajottamatta voimia ja koittaa pitää ensimmäiset torrent-jaot mahdollisimman virkeinä. Pahimpaan hätään voitaisiin tehdä malliksi ohjeita ja komentojonoja aineiston muuntamiseksi esimerkiksi juuri Spatialiteen. Täällä, vähän hassussa paikassa, on yksi sellainen http://latuviitta.org/Standardiaikoja.php
Hyvinkin isot Spatialitekannat toimivat hienosti QGis:ssä, kunhan ei tosiaan yritä avata sitä koskaan kokonaan. Eli täytyy pitää huoli, että spatiaali-indeksi on kunnossa, ja QGis-projektissa täytyy zoomata sopivan pienelle alueelle ennen kuin lisää Spatialitestä ison taulun. Spatialite ottaa karttaikkunan ulottuvuudet huomioon avausvaiheessa, ja sitten kun taso on kartalla, sille voi laittaa mittakaavarajan, jonka jälkeen QGis ei enää yritäkään ladata koko maan laajuista aineistoa kerralla. QGis käyttää Spatialiteä dynaamisesti eli pyytää aina kohteet vain karttaikkunan kokoiselta alueelta, joten jopa maastotietokantaa pystyy käyttämään kokonaisena, kunhan vaan se mittakaavaraja on laitettu sellaiseksi, että käyttäjän pitää zuumailla järkevän lähelle.

Jos otetaan tuo sama englanninkielisestä versiosta koska suomenkielisessä on hämäriä sanamuotoja:

  • mention the name of the Licensor, the name of the dataset(s) and the time when the National Land Survey has delivered the dataset(s) (e.g.: contains data from the National Land Survey of Finland Topographic Database 06/2012)

Lisättävissä, toki sitten kun ilmakuvia ja aineistoja alkaa olemaan vino pino kannattaisi ehkä MML:ltä kysyä mikä olisi siinä tapauksessa sopiva muoto ettei tarvitsisi jokaista niiden aineistoa erikseen nimetä.

  • provide a copy of this licence or a link to it, as well as

…Linkki tuon lisäyksen yhteydessä riittänee.

  • require third parties to provide the same information when granting rights to copies of dataset(s) or products and services containing such data and

Tämä lienee osmissa automaattista tuon lisätyn “sisältää” jutun+siellä killuvan linkin kautta?

  • remove the name of the Licensor from the product or service, if required to do so by the Licensor.

Tämän kohdalla sopivuus taitaa olla ehkä epäselvää?


i.

Olen käynyt useita keskusteluja ja todennut monessa paikassa, että MTK:sta ajetaan osia OSM:n. Ei ole ongelma MML:n päässä.

Tuo maininta MML:n aineiston käytöstä vaan tänne: http://www.openstreetmap.org/copyright. Niin asia on rasiassa.

Tosin jos katsotte tuolta tekeillä olevata Torrent-jaosta noista shape-tiedostoja, niin mikään “helppo” lataus ei ole ratkaisu…

http://laillisettorrentit.net/

Ja tänne: http://www.openstreetmap.org/copyright/en (ensisijaisesti)

Ymmärsinkö oikein, että siellä on nyt yksi paketti jaossa (MML_MTK_m43) ja pikku hiljaa niitä tulisi useita lisää sinne ladattavaksi? Kaiken kaikkiaan aika monta pakettia?

Siellä on nyt tuo M43 ja K2 alueet ikäänkuin testivirityksenä. Tarkoitus on laittaa tuo koko maastotietokannan mötikkä (9 Gt) jakoon. Kunhan saan sen ladaattua kokonaan verkkoon.

En tänään päässyt nopean verkon pariin, joten saatte odottaa ainakin huomiseen alkuiltaan (likimääräinen arvaus).

Eli ei tule montaa ZIP-pakettia vaan yksi torrent. Tosin se rakentuu sitten samalla lailla kun tuo K2. Eli siitä pitäisi voida poimia “helposti” haluamansa karttalehdet.

Joka karttalehdestä on kaksi zippiä, joiden nimet ovat _al_mtk.shp.zip ja _ea_mtk.shp.zip. Onko joku saanut jo selville mikä ero on al- ja ea-jutuilla?

al: aluemaiset, lopussa p (=polygon). ea: pisteet (symbolit, tekstit), viivat. Kai.

Ahaa, ea=ei alueet. OpenJUMP muuten pystyy avaamaan suoraan zip-tiedostosta kaikki sen sisältä löytyvät shapefilet yhdellä kertaa. Nämä zipistä luetut tasot eivät ole muokattavissa, mutta aineiston selaaminen on tuolla tavalla hitusen kätevämpää kuin zippien purkaminen johonkin tilapäishakemistoon ensin.

Huom. OpenJUMP:ssa näyttää olevan bugi. Se kyllä luo kartalle tason jokaiselle zipistä löytyvällä shapefilelle, mutta jokaiselle tasolle tulee ensimmäisen paketista löytyneen shapefilen tiedot. Eli tämä hieno ominaisuus on nyt ikävä kyllä täysin rikki.