Ahvenjärventie (Kangasala) katoaa tarkemmilla skaalaustasoilla

Se MML:n kanssa sorvattu MoU jää kyllä leijumaan tyhjän päälle. MML:llä ei ole asian kanssa mitään ongelmia. OSMerien sisäinen keskustelu ja konsensuksen löytäminen on nyt esteenä.

Tässä nyt muutamia kommentteja ylläolevaan keskusteluun:

  • MML:n puolesta heidän aineistojaan voi käyttää hyväksi OSM:n kartoituksessa: esimerkiksi ortokuva ja/tai peruskartta digitoinnin pohjana. IMHO: mielestäni tässä tapauksessa on kohteliasta liittää kohteisiin src-tag jossa on maininta MML:stä (tai NLSF tms.)
  • MML:n maastotietokannan kohteita voidaan importoida osaksi OSM:iä. Tällöin tulisi OSM:n Copyright sivulle (http://www.openstreetmap.org/copyright) lisätä maininta: "Finland: Contains data from National Land Survey of Finland, 2012 http://www.maanmittauslaitos.fi/avoindata_lisenssi_versio1_20120501. Näihin importoituihin kohteisiin (esimerkiksi puuttuvat ajotiet ja polut, rakennukset), voidaan/pitäisi liittää src-tagin viittaus MML:n.
  • Teknisiä linkityksiä ei kannata ruveta rakentamaan: MML:n uniikkien ID:eiden elinkaari ei ole toimiva.

Ja loput IRC:ssä…

Täsmälleen väärinpäin, eli nähdäkseni “produced work”:kejä voi tuollaisille triviaaleille toisistaan riippumattomille tietolähteille tuottaa odbl “collective DB” häkkyrän takia myös rasterina, Mutta monimutkaisempi “ristiin” käyttö kahden eri lisenssisen kannan välillä on sitten aika pitkälti harmaa alue josta ei suoraan sanota mitään lisenssissä “selvästi”, jää muutaman sanan tulkinnan varaan.


i.

a) Kiitos, unohdin tuossa ylläolevassa täysin tuon uuden lisenssin käsitteen “produced work”. Eli tosiaan yllämainittu rasterikartta nähtävästi menee produced workin piiriin, ja on sallittua. Produced work on jotain jossa ei liiku Derivative Database:

http://opendatacommons.org/licenses/odbl/1.0/

Ei-sallitusta olisi pitänyt kertoa alkuperäinen, ensiksi mieleen tullut esimerkki tästä hillasuotapauksesta. Eli: otetaan OSM-aineisto, liitetään siihen hillasuot, ja käännetään tämä OSM-vektoriaineisto sellaiseen muotoon, että se voidaan näyttää ja sitä voidaan tutkia vektoriaineistoa näyttävällä ja käsittelevällä ohjelmalla (esim. Osmand) mobiililaitteessa. Ainakin silloin, jos ohjelma (esim. Osmand) osaa tehdä rakenteisia hakuja tiedoista (esim. listata lähimpien hillasoiden etäisyydet) muuten kuin kuvankäsittelyä käyttämällä, hahmotan tämän niin että kyseessä on “Derivative Database”, ja kiellettyä ellei hillasuoaineistoa jaella.

b) Sitten kahden eri lisenssillä olevan kannan jakelu yhdessä paketissa. Minun nähdäkseni tästä löytyy erittäin selkeästi sallivat kohdat lisenssissä:

c) Sitten “ristiin käyttö”. Riippuu mitä “ristiin käytöllä” tarkoitetaan. Minun nähdäkseni ylläolevassa hillasuoesimerkissä ei ole mitään harmaata, ja se on täysin selkeästi sallittua, koska hillapaikkakanta on täysin riippumaton kanta OSMista, ja mitään "derivative database"a ei luoda, vaan kahta erillistä ja itsenäistä tietokantaa käytetään yhdessä ja piirretään niistä käyttäjälle kartta jossa näkyy OSM-kartta sekä hillapaikat.

Mutta harmaatakin aluetta toki löytynee. Sanotaanpa vaikka, että halutaan tarjota ajan tasalla olevat kattavat nopeusrajoitukset, ja hankitaan nämä vaikkapa Digiroad -aineistosta. Jostain syystä kuitenkaan ei haluta käyttää Digiroadin tiegeometrioita, vaan halutaan näyttää OSMin tiet. Eli lähtökohtana on kaksi kantaa: Digiroadista löytyvät nopeusrajoitukset, ja OSMin tiestö. Nämä kannat ovat itsenäisiä. Käyttäjälle on tarkoitus näyttää OSMin tiet navigaattorissa varustettuna Digiroadin nopeusrajoituksilla ja varoittaa ylinopeudesta tarvittaessa.

