Suurten multipolygonien pilkkominen

Käyttäjä Daeron esitti närkästyksensä siitä, että olen Saimaan multipolygon-relaatiota määritellessäni pilkkonut järveä melko mielivaltaisesti pienempiin osiin pääsääntöisesti lahtien tai kapeikkojen kohdilta mutta joskus myös keskeltä järven selkää saarten välistä.

Kieltämättä tuntuu hieman väärältä vetää vesistön poikki kaksi vastakkaista natural=water-viivaa, vaikka olen vastaavaa nähnyt pitkissä jokiuomissa (riverbank). Mutta toisaalta en pidä käytännöllisenä määritellä tuhansia tai kymmeniä tuhansia viivanpätkiä käsittävää vesialuetta yhdeksi multipolygoniksi. Se saisi yhden jos toisenkin työkalun yskähtämään.

Koska ei ole tiedossa, osaako Garmin esittää multipolygoneja (reikäisiä alueita), mkgmap pilkkoo ne tavallisiksi alueiksi. Silloin se joutuu määrittelemään mielivaltaisista kohdista halkaistuja vierekkäisiä alueita. Saksassa esitetään rajat (boundary) multipolygon-relaatioilla, ja jotkut ovatkin huomanneet, että rajoja tulee ihan vääriin paikkoihin, nimittäin mkgmapin tekemille leikkausviivoille.

Tarvitaan siis jokin tapa erottaa alueiden sisäiset leikkausviivat aidoista reunaviivoista. Olisi hyvä, jos sama merkintätapa olisi käytössä sekä kartalla että mkgmapin sisäisesti muodostamilla leikkausviivoilla. Onko ehdotuksia? Aion keskustella tästä myös mkgmap-dev-listalla, jossa nimimerkki WanMil on viime aikoina ahkeroinut multipolygonien parissa.

Mitään merkintätapaa leikkausviivoille ei tarvitse, koska niitä ei tarvitse merkitä dataan. Rajoittuneet työkalut voivat itse leikata alueet osiin jos eivät muuten osaa tukea joko reikäisiä alueita tai isoja. Tällöin työkalu myös itse tietää mistä kohti se on leikannut alueen, ja voi näin ollen rendata/exportata/yms. sen eri tavalla.

Todella isoille vesialueille taas on jo ollut pitkään oma merkintätapansa, natural=coastline, jolla saimaa (ja muutamat muut isot järvet suomessa) on/oli merkitty. Sitä hyvin tukeva työkalu on esimerkiksi coastchecker joka luo shapefilen annetuista poluista.

Suuret multipolygonit ovat hankalia oikeastaan vain silloin, kun käytetään jonkun muun leikkaamia alueita, kuten Geofabrikin. Nopeuden vuoksi Geofabrik rikkoo relaatiot leikatessaan alueita. Geofabrik yksinkertaisesti jättää kaikki leikkausalueensa ulkopuoliset solmut pois eikä yritä jatkaa jäljelle jääneitä viivanpätkiä leikkausalueeseen saakka. Jotta relaatiot toimisivat hyvin leikkauksen jälkeenkin, niiden sisältämät viivat ja solmut pitäisi säilyttää kokonaisuudessaan, jos yksikin relaatioon kuuluva viiva tai solmu on leikkausalueen sisäpuolella.

Merkintätapa natural=coastline vaikuttaa enemmän virhealttiilta kuin multipolygon. Työkalut osaavat toki varoittaa, jos jokin viiva on väärinpäin, mutta esimerkiksi JOSM ei väritä sellaisia vesialueita lainkaan. Paljon pieniä järviä ja saaria (ja saarella olevia järviä) sisältävällä alueella voi olla hankala nähdä, missä on vettä ja mihin kohtaan tietä kuuluisi piirtää siltoja.

JOSM osaa näyttää osittain ladatutkin multipolygonit kohtalaisen järkevästi. Samoin mkgmap käsittelee osittaiset multipolygonit paremmin kuin sen, että natural=coastline katkeaa ennen karttapalan reunaa. mkgmap --generate-sea=multipolygons olettaa neliskanttisen alueen, ja Geofabrik leikkaa monikulmion muotoisia alueita epämääräisistä kohdista ilmoittamatta leikkauskohtaa.

