Corine aineiston korjailut - apua tarvitaan

Communities Suomi (Finland)
1

Terve !

Aloitin lievän katkoksen jälkeen nyt prosessoimaan noita puuttuvia Corine-aineistoja. Prosessia olen tuolla Wiki:ssä koettanut selventää. Juuri nyt ajan 63 leveyspiirin yläpuolella olevia ruutuja (0.5 asteen ruudukko).

Prosessin tuloksena jää yli sellaisia monikulmioita, jotka leikkaavat jo olemassa olevia OSM:n kohteita. Joissakin tapauksissa on selvää, että Corine-aineistoa ei voi missään tapauksessa laittaa OSM:n. Mutta monessa tapauksessa leikkaus on vain muutamia metrejä tai muuten manuaalisesti helposti korjailtavissa.

Prosessin tuloksena syntyy siis noin 300 kpl osm-xml-muotoisia tiedostoja, jotka pitäisi käydä manuaalisesti läpi. Tämä manuaalinen prosessi menisi suunnilleen näin:

  • Lataa aineisto JOSM:in
  • Tarkastele kohteet
  • Siirrä / muokkaa kohteita, jotta ne voi ladata OSM:n.

Halukkaat voivat heittää suoraan mailia (pos at iki.fi), niin voin laittaa tulemaan yhden esimerkkiruudun tutustuttavaksi.

2

Hupsansaa, työkalusi pukkaa tuplanodeja jokaiselle taitepisteelle joka on kahden alueen rajalla, ts. oma node kummankin/jokaisen puolen polulle.

3

Oops,

…
Ei pitäisi käyttää paikkatieto-ohjelmistoja OSM-aineistojen kanssa.
…
Hmm, pitää katsoa kuinka tuon saan korjattua.

Joku ilmeisesti oli valittanut IRC:ssä tuplavaani aineistoja. Sehän ei nyt pitänyt paikkansa. Lievää epätarkkuutta prosessissa.

4

Ihan vain sellainen tyhmä kysymys liittyen tähän importtiin (11409357 Tue, 24 Apr 2012 20:42:46 +0000, peittoalue Viitasaari - Pihtipdas). Tuossa on OSMiin pukattu lähes 44.000 pistettä. Onko prosessi vielä kesken, kun Pihtiputaan keskustan tuntumasta löytyy kasa “tyhjiä” pisteitä. Esimerkiksi 1729470564, sijaintipaikka keskellä Putaanvirran (ala)koulun pihaa (Bingin ilmakuvassa parakkiväistötilojen ja koulurakennuksen välissä).

5

Korjailu kesken, jostain syystä alueiden muodostus ei onnistunut tuossa Importissa ja sinne meni vain alueiden reunapisteet. Tai siis ei edes olisi pitänyt mennä mitään tuonne alueelle, jossa on jotain alueita jo valmiiksi.

En aja mitään lisä-importtia, ennen kuin olen korjannut edelliset virheeni ja saanut prosessiin jonkun tolkun. Jos sittenkään :frowning:

6

Tuo sekoilu-importin korjailussa teen kahta asiaa: poistan nuo reunapisteet, joista jostain syystä ei muodostunutkaan alueita sekä poistan duplikaatit noista alueiden rajaviivoista. Molempia teen käsityönä, kun en usko enää skripteihin :frowning: Sitten ilmeisesti tuon lisenssivaihdon osalta on hieman ruuhkaa todellisten massapoistojen osalta. Ja kun olen aiheuttanut ongelman, niin saan sitten kärsiä seuraamuksista. Eli teen JOSM:n avulla tätä työtä. Ei kovin mieltä kohottavaa, mutta mainio tapa viettää Vappua.

Menen aluetta läpi järjestelmällisesti puolen asteen alueissa. Nuo puolen asteen alueet lähtevät pistesstä 25.0 (lon) ja 63.0 (lat). Eli ensimmäinen oli 25.0-25.5 ja 63.0 - 63.5. Joskus dataa on sen verran paljon, että pitää käyttä neljäsosa asteen alueita.

Lataan aineiston siis JOSmiin koordinaattialuerajoilla: Bounding box: min lat 63, max lat 63.5, min lon 26 max lon 26.5.

JOSM:ssa haen pisteet, jotka ovat täysin turhia (vrt. Pikarin mainitsema piste Pihtiputaalla/ssa). Search-haulla (tai CTL+F): “user:FinCorineImport -area? -child”. Sen jälkeen vain delete / poista.

