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.
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.
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.)
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.
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.
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.
*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.
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.
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.
- 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Sa naše strane, osnovni razlog rezervisanog stava je strah da ono što se
uradi ne ostane u zatvorenim krugovima.
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.
Opet da ne bude zabune, otvaranje podataka RGZ ne znači da svi podaci
moraju da se otvore.
Pedja
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
Talk-rs mailing list
Talk-rs@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-rs
