GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

Se on ollut alusta alkaen tiedossa, että MML:lla ei ole mitään sitä vastaan, että heidän dataansa talletetaan OSM:iin. Ongelma on ollut alusta alkaen kyseisen datan lisenssi ja siinä maininnat:
"require third parties to provide the same information when granting rights to copies of dataset(s) or products and services containing such data "
ja ehkä myös “and remove the name of the Licensor from the product or service, if required to do so by the Licensor.”, tosin itse en usko tämän jälkimmäisen olevan mikään ongelma.

Tässä ketjussa ei ole vielä ollut viittausta Memorandum of Understanding keskusteluun, jonka Pekka aloitti OSM-legal-talk postituslistalla (http://lists.openstreetmap.org/pipermail/legal-talk/2012-July/007122.html). Keskustelu jäi varsin lyhyeksi, mutta yhdessä vastauksista (http://lists.openstreetmap.org/pipermail/legal-talk/2012-July/007129.html) sanotaan:

Ratkeaisiko ongelma sillä, että jos MML ilmoittaisi, että tässä tapauksessa vaatimus “require third parties to provide the same information …” ei olisi mikään ongelma. Vai pitääkö tässä sitten todella odotella sitä CC 4.0 lisenssiä ja sitä, että MML luovuttaa aineistonsa sen alla ja sitä, että onko kyseinen lisenssi edelleenkään yhteensopiva? Odotellessa saadaan taas hyvinkin toinen lähes puolitoista vuotta kulumaan ja sen aikana itse en ainakaan ole kovinkaan kiinnostunut OSM aineiston kartoituksesta, koska aineisto olisi valmiina, sen kun importtaisi.

Lopuksi voisin vielä kerran toistaa itseäni ja todeta sen, että valmistelut MML:n aineiston importoimiseksi kannattaa aloittaa pikimmiten. Lisenssiasia ratkeaa kyllä joskus. Ja kun se ratkeaa, tekniikka olisi valmiiksi mietittynä.

Eiköhän tosiaan kysäistä MML:ltä, mitä tuo “require third parties to provide the same information when granting rights to copies of dataset(s) or products and services containing such data” tarkoittaa OSM:n tapauksessa. Kuka lähettää viestiä?

moi,

MML:än pomolta saatu viesti on selkokielinen.

Siinä on kerrottu miten tulee mainita eli niinkuin on
muutenkin OSM:ssä lähteet mainittu.

On kerrottu että tulee uusi lisenssi ja mikä.

Nyt keskitytte tuohon muunto scriptiin että KAIKKI
tietotyypit siirtyvät,…

MTK-GML.py
https://github.com/tpikonen/ogr2osm-translations

===

Itse OSM kantaan kaikkea ei kannata siirtää tarvitaan
erikseen distribuution Finland-MML, ehkäpä eri alueille
omat OSM:ät,… Finland-SW-MML ,…

Systeemi/sopimus miten data pysyy tietokanssa erillään
ja päivitetävissä eri lähteistä.

Joku systeemi millä voi valita kumpaan luotetaan,
MML aineistoon vai OSM:ään,…

Postresql tietokannassa voisi ajoilla poistaa päällekyydet
ja suosia *.OSM aineistoa ja MML paikata puuttuvaa,…

Takasin aiheeseen eli miten saadaan GDAL:illa MML ainesto avoimeksi.
Mun ratkaisu oli tuoda se *.osm muotoon ja siitä postgres kantaan ja renderöidä manik;illä.

Keimo voisitko avata pikkusen tuota MTK-GML.py scrptiä ja miten siihen
tietotyyppejä voi lisätä,… pitäisi ymmärtää edes tietojen muodot,… lähteitä,…:
-mitä maastotietokanssa on
-mitä on OSM:ssä
-miten nuo näkyy postresql:ässä ja siirtyy mapnik:iin

Olit sitä mieltä että kaikkea ei kannata siirtää,… uskon
että eri ihmiset etsii eriasioita ja jonkinlainen valintamekansismi, layerit MAPNIK päässä tai
erinlaisia muunnos scripptejä eri käyttöön?

Tää on hankala juttu hallinoida monikäyttöisyyttä ja jakelua,…
jos sen sellaiseksi haluaa ?

Päivitin taas translaatioskriptiä (joka on siis saatavilla githubista: https://github.com/tpikonen/ogr2osm-translations ) ja nyt se alkaa olla aika lähellä niin täydellistä kuin yksinkertaisella kohdeluokka → tagisetti -muunnoksella on mahdollista saada aikaan. Tarkempi konversio vaatisi mm. tekstipisteiden yhdistämistä vastaaviin maastogeometrioihin, ynnä muuta heuristiikkaa. Sinänsä varsin yksinkertaista, mutta jonkin verran työlästä kirjoittaa, eikä sataprosenttisesta toimivuudesta ole takuita.

Muunnos pohjautuu wikistä löytyvään taulukkoon http://wiki.openstreetmap.org/wiki/Fi:Maastotietokanta/Luokat jota on jonkin verran täydennetty mm. teiden luokitusten osalta ja importoimalla ‘nimi’-pisteet erillisiksi OSM-nodeiksi, jolloin karttaan saadaan paikannimet näkyviin. MTK:n tieluokat muunnetaan OSM tieluokituksiin, mutta koska MTK:n luokitus perustuu ainoastaan tien geometriaan (kaistojen lukumäärä ja tien leveys), lopputuloksessa on tiettyjä puutteita.

Testirendaukset mapnikillä näyttävät kuitenkin varsin hyviltä ja suurten kaupunkien keskustojen ulkopuolella kartta on huomattavasti OSM:ia parempi. Tämä ei varmaankaan yllätä ketään.

Konvertoin tod. näk. lähipäivinä koko MTK:n paikalliseen tietokantaan, ja jos se toimii, pitää alkaa tosissaan miettimään oman leaflet-kartan hostaamista.

keimo,… kun kuitenkin joudutaan yhdistelemään muotono ja nimi konversion lisäksi,… miltä tuntuis päällekkyyksien ja
niitten kartan yksityiskohtien viimeistely sql:ssä,… tuntuisi musta luontevimmalta ?

Minulla on jo tuotettuna .osm filejä, joissa on aliverkkoja MML:n tiestö osoitteilla aineistossa (tietääkseni ainoa jossa tiennimet yms tiedot löytyvät, ei taida saada latauspalvelusta?), jotka eivät overlappaa OSM:ssa minkään oleellisen kanssa. Verkkoja on n. 170k joten siinä riittää varmasti hommaa jaettavaksi, jahka saisivat tuon copyright merkinnän lisättyä + kaikki importtiin liittyvä byrokratia on hoitettu asianmukaisessa järjestyksessä (tosin iso osa on suhteellisen pieniä, joita kannattaisi varmaan bundlettaa jotenkin yhteen, mutta tapaa täytyy ehkä vielä hetki pohtia). Suurimmat verkot olivat yhteismitaltaan n. 624km, mikä ehkä tuntuu suurelta, mutta koot pienenevät nopeasti ja n. 40km verkkoa kun koitin, sen käy jo muutamassa minuutissa läpi ilmakuvien kanssa. Isoimmissa verkoissa luulen että aikaa kuluu tunteja.

Käytännössä teiden luokittelua joudutaan varsin paljon tekemään käsin, mutta tuo näytti olevan suhteellisen yksinkertainen ja nopeahko operaatio muutaman kymmenen kilometrinkin kokoiselle verkolle jos ilmakuvat ovat alueelle saatavilla. Tuo “arvontaluokittelu” esim. tracktype:ille yms, mitä tuolla ogr2osm muunnoksessa on käytetty kannattaa kyllä hylätä suoraan ja myöntää se että MML:n luokittelusta ei läheskään täydellistä OSM-tavaraa vaivatta synny vaan dataa joudutaan ihan oikeasti katsomaan ihmissilmin! Lisäksi geometriavirheet MML:n tiestön yhteenkytkennöissä ovat pikemminkin sääntö kuin poikkeus, joten JOSMin validaattorilla tarkistelu ja jokaisen löydetyn arveluttavan kohdan läpikoluaminen on aivan välttämätöntä ennen uppimista.

Olen jo tällä hetkellä valmistelemassa tuota import-kuvausta ja koitan myös kirjoittaa importista kiinnostuineita varten oman ohjesivun tuon tekemisen jälkeen (mutta painan vain upload-nappia tyylistä ratkaisua ei valitettavasti ole niistä kiinnostuneiden iloksi tarjota):
http://wiki.openstreetmap.org/wiki/Fi:Maastotietokanta/Road_Import_Stage1_Plan

Saapi heittää kommentteja, vaikken tuota loppupuolta vielä ihan ehtinyt saamaan valmiiksi.

Tämä on siis ensimmäisen vaiheen operaatio niille alueille, jotka ovat tällä hetkellä tyhjiä OSMissa. Seuraavassa vaiheessa pitää sitten miettiä olemassaolevaan dataan tietojen liittämistä, mutta se on huomattavasti haasteellisempi operaatio (jotain yritystä mulla on matchayksenkin suhteen olemassa, mutta se on vähän vielä vaiheessa se koodi).


i.

Latauspalvelusta on nykyään saatavana tiestö osoitteilla: http://www.maanmittauslaitos.fi/aineistot-palvelut/latauspalvelut/avoimien-aineistojen-tiedostopalvelu “Maastotietokanta kaikki kohteet, tiestö osoitteilla”. Muistaakseni tiestö osoitteilla ei ollut latauspalvelussa alusta alkaen.

Edit: http://wiki.openstreetmap.org/wiki/Fi:Maastotietokanta/Road_Import_Stage1_Plan on kohta “Address data”. Onko kellään tietoa mistä MML saa pohjakarttaansa osoitteet talojen kohdalle? Esimerkin saa helposti, jos avaa Paikkatietoikkuna.fi:n Karttaikkunan (http://www.paikkatietoikkuna.fi/web/fi/kartta) ja zoomaa riittävän lähelle oletuspohjakartan ollessa päällä. Osoitenumerot ovat talon kohdalla. Joissain tapauksissa saattaa tietysti olla hankalaa kohdistaa numero oikeaan tiehen, mutta muuten kyseinen aineisto sopisi varmaan hyvin OSM:n osoiteaineiston pohjaksi. Saattaisiko lähtöaineistona olla rakennus- ja huoneistorekisteri (http://www.vaestorekisterikeskus.fi/default.aspx?id=175) vai joku muu aineisto?

Käsityö kuulostaa pahalata, kaikissa systeemeissä järjestelmän saaminen pystyyn on helppo juttu verattuna siihen
että se on pystyssä 10 ehkä 50 vuoden päästä ja toimii vielläkin.

NIIN Maanmittaushallitus PÄIVITTÄÄ TIETOKANTAANSA KOKO AJAN, PÄIVITYKSET PITÄISI SAADA SIIRTYMÄÄN
MAHDOLLISIMMAN AUTOMAATTISESTI !

En ole ehtinyt, enkä ihan heti ehdi, kun tappelen rinakkain laskenta ongelmien kanssa, perehtyä OSM päivitys mekanismeihin mutta näillä vilasuilla on sellainen
tunuma että siellä on joku osm_id mikä yksilöi yksittäisen objektin päivitystä varten. Joten MML tietokannalle pitäisi
saada varmaan jostakin oma “id avaruus” ?

Päällekäiset tiet, ja nimistön puhdistus pitäisi onnistua ihan SQL:llä, voisi olla toimiva,…

Voisko tuotanto olla tällänen:

OMAT KARTTAT, KARTAN JAKELU PALEVLUT MUODOSTAMINEN JA PÄIVITYS:

OSM materiaali, esim. finland-latest.osm.pdf —> osm2prsql -append
Omat OSM lisäykset ----> osm2prsql -append
ja
MKL aineisto → gdal → ogr2osm -append MTK.py ( JOKU TÄGI MIKÄ MTK VERSIO JA PÄIVITYS PSM ) → osm2prsql → sql käsittelyllä päällekkyydet pois

ko. muodostettu tietokanta takasin OSM muotoon ja edelleen Nominatimille ja esim. android/Iphone/garmin karttojen tuotantoon ja
itse OSM viimesimmäksi finland-latest.osm versioksi ??? Ja sama uudestaan taas kun MTK tietokanta riittävästi muuttunut vai saako
MTK:lta pelkät muutokset ???

Tietysti muodostuneen tietokannan voisi käsintarkastelun jälkeen viedä takasin OSM:äksi.

Niin lisenssistä viellä, musta tuo vastaus oli selkeä, nykynen on riittävä ja mitään erillistä sopparia ei tule.

Viimesin MTKGML.py antaa virheen:
AXIS[“Easting”,EAST],
AXIS[“Northing”,NORTH],
AUTHORITY[“EPSG”,“3067”]]
Traceback (most recent call last):
File “ogr2osm.py”, line 656, in
parseData(data)
File “ogr2osm.py”, line 336, in parseData
parseLayer(translations.filterLayer(layer))
File “ogr2osm.py”, line 397, in parseLayer
parseFeature(translations.filterFeature(ogrfeature, fieldNames, reproject), fieldNames, reproject)
File “ogr2osm.py”, line 418, in parseFeature
translations.filterFeaturePost(feature, ogrfeature, ogrgeometry)
File “/home/joni/src/ogr2osm/translations/MTK-GML.py”, line 47, in filterFeaturePost
feature.tags = mtk_features.get(ogrfeature[‘kohdeluokka’], mtk_default)(ogrfeature)
File “/home/joni/src/ogr2osm/translations/MTK-GML.py”, line 587, in
44803 : lambda f: { “man_made” : “tower”, “height” : ustr(float(fget(‘korkeusarvo’, 0.0))/1000.0), },
File “/home/joni/src/ogr2osm/translations/MTK-GML.py”, line 58, in fget
val = ogrfeature[key]
TypeError: string indices must be integers, not float
(jpk)joni@mpi1:~/src/ogr2osm$

keimo, siirtyykö korkeyskäyräkin ? Eli riittääkö osm-xml uuden tyylin lisäys, ilmeisesti OSM DATA
ei tunne korkeus käyrää, niinkö ??? Pitäiskö tyyleille antaa yhteiset nimet jostain ?

Mistä saataisiin vanha tietokanta syvyyskäyrillä,… missä jaossa ???

Toisaalta voi olla niinkin, että voimme jättää tämän ongelman ratkaisemisen myöhemmäksi. Näin siksi, että MML ei (tietääkseni) mitään diffejä pysty toimittamaan, joten se jäisi joka tapauksessa meidän tehtäväksemme. En tiedä miten “diffit” voisi tehdä, mutta joka tapauksessa se aineisto, josta importti tehdään, pitää tallentaa johonkin säilöön, esimerkiksi torrentteina, joita importoijat sitoutuvat säilyttämään, kunnes seuraava importti tehdään. Siinä vaiheessa voi sitten yrittään jotenkin selvittää muutoksia edellisen importin lähdeaineistoon.

Ei lisenssiasia ole vielä selvä, mutta jos MML:ta saisi vastauksen, että “vaadittava vastaavat maininnat …” ei kosketa OSM:ia, niin sitten lisenssiongelma saattaisi olla ratkaistu. Tavallaan kyseessä olisi erikoislisenssi OSM:lle.

Muuta:

Dokumentissa http://wiki.openstreetmap.org/wiki/Fi:Maastotietokanta/Road_Import_Stage1_Plan#Tagging_Plans on kirjattu, että “We feel no need to have source attribution in each object. It would just bloat the database unnecessarily and the current requirement for a separate import account should be enough to distinguish imported data from the other edits.”
Laittaisin tuon edellisen toiseen järjestykseen siten, että aloitetaan tuolla “separate import account”:lla ja sen jälkeen todetaan, että source attributionia ei siten tarvita. Olisikohan tarvetta käyttää useita “separate import accunteja”?

Ehdotan seuraavaa importin suunnitteluun liittyen:

  • Pyritään tekemään dokumentaatio pääosin englanninkielellä
  • Lisätään etusivulle linkki importin suunnitteludokumentaatioon (http://wiki.openstreetmap.org/wiki/Fi:Main_Page)
  • Tehdään lyhyehkö pääsivu suomeksi ja siitä linkki englanninkieliseen vastaavaan, josta sitten linkkejä alisivuihin
  • Pääsivulla on kuvattu lisenssi ja siihen liittyvät ongelmat sekä importin vaiheistus
  • Eriytetään mäppäyssivu (sivu, jossa kuvataan kuvaus MML->OSM) omaksi sivukseen, Mäppäys on varmaankin parasta kuvata taulukkona, joka noudattaisi MML:n tietojen järjestystä (tämä vaikuttaa hyvältä pohjalta http://wiki.openstreetmap.org/wiki/Fi:Maastotietokanta/Luokat))
  • Jaetaan mäppäyksen kuvaus kahteen osaan: triviaali osa ja hankalampi osa, jossa jälkimmäinen sisältää aineiston, jossa esim. aluemuotoisten kohteiden ominaisuustietoja on kuvattu ”kartografisesti” tunnuspisteellä tms. kuvaustekstillä ja importissa nämä tiedot pitäisi pystyä yhdistämään

Jos MML:n lisenssiongelma ratkeaa myös Metlan lisenssiongelma saattaisi olla ratkaistavissa samalla periaatteella. Metlan avointen aineistojen lisenssi on kutakuinkin ellei sama kuin MML:lla (http://kartta.metla.fi/). Metlan aineistosta voisi tuoda metsäkuviotietoja ja metsän maapohjatietoja. Metlan aineistojen importtauksen voisi ehkä ottaa samaan prosessiin mukaan.

OSM ei talleta korkeuskäyriä. Joitain korkeustietoja on mahdollista tallettaa, mutta ei korkeuskäyriä. Tästä taisi olla muutama sivu aiemmin.

Ei ainakaan vapaasti taida olla missään tarjolla. MML poisti vesistöön (veneilyyn) liittyvät tiedot aineistosta ennen aineiston vapautusta. Eikös tästäkin ollut jotain sivu pari aiemmin tai jossain toisessa ketjussa.

Siinä olisikin uudelle yhteisöprojektille paikka: syvyystietojen kartoittaminen. Näyttäisi siltä, että OpenSeaMap ei sekään taida tallettaa syvyystietoja, eli perustuisiko kokonaan OSM aineistoon: http://openseamap.org/

Se vaan on valitettavasti niin etteivät nuo classifioinnit sovi yhteen (MML vs OSM). Tätä ongelmaa ei pidä sivuuttaa sillä että valitaan Garbage In Garbage Out ratkaisu (ja päästään bad imports hall-of-shame listalle :-))! Muistutan toki että sinun henkilökohtaisesti ei ole mikään pakko osallistua, jos haluat pitäytyä tahrimasta käsiäsi mihinkään käsityöhön ;-), uskon kyllä että riittävästi halukkaita löytyy muutenkin että homma saadaan toimimaan.

Aivan, mutta kannattaa myös muistaa se tosiasia, että maasto pysyy loppuen lopuksi varsin stabiilina muutoksista huolimatta. Elikkä ei Suomen kaikkia teitä tai vaikkapa taloja kerran vuodessa laiteta uusiksi. Nähdäkseni tässä on nyt hiukan liioiteltu muuttumisen mittakaavaa.

Heh-heh. Moni koodipuolellakin varmasti maksaisi maltaita jos saisi aukottomasti toimivan automaatin joka huolehtii esim. confliktit. Muistathan että myös OSM päivittyy jatkuvasti!

OSMissa on ID-avaruus (osm_id column jos osm2pgsql:llä importtaat). Mutta mutta, OSMin puolella ID:iden pysyvyydestä ei ole mitään takeita, seuraava editoija saattaa laittaa editoidessaan ID:t piu-pau-poks. Toki sitä voidaan .osc diffejä processoidessa vielä käyttää kontrolloidusti hyödyksi mutta muuten siitä ei ole hirveästi muutosidentifiointiin avuksi (eli poistetut objektit “katoavat” kannastasi jos ne poistetaan osmista ja ajoit diffit sisään). Vähän sama homma MML:n puolelta vai oletko löytänyt jostain dokumentaatiota miten heidän ID:t käyttäytyisivät muutoksien yhteydessä? IMHO, kaikki ID:t jotka eivät perustu objektien geometriaan ovat tuhoontuomittu yritys tällä pohjalla. Lisäksi geometria on mielestäni täysin riittävä, joskaan ei täysin helppo ID noin niinku laskennan vaativuutta ajatellen, mutta nähdäkseni ainakin tieverkon tapauksessa se pitäisi olla varsin mahdollista ratkaista riittävällä tarkkuudella! Lisäksi MML:llä tiet on pilkottu pieniin osiin vaikkei mikään attribuutti muuttuisikaan, OSMissa wayt ovat pitempiä jos tien attribuutit pysyvät samana.

Käytännössä MML:n aineistosta on helpohkoa laskea diffit edelliseen MML:n versioon nähden tietokannassa, muutoksien määrä ei tule olemaan järin suuri vaikka sitä pelkäsitkin. Tämä vaihe on varsin helppo automatisoida!

Itse lähtisin kuitenkin mielummin siitä, että MTK:n aineisto pyritään yhdistämään uppimalla se järkevästi suunniteltuna suoraan OSMiin (mutta tässä tarvitaan sekä harkintaa, että jonkun verran aikaakin, sitä ei saa aikaan yhdessä yössä). Toki en kiellä sinua koitamasta tehdä yhdistämistä täysin OSMista riippumatta :-). Ongelmana tuossa yhdistelyssä, jota ilmeisesti toivot mahdollisimman automaattiseksi ovat OSM:in laatuvaihtelut. Tieverkkojen yhdistäminen automaattisesti riittävän hyvällä onnistumisprosentilla voi osoittautua jossain määrin haastavaksi, erityisesti jos sinulla ei ole erittäin vahvaa pohjaa conflation-algoritmeista etukäteen - juu olen miettinyt näitä itse jonkun verran ja tiedän kyllä jotain siitä mitä sieltä tulee vastaan, vaikka pahimpia juttuja olenkin jo kauan sitten OSMista korjaillut “käsityönä” ;-).

