Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

ij_ · 2012-09-06 10:11:31

HACY wrote:

Onhan vielä olemassa radikaali "plan b", eli ilmiannetaan osm:lle Kemijärven alueella tapahtunut ilkivalta - aiemman osm datan hävitys sekä lisenssien vastainen copyrightin alaisen datan massasyöttö samalle alueelle.
http://wiki.openstreetmap.org/wiki/Vandalism
Tai sitten myös radikaali "plan c", eli pyydetään suunnitelman mukaisesti osm:ää laittamaan maininta MML:stä sinne copyright sivulle, ja kun se on siellä, ilmiannetaan MML:lle Kemijärven alueella tapahtunut MML lisenssin vastainen datan syöttö OSM:ään. Sen jälkeen saataneen MML:n kannanotto onko lisenssiä heidän mielestään rikottu.

Minä olen kokoajan tässä toivonut että teollisuus ymmärtäisi itse hoitaa revertoinnit mutta alkaapi näyttämään siltä ettei kaverilla ole aikomusta perääntyä.

--
i.

ij_ · 2012-09-06 11:42:48

Katos vaan, ei välttämättä olekaan maailman yksinkertaisin juttu tuo revertti ku tuolla on tollanen 50k noden monsteri changesettikin joukossa, API antaa niistä avuliaasti out-of-memoryä. Pitänee kaivaa se changeset minutelyistä sitten näemmä.

--
i.

JRA · 2012-09-06 13:55:42

Minä en ole importtien ystävä ollenkaan, mutta kyllä minun mielestäni on silti parempi, että Kemijärven importti on tehty kuin jos sitä ei olisi tehty. Keskustelua syntyi ja ongelmia löytyi, eikä maailma vielä ole tuohon kokeiluun kaatunut.

Latuviitan Latuviitan WFS-palvelussa MML mainitaan lähteenä ainoastaan palvelun metadatassa, jonka saa pyynnöllä

http://188.64.1.61/cgi-bin/tinyows?service=WFS&version=1.0.0&request=GetCapabilities

Vastauksen XML:n seassa lukee

Contains spatial data from the National Land Survey of Finland (NLS)
NLS open license http://www.maanmittauslaitos.fi/ilmaisetaineistot

WFS-palvelusta tosin saa dataa ulos ilman, että koskaan käy lukemassa moisia metadatoja

http://188.64.1.61/cgi-bin/tinyows?service=WFS&version=1.1.0&request=GetFeature&typeName=lv:mml_paikannimet20&maxFeatures=20

MML:n mielestä lähteen ilmoittaminen palvelun GetCapabilities-metadatassa on välineelle eli WFS-palvelulle ominainen tapa ja se tyydyttää heitä, kuten minuakin (tämä kerrottiin sähköpostissa, jonka olen hävittänyt, mutta se ei tullut lakimiehiltä eikä ylijohtajalta, joten se ei täyttäisi OSM-virallisuusvaatimuksia, vaikka olisikin tallessa).

Kemijärven koepalassa joka kohteelle on annettu "source" ja "mml:class" joten lähdeviittaukset ovat vahvemmat kuin latuviitan WFS:ssä, joten kyllä ne riittävät MML:lle, ja vielä varmemmin sitten kun OSM-wikissä on maininta tuosta tietolähteestä. Lisenssin takia tuonnin peruminen on ylimitoitettu reaktio. Jos tuonti kuitenkin perutaan, niin otetaan sekin sitten harjoittelun kannalta ja opiksi tulevaisuutta varten, niin että jatkossa tietoja osataan sekä tuoda että tunteja perua tehokkaalla tavalla.

ij_ · 2012-09-06 14:14:04

JRA wrote:

Jos tuonti kuitenkin perutaan, niin otetaan sekin sitten harjoittelun kannalta ja opiksi tulevaisuutta varten, niin että jatkossa tietoja osataan sekä tuoda että tunteja perua tehokkaalla tavalla.

Valitettavasti se vaan taitaa olla niin että isot määrät dataa on liian helppoa importata suhteessa siihen työmäärään mitä niiden revertoiminen vaatii. On aivan selvää että tuo importti pitää kokonaisuudessaan perua ja toteuttaa kunnolla. Valitettavasti en ole kovin vakuuttunut kyllä siitä että vastaisuudessakaan tulos tulee olemaan kovin hyvä jos tuon kaverin asenne muiden keräämää dataa kohtaan ei muutu. Ja siksi osmissa on ne import säännötkin ja myös mml:n datojen kohdallakin on toimintatavoista puhuttu "yhteisössä" aivan selvästi ettei dataa vaan lähdetä poistelemaan kuten tuossa tapauksessa on tehty. Miksi tämä tuntuu niin vaikealta käsittää kun tuntuu että kovasti jossitellaan vaikka homma tehty yksinkertaisesti väärin ja vastoin toimintaperiaatteita? Siksikö että se on niin kivannäköinen katsella?!? Kyllä se tulee kivannäköiseksi myös oikein tehtynä mutta silloin myös ne mapnikissa näkymättömät tuhot jäävät aiheuttamatta. Tai se vaatii työtä? Niin se tekee juu, ja sen välttämiseksi olisi ollut ne import ohjeistukset mutta minkäs sille mahtaa jossei niistä piitata.

--
i.

Last edited by ij_ (2012-09-06 14:15:50)

teollisuus · 2012-09-06 15:52:03

