Uvoz podatkov RABA

Zdravo,

Pregledal sem malce območje kjer sem najbolj aktiven in moram rečt, da je tole kar ste pripravili super, vsa pohvala :slight_smile:

Predlagam, pa da se delajo uvozi na ta način: eno in eno območje, kot ste jih razsekali! Dobr bi bilo če bi lahko RABO dodali kot rasterski sloj - podlago, katerega bi lahko nastavili transparenco, da bi potem lahko popravljali naše ceste po gozdovih, sredi travnikov ipd.

Kolikor razumem bi uvozili gozd- id2000; bilo pa bi še smiselno tudi kaj druga npr. 1300, 1500, 7000…

lp

Prvotna ideja (razlog za pobudo) je bila uvoziti le gozd, kar bi predstavljalo nekaj čez 60% površine Slovenije. Ob pregledu vira pa se je izkazalo, da bi bile zelo zanimive tudi nekatere ostale vrste površin. Zaradi strukture OSM podatkov (deljene meje med površinami) pa je bolj smiselno uvoz narediti hkrati in ne v več fazah (v tem primeru bi imeli meje sosednjih poligonov podvojene). Katere vrste površin točno bi uvažali pa je stvar dogovora, v skrajnem primeru lahko celo vse.

Sam se nagibam k vsem površinam razen RABA_ID=3000 (Pozidano in sorodno zemljišče), ker slednje vsebuje ceste, naselja, deponije, stadione, letališča…skratka vse “man_made nekmetijske objekte”, kar:

  • je za OSM premalo natančno (za kmetijske, od koder izvirajo pa je to bilo povsem dovolj)
  • ni nekega OSM taga, ki bi opisal to vrsto površin
  • imamo v OSM ceste kot linijske objekte in ne kot površine
  • je na teh površinah že največ podatkov v OSM in bi imeli največ konfliktov oz bi površina lahko motila urejanje.
    Uvoz vseh ostalih (razen 3000) površin bi nam hkrati v OSM izrisal tudi površine mnogih v OSM še neobstoječih cest (Če bi uvažali samo gozdove bi imeli ceste samo skozi gozd, na travnikih in ob robu gozda pa bi se izgubile). Ta problem je rešljiv tudi s tvojim predlogom za rasterski sloj, ki bi ga nalagali kot podlago v urejevalnike in potem vrisovali v OSM, vendar bi v tem primeru končni uporabniki ceste videli šele po ročnem vrisu, v primeru uvoza pa bi se “nek cesti podoben pas” prikazal končnim uporabnikom brez dodatnega vrisovanja (ne bi pa navigacije še teg uporabljale za routing!).

Je pa potrebno še doreči način označevanje (tagging), kar je v nekaterih primerih lahko problemtično. Tam kjer se mi označevanje ne zdi problematično sem v wiki tabeli to označil z zeleno.

Ja, uvoz bo zaradi obstoječih podatkov moral potekati po posameznih področjih (en po en kvadrat), po potrebi, “ročno” (odprtje pripravljene .osm datoteke v JOSM, grob pregled, upload, popravki konfliktov, bolj natančno označevanje rečnih bregov, jezer… preudarno združevanje relacij, upload…)

Če kdo želi je opcija tudi, da podatke razrežemo TUDI (poleg obstoječega 3x2 km grida) na bolj drobne kvadrate, npr neposredno po referenčni 1x1 km mreži, da bo lažji uvoz v bližini obstoječih podatkov in področja ročnega merganja podatkov manjša.

Iz skupine, ki smo pripravljali uvoz, se sam precej bolj nagibam k temu, da bi uvozili samo podatke, ki predstavljajo gozd. V tagging shemi bi to pomenilo, da bi npr. prevzeli naslednje rabe iz registra KGZ (Kmetijska in Gozdna Zemljišča):

  • 2000 (gozd) … landuse=forest
  • 1500 (drevesa in grmičevje) … natural=scrub
  • 1410 (kmetijsko zemljišče v zaraščanju) … natural=heath
  • 1420 (plantaža gozdnega drevja) … landuse=forest
  • 1800 (Kmetijsko zemljišče, poraslo z gozdnim drevjem) … landuse=forest

