Zahvala Kazalo Seznam uporabljenih kratic in simbolov 1 Povzetek 2 Abstract 3 Uvod 4 Opis problema 5 Načrt sistema 6 Podatkovni model 7 Geokodiranje 8 Nasprotno geokodiranje 9 Usmerjanje 10 Izkušnje in nadaljnje delo 11 Sklep Dodatek A Navodila za uporabo sistema Literatura
- Naslov
- Razvoj naprednih storitev za GIS
- Del
- 10 Izkušnje in nadaljnje delo
- Datum vsebine
- 08. 11. 2009
- Original
- RazvojNaprednihStoritevZaGIS.pdf
- Vrsta
- diplomska naloga
- Jezik
- slovenščina
- Različica
- 1.0
- Ustanova
- Fakulteta za računalništvo in informatiko, Univerza v Ljubljani
- Študij
- Univerzitetni, računalništvo in informatika, logika in sistemi
- Predmet
- -
- Mentor
- doc. dr. Mojca Ciglarič
- Avtor
- Tine Lesjak
- Ocena
- 10 od 1-10
Gre za celotno diplomsko delo s predstavitvijo.
Dodatne objave dela:
- ePrints.FRI: ID 933
- COBISS: ID 7349844
- predstavitev.pdf
- Predstavitev diplomskega dela na zagovoru (dne 22. 10. 2009).
- projekti.zip
- Vsa izvorna koda v obliki SpringSource Tool Suite projektov (združljivi z Eclipseom) pod licenco Creative Commons Attribution 2.5 Slovenia License
- primeri.zip
- Primeri, predstavljeni kot izvlečki kode v diplomskem delu.
- tinel-gis-geocoding.war
- Storitev geokodiranja.
- tinel-gis-reversegeocoding.war
- Storitev nasprotnega geokodiranja.
- tinel-gis-routing.war
- Storitev usmerjanja.
Sistem vsebuje nekaj uspešnih rešitev, ki drugače predstavljajo resne omejitve. V podatkovnem modelu se podatki ne podvajajo in niso projicirani, zato so neposredno uporabni za analizo kjerkoli na svetu. To je velika prednost, še posebej, če to velja tudi pri storitvi nasprotnega geokodiranja. To je redka praksa, saj so GIS-i običajno lokalne narave (npr. za ZDA), kjer pa načeloma ustreza ena projekcija in so zato podatki predprojicirani. Seveda pri svetovni rabi trpi hitrost, saj se indeksi ne uporabljajo vedno, a kakor smo videli pri meritvah zmogljivosti, je pametna uporaba poizvedbe lahko skoraj enako hitra kot tista, ki vedno uporablja indekse. Zanimivost, ki ostane za nadaljnjo obravnavo, je funkcija PostGIS ST_Intersects, ki je skrivnostno počasna pri velikem iskalnem pravokotniku. To sicer v praksi ni moteče, ker velja le za zelo velik iskalni radij, a morda bi lahko prispevali kakšno plodno debato razvijalcem PostGIS-a.
Vsak geografski podatek lahko ima poljubno število imen. Na prvi pogled sicer ni videti, kakšno prednost prinaša to s seboj. A predstavljajte si ulico, ki ima dve imeni. Ali pa cesto, ki ima dve oznaki. Že v Sloveniji je moč naleteti na takšne primere, npr., avtocesta A1 je na štajerskem koncu tudi E57, na notranjskem koncu pa tudi E61 in E70. Da imajo tudi zgradbe več imen, je odvisno od tega, kako jih poimenujemo. Npr., nakupovalnemu središču lahko dodamo vsa imena trgovin, ki so v njem. Vse to omogoča podatkovni model, le pravilno ga moramo uporabiti. To pa je hkrati tudi slabost, ki se rahlo kaže pri storitvi geokodiranja. Poizvedba vsebuje združevanje tabel (funkcija join), ki je značilno po tem, da je počasno. Meritve zmogljivosti so pokazale, kako največje število zadetkov vpliva na samo poizvedbo. V primerjavi z nasprotnim geokodiranjem je nalaganje stotih zadetkov vsaj trikrat počasnejše (nivo storitev). Definitivno je tukaj še veliko možnosti za nadaljnje izboljšave. Poizvedbe z združevanjem tabel bi lahko enostavno nadomestili kar s celobesedilnim iskanjem, a je to ravno tukaj odpovedalo - zaradi podatkovnega modela, ki omogoča poljubno število geoimen. Tudi drugače je še veliko odprtih vprašanj, recimo skupna hitrost, saj bi bilo treba po celobesedilnem iskanju iz zbirke potegniti vse rezultate.
Bi pa celobesedilno iskanje lahko močno izboljšalo uporabniško izkušnjo v povezavi z dobrim grafičnim uporabniškim vmesnikom odjemalca. Vanj bi vgradili funkcijo, ki sproti išče, kar uporabnik vpisuje v vnosno polje, in prikazuje rezultate v spustnem seznamu. Ko bi se uporabnik odločil za enega izmed zadetkov, bi se ta zadetek naložil iz zbirke in prikazal na zemljevidu ali uporabil kje drugje.
Ravno nasprotno od storitve geokodiranja, ki je namenjena bolj uporabnikom - ljudem, je storitev nasprotnega geokodiranja uporabna večinoma samo za avtomatske namene. Predstavljamo si lahko odjemalce, ki želijo nekajkrat v sekundi izvedeti, kateri znan geografski kraj je najbližji določeni lokaciji, ki jo vrnejo razne naprave GPS. Pri tako pogosti uporabi bo moral odjemalec pametno uporabljati to storitev. Ena možnost je uporaba predpomnjenja (angl. cache, buffer) rezultatov, kar pomeni, da si zapomni vse rezultate od vseh iskanj in namesto iskanja uporabi kar shranjene rezultate, če ustrezajo lokaciji. Ali ustrezajo lokaciji in ali bi iskanje vrnilo enake rezultate, kot so ti, iz predpomnilnika, zna biti zelo zahtevno ugotoviti. Pravzaprav so vsi načini uporabe predpomnjenja zelo delikatni in zahtevni. Velikokrat se ravno zaradi njih uporabljajo drugačni protokoli ali dodatni podatki.
Naslednja, bolj obetavna možnost je kopičenje več zahtev skupaj (angl. bulk). Namesto da odjemalec nekajkrat na sekundo sproži iskanje, lahko zahtevke nekaj časa kopiči in potem z enim iskanjem poišče vse rezultate. Na primer, enkrat na sekundo, ali ko se nabere največ 100 zahtevkov. Tukaj bi veliko privarčevali pri omrežni komunikaciji, povprečni čas reševanja enega zahtevka bi bil bistveno manjši.
Predpomnjenje rezultatov in kopičenje več zahtev skupaj predstavlja zanimivo možnost za nadaljnje delo, oboje pa bi z nekaj popravki na strežniškem delu izvedli večinoma na odjemalčevem delu.
Storitev usmerjanja je uporabna iz več zornih kotov. Lahko jo uporabljajo uporabniki, ki želijo poceni pot od ene lokacije do druge, lahko jo uporablja stroj za samodejno izdelavo poti, lahko jo uporablja kakšen računalnik za optimizacijo delovnih prevozov. Ne nazadnje jo lahko uporabimo tudi za navigacijo. Pri vseh teh načinih uporabe bi bilo smiselno najti optimalne ocenjevalne funkcije, kar zna biti tako zahtevno, kot je zahtevna dejanska cestna mreža.
V prvi fazi bi vsekakor lahko algoritem bistveno pohitrili s tem, da bi občutno zmanjšali število poizvedb. To bi storili tako, da bi uporabili predpomnilnik in bi iz podatkovne zbirke naenkrat potegnili vse ceste, ki padejo v večje območje okoli obravnavanega vozlišča. Na primer, pri sedanjem izračunu poti iz Škofljice v Ljubljana-Dravlje pri običajnih parametrih se podatkovna zbirka uporabi 645-krat in praktično ves čas vzamejo ravno te številne poizvedbe in komunikacija z njimi. Če bi iz zbirke vzeli vse ceste v večjem območju okoli obravnavanega vozlišča kot samo neposredno navezujoče ceste, bi lahko število poizvedb zmanjšali na vsega, recimo, štiri.
Za nadaljnjo obravnavo bi, poleg tega predloga, vzeli pod drobnogled tudi projekt pgRouting, ki dodaja zmožnost usmerjanja neposredno v PostGIS. Že samo dejstvo, da teče neposredno v zbirki, nas prepričuje, da gre za zelo hitro rešitev.
Storitve so napisane v javini arhitekturi, navzven se predstavljajo kot spletni strežnik, ki pa razume le serializirane javine objekte v obliki, kot jo uporablja Springov HTTP Invoker. Odjemalci morajo tako uporabiti isto tehnologijo. Storitve bi lahko preoblikovali tako, da bi se navzven predstavljale v tehnologiji standardnih spletnih storitev (angl. web services). Odjemalci in strežniki v tej tehnologiji komunicirajo le zgolj v obliki XML, zahteve in odgovori so natančno definirani v shemi XSD. Iz izkušenj vem, da bi bila preobrazba obstoječih storitev razmeroma enostavna, če bi uporabili Springov MVC modul. Še več, lahko bi HTTP Invoker obdržali. Ampak iz izkušenj tudi vem, da bi bila takšna storitev nekajkrat počasnejša, saj bi se vsaka zahteva in odgovor najprej po shemi XSD pretvorila v podatke XML (angl. (un)marshall). Po omrežju bi se prenašali večji paketi, ob morebitnih kasnejših razširitvah storitev pa bi morali posebej paziti na posodobitev sheme XSD.
V kolikor nas skrbi za privatnost in varnost podatkov, kar je prav, bi v nadaljevanju lahko komunikacijo med strežniki in odjemalci ovili s kriptografskim protokolom TLS/SSL. Javina arhitektura je na to pripravljena.
Del sistema | Izboljšave |
---|---|
geokodiranje | pohitritev združevanje tabel, celobesedilno iskanje |
nasprotno geokodiranje | pohitritev funkcije ST_Intersects, predpomnjenje rezultatov, kopičenje zahtev |
usmerjanje | iz zbirke vzamemo ceste večjega območja, projekt pgRouting |
vsi deli | spletne storitve, TLS/SSL komunikacija |
Tabela 10.1: Možne izboljšave delov sistema v nadaljnjem delu.
Geografski informacijski sistem bi lahko obogatili tudi tako, da bi mu, poleg novih domen v podatkovnem modelu, dodali še kakšno orodje. Eno izmed njih je, na primer, storitev interesantnih točk (angl. Points of Interest - POI), ki bi lahko vsebovala lastne privatne uporabnikove točke ali pa javne zanimivosti (npr. črpalke za gorivo, moteli, restavracije, parki ipd.). Tukaj bi bil še posebej zanimiv del varnosti podatkov pri privatnih točkah, saj bi morali zagotoviti, da so določene interesantne točke na voljo samo določenim uporabnikom.
Uporabnikom bi lahko geografske podatke prikazali v obliki zemljevidov v grafičnem vmesniku (na spletnih straneh ali v namizni aplikaciji). Upodabljanje podatkov bi lahko, na primer, prepustili strežniku GeoServer, ki vse to že zna in se pri tem drži lepega nabora standardov.