Jos kaikki Suomen järvet multipolygoneiksi muuttuisivat

Jaahas, näköjään on wikissä multipolygon -keskustelusivulla sanottu niinkin, että multipolygon-relaation outer-polygonit eivät saa koskettaa toisiaan kuten inner-polygonit saavat. Onkohan tässä jotain tolkkua, ei minusta. Kts. http://wiki.openstreetmap.org/wiki/Talk:Relation:multipolygon - niinpä nuo tekemän Saimaa- ja Syväri -muutokset nyt eivät sitten ole tuolla keskustelusivulla kuvatun multipolygonin mukaisia.

Kirjoittelin ehdotuksen, että muutettaisiin niin, että myös outer-polygonit voivat koskettaa toisiaan. Paljon järkevämpi minusta noin, koska silloin karttaa voisi rakentaa polygoneilla ja piirtää pelkästään polygoneista kuten esim. GpsMid tekee, eikä koko maailman tarvitsisi opetella multipolygon-relaatioita kuten silloin jos isot järvet yhdistetään pätkityistä rantaviivoista kuten http://wiki.openstreetmap.org/wiki/Relation:multipolygon -sivun otsikon “Use case: Multiple ways forming a ring” alla kuvataan.

Mikäli lähdetään tuosta tulkinnasta että koskettavat outer-polygonit eivät ole sallittuja, sitten kai pitäisi Saimaan ja Syvärin suhteen joko a) palata tuohon “Use case: Multiple ways forming a ring” -tyyliin tai b) koodata niin, että kummallakin / jokaisella puolella keskeltä selkää olevaa katkaisuviivaa on oma relaationsa. Ainakin Syvärin tapauksessa jälkkimmäinen vaikuttaisi hiukan epäoptimaaliselta ja tarpeettoman mutkikkaalta. Saimaan tapauksessa useampi relaatio voi hyvinkin olla järkevää, sen verran paljon saaria siellä on.

Ahaa, alueiden meno useampaan multipolygoniin johtuu varmaankin siitä että en hoksinut noita poistella, kun yhdistelin rantaviivoja kehiksi. Ristiin menneitä rantaviivoja en ole huomannut enkä tietoisesti tehnyt, mutta aika paljon tuolla näkyi olevan samoissa kohdissa kahta rantaviivaa päällekkäin, noita olen tänäänkin poistellut.

OK, no sittenhän näiden pitäisi olla kaikkien sääntöjen mukaan ihan validia kamaa, vrt. edellinen viesti.

Tämä kaveri (Pietarista näköjään) joka tuon on tehnyt, taisi kirjoitella säikeessä http://forum.openstreetmap.org/viewtopic.php?id=7402 asiasta, kommentoin ja lähetin sinne luettelon multipolygon -relaatioista (reilu tuhat) joista Osm2GpsMid huomauttaa.

Kuopion tienoon Mapnik-Saimaa näyttää osittain korjaantuneen, mutta vielä on ainakin Kuopion keskustasta itään ja koilliseen neliö maa-aluetta paikassa jossa ei pitäisi, virhe esiintyy zoomilla 13 ja hiukan erilaisena zoomilla 12. Vähän etelämpänä Savolanniemien lähellä ongelmia zoomeilla 13-14.

Saimaa-korjauksia varten tässä vielä viimeöisestä geofabrik-kartasta (miinus se venäläisdata skelan scriptillä poistettuna) Osm2GpsMidin relaatiovalitukset ja ikiluuppivalitukset. Joku ainakin näytti olevan Saimaa-relaatioita.

Muoks: URLit korjattu.

Noita voi vilkuilla ja muokata OSM:ssä suoraan urleilla, osa ilmeisesti on jo korjattukin, mutta osa näyttää vielä virheelliseltä, esim. relaatio jossa ei outereita.

