You are not logged in.

#51 2013-08-25 19:20:50

boy007
Member
From: Lappeenranta
Registered: 2013-08-05
Posts: 33
Website

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

keimo,... kun kuitenkin joudutaan yhdistelemään muotono ja nimi konversion lisäksi,... miltä tuntuis päällekkyyksien ja
niitten kartan yksityiskohtien viimeistely sql:ssä,... tuntuisi musta luontevimmalta ?

Offline

#52 2013-08-25 23:47:48

ij_
Member
Registered: 2011-11-22
Posts: 161

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

Minulla on jo tuotettuna .osm filejä, joissa on aliverkkoja MML:n tiestö osoitteilla aineistossa (tietääkseni ainoa jossa tiennimet yms tiedot löytyvät, ei taida saada latauspalvelusta?), jotka eivät overlappaa OSM:ssa minkään oleellisen kanssa. Verkkoja on n. 170k joten siinä riittää varmasti hommaa jaettavaksi, jahka saisivat tuon copyright merkinnän lisättyä + kaikki importtiin liittyvä byrokratia on hoitettu asianmukaisessa järjestyksessä (tosin iso osa on suhteellisen pieniä, joita kannattaisi varmaan bundlettaa jotenkin yhteen, mutta tapaa täytyy ehkä vielä hetki pohtia). Suurimmat verkot olivat yhteismitaltaan n. 624km, mikä ehkä tuntuu suurelta, mutta koot pienenevät nopeasti ja n. 40km verkkoa kun koitin, sen käy jo muutamassa minuutissa läpi ilmakuvien kanssa. Isoimmissa verkoissa luulen että aikaa kuluu tunteja.

Käytännössä teiden luokittelua joudutaan varsin paljon tekemään käsin, mutta tuo näytti olevan suhteellisen yksinkertainen ja nopeahko operaatio muutaman kymmenen kilometrinkin kokoiselle verkolle jos ilmakuvat ovat alueelle saatavilla. Tuo "arvontaluokittelu" esim. tracktype:ille yms, mitä tuolla ogr2osm muunnoksessa on käytetty kannattaa kyllä hylätä suoraan ja myöntää se että MML:n luokittelusta ei läheskään täydellistä OSM-tavaraa vaivatta synny vaan dataa joudutaan ihan oikeasti katsomaan ihmissilmin! Lisäksi geometriavirheet MML:n tiestön yhteenkytkennöissä ovat pikemminkin sääntö kuin poikkeus, joten JOSMin validaattorilla tarkistelu ja jokaisen löydetyn arveluttavan kohdan läpikoluaminen on aivan välttämätöntä ennen uppimista.

Olen jo tällä hetkellä valmistelemassa tuota import-kuvausta ja koitan myös kirjoittaa importista kiinnostuineita varten oman ohjesivun tuon tekemisen jälkeen (mutta painan vain upload-nappia tyylistä ratkaisua ei valitettavasti ole niistä kiinnostuneiden iloksi tarjota):
  http://wiki.openstreetmap.org/wiki/Fi:M … tage1_Plan

Saapi heittää kommentteja, vaikken tuota loppupuolta vielä ihan ehtinyt saamaan valmiiksi.

Tämä on siis ensimmäisen vaiheen operaatio niille alueille, jotka ovat tällä hetkellä tyhjiä OSMissa. Seuraavassa vaiheessa pitää sitten miettiä olemassaolevaan dataan tietojen liittämistä, mutta se on huomattavasti haasteellisempi operaatio (jotain yritystä mulla on matchayksenkin suhteen olemassa, mutta se on vähän vielä vaiheessa se koodi).

--
i.

Offline

#53 2013-08-26 05:48:51

muistikas
Member
Registered: 2011-01-02
Posts: 226

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

ij_ wrote:

MML:n tiestö osoitteilla aineistossa (tietääkseni ainoa jossa tiennimet yms tiedot löytyvät, ei taida saada latauspalvelusta?),

Latauspalvelusta on nykyään saatavana tiestö osoitteilla: http://www.maanmittauslaitos.fi/aineist … stopalvelu "Maastotietokanta kaikki kohteet, tiestö osoitteilla". Muistaakseni tiestö osoitteilla ei ollut latauspalvelussa alusta alkaen.

Edit: http://wiki.openstreetmap.org/wiki/Fi:M … tage1_Plan on kohta "Address data". Onko kellään tietoa mistä MML saa pohjakarttaansa osoitteet talojen kohdalle? Esimerkin saa helposti, jos avaa Paikkatietoikkuna.fi:n Karttaikkunan (http://www.paikkatietoikkuna.fi/web/fi/kartta) ja zoomaa riittävän lähelle oletuspohjakartan ollessa päällä. Osoitenumerot ovat talon kohdalla. Joissain tapauksissa saattaa tietysti olla hankalaa kohdistaa numero oikeaan tiehen, mutta muuten kyseinen aineisto sopisi varmaan hyvin OSM:n osoiteaineiston pohjaksi. Saattaisiko lähtöaineistona olla rakennus- ja huoneistorekisteri (http://www.vaestorekisterikeskus.fi/default.aspx?id=175) vai joku muu aineisto?

Last edited by muistikas (2013-08-26 06:18:23)

Offline

#54 2013-08-26 07:12:41

boy007
Member
From: Lappeenranta
Registered: 2013-08-05
Posts: 33
Website

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

Käsityö kuulostaa pahalata, kaikissa systeemeissä järjestelmän saaminen pystyyn on helppo juttu verattuna siihen
että se on pystyssä 10 ehkä 50 vuoden päästä ja toimii vielläkin.

NIIN Maanmittaushallitus PÄIVITTÄÄ TIETOKANTAANSA KOKO AJAN, PÄIVITYKSET PITÄISI SAADA SIIRTYMÄÄN
MAHDOLLISIMMAN AUTOMAATTISESTI !

En ole ehtinyt, enkä ihan heti ehdi, kun tappelen rinakkain laskenta ongelmien kanssa, perehtyä OSM päivitys mekanismeihin mutta näillä vilasuilla on sellainen
tunuma että siellä on joku osm_id mikä yksilöi yksittäisen objektin päivitystä varten. Joten MML tietokannalle pitäisi
saada varmaan jostakin oma "id avaruus" ?

