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.
Almost there, torrent jako valmistuu… ihan kohta…
Käyttäkää ja jakaa antaumuksella. Kun jakajia rupeaa olemaan, niin kerron tästä julkisuuteen (SOME, blog ja muutama ohjekin tulossa)…
Seuraavaksi sitten peruskarttarasterit. Onko jollain nopeaa nettiä viikonloppuna käytössä?
Ajattelin että oikeiden korvaavien merkkien kaivamiseen menisi hetki, mutta nekin löytyi tuolta paikannimirekisterin mukana tulevasta pdf:stä.
Kaivoin nyt samalla vielä vastaavat utf-8 koodit ja noi 8859-10:n kirjaimet.
iso-8859-10 utf-8
# hex unicode-hex utf-8-hex
ë 235 EB ǧ U+01E7 c7a7 Latin small letter G with caron
Ë 203 CB Ǧ U+01E6 c7a6 Latin capital letter G with caron
ę 234 EA ǥ U+01E5 C7A5 Latin small letter G with stroke
Ę 202 CA Ǥ U+01E4 c7a4 Latin capital letter G with stroke
ė 236 EC ǩ U+01E9 c7a9 Latin small letter K with caron
Ė 204 CC Ǩ U+01E8 01e8 Latin capital letter K with caron
ō 242 F2 Ʒ U+0292 ca92 Latin small letter EZH
Ō 210 D2 Ʒ U+01B7 c6b7 Latin capital letter EZH
ó 243 F3 ǯ U+01EF c7af Latin small letter EZH with caron
Ó 211 D3 Ǯ U+01EE c7ae Latin capital letter EZH with caron
Hienoa!
Mulle pitäisi tänään tulla postissa pikkupalvelin, jolla voin sitten jakaa 24/7. Netissä mulla on jakonopeutena 10Mbps, parempi kun mega, mutta ei nyt kuitenkaan firmojen 100 megaa vastaava.
Edit: Tai sitten Otaniemeläisten nopeuksia vastaava. Sieltä näyttää tulevan aika haipakkaa noita bittejä.
Periaatteessahan tekstitiedostosta (kun kaikki on kunnossa ja menee hyvin), perlillä on helppo sitten ISO-8859-10 => UTF-8 -käännöksen jälkeen muuntaa nuo merkit oikeiksi, tähän tyyliin (muistakaa testata kunnolla):
perl -CS -i.bak -pe 'tr/ëËęĘėĖōŌóÓ/ǧǦǥǤǩǨʒƷǯǮ/' tiedosto.txt
Selitys: -CS tarkoittaa, että syöttö ja tulostus on UTF-8:a, -i.bak tekee varmuuskopion tiedostosta, -pe sitten suorittaa tiedoston joka rivillä '-merkkien sisällä olevan korvausoperaation.
Sitten siinä maastotietokannan jakomuodossa tekstit ovat dbf-tiedostoissa, joita ei yhtä suoraan voi käsitellä.
Niin no, eihän tässä siitä olekaan koskaan ollut kysymys etteikö se MML:lle sopisi. Heillehän se toki käy (niin kauan kuin heidän lisenssiehdot täyttyvät, tietenkin). …Ongelma on pikemminkin toisinpäin jos on (siis: kelpaako lisäys suorittaa noilla MML:n asettamilla ehdoilla vai ei).
–
i.