Na ta način bi prišli do dokaj dobrega sloja gozdov (večinoma landuse=forest), kar bi nam dalo dobro geometrijsko osnovo in predvsem pokritje sedaj zelo “bele” Slovenije na nekaterih področjih.

Poleg tega vidim še nekaj argumentov, zaradi katerih nekako ne bi šel v prenos drugih vsebin:

  • definicije posameznih vsebin so vendarle različne in preslikave niso vedno popolnoma “čiste”
  • s tem ohranjamo “originalnost” in “odprtost” OSM, ki sloni na “prispevkih” prostovoljcev, lokalnem poznavanju prostora in izvajanju meritev - mislim, da bi prenos velikega obsega vsebin iz KGZ preveč “obremenil” vsebino OSM in morda celo oviral prispevke lokalnih poznavalcev
  • dobili bi zelo nekonsistentno pokrita področja - danes imamo področja, ki so pokrita z gozdovi, večinoma dokaj prazna glede ostalih “kmetijskih” vsebin in bi sedaj dobili področja zelo podrobno pokrita s “kmetijskimi” vsebinami, medtem ko bi ostala sedaj že “pokrita” oziroma vrisana področja (npr. v bolj urbanih področjih) ostala taka kot so in večino brez “kmetijskih” vsebin

Morda je smiselna še kakšna vmesna varianta. Če bi kdo npr. želel prenesti vinograde na nekem omejem območju, je to mogoče to izvesti tudi posebej.

Ideja pa je seveda ta, da širša skupnost o tem skreše mnenja in se na koncu dogovori.

Khm, tehnično je izvedljivo tudi to, da pripravimo več variant podatkov, npr

  • eno samo z gozdovi in grmičevji (kar si opisal zgoraj)
  • in eno ločeno z vsem razen vrste 3000 (Pozidano in sorodno zemljišče), četudi morda ne najdemo čisto idealnih preslikav v OSM tage (uvozimo kakšno bolj posiljeno varianto) in se morda še ne izrisujejo v obstoječih aplikacijah (tile, navigacije…)
  • in eno ločeno s površinami, kjer tagging ni težaven in se stvari lepo preslikajo v OSM tage
  • in eventuelno še kakšno vmesno varianto (nima pa smisla pretiravati s številom variant).
    Tisti ki bo uvažal pa se odloči katero varianto bo uvozil (prelaganje odločitve na uvažalca :slight_smile: ) … ampak to bi bila le skrajna, rezervna varianta, da lahko nadaljujemo tudi če tu nikakor ne bi dosegli konsenza.

Vinogradi se pa itak ne bi uvažali tam, kjer jih ni (npr gorenjska, kočevska), hmeljišč ne bo na primorskem, skalovja v prekmurju itd. Prehodi med pokrajinami (delež vinogradnih/travnatnih/njivskih… površin) pa mehki (=naravni) in vinogradi/travniki/njive ne odrezani po nekem umetnem gridu (naš sicer izhaja iz EEA referenčnega grida, ampak vse to je umetno).

Na tistih predelih, kjer sem gozdove (bolj na grobo) ročno vrisal jaz, bi šel celo tako daleč, da bi jih izbrisal in uvozil na novo (z dodatnimi vrstami površin). Je pa vprašanje, če je etično kaj takega početi na “tujih” (=tistih, ki jih je vrisal nekdo drug) gozdovih. Teh etičnih zadržkov nimamo pri manjših ročnih dopolnitvah in popravkih (cest, hiš, naselij…) ampak se pojavijo šele pri uvažanju, ker bi to početje (steamroller import) lahko povsem zatrlo/demotiviralo sicer zelo produktivne kartografe, čigar delo bi zavrgli (in pri tem morda celo izgubili kakšne natančnejše informacije, npr o vrsti gozda, naklonu vinograda, nivoju hrupa na močvirju in kaj vem kaj še…)

Prebrati velja tudi smernice za uvoz v OpenStreetMap (coloredstone, to ne leti nate, ker verjamem, da si to že prebral, ampak za vse ostale).

Preden preveč razglabljamo in preden pride do kakšnih prerekanj sem za (tretje :)) mnenje vprašal še na imports@ poštnem seznamu.