Päällekäiset tiet, ja nimistön puhdistus pitäisi onnistua ihan SQL:llä, voisi olla toimiva,....

Voisko tuotanto  olla tällänen:

OMAT KARTTAT, KARTAN JAKELU PALEVLUT MUODOSTAMINEN JA PÄIVITYS:

OSM materiaali, esim. finland-latest.osm.pdf ---> osm2prsql -append
Omat OSM lisäykset ----> osm2prsql -append
ja
MKL aineisto -> gdal -> ogr2osm -append MTK.py ( JOKU TÄGI MIKÄ MTK VERSIO JA PÄIVITYS PSM ) -> osm2prsql -> sql käsittelyllä päällekkyydet pois 

ko. muodostettu tietokanta takasin OSM muotoon ja edelleen Nominatimille ja esim. android/Iphone/garmin karttojen tuotantoon ja
itse OSM viimesimmäksi finland-latest.osm versioksi ??? Ja sama uudestaan taas kun MTK tietokanta riittävästi muuttunut vai saako
MTK:lta pelkät muutokset ???

Tietysti muodostuneen tietokannan voisi käsintarkastelun jälkeen viedä takasin OSM:äksi.

Niin lisenssistä viellä, musta tuo vastaus oli selkeä, nykynen on riittävä ja mitään erillistä sopparia ei tule.

Offline

#55 2013-08-26 07:39:54

boy007
Member
From: Lappeenranta
Registered: 2013-08-05
Posts: 33
Website

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

Viimesin MTKGML.py antaa virheen:
   AXIS["Easting",EAST],
    AXIS["Northing",NORTH],
    AUTHORITY["EPSG","3067"]]
Traceback (most recent call last):
  File "ogr2osm.py", line 656, in <module>
    parseData(data)
  File "ogr2osm.py", line 336, in parseData
    parseLayer(translations.filterLayer(layer))
  File "ogr2osm.py", line 397, in parseLayer
    parseFeature(translations.filterFeature(ogrfeature, fieldNames, reproject), fieldNames, reproject)
  File "ogr2osm.py", line 418, in parseFeature
    translations.filterFeaturePost(feature, ogrfeature, ogrgeometry)
  File "/home/joni/src/ogr2osm/translations/MTK-GML.py", line 47, in filterFeaturePost
    feature.tags = mtk_features.get(ogrfeature['kohdeluokka'], mtk_default)(ogrfeature)
  File "/home/joni/src/ogr2osm/translations/MTK-GML.py", line 587, in <lambda>
    44803 : lambda f: { "man_made" : "tower", "height" : ustr(float(fget('korkeusarvo', 0.0))/1000.0), },
  File "/home/joni/src/ogr2osm/translations/MTK-GML.py", line 58, in fget
    val = ogrfeature[key]
TypeError: string indices must be integers, not float
(jpk)joni@mpi1:~/src/ogr2osm$

keimo, siirtyykö korkeyskäyräkin ? Eli riittääkö osm-xml uuden tyylin lisäys, ilmeisesti OSM DATA
ei tunne korkeus käyrää, niinkö ??? Pitäiskö tyyleille antaa yhteiset nimet jostain ?

Mistä saataisiin vanha tietokanta syvyyskäyrillä,... missä jaossa ???

Last edited by boy007 (2013-08-26 07:59:15)

Offline

#56 2013-08-26 08:07:19

muistikas
Member
Registered: 2011-01-02
Posts: 226

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

boy007 wrote:

NIIN Maanmittaushallitus PÄIVITTÄÄ TIETOKANTAANSA KOKO AJAN, PÄIVITYKSET PITÄISI SAADA SIIRTYMÄÄN
MAHDOLLISIMMAN AUTOMAATTISESTI !

Toisaalta voi olla niinkin, että voimme jättää tämän ongelman ratkaisemisen myöhemmäksi. Näin siksi, että MML ei (tietääkseni) mitään diffejä pysty toimittamaan, joten se jäisi joka tapauksessa meidän tehtäväksemme. En tiedä miten "diffit" voisi tehdä, mutta joka tapauksessa se aineisto, josta importti tehdään, pitää tallentaa johonkin säilöön, esimerkiksi torrentteina, joita importoijat sitoutuvat säilyttämään, kunnes seuraava importti tehdään. Siinä vaiheessa voi sitten yrittään jotenkin selvittää muutoksia edellisen importin lähdeaineistoon.

Niin lisenssistä viellä, musta tuo vastaus oli selkeä, nykynen on riittävä ja mitään erillistä sopparia ei tule.

Ei lisenssiasia ole vielä selvä, mutta jos MML:ta saisi vastauksen, että "vaadittava vastaavat maininnat ..."  ei kosketa OSM:ia, niin sitten lisenssiongelma saattaisi olla ratkaistu. Tavallaan kyseessä olisi erikoislisenssi OSM:lle.

Muuta:

Dokumentissa http://wiki.openstreetmap.org/wiki/Fi:M … ging_Plans on kirjattu, että "We feel no need to have source attribution in each object. It would just bloat the database unnecessarily and the current requirement for a separate import account should be enough to distinguish imported data from the other edits."
Laittaisin tuon edellisen toiseen järjestykseen siten, että aloitetaan tuolla "separate import account":lla ja sen jälkeen todetaan, että source attributionia ei siten tarvita. Olisikohan tarvetta käyttää useita "separate import accunteja"?