Koeimporttauksen perusteella suurimmaksi kynnyskysymykseksi on näköjään noussut yhä enemmän vanhan ja uuden datan integrointi. Mielestäni teiden säilytyksessä/poistossa tulisi pyrkiä säilyttämään toisten tekemä työ mikäli
tiet ovat tarkkuudeltaan riittäviä. Useassa tapauksessa Landsat aineiston yhteenliittäminen MML:n aineistoon ei tullut kysymykseen, koska tiet olivat yli sata metriä väärässä paikassa ja halkoivat maastoalueita tavalla, joka ei vastannut todellisuutta(tavalla joka olisi johtanut kartankäyttäjän harhaan maastossa). MML:n aineiston tiet ovat mitattu silmälläpitäen hälytysajoneuvoliikennettä, ja niiden tarkkuus on todella hyvä(alle puoli metriä). Taas voimme ottaa kantaa siihen kuinka tarkasti haluamme OSM:n vastaavan todellisuutta? GPS laitteen kanssa mitoitetut tiet kuuluvat mielestäni riittävällä tarkkuudella tehtyihin teihin ja ne tulisi säilyttää.

Ennakkotapauksen ajatus on mielestäni hyvä, sillä saisimme tiedon kuinka kehittää attribuutiota/lisensointia eteenpäin myös itse Maanmittauslaitokselta. En näe asiaa kovin radikaalina, sillä kyseessä on lainvoimanen viranomaistaho, jolta asiaa on kysyttävä kuitenkin. Mikäli näin ei haluta kuitenkaan tehdä, voisin aloittaa revertoinnin jo tänäiltana, sillä aineistoa on tullut riittävästi importoinnin kehitysehdotuksiksi.

HACY · 2012-09-06 16:30:51

teollisuus wrote:

... Mielestäni teiden säilytyksessä/poistossa tulisi pyrkiä säilyttämään toisten tekemä työ mikäli
tiet ovat tarkkuudeltaan riittäviä...

Et ole sisäistänyt openstreetmapin syvintä olemusta. Vähän sama kuin jos ehdottaisi Wikipedian sisällön hävittämistä ja korvaamista Encyclopedia Britannican sisällöllä.

.

PS:

ij_ wrote:

On aivan selvää että tuo importti pitää kokonaisuudessaan perua ja toteuttaa kunnolla.

+1.

ij_ · 2012-09-06 22:11:39

teollisuus wrote:

Koeimporttauksen perusteella suurimmaksi kynnyskysymykseksi on näköjään noussut yhä enemmän vanhan ja uuden datan integrointi. Mielestäni teiden säilytyksessä/poistossa tulisi pyrkiä säilyttämään toisten tekemä työ mikäli
tiet ovat tarkkuudeltaan riittäviä. Useassa tapauksessa Landsat aineiston yhteenliittäminen MML:n aineistoon ei tullut kysymykseen, koska tiet olivat yli sata metriä väärässä paikassa ja halkoivat maastoalueita tavalla, joka ei vastannut todellisuutta(tavalla joka olisi johtanut kartankäyttäjän harhaan maastossa). MML:n aineiston tiet ovat mitattu silmälläpitäen hälytysajoneuvoliikennettä, ja niiden tarkkuus on todella hyvä(alle puoli metriä). Taas voimme ottaa kantaa siihen kuinka tarkasti haluamme OSM:n vastaavan todellisuutta? GPS laitteen kanssa mitoitetut tiet kuuluvat mielestäni riittävällä tarkkuudella tehtyihin teihin ja ne tulisi säilyttää.
Ennakkotapauksen ajatus on mielestäni hyvä, sillä saisimme tiedon kuinka kehittää attribuutiota/lisensointia eteenpäin myös itse Maanmittauslaitokselta. En näe asiaa kovin radikaalina, sillä kyseessä on lainvoimanen viranomaistaho, jolta asiaa on kysyttävä kuitenkin. Mikäli näin ei haluta kuitenkaan tehdä, voisin aloittaa revertoinnin jo tänäiltana, sillä aineistoa on tullut riittävästi importoinnin kehitysehdotuksiksi.

Uskon toki, että tie joka on landsatistä piirretty voi hyvinkin olla 50-100m sivussa tai koko tietä ei edes ole vaan tilalla on joku oja tai mikä lie metsään leikattu aukko tai jotain. Mutta tarkastiko asiaa sen enempää esim. objektien historiasta (kaikkien poistettujen)? Se että arvataan että niin on ei ole tyydyttävä toimintatapa. Joku niistä saattaisi olla jälkeenpäin myös gps:llä kartoitettu.

Itse olen sitä mieltä että pääosa mml:n geometrioista on parempaa laatua kuin gps pohjaisetkin tiet, mutta asia kannattaa aina tarkistaa ilmakuvaa apuna käyttäen ennen päätöksen tekemistä (jotain tarkkuusanalyysiäkin voisi virittää mml vs osm way virheestä jos saisi noita jotenkin järkevästi yhdistettyä kannassa toisiinsa ja todeta että osmissa on kökköä koko tie "algoritmi suosittelee tämän tien geometria korvausta - yes no?" tms, joku sellanen hyppää seuraavaan kohtaan plugini josmille ilmeisesti olisi jota voisi ehkä hyödyntää nopetuttamaan tuollaista editointia). Hyvin kohdilleen prosessoiduista ilmakuvasta pystyy yleensä piirtämään mml:n tasoisesti ja jopa paremmin, koska mml:llä olen havainnut ainakin jonkun verran oikomista jotka ovat ilmakuvaan verrattaessa ilmeisiä tarkkuusvirheitä.

Alle puolta metriä en usko, eikä usko mml:kään itse vaan ilmoittaa tarkkuudeksi huomattavasti suurempiakin numeroita (toki osa teistä on <0.5m tasoa toki, kadut luultavasti ovat aina ns. riittävän tarkkoja mutta jo vierellä kulkevissa pyöräteissä on oikomista näkynyt). Siitä huolimatta ne ovat silti niin hyvin kohdillaan että selvää on että pääosa osmin _geometrioista_ kannattaa korvata mml:n geometrioilla. Mutta osmissa on muutakin kuin geometrioita, ja se muu tieto+sen tiedon historia tulisi säilyttää. Eli way säilytetään mutta sen nodet korvautuvat käytännössä mml:stä kaivetuilla vastineilla. En tiedä kuinka hyvin nuo conflation työkalut osaavat tuon säilytyksen tehdä, asia tulisi selvittää (muutoin kuin suurilla testeillä, mielellään pelkälle .osm tasolle jääviä kokeita). Tai jos tyydyttäviä työkaluja ei löydy niin täytyy itse tehdä operaatiot kannassa.

