GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

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.

Voisiko tuon yhdistää osaksi MTK-importin suunnitelmaa? Turha niitä Corine importteja on poistaa ennen kuin MTK-importtia päästään oikeasti toteuttamaan.

Yksi asia, mistä ei ole ollut (luullakseni) puhetta MTK-importiin liittyen on aineiston tarkkuus: Onko MTK-aineisto liian tarkkaa OSM:lle esim. haja-asutusalueilla? Pitäisikö sitä yleistää? Kyseessä on kuitenkin, kuten nimikin antaa ymmärtää, tiekartta.

Niin minustakin olisi paras toimia. Mutta poistossa pitää huomioida se että niitä on siellä täällä joku saattanut parannellakin. Eli vain pelkästään import versioista koostuvat objektit (kaikkine aliobjekteineen) voidaan surutta poistaa.

Maastokohteista varmaan joutunee karsimaan pisteitä (koitin jossain toisessa threadissä kysellä joltain lukuja paljonko järvistä katoaa pisteitä jos niitä yksinkertaistaa eri kokoisilla virhesallimuskriteerillä, mutta en saanut silloin vastausta miten se vaikuttaa node määriin). Noissa teissä liikanodeisuus ongelmaa ei juurikaan ole näkyny (muutaman noden lähellä toista olen bongannut, mutta niitä on todella vähän suhteessa siihen kuinka paljon olen noita eri puolilta jo ehtinyt vilkuilemaan).

Poisto voi ehkä mennä “samassa”, mutta toteutuksellisesti se on kuitenkin oma operaationsa, joka suoritetaan ensin ja sitten ajetaan varsinaista importtia sisään vasta.


i.

Niin eikö MML maastotietokannassa olekkin korkeuskäyrä,… aiankin tägi löytyy.

Eikö tuon voi talettaa samaan finland-mml.osm tiedostoon ja se vaatii mapnikissä
käsittääkseni korkeuskäyrälle oma määrittely, eikö tuo käyrä ole datana
ihan samalainen kuin kaikki way ???

Päivitys rumban saisi toimimaan objektien nimellä ja kyllä ohjelmisto osaa
tietokannasta poistaa saman kaltaisen objektin, ettei oo kahteen kertaan.
Siinä voisi sitten käyttää järkeä ja suosia osm:ss olevaa dataa, noin nopsasti
katsottuna sieltä mistä sitä on se tuoreempaa.

Syvyyskäyrät on vanhoissa tiedostoissa ja sellaista kaipaisin, niitä ei tarvitse
OpenStreetMap:iin viedä. Omaan käyttöön ne saa varmasti ottaa ja kun
lisenssin saa käsiin voihan se olla että yhdistely on mahdollista julkisestikkin.
Syvyyskäyrä kun on korkeuskäyrän jatko,…

Tää thread ei ole OpenStreet map MML import vaan että aineistoa voi käyttää ja jatkojalostaa,…
ja miten se saadaan eteenpäin.

Itse en halua MML aineistosta jättää mitään pois, filtteroinin voi tehdä mapnikin filttereillä,…

ITSE EN OLE RAKENTAMASSA OPENSTREETMAP:iä vaan hyvää karttaa omiin harrastuksiin
missä on kaikki tarpeellinen,… se varmaan muillakin?

Kyllä ainakin tällä karttalehdellä on kapsissa syvyyskäyrät mukana

ogrinfo /vsizip/vsicurl/http://kartat.kapsi.fi/files/maastotietokanta/kaikki/etrs89/gml/M5/M52/M5222R_mtk.zip Syvyyskayra |more

Jos syvyyskäyriä aikoo käyttää Mapnik-kartalla, niin minä en muuntaisi niitä ensin osm-xml-muotoon ja siitä osm2pgsql:llä tietokantaan, koska ogr2ogr:llä käyrät voisi viedä suoraan kantaan tai shapefileiksi. Niistä pitää sitten vain tehdä “datasource” Mapnikin määrittelyihin, mallia voi ottaa jostain valmiista shapefilejä käyttävästä tasosta, kuten tämä, joka löytyi jostain 5 vuotta vanhasta Mapnikin tyylitiedostosta