Ehdotan seuraavaa importin suunnitteluun liittyen:
- Pyritään tekemään dokumentaatio pääosin englanninkielellä
- Lisätään etusivulle linkki importin suunnitteludokumentaatioon (http://wiki.openstreetmap.org/wiki/Fi:Main_Page)
- Tehdään lyhyehkö pääsivu suomeksi ja siitä linkki englanninkieliseen vastaavaan, josta sitten linkkejä alisivuihin
- Pääsivulla on kuvattu lisenssi ja siihen liittyvät ongelmat sekä importin vaiheistus
- Eriytetään mäppäyssivu (sivu, jossa kuvataan kuvaus MML->OSM) omaksi sivukseen, Mäppäys on varmaankin parasta kuvata taulukkona, joka noudattaisi MML:n tietojen järjestystä (tämä vaikuttaa hyvältä pohjalta http://wiki.openstreetmap.org/wiki/Fi:M … ta/Luokat)
- Jaetaan mäppäyksen kuvaus kahteen osaan: triviaali osa ja hankalampi osa, jossa jälkimmäinen sisältää aineiston, jossa esim. aluemuotoisten kohteiden ominaisuustietoja on kuvattu ”kartografisesti” tunnuspisteellä tms. kuvaustekstillä ja importissa nämä tiedot pitäisi pystyä yhdistämään

Jos MML:n lisenssiongelma ratkeaa myös Metlan lisenssiongelma saattaisi olla ratkaistavissa samalla periaatteella. Metlan avointen aineistojen lisenssi on kutakuinkin ellei sama kuin MML:lla (http://kartta.metla.fi/). Metlan aineistosta voisi tuoda metsäkuviotietoja ja metsän maapohjatietoja. Metlan aineistojen importtauksen voisi ehkä ottaa samaan prosessiin mukaan.

Offline

#57 2013-08-26 08:19:54

muistikas
Member
Registered: 2011-01-02
Posts: 226

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

boy007 wrote:

keimo, siirtyykö korkeyskäyräkin ? Eli riittääkö osm-xml uuden tyylin lisäys, ilmeisesti OSM DATA
ei tunne korkeus käyrää, niinkö ???

OSM ei talleta korkeuskäyriä. Joitain korkeustietoja on mahdollista tallettaa, mutta ei korkeuskäyriä. Tästä taisi olla muutama sivu aiemmin.

Mistä saataisiin vanha tietokanta syvyyskäyrillä,... missä jaossa ???

Ei ainakaan vapaasti taida olla missään tarjolla. MML poisti vesistöön (veneilyyn) liittyvät tiedot aineistosta ennen aineiston vapautusta. Eikös tästäkin ollut jotain sivu pari aiemmin tai jossain toisessa ketjussa.

Siinä olisikin uudelle yhteisöprojektille paikka: syvyystietojen kartoittaminen. Näyttäisi siltä, että OpenSeaMap ei sekään taida tallettaa syvyystietoja, eli perustuisiko kokonaan OSM aineistoon: http://openseamap.org/

Offline

#58 2013-08-26 10:50:44

ij_
Member
Registered: 2011-11-22
Posts: 161

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

boy007 wrote:

Käsityö kuulostaa pahalta,

Se vaan on valitettavasti niin etteivät nuo classifioinnit sovi yhteen (MML vs OSM). Tätä ongelmaa ei pidä sivuuttaa sillä että valitaan Garbage In Garbage Out ratkaisu (ja päästään bad imports hall-of-shame listalle :-))! Muistutan toki että sinun henkilökohtaisesti ei ole mikään pakko osallistua, jos haluat pitäytyä tahrimasta käsiäsi mihinkään käsityöhön ;-), uskon kyllä että riittävästi halukkaita löytyy muutenkin että homma saadaan toimimaan.

kaikissa systeemeissä järjestelmän saaminen pystyyn on helppo juttu verrattuna siihen
että se on pystyssä 10 ehkä 50 vuoden päästä ja toimii vielläkin.

Aivan, mutta kannattaa myös muistaa se tosiasia, että maasto pysyy loppuen lopuksi varsin stabiilina muutoksista huolimatta. Elikkä ei Suomen kaikkia teitä tai vaikkapa taloja kerran vuodessa laiteta uusiksi. Nähdäkseni tässä on nyt hiukan liioiteltu muuttumisen mittakaavaa.

NIIN Maanmittaushallitus PÄIVITTÄÄ TIETOKANTAANSA KOKO AJAN, PÄIVITYKSET PITÄISI SAADA SIIRTYMÄÄN
MAHDOLLISIMMAN AUTOMAATTISESTI !

Heh-heh. Moni koodipuolellakin varmasti maksaisi maltaita jos saisi aukottomasti toimivan automaatin joka huolehtii esim. confliktit. Muistathan että myös OSM päivittyy jatkuvasti!

En ole ehtinyt, enkä ihan heti ehdi, kun tappelen rinnakkain laskenta ongelmien kanssa, perehtyä OSM päivitys mekanismeihin mutta näillä vilasuilla on sellainen
tunuma että siellä on joku osm_id mikä yksilöi yksittäisen objektin päivitystä varten. Joten MML tietokannalle pitäisi
saada varmaan jostakin oma "id avaruus" ?

OSMissa on ID-avaruus (osm_id column jos osm2pgsql:llä importtaat). Mutta mutta, OSMin puolella ID:iden pysyvyydestä ei ole mitään takeita, seuraava editoija saattaa laittaa editoidessaan ID:t piu-pau-poks. Toki sitä voidaan .osc diffejä processoidessa vielä käyttää kontrolloidusti hyödyksi mutta muuten siitä ei ole hirveästi muutosidentifiointiin avuksi (eli poistetut objektit "katoavat" kannastasi jos ne poistetaan osmista ja ajoit diffit sisään). Vähän sama homma MML:n puolelta vai oletko löytänyt jostain dokumentaatiota miten heidän ID:t käyttäytyisivät muutoksien yhteydessä? IMHO, kaikki ID:t jotka eivät perustu objektien geometriaan ovat tuhoontuomittu yritys tällä pohjalla. Lisäksi geometria on mielestäni täysin riittävä, joskaan ei täysin helppo ID noin niinku laskennan vaativuutta ajatellen, mutta nähdäkseni ainakin tieverkon tapauksessa se pitäisi olla varsin mahdollista ratkaista riittävällä tarkkuudella! Lisäksi MML:llä tiet on pilkottu pieniin osiin vaikkei mikään attribuutti muuttuisikaan, OSMissa wayt ovat pitempiä jos tien attribuutit pysyvät samana.

Käytännössä MML:n aineistosta on helpohkoa laskea diffit edelliseen MML:n versioon nähden tietokannassa, muutoksien määrä ei tule olemaan järin suuri vaikka sitä pelkäsitkin. Tämä vaihe on varsin helppo automatisoida!

Päällekäiset tiet, ja nimistön puhdistus pitäisi onnistua ihan SQL:llä, voisi olla toimiva,....

Voisko tuotanto  olla tällänen:

OMAT KARTTAT, KARTAN JAKELU PALEVLUT MUODOSTAMINEN JA PÄIVITYS:

OSM materiaali, esim. finland-latest.osm.pdf ---> osm2prsql -append
Omat OSM lisäykset ----> osm2prsql -append
ja
MKL aineisto -> gdal -> ogr2osm -append MTK.py ( JOKU TÄGI MIKÄ MTK VERSIO JA PÄIVITYS PSM ) -> osm2prsql -> sql käsittelyllä päällekkyydet pois 

ko. muodostettu tietokanta takasin OSM muotoon ja edelleen Nominatimille ja esim. android/Iphone/garmin karttojen tuotantoon ja
itse OSM viimesimmäksi finland-latest.osm versioksi ??? Ja sama uudestaan taas kun MTK tietokanta riittävästi muuttunut vai saako
MTK:lta pelkät muutokset ???

Tietysti muodostuneen tietokannan voisi käsintarkastelun jälkeen viedä takasin OSM:äksi.

Itse lähtisin kuitenkin mielummin siitä, että MTK:n aineisto pyritään yhdistämään uppimalla se järkevästi suunniteltuna suoraan OSMiin (mutta tässä tarvitaan sekä harkintaa, että jonkun verran aikaakin, sitä ei saa aikaan yhdessä yössä). Toki en kiellä sinua koitamasta tehdä yhdistämistä täysin OSMista riippumatta :-). Ongelmana tuossa yhdistelyssä, jota ilmeisesti toivot mahdollisimman automaattiseksi ovat OSM:in laatuvaihtelut. Tieverkkojen yhdistäminen automaattisesti riittävän hyvällä onnistumisprosentilla voi osoittautua jossain määrin haastavaksi, erityisesti jos sinulla ei ole erittäin vahvaa pohjaa conflation-algoritmeista etukäteen - juu olen miettinyt näitä itse jonkun verran ja tiedän kyllä jotain siitä mitä sieltä tulee vastaan, vaikka pahimpia juttuja olenkin jo kauan sitten OSMista korjaillut "käsityönä" ;-).