Izgleda, da prvotni testni uvozi niso bili povsem všeč OSM inspectorju, zato jih je uporabnik Map47 popravljal z nič kaj zgovornim opisom “Eliminato segnalazione in OSM Inspector-Geometry”. Morda kdo uspe ugotoviti kaj je bilo narobe?

Že vidim, da bo tole pošten zalogaj za vso SLO OSM skupnost. Če bi se zadeve lotili metodično, bi nemara tole Slovenijo lahko precej polepšalo.
Kar se tiče uvoza bi predlagal, da se pestrost vseh možnih tipov zemljič omeji v mestih bolj, kot pa na podeželju kjer je ponavadi manj zrisanih objektov (hiš,cest)
Tukaj bi se lahko pestrost nekoliko bolj povdarila na površinah. Ker sem iz Prekmurja, bi dodal razen gozdov še vinograde in travnike.
Če lahko še malo karikiram: Se pripeljem v Lj. z neko povprečno androidno navigacijo na kateri teče OsmAnd+ ali kaj podobnega.
Ta mi začne “trokirati” ker enostavno ne more zrenderirati toliko podatkov-detajlov kot jih imamo zrisanih v prestolnici. Na podeželskem koncu te težave ni :slight_smile:
Če bi pa izpadlo, da je tehnično prezahtevno izvesti uvoz nekega prednastavljenega filtra za dano območje, bi pa absolutno šli najprej z gozdnimi površinami, naknadno pa še kaj več.

Zadnjič na sestanku (30.1.2015) smo prisotni med površine za uvoz uvrstili:
Hmeljišča
Vinograde
Sadovnjake (obe vrsti enako)
Oljčnike
Gozdove (3 vrste površin v rabi)
Grmičevje (heath)
Drevesa in grmičevje (scrub)
Ter te sklepe zapisali v wiki: https://wiki.openstreetmap.org/wiki/Slovenia_Landcover_Import_-_RABA-KGZ

Na sestanku smo njive in travnike izločili, ker naj bi se zaradi kolobarjenja pogosto izmenjevali. Vendar smo naknadno ugotovili, da so tiste površine, ki so v kolobarjenju začasno travniki v rabi vseeno kategorizirani kot “njive” in opis je zelo skladen z landuse=farmland. Njive so malo neposrečeno ime, bolje bi bilo “kmetijske povšine - njive in začasni travniki”.

Te razumem, tudi jaz uporabljam OsmAnd in je npr za pot v Nemčijo potrebno prenesti zemljevid Avstrije, ki pa je ogromen, večji del podatkov pa v dani situaciji odveč. Zato si v takšem primeru ponavadi naložim lažji in manjši road-only zemljevid, ki ga ponuja OsmAnd. Od nemčije pa le kompletno Bavarsko. Če bo potreba (rast podatkov bo počasi, ne eksplozija čez noč) se podobno lahko uvede za slovenijo (razbitje na več kosov). Road-only zemljevide OsmAnd za Slovenijo že ponuja. Italija je zelo razrobljena in včasih imam dilemo katero regijo točno moram naložiti, ampak to je stvar uporabniškega vmesnika/UX.

Kar se pa konkretno prestolnice tiče, bo s tem uvozom dobila precej manj podatkov (praktično nič, ker pozidanih območij ne bomo uvažali, okoli ljubljane pa so že vrisane njive in gozdovi) kot podeželski predeli.

Brez skrbi, iamo točen nadzor nad tem katere površine se uvažajo in kako se označijo. V končni fazi bo šlo pa vse skozi človeške roke (uvoz preko JOSM urejevalnika).

Na naslovu https://docs.google.com/forms/d/1-KgebKA7YPCxnVqvR5nl856OKDFGgu9xLMFgzAEeCPA/viewform
je odprta kratka anketa glede obsega uvoza podatkov RABA-KGZ.

Pazite, da se ne zmotite in ne izpolnite 2x. To se tudi da:)

Na tile map strežniku je sedaj na voljo zadnja verzija vira, izdana 31.3.2015:
http://wms.openstreetmap.de/slippymap/RABA - vse
http://wms.openstreetmap.de/slippymap/RABA3000 - pozidana območja