Duplikaattien poisto tapahtuu käyttämällä Validate -operaatiota. Yleensä alueesta näyttää löytyvän jonkin verran myös muiden “tekemiä” virheitä. Valitsen kumminkin vain FinCorineImport -käyttäjän virheet. Lähtökohtaisesti korjaan kahdet duplikaatit pois.

Ensimmäinen on Validate-osan “Error”-kategoriassa: Natural- ja/tai Landuse duplicated nodes. Valitaan alueet (“Select”) ja sen jälkeen Fix.

Toinen on sitten “Warning”-kategoriassa: Mixed type duplicated nodes. Näistäkin valitsen FinCorineImport-tunnuksen tekemät muutokset ja korjaan ne automatiikalla (Fix).

Sen jälkeen uploadaan aineiston takaisin OSM:n. Riippuen alueen koosta, niin tähän menee sitten joskus aika paljonkin aikaa.

En laita pahaksi, vaikka muutkin noita FinCorineImport -virheitä korjailee näiden opastusten perusteella. Jos joku poistaa joltakin alueelta kaikki FinCorineImport -käyttäjän tekemät alueet, niin en siitäkään pahastu. Antaa mennä vain. Toivoisin kuitenkin, että Suomesta tulisi joskus vihreä…

Ja jos kohtaamme fyysisesti, niin saa lämäyttää. Ansaitsen sen, mutta ei kiitos kasvoihin. :expressionless:

Kaikesta huolimatta oikein hyvää Vappua ja toivottavasti olette kartoittamassa maastossa, ettekä roiku sisätiloissa tekemässä päivityksiä.

ps. Pikari: korjaan sen Pihtiputaan nyt ensiksi (alueena 63.5 /25.0-25.5-26.0)

7

Eiku se Pihtipudas onkin eteläisempää aluetta eli 63.0 (25.0-25.5)

8

Moro,

Voin tarvittaessa jatkaa corineaineiston importtausta ns. “manuaalisesti” jos automaattinen tuonti ei onnistu, konsensus sitä vaatii ja parempaakaan aineistoa ei ole saatavilla. Katsoisin nyt ensin kuitenkin mitä maastotietokanta sisältää ennen importtauksen jatkamista.

9

Toivottavasti korjaus ei jumiudu siihen, että aivopieruissa poistin mitään ajattelematta kokonaisen yhden tyhjän FinCorineImport -pisteen Pihtiputaan kirkonkylästä. Rapatessa roiskuu. Olen törmännyt muistaakseni Parikkalassa, Uuraisilla (farm * 107168694 & forest 107171907) ja Hämeenlinnan Lammilla sellaisiinkin CorineImport kummallisuuksiin, joissa on kaksi täysin identtistä maa-aluetta päällekkäin. Toinen on merkitty aina farm ja toinen forest -avaimella. Haamumetsän olen silloin poistanut huhuilemasta.

Voidaan leikkiä läimäysleikkien sijaan “Hauskoista kotivideoista” tuttua alligaattorileikkiä. :wink:

  • Muokkasin manuaalisesti tuota peltoaluetta
10

Oliko haamumetsä osana jotakin multipolygon-relaatiota? Alkuperäisessä Corine-tuonnissahan oli vanhaan tyyliin merkitty relaatiolle pelkkä type=multipolygon ja sitten sekä outer- että inner- jäsenille ne kaikki tagit, siis esimerkiksi natural=wood, wood=mixed, sekä koko joukko corine- ja clc-tageja. Tuossa vanhassa merkintätavassa todella tarvitaan ne kaksi identtistä aluetta päällekkäin, sillä toinen alueista kertoo olevansa reikä metsän keskellä ja toinen kertoo olevansa maatila. Nyt siellä saattaa jonkin tulkinnan mukaan olla maatila metsän päällä.

Olen korjaillut mkgmapin multipolygon-varoituksia kuukausien mittaan. Niitä ei juurikaan tullut siitä Corine-tuonnista vaan ilmeisesti myöhemmistä muokkauksista. Olen silloin muokannut relaation nykykäytännön mukaiseksi, siis siirtänyt outer-polulta kaikki muut tagit paitsi source=* relaatioon sekä poistanut kaikki multipolygon-relaatiossa olevat tagit kaikilta outer- ja inner-jäseniltä. Tällä tavoin saatoin poistaa mainitsemasi kaltaiset tupla-alueet, jos jossain oli järvi tai peltoa Corine-metsän keskellä.