Break because of infinite loop for outline 57847008
see http://www.openstreetmap.org/browse/way/57847008
Break because of infinite loop for outline 23204766
see http://www.openstreetmap.org/browse/way/23204766
Break because of infinite loop for outline 57847008
see http://www.openstreetmap.org/browse/way/57847008
strange this outline is already triangulated ! maybe duplicate. I will ignore it
Way http://www.openstreetmap.org/browse/way/46589148
please see http://www.openstreetmap.org/browse/relation/365434
strange this outline is already triangulated ! maybe duplicate. I will ignore it
Way http://www.openstreetmap.org/browse/way/57849125
please see http://www.openstreetmap.org/browse/relation/404881
strange this outline is already triangulated ! maybe duplicate. I will ignore it
Way http://www.openstreetmap.org/browse/way/22945979
please see http://www.openstreetmap.org/browse/relation/404386
strange this outline is already triangulated ! maybe duplicate. I will ignore it
Way http://www.openstreetmap.org/browse/way/23540831
please see http://www.openstreetmap.org/browse/relation/163835
strange this outline is already triangulated ! maybe duplicate. I will ignore it
Way http://www.openstreetmap.org/browse/way/57731841
please see http://www.openstreetmap.org/browse/relation/405950
Relation has no outer member
see http://www.openstreetmap.org/browse/relation/405945I’ll ignore this relation
Relation has no outer member
see http://www.openstreetmap.org/browse/relation/405947I’ll ignore this relation
Break because of infinite loop for outline 57746082
see http://www.openstreetmap.org/browse/way/57746082
Break because of infinite loop for outline 26226532
see http://www.openstreetmap.org/browse/way/26226532
Break because of infinite loop for outline 26226532
see http://www.openstreetmap.org/browse/way/26226532
Break because of infinite loop for outline 26226532
see http://www.openstreetmap.org/browse/way/26226532
Break because of infinite loop for outline 31032510
see http://www.openstreetmap.org/browse/way/31032510
Break because of infinite loop for outline 57744338
see http://www.openstreetmap.org/browse/way/57744338
Break because of infinite loop for outline 57744338
see http://www.openstreetmap.org/browse/way/57744338
Break because of infinite loop for outline 57744338
see http://www.openstreetmap.org/browse/way/57744338
Break because of infinite loop for outline 57744338
see http://www.openstreetmap.org/browse/way/57744338
strange this outline is already triangulated ! maybe duplicate. I will ignore it
Way http://www.openstreetmap.org/browse/way/50834785
please see http://www.openstreetmap.org/browse/relation/405958
strange this outline is already triangulated ! maybe duplicate. I will ignore it
Way http://www.openstreetmap.org/browse/way/49991633
please see http://www.openstreetmap.org/browse/relation/405685
strange this outline is already triangulated ! maybe duplicate. I will ignore it
Way http://www.openstreetmap.org/browse/way/49991631
please see http://www.openstreetmap.org/browse/relation/405684
strange this outline is already triangulated ! maybe duplicate. I will ignore it
Way http://www.openstreetmap.org/browse/way/49991630
please see http://www.openstreetmap.org/browse/relation/405683
strange this outline is already triangulated ! maybe duplicate. I will ignore it
Way http://www.openstreetmap.org/browse/way/49991629
please see http://www.openstreetmap.org/browse/relation/405682

Saimaan korjaus jatkuu, nyt kaipaisi bulkki -päivitys -työkalua, ei jaksa potlatchilla tuhertaa kymmeniä järviä kerta toisensa jälkeen.

Partasensaaressa olevat järvet ovat relaatiossa 484882, http://www.openstreetmap.org/browse/relation/404882 ja pitäisi olla ymmärtääkseni relaatiossa 404881. Osaako joku neuvoa mallia tuollaisen relaation päivityssyntaksista ja työkalusta jolla se tungettaisiin OSM:ään? Scriptin jolla muunnan tieluettelon päivityksiksi varmaan saisin sitten aikaiseksi.

Muoks: Josmillahan tuo sujui kätevästi.

Luen tuon vain niin että peräkkäisistä outer- ja inner-jäsenistä pitää peräkkäin liitettynä muodostua suljettuja polkuja. Villeimmät (saksalaiset) tekevät multipolygoneilla esim. metsiä viereisten peltoalueiden reunojen osista, eikä itse tapaa ole torjuttu “viallisena multipolygonina”, vain tarpeettoman hankalasti ylläpidettävänä ja muiden muokkaajien työtä vaikeuttavana.

Jos ei siellä järven selällä mitään rajaa ole…