To ni namenjeno prerisovanju, pač pa preverbi skladnosti z obstoječimi OSM podatki. Uvoz vektorskih podatkov bo rešen bolje.

Oba sta na voljo tudi prek JOSM urejevalnika, v meniju Imagery (kadar imate pogled odprt na področju Slovenije)

V zadnji izdaji weeklyosm.eu smo omenjeni, da čakamo odobritev:

Še malo, pa bo :smiley:

Na http://raba.openstreetmap.si so na ogled podatki, kakršne naj bi uvozili ko dobimo odobritev na imports@ mailing listi.

Pregledovalnik ima več slojev: osnova so obstoječi OSM zemljevidi, čez pa je položen raba rasterski sloj (50% prosojen), izohipse iz opensnowmap.org in mreža, po kateri so razrezani podatki. Klik na posamezen izrez prikaže id izreza (Split) in gumb z očesom - klik nanj naloži še vektorske podatke v brskalnik, potem pa kllik na posamezno površino prikaže njene lastnosti - osm tage, kot je videti na sliki:

Malce jih preverite vsaj po svojih okoliših.
Podatki so s konca marca (trenutno zadnji).

Pozdrav,

Po dveh letih od odobritve RABA še vedno ni v celoti naložena v OSM. Ali je možno ponuditi kakšno roko pomoči?
GIS so moj drugi dom.

lp
Grega

Seveda!

Tule je wiki stran, kjer je opisan osnovni protokol: https://wiki.openstreetmap.org/wiki/Slovenia_Landcover_Import_-_RABA-KGZ

Tole je pa še par napotkov oz. dobrih praks:

Za izvajanje importov se je potrebno praviloma registrirat kot poseben uporabnik (pravilo “Use a dedicated user account” na temle linku: http://wiki.openstreetmap.org/wiki/Import/Guidelines)). Pri nas smo se dogovorili, da bomo našim uporabniškim imenom dodali pripono “_import”.

Na naši wiki strani tega importa spodaj se vidi, kdo so še drugi, ki izvajajo import:
https://wiki.openstreetmap.org/wiki/Slovenia_Landcover_Import_-_RABA-KGZ

Delo poteka na sledeč način (priporočilo):

  1. Običajno pred izvedbo importa “pripravimo” obstoječo vsebino, kjer se bo import izvajal, na način, da bo kasneje morebiti že obstoječo vsebino mogoče prilagoditi importu. Največ dela je z “umikanjem” gozdov in kakšnih drugih tipov landuse (meadow, scrub), včasih tudi z brisanjem teh elementov. Včasih postane to komplicirano, če so elementi zgrajeni kot multipoligoni. Največ tega je na meji z Avstrijo.

  2. Priporočljivo je, da se vsebine kot so ceste, reke, morda tudi stavbe položajno prilagodijo elementom importa (če je to seveda ustrezno, ni nujno, da podatki uvoza vedno ustrezajo stanju v naravi in če kdo to ve, potem je seveda priporočljivo, da sledi “lokalnemu poznavanju” situacije.

Področje importa se najprej prenese v JOSM: na strani http://raba.openstreetmap.si se izbere en »split« kvadrant in požene »Load full to JOSM«. V JOSM mora biti aktiven plugin JOSM remote control.

Ko se podatki »split« kvadranta naložijo v JOSM, se čez njega naloži nov sloj (Download as new layer) na istem področju (prav nič se ne premika levo desno). Naloženi podatki »split« kvadranta bodo vidni v ozadju, na atkivnem sloju pa se urejajo elementi (ceste, reke, …). Upload se označi kot “Preparation for RABA import”, brez oznake za source.

  1. Nato izvedemo import. Najprej odstranimo sloj, ki smo ga pravkar shranili in je sedaj aktiven »split« kvadrant. Kaj veliko dela s tem ni, včasih zaradi prevelikega števila lomnih točk (omejitev je 2000) lahko javi error (če ni to že odpravljeno?). Tako linijo je treba samo razlomiti (split – označi se dve sosednji točki, ki sta lastni samo tej liniji in se linijo razlomi - Tools - Split way). To je potrebno storiti še na enem drugem koncu. Import označimo npr. “RABA-KGZ import (številka split kvadranta)”, kot source pa navedemo “RABA-KGZ”.

Če to upoštevamo, vidimo spremembe, ki imajo naveden ta vir na strani
http://resultmaps.neis-one.org/osm-changesets?comment=RABA-KGZ#9/45.8001/14.0927

  1. Po izvedbi importa ponovno naložimo celotno območje v JOSM in (to pa je precej obvezno) naredimo kontrolo - Validation. Običajno javi errorje in warningse, ki so tipa “Duplicated ways” in “Duplicated nodes”. Z ukazom Fix, jih večinoma zelo enostavno odpravimo. Ob tem se lahko popravi še kaj drugega.

Pri nekaterih območjih moramo pogledati še, kako se vogali območij stikajo z že uvoženimi področji. V začetku smo namreč imeli nekaj težav in so se vogali nekam čudno pozicionirali izven ravne linije.

  1. Zadnja priporočljiva operacija je ponoven pregled, če je ostala vsebina kolikor toliko usklajena z importirano. Največkrat je smiselno urediti vsebine landuse=residential, landuse=industrial in podobno. Ni lepo, da ta območja neurejeno križajo vse ostalo. Prekrivanje sicer ni prepovedano, včasih je celo pravilno. Pri tem ni nujno popolnoma slediti obrisu pozidanih območjih, ki jih RABA že določa, ampak je včasih smiselno po logiki določiti tudi na novo.

Tako operacijo se označi z “Improvements of RABA import”, brez oznake za source.

Kar na delo:)

coloredstone, super si spisal ta navodila!

Na http://raba.openstreetmap.si/ sem v meni Info dodal povezavo na http://resultmaps.neis-one.org/osm-changesets?comment=RABA-KGZ

Če se kdo ustraši tako dolgih navodil in je povsem neizkušen z OSM in ga zanima uvoz le za nek manjši specifičen predel pa lahko tudi tu to izpostavi in bo (sem prepričan) stvar izpeljal kdo od že izkušenih “veleuvoznikov”.

Uroš Jamnik se je v magistrskem delu lotil primerjave pokrivnosti tal:

  • OpenStreetMap zemljevidov v okolici Maribora (tu so vrisani pretežno le gozdovi, ročno)
  • podatki klasifikacije (QGIS z vtičnikom »Semi-automatic classification plugin«) na podlagi satelitskih posnetkov (barvni spekter satelita Sentinel 2),
  • kontrola s podatki dejanke rabe (RABA) Ministrstva za Kmetijstvo, gozdarstvo in prehrano kot najnatančnejši vir o rabi tal na območju Slovenije :slight_smile:

Po nekaj težavah in izostankih podatkov na strani MKGP ( https://rkg.gov.si/vstop/ ) se zdaj podatki za uvoz na https://raba.openstreetmap.si/ spet redno osvežujejo, zdaj samodejno vsak 1. dan v mesecu s podatki ki jih je MKGP objavil zadnji dan predhodnega meseca :smiley:

Ker so zadnje čase bili ob uvozu v rabi vse sorte komentarji in je JOSM bug 11310 bil popravljen v verziji r16324 sem dopolnil stran za uvoz, da nastavi komentar in source:

Po želji seveda lahko spremenimo, cilj pa je, da imamo možnost te changeseete zbrati na nek enostaven način, npr na
https://resultmaps.neis-one.org/osm-changesets?comment=RABA-KGZ
ne da bi s teem po neepotrebnem obremenjevali uvaževalce :slight_smile:

Kot ste morda že ugotovili se je samodejno mesečno posodabljanje ustavilo s koncem aprila:

Na viru (https://rkg.gov.si/vstop/ )

so podatke premaknili v mapo /arhiv/:

kjer se vidi, da so od maja naprej uporabili zip arhiv (namesto rar).

Popravil sem skripto in trenutno se procesirajo podatki za avgust:

Predvidoma bi se morali danes tu pojaviti tudi podatki za september, ki se bodo jutri zjutraj obdelali in pripravili za uvoz na https://raba.openstreetmap.si/

Jup, izgleda da ta flow zdaj spet deluje in se podatki spet samodejno posodabljajo:

Če opazite, da se kdaj spet zatakne prosim sporočite.