[OpenStreetMap Serbia] Talk-rs Digest, Vol 49, Issue 2

Milos Glisovic milos.krug at gmail.com
Wed Nov 29 13:26:14 UTC 2017 

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 Немања Паунић <paunicnemanja at gmail.com>:

> 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-request at openstreetmap.org> wrote:
>
> Send Talk-rs mailing list submissions to
>         talk-rs at 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-request at openstreetmap.org
>
> You can reach the person managing the list at
>         talk-rs-owner at 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.krug at gmail.com>
> To: OpenStreetMap Serbia <talk-rs at 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 Немања Паунић <paunicnemanja at gmail.com>:
>
>> Dragi svi,
>>
>> Da li imamo neke nove informacije?
>>
>> Pozdrav,
>> Nemanja
>>
>> 2017-11-21 23:34 GMT+01:00 Немања Паунић <paunicnemanja at 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-request at openstreetmap.org>:
>>>
>>>> Send Talk-rs mailing list submissions to
>>>>         talk-rs at 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-request at openstreetmap.org
>>>>
>>>> You can reach the person managing the list at
>>>>         talk-rs-owner at 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 <pedja at supurovic.net>
>>>> To: talk-rs at 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 <pedja at supurovic.net>
>>> To: talk-rs at 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 <pedja at supurovic.net
>>>> <mailto:pedja at 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 at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-rs
>>>
>>>
>>>
>>
>> _______________________________________________
>> Talk-rs mailing list
>> Talk-rs at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-rs
>>
>>
>
> _______________________________________________
> Talk-rs mailing list
> Talk-rs at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-rs
>
>
>
> _______________________________________________
> Talk-rs mailing list
> Talk-rs at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-rs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-rs/attachments/20171129/281ef14f/attachment-0001.html>

More information about the Talk-rs mailing list