Jotkut muokkaajat ovat silloin tälllöin tehneet multipolygoneja, joissa alueet eivät ole sisäkkäin vaan vain koskettavat toisiaan. Niitä olen pilkkonut pois relaatioista, sillä nehän ovat vain vierekkäisiä alueita.

11

Ei pitäisi ongelmaa, tai siis kun teen manuaalisesti (nyt tosin toistaiseksi taas holdissa) niin homma ei välitä noista toisten tekemistä korjauksista.

12

Miksi tuo alkuperäinen importtaus sitten keskeytyi?

Maastotietokanta on eri juttu, siitä käydään keskustelua muualla.

13

Heippa,
Se keskeytyi siihen, että maastotietokanta määriteltiin julkaistavaksi lähitulevaisuudessa. Maastotietokanta sisältää paljon tarkemman metsäaineiston lajimäärittelyineen ym. joten en katsonut järkeväksi jatkaa prosessia, jonka lopputulos olisi kuitenkin vaatinut suuren määrän korjauksia tai kokonaan poiston.

(Edit: Tarkemman tarkastelun perusteella maastotietokannan metsäaineisto on yksittäisessä pistemuodossa, joilloin sitä ei voida käyttää OSM:ssä. Maastotietokanta sisältää kuitenkin louhokset, maatilat ja metsäsuot, jotka voidaan mielestäni jättää corinetuonnista pois.)

14