<Layer name="world-1" status="on" srs="+proj=merc +datum=WGS84 +over">
    <StyleName>world-1</StyleName>
    <Datasource>
      <Parameter name="type">shape</Parameter>
      <Parameter name="file">c:/data/world_boundaries/world_boundaries_m</Parameter>
    </Datasource>
  </Layer>

Hankalampi tilanne on sitten, jos samaa tavaraa on sekä OSM:ssa että maastotietokannassa tarjolla. Niistä sitten joutuu joko valitsemaan jomman kumman käyttöön tai yhdistämällä aineistoja joka tekemällä importteja OSM:in tietokantaan tai sitten viekkaalla SQL:llä omassa kannassa. Miettimistä tulee riittämään, mutta kyllä siitä jotain hupiakin saattaa saada irti. Onneksi ketään ei tiettävästi pakoteta tekemään töitä tällaisessa ympäristössä.

Niin, sitten tullaan siihen entä jos koko Maanmittaus aineiston tuo ogr2ogr:llä ja tekee mapnikiin
määrrittelyt sen käyttämiseksi. Oisko siihen ohjetta ettei pioneeriksi tarvitse käydä,…

Silloin nuo pysyisi erillään,… mutta ei saa siirtymään samaa karttaa androidille eikä nimistö dataa
nomatimille!

Toisaalta syvyys, korkeus ja muudata tulee yhdellä kertaa osm2ogr → osm"postresrg kautta ja
välissä syntyy jaeltava tavara.

Noin jakelun kannalta yksi tiedosto muoto on ja importti on helpompi kuin monta.

KYSYMYKSEEN "Onneksi ketään ei tiettävästi pakoteta tekemään töitä tällaisessa ympäristössä. " ANNAN AUTORATIIVISEN VASTAUKSEN,
ON PAKKO, EI VAPAAEHTOISTA. Kaikki jotka komntoivat threadissä ON PAKOTETTU, PAKOTETAAN JA ON AINA, HETI NYT KÄYTETTÄVISSÄ.

Kyllä tässä on ihan mietittävä juttu, katsotaan keneltä tulee se paras idea!

Minun tekemät Corine importit (FinCorineImport -tunnuksella tehdyt) voi poistaa kokonaan OSM:stä, heti kun on korvaava aineistoa laittaa tilalle. Mielellään ei niin, että otetaan pois ja sitten odotellaan skriptiä/MML:n lisenssiä/aikaa/tms. muutama vuosi…

Ei kirpaise missään. Ei näillä kilometreillä. Mua kirpaisee se metsäraja Suomen OSM:ssä :frowning:

P

Näinköhän? Voisit olla ihan tyytyväinen, jos kartan taustavärinä olisi vihreä. Kokeile laittaa landuse=forest Suomen rajarelaatiolle :wink: - Don’t import for rendering.

Suomi ON pääsääntöisesti metsää ja jos Suomen alue kartoitetaan tarkasti, niin vihreäksihän Suomi OSM kartalla muuttuu.
Vihreä väri on luullakseni perua UK:sta tai jostain sieltä suunnasta, missä metsät ovat harvinaisuuksia ja niille harvoille jäljellä oleville metsille on ANNETTU JOPA NIMET!

Suomalaisessa tiekartassa metsä on vaaleaa, ei ehkä ihan valkoista, mutta vaaleaa kuitenkin. Katsokaapa vaikkapa gt-karttaa (esimerkkejä löytyy googlen images -haulla).

Siitä syystä olisikin hyvä, jos perustaisimme oman sivuston OSM:lle ja tuottaisiin karttatiilet suomalaiseen makuun sopivana.

Ja, kyllä, ne metsät kartoitetaan vielä, kunhan ehditään. Viimeistään NLS-importissa.