Osm2GpsMidin huomautuksista: Nimellä Puula on toinen kahdesta hyvin samannnäköisestä relaatiosta:

http://www.openstreetmap.org/browse/relation/443975
http://www.openstreetmap.org/browse/relation/405685

Muoks: vastaava skela / Caballista -tuplarelaatio on myös:

http://www.openstreetmap.org/browse/relation/443971
http://www.openstreetmap.org/browse/relation/405682

No eipä sieltä järven rannastakaan paaluja löydy 2000 tai 500 OSM-pisteen välein, aivan verrannollinen asia.

Jos piirretään polkujen yhdistelmänä niin kaikki viivat kulkevat rantaviivaa pitkin eikä tule ylimääräisiä viivoja, kuten käy tapauksessa että muodostetaan polygoneiden yhdistelmistä.

Polkujen yhdistelmästä on helppoa tehdä yksi iso polygoni. Polut vain laitetaan peräkkäin. Sen sijaan polygonien tapauksessa pitää alkaa etsimään päälekkäisiä viivoja ja pilkkomaan polygonit osiin. Tämä on huomattavasti raskaampi laskentaoperaatio.

Esimerkiksi peruskartassa on piirettynä korostukset rantaviivoihin hahmottamisen helpottamiseksi.

Myös rantaviivan pituus on kiinostava tieto, vaikka kartoitus tarkkuus vaikuttaakin siihen.

JOSMilla se onnistuu melko mukavasti. Lataat vain CTRL-L http://api.openstreetmap.org/api/0.6/relation/404881/full ja CTRL-L http://api.openstreetmap.org/api/0.6/relation/404882/full (484882 oli jotain vallan muuta). Sitten vain valitset alueen, etsit valinnasta “type:way” ja vähennät alueesta ylimääräisiä alueita suorakaidevalinnalla CTRL-näppäin pohjassa. Sitten lisäät tai poistat alueita relaatioista. Välillä valitset relaation kaikki jäsenet, zoomailet ympäriinsä (myös “zoom to selection”) ja katsot, että inner-jäseniä on juuri oikea määrä. Lopuksi poistat relaatioon kuuluvat saaret muista relaatioista nappia painamalla. Ja ihan lopuksi varmistat, ettei validator huomauta mitään, ennen kuin lähetät muutokset.

Tuo mainitsemasi virhe oli helppo korjata. Aamupäivän korjauksiin meni enemmän aikaa, kun siirtelin kymmeniä polkuja oikeisiin relaatioihin ja jouduin jakamaan relaatioita osiin, niin että tuli yksi multipolygon-relaatio kutakin outer-aluetta kohden.

Minunkin mielestäni outer-viivojen piirtäminen polygoneiksi on ongelmallista. Rantaviivan pituuden laskentaa voisi ehkä helpottaa merkitsemällä keskellä järveä olevat mielikuvitussolmut jotenkin, jolloin kyseisiin solmuihin kytketyt viivanpätkät jätettäisiin laskematta. Mutta sekään ei auta siinä tilanteessa, että järven lahti tai selkä on katkaistu omaksi natural=water-alueekseen siten, että viiva kulkee vain rannalla olevien pisteiden kautta.

Eikö sitä gpsmidiä voisi opettaa ymmärtämään multipolygoneita? mkgmapin multipolygon→polygon-käännös toimii hyvin.

Voisitko pitää pari päivää taukoa tuosta pilkkomisesta, niin että saan jäljellä olevat virheet korjatuiksi ja voin päivittää toimivan kartan?

Rantaviivan suuntaa-antava pituus tosiaan on jossain määrin pätevä peruste rantaviivanpätkistä koostuvan relaation puolesta, tosin ei nyt ehkä kovin painava, kun rantaviivan pituus riippuu tosiaan kokolailla siitä kuinka tarkasti mutkia on seurattu.

Toisaalta, mikäli kartanpiirron tyyli on sellainen kuin järvillä usein on, että on sinistä ilman sen kummempia reunoja, ei ole mitään tarvetta etsiä päällekkäisiä viivoja tai yhdistellä polygoneja, vai kuinka? Polygonien pilkkomiseen ei kai ole tarvetta, rantaviivan pilkkominen päällekkäisten viivojen etsimiseksi tosiaan olisi tarpeen jos tyyliin kuuluu erityisesti merkitty ranta.