Niin lisenssistä viellä, musta tuo vastaus oli selkeä, nykynen on riittävä ja mitään erillistä sopparia ei tule.

Olen samaa mieltä tuosta MML:n vastauksesta, ei se sinänsä ollut mitenkään yllättävä (suullisesti sama viesti onkin jo kuultu).

--
i.

Offline

#59 2013-08-26 11:06:03

ij_
Member
Registered: 2011-11-22
Posts: 161

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

muistikas wrote:
boy007 wrote:

NIIN Maanmittaushallitus PÄIVITTÄÄ TIETOKANTAANSA KOKO AJAN, PÄIVITYKSET PITÄISI SAADA SIIRTYMÄÄN
MAHDOLLISIMMAN AUTOMAATTISESTI !

Toisaalta voi olla niinkin, että voimme jättää tämän ongelman ratkaisemisen myöhemmäksi. Näin siksi, että MML ei (tietääkseni) mitään diffejä pysty toimittamaan, joten se jäisi joka tapauksessa meidän tehtäväksemme. En tiedä miten "diffit" voisi tehdä, mutta joka tapauksessa se aineisto, josta importti tehdään, pitää tallentaa johonkin säilöön, esimerkiksi torrentteina, joita importoijat sitoutuvat säilyttämään, kunnes seuraava importti tehdään. Siinä vaiheessa voi sitten yrittään jotenkin selvittää muutoksia edellisen importin lähdeaineistoon.

Tuo diffien tuottaminen MML:n aineistoista vertaamalla edelliseen MML:n aineistoversioon on tosiaan helpohko operaatio. Ajatuksena oli toimia about siihen tyyliin kuin yllä kuvasit.

Olen samaa mieltä että tätä ei vielä tässä vaiheessa kannata edes ratkaista, koska ratkaisu saattaa osin tai kokonaan löytyä siinä vaiheessa kun Importin "phase 1":stä lähdetään jatkamaan, eli siirrytään phase 2:ssa (tms) alueille joissa on jo tiedataa OSM:ssa (jolloin tarvitaan hiukan lisää kehitystyötä MML vs OSM objektien matchaystä varten. Syntynyttä työkalustoa pystyy ehkä hyötykäyttämään myös päivitysvaiheessa.

--
i.

Offline

#60 2013-08-26 11:26:25

ij_
Member
Registered: 2011-11-22
Posts: 161

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

Kiitos kommenteista ja ajatuksista!

Dokumentissa http://wiki.openstreetmap.org/wiki/Fi:M … ging_Plans on kirjattu, että "We feel no need to have source attribution in each object. It would just bloat the database unnecessarily and the current requirement for a separate import account should be enough to distinguish imported data from the other edits."

Koitan illalla uudelleenmuotoilla tuota object attribuutiota, mutta kyseessä on wiki joten saat sinäkin siihen koskea :-D.

Laittaisin tuon edellisen toiseen järjestykseen siten, että aloitetaan tuolla "separate import account":lla ja sen jälkeen todetaan, että source attributionia ei siten tarvita. Olisikohan tarvetta käyttää useita "separate import accounteja"?

Uusi accountti per importti voisi olla järkevää, mutta tuossa on vaan se ongelma, että accounteilla pitää olla uniikki email osoite, josta on ainakin muuallapäin maailmaa ollut jonkun verran purnausta. Valitettavasti erillisiä accounteja vaativilla admin puolen kavereilla ei näytä olevan intoa koodata osmiin "secondary usernameja", missä yhteys varsinaiseen käyttäjään olisi vielä vahvempi (käyttäjien tuntemisen kannalta tuo olisi kiva feature eli tiedettäisiin suhteellisen suoraan että importtaaja x_yzimport on sama käyttäjä joka editoi nimellä x). Secondary usernamet jakaisivat tietenkin sen emailin automaattisesti :-).