Nämä relaatioiden piirtelyt vaikuttaa minusta siltä, että ihminen on laitettu tekemään koneen hommaa - turhaan. Jos työkalut ei hanskaa coastlineja, niin ne tarttis korjata. Ei se nyt niin vaikeaa voi olla, jotensakin tuntuisi että nopeampi on korjata josm ja mkgmap kuin pilkkoa Saimaa ja Päijänne. Bonuksena ei ole sitten kannassa ylimääräisiä relaatioita murehdittavana jatkossa, minusta nuo N:n relaation multipolygonit eivät oikein ole järkevästi hahmotettavisssa näin ihmisnäkökulmasta.

JOSMissa rittäisi kun olisi sininen paksu viiva coastlinen oikealla puolella, mkgmapissa voisi olla jokin pureskelualgoritmi joka askartelee tarvittavat muutokset syötteeseensä heti alkuunsa, jos ei muuten onnistu (kummankaan koodia en ole lukenut).

Olet oikeassa, vain työkalut kaipaavat viilausta. Paksu viiva JOSMissa voisi toimia, ja validator-liitännäinen voisi vaieta sellaisista kesken päättyvistä rantaviivoista, joiden päätepiste on ladatun alueen ulkopuolella. Yritän virittää mkgmap --generate-sea:n toimimaan Geofabrikin karttapalalla. Jos ladattuun karttapalaan liimaisi muutaman ongelmallisen natural=coastlinen umpeen, niin sen pitäisi toimia.

Natural=coastline ei selvitä kaikkia ongelmia. Saaria ei voi merkitä millään natural-tagilla, ja pelkälle coastlinelle annettu nimi tahtoo hautautua tietokantaan. Käyttäjät, jotka ovat halunneet antaa saarille nimiä ja laittaa niihin vähän väriä ovat keksineen varsin luovia tapoje yhdistellä esimerkiksi landuse- ja place=island/islet -tageja. Lopputuloksena on se, että ei taida löytyä gurua, joka osaisi hakea OSM-tietokannasta yhdellä haulla vaikkapa kaikki Helsingin edustan saaret.

On kyllä hauska välillä seurata, miten mutkikkaita ratkaisuja joudutaan kehittämään Steve C:n hahmotteleman yksinkertaisimman mahdollisen lähestymistavan pohjalta (“OpenStreetMap has been built iteratively using the simplest approach that could possibly generate useful maps”).

Olin vähän kahden vaiheilla, mainitsenko tuota. Näin jossain päin Saimaata melko mielenkiintoisia ratkaisuja. Olisiko jossain peräti piirretty erillinen natural=coastline saaren ympärille. Joillekin saarille annoin nimen niihin päättyvän highway=* name=jonkin_saarentie perusteella.

Käsitin niin, että natural=coastline on vanhempaa perua kuin relaatiot ja että nykyään asiat on tapana tehdä relaatioilla. Minulle tuli tämä multipolygonien pilkkomisongelma vähän yllätyksenä.

Onko sinulla hyviä ehdotuksia? Tähän mennessä on tullut ilmi seuraavaa:

  1. Multipolygonit ovat tarpeen annettaessa saarille nimiä ja attribuutteja. Vanha tapa natural=coastline toimii asumattomilla tai kartoittamattomilla alueilla.
  2. Jotkut työkalut yskähtävät suurista multipolygoneista.
    Esimerkkejä: tulviva Kuopio Osmarender-kartalla, suurten relaatioiden hidas lataaminen ja tallentaminen JOSMissa
  3. Nykyiset työkalut eivät osaa yhdistää keinotekoisesti pilkottuja multipolygoneja yhdeksi.
  4. Ei ole sopivaa määritellä natural=coastline tai natural=water keskelle järveä. Keinotekoisista leikkausviivoista pitäisi tarvittaessa päästä helposti eroon.