Olen samaa mieltä tuosta MML:n vastauksesta, ei se sinänsä ollut mitenkään yllättävä (suullisesti sama viesti onkin jo kuultu).


i.

Tuo diffien tuottaminen MML:n aineistoista vertaamalla edelliseen MML:n aineistoversioon on tosiaan helpohko operaatio. Ajatuksena oli toimia about siihen tyyliin kuin yllä kuvasit.

Olen samaa mieltä että tätä ei vielä tässä vaiheessa kannata edes ratkaista, koska ratkaisu saattaa osin tai kokonaan löytyä siinä vaiheessa kun Importin “phase 1”:stä lähdetään jatkamaan, eli siirrytään phase 2:ssa (tms) alueille joissa on jo tiedataa OSM:ssa (jolloin tarvitaan hiukan lisää kehitystyötä MML vs OSM objektien matchaystä varten. Syntynyttä työkalustoa pystyy ehkä hyötykäyttämään myös päivitysvaiheessa.


i.

Kiitos kommenteista ja ajatuksista!

Koitan illalla uudelleenmuotoilla tuota object attribuutiota, mutta kyseessä on wiki joten saat sinäkin siihen koskea :-D.

Uusi accountti per importti voisi olla järkevää, mutta tuossa on vaan se ongelma, että accounteilla pitää olla uniikki email osoite, josta on ainakin muuallapäin maailmaa ollut jonkun verran purnausta. Valitettavasti erillisiä accounteja vaativilla admin puolen kavereilla ei näytä olevan intoa koodata osmiin “secondary usernameja”, missä yhteys varsinaiseen käyttäjään olisi vielä vahvempi (käyttäjien tuntemisen kannalta tuo olisi kiva feature eli tiedettäisiin suhteellisen suoraan että importtaaja x_yzimport on sama käyttäjä joka editoi nimellä x). Secondary usernamet jakaisivat tietenkin sen emailin automaattisesti :-).

