Vaikutti omaan silmään hienolta. Vielä kun koko suomi saataisiin yhtä kattavasti, niin siinä olisi juhlan paikka. Muutamassa tiessä mitä tarkistin ei näyttänyt olevan tien nimeä, mutta liekkö kaikissa teissä asutuskeskuksien ulkopuolella onkaan.
Onko muuten missään ohjeita työnkulkuun millä teit importin? Silmäilin tätä ketjua, huomasin vain mainintoja käytetyistä työkaluista.
Itselläni polttelee päästä askartelemaan muutamaa heikompaa aluetta Mutta kuten tästäkin ketjusta huomataan, ei kaikilla ole vielä selvyyttä lisenssikiemuroiden statuksesta, odottelen ensin josko jotain “virallisempaa” infoa asiasta tulisi.
Ja kukaan ei ole tätä tehnyt! Ihan turha laatia mitään memorandum of understandingejä, jos omassa päässä ei vaivauduta tekemään luvattuja asioita. Oman tulkintani mukaan kaikki tähän mennessä tehdyt tuonnit rikkovat MML:n lupaehtoja sekä annettuja lupauksia.
Aivan varmasti rikkovat, mutta tämä ei toki ole lainkaan posikin vika vaan niiden jotka kyseiset importit “vähän” “kokeilu” / “testi” yms. mielessä ovat tehneet. …Jäitä pitäisi olla hatussa. Toki ymmärrän että jotkut ovat huonoa esimerkkiään täälläkin foorumilla mainostaneet ja toiset jotka eivät ole niin hyvin perillä ovat sen tähden kuvitelleet että kaikki on jo ok. “Testiksi” riittäisi pääsääntöisesti riittävän hyvin joku .osm file jonka avaa editorissa katselua varten (jonka voisi uppia siis jos luvat, yms. olisivat oikeasti kunnossa), toki niitä .osm filejä voisi ilman osmiakin laittaa näytillekin jos haluaa ilman että upitaan mihinkään koska mml:n lisenssi toki sallii levittelyn.
Toinen ongelma mikä tulee luultavasti pian esiin:
…Oletetaan nyt että lisenssi ja muut jutut jotenkin maagisesti olisivat jo ratkenneet… Itseäni vähän epäilyttää että syntyy aikamoinen kaaos kun erinäiset ei kovin aktiiviset kartoittajat alkavat importtaamaan sinne ja tänne vähän sitä ja tätä, ja vielä ehkä hiukan erinäköisillä säädöillä niin että datasta tulee sillisalaattia eri key valueilla. Lisäksi vielä veikkaan että iso osa importaajista sitten kummallisesti katoaa kuvioista siinä vaiheessa kun sitä importattua dataa pitäisi oikeasti alkaa käymään läpi ja ratkomaan mml:n datan virheitä, vertaamaan ilmakuviin jne. Väitän että on toiveajattelua että tähän asti kovin inaktiiviset yllättäen innostuisivat valtavasti korjaustyöstä importin suoritettuaan (kyseessä ei tule olemaan mikään pienen mittakaavan juttu kuin mitä tähän asti osmissa olevan datamäärän käsittely!), ehkä käy korkeintaan niin että mennään vaan toiselle läntille importtaamaan, se kun on “helpompaa”. Tähän kun vielä lisätään se että jo alusta alkaen pitäisi ottaa huomioon se että dataa olisi tarkoitus myös ylläpitää mml:n aineiston muutoksien mukaan. Moni ehkä suhtautuu varsin kevyesti koko ylläpito-ongelmaan, mutta todelliset haasteet tulevat eteen siinä kun sitä aletaan miettimään, toivottavasti mietitään asiaa ennemmin kuin myöhemmin (MML:n kaverin huomiot päivityksiin liittyen aiemmassa miitissä kannattaisi oikeasti ottaa vakavasti, vaikka ne siinä valitettavasti sivuutettiinkin “epäoleellisina” ja “itse toteutukseen kuuluvina” eikä toteutuksen suunnittelusta ole sen koommin kuulunut halaistua sanaa).
Toinen mikä mua vähän pelottaa on se että jotkut alkavat raa’asti vaan poistamaan olemassa olevaa dataa, jossa saattaa hyvinkin olla tietoja joita mml:llä ei ole (esim. valaistus, maxspeed, yms) ja korvaamaan importatulla “paremmalla” tavaralla mml:ltä suoraan ilman asiaankuuluvaa tietojen siirtoa. En ole nyt käynyt noita “testi”/“koe” changesettejä läpi, mutta ehkä pitäisi, toivottavasti jo niissä ei tämä ongelma esiinny…
Kolmanneksi: importteja tehtäessä olisi asiaan kuuluvaa tehdä niiltä vaadittu kuvaus wikiin jne. eikä vaan painella suoraan uploadia kun on jotain työkalustoa saanut kasaan.
Pientä esimakua tuosta on jo saatu Corine-maankäyttötietojen tuontien yhteydessä. Viime aikoina, kun Bing-peitto on parantunut, jotkut ovat tarkentaneet Corinen jo kattamia alueita. Siinä yhteydessä on jäänyt Corine-viivanpätkiä kummittelemaan. Olen noita korjaillut, kun mkgmap on huomauttanut sulkematta jääneistä alueista.
Lisäksi olisi syytä tarkistaa aineisto esimerkiksi JOSMin tarkistimella ennen lähettämistä. Kemijoen multipolygon-relaatiossa oli MML-tuontikokeilun jälkeen virheitä, jotka korjasin. Tuonti ei voi koskaan tapahtua täysin automaattisesti.
Jos tähän nyt suhtautuisi käytännönläheisesti eli lähtökohtana että ihmisten sormet syyhyävät päästä MML:n aineistoa OSM-muokkauksessa hyödyntämään ja tämä olisi hyvä mahdollistaa edes jossain määrin (toinen juttu on sitten missä määrin ja millä tavalla esim. importteja on viisasta tehdä, siinä on paikallaan esittää varauksia, kts. (1)), niin ensimmäinen askel olisi kaiketi tämä:
Onkos tämän toteutumisen tiellä jokin este? Onko tätä OSM-säätiön väelle ja/tai järjestelmän ylläpitäjille ehdotettu, onko ehdotukseen otettu kantaa? Minullakin on tuolla OSM-kehityspuolella yksi kontakti jolta voisin kysäistä miten asiassa kannattaisi edetä ja voiko hän tätä edistää, jos tässä on vaikeuksia saada asiaa eteenpäin.
Muoks PS: vai onko sittenkin parempi pistää jäitä hattuun siinä määrin, että ensin mietitään jonkinasteinen konsensus siitä mitä on sopivaa MML-aineistosta OSMiin siirtää ja millä tavalla, ja miten siirroista päätetään ym. pelisääntöjä, ja vasta sitten lisätä tuo MML-lisäykset salliva copyright -maininta OSMin sivuille?
Mielestäni tämä on ainoa oikea lähtökohta ettei lähdetä suin päin lisäilemään tavaraa.
Olisiko jonkinlainen aluejaottelu esimerkiksi kuntatasolla järkevää? Jos tähdätään siihen, että aineiston importoijat tietävät myös jotakin alueestaan ja aikaisemmin kartoitetun datan laadusta, ei tapahtuisi tätä “katoa” helpon importtausvaiheen jälkeen vaan aineiston ylläpitoonkin löytyisi mahdollisesti kiinnostusta jatkossa. Esimerkiksi Espanjan yhteisö on päätynyt kuntakohtaisesti jaettuun malliin ainakin wikin mukaan.
Tietyillä suht kattavasti kartoitetuilla alueilla paljon toimineita voisi houkutella mukaan importointiprojektiin, suorittaa perehdytys aineiston täydennysperiaatteista ja prioriteeteista ja näin varmistaa importtien tasaisempi laatu. Näiden alueiden lisäksi suomessa on edelleen paljon vähän kartoitettua aluetta johon importointi on suoraviivaisempaa eikä importointitarpeen arviointi vaatisi niin paljoa paikallistuntemusta alueen kartoituksen tasosta. Auttaisiko tässä jos kerättäisiin esimerkiksi wikiin lista kunnista sisältäen jonkinlaisen arvion kyseisen kunnan aineiston nykytasosta ja täydennystarpeesta?
Kuulostaa hyvältä, ja etenkin tuo kuntakohtainen kartoitustarpeen kartoittaminen (hmm) wikiin kuulostaa hyvin hyödylliseltä toiminnalta joka hyödyttäisi OSM-hanketta muutenkin.
Minua kyllä kaihertaa joukkoimporteissa jatkuvuuskysymys - mitä sitten, kun MML:ltä tulee uusi aineisto? Uuden aineiston julkaisuun mennessä aiemmin importoituun MML-aineistoon on porukka todennäköisesti lisännyt monenlaisia hyödyllisiä määreitä kuten valaistus, nopeusrajoitus, tien pinnan laatu jne. jne. Miten sitten saadaan MML:n uuden aineiston uudet kohteet ja määreet OSM-kartalle, joutuuko käytännössä käymään käsin koko Suomen alueen läpi? Jos talkooporukkaa riittää ja homma jaetaan alueellisesti niin ei kai tuokaan mahdotonta ole, varsin työlästä kyllä, pelkään hiukan että tappaako tuo pitemmällä tähtäimellä päivitysinnon.
Olen antanut kertoa itselleni, että MML:n aineistossa ei ole julkaisuversiosta toiseen pysyviä tunnisteita, joka ilmeisesti tarkoittaa, että “diffien” ajo MML-aineiston versiosta toiseen on hyvin haastavaa ellei mahdotonta, samoin koneellinen / koneavusteinen päivitys on varsin haastavaa.
Minusta taas kuntarajoihin perustuva jaottelu on aivan turhaa, helpompaa ja huomattavasti yksinkertaisempaa on pitäytyä laatikkomaisissa palasissa. Kuntarajat ovat suomessa tällä hetkellä sen verran eläviä että ennenkuin ollaan valmiita ne ovat joka tapauksessa muuttuneet, ainakin kerran. Toiseksi, kuntarajat pitävät sisällään vaikka minkälaisia kummajaisia kun joku tietty alue on pitänyt saada “oikean kunnan puolelle”, ihmeellisiä mutkia yms. X kertaa y palat taas ovat erittäin helppoja erottaa laskennallisesti (vs kiljoona pistettä sisältävät kuntarajat) ja mml:n data nyt joka tapauksessa on x2 kertaa y2 muotoista, ja joskus x=x2 y=y2 on jo suoraan mahdollista järkevän kokoisia paloja (ei ehkä aina).
Olen miettinyt jonkun verran että noita diffejä voisi kyllä varmaan kannasta tuottaa itsekin jotenkuten, jos on siis vanha ja uusi aineisto olemassa niin geometrioiden erotuksia kyllä pystyy laskemaan vaikkakin jonkun verran aikaa palaa kun aineisto kaikkinen luonnonmuotoineen on varsin laaja. Muutokset toki ovat luonnonkohteissa aika vähäisiä joitain vesijättömaita lukuunottamatta. Muutokset identtisiin geometrioihin taas ovat lähes triviaaleja laskea (keyval muutokset).
En luottaisi heidän id:iin muutenkaan, miten käy esim. siinä tilanteessa kun pieni pätkä tietä muuttuu, miten id avaruus muuttuu yms. Itse geometria on minusta riittävä id, toki laskennallisesti selvästi raskaampi kuin hatusta vedetty numerosarja.
Itse toteutuksesta jotain ajatuksia, alkuvaiheessa olen ajatellut että olisi mahdollista edetä jotenkin näin:
Tuodaan lähes koneellisesti se osa mikä ei overlappaa “minkään” kanssa osmissa. Katsoin tuossa joku vk sitten teiden osalta että 30-50m bufferilla (en muista enää tarkkaa arvoa), 46% mml:n pilkottuja geometrioista (iirc, 40-65% anyway) ei overlappaa “minkään” (käytin tie/rautatie) kanssa osmissa (talo overlapit tein ilman bufferia, ihan vaan varmuuden vuoksi ettei joku selitä jälkeenpäin että tässä on selvästi joku virhe jolle olisi pitänyt tehdä jotain). Tuo tuottaisi yhteinäistä verkkoa aina siellä missä ei tällä hetkellä ole mitään, mutta verkko ei toki olisi kiinni vielä missään. Jotkin kohteet kannattaisi jo tässä vaiheessa merkitä FIXME=olemassaolo tarkistettava ilmakuvasta/luonnosta tms., lähinnä kait metsätiet ja polut. Sitten vaan aletaan niitäkin käymään läpi ja poistamaan noita FIXME merkintöjä ihan käsityönä. Myös järviä / lampia katsoin joskus ja niistäkin on paljon sellaisia jotka eivät overlapanneet mutta en muista enää numeroita.
Vähemmän automaattista toimintaa, monia ideoita: teiden “tarkkuusluvun” arvointia osm vs mml (paljon landsat, muutama gps piste, yms teitä jotka olisi kiva löytää suht automaattisesti, mml:llä on se oma arvio geometrian tarkkuudesta jota voisi ehkä käyttää apuna max errorin asettamiseen), risteys-to-risteys väli pohjaista analyysiä yms (onko kaikki risteykset? puuttuuko joltain sivutieltä joku keyval), mutta tähän vaiheeseen en ole oikein mitään toteutus puolta saanut vielä tehdyksi. Vaikeimmat jutut liittyvät tuon 1 vaiheen tavaran ja osmissa jo aiemmin olleen tavaran yhdistämiseen, johon siihenkin olisi kiva jotain puoliautomaattista kehitellä (.osm ulos manuaalisesti tarkistettavaksi/muokattavaksi), mutta nämä ovat vielä enemmän mietintämyssy tavara tasolla tällä hetkellä.
Kun tavarat ovat kannassa jossa on sekä mml että osm tavara, on mahdollista yhdistää automaattisesti aiemmin upittuun mml tavaraan koska pisteet ovat edelleen samassa paikassa (niin kauan kuin niitä ei ole joku siirtänyt, jolloin faili jo onkin haluttu toiminnallisuus).
Totta, Corinesta saa vähän käsitystä datamäärän valtavuudesta. Toki MML:n data pitäis näin lähtökohtaisesta olla parempilaatuista ettei korjattavaa ole ~joka nodessa kuten corinen kanssa melkein on. Ilmeisesti corinea ei kukaan alkanut urakalla korjailemaan osittain sen takia että mml teki ilmoituksia omista siirroistaan(?), mutta aika huonolta tuo tilanne noin niinkuin periaatteessa näyttäisi jos corinen korjausvauhti antaa yhtään osviittaa siitä kuinka mml:n datan läpikäynti tulee etenemään importin jälkeen.
Aivan. MML:llä on lisäksi ominaisuuksia datassa jotain ei ole suotavaa toistaa osmiin. Muutama mitä nyt heti tulee mieleen:
Tiestö on pilkottu risteyksistä vaikkei mikään attribuutti muutu
Yksisuuntaisuus on väärään suuntaan. On periaatteessa laillista myös osmissa laittaa oneway=-1, mutta myöhemmän editoinnin kannalta erittäin epäintuitiivista, parempi olisi vain kääntää kaikki sellaiset kohteet jo alkuunsa myötäsuuntaisiksi.
Ilmeisesti ainakin alueissa nodeja on vähän runsaammalla kädellä? teollisuudella taisi olla jotain tarkempaa huomioita tästä? (Myös viivamaisissa kohteissa olen ollut huomaavinani jonkun verran turhahkoja nodeja suorilla osuuksilla mutta ilmeisesti niitä on oleellisesti vähemmän joten ei välttämättä kannata vielä tässä vaiheessa niistä olla hirveän huolissaan, niitä voi ehkä poistella siinäkin vaiheessa kun vaikkapa tiestö on jo upittu osmiin, IMHO).
Ilmeisesti tuota copyright sivua saa muutettua pyytämällä lisäyksiä trac tickettien kautta (yleisenä huomiona se että sinne ei nykyään ilmeisesti haluta enää kauheasti national tasoa pienempien tahojen puumerkkejä vaan ne olisi tarkoitus laittaa tuonne wikiin vain), minusta posiki oli jo jossain vaiheessa sitä pyytämässä mutten sitten löytänyt koko tickettiä kun katsoin vähän sen jälkeen.
Saapi nähdä alkaako siinä vaiheessa osmin puolelta joku vihdoin haluamaan huhupuheita varmempia dokumentteja siitä että se on mml:llä ok että tuo on vaan siellä sivulla ja data menee eteenpäin odbl:nä (kohta). Joku maili tms. varmaan jo kävisi huomattavasti paremmin kuin “olen kysynyt” ja “niin ne sanoivat” tasoinen vakuuttelu. Ehkä jonkun muun pitäisi asiaa mml:ltä kysyä mailitse tyyliin: “olen kuullut … onko todella niin että on se riittää että on tuolla sivulla maininta … ja data menee sitten eteenpäin odbl lisenssillä” tms. jossei kerran sellaista “dokumenttia” tällä hetkellä tunnu löytyvän?
Onkohan MML:n aineistossa jotain ylikuormitusta (overload) talvisten elementtien suhteen yleisemminkin - en ole vientejä OSMiin MML-aineistosta tehnyt, mutta kun testimielessä tein muunnosta MML-aineistosta OSM-aineistoon (mm. sen taulukkolaskentaohjelmaformaatissa olevan dokumentin perusteella) niin näytti vähän oudolta miten monet metsäautotiet näkyivät talviteinä.
Kyseessä on todellakin MML:n luokka 12312 Talvitie. Kemijärven kylän lehtiössä ne on merkittynä polkuina ja viereisessä lehtiössä highway=roadina kuten wikin luokkaohjeistus on määritelty. Wikissä olevassa luokittelussa on määritelty lähes kaikki tiet roadeina. Tämä tarkoittaa, että lähes jokainen tie on todennettava jälkikäteen itse. Mielestäni tämä voitaisi koneellisesti arvioida mukana tulevan tienumeron ja mml:n luokan perusteella mihin OSM luokkaan tie kuuluu. Koska MML:n aineiston tiestö on pätkitty todella pieniin osiin ja vaatii aikamoista yhdistelyä jälkikäteen, olisi tässä hyvä myös olla joku menetelmä, joka osaisi yhdistellä tieviivat nimen, luokan ja päällysteen perusteella.
Maastotietokannasta suoraan otettujen maastoalueiden pistemäärät liikkuvat juurikin tasolla 60 000-150 000, tähän kun lisää päälle tiet ja viivat niin helposti ollaan yli 200 000 pistettä per karttalehtiö. Karttalehtiö vastaa noin 100 neliökilometriä joten koko Suomen tuonnissa puhutaan puolesta miljardista pisteestä. Sanottakoon että tällä hetkellä koko OSM käsittää 1,6 miljardia pistettä(nodes) joten siihen suhteutettuna puhutaan merkittävästä tuonnista. Mielestäni tuota pistemäärää voidaan juurikin vähentää esim soiden reunoilta, jotka eivät maastossakaan ole kovin selvärajaisia.
En tiedä ymmärsinkö oikein, mutta onko siis jossain joku wiki jossa on pohdittu/kirjattu MML:n luokkien ja OSM-tägien vastaavuuksia? Löysin vain http://wiki.openstreetmap.org/wiki/Fi:Maastotietokanta jota kautta ei ainakaan äkkivilkaisulla löydy.
Laitetaanpä nyt myös tämä päivitetty työversio MML → OSM-muunnoksesta nyt esille, tämä on hyvin niukasti tarkistettu ja varmasti buginen ja puuttellinen, eli ehdottomasti ei tule käyttää minkäänlaiseen massavientiin MML → OSM tässä muodossa. Mutta laitan esille, toivossa että tästä porukalla saisi jotain nykyistä hyödyllisempää. Tämä on se jolla on tehty tuossa gpsmid-mml.apk:ssa oleva esimerkkidata.
Mistähän tuo moottorikelkkaura / -reitti (snowmobile=yes) noille ilmestyi tuon talvitien (ice_road=yes) lisäksi? Esim: http://www.openstreetmap.org/browse/way/178398397/history
Näyttää olevan vielä versio 1, eli ei ole voinut periä saman tien vanhaa tagia?
Siitä en tiedä mitä muunnosta tuohon Kemijärven OSM-vientiin on käytetty, mutta ei tuota lähettämääni, en ole sitä noin laajana aiemmin minnekään jaellut. Ja tuossa minun muunnoksessani talvitie ei ole ice_road=yes vaan highway=winter_road.
Tuossa http://www.openstreetmap.org/browse/way/178398397/history -tiessä näkyy olevan highway=winter_road, ice_road=yes ja snowmobile=yes, ehkä sitten tuo muunnos & tuonti on tehty oletuksilla että talvitie on aina jäällä ja sitä saa aina ajella kelkalla. Tosin näyttäisivät olevan virheellisiä oletuksia, raportoivat kelkkapoliisin kertoneen, että autolle avoimilla jääteillä ei saa ajaa moottorikelkalla, kts. http://www.waasasnowmobile.fi/?p=8&s=0&m=0
Mutta kuten tästäkin ketjusta huomataan, ei kaikilla ole vielä selvyyttä lisenssikiemuroiden statuksesta, odottelen ensin josko jotain “virallisempaa” infoa asiasta tulisi.