Mitä revertiin tulee katsoin asiaa tuossa itse ja totesin että se ei välttämättä ole myöskään aivan triviaali operaatio, arvostan kuitenkin sitä että olet siihenkin nyt valmis :-) (näyit itseasiassa jo aloittaneenkin).

Tärkeä juttu muuten changesettien koosta: älkää laittako 50k objektia samaan changesettiin, API ei pysty palauttamaan sitä vaan muisti loppuu jossain kohtaa ja tulee vaan virhettä (siksi yhden noista changeseteistä .osc tiedoston downaaminen ei onnistu lainkaan, tuo .osc ongelma saattaa tuottaa harmaita hiuksia revert työkaluillekin). Importtien tiukat vastustajat itseasiassa haluaisivat limitin jonnekin 10k-5k luokkaan joka ehkä olisi järkevän oloinen arvo jota ei kannata yhdessä changesetissä ylittää.

--
i.

Last edited by ij_ (2012-09-06 22:14:39)

muistikas · 2012-09-07 08:13:53

ij_ wrote:

selvää on että pääosa osmin _geometrioista_ kannattaa korvata mml:n geometrioilla. Mutta osmissa on muutakin kuin geometrioita, ja se muu tieto+sen tiedon historia tulisi säilyttää. Eli way säilytetään mutta sen nodet korvautuvat käytännössä mml:stä kaivetuilla vastineilla.

Tätä mieltä olen minäkin. Tietääkö kukaan, antaako MML aineistossaan arvioita kohteen geometrian tarkkuudesta? Jos antaa, sitä voisi hyödyntää. Joka tapauksessa jonkinlainen geometrian vertailu MML<->OSM pitäisi aina MML kohdetta vietäessä. Jos sillä kohdalla ei ole mitään vastaavaa geometriaa (jollain puskurilla tarkistettuna), MML-kohteen voinee viedä huoletta. Jos kohdalla on vastaava geometria ja voidaan jollain syyllä olettaa, että MML geometria on tarkempi, viedään geometria ja yhdistetään jollain nerokkaalla algoritmilla MML ja olemassaolevan koheen ominaisuustiedot.

Kuulostaa yksinkertaiselta ja sitä se ei varmasti ole. Lisäksi pitää harkita seuraavia operaatioita viennin ohessa:
- MML aineiston yksinkertaistaminen ja yleistäminen (OSM on tiekartta ja sen tarkkuus ainakin harvemmin asutuilla alueilla voi varmaankikn olla MML tarkkuutta huonompi, tai siis yleistetympi)
- Relaatioiden automaatinen muodostaminen (en osaa antaa esimerkkejä, en ole asiantuntija relaatioden suhteen)

Minusta kannattaisi viedä aineistoa sekä alue että karttataso kerrallaan, aloittaen kenties joistain "helpoista" kohteista tai sellaisista, joita on vähän OSM:ssa tällä hetkellä. Yksi mieleentuleva helpoista kohteista saattaisi olla rakennukset.

Lisäksi voisi harkita jonkinlaista OSM-aineiston "suojaamista" siten, että joitain alueita rajattaisiin MML-aineiston tuonnilta kokonaan pois.

teollisuus · 2012-09-07 09:05:19

Revertti on tosiaankin käynnissä(saadaan sitten tästäkin vaiheesta dokumentaatiota). Käytännössä palautus tapahtuu käyttämällä JOSMin Reverter-pluginia, jolla muutoskokoelmat voidaan kumota yksi kerrallaan. Skelan ohjeiden mukaisesti Kemijärvi ympäristöineen löytyy tältä koneelta tallesta kaikessa maastotietokantaloistossaan mikäli se myöhemmin halutaan takaisin. Toivon saavani alueen ennalleen viimeistään huomenna. Jätän ensimmäisen tuomani mökin kuitenkin ennalleen siltä varalta että sitä voidaan käyttää MML:n mielipiteen kysymiseen.

ij_ · 2012-09-07 10:35:35

muistikas wrote:

ij_ wrote:
selvää on että pääosa osmin _geometrioista_ kannattaa korvata mml:n geometrioilla. Mutta osmissa on muutakin kuin geometrioita, ja se muu tieto+sen tiedon historia tulisi säilyttää. Eli way säilytetään mutta sen nodet korvautuvat käytännössä mml:stä kaivetuilla vastineilla.
Tätä mieltä olen minäkin. Tietääkö kukaan, antaako MML aineistossaan arvioita kohteen geometrian tarkkuudesta? Jos antaa, sitä voisi hyödyntää.

MML:llä on se joku tarkkuusluku, en nyt muista avaimen nimeä mutta se on suht oikean suuntainen TAR jotainkin taisi olla ihan nimessäkin. Erittäin vähän olen niihin perehtynyt mutta vaikutelmani oli se että tiet olivat pääsääntöisesti <10m tarkkuusluvulla, paljolti muistaakseni 3m ja 5m annettu vaikka käytännössä ne ovat kyllä paremmin. Jotain peakkeja mitä katsoin joskus aiemmin oli sitten suuremmillakin luvuilla, 30m ja 50m ainakin taisi olla (eivät ehkä kaikille vähemmän merkitseville huipuille ole kiivenneet niin tarkkaan mittaamaan, tosin luulisi LAS aineistosta saavan aika hyvin <30m tarkkuuksiakin :-)).

Joka tapauksessa jonkinlainen geometrian vertailu MML<->OSM pitäisi aina MML kohdetta vietäessä. Jos sillä kohdalla ei ole mitään vastaavaa geometriaa (jollain puskurilla tarkistettuna), MML-kohteen voinee viedä huoletta. Jos kohdalla on vastaava geometria ja voidaan jollain syyllä olettaa, että MML geometria on tarkempi, viedään geometria ja yhdistetään jollain nerokkaalla algoritmilla MML ja olemassaolevan koheen ominaisuustiedot.

