Tänään tekemälläni Garmin-kartalla on ensi kertaa lähes toimivat vesialueet. Karjalassa vielä tulvii, mutta yritän saada sen korjatuksi tavalla tai toisella.
Olen muutellut jäljellä olevia natural=coastline-alueita multipolygon-relaatioiksi. Päijänteen ja Pielisen jätän vielä rauhaan, mutta tarkoitukseni on muuttaa kaikki niitä pienemmät järvet. Rantaviivat olen ladannut JOSMiin seuraavasti:
Sitten olen avannut JOSMiin uusia karttatasoja alueiden lataamista ja muutosten tekemistä varten. Seuraavan päivän finland-coastline.osm on aina ollut hieman edellistä pienempi.
Nyt Garmin-kartallani näkyy Suomenlahden ja Perämeren ranta, eikä Kaakkois-Suomikaan enää tulvi. Päijänne ja Pielinen sekä jotkin länsirannikon pikkulätäköt näkyvät kauempaa kuin muut järvet, koska ne on merkitty merialueiksi (natural=coastline).
Aion lähiaikoina muuttaa länsirannikon natural=coastline-järvet natural=water:eiksi, ellei kukaan muu ehdi ensin. (Ehkä joku osaa tempun, jolla voi valita pelkät natural=coastline-järvet, ei siis saaria eikä avoimia rantaviivoja.) Sitä ennen teen työkalun, jolla pystyn JOSMissa valitsemaan länsirannikon rantaviivan.
Voin muuttaa myös Päijänteen ja Pielisen multipolygoneiksi, jos enemmistö on sillä kannalla.
Mielellään ei, ja parempi olisi jos kaikki nuo isot järvet muutettaisiin takaisin coastlineksi. Ei nimittäin ole mitään järkeä pilkkoa isoa järveä mielivaltaisesti osiin, kuten olet nyt tehnyt, vaan näissä tapauksissa coastline on ainoa järkevä tapa merkitä kyseinen järvi. Eihän järvissä mitään rajoja kulje keskeltä selkiä, vaan kyseessä on yksi yhtenäinen vesialue joka tulisi sellaiseksi merkitä vakiintuneiden käytäntöjen mukaan.
Joissain järvissä (kuten Saimaa) on kyllä tasoeroja, jotka muodostavat “rajoja”, mutta näissäkin tapauksessa virtapaikat tulisi merkitä esimerkiski riverbankeiksi. Näin muodostuu pienempiä alueita, joiden kohdalla voi erikseen katsoa onko järkevää tehdä kyseinen alue coastlinenä vai multipolygonina.
Myöskään siinä ei ole järkeä että isot järvet pistettäisiin yhdellä relaatiolla kuten Inarinjärvi nyt on, sen relaatiossa kun on yli 700 jäsentä, ja jos sitä yrittää esimerkiksi JOSM:lla ladata, kuluu siihen kymmeniä minuutteja. Nuo isot relaatiot myös pakottavat käyttämään wireframe-tilaa koska rendauksessa kestäisi muuten niin kauan, että datan selauksesta, editoimisesta puhumattakaan, ei tule yhtään mitään.
Coastlinenä merkityt vesialueet pystytään ohjelmallisesti kyllä yhdistämään polygoneiksi, eihän niitä muuten pystyttäisi edes renderöimään! Katsokaa esimerkkiä vaikka coastcheck-työkalusta jolla luodaan Mapnik-tason käyttämät polygonit coastlineistä. Myös osmarendererin close-areas.pl:stä ja multipolygonien rendauksesta sekä osm2pgsql:n multipolygonien yhdistelystä löytyy vinkkejä mahdollisiin toteutuksiin.
Coastcheck on myös jonkinverran vikasietoinen, se osaa yhdistää rantaviivan jos siinä on pieni katkos jolloin ei tule sitä ongelmaa että pieni epäjatkuvuus rikkoo koko järven (tai jopa meren!) rendauksen. Se myös pilkkoo automaattisesti luodut polygonit ennalta määritellyn kokoisiksi paloiksi, joka helpottaa niiden käyttöä rendauksessa ja isompien virheiden kohdalle sattuessa ei riko koko vesialuetta, vaan pelkästään tämän yhden palan alueen.
Myöskin tuo extractin datan puutteellisuus voidaan ottaa huomioon: Työkaluun tulee vain lisätä toiminto jossa sille syötetään alueen bbox, jolloin se voi ottaa huomioon miten rajalle päättyvä coastline tulisi jatkaa jotta muodostuisi suljettuja alueita. Tämä on käytännössä täysin sama asia mitä osmarendererin close-areas.pl jo nyt tekee, bbox on siinä tapauksessa vain yksi z12 -tile.
Mikään ei myöskään pakota käyttämään Geofabrikin extractia (joka muuten ei edes sisällä koko Suomen dataa, erittäin epätarkan bounding polygonin takia!), vaan on myös muita extracteja, ja sellaisen voi myös itse tehdä planet.osm:sta (tai esimerkiski jostain valmiista Euroopan extractista).
Käytän JOSMia muokkaamiseen. Suurten relaatioiden lataaminen voi kestää minuutteja, mutta ei kai sentään kymmeniä? Joitakin viikkoja sitten JOSM piirsi suuret multipolygonit erittäin hitaasti (näyttö jäi jumiin ehkä minuutiksi), mutta vika on sittemmin korjattu.
Miksi suurten alueiden pilkkominen hallittavamman kokoisiin osiin on mielestäsi ongelmallista? Onhan teidenkin pilkkominen sallittua ja jopa suotavaa. Miksi alueet tekisivät poikkeuksen? Monien pitkien jokien waterway=riverbank on piirretty useana vierekkäisenä alueena, ja osassa on saaria multipolygon-relaatiossa.
Päijänteen vesistön natural=coastline sisältää muuten joitakin pikkujärviä. Erotin siitä Arrajärven ja pätkän Kymijokea muutama päivä sitten.
Tällä välin mkgmapin multipolygon-koodi on kehittynyt sen verran, että generate-sea toimii. Geofabrikin karttaleikkeen puutteet korjasin poistamalla siitä osittain latautuneet saaret ja siirtämällä rantaviivan laitimmaiset latautuneet pisteet kartta-alueen rajoille. Ruotsin rajalta Itämeri jatkuu Garmin-kartallani siis suoraan länteen, tukevasti kuivalle maalle saakka, ja Venäjän rajalta Suomenlahti jatkuu suoraan etelään. Karttani kannalta on nyt siis lähes yhdentekevää, kuinka suuret järvet on merkitty. Kuitenkin wikin mukaan natural=coastline on tarkoitettu vain merialueille, eikä järvien tai lahtien nimiä ole helppo istuttaa coastlineihin.
Jos Mapnikin meren piirtämistä käytetään esimerkkinä, niin melkoinen vippaskonsti sekin on. Siinähän luodaan maapolygonit käyttämällä rajoina toisaalta coastline-viivoja, toisaalta kartan päälle laitetun kuvitteellisen hilan viivoja. Mapnik-kartassa on alimmaisena pohjaväri (merensininen), sen päällä coastlinesta kehitetyt maapolygonit (vaaleat), ja sitten niiden päällä kaikki muut tasot. Tästä syystä coastline-systeemillä tehtyjä järviä ei saa valmiina mistään jakeluista. Mapnikin maapolygoneista järvet voi toki muodostaa ottamalla kaikki järven rantaviivalle sattuvat maapolygonit ja erottamalla jollain viekkaalla systeemillä niiden sisään jäävä, ei maata oleva, alue järveksi. Olen kyllä lukenut, että joku on keikauttanut maapolygonityökalun ympäri ja tehnyt siitä vesipolygonityökalun. Ylen hankalaa joka tapauksessa. Järvien merkitseminen coastline:lla on silkkaa tagien laittamista renderöintiä ja muokkausohjelmia varten, mutta ehkä sitä on pakko käyttää, jos muut, kenties periaatteen kannalta paremmat systeemit hankaloittavat muokkaamista liikaa. Jonkun kyllä pitäisi tehdä Mapnikin maapolygoneja vastaava ulkoinen kartta-aineisto Suomen järvistä, jossa olisi ihan tavallisina GIS-polygoneina kaikki vedet, olivatpa ne sitten emo-OSM:ssa merkitty tagilla coastline:ksi, water:ksi tai riverbankiksi. OSM kun ei taida koskaan taipua käyttämään sisäisesti erityisiä aluekohteita tai karttatasoja.
Kuinkahan se mahtaisi onnistua? Kun Osmosis katkaisee viivan, se ei ainakaan oletusarvoisesti lisää leikkauskohtaan pistettä. Siksi leikkauskohta on hyvin epämääräinen. Mistään ei voi jälkikäteen tietää, kuuluisiko leikkausviivan lähellä päättyvän viivan jatkua leikkausviivalle saakka ja mihin pisteeseen siellä.
Nyt Geofabrikin finland.osm.bz2 sisältää kaikki rajat eikä sisällä osittaisia natural=coastline-saaria eikä multipolygoneja. Jotkut saarettomat järvet vielä katkeavat hieman Suomen nykyisen itärajan itäpuolella, mutta johonkin se raja on pakko vetää. Muutaman muokkauskierroksen tämä tietysti vaati.
Vai ymmärränkö nyt jotain väärin, ja pitäisikö ei-suljettujen rantaviivan pätkien kuitenkin olla sallittuja osana multipolygon-relaatiota? Jos ymmärrän oikein, tässä voi tietysti tulla API 0.6:n myötä ongelma, että yli 2000 pisteen järvien rantoja ei voi piirtää yhtenä alueena. Mutta kaipa nuo sitten voisi piirtää useammasta suljetusta monikulmioista koostuvina vesialueina, eikös tämä ikäänkuin ole multipolygon -relaation idea ainakin nimen perusteella pääteltynä?
Muoks: Toisin kuin natural=water -tagin kuvaussivu, Multipolygon sallii useammasta erillisestä polunpätkästä (eli rantaviivanpätkästä) koostuvan renkaan, kts. myöhemmät viestit.
Minulla ei oikeasta toimintatavasta ole järin vahvaa mielipidettä suuntaan eikä toiseen ja asia on uusi minulle, mutta jotain tuntuu olevan pielessä jossain, kun esim. Kuopion tori tulvii niin Osmarenderissä kuin GpsMidissä, ja tulvimista ilmeisesti esiintyy myös Garminissa ajoittain. Ymmärtääkseni järvien pilkkominen monikulmioiksi - jotka yhdistyvät toisiin keskellä selkää kulkevien mielivaltaisten rajojen kautta - saattaa auttaa tässä esimerkiksi sillä tavalla, että pienempiä alueita kerrallaan käsittelevässä ohjelmassa homma alkaa toimia. Eihän niiden karttadatassa olevien mielivaltaisten rajojen tarvitse millään tavalla näkyä käyttäjälle piirretyissä kartoissa, paitsi tietysti muokkaustilassa.
Toisaalta myös on niin, että tähän mennessä eteeni tulleen tiedon perusteella äkkipäätä ajatellen API 0.6:n myötä tehty päätös rajata muokkaukset 2000 pisteeseen ja linjaus, että natural=coastline:a ei käytetä järviin (esim.http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline ) ovat ratkaisseet asian niin, että isot järvet pitää jakaa keskeltä selkää mielivaltaisesti, olettaen että multipolygin pitää koostua nimensä mukaisesti polygoneista. Mutta voi tietysti olla niin, että minulta on jäänyt jotain huomaamatta asiassa ja asia onkin toisin.
“This tag can be placed on an area (i.e. a closed way) for a simple lake,”
ja
"1. Draw or select a closed way around the perimeter of the lake. "
Ensimmäisen lainauksen jatko jättää hiukan tulkinnan varaa, kun jatkuu:
"This tag can be placed on an area (i.e. a closed way) for a simple lake, or it can be placed on a Relation:multipolygon if the lake either contains islands or has a large coastline (but not big enough for natural=coastline). "
tämän perusteella voisi arvella, että myös rantaviivan pätkä voi olla osa relaatiota, mutta tuon toisen lainauksen (otsikon “Creating islands in lakes”) kohta:
"1. Draw or select the way around the perimeter of the lake. "
jonka “the way” kyllä näyttää selvästi viittaavan siihen, että järven rannan pitää kiertää koko järvi ympäri.
“In short, a multipolygon relation can have any number of ways in the role “outer” (the outline) and any number of ways in the role “inner” (the holes), and these must somehow form valid rings to build a multipolygon from.”
… eli multipolygon-relaation osien pitää olla kehiä.
Tämän perusteella katsoisin, että järvenrannat tulee muodostaa kehiksi, ja mikäli 2000 pisteen raja (API 0.6) kehässä tulee vastaan, pitää käyttää multipolygon -relaatioita. Ja Keep Right kaiketi toimii kuten pitää.
Muokkasin Saimaa-relaation 405960 (http://www.openstreetmap.org/browse/relation/405960 ) sellaiseksi kuin ymmärtääkseni relaatioiden pitäisi olla, eli polygoneista koostuvaksi. Näyttäisi onnistuvan potlatchilla - pientä bugitusta ilmeni jossain kohdassa ja rantaviivaa katosi, mutta näytti siltä että sain korjattua.
Nyt en kyllä ihan hahmota, miksi OSM:ssä on useampia Saimaa -multipolygon -relaatioita, esim. Kuopiosta luoteeseen relaatio 405925. No, aika paljon inner-tavaraa (ilm. saaria) on esim. tuossa 405925 -relaatiossa, ehkä tuossa tulee joku raja vastaan kuinka suuria relaatioita voi tai kannattaa olla. Mutta tulee mieleen, että jos joku navigaatio-ohjelma hakee relaatioiden nimistä, miten se mahtaa näyttää löytämänsä useamman Saimaa -relaation.
Määrittelin tosiaan Saimaan monena erillisenä multipolygon-relaationa, koska koko järven saarineen käsittävän relaation lataaminen voisi kestää kymmeniä minuutteja. Se saattoi olla virhe, sillä aika ajoin joku on lisännyt saaria väärään relaatioon. Mutta ei relaation jakaminen osiin ole aivan tavatonta. Bussireittirelaatioissa näyttäisi olevan suositeltava käytäntö tehdä kummastakin suunnasta oma relaatio. Esimerkiksi HSL-linjoilla 731 ja 742 on mahdollista istua kyydissä koko kierros Helsingistä Helsinkiin, mutta jaoin ne silti kahtia käyttäjän Daeron ehdotuksesta.
Tänään nimesin kokeeksi Päijänteen rantaviivan (natural=coastline) määrittelemättä relaatiota. Jos monen relaation Saimaa aiheuttaa ylitsepääsemättömiä ongelmia, niin eiköhän ne voi räjäyttää takaisin natural=coastlineksi.
Juu, voi olla useampi relaatio on järkevää että pysyy kerralla käsiteltävä datamäärä kohtuullisena, tuli vain mieleen tuo, että voiko siitä tulla ongelmiakin. Mutta ei välttämättä, kyllähän navigaattorille lienee fiksua osata käsitellä tuollaisiakin.
Työstin Saimaata ja sen seudun vesistöjä ja saaria monikulmioiksi toiveena, että tulviminen mm. Kuopion keskustaan lakkaisi gpsmid:issä ja osmarenderissä. GpsMidin suhteen näyttää toimivalta, mutta Osmarenderin suhteen ei oikein onnistu esim. Syvärin suhteen, oudosti leviää yhteen Syvärin ruutuun vesi. Mahtaako olla joku bugi osmarenderissä vai eikö vain osaa pureksia vierekkäin olevia vesialueita.
Tuli vastaan aika paljon kahdesti samassa paikassa olevaa rantaviivaa, joka aiheuttanee oman osansa tulvimisongelmasta. Poistelin noitakin.
GpsMid ei ainakaan toistaiseksi ymmärrä multipolygon -relaatiosta mitään, mutta piirtelee silti järvet ja niissä olevat saaret aivan mallikkaasti, kunhan järvi koostuu yhdestä tai useammasta suljetusta alueesta. Ei osaa käsitellä rantaviivanpätkiä. Sivumennen, ei myöskään natural=coastlinen perusteella osaa värittää vettä siniseksi.
Ilmeisesti rantaviivanpätkistä koostuvia järviä on suht paljon Suomen OSM-kartalle.
Potlatchissa on ilmeisesti jokin bugi joka silloin tällöin heittää rantaviivanpätkiä pois. Tämän vuoksi aaattaa olla Saimaassa jotain pielessä ajoittain, eiköhän se tuosta.
Monien järvien rantaviiva on jaettu enintään 500 pisteen mittaisiin pätkiin. Ellen väärin muista, niin osa niistä oli määritelty multipolygon-relaatioiksi jo ennen minun sotkeutumistani asiaan. Käsittääkseni yhdessä viivassa saa olla enintään 2000 pistettä. Jossain (ehkä Venäjällä rajan tuntumassa) olen nähnyt myös 999 pisteen mittaisia viivoja.
Tällä hetkellä ainoa natural=coastline-muotoinen järvi on Päijänne. Jonkin verran nakersin siitä järviä ja vesiväyliä, mutta edelleen alue on sen verran iso, että se pitäisi jakaa moneksi multipolygon-relaatioksi.
Mistä muodosta GpsMid mahtaa karttoja näyttää? Ei kai sentään suoraan XML-puusta? Jos siinä on jokin valmiiksi pureksittu muoto, niin multipolygonit voisi pureksia polygoneiksi, niin kuin mkgmap tekee. Joka tapauksessa siitä voisi saada valmista Java-koodia.
GpsMidissä on oma binäärinen pakattu karttaformaatti ja “kääntäjä” joka muuttaa XML:n sisäiseksi formaatiksi, eli Osm2GpsMid -java-ohjelma syö sisään OSM-aineiston, parsii XML:n ja toisesta päästä tulee ulos tiedostokokoelma bundlattuna jarriin jossa myös itse GPsMid on. Kartta on pilkottu erilaisiksi tiiliksi, reititys ym.
Niin siis eihän niitä multipolygoneja tarvitse lainkaan pureksia polygoneiksi, vaan homma on siinä mielessä alaspäin yhteensopiva, että kun multipolygon koostuu polygoneista, niin GpsMid sitten käsittelee polygonit aivan normaalisti relaatioista mitään ymmärtämättä ikäänkuin erillisinä järvinä jotka vain sattuvat olevan yhdestä rannanosasta toisessa järvessä kiinni. Tämän vuoksi homma pelittää mukavasti, vaikka Osm2GpsMid ei tee multipolygoineilla muuta kuin laskee ne. Enpä tiedä olisiko tuosta multipolygonin ymmärtämisen lisäämisestä GpsMidiin nyt erityisemmin muuta hyötyä kuin että saisi järville nimet jos ei noissa polygoneissa satu olemaan.
Näköjään Osm2GpsMid sai tänään tulokseksi, että multipolygoneja on Suomen kartalla 1057, ylivoimaisesti eniten GpsMidille tuntemattomista relaatioista. Kakkosena on “route” 810, kolmosena “boundary” 297 ja kolmosena “surveillance” eli ilmeisesti valvontakamerat, 237.
Muoks: Laitanpa alle Osm2GpsMidin “tilasto/info”-tulostuksen, huomauttelee esim. kartalla olevista virheistä, josko joku vaikka tuon perusteella innostuisi korjaamaan.
OSM XML parser with bounds started…
Start of Document
Nodes read/used, Ways read/used, Relations read/partial/used
Nodes 674587/674587, Ways 0/0, Relations 0/0/0
Nodes 1327852/1327852, Ways 0/0, Relations 0/0/0
Nodes 2150432/2150432, Ways 0/0, Relations 0/0/0
Nodes 3100952/3100952, Ways 0/0, Relations 0/0/0
Nodes 4024238/4024238, Ways 0/0, Relations 0/0/0
Nodes 4956283/4956283, Ways 0/0, Relations 0/0/0
Nodes 5350983/5350983, Ways 33035/33035, Relations 0/0/0
Nodes 5350983/5350983, Ways 82075/82074, Relations 0/0/0
Nodes 5350983/5350983, Ways 128033/128032, Relations 0/0/0
Nodes 5350983/5350983, Ways 188208/188204, Relations 0/0/0
Nodes 5350983/5350983, Ways 232438/232430, Relations 0/0/0
Nodes 5350983/5350983, Ways 305389/305379, Relations 0/0/0
Nodes 5350983/5350983, Ways 376972/376959, Relations 0/0/0
Nodes 5350983/5350983, Ways 476497/476277, Relations 0/0/0
Nodes 5350983/5350983, Ways 508739/508427, Relations 33437/0/32859
End of document, reading took 232 seconds
strange this outline is already triangulated ! maybe dublicate. I will ignore it
Way http://www.openstreetmap.org/?way=57435379
please see http://www.openstreetmap.org/?relation=839921
“Niin siis eihän niitä multipolygoneja tarvitse lainkaan pureksia polygoneiksi, vaan homma on siinä mielessä alaspäin yhteensopiva, että kun multipolygon koostuu polygoneista, niin GpsMid sitten käsittelee polygonit aivan normaalisti relaatioista mitään ymmärtämättä ikäänkuin erillisinä järvinä jotka vain sattuvat olevan yhdestä rannanosasta toisessa järvessä kiinni.”
Hmm, enpäs olekaan varma, olenko tätä useamman vierekkäisen outer-polun järveä vielä gpsmidillä testannut. Muistin virheellisesti Lohjanjärven olevan multipolygon johon piti laittaa useampi outer -polku, mutta näköjään yksi outer-polku riitti. Palaan asiaan.
Hiukan ongelmia näkyy tällä hetkellä olevan myös Mapnik-renderöinnissä joillakin zoomitasoilla Saimaalla Kuopion keskustan tienoolla. Katsotaanpa asettuuko piirto järkevästi.
Mitenkäs mkgmap suhtautuu tuollaiseen, tuleeko Syväristä oikean näköinen?
Jos Osmarender ei tuosta selviä - tosin ei selviä myöskään relaatioilla koostetuista rannanpätkistäkään ilmeisesti - niin ehkä olisi paikallaan ehdottaa Osmarenderin kehitystä tässä suhteessa.
Vai löytyisikö jokin vaihtoehtoinen tapa vielä? Periaatteessa tietysti natural=coastline on yksi tapa, mutta toisaalta kyllä siististi paketoitu alue natural=water ja koostettuna relaatio(i)ksi olisi aika tyylikkäästi rakenteen kuvaava tapa joka on piirrettävissä myös ilman relaatioita ja ilmeisesti suhteellisen monimutkaista hakemista missä järvi alkaa ja missä loppuu kuten natural=coastlinella. Relaatiossa kun on kauneutena myös se, että sillä kuvautuvat järvessä olevat saaret nimineen siten, että ne voidaan esim. nimihaussa esittää mielekkäästi, ei taida coastlinella oikein tuollaista voida tehdä.
Vahvistan, että kahdesta palasta liitetty Syväri näkyy GpsMidin kartalla oikein, samoin Saimaa Kuopion keskustan tienoilla on enimmäkseen oikein. Luoteeseen keskustasta on neliö maata, tarkistan onko siellä vielä jokin ei-umpinainen järven tai saaren rantapätkä. Myös Vehmersalmelta itään ja Leppävirralta pohjoiseen on maaneliöitä, lienee sielläkin vielä korjattavaa kartassa.
Eipä näytä Osmarender tosiaan tuollaisia toisiinsa liitettyjä vesimonikulmioita osaavan piirtää. No, toisaalta Osmarender -kartta tulvii muutenkin vesialueena Lappeenrannasta Iisalmeen, joten en tiedä huonontaako polygonien käyttäminen tilannetta.
Mapnik-kartalla näkyy multipolygon -muutosten jälkeen vielä Saimaalla Kuopion keskustan tienoolla virheellistä karttaa zoomitasolla 11 ja 12 (kts. http://www.informationfreeway.org/?lat=62.87588814520414&lon=27.849543661388125&zoom=12&layers=00000F0B0F ). Kymppiin asti näyttää oikealta, ja 13 on kunnossa yhtä neliötä lukuunottamatta, 14 näyttää kokonaan oikealta. Poistelin tupla- ja tripla-rantaviivoja jotka ilmeisesti aiheuttavat ongelmia, katsotaan tokeneeko tuosta.
Jos gpsmid ei selviydy useamman outer-polun järvestä, niin eihän se voi ikinä näyttää mertakaan. Vaan eipä GSM-puhelimista taida muutenkaan olla paljoa iloa yli 30 km:n päässä lähimmästä tukiasemasta.
En osaa vielä sanoa. Se valitti Saimaan multipolygoneista, joita juuri korjailin. Olit (tai joku oli) piirtänyt rantaviivoja osittain ristiin, ja jotkut alueet kuuluivat moneen multipolygoniin. Mapnik:kin näytti menneen sekaisin. Korjasin JOSMin Validator-liitännäisen multipolygon-valitukset ja tein lisää multipolygon-relaatioita niin, että kussakin relaatiossa on yksi outer-polkujen (tässä tapauksessa vieläpä yhden outer-polun) muodostama silmukka, jonka sisällä kaikki inner-polut ovat.
Valitettavasti joku on noin viikko sitten aloittanut landuse-tietojen siirtämisen Venäjän puoleiseen Karjalaan. mkgmap valittaa niistä ja mielestäni aiheesta. Minun täytyy toteuttaa jokin tapa, jolla mkgmap sivuuttaa kyseiset relaatiot jonkin avaimen perusteella tai ei ainakaan valita niistä. Ei ole järkevää seuloa kaikkia satoja multipolygon-relaatioita, joista mkgmap valittaa.