a) M5132L kartalla ei näy Pilkonlahdentie,… siis pikkuiteiden nimet ei siirry tietokantaan,… puuttuuko noi kokonaan
maastotietokannasta ?

b) WINTER_ROAD päätyi isona tienä vedenpäälle mapnikissä, yritin muutta osm.xml väriä siniseksi mutta se ei ilmeisesti ole WINTER_ROAD tagillä.

c) Nomatim ei muuten suostu lukemaan kuin yhden *.osm:än mikä oli yllätys. Jotta haun saa toimimaan pitäisi
postgsql kanta tuoda ulos osmsis tai ogr2ogr ja rakentaa uudestaan osm:äksi jonka vie nominatimille, keksiikö
kukaan helpompaa tapaa ??

d) OSM ja MTK-,py scriptin tagit eivät ole yhteensopivia, tuottavat eri tasoisia tägejä samoille teille,… eli scripti translaatio file
tekee tiet isommiksi ?

e) osm2prsql alkaa valittamaan useamman importin jälkeen päälekkäisyyksistä, epävarma on uudet tietotypit siirtynyt

(windows:ssa ogr:n kehitysversiolla):


ogrinfo -ro  /vsizip/vsicurl/http://kartat.kapsi.fi/files/maastotietokanta/kaikki/etrs89/gml/M5/M51/M5132L_mtk.zip Tieviiva| findstr Pilkonlahdentie

Palauttaa:

nimi_suomi (String) = Pilkonlahdentie
nimi_suomi (String) = Pilkonlahdentie
nimi_suomi (String) = Pilkonlahdentie
nimi_suomi (String) = Pilkonlahdentie
nimi_suomi (String) = Pilkonlahdentie
nimi_suomi (String) = Pilkonlahdentie
nimi_suomi (String) = Pilkonlahdentie
nimi_suomi (String) = Pilkonlahdentie

En tutkinut sen enempää.

joo eli MTK:ssa on
joni@mpi1:~/MAP-MTK$ ogrinfo -ro M5132L.xml Tieviiva | grep Pilkonlahdentie
nimi_suomi (String) = Pilkonlahdentie
nimi_suomi (String) = Pilkonlahdentie
nimi_suomi (String) = Pilkonlahdentie
nimi_suomi (String) = Pilkonlahdentie
nimi_suomi (String) = Pilkonlahdentie
nimi_suomi (String) = Pilkonlahdentie
nimi_suomi (String) = Pilkonlahdentie
nimi_suomi (String) = Pilkonlahdentie

Joko en osaa etsiä PostGres - OSM tauluista mutta tuonti tiedostossa M5132L.osm se löytyy !!

Mitenköhän mapnikin sen saa laittaa esille tämän tien nimen:

Eiks ton pitäisi olla ihan [highway]=‘track’

Mutta tän nimi näkyy:

ja tietysti tämä:


VAI ONKO NIMI TIELLÄ VIELLÄ OMA OBJEKTI JA SITÄ EI OLE TAI SYNNY KAIKILLE MTK aineiston teille???

Vai oisko tietokanta jo koruptoitunut liian monesta päälekkäisestä lisäyksestä?

noin, sain kuin sainkin toimimaan, vika oli juuri siinä että ladattu perä jälkeen
updatea toisen päälle ja ilmeisesti objictien id:t sekosi,…

Niin MTK ja OSM tietokantojen rantaviivat ei yhdy ja maastotietokannsta tulee tavaraa
veden päälle,… eli kyllä työtä riittää! MTK tietokannan ajo OSM päälle on pakko juttu
jos tarvitsee lähiöiden ulkopuolelle kartan ja kartta tietoa.

Nuohan sitten tarkentuu kun joku aina katsoo päälekkeäin karttoja ja siirtää & korjaa
MTK aineistoa OSM:ään.