Tarkistin tuon Uuraisten tapauksen. Corine -importissa (7762640) syntyi ensiksi laaja metsäalue 107167704 (Mon, 04 Apr 2011 10:03:04 +0000). Sitten syntyi peltomaa 107168694 (Mon, 04 Apr 2011 10:12:59 +0000) ja puolisen tuntia myöhemmin peltomaan kanssa identtinen metsä 107171907 (Mon, 04 Apr 2011 10:39:56 +0000). Relaatioon 1526959 (Mon, 04 Apr 2011 10:46:54 +0000) päätyi tuo laaja metsäalue (saaden ulkojäsenyyden) sekä identtinen metsä (sisäjäsenyys), peltomaa jäi kokonaan relaation ulkopuolelle. Minä sörssin sitten myöhemmin siten, että poistin tuon peltomaan kanssa olleen metsäalueen ja annoin samalla peltomaalle sisäjäsenyyden. (Loin samassa syssyssä peltomaalle oman multiprelaation (ulkojäsenyys), kun tulin muokanneeksi sen sisään kaksi maatilaa (näistä tulivat sitten tämän uuden relaation sisäjäseniä). Olenko ollut tuhma, ja ansainnut herra Koivuniemen kotikäynnille?

15

Maastotietokantahan on täysin kartografinen tietokanta. Tuo pistemuotoinen metsäkin on ainoastaan kartalla näkyviä puuston symboleita. Perusajatus maastokartoissa Suomessa on, että jos kartalla ei muuta mainita niin alue on metsää. Metsää kun Suomessa on aikasta paljon, päästään vähemmällä jos sitä ei merkitä. Olisiko OSM:ssäkin voinut lähteä vähän tästä ajatuksesta? Koko Suomi ensin metsäksi ja siitä poistaa sitten vesistöt, pellot ja asuinalueet. Näin saisi myös Maastotietokannasta jonkinlaisen metsäaineiston, mutta todellisuudessa vain periaatteellisella tasolla.

16

Mitä tällä tarkoitat? Itse tietokantaako tarkoitat vai siitä muodostettuja tuotteita? Molempia?

Saattaisi toimia, jos tosiaan metsiä ei ole erikseen merkitty, eli aineistossa metsiä olisivat “kaikki muu”. Silloinhan metsät saisi alueina ulos seuraavasti: aluksi muutetaan käsittelyn helpottamiseksi aineisto ensin jonkinlaisiksi grideiksi, niistä neliöiksi tms. suorakulmioiksi, joista leikataan kaikki muu mm. viivat ja pisteet puskuroimalla ja lopputulos on metsää. Sitten yhdistellään takaisin, yhdistetään neliön tms. suorakulmioiden vierekkäiset metsät. Lopputulemana metsäpolygonit. Corine-aineistosta sitten niille tyyppi. Toimisiko? Voi tietty vaatia levytilaa ja laskentatehoa.

17

Moinen ratkaisu kuulostaa mielenkiintoiselta. Maastotietokannan vektoriaineisto näytti olevan lohkottu varsin pieniin yksiköihin viivojen liian suurien pistemäärien estämiseksi. Yksi karkea tapahan olisi tehdä metsät siten, että vesistöviivat ja kartta-alueen reunaviivat toimivat metsärelaation ulkojäsenenä ja muut alueet sisäjäsenenä. Lappikaan ei ole ongelma sillä aineisto sisältää vektorimuotoisen rajan, jonka pohjoispuolella ei kasva varsinaista metsää.

18

Tuskin viivojen pistemäärä niin suuri ongelma on että siitä syystä aineistoa olisi pilkottu. Aineisto on vain haluttu jakaa karttalehtiin, ja viivat katkeavat siinä sivussa. OSM:in pisterajoitusta ajatellen tuo on tietysti hyvä.

Perinteiseen paikkatietokäyttöön suunnitellut ohjelmat selviävät hienosti suurestakin määrästä taitepisteitä. Tässä tilastoja OpenJUMP:in shapefile-lukijan optimointitesteistä viime viikolta.

200 Mb shapefile
containing : 221770 polygons
worst case : 287273 pts and 5484 holes

Tämä suurin geometria yksinään pitäisi jakaa OSM:ia varten aika moneen relaation osaan.
Ennen optimointia koko aineiston avaamiseen meni 41 sekuntia ja optimoinnin jälkeen 11 sekuntia. Tässäkin on vielä parantamisen varaa, sillä GDAL avasi saman aineiston neljässä sekunnissa. Toisaalta OpenJUMP:in koodi ei luota siihen, että shapefile on oikein kirjoitettu, vaan se tekee erinäisiä testejä selvittääkseen, mihin polygoniin mikäki rinkula kuuluu, ja onko rinkula ulkokehä vai sisäkehä.

Dataset : Current OJ code / 1st Martin’s optimization / 3rd Martin’s optimization / 1st+3rd
whole shapefile : 41 s / 24 s / 24 s / 11 s
worst polygon : 4.6 s / 0.16 s / 3.3 s / 0.13 s

OSM:in malli tukee hienosti talkoilla tehtävää kartan muokkausta ja se on tietysti pääasia. Ei silti haittaa tietää, miten valtavan iso hinta siinä maksetaan esimerkiksi juuri isojen polygoniaineistojen käsittelyn hitaudessa ja kömpelyydessä.

19

Tarkoitan sitä, että tietokanta on luotu ainoastaan kartantuotannon tarpeisiin. Esimerkiksi millään järvellä ei ole tietoa sen nimestä, vaan nimet on omia pistemäisiä kohteita, ja vielä niin että suomenkielinen ja ruotsinkielinen nimi on omia kohteita, eikä niillä muistaakseni ole edes mitään yhteistä id:tä tms. Ja kaikki kartalla näkyvät symbolit ovat omia pistemäisiä kohteita. Esim hautausmaa-alueen sisällä voi olla kymmeniä ristin kuvia omina pisteinään. Nykyäänhän alueet voisi automaattisesti täyttää vaikka pienillä svg-kuvilla.

20

Tuo on ihan totta. Jos OSM:ia ei olisi olemassa, niin juttu olisi voinut edetä niin, että jonnekin sivuun olisi syntynyt käyttäjien rakentama ja ylläpitämä ominaisuustietokanta, johon olisi koottu maastotietokannan kohteisiin liittyviä lisätietoja. Yhdistävänä tekijänä olisi ollut maastotietokannan kohteiden tunnisteet. Nyt tuo ominaisuustiedoilla rikastuttaminen tulee ilmeisesti tapahtumaan OSM:ssa. OSM:in tietosisältöön maastotietokantaa paremmin sopivia aineistoja olisivat mm. SYKE:n järvirekisteri ja uomarekisteri ym. ja mitä tiestöön tulee, niin tietysti Digiroad. Toivotaan, että nekin vapautuvat lähitulevaisuudessa.

Mitä järviin tulee, järvien nimet maastotietokannan nimipisteistä pitäisi olla aika helppo liittää järvipolygoneihin spatiaalisen liitoksen kautta esimerkiksi OpenJUMP:lla. Tuo kannattaa tehdä ennen mahdollista järvi-importtia. Suot varmaan hoituvat samalla tavalla.