Enemmän olen itse koittanut miettiä miten on järkevää tehdä import ja sen jälkeiset käsin yhdistely muutokset suhteessa eri accounttien käyttöön (esim. nuo aliverkko pitää uppimisen jälkeen tietysti yhdistää käsin siltä puuttuvalta 40m+ matkalta OSMissa olevaan dataan, mitä accounttia käytetään tähän?).

Ehdotan seuraavaa importin suunnitteluun liittyen:
- Pyritään tekemään dokumentaatio pääosin englanninkielellä

Tämä oli myös oma ajatukseni. Aion tehdä oman sivun ohjeistosta "teamille", jonka linkkaan tuohon planin "step-by-step" kohtaan. Sen team dokkarin suomikäännöstä voi ehkä harkita jos kääntäjiä löytyy avuksi.

- Lisätään etusivulle linkki importin suunnitteludokumentaatioon (http://wiki.openstreetmap.org/wiki/Fi:Main_Page)
- Tehdään lyhyehkö pääsivu suomeksi ja siitä linkki englanninkieliseen vastaavaan, josta sitten linkkejä alisivuihin

Koska tuo plan dokkari on yksi importbyrokratian vaatimus, pidän sen tuollaisena, mutta itse "teamiin" osallistuville toteuttajille tehdään mielummin oma ohje järkevämmällä rakenteella, monet eivät jaksa lukea edes lyhyempää sivua huolellisesti läpi ;-).

- Pääsivulla on kuvattu lisenssi ja siihen liittyvät ongelmat sekä importin vaiheistus
- Eriytetään mäppäyssivu (sivu, jossa kuvataan kuvaus MML->OSM) omaksi sivukseen, Mäppäys on varmaankin parasta kuvata taulukkona, joka noudattaisi MML:n tietojen järjestystä (tämä vaikuttaa hyvältä pohjalta http://wiki.openstreetmap.org/wiki/Fi:M … ta/Luokat)

Tämä importti jota nyt suunnittelen keskittyy pelkkään tiestöön. Erilliset importit saatte/saadaan suunnitella ja toteuttaa muille luokille (vaikkapa rajat, vesistöt, sähköjohdot, "vuorenhuiput", suot, jne.). Ehkä jonkinlainen yhteinen lisenssi yms. tietosivu noille voidaan tuosta road sivun rungosta voidaan toki repäistä, jos ja kun joku rupee niitä seuraavia import planeja kirjoittamaan.

- Jaetaan mäppäyksen kuvaus kahteen osaan: triviaali osa ja hankalampi osa, jossa jälkimmäinen sisältää aineiston, jossa esim. aluemuotoisten kohteiden ominaisuustietoja on kuvattu ”kartografisesti” tunnuspisteellä tms. kuvaustekstillä ja importissa nämä tiedot pitäisi pystyä yhdistämään

Joo, tuo yhdistely MTK:ssakin tuo oman lisänsä haastetta. Mutta nähdäkseni silti suurin haastejakolinja kulkee OSMssa ei mitään ja MTK:ssa ja OSM:ssa on päällekkäisyyksiä välissä.

Jos MML:n lisenssiongelma ratkeaa myös Metlan lisenssiongelma saattaisi olla ratkaistavissa samalla periaatteella. Metlan avointen aineistojen lisenssi on kutakuinkin ellei sama kuin MML:lla (http://kartta.metla.fi/). Metlan aineistosta voisi tuoda metsäkuviotietoja ja metsän maapohjatietoja. Metlan aineistojen importtauksen voisi ehkä ottaa samaan prosessiin mukaan.

Joku arvuutteli että MTK:sta kin saisi metsät... "sitä on kaikkialla missä ei oo mitään muuta", mutta tarkkuudesta en kyllä osaa itse sanoa juuta enkä jaata :-).


--
i.

Offline

#61 2013-08-26 20:56:14

keimo
Member
Registered: 2013-07-11
Posts: 29

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

boy007 wrote:

  File "/home/joni/src/ogr2osm/translations/MTK-GML.py", line 587, in <lambda>
    44803 : lambda f: { "man_made" : "tower", "height" : ustr(float(fget('korkeusarvo', 0.0))/1000.0), },
  File "/home/joni/src/ogr2osm/translations/MTK-GML.py", line 58, in fget
    val = ogrfeature[key]
TypeError: string indices must be integers, not float

Ei pitäisi tuupata testaamatonta koodia... Nyt tuo on korjattu.

boy007 wrote:

Mistä saataisiin vanha tietokanta syvyyskäyrillä,... missä jaossa ???

OSM ei tosiaan sisällä korkeuskäyriä, mutta esim. Opencyclemapin tiilissä ne on renderöityinä. Datalähde ei ole OSM, vaan NASAn tietokanta SRTM. Tuon wikisivun lukemalla tosin oppii, että onhan tuonkin datasetin jo joku ehtinyt konvertoimaan OSM-formaattiin.

Offline

#62 2013-08-27 08:44:01

posiki
Member
Registered: 2010-03-26
Posts: 214
Website

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

muistikas wrote:

Muistaakseni tiestö osoitteilla ei ollut latauspalvelussa alusta alkaen.

Ei ollut alkuun. Kas, sieltä saa siis päivitetyt versiot. Tai tässä aineistossa taitaa olla siis tien alku- ja loppupään osoitteet. Välit pitää interpoloida.

muistikas wrote:

Onko kellään tietoa mistä MML saa pohjakarttaansa osoitteet talojen kohdalle?

Tuon taustakartan osoitteet tulevat VRK:stä ja sinne ne tulevat taas kunnista. VRK:n RHR aineisto ei ole ilmaista aineistoa, eikä ilmeisesti ihan nopeasti tulossakaan...

Offline

#63 2013-08-27 08:49:41

posiki
Member
Registered: 2010-03-26
Posts: 214
Website

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

ij_ wrote:

Joku arvuutteli että MTK:sta kin saisi metsät... "sitä on kaikkialla missä ei oo mitään muuta", mutta tarkkuudesta en kyllä osaa itse sanoa juuta enkä jaata :-).

