Poštovani, na strani o NIGPu http://www.geosrbija.rs/template1.aspx?pageID=100 su objašnjeni osnovni principi funkcionisanja. NIGP bi trebao zvanično da podrži uspostavljanje i rad orgnizacije (udruženja) koja ima za cilj razvoj openstreetmapa. To treba da se nađe u strategiji NIGPa. Treba registrovati udruženje korisnika openstreetmapa.
Miloš 2017-11-29 10:30 GMT+01:00 Немања Паунић <[email protected]>: > 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, <[email protected]> wrote: > > Send Talk-rs mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: OpenStreetMap Serbia <[email protected]> > 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 Немања Паунић <[email protected]>: > >> Dragi svi, >> >> Da li imamo neke nove informacije? >> >> Pozdrav, >> Nemanja >> >> 2017-11-21 23:34 GMT+01:00 Немања Паунић <[email protected]>: >> >>> 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 <[email protected]>: >>> >>>> Send Talk-rs mailing list submissions to >>>> [email protected] >>>> >>>> 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 >>>> [email protected] >>>> >>>> You can reach the person managing the list at >>>> [email protected] >>>> >>>> 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 <[email protected]> >>>> To: [email protected] >>>> 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 <[email protected]> >>> To: [email protected] >>> 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 <[email protected] >>>> <mailto:[email protected]>>: >>>> >>>> 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 >>> [email protected] >>> https://lists.openstreetmap.org/listinfo/talk-rs >>> >>> >>> >> >> _______________________________________________ >> Talk-rs mailing list >> [email protected] >> https://lists.openstreetmap.org/listinfo/talk-rs >> >> > > _______________________________________________ > Talk-rs mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-rs > > > > _______________________________________________ > Talk-rs mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-rs > >
_______________________________________________ Talk-rs mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-rs