Jotenkin tämä esim. Saimaan kartoittaminen advanced multipolygonilla rannanpätkinä tuntuu hiukan nurinkuriselta. Jos >2000 pisteen polku on liian pitkä ja raskas käsitellä verkkoliikenteen ja työkalujen kannalta, niin ei kai nyt aivan ongelmaton ole satojen kilometrien mittainen rantaviiva yhtenä multipolygonina ole sekään - siis kun huomioidaan, että samaan relaatioon laitetaan koko pitkän rantaviivan sulkemina olevat monilukuisat saaret.

No, tietysti ei ole pakko käsitellä koko multipolygonia kerralla (vai onko?), siinä mielessä tilanne on erilainen.

Mutta jos ja kun esim. tuolla 2000 pisteen rajalla tavoitellaan käytännön syistä kerralla käsiteltävän monimutkaisuuden vähentämistä ja asioiden osiin jakamista, kyllähän ainakin Saimaa lukuisine saarineen lienee toivottavaa ja ilmeisesti käytännön pakko jakaa useampiin multipolygoneihin kuten on nyt tehty.

Siinä vaiheessa taas kun järvi on jaettu useampiin multipolygoneihin, tulevat esille multipolygonien rajoilla nuo aivan samat ongelmat liittyen rantaviivan pituuteen, ylimääräisiin viivoihin ja piirtotyylin mahdoliseen rantaviivan korostamiseen kuin toisiinsa rajoittuvissa polygoneissa yhden multipolygonin sisälläkin. Eli noista ongelmista ei pääse eroon pilkkomalla rantaviiva osiin, koska jos halutaan pitää yhden järvi/järvenosarelaation sisältämä datamäärä kohtuuden rajoissa, pitää yhdessä relaatiossa olevan datan määrää rajoittaa eli aluetta rajata. Ja kun rantaviivan pituus ja rannan tyyli tulevat joka tapauksessa vastaan, tällöin minusta ainakin järvien suhteen jakaminen toisiinsa rajoittuviin monikulmioihin saman relaation sisälläkin vaikuttaisi järkevältä, etenkin kun huomioidaan että toisiinsa rajautuvat inner-relaatiot ovat jo nyt sallittuja.

Jossakin muussa asiassa taas kuin Suomen järvissä toki tuollainen multipolygon joka koostuu polunpätkistä voi olla hyvinkin järkevä, tulee mieleen esim. hallinnolliset rajat. Muoks: Lisäyksenä tähän, monissa muissa tägeissä irralliset polunpätkät ovat sallittuja ilmankin relaatioita toisin kuin natural=water:issa.

Kiitos JOSM-vinkeistä, täytyy vilkaista taas JOSMia tarkemmin, näyttää kehittyneen sitten viime näkemän. Löysin mielestäni helpon tavan tehdä homma JOSmilla, eli avasin ensin sen 2-loppuisen relaation, josta siirsin valintaan relaatiossa olevat polut. Sitten avasin 1-loppuisen relaation, jonne siirsin valinnasta nuo polut. Sitten takaisin 2-loppuiseen, josta poistin valitut relaatiot. Aika kätevää leikkaa-liimausta eikä mitään tarvetta zoomailuun tms. virhealttiiseen visuaaliseen juttuun ollut, eli varsin kätevästi toimi bulk-siirtona.

Voihan sen toki opettaa ymmärtämään myös rannoiltaan pätkittyjä multipolygoneja, mutta jotenkin noiden runsassaaristen järvien osalta on vaikea nähdä mitä etua rantaviiva-multipolygoneista olisi verrattuna kehältään yhtenäiseen multipolygoniin. Jollakin toisalla datalla tilanne voi olla tietysti toinen.

Juu, tauon aloitinkin jo, ja nyt olen minäkin korjaillut noita saaria oikeisiin relaatioihin, joka kyllä potlatchilla oli turhan työlästä, tuolla josmin leikkaa-liimaa -systeemillä menisi kätevämmin.

Saattoi löytyä syy ongelmaan Kuopion keskustasta koilliseen olevassa mapnik-kartassa, saaressa http://www.openstreetmap.org/browse/way/57742174 oli pieni järvi, jonka ilmeisesti pitää olla osa relaatiota.

