Zdravo Miloše, Ovo je jednina adresa koju sam našao. Mislim da zvanično ne postoji.
Pozdrav, Nemanja On 29 Nov 2017 10:26, <talk-rs-requ...@openstreetmap.org> wrote: 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 48, Issue 1 (Milos Glisovic) ---------------Прослеђена порука------------------ From: Milos Glisovic <milos.k...@gmail.com> To: OpenStreetMap Serbia <talk-rs@openstreetmap.org> Cc: Bcc: Date: Wed, 29 Nov 2017 10:25:05 +0100 Subject: Re: [OpenStreetMap Serbia] Talk-rs Digest, Vol 48, Issue 1 Poštovani, pratim prepisku i podržavam. Da li postoji u Srbiji registrovano udruženje sa ciljem razvoja openstreetmapa? Pozdrav, Miloš Zlatiborski 2017-11-28 11:38 GMT+01:00 Немања Паунић <paunicnema...@gmail.com>: > Dragi svi, > > Da li imamo neke nove informacije? > > Pozdrav, > Nemanja > > 2017-11-21 23:34 GMT+01:00 Немања Паунић <paunicnema...@gmail.com>: > >> 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 > > _______________________________________________ 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