Dragi Peđa, hvala ti najepše na dostavljenim komentarima. Za konačni sledeći korak su nam potrebne tehničke informacije, ali prilično sam optimističan.
Jedino pitanje, je pitanje vremena. U zavisnosti od tajminga kako se šta pogodi ova priča ide ka tome da bude realizovana. Dobro je da pouzdane informacije obezbedim što pre. Dalke, kao razultat naše prepiske uskoro bi trebalo da izložim konkretno koji su resursi neophodni za početak, koja komponenta ima koju ulogu, koji su konkretni koraci, dinamika i šta je konačni rezultat u smislu šta smo dodeljenim resursima resursima postigli u ovom momentu. Ukoliko to funkcioniše, onda idemo na plan skalacije. Iskreno se nadam da će se ljudi uključiti, ako se ne varam ovo pitanje je pokrenuto još 2012. godine. U nastavku naše već nepregledne prepiske, dodao sam svoje komentare. :) Pozdrav, Nemanja 2017-11-21 13:00 GMT+01:00 <talk-rs-requ...@openstreetmap.org>: > Send Talk-rs mailing list submissions to > talk-rs@openstreetmap.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.openstreetmap.org/listinfo/talk-rs > or, via email, send a message with subject or body 'help' to > talk-rs-requ...@openstreetmap.org > > You can reach the person managing the list at > talk-rs-ow...@openstreetmap.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Talk-rs digest..." > > Today's Topics: > > 1. Re: Talk-rs Digest, Vol 47, Issue 9 (Predrag Supurovic) > 2. Re: Talk-rs Digest, Vol 47, Issue 9 (Pedja Supurovic) > > > ---------------Прослеђена порука------------------ > From: Predrag Supurovic <pe...@supurovic.net> > To: talk-rs@openstreetmap.org > Cc: > Bcc: > Date: Mon, 20 Nov 2017 13:37:44 +0100 > Subject: Re: [OpenStreetMap Serbia] Talk-rs Digest, Vol 47, Issue 9 > > > On 18.11.2017. 22:44, Немања Паунић wrote: > >> - Preuzimanje mape sa OSM i prilagođavanje našim potrebama. Ovo bi moglo >> da se obavi poptuno automatizvoano i povremeno. Dakle ne mora da se radi u >> stvarnom vremenu svaki put kad korsinik zeli da preuzme ili pogleda mapu >> vec ond kada je to zgodno. >> >> NP: Na ovome sam radio pre par meseci. Nisam siguran da li sam uključio >> sve prikupljene slojeve i mislim da je ta baza bila oko 2.5GB što nije >> ništa strašno. >> (Molim da me ispravite sa preciznim podatkom.) >> > > Pretpostovljam da je to ta veličina. > > Time se omogućava da se i dalje sve izmene u mapu unose u OSM - koristeći >> sve već postojeće alate. Time bi se praktično korsitili već dostupni >> resursi OSM, a kod nas bi bio potreban računar na kome bi se vršilo >> automatsko preuzimanje i dopunjavanje mape. Taj računar ne bi morao da bude >> nešto megalomansko, baš naprotiv, osim dosta prostora na disku z >> amanipulaciju podacima, drugi resursi nisu kritični. >> >> NP: Ovaj deo verovatno nisam razumeo a bitan je. Ako je ideja preuzimanje >> seta podataka sa zvaničnih servera OSMa na dnevnom nivou, zar onda nećemo >> ponovo imati problem sa Kosovom? Koliko sam razumeo, bilo kakav pokušaj >> rada na Kosovu se karakteriše kao vandalizovanje. Kako da prikupljamo >> Kosovo sa OMS arhitekturom a da se čuva u lokalnoj bazi? >> > > Nama su zabranili da menjamo sve ono što Šiptari unose i da unosimo > podatke koji nisu uskladu s anjihovom politikom. S obziromda se radi o > geografski egzaktnim podacima, najveći deose pokalapa. Problem su samo > statusi i nazivi. > > Na primer, problem je status granice i problem je što su Šiptari sve > prebacili na šištarski jezik. > > Mi možemo i dalje da unosimo podatke, čak i da unosimo na srpskom samo što > podrazumevani jezik mora da bude šiptarski. Strukura baze je takva da > možemo da unosimo i neke naše podatke koje niko neće ni dirati ako se ne > vide na default mapi. > > Licenca OSM nam doyvoljava d ami preuzmemo bazu, perpravimo je, što u > našem slučaju znači, ispravimo status granice i prebacimo da default jezik > bude srpski i da tako izmenjenu bazu objavimo. Te izmene ne smemo da > uradimo na glavnojbazi ali nam niko ne brani da napravimo kopiju i izmene > unesemo u našu kopiju. Tako kopija, opet, prema licenci, mora da bude javno > dostupna na isti način ko i glavna. > > Dakle, sa te strane nemamo problem i odatle i potiče ideja da napravimo > sopstveni map server. > NP2111: Odlično. Dakle nemamo problem sa editovanjem i nisu potrebni dodatni resursi koji bi hostovali te mehanizme. Projekat se svodi na preuzimanje podataka sa postojeće infrastrutkure. Pitanje licence je kristalno jasno i još jednom potvrđujem da će se podaci distribuirati po istoj licenci. Po pitanju dostupnosti baze mi je neophodan odgovor na koji način treba da omogućimo preuzimanje podataka? (Servis, prost backup, nešto treće) Ukoliko je u pitanju neki web servis, treba uzeti u obzir da možde nismo u stanju da odmah odgovorimo sa ovako nečim (Primer zakačenih 200 konekcija koje žele sa našeg servera putem WFS ili nekog drugog veb servisa da preuzmu kvalitetne podatke koji su open. :) ) Ovde imamo primer Holandije koja je na vestima objavila da su neki podaci postali otvoreni i da su mogući za preuzimanje. Tog momenta je nagrnulo pola Holandije mahnnito da skida narednih mesec do dva dana i šta im treba i šta im ne treba da imaju za svaki slučaj ako ovi zatovre. :) Naravno podaci su ostali i dan danas otvoreni, ljdi su to shvatili, imaju i dalje visok saobraćaj, ali mnogo razumnije cifre nego na početku. Ono o čemu ne bih pričao je godišnja cifra koju izdvajaju za održavanje takve arhitekture o kojoj Srbija može samo da mašta. Međutim sem molbe za razumevanje dok ne uspostavimo sistem, ne pravim bilo kave nagoveštaje o mogućoj zloupotrebi licence. > Ja se upravo najviše plašim od broja konekcija koji istovremeno treba da >> pišu u bazu. Ukoliko se ipak ispostavi da je to direktan rad na resursima o >> kojima pričamo, to može da bude problem. >> > > Bazumenjaju samo editori. Toga nema toliko mnogo da predstavlaj problem a > na krajukrajeva editovanej će i dalje da se radi kroz OpenStreetMaps > servise na glavnoj mapi. Mi ćemo te izmene da preuzimamo već urađene. > > NP2111: Odlično, ovo nam isto ide u korist. > > Drugi deo priče koji razumem je da od prikupljene baze podataka kreiramo >> karte pomoću određenog alata (ako sam razumeo to je kod vas MapInk), NIGP >> za to koristi MapServer i GeoServer. Rezultat rada je najpre kreiranje >> dostupnog veb servisa koji je neophodno ubrzati njegovim keširanjem u nekom >> standardnom gridu za standardne razmere. >> Rezultat keširanja je dosta brz servis koji se renderuje gotovo >> momentalno u vidu malih .jpeg ili .png sličica. (Razlika je u što .png >> format ima providnost, cena je što je teži.) >> >> Sve osnove karte koje trenutno koristi nova aplikacija su napravljene na >> ovaj način, jedna od tih karata podseća na OSM (https://a3.geosrbija.rs/ >> ). >> Ovde vas pozivam da za sada deo informacija koji vam je značajan >> prikupite alatima za crtalnje i eksprt u neki od standardnih formata. (na >> primer vektorizacija po ortofoto snimcima visoke rezolucije). >> >> Sam postupak keširanja traje relativno dugo zato što vreme raste >> eksponencijalno sa svakim sledećim zum levelom. Količina tih podataka na >> disku zna da ide i do 0.5TB. >> (Ukoliko neko od vas ima iskustva sa keširanjem podataka, zamolio bih vas >> da podeli informaciju o konačnoj vrednosti keša OSM mape za teritoriju >> Srbije sa objašnjenjem kako to radite i u kom formatu.) >> > NP2111: Odlično, ovo nam isto ide u korist. Pre svega ovde mi i dalje fali koja je tačna procedura kreiranja web servisa od podataka iz baze. Dakle koji alat se koristi i da li je procedura slična onoj koju sam ja opisao a sa kojom imamo iskustvo. Ne mora da se radi generisanej celog keša odjednom a mislim da to niko tako > i ne radi. > > Ja sam za neke druge potrebe radio nešto slično i ja sam pravio keš koji > je dinamičan: kada korsinik ztraći određenu sličicu, serer proveri da li u > kešuiam tu slučicu i akje iam d ali je dovoljno sveža i ako jeste da je > korisniku. Ako nema sličice ili nije dovoljno sveža odna je preuzem od > nadređeng map servera. > > Tako se operećenje raspoređuje na duži vremenski peroiod i samo na one > sličice koje se zaista i koriste. > > Toretski, mi bi mogli da na map serveru rendersujemo samo sličice koje > prikazuju teritoriju Srbije a da ostale preuzimamo sa OSM map servera, ali > je bolej da naš serer renderuje celu planetu iz razlgoa jednoobraznosti > renderinga. > NP2111: Imam iskustvo sa keširanjem na zahtev i trenutno nemam stav. Bio sam zagovornik iz istog logičnog razloga. Međutim ukoliko saobraćaj ili recimo luckasta skripta dohvati otvoren servis da pravi keš iz zabave, može da se desi šah mat u smislu da nam skripta brže puni diskove od onoga što mi stižemo da ispraznimo. :) Otvoren sam po ovom pitanju, nemam konačno mišljenje, ali svakako bi mi dobro došlo ukrštanje mišljenja i naravno konačna projeckija podataka na disku. > > Jednobraznost je potrebna jer je vrlo moguće da mi postaivm nešto > drugačiaj pravial renderovanaj elemenata mape, prilagođena našim potrebama > ili, recimo, našim kartografskim standardima. > NP2111: Imam iskustvo sa ovim. Podatke bi renderovali u standardnom OSM gridu upravo iz razloga kombinacije. Za potrebe geoportala se koristi projekcija EPSG: 32634 (za namenske zum nivoe) dok brzim pregledom vidim da OSM mapa koristi dve standardne EPSG: 4326 i EPSG: 3857. Ukoliko ne grešim, genersisanje sličica bi trebalo odraditi za svaku projekciju. Dakle redudantnost podataka skldišta. Naravno ukoliko ide na zahtev možemo ići sa optimističnom pretpostavkom da će to da nam štedi resurse. U priči keširanja dolazimo do glavnog problema kada se napravi izmena u > bazi i onda treba rekreirati keš. Ukoliko postoji neki elegantan način, rad > sam da čujem više o tome. > Sa takvim sitnim zamenama nemam iskustva. Moja ideja je da se pusti keš za > neki minimalni obuhvatni pravougaonik gde je došlo do izmene. Kao problem > ostaje kako to područje automatski detektovati? > Kao što rekoh ja sam radio keširanje ne nivu jedne sliice. Svaki put kada korsinik zatraži sličicu, ja proverim da li je imam u kešu ako je imam, izbacim je, ako je nemam preuzmem sa map servera. Pored toga imam i proveru zastarelosti, pa ako je sličica u kešu ali je starija od željenog perioda, onda je prvo osvežim u kešu pa prosledim korisniku. Na taj način moj keš nije uopšte opterećen as tim šta kad kešira, već se to inicira samom posećenošću sajta, odnosno upitima. Kada prvi korisnik zatraži neku sličicu iz mape, ona će biti keširana i nadalje svaki sledeći put kad bilo ko traži tu sličicu dobiće je iz keša. Keš se tokom vremena puni podacima na osnovu upita korsinika. Ako korisnici neki deo mape uopšte ne pregledaju, toga neće ni biti u kešu. Meni se to pokazalo kao prilično efikasno po pitanju resursa. NP2111: Ovo su teorijske prednosti keša na zahvev koji je naročito isplativ ukolik broj korisnika nije veliki. Na većem broju korisnika pri ograničenim resursima imao sam i negatvino iskustvo. Za sada bih ovo pitanje ostavio kao otvoreno do neke estimacije teorijske vrednosti podataka. *Ovde moram biti prilično otvoren. S obzirom na to da se radi o državnoj > infrastrukturi, možete pretpostaviti da pristup ovom serveru u smislu > logovanja i administriranja baze ne bi bilo omogućen nekom iz OSMa > zajednice. Nadam se da to ne predstavlja prepreku jer mislim da je > mehanizam najbitniji a dostupnost bi se garantovala institucijom. > Ovde očekujem buru u smislu trud cele zajednice pokušavamo da stavimo u > crnu kutiju itd. > Ne znam koliko će to biti praktično izvsti ako neko od ljudi koji dobro poznaju map server i rendering alata treba to da podešava. NP2111: S obzirom na veličinu sistema i zrelost tehnologije očekujem da ovde postoji dobra dokumentacija + primeri dobre praske. Konfiguracija servra bi bila odrađena uz konsutalaciju sa onima koji imaju iskustvo, ali praktično realizovana od ljudi čija je tehnička nadležnost nad serverom. P.S. Da li pod terminom map server se podrazumeva naziv za server za genersianje sličica ili rešenje http://mapserver.org/ sa kojim imam iskustvo? To bi se, pretpostavljam, rešavalo u praksi.Pretpsotavljam da niej ni problem napraviti neki izolovan resurs kome mogu da pristupe i osobe sa strane sa odgovarajućim ovlađćenjima a koje ne bi imale pristup drugim stvarima. NP2111: Prilično otvoreno pitanje. Ovlašćenje za tako nešto nije baš trivijalno dobiti, ali tehnički je izvodljivo ukoliko se ispostavi da postoji potreba za tako nečim. Međutim, to bi značilo da je primenjena tehnologija baš specifična pa da ne postoji ekspert koji ima iskustvo sa tim. Ne verujem da je to naš slučaj. Logičnijeg objašnjenja nema od toga da bi podatke publikovali pod istom > licencom i da niko nema korist od nečega što je neažurno ili ne > funkcioniše. Molim vas da ne trošimo energiju na ovaj deo. > Da, to je vrlo važno da bude jasno kao princip. To čaki nije stvar izbora, OSM je objavljen pod takvomlicencom da je to obavezno - podaci moraju da budu otvoreni. NP2111: Još jednom potvrđujem. :) - Drugi deo je serviranje mape korisnicima. Vremenom će za to trebati dosta > resursa u smislu internet protoka jer kada mapa bude dostupna porašče i > interesovanej za nju, počeće ljudi da nju korsite kao podlogu na svojim > sajtovima umesto Google map. Vremenom to će sigurno da postane prilično > veliko. > Keiranje omogućava da se lako napavi cela farma keš servera kojima bi jedini posao bio da rasterete glavni map server od velikog broja upita. Tak keš server može da bude i vrlo jednostavna PHP skripta, kojoj samo terba dovoljno prsotora da može da čuva keširane podatke, tako da to može svako ko ima poterbu i resurse može sam da postavi keš server. NP2111: Farma servera zvuči prilično lepo, ali trenutno nećemo glasno o tome. :) Za početak skromno i malim koracima ka funckionalnom rešenju i omogućavanju mehanizma da neko treći uspostavi keš server na sopstvenim resursima. Budemo li odmah zapucali na farmu, neće da bude dobro. :) U stvari, glavni map sever ne bi ni trebalo da bude izložen direktnim upitima krajnjih korisnika već bi do njega uvek trebalo da se dolazi preko nekog keš servera. NP2111: Definitivno mi treba pojašnjenje termina map server. :) web server (skripta) koji pravi prvi nekeširani servis od podataka iz baze? Može se napraviti da map server pored same mape obezbedi recimo i registar keš servera tako da se omogući da neko ko koristi mapu može da iz registra uzme listu aktivnih keš servera i nasumično uzima podatke sa njih, tako da se opterećenje može dodatno raspršiti. NP2111: Bilo bi mi zanimljivo da čujem više o ovome ako je rešenje iz prakse. Nisam siguran da imam ideju za implementaciju ovoga. NP: Uvod o ovome se nalazi gore. :) Da, definitivno ovo je problem koga se > najviše plašim. Generalno postoji velika potražnja za servisima i taj > konačni bum će da se desi relatvino brzo, a siguran sam da trenutno nemamo > resurse koji mogu to da podnesu. > Ovaj problem ima i OSM. Glavni OSM map server trpi poprilično opterećenje i preporuka je da se on ne koristi već da se uvek ide na neki alternativni izvor. NP2111: Ne treba spominjati glasno u ovoj fazi. Bitno je da smo svesni i da odmah u startu nudimo koncept za rešavanje ovog problema. Podizanje servera koji neće moći da radi nije rešenje koje će biti opravdano i živeti dugo. Međutim, za sad kako nemamo ništa, realizacija kakve takve infrastrukture > bi bila dovoljna za jačanje zajednice i stvaranje održivog koncepta. U > startu treba voditi računa o modlularnosti i skalabilnosti. > Upravo tako. Mi smo u fazi kada terba osmislitii napraviti sistem, a rpboelm opterećenja treba predvideti i rešavati naknadno. Ja sam uveren da će keširanje to sve da reši, pogotovo zato što to može da se uradi veoma fleksibilno i lako se nadograđuje. NP2111: Početni oprez nije na odmet. Ne gubiti iz vida da će početni resursi biti neko vreme ograničeni bez obzira na skalaciju saobraćaja. NP: Ovo je prilično konstruktivan predlog, ali nisam siguran kako bi > funkcionisao u praksi. Ako bi to bilo od 0.5 do 1 TB sličica koje dinamično > menjaju na dnevnom nivou, to bi bila katastrofa. > Iako se izmeen abze mogu raditi u bilo kom trenuktu, rendering ne mora. Rendering može da se radi povremeno upredefinisanim intervalima. Ne mora sve što se ucrtabaš odmah da se vidi namapi, bar ne dok to predstavlja veliko opterećenej sa resursima. S druge strane, mislim da alati za rendering umeju da urade rendering samo onoga što je menjano tako da se ne mora svaki put renderovati cela mapa. NP2111: alati za rendering su za mene prilično uopšten pojam. Nije na odmet definisati tačnu metodologiju koju OSM koristi. Određeno iskustvo i ideje imam. Svodi se na slučaj da keš postoji i da se ažurira u dve varijante: ako je stariji od određenog vremena sam od sebe ili na korisnički zahtev ukoliko je starij od određenog vremena. Na primer da bi obrisali ili prekopirali poptun keš, možda potrošite i više > od jednog dana. :) To su dosta sitni fajlovi večičine od 2KB do 256KB. > Neam ptrebe da se ceo keš odjednom ažurira, kao što sam već rekao, mogu se u keđu ažurirati pojedinačne sličice, i to onako kako dolaze zahtevi za njima. Znači, ono što korisnicima treba to će da se ažurira, ono što im ne treba ili treba ređe, neće se tako često ažurirati, to jest ažuriraće se onda kada nekom zatreba. NP2111: Ok, ovde je jasno da pričamo o drugoj varijatni. :) Ovde verovatno možemo govoriti o skladištenju tih podataka u bazu. Čitanje > je u tom slučaju nešto spronije nego čitanje sa diska. Bitno mi je da > napomenem da sa replikacijom takve baze na druge lokalne nemam iskustvo. > Ukoliko znate nekog ko ima, rad sam da čujem. > Sumnajm da ej to dobra ideja. Stavljanje slika u bazu retko kad sepokazalo kao praktično rešenje. Fajl sistem je sasvim dobra baza za držanje slika a brže i praktičnije od toga i ne može da bude. NP2111:Ovih dana aktivno čitam o ovom problemu. Činjenica je da fajl sistem ima odgovarajuća ograničenja + problem optimalne veličine blokova na disku što je konfigurabilno. Povrh toga, kada postoji sređena baza sa mapom neko može da postavi svoj > rendering server i da namesti drugačiji rendering mape, koji je izgledom > prilagođen nekim specifičnim potrebama (opšta mapa, saobraćajna, > biciklsitička mapa, planinarska mapa, metoeorloška mapa i slično). > > NP: I ovde ste mi pomogli. Svaka nova koju bi voleli da vidite, da kažemo > 0.5 TB više. (Molim da se ne uhvatite fiskno za iznetu vrednost. Možda je > više, možda je manje. Voleo bh ako neko zna tačno ili ima priliku da > testira.) Ako znate nekog sa lokalnim serverima iz neke druge zemlje hajde > da pitamo za najbolju strategiju. > Jeste, ali to nije problem za map server. Ako neko hoće da renderuje drugačiju mapu od one koju glavni map server obezbeđuje, onda neka obezbedi i sve potrebne resurse za to. Na samom glavnom map serveru mogu da se urade neke optimizacije. On će verovatno sadržavati neke podatke koji se mogu prikazivati kompbinovano, slično kao što i sada radi geosrbioja.rs, samo što to ne terba da se radi kao sada na geosrbija.rs da svaki put kada korisnik zatraži određeni prikaz server mora da izrenderuje sliku sa traženim elementima mape. NP2111: Huh, ovde govorimo već o par stvari. Servisi osnovne karte su keširani servisi. Servisi ortofoto snimaka su keširani servisi. Vektorske teme na geosbiji se renderuju direktno iz baze. Ukoliko su podacii inteksirani i njihova geometrija nije prevelika i prekomplikovana ovo je jako brzo rešenje koje štedi dosta prostora na disku. Takođe prednost vektorskih podataka je u tome što omogućavaju više nego slike. Na primer opcijom na klik parcele vraća se određena osobina koju vektorski objekat čuva uz sebe. Takođe moguće je raditi neke druge prostorne upite koji nad slikama nisu mogući. Ovakva osobina na OSM nije neophodna s obzirom da je njena glavna uloga da bude osnovni sloj. ----------------- Kod prikaza kakav je potreban - da se učitavaju male sličice - taj pristup je nepraktičan. Em bi trošio mnogo procesorskog vremena em bi za prilično veliki broj kombnacija morao da se renderuje mnogo raznih setova sličica. Umesto toga, server može da renderuje slojeve, recimo, osnovni sloj mape, sloj administrativnih granica, sloj nečeg trećeg i klijent u prikazu treba da uključi učitavanje potrebnih slojeva koji će da se preklope i daju konačan izgled mape. Tako se izbegava renderovanje mape za sve moguće kombinacije. NP2111: Ok. Ovde sad govorimo o .png fajlovima podeljenim po lejerima uskladištenim u fajl sistemu. Konačna mapa se kreira kombinovanjem više lejera. Prva stvar koju primećujem ok dobili smo mgućnosti za više kombinacija i više mapa, ali ako imamo 10 slojeva x0.5TB nijsmo baš uštedeli resurse. Kešu je nebitno da li to bila sličica sa 5 ili 1 slojem. Naravno ovde može da se govori o težini .png fajla da ukoliko ima više boje njegova veličina je veća, dok ukoliko su to bele sličice je oko 2KB. Takođe ukoliko govorimo o Linux serveru moguće je uspostavljanje simboličkog linka da se svi uniformni tajlovi referišu na jedan (na primer sve bele pločice imaju referencu na jednu). Za Windows servere nije mi poznato da imaju ovu funkcionalnost. Takođe, ako bi se sve ovo oko unos amape podiglo na viši nivo, to bi > sigurno podstaklo mnogo ljudi da se uključe. > > NP: Na dalje bih već bio oprezan, trenutno nemamo ništa ali smo svesni > potencijala. To treba lagano kroz vreme pokazati na mnogo mesta dok ne > poprimi pravi nacionalni značaj. > Editovanje OSM mape ne troši naše resurse tako da uključivanje više ljudi naš serer ne bi ni osetio. NP: Razumem u potpunosti, ali nam treba smirenost jer borba tek predstoji. > Varnice i trzavice na obe strane to neće dovesti na dorbo. :) > Možda sam ja bio preoptimističan da naletim na bolje tako što ću da se > ušetam i kažem e ljudi ajde da uradimo to i to jer šansa posotoji a namera > je dobra. > Naravno ja sam uveren da ovo sve može dobro da se uradi, da se dobije kvalitetan sevis i to tako da rezultati budu dostupni građanima Srbije. NP2111: Čim budemo imali neku estimaciju resursa i konkretnu strategiju kojim koracima idemo i šta očekujemo biće ovo više od verovanja. :) Sa naše strane, osnovni razlog rezervisanog stava je strah da ono što se uradi ne ostane u zatvorenim krugovima. NP2111: Dosadilo mi da pišem. Ljudi otovreno :D Ja bih vas zamolio da razumete da je priča dosta složenija od RGZa. Za > početak, sve bih vas ispravio da to nije RGZ. NIGP je Nacionalna > infrastruktura geoprostornih podataka koja je po svojoj hierarhiji iznad > RGZa u smislu da je RGZ samo jedan član. Ravnopravno ga čine ga i druge > institucije (subjekti NIGPa), a njegovo krovno telo je Savet NIGPa. Istina, > Savetom trenutno predsedava RGZ. I istina, u okviru RGZa postoji odeljenje > za NIGP iz koga centralni deo prče počinje. RGZ je logičan izbor jer > proizvodi najveću količinu prostornih podataka, ima stručni kadar koji zna > da upravlja prostornim podacima i ima mnogo više uloženo u softversku i > hardversku infrastrutkuturu od drugih instituija kojima se trudi da pomogne > kako bi se NIGP razvijao u pravom smeru. Na ovome je akcenat u narednom > periodu. > > Pitanja servisa i otvaranja podataka su i te kako aktuelna a zavise od > mnogo faktora. To nije nešto na šta trenutno bilo ko od nas može da utiče > bilo kakvim komentarom ili raspravom. Predlažem da štedimo energiju i da se > držimo prvog koraka. Delajmo tamo gde ima prostora. > Da, sad je jasnije. Ja sam već video da je na najvišem nivou pokrenut taj proces otvaranja podataka pa sam tako i razumeo ovo tvoje javljanje. Mislim da je OSM kao platforma idealan da se to realizuje. NP2111: Javljanje nema direktnu vezu sa otvaranjem podataka. Otvaranje autoritativnih podataka gde inistitucija kaže podatak je besplatan i ja snosim odgovornost ukoliko nešto nije dobro je priča za sebe. Priča OSM mapa ili nekog sličnog projekta ne vuče ovu vrstu odgovornosti. Dakle podaci sve i sa dobrom gemetrijom teritorijalnih jedinica, zaštićenim područijima i ostalim neće zameniti autoritativne podatke u potpunosti. Dakle OSM mape su u pravom smislu reči otvoreni podaci koji se koriste na sopstvenu odgvornost. Naravno usled snage zajednice oni se mogu koristiti za mnoge primene i smatraju se za pouzdane do nivoa svakodnevne upotrebe. Banalan primer je da OSM ne snosi odgovornost za nepoštovanje podataka za Kosovo. Dakle postojanje Kosova je nečije viđenje za koje niko ne snosi dogovornost ukoliko na osnovu toga nastane neka šteta. Naravno ne govorimo o nekim ekstremnim situacijama gde pritisak bude toliki da na kraju svako mora da snosi odgovornost. Opet da ne bude zabune, otvaranje podataka RGZ ne znači da svi podaci moraju da se otvore. NP2111: Nadam se da je izlaganje iznad pojasnilo koncept i da problematika nije na tom nivou trivijalna. Pedja --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ---------------Прослеђена порука------------------ From: Pedja Supurovic <pe...@supurovic.net> To: talk-rs@openstreetmap.org Cc: Bcc: Date: Mon, 20 Nov 2017 22:54:33 +0100 Subject: Re: [OpenStreetMap Serbia] Talk-rs Digest, Vol 47, Issue 9 On 20.11.2017 18:45, Немања Паунић wrote: Prva napomena da mi je poruka ponovo stigla privatno, ne preko liste. :) > Hmmm... Gmail je izgleda nešto prekonfigurisao liste pa odgovori ne idu na listu nego privatno ;( A drugo, da li mogu dobiti malo pojašnjenje za ovu statistiku? > Da na kom nivou je broj korisnika? (dan, nedelja, mesec) > Koji su ovo korisnici? (Oni koji vektorizuju na mapama ili oni koji > koriste mapu?) > Nema nekih objašnjenja ali meni izgelda na ukupno brojno stanje na navedeni datum. Sledeće vradnosti pretpostavljam da se odnose na same podatke u broju > entiteta. I to tačkastih i linijskih. (Na primer putevi, pešačke i > biciklističke staze) > > Number of nodes:8497716 > > Number of ways:787627 <tel:787627> > > Number of relations:7278 > Da, ovo su osnovne tvi vrste podataka u bazi. Šta je sa ostalim podacima? > Da li postoji negde vrednost koja kaže koliko ovo iznosi bazi? > Ovo sam uspeo da nadjem. Ne znam da li negde postoji neka podrobnija statistika. Da li imamo nekog kog mogu da kontatkiram vezano konfiguraciju servera, > kako bi proverili izvodljivost plana? > Mi ne funkcionišemo kao organizacija u kojoj su podeljeni poslovi. Čak se uglavnom i ne poznajemo. Pokušavam da kontaktiram ljude da vidim ko je aktivan i ko se čime bavi. Pitanje koje nismo podigli do sad je šta je sa susednim zemljama. Ako > budemo imali lokalizovan server, pretpostavljam da bi pored Srbije bar u > nekoj meri trebalo hostovati i okolne zemlje kako bi mapa imapa punu > upotrebljivost oko granice. (Na primer ko putuje u Hrvatsku, glupo bi bilo > da mu je kraj puta na granici sa Srbijom.) > OSM baza sadrži celu planetu. Mi možemo da renderujemo mapu za celu planetu ili samo onaj deo koji prikazuje Srbiju a ostalo da preuzimamo već renderovano sa OSM. Izvinjavam se što sam te zatrpao ovolikim pitanjima. Ako ovo ne guramo sad, > onda biće da se pripremamo za april a do tad može mnogo da se promeni. > Ako nemamo ljude koji znaju, onda je peporuka da testiramo emirijski. > ja se nisma bavio administracijom baze tako da ja lično ne znam mnogo tome, ni kako se postavlja map server ni kako se preuzima baza ni kako se renderuje. Znam o tome samo informativno. Meni je najvećiproblem što su svi ti alati manje-više predviđeni z aLinuks okruženej koe ja ne korsitim aktivno. Da znam više, već bih ja to sve imao urađeno na svom serveru. Očekujem da će se javiti ljudi koji su radili serversku stranu. > 2017-11-20 14:12 GMT+01:00 Predrag Supurovic <pe...@supurovic.net <mailto: > pe...@supurovic.net>>: > > Stats for serbia.osm.pbf > > Date of file:20171031 > > Number of users:5806 > > Number of nodes:8497716 > > Number of ways:787627 <tel:787627> > > Number of relations:7278 > > > Mada mislim da ovo nije obuhvatilo sve podatke. > > Pedja > > _______________________________________________ Talk-rs mailing list Talk-rs@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-rs
_______________________________________________ Talk-rs mailing list Talk-rs@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-rs