Nämä sinun puskuriajatukset ovat varsin lähellä sitä mitä olen jo hiukan kehitellytkin. Laskin jo Suomen laajuisesti 30-50m bufferilla täysin overlappaamattomia teitä olevan 46%-60% mml:n pätkityistä teistä (en nyt enää muista tarkkoja arvoja). Ajattelin että niitä voisi ruutu kerrallaan alkaa importtaamaan kuhan lisenssiasiat ovat selviä. Myös vesistä laskin jotain arvoja ja ne olivat samansuuntaisia (tosin tarkastelin vain yhdessä ruudussa kokonaan sijaitsevia kohteita, joten numero vois olla vielä isompikin). Samanlaisia juttuja kannattaa virittää toki taloillekin. Käytännössä tuota varten tarvitsee kannan jossa on suomen .osm ja mml:n tavarat sisällä. Itselläni on osm2pgsql:llä importattuna nyt myös versiot ja userid:t mukana niin pystyy miettimään olemassaoleviin juttuihin yhdistelyäkin kun pystyy generoimaan oikein versioidut .osm:t yhtymäkohtiin (pitäisi vielä importata uusiksi hstoren kanssa kaikki avaimet niin voisi toistaa keyval datatkin täydellisesti niille olemassaoleville objekteille kun niihin tarvitsee joku jännä yhdistysoperaatio suorittaa, vaikkapa vieresten ruutujen saman tagisten teiden yhdistys yhdeksi wayksi (kun se toinen ruutu tuli jo aiemmin upittua)).

Tuota tarkkuuslukua ajattelin koittaa myös sillä lailla että luon sen kokoisen puskurin ja vertaan onko osm way sillä kohtaa kauniisti jolloin voidaan siirtää geometrian korvausta hamaan tulevaisuuteen jos sitä ikinä tarvitsee edes tehdä, mutta en ole vielä koittanut mitään toteuttaa. Nimi ja ref pohjaista vastinpari etsintää/tietojen täydennystä en ole vielä lähtenyt säätelemään. Tähän liittyä haaste on vakio-offsetit, esim. porvoossa oli pitkään suuri alue tasan korttelin verran sivussa joten algoritmit helposti erehtyisivät kuvittelemaan että kuljetaan vieresellä kadulla jos nimiä yms. tietoja tai topologiaa ei tarpeeksi syvälle lähdetä analysoimaan (siksi ne oikeat conflation algorithmit olisivat ehkä turvallisempia kun ne ilmeisesti ovat enemmän topologia kuin sijainti perustaisia matchejä tuottavia).

Kuulostaa yksinkertaiselta ja sitä se ei varmasti ole. Lisäksi pitää harkita seuraavia operaatioita viennin ohessa:
- MML aineiston yksinkertaistaminen ja yleistäminen (OSM on tiekartta ja sen tarkkuus ainakin harvemmin asutuilla alueilla voi varmaankikn olla MML tarkkuutta huonompi, tai siis yleistetympi)

- Relaatioiden automaatinen muodostaminen (en osaa antaa esimerkkejä, en ole asiantuntija relaatioden suhteen)

En ymmärtänyt mitä ajoit takaa tällä kommentilla? Minkä tyyppisistä relaatioista oli tässä puhe?

Minusta kannattaisi viedä aineistoa sekä alue että karttataso kerrallaan, aloittaen kenties joistain "helpoista" kohteista tai sellaisista, joita on vähän OSM:ssa tällä hetkellä. Yksi mieleentuleva helpoista kohteista saattaisi olla rakennukset.
Lisäksi voisi harkita jonkinlaista OSM-aineiston "suojaamista" siten, että joitain alueita rajattaisiin MML-aineiston tuonnilta kokonaan pois.

Kannatan ajatustasi työn jakamista objektityyppeihin: rakennukset, tiet, meren saariston rantaviivat, vedet (järvet ja joet varmaan samalla), sähkölinjat. Käytännössä nuohan ovat varsin hyvin toisistaan riippumattomia. Tosin rantaviivoihin ja vesiin saattaa liittyä joitain muita maastokohteita kiinni (tietääkö teollisuus tai joku muu miten ne käytännössä menee?), joka tarvitsee sitten myöhemmässä vaiheessa kaivaa osmista yhteenliittämistä varten. Sähkölinjoja on varsin paljon jo piirrettynäkin, vaihtelevalla tarkkuudella joten se voi olla kaikkein haasteellisin noista koska osa on osmissa jo paremmin tai ainakin riittävän hyvin (mml:n tarkkuudesta ei minulla ole käsitystä niiden osalta). Myös huippuja joku voisi koittaa katsoa, minä en ainakaan heti keksinyt miten niiden nimet liitetään itse kohteisiin (en itseasiassa tainnut edes löytää vielä niitä nimiä).

Rautatiet on pääosin jo osmiin piirretty vaikkakin sijaintitarkkuus voi olla mml:llä parempi moninpaikoin. Risteämiset ovat haasteellisempia hoitaa nätistä tiestön kanssa, erityisesti jos molempia käsitellään samaan aikaan, joten jättäisin ratojen säätelyt myöhemmäksi.

--
i.

muistikas · 2012-09-07 14:30:08

ij_ wrote:

MML:llä on se joku tarkkuusluku, en nyt muista avaimen nimeä mutta se on suht oikean suuntainen TAR jotainkin taisi olla ihan nimessäkin.

Tarkoitin horisontaalista tarkkuutta. Tekstistäsi sai käsityksen, että tarkoittaisit vertikaalista tarkkuutta.

Ajattelin että niitä voisi ruutu kerrallaan alkaa importtaamaan kuhan lisenssiasiat ovat selviä.

