geoprostorni repozitorij senzorskih podatakageometrijski oblici poput točke, linije ili poligona 2....

SVEUČILIŠTE U ZAGREBU

FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

DIPLOMSKI RAD br. 926

GEOPROSTORNI REPOZITORIJ SENZORSKIH

PODATAKA

Antonio Piha

Zagreb, lipanj 2015.

2

Zahvala

Svima, koliko god Vas ima.

3

Sadržaj

Zahvala ............................................................................................................................................. 2

Uvod .................................................................................................................................................. 4

1. Geoprostorni repozitoriji senzorskih podataka ................................................................ 5

1.1 Prostorne baze podataka (Spatial databases) ............................................................ 5

1.1.1 Prostorni tipovi podataka .......................................................................................... 6

1.1.2 Prostorno indeksiranje i granične kutije ............................................................... 7

1.1.3 Koordinatni referentni sustav .................................................................................. 8

1.2 Načini prikupljanja podataka ........................................................................................... 9

1.2.1 GeoJSON ..................................................................................................................... 10

1.3 Model objavi-pretplati ...................................................................................................... 11

1.3.1 Pretplate ....................................................................................................................... 12

1.3.2 Objave .......................................................................................................................... 14

1.3.3 Posrednik ..................................................................................................................... 14

2. Implementacija ..................................................................................................................... 16

2.1 REST sučelje ...................................................................................................................... 18

2.1.1 Resursi sučelja........................................................................................................... 20

2.2 Prostorna baza podataka ................................................................................................ 22

2.2.1 PostGIS: ....................................................................................................................... 23

2.3 Poslužitelj ........................................................................................................................... 26

2.3.1 Geotools ...................................................................................................................... 26

2.4 Pretplate i objave .............................................................................................................. 28

2.5 Aplikacija za operacijski sustav Android ................................................................... 36

2.5.1 Osnovne logičke cjeline Android aplikacija ....................................................... 36

2.5.2 Komunikacija između aplikacije i poslužitelja ................................................... 39

2.5.3 Korištenje aplikacije ................................................................................................. 40

3. Analiza performansi sustava ............................................................................................ 41

3.1 Mjerenje ............................................................................................................................... 42

3.2 Plan mjerenja ..................................................................................................................... 45

3.3 Rezultati ............................................................................................................................... 48

Zaključak .......................................................................................................................................... 56

Literatura ....................................................................................................................................... 57

4

Uvod

Informacija je cjelina međusobno povezanih podataka od kojih svaki posjeduje neko

značenje. Kako je Internet dijeljenje informacije, a informacija se sastoji od

podataka, tako su podaci postali ključni u tom procesu dijeljenja. Potrebno ih je

pravilno pohraniti, a istovremeno brzo i precizno dijeliti na Internetu.

Podaci dolaze iz raznih izvora i u raznim formatima, ali pravu vrijednost dobivaju tek

kad ih se obradi u informaciju. Ključno pitanje koje se veže uz podatke je kako ih

spremiti na adekvatan način. Kako podaci ne bi bili izgubljeni spremamo ih u

spremišta, odnosno repozitorije podataka. Osim spremanja, postoje i mnoge

prepreke u rukovanju podacima kao što su količina, raznovrsnost, obrada u

stvarnom vremenu te prostorna lokacija na koju se veže taj podatak.

Ovaj rad se bavi problemom prikupljanja, skladištenja i distribuiranja podataka koji

predstavljaju senzorsko očitanje i koji se vežu na neku lokaciju u prostoru.

Prikupljanje senzorskih očitanja je ostvareno korištenjem tehnologije REST, a

skladištenje pomoću baze podataka PostgreSQL i dodatka za podršku

geoprostornim objektima PostGIS. Dohvaćanje podataka je ostvareno na dva

načina, a to su jednokratni upiti i kontinuirani upiti na principu komunikacijskog

modela objavi-pretplati.

Geoprostorni sustavi koji su ostvareni na principu komunikacijskog modela objavi-

pretplati (GeoPubSub) rješavaju probleme geolokacijske rasprostranjenosti

podataka i dohvaćanja novih podataka te su osnovni dio velikih projekata poput

praćenja izlijevanja ulja u oceanu, globalnog nadzora vremenskih prilika,

nadgledanja lokacija svih taxi vozila unutar prostora koji se prati i slično. Zbog

nužnosti obrade podataka u stvarnom vremenu, kao jedan od osnovnih zahtjeva

javlja se brzina obrade nadolazećih podataka, odnosno što manje kašnjenje pri

njihovoj obradi u ovakvom sustavu. U radu su izmjerene performanse ostvarenog

geoprostornog sustava.

Prvo poglavlje definira osnovne pojmove geoprostornih repozitorija te daje osvrt na

arhitekturu sustava i opisuje način rješavanja osnovnih implementacijskih problema.

Drugo poglavlje se bavi komponentama sustava te detaljima njihove

implementacije. Treće poglavlje daje uvid u postavljanje sustava i prikazuje rezultate

mjerenja njegovih performansi.

5

1. Geoprostorni repozitoriji senzorskih podataka

Senzor je uređaj koji pretvara energiju iz jednog oblika u drugi na način da osjeti i

detektira karakteristike svoje okoline u obliku kvantitativnih promjena te pruži

odgovarajuću mjeru očitane promjene [18]. Primjer senzora je živin termometar

zato što pretvara toplinu u širenje volumena žive čija se promjena očituje na

kalibriranoj staklenoj cijevi u kojoj se ona nalazi. Senzor je dakle fizički uređaj što

znači da imaju svoju lokaciju na kojoj detektira promjene. Uz izmjerenu vrijednost,

lokacija je također bitan podatak za bilo koju vrstu mjerenja zato što očitanje s

nepoznate lokacije ne znači puno. Stoga je potrebno uz očitanje pohraniti i lokaciju

senzora.

Svaki senzor također može davati informacije u mnogo različitih formata, međutim

pri razvoju ovog sustava se koristio standardizirani format za prikupljanje podataka

GeoJSON. Podaci sa senzora su korisne informacije koje imaju raznoliku primjenu,

a kako bi se sva mjerenja sačuvala za buduće analize, podatke je potrebno negdje

pohraniti. Senzorske podatke možemo spremati, obraditi i dijeliti, a to je upravo

zadaća repozitorija podataka koji je ostvaren u praktičnom djelu ovog rada.

1.1 Prostorne baze podataka (Spatial databases)

Prostorna baza podataka je slična običnoj bazi podataka, s razlikom da tretira

prostorni objekt kao i svaki drugi objekt, tj. sprema ga i manipulira njime kao i

običnim objektom.

Prostorni podaci su povezani s bazom podataka kroz tri elementa:

1. Prostorni tipovi podataka – odnose se na prostorni oblik kojeg predstavljaju

geometrijski oblici poput točke, linije ili poligona

2. Višedimenzionalno prostorno indeksiranje – služi za efikasniju obradu

prostornih operacija

3. Prostorne funkcije – definirane u jeziku SQL-, služe za postavljanje upita nad

prostornim svojstvima i odnosima

6

1.1.1 Prostorni tipovi podataka

Klasična baza podataka prepoznaje riječi (tip String), brojeve (tip Number), datume

(tip Date) itd. Prostorna baza podataka dodaje nove tipove koji se nazivaju prostorni

tipovi podataka koji posjeduju geoprostorne značajke. Glavna zadaća im je

apstrakcija i enkapsulacija prostornih objekata i elemenata od kojih su prostorni

objekti sačinjeni, kao na primjer granica i dimenzija objekata. U većini slučajeva ih

možemo shvatiti kao geometrijske oblike i modele.

Postoji više vrsta tipova prostornih objekata. Najčešće korišteni su:

Geometry – općenita klasa iz koje možemo stvoriti neki prostorni objekt

Point – predstavlja točku u prostoru

LineString – linija sačinjena od više točaka koja ima različit početak i kraj

Polygon – predstavlja poligon koji je određen s više točaka i zatvara neku

površinu, može imati praznine

Slika 1. sadrži grafički prikaz najčešće korištenih geometrija, točke, linije i poligona.

Slika 1. Primjer geoprostornih objekata

7

Također postoji i hijerarhijska među tim tipovima, tako npr. geometriju nasljeđuje

točka i površina, a dalje površinu nasljeđuje poligon.

Geometrije ćemo obrađivati pomoću posebnog formata za označavanje i

prezentaciju geoprostornih objekata koji se naziva „dobro poznati tekst“ (Well-

Known-Text, WKT). On se koristi i za transformaciju i prijenos geometrija između

geoprostornih sustava. WKT može prikazati 18 različitih vrsta geoprostornih

objekata poput geometrije, točke, linije, poligona, površine, geometrijske kolekcije i

sl.

Definira se imenom vrste geoprostornog objekta i koordinatama tog objekta u

prostoru. Koordinate mogu biti dvodimenzionalne, trodimenzionalne ili

četverodimenzionalne. Osim toga, moguće je korištenjem oznake EMPTY opisati i

prazni geoprostorni objekt koji ne sadrži koordinate.

Tablica 1. WKT zapis geoprostornih oblika

Geometrija WKT

Točka POINT (30 10)

Linija LINESTRING (30 10, 10 30, 40 40, 10 20)

Poligon POLYGON (35 10, 45 45, 15 40, 10 20, 35 10)

U ovom formatu apscisa može predstavljati zemljopisnu dužinu, a ordinata

zemljopisnu širinu.

1.1.2 Prostorno indeksiranje i granične kutije

U običnim bazama podataka postoje metode za pristupanje podataka koje su

poznate pod nativom indeksi, a služe za brzo dohvaćanje podataka. Standardni

tipovi kao brojevi, riječi i datumi se najčešće indeksiraju pomoću indeksa u obliku B-

stabla. SRID je kratica od „Spatial Reference IDentifier“ koji definira geoprostornu

oznaku i parametre korištenog zemljopisnog koordinatnog sustava te njegove

projekcije odnosno prostorne informacije objedinjuje kao jedan jedinstveni broj.

Koristi se pri jednoznačnom razlučivanju objekata smještenih u projiciranim,

neprojiciranim i lokalnim prostornim koordinatnim sustavima.

8

1.1.3 Koordinatni referentni sustav

Geometrija je matematički oblik definiran skupom koordinata čija se projekcija

dobiva izračunima nad tim koordinatama. Usporedimo geometriju s nekim brojem,

npr. 100, taj broj sam za sebe nema značenje, bar ne značenje koje nam je od

koristi, postavimo pitanje npr. 100 čega? Ono što samom broju nedostaje da bi imao

značenje je mjerna jedinica čime oni skupa predstavljaju neki podatak, npr. 100 ljudi.

Geometrija kao skup točaka ne nudi točno značenje tim individualnim točkama, a

značenje im daje mjerna jedinica koja se naziva lokacija. Lokacija daje značenje

geometriji, a struktura koja omogućava definiranje lokacije naziva se koordinatni

referentni sustav.

Slika 2. Kartezijev koordinatni sustav [19] Slika 3. Polarni koordinatni sustav [20]

Koordinatni referentni sustav pruža razne podatke vezane za određivanje lokacije.

Definira osi i mjerne jedinice koje koristi, npr. zemljopisnu dužinu u stupnjevima, a

zemljopisnu širinu mjeri u stupnjevima uz ekvator kao ishodište. Također osi mogu

biti u metrima za lakše računanje udaljenosti, površina i slično.

Najpoznatiji koordinatni sustavi za prikaz točaka su Kartezijev i polarni koordinatni

sustav koji su prikazani na slikama 2 i 3. Sferni koordinatni sustav opisuje svaku

točku pomoću dva parametra, a to su udaljenost točke od ishodišta i kut za kojeg je

točka odmaknuta od osi. U ostvarenom sustavu koristit ćemo Kartezijev koordinatni

sustav kod kojeg apscisa predstavlja zemljopisnu dužinu, a ordinata predstavlja

zemljopisnu širinu. Ishodište tog sustava je sjecište ekvatora i nultog meridijana, a

9

sustav će biti prikazan kao ravnina umjesto zakrivljenog prostora kao što je Zemlja

u stvarnosti.

1.2 Načini prikupljanja podataka

Geoprostorni informacijski sustavi (Geographic Information Systems, GIS) koriste

različite formate datoteka za razmjenu podataka. Razvoj tih sustava kroz povijest je