Enemmän olen itse koittanut miettiä miten on järkevää tehdä import ja sen jälkeiset käsin yhdistely muutokset suhteessa eri accounttien käyttöön (esim. nuo aliverkko pitää uppimisen jälkeen tietysti yhdistää käsin siltä puuttuvalta 40m+ matkalta OSMissa olevaan dataan, mitä accounttia käytetään tähän?).

Tämä oli myös oma ajatukseni. Aion tehdä oman sivun ohjeistosta “teamille”, jonka linkkaan tuohon planin “step-by-step” kohtaan. Sen team dokkarin suomikäännöstä voi ehkä harkita jos kääntäjiä löytyy avuksi.

Koska tuo plan dokkari on yksi importbyrokratian vaatimus, pidän sen tuollaisena, mutta itse “teamiin” osallistuville toteuttajille tehdään mielummin oma ohje järkevämmällä rakenteella, monet eivät jaksa lukea edes lyhyempää sivua huolellisesti läpi ;-).

Tämä importti jota nyt suunnittelen keskittyy pelkkään tiestöön. Erilliset importit saatte/saadaan suunnitella ja toteuttaa muille luokille (vaikkapa rajat, vesistöt, sähköjohdot, “vuorenhuiput”, suot, jne.). Ehkä jonkinlainen yhteinen lisenssi yms. tietosivu noille voidaan tuosta road sivun rungosta voidaan toki repäistä, jos ja kun joku rupee niitä seuraavia import planeja kirjoittamaan.