Maastotietokananssa ei ole metsää. Eli kaikki mikä on valkoista on metsää ;-) Pellot ja niityt löytyvät yms.

CorineImport (kun taas jatkan sitä), niin tuo perus-metsämaskin OSM:n Suomen osalta. Sitä voi sitten parantaa MML:n ja Metlan aineistoilla.

Metlan aineiston käyttö edellyttäisi aika vahvaa yleistämistä ja esiprosessointia. Sisältää sen verran paljon OSM:n kannalta turhaa tietoa.

P

Offline

#64 2013-08-27 09:36:05

JRA
Member
Registered: 2007-12-17
Posts: 668

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

posiki wrote:

CorineImport (kun taas jatkan sitä), niin tuo perus-metsämaskin OSM:n Suomen osalta. Sitä voi sitten parantaa MML:n ja Metlan aineistoilla.

Minä aloittaisin poistamalla tähän mennessä tehdyn Corine-importin kokonaan.  Seuraavaksi pitäisi laittaa järvien rantaviivat kuntoon maastotietokannasta ja lisätä OSM:sta vielä puuttuvat vedet; tämän jälkeen sama kaikille muille maastotietokannasta löytyville alueille: suot, pellot, kalliot, vesijättö, hiekkakuopat ym.  Nämä ovat maastotietokannassa paljon tarkemmin kuin Corinessa ja laatu varmasti kelpaa OSM:iin.  Jäljelle jää luokittelematonta metsää, ja sitä voisi sitten pilkkoa Corinen tai Metlan aineiston perusteella tarkempiin maankäyttöluokkiin.

Tämä varmaan kirpaisisi Corine-importteja tehneitä, mutta eihän kukaan muuten ikinä jaksa sovittaa esimerkiksi Corinen metsien ja OSM:n järvien rajoja keskenään, ja jos niitä ei soviteta, niin lopputulos ei näytä kovin laadukkaalta.  Tällaisia esimerkkejä ei ole vaikea löytää http://www.openstreetmap.org/#map=14/61 … 3&layers=N

Offline

#65 2013-08-27 09:52:11

muistikas
Member
Registered: 2011-01-02
Posts: 226

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

posiki wrote:

Metlan aineiston käyttö edellyttäisi aika vahvaa yleistämistä ja esiprosessointia. Sisältää sen verran paljon OSM:n kannalta turhaa tietoa.

OSM:n metsätyypit https://wiki.openstreetmap.org/wiki/Tag … e%3Dforest:

name=*
type=coniferous
type=broad_leaved
wood=deciduous
wood=mixed
crop=*

con·i·fer (k n-f r, k n-) n. Any of various mostly needle-leaved or scale-leaved, chiefly evergreen, cone-bearing gymnospermous trees or shrubs such as pines, spruces, and firs.

Deciduous means "falling off at maturity"[1] or "tending to fall off",[2] and is typically used in reference to trees or shrubs that lose their leaves seasonally

Eli havumetsä/lehtimetsä/sekametsä jaon voi tallettaa. Metlan tiedoista saisi mantyvaltaisuus/kuusivaltaisuus -tiedonkin, mutta sen tallentamista OSM ei taida tukea.

Maastotietokannassa näyttäisi olevan päämetsätyyppijako: http://www.maanmittauslaitos.fi/sites/d … ohteet.pdf ja sieltä "4.5.20 Metsämaan kasvillisuus":
Havumetsä (32710)
Lehtimetsä (32713)
Sekametsä (32714)
Varvikko (32715)
Pensaikko (32719).

Ehkä sittenkin kannattaa jättää Metla pois importista. Hyvää tietoa siellä on. Jos haluaa nähdä, mitä tietoja Metla tarjoaa, Paikkatietoikkunan karttaikkunasta löytyy, kohdan "Maanpeite" alta. Suurin osa kyseisen alakohdan tasoista on Metlan avointa aineistoa. Tietoa voi käyttää esim. sienestysreissun suunnittelussa, jos ei tiedä sienimetsiä ennestään.

Offline

#66 2013-08-27 09:57:40

muistikas
Member
Registered: 2011-01-02
Posts: 226

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

JRA wrote:

Minä aloittaisin poistamalla tähän mennessä tehdyn Corine-importin kokonaan.  Seuraavaksi pitäisi laittaa järvien rantaviivat kuntoon maastotietokannasta ja lisätä OSM:sta vielä puuttuvat vedet; tämän jälkeen sama kaikille muille maastotietokannasta löytyville alueille: suot, pellot, kalliot, vesijättö, hiekkakuopat ym.  Nämä ovat maastotietokannassa paljon tarkemmin kuin Corinessa ja laatu varmasti kelpaa OSM:iin.  Jäljelle jää luokittelematonta metsää, ja sitä voisi sitten pilkkoa Corinen tai Metlan aineiston perusteella tarkempiin maankäyttöluokkiin.

Voisiko tuon yhdistää osaksi MTK-importin suunnitelmaa? Turha niitä Corine importteja on poistaa ennen kuin MTK-importtia päästään oikeasti toteuttamaan.

Yksi asia, mistä ei ole ollut (luullakseni) puhetta MTK-importiin liittyen on aineiston tarkkuus: Onko MTK-aineisto liian tarkkaa OSM:lle esim. haja-asutusalueilla? Pitäisikö sitä yleistää?  Kyseessä on kuitenkin, kuten nimikin antaa ymmärtää, tiekartta.

Offline

#67 2013-08-27 13:01:20

ij_
Member
Registered: 2011-11-22
Posts: 161

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

muistikas wrote:
JRA wrote:

Minä aloittaisin poistamalla tähän mennessä tehdyn Corine-importin kokonaan.

