Pitäisikö isojen järvien tekemiseen käyttää natural:water vai natural:coastline tagia? Olen puuhastellut Lakewalkerin kanssa Saimaan parissa ja jäin miettimään asiaa. Tässä vaiheessa nuo olisi helppo vielä vaihtaa.
Entä minkä kokoisiksi paloiksi rantaviivat olisi syytä pilkkoa? Olisiko 500 nodea hyvä?
Minä vaivaan päätäni pääasiassa sillä, kuinka OSM-dataa voisi käyttää hyväksi muutenkin kuin Mapnik- ja Osmarender-karttatasojen tekemiseen, ja siitä syystä olen periaatteessa ehdottomasti natural:water -vaihtoehdon puolella. Tämä pitäisi käsitteistön selvänä, eli kaikki järvet olisivat sulkeutuvia aluekohteita, ja ne saisi esille yhdellä kyselyllä (WHERE “natural”=‘water’). Minulla on vielä lisäongelmana se, että osm2pgsql-ohjelma, jota käytän OSM-dumpin viemiseen PostGIS-tietokantaan, ei näytä tekevän natural:coastline -kohteille yhtään mitään, eli esimerkiksi Päijännettä minä en nyt saa tietokantaan ollenkaan. Mutta osm2pgsql on tietysti vain yksi ja ilmeisesti aika vähän käytetty työkalu, jota voidaan tarpeen tullen kehittää, joten sen ei tarvitse ohjailla tagien käyttöä. Mutta loogisuuden takia minusta kaikkien järvien ja lampien olisi hyvä olla natural:water, jos se vain käytännössä toimii JOSM:in, Potlatchin ja vakiokarttatasojen teossa. Ainakin Lappeenrannan pohjoispuolelle on onnistuttu tekemään iso järviallas oikein hienosti pilkkomalla se useisiin natural:water -alueisiin. Tämä menetelmä näyttää toimivan sekä karttatasojen renderöinnissä että PostGIS tietokantaan lataamisessa.
Jos kaikki Suomen järvet multipolygoneiksi muuttuisivat, niin Garmin-kartalla näkyisivät saariakin sisältävät vesialueet. Nythän siellä näkyvät monista suurista järvistä vain rantaviivat. Eilen määrittelin kokeeksi Inarinjärven, ja sehän näkyy hienosti, jopa saarien sisältämät järvet. Saimaata en uskaltanut ruveta vielä työstämään. Vähänkin isompi multipolygon saa JOSMin tahmaamaan, jos ei valitse wireframe-piirtotilaa (ctrl-w).
Merialueet ovat oma lukunsa. Periaatteessa mkgmap osaa muodostaa rantaviivoista multipolygonit itse (–generate-sea=multipolygon), mutta käytännössä Geofabrikin valmiiksi leikatuista alueista puuttuu tieto siitä, mistä kohtaa ne on leikattu. Samaten splitter vaatii pieniä korjauksia, jottei se riko leikkausrajalla olevia multipolygoneja. Splitterin tekijä on ilmeisesti halukas tekemään tarvittavat korjaukset, mutta Geofabrikin karttapaloihin ei varmaankaan ole luvassa korjausta lähiaikoina.
Relaatiot voivat olla uusi asia monille, mutta niitä ei tarvitse pelätä. JOSMissa on aika mukava relaatiomuokkain. Kannattaa vain olla huolellinen, sillä JOSM ei ilmeisesti vielä osaa tarkistaa multipolygon-relaatioita. Olen korjannut muutamia relaatioita, joihin oli liitetty muiden järvien saaria. Määrittelin jokaisesta järvestä oman multipolygon-relaationsa: rantaviiva (natural=water tai natural=coastline) role=outer ja saaret (natural=land tai natural=wood) role=inner.
Jos vielä voisi luopua natural=coastlinen käytöstä järvillä kokonaan, niin saataisiin isotkin järvet mukaan shapefile-kartoille ja PostGIS:iin osm2pgsql-ohjelmalla. En tiedä, onnistuuko, mutta ensi viikollahan tuon voi Inarinjärvestä tarkistaa. Ehkä tuo ralaatiolle annettu natural=water ja itse rantaviivalle annettu natural-coastline -yhdistelmä toimii. Eivät nuo relaatiotkaan ongelmattomia ole, ainakaan jos haluaa käyttää tietoja muilla kuin vartavasten OSM:ia varten tehdyillä ohjelmilla. Multipolygoneiksi tehdyt järvet kyllä tulevat tiedostoihin oikein, eli reikäisinä polygoneina, mutta reiät, joille on joille on annettu omia ominaisuustietoja, kuten saarille natural=land, tuntuvat tipahtavan pois.
Geofabrikin Suomi-aineistossa näyttää olevan 50143 natural=water -kohdetta. Näistä vain 2872:lla on nimi.
Eilen SlippyMapin Mapnik-taso näytti kovin oudolta Lokan ja Porttipahdan tekojärvien kohdalla. Määrittelin niille asianmukaiset multipolygonit, ja nyt suorat viivat ja käänteiset vesialueet ovat kadonneet kartalta.
Inarinjärvellä liitin aluksi saarten järvet mukaan isoon relaatioon roolissa outer, mutta silloin mkgmap antoi niille pikkujärvillekin nimeksi Inarinjärvi. Daeron poisti järvet relaatiosta, ja minä määrittelin saarille omat multipolygonit (natural=land ja järvet (natural=water) roolissa inner).
Siitä voi halkoa hiuksia, onko natural=land enemmän oikein kuin täysin tyhjä saari. Daeron nimittäin poisti myös saarille lisäämäni natural=land, ja minä palautin ne takaisin määriteltyäni järviä sisältävien saarten multipolygonit. Jos Inarinjärven saaret voidaan olettaa pääosin luonnontilaisiksi, natural=land ei liene kovin väärin (vielä oikeammin saattaisi olla natural=wood). Asutummilla alueilla saaret lienee paikallaan jättää merkitsemättä, jos maankäytöstä ei ole tietoa.
Piirtelin ison osan Saimaata multipolygoneiksi. En antanut nimiä muille kuin selkeille osille, joiden nimet olivat pääteltävissä teiden tai siltojen nimistä, kuten Savilahti Mikkelissä. Joitakin saaria nimesin pisteiden tai teiden nimien perusteella.
Viimeisestä multipolygonista tuli vähän turhan iso (yli 1200 jäsentä), kun en löytänyt luontevaa katkaisukohtaa. Opinpahan JOSMin tehokäyttöä, ja noita voi pilkkoa myöhemmin. Nyt Garmin-karttani näyttää jo kovin siniseltä. Saatan jatkaa Saimaata lähipäivinä vielä koilliseen päin, ellei joku muu innostu ensin.
Keep Right ei taida ymmärtää sitä, että natural=water on jaettu moneen osaan. Jostain syystä (latautumisen nopeuttamiseksi?) pitkät polut on kartalla jaettu enintään 500 solmun mittaisiin osiin, niin kuin rantaviiva Rääkkylän ympäristössäkin. Voisin mainita tuosta Keeprightin tekijälle.
Suurimmassa määrittelemässäni palasessa Saimaata oli noin 1400 polkua samassa relaatiossa, siinä kun ei ollut mitään selkeitä salmia, joiden kohdalta olisi ollut luontevaa pilkkoa rantaviivaa. Siitä saattaa jokin multipolygon-työkalu jo ruveta yskimään.
Navigaattorissa on helppo havaita splitter-ohjelman tämänhetkinen puute, että se ei säilytä multipolygon-relaatioita karttapalasten rajoilla. Saimaa näyttää aika hassulta karttapalan rajan lähistöllä. Siihen on kyllä tulossa lähiaikoina korjaus.
OSMin api-rajapintaan tuli 2000 pisteen rajoitus viime keväänä versiopäivityksen yhteydessä. Perustelu oli tosiaan, että aina kun polkua muutetaan, pitää koko polku lähettää uudestaan palvelimelle, mikä alkaa jo kestää pidempään. Myös erityisesti Potlatch hidastui kovasti “ylipitkiä” polkuja käsiteltäessä. Sittemmin ohje on ollut tuota 500 pisteen luokkaa, niin käyttäjien ei tarvitse heti katkaista polkua uudestaan, jos esim. saavat tarkennettua rantaviivaa kävellen tms. tavalla. Maanteillä näin pitkiä pätkiä ei yleensä tule vastaan, jokin tien ominaisuus muuttuu aikaisemmin (tai sitten on muunnettu suoraan gps-loki pisteiksi). Pisimmät maantie-polut taitavat nyt olla Suomessa 200 pisteen luokkaa.
Vanha Windows-osm2pgsql ei sekään ymmärrä Inarinjärven relaatioita. Järvi ei ole järvi, sen sijaan muutaman saaret ovat. Osa saarissa olevista järvistä kyllä on vettä, kuten pitääkin. Järvi ei ole myöskään mukana Geofabriikin shapefilesatsissa. Se saattaa vielä ajan mittaan hävitä Mapnik-tasoltakin, nyt se kenties piirretään sinne harvakseen päivittyvästä coastline-aineistosta. Mutta periaatteessa hyvä yritys, ehkä ohjelmat joskus kehittyvät OSM-relaatioiden tasolle.
Ei näy Saimaakaan Geofabrikin shapefileissä. Tarkistin myös Cloudmaden shapefilet, mutta en ole ihan varma voiko niistä päätellä vielä mitään. Ne olivat helmikuun 9. päivältä, ja periaatteessa Inarinjärvi oli jo siihen aikaan natural=water. Sellaisena se ei näy, mutta toisaalta järvi on kuitenkin mukana coastline-viivoina. Eli jos Cloudmade tekee tiedostot suoraan OSM-aineistosta, niin helmikuun 9. päivän aineisto on ehkä tehty ainakin pari päivää vanhemmasta tilanteesta.
Järvirelaatioita ja ylipäätään polygoneja varmaan opitaan OSM:ssa hallitsemaan ajan mittaan, mutta muuten olen kyllä sitä mieltä, että reipas relaatioiden käyttö voi johtaa suuriin vaikeuksiin datan käytössä, sen lisäksi että se tekee kartan muokkaamisen epämiellyttäväksi ja karkottaa aloittelijat. Olen tehnyt 11 vuotta töitä OSM-tyylisen viivanpätkistä-alueita relaatioiden avulla -tietokannan ympärillä, mutta ei minulle tulisi mieleen edes itse ruveta rakentamaan relaatioita käsityönä ilman juuri sitä varten viritettyä sovellusta, puhumattakaan että laittaisin jonkun muun tekemään samaa. En ole viitsinyt tehdä edes reikäisiä polygoneja kuin pari kokeeksi, koska GIS-ihminen minussa sanoo, että ei ketään pitäisi pakottaa tekemään niin yksinkertaista asiaa sillä tavalla. Mutta OSM:ssa joudutaan tasapainottelemaan yksinkertaisen muokkauksen ja monipuolisten ominaisuuksien välillä. Relaatioita kuitenkin tarvitaan esimerkiksi kunnollisen reitityksen aikaansaamiseksi.
Olen pitkälti samaa mieltä, mutta kuten totesit, relaatiot ovat välttämättömiä joissakin sovelluksissa. Viime kesänä katselin Tallinnan karttaa, ja siellä pisti silmään se, että bussilinjoja oli piirretty pari metriä tien sivuun ilman relaatioita. Se vaikutti hankaloittavan kartan muokkaamista paljon enemmän kuin relaatioiden käyttäminen. Mihin esimerkiksi piirretään jalkakäytävät? (Niitä oli Tallinnassa merkitty hyvin säästeliäästi, samoin kuin suojateitä, joita ei edes ollut jokaisen risteyksen jokaisessa kulmassa. 20 cm:n reunakiveltä ei niin vain lähdetä ylittämään ajorataa lastenvaunuilla tai polkupyörällä. Lisäsin sinne vain muutaman jalkakäytävän ja suojatien reittijälkieni perusteella enkä ruvennut ekstrapoloimaan.)
Silloin tällöin tulee vastaan rikkinäisiä kääntymiskielto- ja reittirelaatioita. JOSM taitaa rikkoa kääntymiskieltorelaatiot lisäämällä oletusarvoisesti jokaisen tienpätkän relaatioon, kun riittäisi säilyttää vain via-jäsentä lähin tie. Reittirelaatiot taas tuppaavat menemään rikki, kun lisätään kiertoliittymiä tai kaksiajorataisia osuuksia. Niitä on hankala korjata automaattisesti. Kääntymiskieltorelaatiot ovat siitä helppoja, että käyttämäni mkgmap osaa valittaa niistä.
Uskon, että saaret ja järvet pysyvät paremmin paikoillaan kuin tiet. Teitähän pilkotaan tavan takaa, kun sellaisten määreiden kuin surface, lit, maxspeed, name, ref arvot muuttuvat tai kun määritellään reittirelaatioita.
Kyllä, on yksinkertaisempi, eikä sekään toimi Cloudmaden eikä Geofabrikin shapefileissä. Molemmissa Tuomiojärvi on kokonaisena alueena ilman saarireikiä. Ulkoreuna tulee mukaan, koska se on yhtenä sulkeutuvana rinkulana. Esimerkiksi Lehtisaari on kyllä sekin olemassa omana metsäisenä maankäyttöalueenaan. Kumpikin firma käyttää ilmeisesti samaa työkaluohjelmaa, joka ei hallitse järviä ja saaria.
Saarijärven Pyhäjärvi on tehty vähän eri tavalla, rantaviiva on jaettu pätkiin, ja saarilla on toisenlaisia tageja. Siitä ei shapefileihin siirry mitään. http://www.openstreetmap.org/browse/relation/303406
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.
Olisiko multipolygon liian iso tai Mapnik niin tyhmä, ettei se ymmärrä katsoa karttapalan kokonaan ympäröiviä multipolygoneja?
Multipolygonien pilkkominen on hieman ristiriitaista. Avasin siitä oman viestiketjunsa Suurten multipolygonien pilkkominen ja toivon rakentavia ehdotuksia.
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.