Joo, tuo yhdistely MTK:ssakin tuo oman lisänsä haastetta. Mutta nähdäkseni silti suurin haastejakolinja kulkee OSMssa ei mitään ja MTK:ssa ja OSM:ssa on päällekkäisyyksiä välissä.

Joku arvuutteli että MTK:sta kin saisi metsät… “sitä on kaikkialla missä ei oo mitään muuta”, mutta tarkkuudesta en kyllä osaa itse sanoa juuta enkä jaata :-).


i.

Ei pitäisi tuupata testaamatonta koodia… Nyt tuo on korjattu.

OSM ei tosiaan sisällä korkeuskäyriä, mutta esim. Opencyclemapin tiilissä ne on renderöityinä. Datalähde ei ole OSM, vaan NASAn tietokanta SRTM. Tuon wikisivun lukemalla tosin oppii, että onhan tuonkin datasetin jo joku ehtinyt konvertoimaan OSM-formaattiin.

Ei ollut alkuun. Kas, sieltä saa siis päivitetyt versiot. Tai tässä aineistossa taitaa olla siis tien alku- ja loppupään osoitteet. Välit pitää interpoloida.

Tuon taustakartan osoitteet tulevat VRK:stä ja sinne ne tulevat taas kunnista. VRK:n RHR aineisto ei ole ilmaista aineistoa, eikä ilmeisesti ihan nopeasti tulossakaan…