rezultirao velikim brojem različitih zapisa u kojima se geoprostorni podaci

predstavljaju. Danas postoje standardni formati poput datoteka Shapefile i

Geographic Data File.

Shapefile je jednostavan format koji zapisuje objekte u obliku vektorskih podataka

sačinjenog od točaka, linija i poligona, gdje svaki od njih može imati atribute za

dodatni opis zapisanog objekata. Koordinate spremljene u tom formatu

pretpostavljaju korištenje Kartezijevog koordinatnog sustava, a redoslijed

koordinata dvodimenzionalnog prostora je apscisa pa ordinata. Bitno je spomenuti

da se zapis ne sastoji od jedne već od tri različite datoteke. Iako se sama geometrija

nalazi u jednoj datoteci naziva shapefile (s ekstenzijom .shp), za dijeljenje te

geometrije su potrebne druge dvije datoteke koje sadržavaju njen prostorni indeks i

atribute koji je dodatno opisuju. Postoje gotovi alati za učitavanje geoprostornih

objekata iz tog formata u bazu podataka, npr. za GIS OSM (OpenStreetMap) je

razvijen alat osm2pgsql kojim se podatke može direktno prebaciti iz Shapefile-a u

bazu podataka PostgreSQL, ukoliko ona ima instaliran dodatak PostGIS.

Sučelje REST (REpresentational State Transfer) je arhitekturni stil razmjene

podataka za raspodijeljene umrežene sustave. Temelji se na konceptu identifikacije

resursa pomoću „univerzalnog identifikatora resursa“ (Universal Resource Identifier,

URI). Svaki resurs može biti postavljen, dohvaćen ili modificiran kroz standardno

sučelje koje implementira operacije „Stvori-Pročitaj-Osvježi-Izbriši“ (Create-Read-

Update-Delete, CRUD)) te se prenosi nekim standardnim protokolom, npr. HTTP-

om, a sama informacija predstavlja reprezentaciju tog resursa. Repozitorij razvijen

u praktičnom dijelu ovog rada prikuplja podatke upravo kroz takvo sučelje. Podaci

odnosno senzorska očitanja pristižu od raznih senzora koji se nalaze na različitim

lokacijama u prostoru.

10

1.2.1 GeoJSON

Format GeoJSON sintaksom odgovara formatu JSON te na njegovu logiku dodaje

semantiku za razne geografske podatkovne strukture. On može predstavljati

geometriju, oblik ili kolekciju oblika. Podržava sljedeće geometrijske tipove:

Točka (Point)

Linija (LineString)

Poligon (Polygon)

Više točaka (MultiPoint)

Više linija (MultiLineString)

Više poligona(MultiPolygon)

Kolekcija geometrija (GeometryCollection).

U tom formatu, oblici sadrže geometrijski oblik, dodatna svojstva i kolekciju oblika

koji su sastavljeni u listu oblika. Kao i klasični format JSON, tako je i GeoJSON

podatkovna struktura koja predstavlja objekt koji se sastoji od više parametara

(parova ključ-vrijednost) koji su njegovi sastavni dijelovi. GeoJSON se uvijek sastoji

samo od jednog objekta koji može biti geometrijski tip, oblik ili kolekcija oblika te

poštuje sljedeća pravila:

Ima bilo koji broj parova ključ-vrijednost odnosno parametara

Jedan od parametara odnosno ključeva mora biti type koji definira tip koji

objekt predstavlja

Vrijednost pod ključem type mora biti jedna od sljedećih: Point,

MultiPoint, LineString, MultiLineString, Polygon,

MultiPolygon, GeometryCollection, Feature, ili

FeatureCollection

Sadržava opcionalni parametar pod ključem crs kojim se definira

koordinatni referentni sustav (Coordinate Reference System, CRS)

Sadržava parametar bbox pod čijom se vrijednošću definira granična kutija

objekta

Bilo koji geometrijski oblik osim kolekcije geometrija GeometryCollection

mora sadržavati parametar pod ključem coordinates kojim se definiraju

11

njegove koordinate odnosno pozicija objekta, a vrijednost je niz brojeva koji

ima najmanje dva elementa

Lokacija x,y,z se određuje na temelju koordinata objekta i na temelju

koordinatnog referentnog sustava. Redom x,y,z predstavlja istok, sjever i

visinu za projicirane koordinatne referentne sustave, dok u geografskim

koordinatnim referentnim sustavima predstavljaju redom dužinu, širinu i visinu.

Oblici u formatu GeoJSON su tipa Feature i poštuju sljedeća načela:

Obavezan parametar s ključem geometry čija vrijednost predstavlja

geometrijski objekt ili vrijednost null

Obavezan parametar s ključem properties koji pod svojom vrijednošću

sprema JSON objekt koji sadrži dodatna svojstva tog objekta

1.3 Model objavi-pretplati

U sustavima, koji imaju zadaću dostavljanja sadržaja velikom broju korisnika u

stvarnom vremenu na temelju nekog novonastalog podatka, se često koristi neki

oblik komunikacijskog modela objavi-pretplati. Ovaj model definira dvije vrste

entiteta koji sudjeluju u razmjeni podataka. S jedne strane imamo pretplatnike

(subscribers) koji definiraju svoju pretplatu na temelju koje će primati podatke koji ih

interesiraju, dok s druge strane imamo objavljivače (publishers) koji posjeduju neki

podatak, objave ga u sustav te time stvore novu objavu koja će se dalje proslijediti

potencijalnim pretplatnicima.

Takav sustav također predstavlja određenu anonimnost u tome što subjekti

međusobno ne komuniciraju izravno, već preko posrednika. Sustav koji je razvijen

u ovom radu, također nudi mogućnost jednokratnih upita, koji su slični pretplati, ali

dok je pretplata cijelo vrijeme aktivna, ovi upiti ne rtaju, već vrijede samo dok se ne

izvrše. Model komunikacije objavi-pretplati se razlikuje od klasičnih upita po obliku

komunikacije između korisnika sustava. Kod jednokratnih upita korisnik kojega

zanimaju podaci će postaviti upit posredniku te se nadati da će eventualno dobiti

zadovoljavajući odgovor. Takav korisnik nema informaciju o tome postoji li uopće

odgovarajuće očitanje na posredniku koji odgovara njegovom upitu. U ovom

modelu smjer komunikacije je usmjeren od klijenta prema posredniku. Kod modela

12

objavi-pretplati smjer komunikacije je obrnut, dakle posrednik će kontaktirati

pretplatnika kada bude imao informaciju koja odgovara njegovoj pretplati.

Komunikacija se neće ni ostvariti ukoliko ne bude podataka koji bi zadovoljili

pretplatu tog pretplatnika. U suprotnom slučaju posrednik će proslijediti

pretplatnikupodatak koji odgovara pretplati . Takvim modelom se također smanjuje

opterećenje na posredniku i mrežno opterećenje jer se izbjegavaju periodični upiti

na poslužitelj od kojih će neki vratiti traženi resurs dok će većina odgovora samo

dati informaciju da poslužitelj trenutno ne posjeduje odgovarajući resurs za taj upit.

1.3.1 Pretplate

Pretplatnik je definiran s jednom ili više pretplata. Pretplata se sastoji od raznih

uvjeta ovisno o području interesa pretplatnika. Svakom pretplatom pretplatnik, kao

krajnji korisnik sustava, unaprijed definira kakve podatke točno želi primati. Dakle

proces pretplate se temelji na određivanju filtera te dojave te pretplate posredniku

koji je zadužen za objave. Filter se može definirati i kao prazan, što bi značilo da će

pretplatnik primiti svaku vrstu novog očitanja iako to baš i nema nekog smisla.

Posrednik zato omogućuje pretplatnicima definiranje filtera na temelju određenih

metapodataka koji su njemu poznati. Na temelju definiranog resursa objave

možemo logičnim zaključivanjem definirati pretplatu kao resurs koji sadrži:

Identifikator pretplatnika

Geoprostornu lokaciju – predstavlja poligon ili neku drugu geometriju koja

definira lokaciju od interesa (objave će se prostorno filtrirati po njoj)

Vrstu očitanja

Mjernu jedinicu očitanja

Donji interval vrijednosti – očitanja sa senzora moraju biti veća ili jednaka

ovoj vrijednosti da bi zadovoljili pretplati

Gornji interval vrijednosti - očitanja sa senzora moraju biti manja ili jednaka


Ovakvim načinom filtriranja se lako može doći do problema da je očitanje zadano u

jednoj mjernoj jedinici, a pretplata u drugoj.

13

Kod objave senzorskih podataka često se radi o nekoj jednostavnoj vrsti očitanja,

npr. temperaturi koja se definira u Celzijusima, a pretplata može biti definirana u

drugoj mjernoj jedinici npr. Kelvinima. Sustav će omogućiti pretplatniku definiranje

pretvorbe iz jedne mjerne jedinice u drugu pomoću formule koja se definira prije

aktiviranja pretplate. Korisnicima razvijenog sustava su na raspolaganju informacije

o svim vrstama očitanja i mjernim jedinicama tako da oni mogu provjeriti kakvim

sve vrstama mjernih jedinica repozitorij raspolaže i trebaju li definirati pretvorbenu

formulu iz jedne mjerne jedinice u drugu. Sustav ignorira pretplate koje su efinirane

s nekom nepostojećom vrstom mjerne jedinice.

Jednokratni upiti se sastoja od sljedećih podataka:

Geoprostorna lokacija – predstavlja poligon ili neku drugu geometriju koja

definira lokaciju od interesa (objave će se prostorno filtrirati po njoj)

Vrsta očitanja

Mjerna jedinica očitanja

Donji interval vrijednosti – očitanja sa senzora moraju biti veća ili jednaka


Gornji interval vrijednosti – očitanja sa senzora moraju biti manja ili jednaka


Donji interval vremenskog očitanja – očitanja koja su se dogodila nakon ovog

definiranog datuma i vremena

Gornji interval vremenskog očitanja – očitanja koja su se dogodila prije ovog

definiranog datuma i vremena

U jednokratnom upitu je potrebno definirati vremensko razdoblje unutar kojeg nas

zanimaju očitanja, jer ako tražimo očitanja koja su se dogodila upravo u vrijeme

upita, postoji velika šansa da ih neće biti. Stoga je za dobivanje liste očitanja

potrebno definirati vremenski interval. Model objavi-pretplati, kao i ostvareni sustav,

nudi svojim korisnicima mogućnost odustajanja od pretplate.

14

1.3.2 Objave

U ostvarenom sustavu objavljivači novih podataka su senzori pa je stoga objava

definirana kao novonastalo očitanje.

Svako očitanje se sastoji od nekoliko ključnih podataka vezanih za taj senzor:

Geoprostorna lokacija – predstavlja točku ili poligon ili neku drugu geometriju

koja tom očitanju daje prostorno značenje

Vrsta senzora

Vrsta mjerenja – koja je vezana za vrstu senzora

Vrijeme u kojem se očitanje dogodilo

Vrijednost očitanja

Mjerna jedinica za tu vrijednost

Objave u ostvarenom sustavu imaju dva zadatka. Prvi zadatak je objava kao slanje

podataka sa senzora u ostvareni repozitorij podataka. Drugi zadatak je objava kao

slanje podataka iz repozitorija do pretplatnika.

Prvi zadatak je jednostavniji i ostvariv je spajanjem senzora na Internet te slanjem

očitanja preko HTTP-a ostvarenom repozitoriju kojim se stvara novi resurs i

pohranjuje se očitanje u bazu podataka. Taj dio se obavlja preko prethodno

definiranog sučelja REST. Postoji lančana poveznica između prvog i drugog dijela,

kada se uspješno izvrši prvi zadatak, odmah nakon repozitorij počne izvršavati drugi

zadatak. Drugi zadatak je zapravo zadaća posrednika koji će distribuirati

prikupljene podatke pretplatnicima.

1.3.3 Posrednik

Posrednik je u arhitekturnom smislu kombinacija poslužitelja, baze podataka i

distributera podataka.

Posrednik na temelju objavljenog očitanja pronalazi sve pretplate čije kriterije objava

zadovoljava.

Bitno je objasniti redoslijed kojim se pronalaze odgovarajuće objave i pretplate. Kod

jednokratnog upita se (posebne vrste pretplate koja se ne pohranjuje u bazu) na