Nyt sitten kaksi skenariota:

c1) Mobiilissa pyörivä sovellus kohdentaa kahdesta käyttämästään kannastaan löytyvät tiedot keskenään: kohdistaa Digiroadin nopeusrajoituksen tienumeron ja geometrian perusteella vastaavalle tielle. Lopputuloksena oleva varsinainen kartta on peräisin OSMista. Tätä lopputulosta ei jaella eteenpäin, vaan ainoastaan näytetään sovelluksessa käyttäjälle. Nopeusrajoituksia mahdollisesti näytetään ikoneina tai värityksellä OSM-kartan päällä. Tässä ei nähdäkseni ole mitään ongelmaa, vaan menee selvästi sallitun puolelle: mitään derivative databasea ei jaella. Vaikka lisättäisin OSM-teiden värittäminen nopeusrajoituksen mukaan eli kartta sisältäisi kahdesta eri kannasta olevaa tietoa, edelleen oltaisiin selvillä vesillä, ymmärtääkseni sekä 1) kyseessä kaksi itsenäistä, erillistä kantaa että 2) näytetty kartta on Produced Work. 2) -kohdan perusteella tällä piirrettyä rasterikarttaa voisi vaikka jaellakin ongelmitta.

c2) Tehostaakseen mobiilisovelluksen toimintaa, sovelluksen jakelija esiprosessoi ennen Digiroad-kannan jakelua Digiroad-kannan sellaiseen muotoon, että siitä löytyvät suorat viitteet OSMin tiesegmentteihin. OSM-kanta pistetään sovelluksen mukana jakeluun sellaisenaan, sitä ei muokata. Kysymys: kun Digiroad-kannan esiprosessointiin käytetään OSM-kannan tietoja, onko esiprosessoitu, OSM-way-id:t sisältävä Digiroad -kanta tämän vuoksi “Derivative Database” OSM-kannasta? Ainakaan se ei enää ole täysin itsenäinen kanta. Jos kyseessä on Derivative Database, sen jakelu ilmeisesti ei ole sallittua koska Digiroadin lähdeaineistoa ei voida julkaista. Tässäkin tapauksessa käsittääkseni lopputulos eli esim. nopeusrajoitusten perusteella väritetty OSM-kartta olisi Produced Work ja sitä saisi jaella. Mutta mahdollisesti jos haluaa olla varmasti selvillä vesillä, tuollainen esiprosessointi joudutaan jättämään tekemättä. Vai mitä sanoo raati?

Lisenssi:

skela:

Ja nyt kun katson tätä tapausta lisenssin lukemisen jälkeen, niin hyödylliseltä näyttää. Jos nyt jätetään tarkastelematta noiden multipolygon-relaatioiden luontiin ja jakeluun liittyvät tekijänoikeudelliset ja lisenssioikeudelliset ja tietokantasuojaan liittyvät kysymykset, niin kyllä tuollaisilla multipolygoneilla voisi kattavaa karttaa piirrellä yhdistellen OSM-kannasta ja MML-kannasta. Ja jaella karttaa rasterina (produced work) tai vektorina (kunhan jaellaan kumpikin omassa kannassaan).

Sitten OSM-lisenssiopillinen pähkinä pohdittavaksi: Voiko lisenssin "Produced Work"in “work (such as an image, audiovisual material, text, or sounds)” olla vektorimuotoinen? Eli jos OSMista konvertoidaan alue kuvaksi piirtämistä varten, voiko tämä kuva koostua joukosta piirtovektoreita? Näyttäisi, että esim. nykyaikaisissa Android-puhelimissa voi olla tehokkuuden kannalta mielekästä esittää kuvat (image) mieluummin vektoreista koostuvina datajoukkoina kuin bittikarttoina.

Jatkopähkinä: Jos meillä on OSM-ODbL-datasta (joka koostuu vektorimuotoisesta datasta ja metatiedosta esim. nimet) generoitu vektorijoukko, miten arvioidaan, onko kyseessä “derivative database” vai “produced work”? Käyttötarkoituksen mukaan? Käyttömahdollisuuksien mukaan? Riippuuko luonne esimerkiksi siitä, voidaanko vektorijoukosta tehdä hakuja, eli siitä, jos sitä voidaan käyttää kuvatarkoituksen ohella myös hakuihin?