Maastotietokananssa ei ole metsää. Eli kaikki mikä on valkoista on metsää :wink: Pellot ja niityt löytyvät yms.

CorineImport (kun taas jatkan sitä), niin tuo perus-metsämaskin OSM:n Suomen osalta. Sitä voi sitten parantaa MML:n ja Metlan aineistoilla.

Metlan aineiston käyttö edellyttäisi aika vahvaa yleistämistä ja esiprosessointia. Sisältää sen verran paljon OSM:n kannalta turhaa tietoa.

P

Minä aloittaisin poistamalla tähän mennessä tehdyn Corine-importin kokonaan. Seuraavaksi pitäisi laittaa järvien rantaviivat kuntoon maastotietokannasta ja lisätä OSM:sta vielä puuttuvat vedet; tämän jälkeen sama kaikille muille maastotietokannasta löytyville alueille: suot, pellot, kalliot, vesijättö, hiekkakuopat ym. Nämä ovat maastotietokannassa paljon tarkemmin kuin Corinessa ja laatu varmasti kelpaa OSM:iin. Jäljelle jää luokittelematonta metsää, ja sitä voisi sitten pilkkoa Corinen tai Metlan aineiston perusteella tarkempiin maankäyttöluokkiin.

Tämä varmaan kirpaisisi Corine-importteja tehneitä, mutta eihän kukaan muuten ikinä jaksa sovittaa esimerkiksi Corinen metsien ja OSM:n järvien rajoja keskenään, ja jos niitä ei soviteta, niin lopputulos ei näytä kovin laadukkaalta. Tällaisia esimerkkejä ei ole vaikea löytää http://www.openstreetmap.org/#map=14/61.1776/25.8453&layers=N