Olisiko paikallaan koota Suomen vesistöjen suositeltavia ja toimivia merkintätapoja wiki-sivulle, sopisiko esim. http://wiki.openstreetmap.org/wiki/Fi:WikiProject_Finland ?

Sinne voisi kirjata esim. saarten merkintätavasta, isojen järvien merkintätavoista ja multipolygoneista jne. Esim. Saimaan saaret on tägätty tyypillisesti place=island, ei natural=land, niin kumpiko nyt sitten on fiksumpi vai pitäisikö olla peräti molemmat? Ja minkä kokoisille place=islet?

Relaation osana olevassa saaressa olevat järvet (natural=water) jotka eivät ole osa relaatiota, näyttävät aiheuttavan ongelmia ainakin mapnikissa ja gpsmidissä - vesi tulvii niin että saari katoaa ja ympäristö muuttuu maa- tai vesialueeksi, kartta mahdollisesti muutenkin menee sekaisin.

Näyttää korjaantuvan, kun laitetaan kaksi relaatiota jossa saaren rajat ovat place=island -relaatiossa outer-roolissa, ja samaan aikaan järvirelaatiossa inner-roolissa, näyttää homma toimivan. Vrt. kartalla kohta http://www.openstreetmap.org/edit?lat=61.6762&lon=27.8755&zoom=13 joka näkyy mapnikissa http://www.openstreetmap.org/?lat=61.6762&lon=27.8755&zoom=13 tätä kirjoittaessani virheellisesti, ilmeisesti siksi koska saaressa olevat järvet eivät olleet osa relaatiota.

Jos nyt hetkeksi unohdetaan tuo “natural=coastline ei järviin” -vaatimus (jolle jossakin taidettiin lukea poikkeus juurikin suurien järvien osalta), niin yksi mahdollinen tapa kunnioittaa sekä natural=water:in kehävaatimusta että “ei rajoja keskellä järvenselkiä -sääntöä” on olemassa:

  • merkataan multipolygon-relaatio natural=water

  • mikäli järven tai saaren ranta ei sovi 2000 pisteeseen eli rannasta ei voi tehdä kehää, merkataan rannanpätkät natural=coastline

  • relaatio kokoaa järven rannat ja saaret niin, että outer-roolissa ovat joko natural=coastline -pätkät tai natural=water -kehä ja inner-roolissa niinikään saarien natural=costline-pätkät tai natural=water -kehä

Tämä tosin tekisi esim. Saimaasta varsin mammuttimaisen relaation, ja tuollainen natural=coastlinen ja natural=water:in jako ei tunnu oikein siistiltä. En tiedä toimisiko tuollainen käytännössä, että tägi pitäisi valita sen mukaan käsitelläänkö polkua itsenäisenä vai relaation osana.

Tällä tietoa taidan olla sitä mieltä että isojen järvien jakaminen eri multipolygoneiksi kuitenkin pienempi paha kuin natural=coastlinen ja natural=waterin sekoittaminen esim. saman järven alueella.

Eilisen päivän OSM-datalla järvet käyttäytyvät nyt oikein hienosti. Saimaalla tosin maa ja vesi vaihtavat paikkaa parilla isolla alueella Lappeenrannan ja Imatran välillä kun vie tiedot tietokantaan osm2pgsql:llä, mutta suurin osa Saimaastakin siirtyy hienosti. Saaret ovat reikinä polygoneissa. Jos niistä haluaa myös omat saaripolygoninsa, niin se toimii ainakin silloin, kun saaren rantaviiva sulkeutuu ja sille on annettu natural=land. Päijänne taitaa olla viimeinen natural=coastline -järvi. Sain senkin esille muuttamalla ensin finland-osm -tiedostosta natural=coatlinen natural=rantaviivaksi, ja muodostamalla sitten Päijänteen rantaviivan pätkistä alueen OpenJUMP:illa. Mutta kai se Päijännekin kannattaisi muuttaa järveksi jo OSM:in puolella.