Niin minustakin olisi paras toimia. Mutta poistossa pitää huomioida se että niitä on siellä täällä joku saattanut parannellakin. Eli vain pelkästään import versioista koostuvat objektit (kaikkine aliobjekteineen) voidaan surutta poistaa.

Seuraavaksi pitäisi laittaa järvien rantaviivat kuntoon maastotietokannasta ja lisätä OSM:sta vielä puuttuvat vedet; tämän jälkeen sama kaikille muille maastotietokannasta löytyville alueille: suot, pellot, kalliot, vesijättö, hiekkakuopat ym.  Nämä ovat maastotietokannassa paljon tarkemmin kuin Corinessa ja laatu varmasti kelpaa OSM:iin.  Jäljelle jää luokittelematonta metsää, ja sitä voisi sitten pilkkoa Corinen tai Metlan aineiston perusteella tarkempiin maankäyttöluokkiin.

Voisiko tuon yhdistää osaksi MTK-importin suunnitelmaa? Turha niitä Corine importteja on poistaa ennen kuin MTK-importtia päästään oikeasti toteuttamaan.

Yksi asia, mistä ei ole ollut (luullakseni) puhetta MTK-importiin liittyen on aineiston tarkkuus: Onko MTK-aineisto liian tarkkaa OSM:lle esim. haja-asutusalueilla? Pitäisikö sitä yleistää?  Kyseessä on kuitenkin, kuten nimikin antaa ymmärtää, tiekartta.

Maastokohteista varmaan joutunee karsimaan pisteitä (koitin jossain toisessa threadissä kysellä joltain lukuja paljonko järvistä katoaa pisteitä jos niitä yksinkertaistaa eri kokoisilla virhesallimuskriteerillä, mutta en saanut silloin vastausta miten se vaikuttaa node määriin). Noissa teissä liikanodeisuus ongelmaa ei juurikaan ole näkyny (muutaman noden lähellä toista olen bongannut, mutta niitä on todella vähän suhteessa siihen kuinka paljon olen noita eri puolilta jo ehtinyt vilkuilemaan).

Poisto voi ehkä mennä "samassa", mutta toteutuksellisesti se on kuitenkin oma operaationsa, joka suoritetaan ensin ja sitten ajetaan varsinaista importtia sisään vasta.

--
i.

Offline

#68 2013-08-27 15:50:17

boy007
Member
From: Lappeenranta
Registered: 2013-08-05
Posts: 33
Website

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

Niin eikö MML maastotietokannassa olekkin korkeuskäyrä,... aiankin tägi löytyy.

Eikö tuon voi talettaa samaan finland-mml.osm tiedostoon ja se vaatii mapnikissä
käsittääkseni korkeuskäyrälle oma määrittely, eikö tuo käyrä ole datana
ihan samalainen kuin kaikki way ???

Päivitys rumban saisi toimimaan objektien nimellä ja kyllä ohjelmisto osaa
tietokannasta poistaa saman kaltaisen objektin, ettei oo kahteen kertaan.
Siinä voisi sitten käyttää järkeä ja suosia osm:ss olevaa dataa, noin nopsasti
katsottuna sieltä mistä sitä on se tuoreempaa.

Syvyyskäyrät on vanhoissa tiedostoissa ja sellaista kaipaisin, niitä ei tarvitse
OpenStreetMap:iin viedä. Omaan käyttöön ne saa varmasti ottaa ja kun
lisenssin saa käsiin voihan se olla että yhdistely on mahdollista julkisestikkin.
Syvyyskäyrä kun on korkeuskäyrän jatko,...

Tää thread ei ole OpenStreet map MML import vaan että aineistoa voi käyttää ja jatkojalostaa,...
ja miten se saadaan eteenpäin.

Itse en halua MML aineistosta jättää mitään pois, filtteroinin voi tehdä mapnikin filttereillä,...

ITSE EN OLE RAKENTAMASSA OPENSTREETMAP:iä vaan hyvää karttaa omiin harrastuksiin
missä on kaikki tarpeellinen,... se varmaan muillakin?

Offline

#69 2013-08-27 19:28:50

JRA
Member
Registered: 2007-12-17
Posts: 668

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

Kyllä ainakin tällä karttalehdellä on kapsissa syvyyskäyrät mukana

ogrinfo /vsizip/vsicurl/http://kartat.kapsi.fi/files/maastotietokanta/kaikki/etrs89/gml/M5/M52/M5222R_mtk.zip Syvyyskayra |more

Jos syvyyskäyriä aikoo käyttää Mapnik-kartalla, niin minä en muuntaisi niitä ensin osm-xml-muotoon ja siitä osm2pgsql:llä tietokantaan, koska ogr2ogr:llä käyrät voisi viedä suoraan kantaan tai shapefileiksi.  Niistä pitää sitten vain tehdä "datasource" Mapnikin määrittelyihin, mallia voi ottaa jostain valmiista shapefilejä käyttävästä tasosta, kuten tämä, joka löytyi jostain 5 vuotta vanhasta Mapnikin tyylitiedostosta

<Layer name="world-1" status="on" srs="+proj=merc +datum=WGS84 +over">
    <StyleName>world-1</StyleName>
    <Datasource>
      <Parameter name="type">shape</Parameter>
      <Parameter name="file">c:/data/world_boundaries/world_boundaries_m</Parameter>
    </Datasource>
  </Layer>

Hankalampi tilanne on sitten, jos samaa tavaraa on sekä OSM:ssa että maastotietokannassa tarjolla.  Niistä sitten joutuu joko valitsemaan jomman kumman käyttöön tai yhdistämällä aineistoja joka tekemällä importteja OSM:in tietokantaan tai sitten viekkaalla SQL:llä omassa kannassa.  Miettimistä tulee riittämään, mutta kyllä siitä jotain hupiakin saattaa saada irti.  Onneksi ketään ei tiettävästi pakoteta tekemään töitä tällaisessa ympäristössä.

Offline

#70 2013-08-28 07:39:56

boy007
Member
From: Lappeenranta
Registered: 2013-08-05
Posts: 33
Website

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