OSM:n metsätyypit https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dforest:

name=*
type=coniferous
type=broad_leaved
wood=deciduous
wood=mixed
crop=*

con·i·fer (k n-f r, k n-) n. Any of various mostly needle-leaved or scale-leaved, chiefly evergreen, cone-bearing gymnospermous trees or shrubs such as pines, spruces, and firs.

Deciduous means “falling off at maturity”[1] or “tending to fall off”,[2] and is typically used in reference to trees or shrubs that lose their leaves seasonally

Eli havumetsä/lehtimetsä/sekametsä jaon voi tallettaa. Metlan tiedoista saisi mantyvaltaisuus/kuusivaltaisuus -tiedonkin, mutta sen tallentamista OSM ei taida tukea.

Maastotietokannassa näyttäisi olevan päämetsätyyppijako: http://www.maanmittauslaitos.fi/sites/default/files/Maastotietokohteet.pdf ja sieltä “4.5.20 Metsämaan kasvillisuus”:
Havumetsä (32710)
Lehtimetsä (32713)
Sekametsä (32714)
Varvikko (32715)
Pensaikko (32719).

Ehkä sittenkin kannattaa jättää Metla pois importista. Hyvää tietoa siellä on. Jos haluaa nähdä, mitä tietoja Metla tarjoaa, Paikkatietoikkunan karttaikkunasta löytyy, kohdan “Maanpeite” alta. Suurin osa kyseisen alakohdan tasoista on Metlan avointa aineistoa. Tietoa voi käyttää esim. sienestysreissun suunnittelussa, jos ei tiedä sienimetsiä ennestään.