Minusta kannattaisi tehdä kokeilut omalla koneella. Netistä löytyy ainakin kaksi ohjetta oman OSM-palvelimen pystyttämiseksi:
http://jaspreetchahal.org/setting-up-yo … ap-server/
http://www.weait.com/content/build-your … map-server (ei juuri nyt toiminut).
Disclaimer: Minulla ei ole vielä ohjeista kokemusta, en tiedä saako niillä aikaiseksi riittävän toimivan ja toiminnallisen palvelun, jolla voisi muokkausta, tietojen lataamista yms. testata.

- Relaatioiden automaatinen muodostaminen (en osaa antaa esimerkkejä, en ole asiantuntija relaatioden suhteen)
En ymmärtänyt mitä ajoit takaa tällä kommentilla? Minkä tyyppisistä relaatioista oli tässä puhe?

Kuten kirjoitin, en oikein tunne noita relaatioita, mutta sellainen käsitys minulle on tullut, että niitä tarvitaan mm. pitkien rantaviivojen kanssa.

Kun importointia lähdetään oikeasti toteuttamaan, olisi seuraavankaltainen palvelu hyvä olla olemassa:
- palveluun tallentuisi ne MML:n aineiston kohteet, joita ei ole saatu talletettua OSM:iin
- palvelu tarjoaisi aineiston WFS- tms. muodossa, josta aineiston voisi kopioida jotenkin interaktiivisesti OSM:iin (taustakarttana tms.)
- jos käyttäjä saa kohteen kopioitua, se ei enää palvelussa näkyisi.

Edellä on alustavaa ajattelua, jonka tarkoituksena on pyrkiä maksimoimaan MML:n aineiston hyödyntäminen.

Lisäksi tarvitaan toinen palvelu, jossa säilytetään pelkästään MML:n aineistoa ja josta saadaan tulevaisuudessa ne toivotut diffit, eli kun MML päivittää aineistoaan, tämä palvelu jotenkin ylimaagisesti pystyisi tuottamaan esim. WFS- tms. jossain vastaavassa käyttökelpoisessa muodossa ainoastaan muutokset edelliseen MML:n toimitukseen. Tai vaihtoehtoisesti MML itse toteuttaisi tällaisen palvelun.

skela · 2012-09-07 16:24:47

muistikas wrote:

Kuten kirjoitin, en oikein tunne noita relaatioita, mutta sellainen käsitys minulle on tullut, että niitä tarvitaan mm. pitkien rantaviivojen kanssa.

Reikäisiin alueisiin (pelto keskellä metsää tai metsä keskellä peltoa tai saari keskellä järveä) tarvitaan multipolygon-relaatioita. Muita relaatioita ei taida MML:n aineistosta muodostua, paitsi tietysti boundary-relaatiot aluerajoja varten. Muita relaatioita ovat muunmuassa reittirelaatiot, esimerkiksi bussireitit tai vaikka eurooppatiet (E75 yms.).

Tuota importointia voisi tosiaankin harjoitella omalla OSM-palvelimella. Voin osallistua testaamiseen ajamalla dumpista mkgmapia ja OsmAnd-kartankääntäjää ja raportoimalla virheistä. Luulen, että importteja pitää ajaa monta kertaa ’puhtaalta pöydältä’ uusiksi, ennen kuin tuontialgoritmit ovat kunnossa. Käsisäätöä kannattaa tehdä vasta sitten, kun automaatti toimii riittävän hyvin.

Last edited by skela (2012-09-07 16:25:06)

teollisuus · 2012-09-07 17:21:14

Revertoinnissa ei ollut mitään ylitsepääsemättömiä ongelmia ja kaikki changesetit on nyt järjestelmällisesti revertoitu lopusta alkuun. Vertasin Kemijärven nykytilannetta alkutilanteeseen enkä nähnyt mitään muutosta JOSMin eri layereiden välillä. Mikäli jotain kuitenkin puuttuu/on muuttunut saadaan se palautettua kyseisen objektin ID:n avulla.

ij_ · 2012-09-07 20:47:44

skela wrote:

muistikas wrote:
Kuten kirjoitin, en oikein tunne noita relaatioita, mutta sellainen käsitys minulle on tullut, että niitä tarvitaan mm. pitkien rantaviivojen kanssa.
Reikäisiin alueisiin (pelto keskellä metsää tai metsä keskellä peltoa tai saari keskellä järveä) tarvitaan multipolygon-relaatioita. Muita relaatioita ei taida MML:n aineistosta muodostua, paitsi tietysti boundary-relaatiot aluerajoja varten. Muita relaatioita ovat muunmuassa reittirelaatiot, esimerkiksi bussireitit tai vaikka eurooppatiet (E75 yms.).

Jeps, tosi iso järvi tarvitsee multipolygonia mutta niissä lienee joka tapauksessa saaria ja kait isohkot järvet ovat kai jo osmissa jotenkuten piirrettynä joten se menee kuitenkin käsityöksi pääosin? Vetäisin raakan importtina vain niitä ei overlappaavia ja muut ihmisharkinnan jälkeen (osa rantaviivasta voi olla hyvästäkin ilmakuvasta joten ei voi ihan suoraan sanoa että kaikki rannat on huonosti).

Tuota importointia voisi tosiaankin harjoitella omalla OSM-palvelimella. Voin osallistua testaamiseen ajamalla dumpista mkgmapia ja OsmAnd-kartankääntäjää ja raportoimalla virheistä. Luulen, että importteja pitää ajaa monta kertaa ’puhtaalta pöydältä’ uusiksi, ennen kuin tuontialgoritmit ovat kunnossa. Käsisäätöä kannattaa tehdä vasta sitten, kun automaatti toimii riittävän hyvin.

Olisihan tuolla tuo dev apikin olemassa. Sinne tosin pitää ensin itse kait uppia myös suomen osm kopiota jos siellä harjoittelee koska se ei kai mitenkään trackkää db:tä.

--
i.

ij_ · 2012-09-07 21:25:22

muistikas wrote:

ij_ wrote:
MML:llä on se joku tarkkuusluku, en nyt muista avaimen nimeä mutta se on suht oikean suuntainen TAR jotainkin taisi olla ihan nimessäkin.
Tarkoitin horisontaalista tarkkuutta. Tekstistäsi sai käsityksen, että tarkoittaisit vertikaalista tarkkuutta.

TASTAR on horisontaalista tavaraa. Tuolla on näemmä KORTAR kanssa mutta en muista siitä mitään, en ole ehkä edes katsonut.

Ajattelin että niitä voisi ruutu kerrallaan alkaa importtaamaan kuhan lisenssiasiat ovat selviä.
Minusta kannattaisi tehdä kokeilut omalla koneella.

No niinhän olen jo tehnytkin :-). Pikkasen vielä kun jatkan jo tehtyjä juttujan niin saan ulostettu myös niin ei-overlappaavien osien .osm tiedostoja joita on varsin helppoa arvioida juurikin "omalla koneella", Mutta vain siihen asti minusta "kokeilu" on mielekäs ja hyödyllinen (voi tarkistaa että oikeasti ovat ei overlappaavaa tavaraa ja oikein kiinni toisissaan jne.). ...Ei upload vaiheen "kokeilussa" minusta ole paljoa mieltä, se on itsessään mekaaninen operaatio josmilla jonka "testaamiseen omalla koneella" en näe mitään syytä. Lisäksi niitä .osm:eja pystyn toki takaisinkytkemään tietokantaani jos tarvitsen jotain yhdistelytestiä varten.

Kun importointia lähdetään oikeasti toteuttamaan, olisi seuraavankaltainen palvelu hyvä olla olemassa:
- palveluun tallentuisi ne MML:n aineiston kohteet, joita ei ole saatu talletettua OSM:iin
- palvelu tarjoaisi aineiston WFS- tms. muodossa, josta aineiston voisi kopioida jotenkin interaktiivisesti OSM:iin (taustakarttana tms.)
- jos käyttäjä saa kohteen kopioitua, se ei enää palvelussa näkyisi.
Edellä on alustavaa ajattelua, jonka tarkoituksena on pyrkiä maksimoimaan MML:n aineiston hyödyntäminen.
Lisäksi tarvitaan toinen palvelu, jossa säilytetään pelkästään MML:n aineistoa ja josta saadaan tulevaisuudessa ne toivotut diffit, eli kun MML päivittää aineistoaan, tämä palvelu jotenkin ylimaagisesti pystyisi tuottamaan esim. WFS- tms. jossain vastaavassa käyttökelpoisessa muodossa ainoastaan muutokset edelliseen MML:n toimitukseen. Tai vaihtoehtoisesti MML itse toteuttaisi tällaisen palvelun.

Vähän epäilen että jäävät kyllä toteuttamatta. Vaikka nuo ei tallennetut kohteet ovat jotenkuten laskettavissa, se ei ole hirveän halpa operaatio ja vaatisi käytännössä jotain conflation algoritmia toimiakseen "alkuvaiheessa" jolloin tiet ovat vielä vähän vinksin vonksin, ja sille ei ainakaan vielä ole täällä ilmoittautunut vapaaehtoista toteuttajaa ;-). Se openjump moduuli on ilmeisesti suljettua koodia(?) joten siitä ei välttämättä ole kauheasti hyötyä jos sitä nyt muutenkaan saisi tietokantaan järkevästi kytkettyä automaattiin kiinni. Periaatteessa jotain ajatuksia conflation algoritmista löysin kyllä, mutta vaatisivat ilmeisesti jotain clusterointi lisäosaa postgisiin niin ole antanut asian olla, ainakin toistaiseksi omalta osaltani. Siinä vaiheessa kun tavara alkaa olemaan about kohdallaan tuo matchays helpottunee.

MML:llä on muuten joku beta muutos palvelukin nykyään, en ole perehtynyt mutta huomasin joku viikko sitten. MML old vs MML new diffaus olisi kuitenkin toteutettavissa ilman että he toimittaisivat diffejä joten en ole siitä hirveän huolissani vaikkeivat diffejä tarjoaisikaan.

Paikallisesti minulla oikeastaan toki on "palvelu" jolla pystyn tuollaisia laskemaan, mutta se ei ole mikään n kertaa sekunnissa raksutettava operaatio miltään hiukankaan suuremmalta alueelta. Suomen prosessointi kesti 30min-1h iirc ja siinä oli ihan triviaalitarkistuksia vasta tehtynä. Monimutkaisempi analyysi vaatii vielä huomattavasti lisää laskentaa. Voin toki postgis queryitä laittaa jahka ehdin saatavillekin, mutta en pidä todennäköisenä että siitäkään huolimatta tuollaista palvelua jostain nurkan takaa ilmaantuu, ehkä muutama muu kaveri saattaa samantyylisesti omalla koneellaan päätyä niitä kokeilemaan mutta julkisemman "palvelun" virittämiseen voipi olla huomattavasti isompi kynnys.

--
i.

JRA · 2012-09-07 22:11:43

ij_ wrote:

Se openjump moduuli on ilmeisesti suljettua koodia(?) joten siitä ei välttämättä ole kauheasti hyötyä jos sitä nyt muutenkaan saisi tietokantaan järkevästi kytkettyä automaattiin kiinni.

OpenJUMP ja suurin osa sen plugin:eista on GPL-lisenssillä. Road Matcherillä on kaksoislisenssi, koska alkuperäisen JUMP:in tekijä Vivid Solutions on kirjoittanut myös sen, mutta sekin on saatavilla GPL:nä. Suosittelisin kuitenkin uudempaa Matching-laajennosta, koska Michael Michaud on aktiivinen OpenJUMP:in kehittäjä ja erittäin pätevä. Laajennoksen käyttöohje on täällä:
https://sourceforge.net/projects/jump-p … f/download
OpenJUMP lukee PostGIS:iä luonnostaan ja on yksi parhaista mitä on olemassa siihen tarkoitukseen. Päivittämisen kanssa on vähän niin ja näin, se ei ole kuulunut vakio-ominaisuuksiin eikä taida vieläkään olla kaikkein sujuvinta.

