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:
- Ilmoitus importoinnista http://wiki.openstreetmap.org/wiki/Import/Catalogue, varmaankin kohdan “Ongoing Imports, Semi-Automated” alle
- Wiki-sivujen päivittäminen:
– http://wiki.openstreetmap.org/wiki/Maastotietokanta
– http://wiki.openstreetmap.org/wiki/Fi:Maastotietokanta
– http://wiki.openstreetmap.org/wiki/Fi:Maastotietokanta/Luokat
Ja varmaan tehdä vielä erillinen sivu, joka dokumentoi suunnitelmaa/totetutusta, tyyliin:
– http://wiki.openstreetmap.org/wiki/WikiProject_Corine_Land_Cover/Corine_Data_Import
– http://wiki.openstreetmap.org/wiki/Republic_of_Ireland_Corine_2006_Import
– http://wiki.openstreetmap.org/wiki/Finland_Corine_2006_Import
– http://wiki.openstreetmap.org/wiki/WikiProject_Corine_Land_Cover
– http://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover
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…
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.
Muistutus merkistökoodauksesta (ts. aineistossa on paljon huomioon otettavaa): MML käyttää ainakin paikannimirekisterissään itse määrittelemäänsä merkistökoodausta. Onneksi suurimmassa osassa Suomea kaikki kirjaimet näkyvät oikein, kun valitsee koodauksen ISO-8859-10. ISO-8859-10 toimii myös pohjois- ja inarinsaamelaisille nimille, mutta koltansaamen kanssa tulee ongelmia. Tässä lista koltansaamen kirjaimista, joita ei ole ISO-8859-10:ssä:
Testasin jaossa olevan Ahvenanmeren kanssa, jossa ISO-8859-10 antaa oikean lopputuloksen. Koltansaamenkielisiä nimiä on vain Inarin kunnassa, joten muualla Suomessa ei tarvita nimien suhteen mitään erikoistoimenpiteitä. Toki Openstreetmapiin pitää muistaa syöttää vain UTF-8-koodausta.
GDAL käyttää uskoakseni oletuksena ainakin Windowsilla koodia ISO-8859-1. Osaatko sanoa mitä ja kuinka pahasti menee pieleen tuolla? Versiossa 1.9 näyttää olevan mahdollista kuitenkin vihjata 8859-10 käyttöön asettamalla ympäristömuuttuja SHAPE_ENCODING http://trac.osgeo.org/gdal/wiki/ConfigOptions. En ole testannut tuota temppua ollenkaan enkä tiedä toimiiko se kaikilla GDAL:n käännöksillä mutta ei välttämättä toimi.
Spatialitessä voi valita 8859-10:n joten sillä pitäisi saada aikaan hyvä lopputulos.
Jaha, näköjään suomen ja ruotsin kohdalla ISO-8859-1 antaa saman tuloksen kuin ISO-8859-10. Ongelmia on siis vain saamen kielten kanssa.
http://en.wikipedia.org/wiki/ISO/IEC_8859#Table
Pikkuisen on sivuttukin jo sitä, että MML:n aineistojen sisällyttäminen OSM:ään on yksi asia, aineistojen hyödyntäminen muutoin toinen asia. Voisi täälläkin hiukan jatkokehitellä ajatuksia, millä tavalla vapautuvia aineistoja voi hyödyntää varsinaisen OSM-kannan ulkopuolella yhdessä OSM-datan kanssa. Käytännössä tässä yhteydessä ajattelen MML:n aineiston muuntamista OSM-muotoon, jotta sitä voi hyödyntää OSM-formaatteja osaavilla työkaluilla ja ohjelmilla joko yhdessä varsinaisen OSM-datan kanssa tai erikseen.
Yksi esimerkki käyttötarkoituksesta voisi olla korkeuskäyrien ja joidenkin muiden hyödyllisten maastotietokantojen osien yhdistäminen OSM-aineistoon mobiililaitteeseen luotavaa karttaa varten. Eli kun tällä hetkellä luodaan OSM-aineistosta kartta esim. Garminiin tai kännykkään kartta jossa näkyy OSM:ssä oleva tieto, kartan luontiprosessia muokattaisiin niin, että mukaan otetaan MML:n aineistosta korkeuskäyrät (ja ehkä esim. tiestön geometrioita, maastokohteita ja mitä muuta mahdollisesti kattavampaa/parempaa siellä onkaan kuin OSM:ssä). Tuloksena OSM:n aineistosta koostuva maastotietokannan aineistoilla täydennetty kartta, jota voi hyödyntää vanhan OSM:n tapaan. OSM:ään sisällyttämisen etuna käytettävyys jo nyt, ennen kuin OSM:ään syöttämistä varten tarvittavia toimia on ehditty tehdä.
Käytännössä tätä OSM- ja maastokartta -aineistojen yhdistämistä varten pitää kartoittaa ja testata työkalusetit, joilla konversio maastokartasta OSM-muotoiseksi aineistoksi sekä aineistojen yhdistäminen onnistuu. Hiukan karttaa prosessoivasta ohjelmasta ja sen konfiguroitavuudesta sitten riippuu, onko järkevää mapata maastokartan aineistot tavanomaisiksi OSM-tägeiksi vai kannattaa käyttää erillisiä tägejä joille luodaan tuki varsinaisen mobiiliaitteen karttaa luovan ohjelman tyylitiedostoon.
Testailin pikaisesti torrenttina jaossa olevien datojen teknistä muuntoa OSM-formaattiin. Työkaluna pnorman:in og2osm-versio, kts. http://wiki.openstreetmap.org/wiki/Ogr2osm. Toimivuutta testailin merkaartorilla. Kiitos vinkistä täällä; silläkin näköjään pienimuotoiset .shp → .osm -konversiotkin sujuvat, mutta ainakaan läppärillä ei oikein kapasiteetti riittänyt isompaan aineistoon joka ogr2osm:stä meni läpi.
Periaatteessa homma näyttää pelittävän kitkatta joidenkin aineiston osien (esim. korkeuskäyrät) kanssa.
Tenkkapootakin tulee - maastokartta-aineisto on pilkottu nippuun erillisiä aineistoja, joissa eri tietosisältö; esim. yhdessä korkeuskäyrät, toisessa näyttäisi olevan rantaviivoja, jne. OSM-konversion kannalta toivottavaa olisi saada maastotietokannasta poimittavat tiedot yhteen OSM-tiedostoon. ogr2osm:n ulosannin yhdistäminen osmosis -ohjelmalla näköjään tyssää johonkin puuttuvaan attribuuttiin, joten ihan suoraan ei käsikirjoituksen mukaan mene. Nähtävästi myös node- ja way -iideiden kanssa tulee muunnostarvetta (en ole vielä katsonut osaako osmosis tuon muunnoksen, pikavailkaisulla ei näkynyt optioissa).
Digiroadin esimerkkiaineistosta olen katsellut, että siellä on erillisessä dbf:ssä nimistö, joten järkevä konversio sillä puolella vaatii erilliset tauluhaut dbf-tauluista. Täytyy tutkia onko maastokartta-aineistossa jotain samanlaista, vai onko kaikki nimistö vain pisteinä kartalla kuten nähtävästi ainakin joissain aineiston osissa.
Nimistössä periaatteessa on käytetty ISO-8859-10 koodausta, mutta saamenkielen erikoiskirjaimien tilalla on käytetty vain muita harvinaisia kirjaimia kuten Ó,Ë tms. Ja MML:n käyttämissä fonteissa taas nämä kirjaimet on korvattu saamenkielen kirjaimilla. Latin-1 (iso-8859-1) ei käy, sillä esim Š näkyisi ª:na.
Ehdottaisin, että koko aineisto käännetään nyt utf-8:ksi ja nämä saamen kirjaimia korvaavat erikoiskirjaimet muutetaan oikeiksi kirjaimiksi. Vähän käsipeliä, mutta mun mielestä tämä kannattaisi tehdä.
Eikö siinä olisi aika vähän käsipeliä, jos vie ensin kaiken ISO-8859-10 -oletuksella Spatialiteen, jolloin ja päivittää sitten ne muutamat harvinaiset kirjaimet oikeiksi utf-8 -merkeiksi? Spatialitehän käyttää sisäisesti utf-8:aa. Ongelma kuitenkin taitaa vaikuttaa vain teksteihin eli t-loppuisiin shapefileihin, vai onko noita erikoisempia kirjaimia muuallakin?
Minun täytyy sitten ilmeisesti tarkistaa ja päivittää ne samat kirjaimet paikannimistötietokantaan ja laittaa sitten korjattu versio ladattavaksi http://latuviitta.org/Lataukset.php#6.