temelju njegovih kriterija pronalaze sve odgovarajuće objave koje ih zadovoljavaju.

15

Kod kontinuiranih upita (pretplata pohranjenih u bazu podataka), sena temelju

podataka iz pristigle objave pronalaze sve odgovarajuće pretplate na način da se

ispituje odgovaranje objave svakoj pretplati. Ukoliko objava zadovoljava kriterije

neke pretplate tada se ona dodaje u listu pretplata čijim pretplatnivima će biti

poslana pristigla objava.

Kao što je već spomenuto, objave i pretplate definiraju vrstu mjerenja i mjernu

jedinicu očitanja. Dakle možemo imati objavu čija je vrsta mjerenja postavljena tako

da je jednaka nekoj pretplati ili da su one definirane u dvije različite mjerne jedinice.

Npr. objava je definirana vrstom mjerenja „temperatura“ i mjernom jedinicom „C“

(Celziji, dok je neka pretplata definirana također vrstom mjerenja „temperatura“, ali

u drugoj mjernoj jedinici „K“ (Kelvini ). Taj problem se riješava definiranjem formule

konverzije iz jedne mjerne jedinice u drugu. Nova formula je definirana sa sljedećim

karakteristikama:

Vrsta mjerenja – formula vrijedi samo za tu vrstu mjerenja

Iz mjerne jedinice – definiramo iz koje mjerne jedinice će se vršiti pretvorba

U mjernu jedinicu – definiramo mjernu jedinicu u koju želimo pretvoriti

vrijednost

Formula – pretvorba će se izračunavati na temelju ove formule

U ovom primjeru, definirat ćemo pretvorbu za vrstu mjerenja „temperatura“, iz

mjerne jedinice „C“, u mjernu jedinicu „K“, pomoću formule (1).

K = C + 273.15 (1)

Ostvareni sustav pretvara vrijednost iz dobivenog očitanja te na temelju te

pretvorene vrijednosti uspoređuje objavu i pretplatu. Pritom ispituje granice intervala

vrijednosti pretplate, a kako su one zadane u mjernoj jedinici pretplate, potrebno je

vrijednost objave pretvoriti u mjernu jedinicu pretplate i tada provjeriti jeli ona u

traženom intervalu.

16

2. Implementacija

Poslužitelj GlassFish omogućava izradu i razvijanje te puštanje u rad aplikacija

razvijenih za Javinu platformu Enterprise . Za razvoj ostvarenog sustava korišten

je poslužitelj GlassFish 4.1 koji između ostalog nudi sljedeće funkcionalnosti:

Laganu i proširivu jezgru temeljenu na poznatim standardima

Kontejner za web aplikacije

Jednostavno web sučelje za konfiguraciju, kroz koje smo podesili bazu

podataka

Posrednik između sučelja REST i baze podataka PostgreSQL je zapravo aplikacija

napisana u Javi koja je pokrenuta na poslužitelju GlassFish u obliku arhive WAR

(Web application Archive) koji se često koristi za distribuciju Javinih web aplikacija.

Slika 4. prikazuje elemente ostvarenog repozitorija.

Slika 4. Komponente repozitorija

17

Poslužitelj i baza podataka se nalaze u istoj mreži te su izravno povezani, a

pokrenuti su kao instance na operacijskom sustavu Debian GNU/Linux 7.8

(wheezy). Instanca poslužitelja GlassFish ima javno dostupnu URL adresu na

lokaciji: https://gprsp.no-ip.org:8080/ , fizička lokacija je računalo unutar FER-ove

mreže. Poslužitelj GlassFish dolazi s integriranim administracijskim web sučeljem

koje se nalazi na istoj adresi, ali na portu 4848, za kojeg je potrebno imati

administratorskog korisnika:

Tablica 2. Podaci za administratorski pristup poslužitelju

Korisničko ime admin

Lozinka repozitorij

Slika 5. Administracijsko sučelje poslužitelja i postavke veze na bazu podataka

Kroz administracijsko sučelje podešena je veza na bazu podataka koju koristimo

unutar same aplikacije pokrenute na poslužitelju, što je prikazano na Slici 5.

Aplikaciju je potrebno postaviti također kroz administratorsko sučelje. Ostvarena

aplikacija za razvoj zapakirana u Java WAR format datoteke koju je vrlo jednostavno

postaviti kroz isto sučelje.

https://gprsp.no-ip.org:8080/

18

2.1 REST sučelje

U Javi postoji JAX-RS koji je zapravo API na razini programskog jezika koji olakšava

razvoj aplikacija u REST modelu, a koristi anotacije nad klasama i metodama te

olakšava razvoj i spremanje konfiguracije i implementacije u jednu datoteku.

Anotacijama se definiraju odgovornosti za pojedine klase i njihove metode. Njima

se određuje koja je metoda zadužena za obradu pojedinog URI-a, koji tip resursa

taj URI podržava, a također je moguće detaljnije podešavati resurs, npr. vremenski

period trajanja resursa i kontrolu pohrane u privremenu memoriju (Expire i Cache

Control). Anotacije koje definiraju vrstu zahtjeva koje metoda podržava odgovaraju

istoimenim metodama protokola HTTP, npr. anotacija @DELETE odgovara metodi

DELETE protokola HTTP, a detaljniji opis nalazi se u tablici 3.

Tablica 3. Java REST anotacije za metode i klase

Anotacija Opis

@Path Predstavlja relativan URI koji je putanja do lokacije gdje su Java

klase biti posluživane. Primjer: /rest . Također podržava ugradnju

varijabli. Primjer s varijablom: /rest/{akcija}

@GET Označava vrstu zahtjeva koju metoda podržava i odgovara

istoimenoj HTTP metodi GET.

@POST Označava podršku za procesiranje HTTP POST zahtjeva.

@PathParam Definira tip parametra koji se izvuče iz zahtjeva i može se koristiti

unutar resursa odnosno klase. Ime parametra je definirano

@Path anotacijom te se izvlači iz URI-a zahtjeva.

@Consumes Specificira MIME tip koji opisuje resurs poslan s klijenta.

@Produces Specificira MIME tip resursa koji metoda generira i šalje na

natrag klijentu. Primjer : „application/json“

Svaki senzor postavlja resurs odnosno očitanje kroz sučelje REST uPOST za

kreiranje resursa. Svaki zahtjev koji pristigne na sučelje prvo prolazi kroz glavnu

klasu za obradu zahtjeva koja se naziva „korijen klasa resursa“ (Root resource

class). Ta je klasa u Javi zapravo običan POJO (Plain Old Java Object), ali da bi ta

klasa bila korijen mora zadovoljavati ove uvjete:

nad klasom postoji anotacija @Path

19

ima bar jednu metodu koju opisuje anotacija @Path

ima bar jednu metodu koju opisuje oznaka za vrstu zahtjeva koju podržava,

a oznake su @GET, @PUT, @POST, @DELETE

Ono što razlikuje resurs na sučelju je parametar sadržan u zahtjevu. Tim

parametrom dolazimo do traženog resursa, a postoji više vrsta samih parametara:

Query –parametri se nalaze u samom URI-u zahtjeva i to u „query“ dijelu koji

se definira tako da se na URI doda „?“ nakon kojeg slijede parametri u obliku

„ključ=vrijednost“ koji su odvojeni znakom „&“ što možemo interpretirati kao

dodatne postavke upita. Izvlači se pomoću anotacije @QueryParam. Primjer:

/rest?id=123, u ovom slučaju parametar je „id“ s vrijednosti 123.

URI dio – također se nalaze u URI-u, ali ovaj put su zapakirani u URI i

potrebno ih je izvući iz njega pomoću anotacije @PathParam. Primjer:

/rest/123 , u ovom slučaju je s anotacijom definirano da je traženi parametar

„id“ s vrijednošću iz URI-a koja je 123.

Form – izvlačenje parametara iz zahtjeva koji je MIME tipa

application/x-www-form-urlencoded

Cookie – izvlačenje parametara iz kolačića definiranih u HTTP zaglavljima

Ostvareni sustav nema definirane zahtjeve za prijavom korisnika, registracijom i

slično, stoga nam načini Cookie i Form ne odgovaraju. Parametri Query i URI su

vrlo slični s razlikom da prvi ne moraju biti svi definirani i ne moraju poštivati

redoslijed kojim ih definiramo dok drugimoraju točno zadovoljiti redoslijed te svaki

parametar mora biti definiran ako želimo definirati sljedećeg. Npr. kod URI

parametara, ako je URI definiran kao /rest/{param1}/{param2} tada moramo

konstruirati URI tako da prvo postavimo param1 i koji mora biti postavljen ako

želimo definirati param2.

Definirani su resursi koji logički odgovaraju zahtjevima implementacije, a također su

sukladno tome omogućene samo pojedine metode vrsta zahtjeva koje pojedini

resurs može obraditi na određenom URI-u.

Baza za sučelje je klasa Application iz paketa GlassFish Jersey koja služi kao klasa

ispred svih drugih pomoću koje se učitaju druge klase sučelja.

20

Svaka objava i pretplata koju aplikacija šalje mora biti u formatu GeoJSON i to u

obliku objekta FeatureCollection koji se sastoji od liste objekata Feature. Primjer

GeoJSON formata prikazan je na slici 6.Izabran je taj format zbog mogućnosti

dodavanja više pretplata i objava u jednom zahtjevu. Svaki objekt tipa Feature se

sastoji od geometrije i dodatnih svojstava.

Slika 6. GeoJSON struktura zapisa podataka

2.1.1 Resursi sučelja

Svaki resurs ima svoj URI, a URI odgovara URL-ovima koji su javno dostupni.

Implementirani su unutar klase Rest:

@Path("/api")

public class Rest

Svaki URI je jedna metoda te klase, a one su opisane u nastavku.

21

Za dohvaćanje, u JSON obliku, popisa svih vrsta senzora i odgovarajućih mjernih

jedinica koje pripadaju toj vrsti senzora, a postoje u repozitoriju se koristi sljedeća

metoda

@GET

@Path("/sensortypes")

@Produces(MediaType.APPLICATION_JSON)

public String sensortypes()

Za jednokratne upite se koristi sljedeća metoda:

@POST

@Path("/singlequery")

@Consumes(MediaType.APPLICATION_JSON)


public String singleQuery(String geoJSON)

Pretplaćivanje na repozitorij se ostvaruje sljedećom metodom:

@POST

@Path("/subscribe")



public String subscribe(String geoJSON)

Dohvaćanje svih pretplata za pretplatnika čiji se ID prosljeđuje u samom URI-u se

obavlja sljedećom metodom:

@GET

@Path("/subscriptions/{identifikator_pretplatnika}")


public String subscriptions(@PathParam("identifikator_pretplatnika")

String subscriptionId)

Brisanje svih pretplata pretplatnika pod ID-jem koji se prosljeđuje kao parametar

URL-a se ostvaruje sljedećom metodom:

@DELETE

@Path("/unsubscribe/{identifikator_pretplatnika}")


public String unsubscribe(@PathParam("identifikator_pretplatnika") String

subscriptionId)

Nova senzorska očitanja se objavljuje sljedećom metodom

22

@POST

@Path("/publish")



public String publish(String geoJSON)

Nova formula pretvorbe iz jedne mjerne jedinice u drugu se stvara sljedećom

metodom:

@POST

@Path("/conversion")



public String conversion(String json)

Postojeće formule pretvorbe se dohvaćaju sljedećom metodom:

@GET

@Path("/conversions")


public String conversions()

2.2 Prostorna baza podataka

Baza podataka korištena u ovom sustavu je PostgreSQL. Ona pripada grupi

ORDBMS odnosno objektno relacijski sustav upravljanja podacima te implementira

većinu bitnih SQL standarda poput ACID-a, transakcija i otporna je na probleme

zaključavanja, a sve u svrhu sigurnog spremanja i preciznog posluživanja podataka.

Konfiguracijski podaci za spajanje na bazu podešeni su kroz poslužitelj, a korištene

su klase knjižnice GeoTools iz razloga što se svi objekti moraju pretvoriti u pogodne

za spremanje u bazu, a to je podržano ovom kjižnicom.

public class Database {

private final static String DB_TYPE = "postgis";

private final static String DB_NAME = "GeospatialPostgis";

private DataStore dataStore;

protected void connectSpatial(String typeName) throws Exception {

Map<String, Object> map = new HashMap<String, Object>();

map.put( "dbtype", DB_TYPE);

map.put( "jndiReferenceName", DB_NAME);

DataStore dataStore = DataStoreFinder.getDataStore(map);

23

Objekt dataStore instanciran iz klase DataStore sadrži instancu baze podataka.

2.2.1 PostGIS:

PostGIS je ekstenzija za bazu podataka PostgreSQL koja je pretvara iz klasične u

prostornu. Podržava sve funkcije i objekte definirane u specifikaciji OpenGIS

(„Simple Features for SQL“) te je otvorenog koda.

Postoji još sličnih ekstenzija kao što su „Oracle Spatial“, „DB2 Spatial“ i „SQL Server

Spatial“, ali za druge baze podataka, dok je PostGIS zapravo „PostgreSQL Spatial“

odnosno odgovara samo bazi PostgreSQL.

Kao i sve druge ekstenzije tog tipa on proširuje bazu na sljedeći način:

dodaje pojam geometrijskog tipa podataka „geometry“ među klasične

tipove kao što su „varchar“, „integer“, „date“ i slično.

Dodaje funkcije koje primaju geometrijski tip podataka „geometry“ i vraćaju

korisne informacije vezane uz taj objekt, primjeri funkcija:

ST_Distance(geometry, geometry), ST_Area(geometry) i

ST_Intersects(geometry, geometry)

Koristi se u klasičnim SQL upitima kao i druge funkcije koje su podržane u SQL-u.

Implementira razne funkcije koje omogućuju stvaranje i rukovanje geoprostornim

podacima. Neke od PostGIS funkcija nalaze se u tablici 4.

Tablica 4. Opis PostGIS funkcija

Funkcija Opis

ST_MakePoint (

Širina,

Dužina

)

Kreira i vraća novu točku. Prima

koordinate čiji je redoslijed bitan, širina

pa dužina.

ST_GeomFromText(

WellKnownText,

Srid

)

Kreira i vraća novu geometriju koju

stvara iz parametra koji je WKT string i

srid-a.

24

ST_AsText(

Geometry

)

Vraća geometriju danu kao parametar

u tekst formatu koji je čovjeku lako

čitljiv.

ST_AsGeoJSON(

Geometry

)

Vraća geometriju danu kao parametar

u GeoJSON obliku.

ST_Distance(

Geometry,

Geometry

)

Vraća udaljenost između dvije

geometrije predane kao parametri, u

jedinici određenoj referentnim

koordinatnim sustavom.

ST_Intersects(

Geometry,

Geometry

)

Vratit će istinu (true) ako dvije

geometrije predane kao parametri

imaju presjek odnosno presijecaju se,

inače je laž (false).

Za ispravan rad aplikacije, odnosno spremanje i dohvaćanje podataka, je bilo nužno

u bazi stvoriti nekoliko tablica. Tablice nisu normalizirane jer je to izvan okvira ovog

zadatka. Tablice smo stvorili pomoću alata PgAdminIII koji omogućava upravljanje

bazom podataka odnosno stvaranje, modifikaciju i brisanje tablica. Ime baze

podataka PostgreSQL je „GeospatialRepositorySensorData“, a sve tablice također

imaju simboličko ime koje opisuju čemu služe.

Tablica „senzorska_ocitanja“ koristi se za pohranu prikupljenih senzorskih očitanja

odnosno objava sa senzora. Svaka objava koja sadrži sve informacije o jednom

senzorskom očitanju je pohranjena u tablicu baze koja je prikazana u tablici 5.

Tablica 5. Struktura zapisa u bazi podataka u koju se spremaju objave

public.senzorska_ocitanja

Id bigserial primary key

Lokacija geometry

Vrijeme_ocitanja timestamp

Identifikator_senzora varchar(50)

Tip_senzora varchar(50)

Vrsta_ocitanja varchar(50)

25

Vrijednost float

Jedinica_ocitanja varchar(50)

Kontinuirani upiti su perzistentni te se oni spremaju u bazu podataka. U ostvarenom

sustavu to je postignuto pohranom pretplata koje pristignu od korisnika u tablicu

„pretplate“, a sve što je vezano za relaciju pretplatnik-pretplata se može saznati iz

te tablice čija je struktura prikazana u tablici 6.

Tablica 6. Struktura zapisa u bazi podataka u koju se spremaju pretplate

public.pretplate


Geometrija_pretplate geometry

Identifikator_pretplatnika timestamp

Identifikator_senzora varchar(50)



Interval_donji float

Interval_gornji float

Prilikom definicije ostvarenog sučelja REST odredili smo resurs kojim će se moći

dohvatiti informacije o svim vrstama očitanja i mjernih jedinica koje se vežu uz njih.

Efektivno ova tablica sadrži popis tih podataka na temelju objava koje postoje u

bazi, a kako bi što više ubrzali potragu za tim podacima, pospremit ćemo ih u ovu

tablicu koja služi kao priručno spremište. Kada stigne objava, prvo se provjerava

postoji li već zapis o vrsti očitanja i mjernoj jedinici u ovoj tablici. Ako ne postoji

stvara se novi zapis s tim podacima. Tako smo ubrzali dohvaćanje tih podataka u

odnosu da smo pretraživali po svim objavama te tako dohvaćali te podatke.

Tablica 7. Struktura zapisa u bazi podataka za pohranu podataka o senzorima

public.podaci_o_senzorima




26

Tablica „konverzije“ sadrži formule za pretvorbe vrijednosti iz jednih mjernih jedinica

u druge, a formule su vezane uz vrstu očitanja. Također prije zapisivanja se

provjerava postojanje formule za vrstu očitanja, kako ne bi došlo do kolizije u

odlučivanju, što znači da za neku vrstu mjerenja može postojati samo jedna formula

pretvorbe iz jedne mjerne jedinice u drugu.

Tablica 8. Struktura zapisa u bazi podataka u koju se spremaju pretvorbene formule

public.konverzije



Iz_mjerne_jedinice varchar(50)

U_mjernu_jedinicu varchar(50)

Formula varchar(500)

2.3 Poslužitelj

Korišteni su Javini RESTful web servisi za ostvarenje sučelja koje implementira

paket „Jersey“ koji dolazi s izabranim poslužiteljem GlassFish. Paket „Jersey“ je

implementacija JAX-RSa koji podržava anotacije koje olakšavaju izgradnju samog

REST sučelja zato što svu definiciju otvorenih URL-ova možemo pospremiti unutar

jedne klase odnosno datoteke.

2.3.1 Geotools

GeoTools je besplatni alat otvorenog koda napisan u Javi koji omogućava korištenje

vektorskih i rasterskih prostornih podataka. Sastoji se od velikog broja modula koji

omogućavaju pristup GIS podacima u datotekama raznih formata i prostornim

bazama podataka. Ključna stavka je oblik (feature). Oblik se poistovjećuje s

Javinim objektom, a po definiciji može biti neki objekt iz stvarnog svijeta (npr.

Himalaja). Kao i objekti u Javi tako i oblici sadrže informacije o stvarnom predmetu

kojeg predstavljaju, a organizirani su u atribute (baš kao što su u Javi polja objekta).

U Javi razred (klasa) grupira objekte koji imaju iste ili slične karakteristike, a tako

FeatureType grupira oblike. Ova knjižnica koristi terminologiju koja je pomalo

različita od Javine što se vidi u tablici 9.

27

Tablica 9. Istovjetnost značenja klasa u GeoTools knjižnici i Javi

Java GeoSpatial

Object Feature

Class FeatureType

Field Attribute

Method Operation

GeoTools nudi sučelja za Feature, FeatureType i Attribute. Oblik vrlo često

ima jednostavne atribute koji su tipa String, Integer i Date, a ne reference na druge

oblike te stoga postoji i klasa dijete oblika koja se zove SimpleFeature. Na razini

Java koda oblik je sličan klasi java.util.Map zato što služi za spremanje informacije

pa tako se vrijednosti atributa mogu pretraživati po ključu, dok je lista ključeva

sadržana u klasi FeatureType. Oblik se od objekta razlikuje svojstvom određenosti

koji se zove lokacija dakle sadrži informaciju o svojoj lokaciji kako bi ga mogli

prikazati na karti.

Lokaciju objekta predstavlja geometrija (Geometry) koja je spremljena u atribut

oblika. Geometrija može biti npr. točka, linija ili poligon, te je određena jednom ili

više točaka i površina. GeoTools interno za prikazivanje i obradu geometrijskih

oblika koristi knjižnicu JTS (Java Topology Suite) koja nudi efikasnu

implementacijugGeometrija. Geometrije mogu biti prikazane i instancirane iz raznih

formata zapisa kao što je WKT. Prostorni podaci se obrađuju kroz sučelje DataStore

API koje može predstavljati datoteku, uslugu ili bazu podataka koja ih sadrži. Za

dohvaćanje se koriste GeoTools-ovo sučelje FeatureSource, a za spremanje

FeatureStore. Usporedba klasa knjižnice GeoTools i JDBC drivera nalazi se u

tablici 10.

Tablica 10. Istovjetnost značenja klasa u GeoTools knjižnici i upravljaču bazom

podataka JDBC driver-u

GeoTools JDBC

FeatureSource View

FeatureStore Table

FeatureCollection PreparedStatement

28

GeoTools JDBC

FeatureIterator ResultSet

SimpleFeatureSource featureSource = dataBase.getSimpleFeatureSource();

if (featureSource instanceof SimpleFeatureStore) {

SimpleFeatureStore featureStore = (SimpleFeatureStore) featureSource;

// Za zapisivanje - WRITE ACCESS

SimpleFeatureCollection collection = new

ListFeatureCollection(dataBase.getShapeType(), features);

featureStore.setTransaction(transaction);

try{

featureStore.addFeatures(collection);

transaction.commit();

} catch(Exception e)

{

transaction.rollback();

throw e;

}

finally {

transaction.close();

dataBase.dispose();

}

}

2.4 Pretplate i objave

Kada nova objava pristigne u sustav potrebno je pronaći pretplate kojima će ta

objava biti poslana. Pretplatnike se redom traži po logičkim cjelinama, dakle prvo se

funkcijom ST_Intersects uspoređuje geometrija pretplate i objave da se utvrdi

postoji li među njima presijecanje. Ova je PostGIS-ova funkcija koja se poziva kroz

knjižnicu Geotools. Zajedno s geometrijom provjerava se i vrsta mjerenja u objavi i

ona koja je definirana pretplatom. Zatim se provjeravaju ostali parametri pretplata i

objave. Ako ne postoji formula pretvorbe automatski objava ne zadovoljava

pretplatu, što je i logično jer pretplatnik nije unaprijed definirao pretvorbenu formulu

pa možemo zaključiti da ga te objave ne zanimaju.

Pretplate i objave, uspoređujemo u dvije grupe, a prva grupa usporedbi sastoji se

od usporedbe geometrije i vrste mjerenja preko upita na bazi. Ovo je napravljeno

zbog dinamičkih pretvorbi mjernih jedinica jer kada prva grupa usporedbe vrati

potencijalne pretplatnike, tada se za svakog pretplatnika mora dohvatiti formulu

pretvorbe iz baze podataka te se u memoriji poslužitelja mora odraditi prilagodba

objave na pretplatu na osnovu čeka se konačno može odraditi drugu grupu

29

usporedbi koja se sastoji od provjere postojanja formule i provjere pripadanja

vrijednosti objave intervalu vrijednosti pretplate.

Algoritam traženja pretplatnika za jednu objavu se sastoji od sljedećih koraka, uz

napomenu da se algoritam zaustavlja ukoliko bilo koji korak nije zadovoljen:

1. Provjera presijecanja geometrija , funkcija ST_Intersects, primjer

presijecanja prikazuje slika 7.

2. Provjera vrsta mjerenja objave i pretplate

3. Ako se mjerne jedinice objave i pretplate razlikuju, postoji li formula pretvorbe

iz jedne u drugu

4. Ako postoji formula pretvorbe, pretvara se vrijednost iz objave u novu mjernu

jedinicu

5. Usporedba vrijednosti iz objave s granicama intervala definiranih u pretplati

6. Objava odgovara pretplati, pronađen je pretplatnik

Slika 7. Presijecanje dva poligona

30

Izvorni kod za traženje pretplatnika prvom grupom usporedbi (geometrije i vrste

mjerenja), koji vraća sve potencijalne pretplatnike iz baze podataka:

public List<SubscriptionResource>

getSubscribersBySensorReading(SensorReadingResource

sensorReadingResource) throws Exception {

WKTWriter wktWriter = new WKTWriter();

StringBuilder filterBuilder = new StringBuilder();

filterBuilder.append("INTERSECTS (");

filterBuilder.append(GEOMETRIJA_PRETPLATE);

filterBuilder.append(",");

filterBuilder.append(wktWriter.write(convertGeoJSONType(sensorReadingReso

urce.getLokacija())));

filterBuilder.append(")");

filterBuilder.append(" AND ");

filterBuilder.append(VRSTA_OCITANJA);

filterBuilder.append(" = '" +

sensorReadingResource.getVrstaOcitanja() + "'");

String filterQuery = filterBuilder.toString();

Filter filter = CQL.toFilter(filterQuery);

SimpleFeatureCollection features =

dataBase.getSimpleFeatureSource().getFeatures(filter);

List<SubscriptionResource> subscribers = new

ArrayList<SubscriptionResource>();

SimpleFeatureIterator simpleFeatureIterator = features.features();

try {

while( simpleFeatureIterator.hasNext() ){

SimpleFeature feature = simpleFeatureIterator.next();

SubscriptionResource subscriptionResource =

toSubsciptionResource(feature);

subscribers.add(subscriptionResource);

}

}

finally {

simpleFeatureIterator.close();

}

return subscribers;

}

Izvorni kod za traženje pravih pretplatnika za tu objavu među potencijalnim

pretplatnicima, drugom grupom usporedbi (postojanje konverzije ako se razlikuju

mjerne jedinice i provjera intervala vrijednosti):

List<SubscriptionResource> subscribers;

for(SensorReadingResource sensorReadingForPublish : forPublish)

{

31

subscribers =

subscriptionRepository.getSubscribersBySensorReading(sensorReadingForPubl

ish);

for(SubscriptionResource subscriptionResource : subscribers)

{

SensorReadingResource sensorReading =

prepareForSubscriber(sensorReadingForPublish, subscriptionResource);

if(null == sensorReading)

{

//NEMA KONVERZIJE

continue;

}

//PROVJERA INTERVALA

if( ! (subscriptionResource.getIntervalDonji() <=

sensorReading.getVrijednost() && sensorReading.getVrijednost() <=

subscriptionResource.getIntervalGornji())) {

// NIJE U INTERVALU

continue;

}

//PRETPLATNIK ODGOVARA OBJAVI

String subscriberID =

subscriptionResource.getIdentifikatorPretplatnika();

//SLANJE PRETPLATNIKU

String sensorReadingGeoJSON =

mapper.writeValueAsString(sensorReading);

GCMServer.sendMessageToClient(subscriberID,

sensorReadingGeoJSON);

Korisnike se identificira preko pretplata tako da se jedan korisnik može pretplatiti na

neograničen broj pretplata, a također može definirati više njih istovremeno. Pretplata

je zaseban entitet u sustavu. Kada korisnik definira više preplata odjednom, svaka

pretplata će se pohraniti kao da ih je definirao jednu po jednu, dakle one neće biti

povezane. Logika iza tog principa je da se spriječe pretplate koje ne bi zadovoljavale

uvjete za nijednu objavu.

Kada uzmemo u obzir navedeno i da je pretplata u GeoJSON obliku, tada možemo

prikazati primjer jedne pretplate:

{ "type": "FeatureCollection",

"features": [

{ "type": "Feature",

"geometry": {

"type": "Polygon",

"coordinates": [

[ [100.0, 0.0], [101.0, 0.0], [101.0, 1.0],

[100.0, 1.0], [100.0, 0.0] ]

]

},

"properties": {

"identifikator_pretplatnika": "jgu24hg23wij29g24",

"vrsta_ocitanja": "temperatura",

32

"jedinica_ocitanja": "C",

"interval_donji": 20,

"interval_gornji": 30

}

}

]

}

Identifikator pretplatnika predstavlja jedinstveni identifikator usluge GCM (Google

Cloud Messaging for Android) pomoću kojeg Googleov poslužitelj šalje objave

aplikaciji. Svakom pretplatniku će objava biti poslana odmah nakon što se utvrdi da

njegova pretplata odgovara pristigloj objavi. Jednokratni upiti, iako vrlo slični

pretplatama, razlikuju se po mogućnosti definiranja vremenskog intervala u kojem

korisnika zanimaju objave koje se nalaze spremljene u bazi. Jednokratni upit se

koristi kada se želi dohvatiti povijest spremljenih objava te je jednokratnim upitom

nemoguće dohvatiti objave iz budućnosti zato što se on ne pospremi u bazu

podataka. Odgovor poslužitelja na jednokratni upit šalje se preko REST sučelja,

dakle kada stigne zahtjev jednokratnog upita, u odgovoru s poslužitelja će se nalaziti

sve objave koje odgovaraju tom upitu.

Primjer jednokratnog upita:


"features": [


"geometry": {

"type": "Polygon",

"coordinates": [

[ [100.0, 0.0], [101.0, 0.0], [101.0, 1.0],

[100.0, 1.0], [100.0, 0.0] ]

]

},

"properties": {


"jedinica_ocitanja": "C",

"interval_vrijednosti_donji": 20,

"interval_vrijednosti_gornji": 30,

"interval_vremena_donji": "2013-01-21T12:30:21",

"interval_vremena_gornji": "2016-01-21T12:30:21"

}

}

]

}

Proces pronalaska odgovarajućih podataka kod jednokratnih upita je drugačiji nego

što je to kod objave. Kada se dogodi objava tada se prema njoj traže pretplate, a

33

kod jednokratnih upita je postupak obrnut, odnosno jednokratnim upitom se traže

odgovarajuće objave kako je i prikazano na slici 8.

Slika 8. Smjer traženja odgovarajućih pretplata i objava

Kako bi lakše opisali što je objava, zamislimo jedan digitalni termometar s

mogućnošću spajanja na Internet koji se nalazi negdje u Zagrebu i mjeri

temperaturu u Celzijusima. Taj termometar je zapravo senzor koji je spojen na

Internet preko najbliže bežične pristupne točke, a podešen je tako da svaku očitanu

promjenu koja se razlikuje od prethodne za neki manji Δ𝑡 pošalje na REST sučelje.

Senzor je tvornički napravljen da strukturira podatke u formatu GeoJSON koji sadrži

svoju trenutnu lokaciju (geometriju) te dodatne parametre kao što je očitanja

vrijednost, vrijeme, svoj identifikator, vrstu veličine koju mjeri i mjernu jedinicu za

očitanu vrijednost. Taj skup povezanih strukturiranih podataka kada pristigne putem

mreže na ostvareni repozitorij postaje jedna objava.

Iz svega do sada navedeno ovdje se nalazi primjer jedne objave:


"features": [


"geometry": {

"type": "Polygon",

"coordinates": [

[ [100.5, 0.1], [100.8, 0.1], [100.8, 0.2],

[100.5, 0.2], [100.5, 0.1] ]

]

},

"properties": {

"vrijeme_ocitanja": "2015-04-29T20:24:25",

"identifikator_senzora": "senzor123456",

"tip_senzora": "termometar",


"vrijednost": 27,

34

"jedinica_ocitanja": "C"

}

}

]

}

Upotrijebili smo tip FeatureCollection jer podržava slanje liste takvih očitanja,

odnosno mogućnost privremenog spremanja na senzoru te slanja više objava

odjednom. Omogućuje senzoru rad kada je izvan mreže, odnosno nije spojen na

Internet, te kada se spoji da pošalje sve što je do tada izmjerio, u jednom slanju

podataka na sučelje REST. Za pretvaranje iz jedne mjerne jedinice u drugu pomoću

formule korištena je knjižnica „exp4J“ koja omogućava evaluaciju matematičkih

izraza i funkcija u stvarnoj domeni.

Primjer definiranja jedne konverzije slanjem u JSON formatu na REST URI:

{

"vrstaOcitanja" : "temperatura",

"izMjerneJedinice": "C",

"umjernuJedinicu": "K",

"formula" :"C - 273.15"

}

Kada poslužitelj uspješno odredi pretplatnika tada mu je potrebno poslati objavu na

koju je pretplaćen. Iskoristili smo uslugu GCM za tu potrebu, a implementirana klasa

izgleda ovako:

public class GCMServer {

private static final String APIKey = "API-KLJUC";

private static Sender sender = new Sender(APIKey);

public static void sendMessageToClient(String registrationId,

String jsonBody) throws Exception {

Message message = new Message.Builder()

.addData("data", jsonBody)

.build();

sender.send(message, registrationId, 0);

}

}

Klasa je poprilično jednostavna jer su dovoljne samo klase Sender i Message iz

paketa com.google.android.gcm.server i potrebno je pozvati metodu send te kao

35

parametre predati poruku koju šaljemo i identifikacijski ključ klijenta kojem šaljemo,

a dodatni treći parametar je broj ponovnih pokušaja u slučaju neuspjeha.

Slijedni dijagrami prikazan na slici 9 i 10 prikazuju aktiviranje jedne pretplate i

objavljianje jedne objave u usutavu.

Slika9. UML sekvencijski dijagram za pretplatu nakon koje slijedi objava

Slika 10. UML sekvencijski dijagram za jednokratni upit

36

2.5 Aplikacija za operacijski sustav Android

Operacijski sustav Android je otvorenog koda i napravljen je za mobilne uređaje te

je danas najrašireniji operacijski sustav za mobilne . Dolazi u raznim verzijama, a

osnovni tip jezgre je Linux jezgra. Posljednja stabilna verzija je 5.1.x kodnog imena

Lollipop. Iako su sama jezgra, API i knjižnice ra razvoj napisane u C programskom

jeziku, aplikacije su zapravo napisane u Javi i pokrenute unutar modificiranog

Javinog virtualnog stroja imenom Dalvik-ov virtualni stroj. Kod novijih verzija Android

uređaja sa operacijskim sustavom vezije 5.0 koristi se napredniji virutalni stroj ART

(Android Runtime).

Aplikacije za Android su pisane u Javi pa je tako izvedena i zadana aplikacija.

Aplikacije za Android se pokreću unutar svog vlastitog okruženja (sandbox) koje je

izolirano od ostatka sustava tako da nemaju pristup dijelovima operacijskog sustava

bez dodatnih odobrenja, koje je eksplicitno pridodao korisnik prilikom instalacije

aplikacije . Također Android je sustav koji podržava višekorisničko okruženje pa se

tako svaka aplikacija ponaša kao jedan korisnik s vlastitim identifikacijskim brojem

koji je nepoznat aplikaciji, a na temelju tog ID broja sustav pridjeljuje i prati dozvole

odobrene toj aplikaciji. Jedna od mogućnosti Android uređaja je praćenje trenutne

lokacije, a mnogo uređaja ima ugrađene senzore za mjerenje raznih vrsta mjerenja.

Kada spojimo te dvije opcije, uz korisnikovo dopuštenje, možemo mobilni uređaj

pretvoriti u mobilni senzor koji objavljuje podatke u ostvareni repozitorij. Za potrebe

pokazne aplikacije nećemo implementirali provjeru mogućnosti pretvorbe u senzor,

ali možemo tražiti korisnikovo dopuštenje za prepoznavanje lokacije kako bi mu

olakšali pretplaćivanje na repozitorij za njegovo interesno područje.

2.5.1 Osnovne logičke cjeline Android aplikacija

Logičke cjeline se mogu shvatiti kao komponente aplikacije, a postoji par vrsta

osnovnih od koje se sastoji svaka aplikacija. Svaka komponenta određuje svoj

životni ciklus unutar aplikacije. Aktivnost je jedna od tih osnovnih komponenti. Kao

što samo ime kaže, pomoću nje se komunicira s korisnikom, odnosno prikazuje se

sučelje i obrađuje interakcija korisnika i sučelja. Aplikacija može imati više aktivnosti

koje su najčešće različite po svojim mogućnostima i zadaćama. Interakcija se svodi

37

na promjenu aktivnosti odnosno stvaranje nove aktivnosti pri čemu se svaka

posprema na FIFO stog. Implementirana je s nekoliko metoda koje možemo

interpretirati kao događaje koji se dogode prije neke važnije promjene u ciklusu:

onCreate – stvaranje nove aktivnosti

onStart - prije nego što se sučelje osvježi i prikaže pozvat će se ova metoda

onResume – pozvana je metoda kada je aktivnost stvarno postala vidljiva

onPause– prilikom zaustavljanja aktivnosti

onStop – nakon što je aktivnost zaustavljena

Aktivnosti, kao i procesi, podliježu prioritetima, upravitelju prozora i odlasku u

pozadinsko stanje. Prilikom pauziranja aktivnosti ona će zadrži svoje stanje u radnoj

memoriji tako da je upravitelj prozorima može uvijek prebaciti u aktibno stanje. Kada

pozivom metode onStop aktivnost prijeđe u pozadinu, tada više nije vezana za

upravitelja prozora i postoji mogućnost da će biti izbrisana, iako čuva sve

informacije. Slika 11. prikazuje životni ciklus aktivnosti u operacijskom sustavu.

38

Slika 11. Životni ciklus i stanja aktivnosti u Android-u

Fragmenti služe prikazivanju unutar same aktivnosti odnosno oni su jednostavniji

dijelovi aktivnosti čijim sadržajem aktivnost upravlja te tim promjenama aktivno

mijenja sadržaj prikazan na ekranu. Usluge služe za izvršavanje operacija na

zasebnim dretvama u pozadini aplikacije. Dakle one se poistovjećuju sa

pozadinskim uslugama kojima se aplikacija služi za obavljanje poslova koji su

paralelni s poslovima obrade korisničkog sučelja. Samim time one nemaju ulogu u

prikazu korisničkog sučelja već su zadužene za poslove poput snimanja i čitanja s

diska ili spajanja te dohvaćanja podataka iz mreže. Bitno je naglasiti da nam usluge

služe i za obavljanje radnji kada aplikacija nije u fokusu odnosno kada nije glavna

na korisničkom sučelju. Postoje u dvije vrste, kao pokrenuta usluga i kao povezana

39

usluga. Pokrenuta usluga je instancirana iz neke druge komponente te se ona izvodi

u pozadini dok god nije prekinuta. Pokreće se metodom startService. Povezana

usluga kreira se stvaranjem veze s nekom drugom komponentom pri pozivu metode

bindService, a ona tada omogućava komunikaciju te dvije komponente. Izvršava

se dok postoji komponenta s kojom je povezana, jednom ili više njih, ali barem

jednom. Pružatelji sadržaja zaduženi su za podatke koji se dijele među aplikacijama,

a to su podaci iz baze podataka, datotečnog sustava ili mreže. U Androidu postoji

par unaprijed definiranih kao što su npr. pristup kontaktima ili glazbi.

2.5.2 Komunikacija između aplikacije i poslužitelja

Ostvarena pokazna aplikacija i poslužitelj komuniciraju na dva načina. Kada

aplikacija inicira zahtjeve na poslužitelj tada se komunikacija odvija preko HTTP-a

na sučelje REST klasičnim slanjem zahtjeva na poslužitelj, a poslužitelj odgovara

istim putem natrag. Ovakva komunikacija je moguća jer poslužitelj ima javnu IP

adresu koju aplikacija poznaje. Međutim kada poslužitelj inicira zahtjeve na

aplikaciju tada on ne zna gdje se aplikacija nalazi jer ona nema javnu IP adresu na

koju bi poslužitelj poslao svoj zahtjev. Ovaj problem riješen je korištenjem Google-

ove usluge GCM.

GCM omogućava dvosmjernu komunikaciju između Android aplikacije i poslužitelja

koju su spojeni preko Interneta. Sastoji se od poslužiteljskog dijela i klijentskog

dijela, a potrebno je implementirati zasebno na svakoj strani komunikacijskog

kanala. Poslužitelj se registrira na Google-ovoj usluzi GCM te dobiva unikatni

identifikator. Zatim se aplikacija može registrirati na poslužitelja tako da poznaje

njegov GCM identifikator. Prilikom registracije aplikacija će od poslužitelja dobiti svoj

jedinstveni ID, koji će poslužiti poslužitelju da točno zna kojem uređaju se šalje

poruka. Cijela komunikacija se odvija preko Google-ovih poslužitelja, odnosno

posrednika, a veličina poruke ograničena je na 4kb.

Aplikacija omogućava korisniku definiranje pretplate na karti Google Maps, a svaki

korisnik prije nego što se pretplati na repozitorij može odraditi par stvari:

dohvatiti listu svih vrsta mjerenja i pripadajućih mjernih jedinica

dohvatiti listu svih postojećih formula pretvorbi, odnosno provjera postoji li

formula pretvorbe za mjernu jedinicu u kojoj on želi definirati pretplatu

40

u slučaju da pretvorba ne postoji, odabirom "Add conversion" tipke na ekranu

može dodavati nove formule pretvorbe, a to želi napraviti da bi bio siguran

da će primati pretplate u drugim mjernim jedinicama.

2.5.3 Korištenje aplikacije

"Add subscription" tipkom na ekranu dodaje se nova pretplata. Kod postavljanja

postavki pretplate korisnik definira vrstu mjerenja, mjernu jedinicu, gornji i donji

interval vrijednosti i vrstu geometrijskog oblika kako je prethodno definirana

pretplata. Slika 12. prikazuje izgled korisničkog sučelja aplikacije.

Slika 12. Izgled Android aplikacije

Slika 13. Primitak notifikacije o objavi

U aplikaciji je moguće izabrati između nekoliko ponuđenih različitih geometrija, a to

su točka, linija i poligon. Ograničen je izbor zato što aplikacija služi u demonstrativne

svrhe i da se izbjegne komplikacija implementacije sučelja. Nakon što korisnik

odabere tip geometrije, klikom na prikazanu kartu definira geometriju u stvarnom

prostoru tako da odabire točke. Zatim potvrdom na gumb "OK" aplikacija će

pretplatu poslati na poslužiteljevo sučelje REST. Očekivani rezultat je naknadni

primitak objava koje odgovaraju definiranoj pretplati u obliku notifikacije koja pristiže

putem GCM usluge, kao što se vidi na slici 13.

41

3. Analiza performansi sustava

Objave su ključni dio ostvarenog repozitorija te one nose informacije koje

omogućavaju uspješan rad repozitorija. Postoji velika kvantitativna razlika između

objava i pretplata. Naime pretplata će u repozitoriju uvijek biti puno manje nego što

će biti zabilježenih objava i dolazimo do zanimljive primjedbe o strukturi modela

objavi-pretplati u ostvarenom sustavu, a to je da će gotovo uvijek biti puno više

objavljivača, u ovom slučaju senzora, nego što će biti pretplatnika. Kako vrijeme

odmiče repozitorij će sve više težiti u opisano stanje. Za kontinuirane upite to nije

problem jer se za svaku pristiglu objavu uspoređuje relativno manji skup

pretplatnika. Možemo reći da će to uvijek biti puno manji skup od skupa objava.

Potencijalni problem se javlja kod jednokratnih upita s velikim vremenskim

intervalom od interesa. Postavlja se pitanje, kako će se sustav ponašati kada stigne

jednokratni upit s geometrijom koja pokriva veliko područje s dodatnim parametrom

vremenskog intervala od jedne godine, a pretpostavka je da će veliki broj objava

zadovoljiti taj upit.

U skladu s tim postoje dvije vrste mjerenja koje je potrebno napraviti. Prva vrsta

mjerenja su performanse jednokratnih upita, a druga su performanse kontinuiranih

upita odnosno pretplata jer se te dvije vrste razlikuju u tome kako korisnik prima

odgovor. Obje imaju sličnosti u tome što možemo mjeriti postotak „pogodaka“

odnosno koliko je objava ili pretplata zadovoljilo tražene kriterije. Pretpostavka je

opet što je veći broj pogođenih to će biti dulje vrijeme obrade bilo jednokratnog upita

ili objave.

Kod jednokratnih upita odgovor se vraća na IP adresu s koje je i došao te je to

proces klasičnog HTTP upita i odgovora. Kada stigne upit započnemo mjerenje, a

kada repozitorij pronađe sve odgovarajuće objave za taj upit i prije nego što

odgovori korisniku natrag, zaustavlja se mjerenje. Dakle upit je sinkron jer će

korisnik za to vrijeme čekati od poslužitelja na odgovor.

Kod kontinuiranih pretplata mjerit ćemo koliko je potrebno sustavu da za određeni

broj objava, unutar nekog vremenskog intervala, pronađe sve odgovarajuće

pretplate za pojedinu objavu. Mjerenje se započinje kada pristigne objava u sustav,

a zaustavlja kada su pronađene sve pretplate čije kriterije objava zadovoljava. Upit

je asinkron jer korisnik ne mora čekati na odgovor s poslužitelja jer će mu podaci

42

biti dostavljeni preko usluge GCM kada poslužitelj bude ima0 podatke za njega. Zato

ova vrsta mjerenja pokazuje isključivo koliko je potrebno vremena poslužitelju da

obradi objavu.

Pomoću usluge Google Maps lako se može saznati geografsku lokaciju Grada

Zagreba što je prikazano na slici 14.. Repozitorij koristi koordinate koje su zadane

u decimalnom prikazu pa će nam podaci s ove usluge biti od koristi jer daju

informaciju lokacije u decimalnom prikazu, a za Zagreb su to [45.804687,

15.981131] redom zemljopisna širina pa dužina odnosno gledano za ostvareni

sustav kada definiramo geometriju u formatu WKT, prvo je prikazana y koordinata

pa x koordinata, dakle ta točka u formatu WKT bi izgledala ovako: POINT

(15.981131, 45.804687)

Slika 14. Koordinate Grada Zagreba u aplikaciji Google Maps [21]

3.1 Mjerenje

Alat koji nam je poslužio za mjerenje je Apache JMeter koji je napisan u Javi i

otvorenog je koda, a dizajniran je za testiranje funkcionalnosti i performansi sustava

pod opterećenjem. Simulira preopterećenost poslužitelja i rad pod velikim brojem

zahtjeva stvaranjem više dretvi koje istovremeno šalju zahtjeve na poslužitelj te tako

analizira rad sustava kakav bi on stvarno bio da je korišten u praksi. Ovaj alat je

dobar i po tome što može slati modificirane zahtjeve HTTP na sučelja REST, a mi

43

ćemo ga iskoristiti upravo za to. Za potrebe mjerenja rezultata napravljen je i

generator pretplata i objava. Mjerni podaci će biti generirani u formatu csv jer

Apache JMeter ima mogućnost slanja različitih zahtjeva učitavanjem parametara iz

datoteka strukturiranih kao csv, a zatim se definira uzorak na temelju kojeg JMeter

iščitava podatke iz datoteka i popunjava varijable u uzorku da dobije konačni izgled

zahtjeva.

Generator stvara objave i pretplate s geometrijom čije koordinatne točke variraju

oko točke centra Grada Zagreba. Koordinate točaka geometrija stvaraju se

dodavanjem i oduzimanjem slučajno generiranih brojeva između 0 i 1 na x i y

koordinate točke (15.981131, 45.804687). Također se stvaraju tri vrste mjerenja:

„temperatura“, „buka“ i „CO2“ od kojih svaka ima svoje mjerne jedinice, definirane

formule pretvorbe i početne točke iz kojih se pomoću slučajno generiranih brojeva

dobivaju vrijednosti objava i intervali pretplata. Npr. početna točka za vrstu mjerenja

temperatura uz mjernu jedinicu K (Kelvin) je 300 stupnjeva, a za mjernu jedinicu C

(Celzij) je 25 stupnjeva te postoje formule pretvorbe u bazi podataka.

Ovako izgleda uzorak objave za JMeter tj. zahtjev HTTP POST koji će biti poslan

na REST sučelje i predstavljat će objavu:

{ „type“: „FeatureCollection“,

„features“: [

{ „type“: „Feature“,

„geometry“: {

„type“: „${tipGeometrije}“,

„coordinates“: ${koordinate}

},

„properties“: {

„vrijeme_ocitanja“: „${vrijemeOcitanja}“,

„identifikator_senzora“: „${identifikatorSenzora}“,

„tip_senzora“: „${tipSenzora}“,

„vrsta_ocitanja“: „${vrstaOcitanja}“,

„vrijednost“: ${vrijednost},

„jedinica_ocitanja“: „${jedinicaOcitanja}

}

}

]

}

JMeter predstavlja i korisnike koji se pretplaćuju na repozitorij, a isto tako predstavlja

i senzore koji objavljuju u repozitorij. Kako bi testiranje stresa bilo što vjernije i kako

bi se izbjeglo čekanje u mreži podešen je JMeter na istom računalu gdje je pokrenut

i poslužitelj i baza podataka pa će efektivno oni biti u lokalnoj mreži gdje možemo

44

zanemariti kašnjenje. Slika 15. prikazuje podešenu JMeter aplikaciju za testiranje

repozitorija.

Generator kreira par vrsta objava i pretplata koje se razlikuju po vrsti geometrije i

dodatnim parametrima. Vrste geometrije koje kreira su točka (Point), linija

(LineString) i poligon (Polygon), a vrste mjerenja su temperatura, buka i CO2 u

zraku. On stvara broj objava i pretplata koji su zadani pri njegovu pokretanju.

Metoda za generiranje jedne točke koja se zatim poziva kod stvaranja koordinata

za sve zadane vrste geometrija:

public String generatePoint() {

double ZagrebX = 15.981131;

double ZagrebY = 45.804687;

double xCoord = ZagrebX + randDouble();

double yCoord = ZagrebY + randDouble();

String tocka = „[„+ Double.toString(xCoord) + „,“ +

Double.toString(yCoord) + „]“;

return tocka;

}

Jedna linija u datoteci će predstavljati jednu pretplatu ili jednu objavu, a linija koja

predstavlja objavu izgleda ovako:

Point;[15.913196758984187,45.891931741227936];2014-01-

04T10:10:10;1197448;termometar;temperatura;273.56651252378333;K

U bazi su prethodno unesene sve moguće pretvorbene formule mjernih jedinica za

dane vrste mjerenja, a ovdje je primjer jedne pretvorbe mjernih jedinica koju POST

metodom pošaljemo na REST sučelje:

{

„vrstaOcitanja“ : „temperatura“,

„izMjerneJedinice“: „C“,

„umjernuJedinicu“: „K“,

„formula“ :“C + 273“

}

45

Slika 15. GUI sučelje JMeter aplikacije za testiranje repozitorija

3.2 Plan mjerenja

Mjerenje performansi kod jednokratnih upita zahtjeva postojeće objave u bazi

podataka. Zato smo započeli s mjerenjem karakteristika pretplata i objava jer je

baza na početku bila prazna, a mjerenjem smo postepeno dodavali pretplate i

objave u sustav. Objave i pretplate sastoje se od slučajno generiranih podataka

dobivenih pomoću spomenutog generatora. Brzinu pretplaćivanja na repozitorij

mjerili smoi za veliki broj pretplata u kratkom intervalu. Kada je sustav u početku

svoga rada imao manji broj pretplatnika, tada su pretplate stizale malom brzinom u

pa smo pretpostavili da bi poslužitelj trebao nove pretplate odraditi iznimno brzo. Za

mjerenje performansi sustava u slučaju objave morali smo imati postojeće

pretplatnike pa smo to mjerenje provodili nakon što je u bazu unešen određeni broj

pretplatnika. Kod svake objave mjerili smo vrijeme potrebno da repozitorij pronađe

sve odgovarajuće pretplatnike kao i broj koliko je pretplata zadovoljila ta objava.

46

Kasnije smo usporedil kako je utjecala brzina objave na broj pretplata koji je objava

zadovoljila. Također dodatno smo promatratli utjecaj vrste geometrije iz objave na

performanse repozitorija. Iz svega navedeno, za svaku objavu zapisivali smo vrstu

geometrije objave, broj odgovarajućih pretplata i potrebno vrijeme za izvršavanje.

Parametri prvog mjerenja su broj pretplata u sustavu i broj objava koji će pristizati u

sustav sa senzora. Broj objava je bio pet puta veći od broja pretplata, kako je

prikazano u tablici 11., jer smo tako povećavali šansu za večim brojem „pogodaka“

odnosno omjera objava i odgovarajućih pretplata.

Tablica 11. Broj pretplata i objava za prvo testiranje

Pretplate 50 100 500 1000 5000

Objave

250 500 2500 5000

25000

Drugim mjerenjem provjerili smo kako se ponaša sustav uz konstantan broj

pretplata i rastući broj objava, a brojevi objava i pretplata su prikazani tablicom 12..

Pretpostavili smo da će prosječno trajanje jedne objave biti konstantno jer će uvijek

pretraživati po istom skupu pretplatnika.

Tablica 12. Drugo mjerenje - konstantan broj pretplata, a rastući broj objava

Pretplate 1000 1000 1000 1000 1000

Objave

500 1000 1500 2000

2500

U trećoj fazi mjerenja ispitali smo kako broj pretplata u sustavu ovisi o trajanju jedne

objave. Uz poznavanje algoritma za jednu objavu, pretpostavili smo da će uz

linearan porast pretplata biti i linearno povećanje u trajanju jedne objave kod

konstantnog broja objava. Broj pretplata za to mjerenje prikazan je tablicom 13.

Tablica 13. Treće mjerenje - Konstantan broj objava uz rastući broj pretplatnika

Objave

100 100 100 100

100

Pretplate 500 1000 1500 2000 2500

47

Performanse jednokratnih upita ispitivali smo promjenom intervala vrijednosti i

vremenskog intervala. Ostali parametri nisu se mijenjali, već smo mjerenje provodili

samo za objave čija je vrsta mjerenja temperatura, a jedinica očitanja stupanj

Celzijev. Ti parametri su bili kontinuirani jer ne utječu toliko na performanse. Ono

što najviše utječe je broj objava koji će zadovoljiti taj upit, a povećanje broja

odgovarajućih objava po upitu ostvarili smo najviše povećanjem vremenskog

intervala. Mjerili smo za vrstu mjerenja „temperatura“, kod koje objave pohranjene

u bazi nemaju vrijednosti izvan intervala 0 – 50 stupnjeva Celzijevih pa je kod upita

bio postavljen konstantan interval na tu vrijednost, kako je prikazano u tablici 14.

Tablica 14. Postavke za jednokratne upite

Interval

vrijednosti / °C

0 - 50 0 - 50 0 - 50 0 - 50

0 - 50

Interval vremenskog razdoblja /

Vrijeme

sat dan mjesec godina

5 godina

Geoprostorni objekt upita bio je poligon koji pokriva područje u koje pripada većina

generiranih pretplata, a zapisan u GeoJSON formatu izgleda ovako:

{

"type": "Polygon",

"coordinates":[

[[15.7609,45.7337],[15.7574,45.8855],[16.1914,45.8773],[16.1948,45.7376],

[15.7609,45.7337]]

]

}

Slikovni prikaz geometrijskog objekta korištenog u jednokratnim upitima nalazi se

na slici16.

48

Slika 16. Poligon za testiranje jednokratnih upita koji sadrži sve objave [22]

3.3 Rezultati

Većina grafičkih prikaza u rezultatima pokazat će tri vrijednosti: maksimalno,

minimalno i prosječno trajanje obrade objave na poslužitelju. Prosjek je

najzanimljiviji podatak za analizu rezultata, međutim za analizu i optimizaciju

sustava potrebno je poznavati koliko je objava maksimalno mogla čekati na obradu

odnosno koliko je maksimalno mogla trajati. Minimalno trajanje prikazano je radi

konzistentnosti grafova, a iz svakog minimalnog trajanja objave se može zaključiti

da su to objave koje su, za vrijeme mjerenja, prve pristigle u sustav te su najmanje

čekale na obradu i bile najbrže obrađene jer sustav još nije bio pod opterećenjem.

U daljnjoj analizi mjerenja fokusirat ćemo se na prosječno trajanje mjerenja jer ono

daje stvarno sliku kako sustav radi pod opterećenjem, a također jer su sve pretplate

i objave generirane nasumičnim geometrijskim oblicima što može značiti da će neke

objave zadovoljavati jako veliki broj pretplata, dok će neke objave zadovoljavati jako

malo ili nijednu pretplatu. Takav oblik mjerenja je najbliži mjerenju ponašanja nekog

stvarnog sustava.

Rezultat mjerenja za trajanje pretplaćivanja u sustav prikazan je na slici 17.

49

Slika 17. Rezultati mjerenja za trajanje pretplaćivanja u sustav

Kako je i očekivano, sustav relativno brzo može obraditi veliki broj istovremenih

novih pretplata. Za 5000 novih pretplata koje u sustav stignu istovremeno potrebno

prosječno vrijeme da ih pohrani je 1700 ms.

Grafički je prikazano trajanje jedne objave u odnosu na broj odgovarajućih pretplata

čije kriterije objava zadovoljava. Svaka točka na grafu predstavlja jednu objavu.

Možemo zaključiti da objava traje duže ako zadovoljava veći broj pretplata. Razlog

tome je implementacija samog algoritma koji prvo uspoređuje geometrijske objekte

objave i pretplate upitom na bazu podataka, a razlika između pretplata koje

odgovaraju objavi i onih koje ne odgovaraju je u tome što se pretplate koje ne

odgovaraju objavi niti ne vrate na poslužitelj iz baze podataka jer su filtrirane SQL

upitom. Dodatno objašnjenje je da se za svaku pretplatu koja odgovara objavi

provjerava postoji li formula pretvorbe mjernih jedinica te se vrši sama pretvorba pa

se i na to izgubi vrijeme obrade objave. Mjerenje je očekivano pokazalo i da je dulje

trajanje objave što je veći broj odgovarajućih pretplata, a grafički prikaz rezultata

nalazi se na slici 18.

0

500

1000

1500

2000

2500

3000

50 100 500 1000 5000

t /m

s

Pretplate / N

Trajanje pretplaćivanja

Min

Max

Prosjek

50

Slika 18. Rezultati mjerenja za trajanje jedne objave u odnosu na odgovarajući broj pretplata

Na grafičkim prikazima na slikama 19. i 20. prikazano je trajanje objave uz

konstantni broj pretplata i konstantni broj objava. Mjerenje je potvrdilo pretpostavku

da će uz konstantan broj pretplata objava trajati jednako za različit broj objava. Na

grafu je prikazano ukupno trajanje kada u sustav pristigne 1000 ili 2500 objava

odjednom te je vidljivo da će u svakom slučaju ukupan broj objava trajati između

15 i 20 sekundi. Razlog tome je što će objava, kada pristigne u sustav, pokrenuti

proces pretrage za pretplatama, koji uvijek pretražuje po istom skupu pretplata.

Kako se unutar 1000 objava same objave dosta razlikuju i različito je vrijeme obrade

za pojedinu objavu, zato smo uzeli prosjek obrade kako bi dobili rezultate koje

možemo uspoređivati isključivo na temelju broja objava.

0

500

1000

1500

2000

2500

0 50 100 150 200 250 300

t / ms

Odgovarajuće pretplate / N

Trajanje jedne objave u odnosu na broj odgovarajućih pretplata

51

Slika 19. Rezultati mjerenja za trajanje objava u odnosu na konstantni broj pretplata

Slika 20. Rezultati mjerenja za trajanje konstantnog broja objava u odnosu na broj pretplata

0

5000

10000

15000

20000

25000

500 1000 1500 2000 2500

t /m

s

Objava / N

Trajanje objava kod konstantnog broja pretplata

Min

Max

Prosjek

0

5000

10000

15000

20000

25000

30000

35000

500 1000 1500 2000 2500

t /m

s

Pretplate / N

Trajanje konstantnog broja objava uz povećanje broja pretplata

Min

Max

Prosjek

52

Postavili smo konstantan broj objava na 100 objava uz linearno povećanje broja

pretplata u bazi podataka, a rezultati su pokazani na grafu iznad. Kako će vrijeme

odmicati u repozitoriju će biti sve veći broj pretplatnika, tako da je ovo realna

situacija. Kada je broj pretplata u bazi jednak 500 tada će 100 objava senzora u

repozitorij prosječno trajati 5,6 sekundi dok će za isti broj objava 100 senzora uz

2500 pretplata u bazi trajati 17,8 sekundi.

Slika 21. Rezultati mjerenja za povećavajući broj pretplata i objava

Svako sljedeće stanje repozitorija je sve veći broj senzora koji objavljuju u sustav

uz sve veći broj pretplatnika koji su pretplaćeni na sustav. Iz grafa na slici 21. vidljivi

su rezultati mjerenja kada je omjer pretplata i objava jednak 1:5. Očekivani

eksponencijalni rast u trajanju objava potvrđen je mjerenjem. Pokušano je mjeriti za

puno veći broj pretplata pohranjenih u bazi podataka, međutim repozitorij to nije

mogao podnijeti te se poslužitelj našao u nefunkcionalnom stanju. Repozitorij rukuje

podacima koji zahtijevaju iznimne napore procesora jer se radi o velikom broju

matematičkih izračuna za usporedbu geometrijskih objekata pa smo morali broj

pretplata spustiti na maksimalno 5000 kako bi mogli izvršiti mjerenja. Također nakon

25000 objava koji pristižu u sustav, pola ih je bilo odbačeno zbog pokušaja

zapisivanja u bazu podataka. Iz ovih rezultata se da zaključiti da je objava dugotrajni

i zahtjevan proces koji pronalazi pretplate, a kako će rasti broj objava i senzora koji

0

5000

10000

15000

20000

25000

30000

35000

40000

50/250 100/500 500/2500 1000/5000 5000/25000

t / ms

Pretplata(N) / Objava(N)

Trajanje objava s povećanjem broja pretplata i objava

Min

Max

Prosjek

53

se spajaju na repozitorij bit će potrebno skalirati sustav na više poslužitelja i baza

podataka kako bi zadržali trajanje jedne objave na maksimalno 30 sekundi.

Slika 22. Rezultati mjerenja za trajanje jednokratnih upita u odnosu na vremenski interval upita

Slika 23. Rezultati mjerenja za trajanje jednokratnih upita u odnosu na broj rezultata objava koji odgovaraju upitu

0

500

1000

1500

2000

2500

sat dan mjesec godina 5 godina

t /m

s

Vremensko razdoblje

Trajanje jednokratnih upita u odnosu na vremenski interval upita

0

500

1000

1500

2000

2500

3000

3500

0 9 67 345 547

t /m

s

Odgovarajuće objave / N

Trajanje jednokratnih upita u odnosu na broj rezultata objava koji odgovaraju upitu

54

Jednokratni upiti daju rezultate kao na slikama 22. i 23. iz kojih možemo jednostavno

zaključiti da će trajanje samog upita trajati toliko dugo koliko će taj upit pronaći

objava koje se nalaze u bazi podataka. Povećanjem vremenskog intervala upita

smo efektivno povećali broj objava koje su zadovoljile taj upit te time produljili

trajanje tog upita. Iz grafova iznad vidimo da je upit koji definira vremenski interval

od mjesec dana trajao četiri puta kraće nego upit s intervalom od pet godina.

Činjenicu potvrđuje i graf trajanja upita u odnosu na broj pronađenih rezultata objava

gdje vidimo da je upit kojem odgovara 67 objava trajao šest puta kraće nego upit

kojem odgovara 547 objava.

Graf na slici 24. prikazuje rezultate mjerenja za trajanje objave ovisno o

geometrijskom obliku kojeg ta objava sadrži. Mjerili smo za tri vrste geometrijskih

oblika: točku, liniju i poligon. Za svaki oblik napravljena je po jedna objava koja je

imala iste karakteristike s jedinom razlikom u geometrijskom obliku. Najkraće traju

objave čiji senzor svoju lokaciju predstavlja kao točku, a najdulje traju objave

senzora koji lokaciju predstavljaju kao poligon. Kako je točka puno manji

geometrijski oblik od poligona tako će se ona presijecati s puno manje drugih

geometrija nego što će se presijecati poligon. Efektivno će objava s točkom pronaći

manje odgovarajućih pretplata nego što će ih pronaći poligon te će iz tog razloga

trajati kraće. Slično je i s linijom koja će pronaći više odgovarajućih objava nego

točka, ali još uvijek puno manje od poligona. Uostalom poligon je geometrijski oblik

koji se sastoji od točaka i linija pa su njemu veće šanse za presijecanjem s drugim

geometrijskim objektima odnosno pronalaskom pretplata za objavu.

55

Slika 24. Rezultati mjerenja za trajanje jedne objave u odnosu na geometrijski objekt te objave

0

200

400

600

800

1000

1200

1400

t/ms

Vrsta objave

Trajanje jedne objave u odnosu na geometrijski objekt te objave

Točka

Linija

Poligon

56

Zaključak

Cilj ovog rada je uspješno ostvaren, a rezultat je repozitorij geoprostornih podataka

za senzorske podatke koji se temelji na komunikacijskom modelu objavi-pretplati.

Prikazana je implementacija repozitorija, slanje i format objava i pretplata, pohrana

u bazu podataka, a također je napravljena i analiza rada repozitorija ostvarenog u

praktičnom djelu ovog rada. Izvedeni su zaključci na temelju rezultata mjerenja

performansi repozitorija. Zaključeno je kako je rukovanje s geoprostornim objektima

zahtjevan posao te bi za korištenje ostvarenog repozitorija u praksi s velikim brojem

korisnika i senzora trebali razmotriti njegovo raspodjeljivanje radi postizanja

zadovoljavajuće skalabilnosti. Sučelje REST se pokazalo kao iznimno dobar izbor

za prikupljanje podataka i analizu performansi poslužitelja zato što su u stvarnosti

senzori raspodijeljeni na različitim lokacijama, a takvo sučelje pojednostavljuje

objavu novih senzorskih očitanja u sustav.

57

Literatura

[1] Krešimir Pripužić, Usporedba u sustavima objavi/pretplati,

https://www.fer.unizg.hr/_download/repository/kvalifikacijski.pdf, 2015.

[2] PostGIS Project Steering Committee, PostGIS documentation,

http://postgis.net/documentation, 2015.

[3] Oracle, GlassFish Get started Quickly, 2013.,

https://glassfish.java.net/getstarted.html, 2015.

[4] Edgewall Software, How to install PostGIS 2.0 on Debian 6.0 (squeeze)

from source,

http://trac.osgeo.org/postgis/wiki/UsersWikiPostGIS20Debian60src, 2015.

[5] Oracle, Getting Started with RESTful Web Services,

https://netbeans.org/kb/docs/websvc/rest.html, 2015.

[6] Boundless, Introduction to PostGIS,

http://workshops.boundlessgeo.com/postgis-intro/, 2015.

[7] Lubby, How to configure a connection pool for a postgres database in

glassfish, http://www.lubby.org/result.jsf?DB=lkb_linux_english&ID=215,

2015.

[8] Oracle, Jersey, Restful Web Services in Java, https://jersey.java.net/, 2015.

[9] Manu Lakaster, Run postgresql queries from the command line,

http://stackoverflow.com/questions/19674456/run-postgresql-queries-from-

the-command-line, 2015.

[10] GeoTools, GeoTools Documentation, http://docs.geotools.org/, 2015.

[11] FOSS4G, W-04: Introduction to PostGIS,

http://2007.foss4g.org/workshops/W-04/, 2015.

[12] Arul Dhesiaseelan, How to send and receive JSON data from a restful

webservice using Jersey API,

http://stackoverflow.com/questions/14600510/how-to-send-and-receive-

json-data-from-a-restful-webservice-using-jersey-api, 2015.

https://www.fer.unizg.hr/_download/repository/kvalifikacijski.pdf

http://postgis.net/documentation

https://glassfish.java.net/getstarted.html

http://trac.osgeo.org/postgis/wiki/UsersWikiPostGIS20Debian60src

https://netbeans.org/kb/docs/websvc/rest.html

http://workshops.boundlessgeo.com/postgis-intro/

http://www.lubby.org/result.jsf?DB=lkb_linux_english&ID=215

https://jersey.java.net/

http://stackoverflow.com/questions/19674456/run-postgresql-queries-from-the-command-line

http://stackoverflow.com/questions/19674456/run-postgresql-queries-from-the-command-line

http://docs.geotools.org/

http://2007.foss4g.org/workshops/W-04/

http://stackoverflow.com/questions/14600510/how-to-send-and-receive-json-data-from-a-restful-webservice-using-jersey-api

http://stackoverflow.com/questions/14600510/how-to-send-and-receive-json-data-from-a-restful-webservice-using-jersey-api

58

[13] The GeoJSON Format Specification, http://geojson.org/geojson-spec.html,

2015.

[14] Open Source Geospatial Foundation, ECQL Reference, 2014.,

http://docs.geoserver.org/stable/en/user/filter/ecql_reference.html#filter-

ecql-reference, 2015.

[15] Android Developers http://developer.android.com/develop/index.html,

2015.,

[16] exp4j, Introduction to exp4j, http://www.objecthunter.net/exp4j/, 2015.

[17] Apache Software Foundation, Apache JMeter,

http://jmeter.apache.org/index.html, 2015.

[18] Wikipedia, Sensor, https://en.wikipedia.org/wiki/Sensor , 2015.

[19] Skica Kartezijevog koordinatnog sustava,

https://upload.wikimedia.org/wikipedia/commons/thumb/6/69/Coord_system

_CA_0.svg/250px-Coord_system_CA_0.svg.png , 2015.

[20] Skica polarnog koordinatnog sustava,

http://mathworld.wolfram.com/images/eps-

gif/SphericalCoordinates_1201.gif, 2015.

[21] Google Maps, Grad Zagreb ,

https://www.google.hr/maps/@45.840196,15.9643316,11z, 2015.

[22] GeoJSONLint, http://geojsonlint.com/, 2015.

http://geojson.org/geojson-spec.html

http://docs.geoserver.org/stable/en/user/filter/ecql_reference.html#filter-ecql-reference

http://docs.geoserver.org/stable/en/user/filter/ecql_reference.html#filter-ecql-reference

http://developer.android.com/develop/index.html

http://www.objecthunter.net/exp4j/

http://jmeter.apache.org/index.html

https://en.wikipedia.org/wiki/Sensor

https://upload.wikimedia.org/wikipedia/commons/thumb/6/69/Coord_system_CA_0.svg/250px-Coord_system_CA_0.svg.png

https://upload.wikimedia.org/wikipedia/commons/thumb/6/69/Coord_system_CA_0.svg/250px-Coord_system_CA_0.svg.png

http://mathworld.wolfram.com/images/eps-gif/SphericalCoordinates_1201.gif

http://mathworld.wolfram.com/images/eps-gif/SphericalCoordinates_1201.gif

https://www.google.hr/maps/@45.840196,15.9643316,11z

http://geojsonlint.com/

59

Geprostorni repozitorij senzorskih podataka

Ovaj rad sadrži osnovne pojmove, problematike i razvoja geoprostornog sustava

temeljenog na modelu objavi-pretplati. Korištena je baza podataka PostgreSQL za

pohranu podataka uz ekstenziju PostGIS za baratanje prostornim podacima.

Repozitorij je dizajniran za senzorske podatke, a svaki senzor posjeduje svoju

lokaciju i dodatne parametre za to očitanje kao što je vrsta mjerenja, vrijednost i

mjerna jedinica. Poslužitelj je napisan u Java programskom jeziku, a koristi

knjižnice klasa kao što je GeoTools za geoprostorne podatke te je pokrenut kao

aplikacija na GlassFish-u. Senzor šalje očitanja na poslužitelj kroz REST sučelje te

je time definirana jedna objava. Korisnici repozitorija također koriste isto sučelje za

pretplaćivanje na objave i slanje jednokratnih upita od interesa. Podaci se

razmjenjuju u GeoJSON formatu. Objave se na klijentsku Android aplikaciju šalju

uslugom GCM.

Ključne riječi:

Geoprostorno, repozitorij, senzori, PostGIS, GeoTools, GeoJSON

60

Geospatial Repository for Sensor Data

This paper describes basic concept, problems and implementation of geospatial

publish-subscribe repository for sensors data. System is implemented in Java

programming language on GlassFish web server which connects to PostgreSQL

database with PostGIS extension for process and storage of geospatial objects.

Sensors publish their data which consists of location and other parameters such

as type of measurement, value, timestamp and measurement unit. Data is

collected through REST interface. Communication with clients goes through that

interface but also uses GCM to send new data to clients subscribers. Two types of

requests are supported that is single query request and subscriptions. Repository

use GeoTools library to manipulate with geospatial data. Interchange format of

data is GeoJSON.

Keywords:

Geospatial, repository, sensors, PostGIS, GeoTools, GeoJSON

geoprostorni repozitorij senzorskih podatakageometrijski oblici poput točke, linije ili poligona 2....

Documents