Niin, sitten tullaan siihen entä jos koko Maanmittaus aineiston tuo ogr2ogr:llä ja tekee mapnikiin
määrrittelyt sen käyttämiseksi. Oisko siihen ohjetta ettei pioneeriksi tarvitse käydä,...

Silloin nuo pysyisi erillään,... mutta ei saa siirtymään samaa karttaa androidille eikä nimistö dataa
nomatimille!

Toisaalta syvyys, korkeus ja muudata tulee yhdellä kertaa osm2ogr -> osm"postresrg kautta ja
välissä syntyy jaeltava tavara.

Noin jakelun kannalta yksi tiedosto muoto on ja importti on helpompi kuin monta.

KYSYMYKSEEN "Onneksi ketään ei tiettävästi pakoteta tekemään töitä tällaisessa ympäristössä. " ANNAN AUTORATIIVISEN VASTAUKSEN,
ON PAKKO, EI VAPAAEHTOISTA. Kaikki jotka komntoivat threadissä ON PAKOTETTU, PAKOTETAAN JA ON AINA, HETI NYT KÄYTETTÄVISSÄ.

Kyllä tässä on ihan mietittävä juttu, katsotaan keneltä tulee se paras idea!

Offline

#71 2013-08-28 11:12:23

posiki
Member
Registered: 2010-03-26
Posts: 214
Website

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

JRA wrote:

Minä aloittaisin poistamalla tähän mennessä tehdyn Corine-importin kokonaan.
...
Tämä varmaan kirpaisisi Corine-importteja tehneitä, mutta...

Minun tekemät Corine importit (FinCorineImport -tunnuksella tehdyt) voi poistaa kokonaan OSM:stä, heti kun on korvaava aineistoa laittaa tilalle. Mielellään ei niin, että otetaan pois ja sitten odotellaan skriptiä/MML:n lisenssiä/aikaa/tms. muutama vuosi...

Ei kirpaise missään. Ei näillä kilometreillä. Mua kirpaisee se metsäraja Suomen OSM:ssä sad

P

Offline

#72 2013-08-28 11:22:19

JRA
Member
Registered: 2007-12-17
Posts: 668

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

posiki wrote:

Mua kirpaisee se metsäraja Suomen OSM:ssä

Näinköhän? Voisit olla ihan tyytyväinen, jos kartan taustavärinä olisi vihreä.  Kokeile laittaa landuse=forest Suomen rajarelaatiolle wink - Don't import for rendering.

Last edited by JRA (2013-08-28 12:11:11)

Offline

#73 2013-08-29 06:42:54

muistikas
Member
Registered: 2011-01-02
Posts: 226

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

Suomi ON pääsääntöisesti metsää ja jos Suomen alue kartoitetaan tarkasti, niin vihreäksihän Suomi OSM kartalla muuttuu.
Vihreä väri on luullakseni perua UK:sta tai jostain sieltä suunnasta, missä metsät ovat harvinaisuuksia ja niille harvoille jäljellä oleville metsille on ANNETTU JOPA NIMET!

Suomalaisessa tiekartassa metsä on vaaleaa, ei ehkä ihan valkoista, mutta vaaleaa kuitenkin. Katsokaapa vaikkapa gt-karttaa (esimerkkejä löytyy googlen images -haulla).

Siitä syystä olisikin hyvä, jos perustaisimme oman sivuston OSM:lle ja tuottaisiin karttatiilet suomalaiseen makuun sopivana.

Ja, kyllä, ne metsät kartoitetaan vielä, kunhan ehditään. Viimeistään NLS-importissa.

Offline

#74 2013-09-01 20:01:08

boy007
Member
From: Lappeenranta
Registered: 2013-08-05
Posts: 33
Website

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

a) M5132L kartalla ei näy Pilkonlahdentie,... siis pikkuiteiden nimet ei siirry tietokantaan,... puuttuuko noi kokonaan
maastotietokannasta ?

b) WINTER_ROAD päätyi isona tienä vedenpäälle mapnikissä, yritin muutta osm.xml väriä siniseksi mutta se ei ilmeisesti ole WINTER_ROAD tagillä.

c) Nomatim ei muuten suostu lukemaan kuin yhden *.osm:än mikä oli yllätys. Jotta haun saa toimimaan pitäisi
postgsql kanta tuoda ulos osmsis tai ogr2ogr ja rakentaa uudestaan osm:äksi jonka vie nominatimille, keksiikö
kukaan helpompaa tapaa ??

d) OSM ja MTK-,py scriptin tagit eivät ole yhteensopivia, tuottavat eri tasoisia tägejä samoille teille,... eli scripti translaatio file
tekee tiet isommiksi ?

e) osm2prsql alkaa valittamaan useamman importin jälkeen päälekkäisyyksistä, epävarma on uudet tietotypit siirtynyt

Last edited by boy007 (2013-09-01 20:05:28)

Offline

#75 2013-09-02 13:32:22

muistikas
Member
Registered: 2011-01-02
Posts: 226

Re: GDAL tukee maastotietokannan MTK-GML-tiedostomuotoa

boy007 wrote:

a) M5132L kartalla ei näy Pilkonlahdentie,... siis pikkuiteiden nimet ei siirry tietokantaan,... puuttuuko noi kokonaan
maastotietokannasta

(windows:ssa ogr:n kehitysversiolla):

ogrinfo -ro  /vsizip/vsicurl/http://kartat.kapsi.fi/files/maastotietokanta/kaikki/etrs89/gml/M5/M51/M5132L_mtk.zip Tieviiva| findstr Pilkonlahdentie

Palauttaa:

  nimi_suomi (String) = Pilkonlahdentie
  nimi_suomi (String) = Pilkonlahdentie
  nimi_suomi (String) = Pilkonlahdentie
  nimi_suomi (String) = Pilkonlahdentie
  nimi_suomi (String) = Pilkonlahdentie
  nimi_suomi (String) = Pilkonlahdentie
  nimi_suomi (String) = Pilkonlahdentie
  nimi_suomi (String) = Pilkonlahdentie

En tutkinut sen enempää.

Offline

Board footer

Powered by FluxBB