ij_ · 2012-09-08 09:34:59

JRA wrote:

ij_ wrote:
Se openjump moduuli on ilmeisesti suljettua koodia(?) joten siitä ei välttämättä ole kauheasti hyötyä jos sitä nyt muutenkaan saisi tietokantaan järkevästi kytkettyä automaattiin kiinni.
OpenJUMP ja suurin osa sen plugin:eista on GPL-lisenssillä. Road Matcherillä on kaksoislisenssi, koska alkuperäisen JUMP:in tekijä Vivid Solutions on kirjoittanut myös sen, mutta sekin on saatavilla GPL:nä. Suosittelisin kuitenkin uudempaa Matching-laajennosta, koska Michael Michaud on aktiivinen OpenJUMP:in kehittäjä ja erittäin pätevä. Laajennoksen käyttöohje on täällä:
https://sourceforge.net/projects/jump-p … f/download
OpenJUMP lukee PostGIS:iä luonnostaan ja on yksi parhaista mitä on olemassa siihen tarkoitukseen. Päivittämisen kanssa on vähän niin ja näin, se ei ole kuulunut vakio-ominaisuuksiin eikä taida vieläkään olla kaikkein sujuvinta.

Ah, ok. Oli sitten joku muu juttu mitä katsoin kuukausia sitten tai en vaan osannut keksiä mistä downloadata pluginin koodin. OpenJUMP:n nyt tiesinkin olevan vapaata koodia toki.

--
i.

ij_ · 2012-09-08 21:51:32

Katoin tastar arvoja... teille on näitä käytössä:

tastar | count
0 | 1125
500 | 511
800 | 12908
1000 | 675
2000 | 187121
3000 | 2565159
4000 | 120063
5000 | 359007
7500 | 116678
8000 | 35790
10000 | 5738
12500 | 4886
15000 | 19414
20000 | 19394
25000 | 45
30000 | 275
40000 | 592
80000 | 115
100000 | 2133

T52 cellissä tuolla kemijärven seutuvilla menevät näin:

3000 | 15005
5000 | 3403
7500 | 366
10000 | 36
12500 | 3
15000 | 266
100000 | 1

KORTAR avainta teille ei edes käytetä.

--
i.

ij_ · 2012-09-08 22:04:13

VALMAS (valmiusaste) arvot teillä:

valmas | count
--------+---------
0 | 3451029
1 | 420
3 | 180

1 ja 3 merkitys selvittämättä. Kuvaus puhuu että suunnitelman ovat vain poikkeustapauksissa (merkittävä hanke, kehä II; jatko esimerkkinä). Yllättävän vähän noita kaikkiaan on ja taas melkein yhtä paljon joten vaikea uskoa että 180 olisi kaikki poikkeustapaukset.

--
i.

Last edited by ij_ (2012-09-08 22:04:50)

ij_ · 2012-09-08 23:52:38

Tein nyt pari yksinkertaista koetta tuolla kemijärven ympäristössä (näemmä extractini oli sellainen jossa oli vielä ei-revertoituna tuo kemijärvi ainakin pääosin, joten siinä on "aukko" nyt sitten overlappitestin takia ja jotain myöhemmin palautettuja unclassified overlappejä lähellä noita revertoidun alueen reunoja):

- http://www.cs.helsinki.fi/u/ijjarvin/osm/kemijtest.osm - Ei mitään tie/rautatie overlappejä osmin kohteisiin 40m puskurilla (eikä taloja leikkaavia teitä).
- http://www.cs.helsinki.fi/u/ijjarvin/os … nowmob.osm - Koska näytti siltä että nuo highway=path snowmobile reitit estivät isohkoa osaa teistä tulemasta mukaan kokeilin tässä filtteröidä niitä pois niin että overlapit niiden kanssa eivät haittaa.

Laskenta kesti 3-2.5minuuttia (T52 ruudun alueen kaikki mml objektit tarkistettiin).

Joillain alueilla syntyy noissa aika suuriakin verkkoja tuolla suoraan. Jos haluaisi hienostelemaan ryhtyä voisi noita ehkä erotella jopa jokaisen omaksi verkokseenkin.

LineMergeä en vielä ajanut noille, mutta se ei ole kovinkaan monimutkainen operaatio. Pitäisi vielä koittaa "putsata" overlap testeista mml;ään täysin matchaavat aineisto ennen ku ajaisi tuota overlap testiä niin saisi mml tavaran kauniisti yhteen itsensä kanssa automaattisesti.

--
i.

skela · 2012-09-09 10:23:25

ij_ wrote:

näemmä extractini oli sellainen jossa oli vielä ei-revertoituna tuo kemijärvi ainakin pääosin

Luin jostakin, että virallinen planet.osm on vaihtanut paikkaa muutama päivä sitten. Vanhassa osoitteessa olisi viimeinen CC-BY-SA-lisensoitu kartta.

Latasin eilen ja tänään Geofabrikista finland.osm.pbf:n. Korjasin eilen yhden rikkinäisen (väärin päin osoittavan) merenrantaviivan, mutta virhe on mkgmapin mukaan tänäänkin siellä. Jo eilen kokeilin ladata muutamia MML-tuotuja kohteita, joista mkgmap narisi, eikä niitä enää ollut tietokannassa.

Täytynee odotella muutama päivä, kunnes Geofabrikin väki on palannut SoTM12:sta, ja kysellä vasta sitten, saisiko kartan taas päivittymään.

ij_ · 2012-09-09 11:42:26

teollisuus wrote:

Revertoinnissa ei ollut mitään ylitsepääsemättömiä ongelmia ja kaikki changesetit on nyt järjestelmällisesti revertoitu lopusta alkuun. Vertasin Kemijärven nykytilannetta alkutilanteeseen enkä nähnyt mitään muutosta JOSMin eri layereiden välillä. Mikäli jotain kuitenkin puuttuu/on muuttunut saadaan se palautettua kyseisen objektin ID:n avulla.

Kävin automaatilla läpi kaikki nuo > v1 objektit. Ainoat muutokset nodeissa / wayssa olivat created_by tagien katoamisia, joten homma on hyvin hoidettu. Kiitos. Relaatioita, 5kpl, en jaksanut tarkistella, olivat multipolygoneja ja rata routeja + E-tie relaatio, mutta ei ole mitään syytä olettaa että ne olisivat väärin.

--
i.

HACY · 2012-09-09 16:55:24

Olin pienellä viikonloppukiertoajelulla. Savonlinnan ohitustietieremontti ja pohjoispää.
http://www.openstreetmap.org/?lat=61.87 … 7&layers=M
http://kansalaisen.karttapaikka.fi/kart … al&lang=fi
Ajoin tuosta eilen. Openstreetmapissa tuo (käsittääkseni väliaikainen) liikenneympyrä on oikein ja myös rakenteilla oleva ohitustiekin. Tagi on highway=construction. Karttapaikalla (copyright mml) on vanhaa tietoa.

Sitten Tornion Pirkkiöön suunnitellaan uusia katuja:
http://www.openstreetmap.org/?lat=65.81 … 5&layers=M
http://kansalaisen.karttapaikka.fi/link … 67&lang=fi
Nätisti piirtyy openstreetmapissa uudet suunnitelmat katkoviivoilla. käytetty tagi on highway=proposed. Karttapaikalla ei mitään näkyvissä (ei myöskään maastossa, niin ei tuota virheenä voi pitää).

Openstreetmapin vahvuus on siinä, että sinne ilmestyy hyvin äkkiä uudet tai jopa vasta suunniteltavat tiet, jos ihmiset vain vaivautuu niitä lisäämään oman paikallistuntemukseensa perustuen ja muutokset ilmestyvät saman tien karttoihin. Tätä vahvuutta ei ole millään kaupallisella toimijalla. Niiden kartat on aina vanhoja jo ilmestyessään.

Jos nyt valitaan se tie, että kaikki käyttäjien syöttämä data jyrätään yli vaikkapa kerran vuodessa, kun MML:ltä ilmestyy "oikeampi/tarkempi" tämän vuoden kirjasto, niin tämä vahvuus menetetään. Kukaan ei enää vaivaudu lisäämään karttaan yhtään mitään, kun tiedossa on, että kaikki jyrätään kuitenkin yli.

Mitä enemmän olen katsonut tuota osm sisältöä, sitä enemmän olen alkanut inhoamaan juuri tätä keskustelun alla olevaa suunnitelmaa tehdä tästä vain "yet another outdated copy of a generic map".

.

Manu S · 2012-09-09 21:29:03

HACY wrote:

Olin pienellä viikonloppukiertoajelulla. Savonlinnan ohitustietieremontti ja pohjoispää.
http://www.openstreetmap.org/?lat=61.87 … 7&layers=M
http://kansalaisen.karttapaikka.fi/kart … al&lang=fi
Ajoin tuosta eilen. Openstreetmapissa tuo (käsittääkseni väliaikainen) liikenneympyrä on oikein ja myös rakenteilla oleva ohitustiekin. Tagi on highway=construction. Karttapaikalla (copyright mml) on vanhaa tietoa.

Liikenneympyrä on kyllä mielestäni tullut ihan jäädäkseen, ollut käytössä vajaat kaksi viikkoa. Oli aikansa 'construction', kunnes tuli virallisesti käyttöön. Sitä tilapäistä ajoreittiä en viitsinyt piirrellä kun se ei hirveästi poikennut alkuperäisestä tielinjauksesta.

Tämä lähes reaaliaikaisuus on minunkin mielestäni OSM:n ehdoton vahvuus muihin karttapalveluihin nähden. Jopa kaupungin (Savonlinna siis) nettisivuilta linkitetään karttoihin joissa osa zoomaustasoista käyttää ilmeisesti MML:n vanhoja tietoja ja näyttää mm. muutama vuosi sitten käytöstä poistettuja tasoristeyksiä kulkukelpoisina, seikka jonka sain itse aikanaan karvaasti kokea.

MML:n materiaalilla olisi toki kiva tilkitä niitä alueita joille OSM-kartoittajat eivät satu eksymään.
-
Manu

ij_ · 2012-09-09 21:51:07

Paljonkos teollisuus sallit tossa importissaan teiden oikovan simplifioinnin seurauksena? Löydän varsin suuriakin etäisyyksiä (~3m) mikä alkaa olemaan jo aika reipasta heittoa.

--
i.

Announcement

#151 2012-09-06 10:11:31

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#152 2012-09-06 11:42:48

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#153 2012-09-06 13:55:42

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#154 2012-09-06 14:14:04

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#155 2012-09-06 15:52:03

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#156 2012-09-06 16:30:51

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#157 2012-09-06 22:11:39

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#158 2012-09-07 08:13:53

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#159 2012-09-07 09:05:19

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#160 2012-09-07 10:35:35

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#161 2012-09-07 14:30:08

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#162 2012-09-07 16:24:47

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#163 2012-09-07 17:21:14

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#164 2012-09-07 20:47:44

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#165 2012-09-07 21:25:22

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#166 2012-09-07 22:11:43

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#167 2012-09-08 09:34:59

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#168 2012-09-08 21:51:32

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#169 2012-09-08 22:04:13

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#170 2012-09-08 23:52:38

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#171 2012-09-09 10:23:25

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#172 2012-09-09 11:42:26

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#173 2012-09-09 16:55:24

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#174 2012-09-09 21:29:03

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

#175 2012-09-09 21:51:07

Re: Maanmittauslaitoksen ilmaisten aineistojen hyödyntäminen

Board footer