Kuopio näyttää vielä tulvivan Osmarenderissä, mutta Mapnik on tietääkseni koko ajan näkynyt oikein, ja nyt (ehkäpä umpinaisten natural=water-polygonien ansiosta) OpenCycleMap:kin näyttää melko hyvältä (saaria puuttuu). Voin muuttaa sen muutaman viikon kuluessa, ellei kukaan muu ehdi ensin. Se käy aika näppärästi lataamalla finland.osm.bz2, ottamalla siitä pelkkä natural=coastline ja lataamalla tiedosto JOSMiin. Tällaista Osmosis-komentoa olen käyttänyt:

osmosis --rx finland.osm.bz2 --tf accept-ways natural=coastline --used-node --wx finland-coastline.osm

Pientä häikkää on vielä Mapnikin puolellakin Kuopion keskustan lähellä Saimaassa, kts. outo kolmio zoomilla 14 http://www.openstreetmap.org/?lat=62.8399&lon=27.741&zoom=14

Kolmion vaakasuora viiva näyttäisi olevan karttapalan raja. Virhe on siis palasessa http://c.tile.openstreetmap.org/14/9454/4488.png, jossa näkyy liian vähän vettä. Muut tarkkuudet näyttävät hyviltä, jos unohdetaan se kauneusvirhe, että Mapnik piirtää erillisten natural=water-polygonien väliin viivan. Kolmion viisto viivahan on käsittääkseni tekosiasi.

Kolmion viisto viiva on tosiaan relaation raja. Näyttää siltä, että tässä voisi olla kyse ongelmasta nimenomaan tuollaisen kahden vierekkäisen vesi-relaation aiheuttamana, siis että Mapnik ei tuollaista hahmota kuten kartoittaja. Eli kun tuo palanen on tyhjä relaation rajalta vasemmalta yläpuolelta, epäilen, että Mapnik laskee, että vasen yläkulma on maata, koska rajoittuu veteen. Maa näyttäisi sitten leviävän myös viereiseen vasemmanpuoleiseen ruutuun.

Mitenkäs tässä nyt sitten yleinen näkemys tai jonkinasteinen konsensus menee noiden järvenselkää halkovien relaatioiden jakoviivojen osalta? Ovathan ne tietysti ongelmallisia kuten esim. tästä tapauksesta nähdään. Mutta jos esim. tuossa tapauksessa järven jakaminen keskeltä selkää on paheksuttavaa, ja toisaalta mammuttirelaatioita (koko Saimaa) ei voi myöskään hyväksyä, niin mitä jää jäljelle? Natural=coastline? Mutta siinä kuitenkin näyttäisi jonkinasteinen konsensus asettuneen niin, että natural=coastline ei oikein mielekäs järville ole.

Ajan tässä takaa oikeastaan sitä, että jos jonkinlainen hyväksyntä tuollaiselle järven jakamiselle keskeltä selkää on olemassa, niin olisi varmaan paikallaan tehdä esim. feature requestia tuosta kohdasta Mapnikin toiminnan osalta, että Mapnik osaisi tuon piirtää oikein, ja samalla voisi varmaan tuosta kauneusvirheestä pistää tietoa ja feature requestia, että jatkossa Mapnik piirtäisi yhtenäisen vesialueen. Jos taas on jokin muu vähemmän huono tapa kartoittaa Saimaa joka esim. toimisi Mapnikin kanssa jo nyt, niin ehkä kannattaa käyttää sitä mieluummin kuin ehdottaa muutoksia Mapnikiin.

Minun mielestäni Saimaan jakaminen erilliseksi multipolygoneiksi on vähiten huono esillä olleista, ja asiasta kannattaisi pistää feature requestiä tai bugiraporttia Mapnikin kehittäjille, että tuokin kohta alkaisi näkyä oikein.

Muoks: Multipolygonien yhdistäminen kartta renderöidessä voi olla aika työläs homma ohjelmoida ja raskas prosessoida ilman, että datassa on joku tieto siitä että tällä multipolygonilla on naapuri joka pitäisi esittää saumattomasti tämän kanssa. Tein ehdotuksen tuollaisen tiedon merkkaamiseksi, kts. http://wiki.openstreetmap.org/wiki/Talk:Relation:multipolygon#Issues_rendering_adjacent_multipolygon_relations_in_large_lakes