Olen edelleen multipolygonien kannalla ja pitäisin järkevänä niiden käyttämistä merialueillakin. Mutta kartan olioilla on oltava jokin kohtuullinen enimmäiskoko. Pitkät tiet ja jokiuomat on katkottu muutaman sadan solmun pätkiin, ja niin pitäisi voida tehdä paljon (viivojen välityksellä) pisteitä sisältäville multipolygoneillekin. Työkalut osaavat yhdistää ainakin pilkottuja teitä tarpeen mukaan.

Näistä lähtökohdista pitäisin järkevänä sitä, että “sallitaan” multipolygonin outer-jäsenen pilkkominen. Jotta leikkausviivat erottuisivat oikeista viivoista, ne voisi tehdä erillisinä viivoina ilman mitään attribuutteja. Ne liitettäisiin multipolygon-relaatioon outer-viivojen ketjuun. Vierekkäisten alueiden leikkausviivat kulkisivat täsmälleen samojen pisteiden kautta, vastakkaisiin suuntiin, tai sitten alueilla olisi yhteinen leikkausviiva roolissa outer. Työkaluja korjattaisiin niin, että ne käsittelevät täten pilkottuja multipolygoneja yhtenä alueena.

Ennen kuin tilanne selkiytyy, en aio enää määritellä pilkottuja enkä suuria multipolygoneja.

Tuota, minkäs takia saaria ei voi käsitellä vain saarina, ts. miksi ne pitää sotkea ympäröivään vesialueeseen? Kyllähän ne on sijaintinsa perusteella siellä veden keskellä, eikai sitä tarvitse erikseen tagata jollain multipolygonirelaatiolla (järviä ja saaria toisiinsa kiinni). Luulisi sen tiedon kaivautuvan kannasta melko yksinkertaisesti. Onko tarkoitus vain helpottaa kannasta hakemista?

Ja jos Saimaa pilkotaan pieniin paloihin, niin onko seuraava projekti tehdä jokin relaatio niille paloille, että voidaan hakea Saimaan saaret? Vai onko tässä vaiheessa sitten rajanveto siinä, mitä ei kantaan laiteta, ja luotetaan että ne palat kaivautuvat sieltä.

Jos saari on vaikka kasattu useammasta coastlinesta (miksi? helkutin iso?), niin miksei siitä voi sitten tehdä yhtä multipolygonia missä on vain ko. saari, jos tarpeen? (jotenkin tuntuisi että ei välttämättä edes ole, kun liittyyhän ne coastlinet toisiinsa, mutta helpottaa varmaan taas kantahakua. Tapoja tagata “tämä on saari” on helppo keksiä, lähtien viivan tageista, tai laittamalla pisteen keskelle saarta ja tagi “tässä on saari ja nimi on tämä”, sisäkkäisten saarten tapauksessa käydä läpi sisältä ulospäin, …)

Miksi se ympäröivä vesialue pitää olla jotain muuta kuin coastline tai sarja coastlinen pätkiä?

En ole asiaan perehtynyt sen syvällisemmin, mutta rupesi vain tuntumaan siltä että nyt saatetaan tehdä asiasta liian vaikeaa kartoittajalle. Kysymys taitaa nyt olla lähinnä siitä, että kuinka valmiiksi pureskeltua kannassa olevan datan on tarkoitus olla, ja mitä sitten jätetään tietoa pureskelevien työkalujen logiikan harteille. Ja kun en ole perehtynyt, niin ei taida olla syytä ottaa asiaan kantaa. Homma sinänsä hoitunee millä tahansa tavalla… Eli ei mitään, jatkakaa :slight_smile:

Tämä voisi todellakin jatkua vaikka kuinka pitkään, tässä kun ollaan periaatteellisten asioiden kanssa tekemisissä. Puritaanipuolue on sitä mieltä, että koska saari ei ole järveä, niin järveen on tehtävä sille kohtaa reikä. Jos järvi olisi isona altaana, ja siihen päälle piirrettäisiin saari, niin saaren kohdalla karttaa olisi sekä järveä että saarta, mikä tuntuu jotenkin väärältä. Coastline-puolueen tyylillä, jos saari ympäröidään rantaviivalla, saaren kohdalla on alue, josta tiedetään, että se ei ole vettä. Esimerkiksi Mapnik-kartan teossa pelataankin oletuksella, että joka kohdassa on jotain, ja jos muuta ei ole ilmoitettu, niin piirretään se sitten kuivana maana. Järvi-multipolygoni ilman saarelle annettuja omia tägejä johtaa samaan tulokseen, eli tyhjään reikään.
Käytännössä voidaan tehdä ihan hyvän näköinen lopputulos saarilla, jotka ovat vain reikiä. Siihen päälle jos tehdään jotain karttasovellusta, niin helpoimmalla siitä syntyy sellainen, joka saaren kohdalle klikattaessaa antaa kysymykseen “Mitä tässä on?” vastauksen “Ei mitään”. Järviallas + saari taas johtaa vastaukseen “Tässä on järvi ja saari”. Jos ajatellaan, että oikea vastaus olisi “Tässä on saari”, niin helpoiten sen saisi aikaan, jos tietokannassa olisi jotenkin yksiselitteisesti olemassa tieto reikäisestä järvestä ja reiän täyttävästä saaresta. Sama vastaus on mahdollista saada aikaan järkeilemällä noilla toisillakin merkintätavoilla. Mitä useampia tapoja merkitä sama asia on käytössä, sitä mutkikkaammaksi tulee käyttää dataa mihinkään hyödylliseen.
Sinänsähän koko tämä saivartelu johtuu vain tietokoneista. Kuka tahansa nelivuotias renderöi hienon kartan, jos annetaan ohjeet: “Piirrä järvi, jossa on kolme saarta. Keskimmäisessä saaressa on hiekkaranta. Kaksi muuta ovat metsäisiä ja toisessa niistä on lampi. Jos sanot saarten nimet, niin isä kirjoittaa ne.”

Mapnik:in coastline-tageista piirretyt vedet päivittyvät vain epäsäännöllisesti kun niistä generoidut shapefile-tiedot päivitetään mapnik:n kantaan, joten emme voi tietää onko esim. em. Kuopio piirtynyt oikein koska käytössä on vanhat coastlinet, vai siksi että mapnik pärjäisi massiivisen natural=water multipolygonin kanssa. Uskoisin sen pärjäävän niin kauan kuin yksikin node osuu ns. supertileen eli 8x8(?) karttapalakuvan alueelle jotka piirretään samanaikaisesti.

Olen pilkkomassa Saimaan multipolygonien väliset leikkausviivat erillisiksi tagittomiksi viivoikseen, jotka ovat yhteisiä vierekkäisten multipolygonien kesken muutoskokoelmassa 3926233.

Yksi mahdollinen ratkaisu olisi merkata edelleen natural=water (jotta järven osaa voidaan käsitellä normaalisti natural=water -kehänä) joka on relaatiossa outer-roolissa, mutta merkata keinotekoiset viivat relaatioon myös omalla roolillaan, vaikkapa outer_glue. Tällöin voidaan tarvittaessa poistaa keinotekoiset viivat normaaleilta outer -kehiltä esim. kehän pituutta laskiessa, ja silti säilyttää yhteensopivuus niiden työkalujen kanssa jotka eivät noita uusia rooleja ymmärrä.

Kaiketi tämä auttaisi myös renderöintiin silloin jos tyylissä on rannan korostus, kahden multipolygonin saumakohtaa renderöitäessä ei käytettäisi korostusta, eli jos renderöidään multipolygonit yksi kerrallaan niin pitää esittää outer_glue-roolilla merkitty eri tavalla eli ilman korostusta niin että näyttää hyvältä naapurimultipolygonin vastaavaa rajaa vasten. Jos taas ennen renderöintiä yhdistetään koko järven multipolygonit, tätä varten ei kahden kehän leikkausviivojaa ei tarvitse etsiä, kun ne on merkitty relaatioon.

Jokin tapa pitäisi kaiketi vielä olla saman järven eri relaatioiden automaattiseen yhdistämiseen, tai siis naapurimultipolygonien löytämiseen. Esim. sovitaan, että outer_glue täytyy merkitä yhdellä ja samalla polulla joka on yhteinen molemmille relaatioille, sitä kauttahan pääsee naapurimultipolygoniin.