Imamo soglasje za uporabo grafičnih podatkov RABA!!

Rkg.Mkgp@gov.si

11.47 (pred 19 minute)

Za meni
Spoštovani,

podatki evidence dejanske rabe so javni in se lahko uporabljajo v vse namene, ob predpostavki, da je naveden vir in datum podatkov ter navedba, da se evidenca dejanske rabe kmetijskih in gozdnih zemljišč sprotno posodablja, glede na dostopnost virov in informacij in da stanje, ki ga prikazujete ne odraža vedno trenutnega stanja.

Lep pozdrav, Alenka Rotter

27.06.2014 09:29
Prosim, odgovorite za rkg.mkgp

    Za:        rkg.mko@gov.si,
    kp:        
    Zadeva:        Prošnja za soglasje za uporabo grafičnih podatkov RABA v OpenStreetMap

Super!

Za občutek kaj je to:
http://rkg.gov.si/GERK/WebViewer/#map_x=500511.2115&map_y=102281.1&map_sc=1785&layers=SLO_RASTER_TEMPLATE-client,Rastri,DOF-client,REZI250,REZI25,REZI5,RABA

Več o tem pa na http://rkg.gov.si/GERK/
Tu je na voljo tudi celoten dataset za prenos (600 MB).

Statistika podatkov:
http://rkg.gov.si/GERK/documents/Statistika_GR/SGR_last.txt

Dokumentacija za uvoze podatkov:
http://wiki.openstreetmap.org/wiki/Import

Določiti je potrebno preslikave iz dataseta v OSM podatke.
Šifrant je na http://www.uradni-list.si/files/RS_-2008-122-05471-OB~P001-0000.PDF
obstajajo pa tudi naknadne spremembe šifranta, ki jih bo potrebno zbrati…
Predlagam, da to delamo na namenski strani v OSM wikiju.

Zahteve “naveden vir in datum podatkov ter navedba, da se evidenca dejanske rabe kmetijskih in gozdnih zemljišč sprotno posodablja, glede na dostopnost virov in informacij in da stanje, ki ga prikazujete ne odraža vedno trenutnega stanja.” pa si razlagam kot:

Navedba vira, nekako tako kot imamo GURS za državno mejo, to je ok.
http://wiki.openstreetmap.org/wiki/Tag:source%3DGURS (stran povezana iz zemljevida)
http://wiki.openstreetmap.org/wiki/Geodetska_uprava_Republike_Slovenije
primer: http://www.openstreetmap.org/way/39890185

Kaj si pa predstavljajo pod “sprotno posodabljanje”? Ali s tem slučajno zahtevajo (oz pričakujejo), da ima OSM vedno ažurne podatke (oz vsak kakršne imajo oni), ali pač nerodno razvlečen disclaimer, da podatki ne odražajo nujno dejanskega stanja v naravi oz uradnih evidencah? Slednje mislim da itak že velja za celoten OSM in ne vem če je potrebno posebej izpostavljati.

Citat … “da stanje, ki ga prikazujete ne odraža vedno trenutnega stanja”

mislim, da je dosti jasno, da hočejo samo da dodamo opozorilo da podatki ne odražajo vedno trenutnega stanja.

lp
G

To kar OSM itak že ima v licenci?
http://wiki.openstreetmap.org/wiki/Disclaimer
Ali še kaj dodatnega? Ne vem sicer kam bi to še dodatno napisali… Lahko pač pri opisu vira dopišemo in linkamo ta disclaimer.

Vir bi pa lahko vključili na
http://www.openstreetmap.org/copyright in
http://wiki.openstreetmap.org/wiki/Contributors

Zdravo,

Fajn novica. V QGISu sem naložil .shp rabe (600 MB), ni mi pa uspelo dodati OSM map layerja, javlja napako, nisem se poglabljal.
Tukaj sta dva primera rabe za MB in LJ: https://dl.dropboxusercontent.com/u/6894864/temp/raba-mb.jpg in https://dl.dropboxusercontent.com/u/6894864/temp/raba-lj.jpg

Prvo, kar se da ugotoviti je, da so poligoni razbiti v pravokotno mrežo. Torej če bomo tole importali, je eno od vprašanj ali to združevati v večje multipoligone ali ohraniti tako, kot je. In kako bi se sploh lotili importa (in kdo).

lp Igor

Ja, razbitje po mreži sem opazil tudi jaz. Je pa zanimivo, da razbitje nima doslednega vzorca, npr:

Skratka nekih dosledno upoštevanih pravil glede te mreže ni.
Idealno bi bilo poiskati soležne poligone istih vrst in jih združiti skupaj, lahko pa bi nam to potem povzročilo tudi težave pri nadaljnem urejanju v OSM orodjih (npr večje zvezne kompleksne gozdne površine…). Lahko pa jih ne bi združevali fizično (zlivanje mej na mreži), ampak z multipolygon relacijami (morda tak nivo že obstaja v shapefile-u?).

Ker je vir Ministrstvo za kmetijstvo in okolje so tudi podatki ustrezno orientirani, z natančnio razčlenjenimi vrstami kmetijskih površin, in zelo grobo razčlenitvijo površin označenih z “3000 Pozidano in sorodno zemljišče”, kamor spadajo tako ceste, naselja, zelenice med cestišči… teh površin verjetno nima smisla uvažati, ker so po mojem mnenju preveč splošna, “ostalo” z vidika kmetijstva.

Glede na to, kar praviš, se mi zdi, da bi mogoče najraje pustili poligone takšne kot so, brez združevanja. Tako kot praviš, drugače lahko na koncu dobimo par ogromnih multipolgonov z gozdom, s katerimi bodo vedno težave pri kakršnemkoli obdelovanju OSM podatkov za Slovenijo.

Je sploh kakšna prednost imeti multipoligone? Dober GIS software bo tako ali tako znal združiti zadeve v večje entitete, če bo kdo to rabil.

Poraja se mi nekaj vprašanj:

  1. Ali uvoziti vse ali ne? Ena opcija je uvoziti vse, za preveč splošne kategorije potem pustiti netagirano, pa se potem kasneje ročno tagira.
  2. Kaj narediti z obstoječimi landuse podatki?
  3. Kako uskladiti podatke na meji s sosednjimi državami?
  4. Kakšen bi bil najboljši postopek uvoza? Ima kdo že iskušnje s tem (jaz nimam)?
  5. Na koliko ljudi lahko računamo, da pomagajo pri tem?

V prid združevanju bi bila odprava artefaktov mreže pri izrisu nekaterih vrst površin v nekaterih programih (površine z obrobo ali šrafuro). Ampak to je načeloma že problem izrisa in ne podatkov samih.

Tehnično pomoč bi zagotovo dobili v OSM skupnosti, ker je podobnih uvozov že bilo narejenih precej. Zanimivo bo zagotovo tudi z multipolygon relacijami, določati inner in outer člane, pa koliko največ poligonov združiti v posamezno relacijo… + razmisliti o možnostih osveževanja podatkov (npr vsakoletni reimport tistih, ki v OSM ne bi bili spremenjeni)

Vsebinska vprašanja (premapiranje šifrantov) in razreševanje konfliktov pa bo ostala na lokalcih. Neuporabnih podatkov (3000 Pozidano in sorodno zemljišče) pomoje nima smisla uvažati. Meje se bodo pa itak videle zaradi sosednjih površin. In načeloma je po tistih površinah treba narisati ceste, naselja, hiše, parke…gneča bo velika, tudi če bo brez oznak.

Za začetek bi bilo pomoje treba to nekam zrenderirati + vključiti kot polprosojno plast čez obstoječih zemljevid, da vidimo kakšna so odstopanja od obstoječih podatkov, kaj je boljše v primeru konfliktov ipd. Pač ocena primernosti vira.

Predlagam srečanje v Kmečkem Hramu v Ljubljani, 19. septembra ob 18. uri. Potrjeno imam, da pridejo Coloredstone, StefanB, Mark in jaz. Vse, ki so zainteresirani vabim na srečanje, kjer se bomo za začetek vsaj spoznali, potem pa dogovorili za nadaljne korake. Prosim za potrditev…