Mun tän hetkinen planet-finland + MTK ( L5242L.osm M5124R.osm M5134L.osm M5142R.osm M5231L.osm M5322L.osm
L5242R.osm M5131L.osm M5134R.osm M5143L.osm M5231R.osm M5411L.osm
L5244L.osm M5131R.osm M5141L.osm M5143R.osm M5233L.osm
L5244R.osm M5132L.osm M5141R.osm M5144L.osm M5312L.osm
M5123R.osm M5133R.osm M5142L.osm M5144R.osm M5321L.osm
) sekasikiöon osoitteessa http://kurrola.dy.fi:81/
ja koska dynaamisen ja 3G yhteyden takana niin ainoastaan jos joku tarvitsee katsoa
miten objektit meneen päällekkeäin - ei siis käyttöön eikä uteliaisuutta varten!.

Tällä hetkellä perus osm.xml käytössä ja sehän tarvitsis ilmeisesti korkeuskäyrät,
merisymbolit,… uupuuko kivetkin,… saisko noita siirrettyä OpenSeaMap, OpenCycle,…
tyyleistä ja symboleita,… onko joku tehnyt.

A) Maastotietokanta tiedot nominatimiin ?

./utils/update.php --import-file …/ogr*/M5132L.osm

SEVERE: Thread for task 1-read-xml failed
org.openstreetmap.osmosis.core.OsmosisRuntimeException: Node -2 does not have a version attribute as OSM 0.6 are required to have. Is this a 0.5 file?

at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
at org.codehaus.classworlds.Launcher.main(Launcher.java:31)
Error converting osm to osc, osmosis returned: 1

Ehdotuksia miten saisi toiminaa,
vaiko pitäiskö nominatim saada automaattsiesti updateämään kartan kannasta,
pitääkö kartan kanta kokonaisuudessaan tehdä yhdeksi .osm ja alusta luoda nominatim,
???

VAI ONKO BUGI MTK.py keimo? Node -2 does not have a version attribute as OSM 0.6 are required to have. Is this a 0.5 file? ???

B) Loppu data MAPNIK:ill’ näkyviin,
Onko joku yhdistelly jo osm.xml korkeuskäyrät, kivet ja loput symbolit vai vaatiiko muutakin työtä ?
Onko mapnik osm.xml style jaossa jossain vai ihasteletko IKI OMAA KARTTAA yksin ?
Pidän taas viikon kahden tauon ja sitten yritän A) ja B) jos kukaan ei tunnusta oinnistuneensa.

C) Miten saa helpoiten eri zoomitasoilla tiilien numeroinnin? Eli esim. jos tarvitsen zoomitasoilla 14-18 saimaan
alueen tiilien ylä ja alanurkat render_list komennolle jotta renderöin valmiiksi koko alueen tiiliksi?

Tuo virhe johtuu ehkä siitä että tuo update.php (jonka sisältöä en toki tiedä) odottaa .osc formaattia (osm diffejä) .osm:n sijaan.

14:sta kun lähdet on kyseessä vain kertolaskua kahdella per zoomitaso (tietty pitää huomioida ne aliruudut offseteilla +0, +1).


i.

Nominatimista en tiedä mitään, mutta maastotietokannan tienpätkien osoitenumerotietoja ei tuossa ogr2osm-konversiossa käytetä lainkaan. Siis niitä minOsoitenumeroVasen ym. -kenttiä. Näitten lisääminen konversioon parantaisi toki lopputulosta, mutta onko OSM:ssä mitään tapaa liittää osoitenumeroita teihin?

Muuten GML-tiedostojen konversio näyttäisi toimivan, ajoin juuri koko maastotietokannan .osmiksi ilman ongelmia ogr2osm:in kanssa. Kapsin tiedostoissa tosin oli sitten enemmänkin vikaa, rsyncattavissa hakemistoissa on iloisesti sekaisin monia versioita samoista karttalehdistä, ja osa niistä uudemmistakin zipeistä oli rikki. Kapsin tukikaan ei tunnu reagoivan huomatuksiin. Onneksi maanmittauslaitoksen latauspalvelustakin saa imuroitua kaiken ilman klikkailua, kunhan vain tietää karttalehtien nimet.