Kje: Kmečki Hram, Ljubljana ( http://www.openstreetmap.org/#map=18/46.07848/14.53686 )
Kdaj: petek, 19. septembera 2014 ob 18. uri.

:slight_smile:

Podatki dejanske rabe MKO so bili testno že uvoženi - primer manjšega območja: http://www.openstreetmap.org/way/286671925

Podatki so bili pripravljeni na sledeč način (okvirno po spominu):

  • iz sloja so izbrani elementi, ki predstavljajo gozd (šifra 2000); ostalih elementov se verjetno ne splača prenašati, ker bi bilo potrebnega preveč usklajevanja z drugimi vsebinami, ki že obstajajo v OSM
  • podatki tega sloja so bili nato združeni, tako da se odpravi mreža
  • sloj je nato trasnformiran iz GK48 v ETRS84
  • sloju so bili dodani atributi (source, source_date, source_name) - to je še vse za celo Slo
  • sloj je nato razrezan na manjša področja (v tem primeru po kvadratkih standardne EU km mreže)
  • kvadratek se lahko nato importira preko JOSM (kar je verjetno najlažje; da se tudi preko Merkaator-ja, a je manj prijazno)
  • lahko se seveda pripravi tudi večje območje

V vsakem primeru, ne gre za čisto avtomatski import. Vsebino je nujno potrebno pregledati in po potrebi uskladiti z že obstoječo vsebino.
Verjetno ni smiselno nadomeščati obstoječe vsebine, ampak se lotiti področij, kjer gozdovi še niso pokriti, kar je bistveno lažje, kot pa popravljati obstoječo vsebino.

Mislim, da ni smotrno importirati zelo velikih poligonov (a ni tudi nek limit 2000 vertexov?). Tudi pri kasnejšem delu z velikimi poligoni lahko prihaja do težav.

Kakovost podatkov je lahko zelo različna, kar je posledica različnega načina dela (tudi natančnosti zajema), različnih osnovnih virov, na osnovi katerih se zajemajo podatki dejanske rabe (DOF5) ali OSM (npr. bing), različnih interpretacijskih pravil. Ko bomo npr. pogledali importirane podatke in satelitske podatke v ozadju, bomo videli kar precej razlik.

Vsekakor je tale akcija vredna kakega bolj resnega pristopa skupnosti in je smiselno, da se res dogovorimo, kako bi počeli ta import.

Sem poskušal ugotoviti kaj vse je bilo že uvoženo na ta način, kot ga opisuješ coloredstone, ampak je source tag enak samo za to relacijo: http://overpass-turbo.eu/s/4Ym
Je dejansko uvožen samo ta kvadrat za pokušino ali gre za zmešnjavo pri označbah vira?

Bližnja, pravokotna gozdna področja so nekoliko starejša, in narejena (ročno) spletnim OSM urejevalnikom iD, npr: http://www.openstreetmap.org/changeset/19761550

Škoda bi bilo, da bi druga (razen gozda) natančna področja kar zanemarili. Verjamem, da so podatki o vinogradih, njivah, travnikih, oljčnih nasadih, grmičevju, jezerih … zelo točni in lahko znatno pripomorejo k popolnosti zemljevida. Če je razlog za zanemarjanje prostor je bolj smotrno filtrirati podatke na izhodu (npr za avtomobilsko navigacijo vključiti le ceste in povezane elemente).

A se njihovo soglasje za uvoz morda nanaša le na gozdne površine, kot bi lahko sklepali iz http://forum.openstreetmap.org/viewtopic.php?id=25791 ??

Na opisani način je bil poskusno uvožen samo ta kvadrat.

Soglasje je razumeti kot soglasje za uporabo vseh podatkov, saj so podatki generalno javni in razen pravil glede navedbe virov, drugih omejitev ni.
Se je pa pri pridobiti soglasja res razmišljalo bolj o podatkih o gozdovih (češ “glej kako zgleda Slovenija, ko odpreš OSM, a se to ne bi dalo urediti”).
Kolikor sem sam gledal in poznam te podatke bi seveda bilo mogoče uporabiti tudi druge podatke, s tem da je potreben biti previden pri morebitnem prekrivanju vsebine na področjih, kjer je precej vsebine na OSM že vrisano.

Vsekakor smiselno proučiti tudi to.

Zdravo,

Se bom probal udeležiti sestanka. Če je še kdo iz MB konca zainteresiran, naj mi javi, pa delimo stroške prevoza.
Glede uvoza pa se strinjam s Štefanom, škoda bi bilo ne uvoziti tudi druge stvari, ne samo gozda, če že (končno) imamo nek zunanji vir, ki ga lahko uporabimo.

Mapbox je uvažal naslove in hiše v New Yorku in je v blogu dobro opisano, kaj vse so uporabljali in kaj je dobro za import:
Uporabljali so Tasking manager in probleme so pa dodajali na GitHub (issues) skupaj z import skripti.

Pozdravljeni!
Rad bi le dodal da se tag source itd ne dodaja na posamezne elemente, ampak, kot je to praksa tudi drugje, samo v posamezne changesete.

LP,
Damjan

S ciljem, da se spoznamo med seboj se dobimo v Kmečkem hramu v Ljubljani. Obdelali bomo tudi uvoz podatkov (glej forum OSM http://forum.openstreetmap.org/viewforum.php?id=58))

Kraj: gostilna Kmečki hram v Ljubljani (http://www.kmeckihram.si/). Čas: petek, 19.9.2014 ob 18:00

Vsi prisrčno vabljeni!