REKONSTRUKCIJA IN VIZUALIZACIJA POLETOV · PDF fileuniverza v mariboru fakulteta za elektrotehniko, ra ČunalniŠtvo in informatiko simon irman čnik rekonstrukcija in vizualizacija

UNIVERZA V MARIBORU

FAKULTETA ZA ELEKTROTEHNIKO,

RAČUNALNIŠTVO IN INFORMATIKO

Simon Irmančnik

REKONSTRUKCIJA IN

VIZUALIZACIJA POLETOV LETAL

IN JADRALCEV

Diplomska naloga

Maribor, november 2010

Diplomska naloga univerzitetnega študijskega programa

REKONSTRUKCIJA IN

VIZUALIZACIJA POLETOV LETAL

IN JADRALCEV

Študent:

Študijski program:

Smer:

Mentor:

Somentor:

Simon IRMANČNIK

univerzitetni, Računalništvo in informatika

Programska oprema

prof. dr. Nikola GUID

doc. dr. Damjan STRNAD

Maribor, november 2010

i

ZAHVALA

Zahvaljujem se svojemu mentorju, prof. dr.

Nikoli Guidu, in svojemu somentorju, doc. dr.

Damjanu Strnadu, za pomoč in vodenje pri

opravljanju diplomske naloge. Prav tako se

zahvaljujem podjetju Naviter d.o.o. in vsem

zaposlenim za pomoč in omogočitev izdelave

diplomske naloge.

Posebna hvala velja mami, ki mi je omogočila

študij in me skupaj z vsemi bližnjimi podpirala

skozi celotno obdobje.

ii

REKONSTRUKCIJA IN VIZUALIZACIJA

POLETOV LETAL IN JADRALCEV

Ključne besede: rekonstrukcija, projekcija, genetski algoritem, prikaz, polet,

vektorski podatki

UDK: 004.92(043.2)

Povzetek

Cilj diplomske naloge je narediti realistično in efektivno predstavitev leta jadralnih

in drugih letal, konstruiranega iz diskretnih podatkov, ki jih beležijo letala sama. Ključni

elementi diplome bodo procesiranje podatkov, rekonstrukcija leta in vizualizacija. Vsi

podatki o letu se shranjujejo v zakodirano datoteko, ki jo je potrebno dekodirati, let pa

rekonstruirati, da dobimo dejanske podatke. Zaradi velikih časovnih intervalov predstavlja

rekonstrukcija velik problem pri vizualizaciji poleta. Ker je nabor točk diskreten, je težko

interpolirati verodostojno krivuljo poleta, še posebno, če letalo kroži. V diplomskem delu

uporabljamo interpolacijo in druge metode za rekonstrukcijo kredibilne krivulje poleta iz

diskretnega nabora točk. Nazadnje dekodirane podatke in rekonstruirane krivulje poleta

prikažemo na zaslonu.

iii

RECONSTRUCTION AND VISUALIZATION OF

FLIGHTS AND GLIDERS

Ključne besede: reconstruction, projection, genetic algorithm, visualization, flight,

vector data

UDK: 004.92(043.2)

Abstract

The goal of this thesis is to make a realistic and effective flight visualisation of

glider planes from the discrete data, which is being recorded by the planes itselves. The

key elements of this thesis are data processing, flight reconstruction and visualization. All

flight data is being saved into an encoded file, which needs to be parsed and reconstructed

in order to receive actual data. Due to frequent wide timeframes, flight reconstrution

represents a major problem in visualising a flight. Because of the discrete point sets, it is

hard to interpolate a credible flight curve, especially if the plane is circling. This thesis will

focus on interpolations and other methods in order to reconstruct a credible flight curve out

of a discrete set of points. Finally, the decoded data and the reconstructed flight curves and

patterns will be projected on screen.

iv

VSEBINA

1 Uvod ................................................................................................................................... 1

1.1 Opredelitev problema .................................................................................................. 1

1.2 Cilji in teze .................................................................................................................. 2

1.3 Predpostavke in omejitve ............................................................................................ 3

1.4 Predvidene metode dela ............................................................................................... 4

1.5 Struktura diplomskega dela ......................................................................................... 5

2 Pregled stanja .................................................................................................................... 7

3 Razvojno okolje .............................................................................................................. 13

3.1 Arhitektura ................................................................................................................. 14

3.2 Razširljivost ............................................................................................................... 18

3.3 Hitrost razvijanja ....................................................................................................... 19

3.4 Meta programiranje ................................................................................................... 19

3.5 Napredno objektno orientirano programiranje .......................................................... 20

3.6 Prenosljivost .............................................................................................................. 21

4 Zapis podatkov ................................................................................................................ 23

4.1 Podatkovne vrstice ..................................................................................................... 23

4.2 Obvezni elementi in praktični primer ........................................................................ 25

4.3 Pretvorba in posebnosti ............................................................................................. 27

5 Rekonstrukcija ................................................................................................................ 30

5.1 Fizikalni model letenja .............................................................................................. 31

5.2 Metode reševanja ....................................................................................................... 33

5.3 Metoda krožnih lokov ................................................................................................ 34

5.4 Interpolacija ............................................................................................................... 37

5.5 Genetski algoritem ..................................................................................................... 38

5.5.1 Predstavitev rešitve ............................................................................................. 39

v

5.5.2 Funkcija uspešnosti ............................................................................................ 40

5.5.3 Genetski operatorji ............................................................................................. 44

5.5.4 Inicializacija........................................................................................................ 46

5.5.5 Metoda minimalnega obsegajočega pravokotnika ............................................. 48

5.5.6 Konveksna lupina ............................................................................................... 51

5.5.7 Brentova metoda ................................................................................................. 52

5.5.8 Generiranje kroženja........................................................................................... 55

5.5.9 Zagon genetskega algoritma ............................................................................... 55

5.5.10 Pristop »Deli in vladaj« .................................................................................... 62

6 Vizualizacija .................................................................................................................... 64

6.1 Projekcija ................................................................................................................... 64

6.2 Transformacija ........................................................................................................... 66

6.3 Izris ............................................................................................................................ 68

7 Sklep ................................................................................................................................. 69

8 Priloge .............................................................................................................................. 70

8.1 Viri ............................................................................................................................. 70

vi

KAZALO SLIK

SLIKA 1: PRIKAZ PODATKOV OSM Z ORODJEM MAPNIK ............................................................................................... 11

SLIKA 2: PRIKAZ PODATKOV OSM Z ORODJEM OSMARENDER ....................................................................................... 12

SLIKA 3: STRUKTURA OGRODJA .NET 2.0.................................................................................................................. 15

SLIKA 4: PRIKAZ LETA V RAVNINI XY .......................................................................................................................... 32

SLIKA 5: VETROVNI TRIKOTNIK ................................................................................................................................ 33

SLIKA 6: PREDPOSTAVKE PRI METODI KROŽNIH LOKOV ................................................................................................. 34

SLIKA 7: DEMONSTRACIJA REKONSTRUKCIJE S KROŽNIMI LOKI ....................................................................................... 36

SLIKA 8: REŠITEV KROŽENJA Z METODO OSTRIH KROŽNIH LOKOV .................................................................................... 37

SLIKA 9: PRIMER SLABEGA KROŽENJA PO FUNKCIJI PRILAGAJANJA ................................................................................... 41

SLIKA 10: PRIMER GENERIRANEGA KROŽENJA Z NAPAČNIM VRSTNIM REDOM .................................................................... 43

SLIKA 11: DEFINIRANJE SMERI VEKTORJA VETRA ......................................................................................................... 47

SLIKA 12: DEFINIRANJE CENTRA KROŽNICE S PROJEKCIJO VHODNIH TOČK NA PREMICO, PRAVOKOTNO NA SMER GIBANJA ........... 48

SLIKA 13: PRIKAZ ROTIRAJOČIH KALIPROV ZA IZRAČUN MINIMALNEGA OBSEGAJOČEGA PRAVOKOTNIKA .................................. 49

SLIKA 14: PRIMER KONVEKSNE LUPINE...................................................................................................................... 51

SLIKA 15: ROTACIJA KOORDINATNEGA SISTEMA IN PROJEKCIJA TOČK NA ABSCISO .............................................................. 57

SLIKA 16: REKONSTRUKCIJA - TESTNI PRIMEREK .......................................................................................................... 59

SLIKA 17: REKONSTRUKCIJA – PRIMER NAPAČNE REŠITVE TESTNEGA PRIMERKA ................................................................. 60

SLIKA 18: REKONSTRUKCIJA: PRIMER DOBRE REŠITVE TESTNEGA PRIMERKA ...................................................................... 60

SLIKA 19: PRIMER REALNEGA KROŽENJA Z VISOKIM ČASOVNIM INTERVALOM .................................................................... 61

SLIKA 20: PRIMER REŠITEVE REALNEGA PROBLEMA ...................................................................................................... 62

SLIKA 21: PROJEKCIJA SVETA .................................................................................................................................. 65

SLIKA 22: PRIMER MERCATORJEVE PROJEKCIJE ........................................................................................................... 67

SLIKA 23: VIZUALIZACIJA LETA ................................................................................................................................. 68

vii

KAZALO TABEL

TABELA 1: STRUKTURA VRSTICE B ............................................................................................................................ 24

TABELA 2: STRUKTURA VRSTICE I ............................................................................................................................. 25

KAZALO PROGRAMSKE KODE

PROGRAMSKA KODA 1: RAZŠIRITVE V OGRODJU .NET ................................................................................................. 18

PROGRAMSKA KODA 2: METAPROGRAMIRANJE V OGRODJU .NET ................................................................................. 20

PROGRAMSKA KODA 3: PRIMER ZAPISA LETA V FORMATU IGC ....................................................................................... 26

PROGRAMSKA KODA 4: EVOLUCIJSKI ALGORITEM ........................................................................................................ 39

PROGRAMSKA KODA 5: PSEVDOKOD BRENTOVE METODE ............................................................................................. 54

PROGRAMSKA KODA 6: PSEVDOKOD REKONSTRUKCIJSKEGA ALGORITMA ......................................................................... 58

viii

UPORABLJENE KRATICE

GPS (Global Positioning System),

IGC (International Gliding Commission),

XML (Extended Markup Language),

RAD (Rapid Application Development),

OSM (Open Street Map),

NASA (National Aeronautics and Space Administration),

COM (Component Object Model),

CTS (Common Type System),

IL (Intermediate Language),

UTC (coordinated universal time),

MBR (Minimum Bounding Rectangle),

HTTP, ZIP

Rekonstrukcija in vizualizacija poletov letal in jadralcev 1

1 Uvod

Jadralni piloti in padalci se pri letenju srečujejo s svojevrstnimi problemi. Njihov

način letenja se razlikuje od letenja motornih letal in drugih, saj kot vir energije

uporabljajo skoraj izključno termodinamiko, so bolj gibčni in precej bolj nepredvidljivi. V

zrak poletijo s pomočjo motornega letala, nato pa so povsem odvisni od naravnih virov. Za

njihovo dviganje je tako kritično, da najdejo potencialne termične stebre, tako imenovane

termične žepe, kjer se giblje toplejši zrak. Tam zavzamejo za njih značilno gibanje

kroženja.

1.1 Opredelitev problema

Vsako jadralno letalo je dandanes opremljeno s sodobnim GPS-sprejemnikom in

napravo, ki omogoča prestrezanje in analizo prejetih podatkov. S tem se lahko beleži

lokacija leta, ki je tako natančna, da je lahko kasneje uporabljena v zapisu celotnega leta.

Pri beleženju moramo upoštevati dejstvo, da čas postane striktno diskreten z relativno

določenim časovnim intervalom, ki dovoljuje tudi odstopanja.

Problem se pokaže pri starih GPS-sprejemnikih, kjer ni največja pomanjkljivost

natančnost, temveč časovni interval med posameznimi časovnimi rezinami, ko dobivamo

podatke. Pri časovnem intervalu, dolgem do 4 sekunde, je mogoče relativno enostavno

razbrati in procesirati podatke na tak način, da je končni produkt jasno viden potek

preletenega leta. Za intervale, večje od omenjenega, pa se problematičnost stopnjuje

eksponentno, saj pri letu večinoma ne gre zgolj za premočrtno gibanje, ki smo ga vajeni od

večjih letal, temveč se velikokrat pojavi krožno gibanje, ki se ga v kasnejšem procesiranju

podatkov ne da enostavno predstaviti kot nabor daljic med zapisanimi GPS-koordinatami.

V dovolj neugodnih primerih ni dovolj niti interpolacija med zabeleženimi točkami. Ker

številni aeroklubi, ki v večini primerov skrbijo za opremo letalstva, dostikrat uporabljajo

staro opremo, je ta problem še vedno aktualen.

Podatki so navadno spravljeni po dogovorjenem standardu mednarodne jadralne

komisije (International Gliding Commission, v nadaljevanju krajše IGC), ki pa je za

človeka v nasprotju z zapisoma JSON in XML le delno berljiv in ga je treba procesirati


posebej. Hkrati je potrebno odpraviti napake, kot so anomalije v točkah, datumski

preskoki, časovna usklajenost in posledice šibkega standarda, vidne v dostikrat nejasnih

podatkih.

Naposled je za jadralne pilote najbolj zanimiva končna obdelava, analiza in prikaz

podatkov. Tu se srečamo s problematiko lokalizacije terena, saj same točke ne pomenijo

ničesar, če ne vidimo terena, nad katerim je bil izvršen let. Prav tako se vedno postavlja

vprašanje projekcije terena, ukrivljanje terenskih poslikav, mnogokotnikov in točk,

računanje lokacije, dolžine, zračne hitrosti in hitrosti na zemlji. Vse to je seveda odvisno

tudi od postavitve modela površja, o katerem se stroka še dandanes ne more zediniti, saj na

tem temelji večina računanja.

1.2 Cilji in teze

Cilj diplomske naloge je sistematično reševanje opisanih problemov v srednje

dolgem časovnem razponu in z omejenimi sredstvi. Ker gre za problematike, ki se rešujejo

v poslovni sferi, so rešitve praktične narave, ki se jih na določeni točki preneha

izboljševati, ko dosežejo svoj namen – zadostiti pričakovanju nalogodajalca, posledično pa

tudi koristnikov oziroma odjemalcev.

Cilj je predstaviti uspešno procesiranje vhodnih podatkov, ki so bili po standardu

IGC zabeleženi na letu jadralnih letal in padalcev, jih ustrezno procesirati in odpraviti

napake.

Cilj je prav tako rekonstruirati popačene podatke, ko je časovni interval prevelik in

bi z izvornimi podatki dobili popačeno sliko ter s tem zgolj namig o tem, kje in kako je let

potekal. To je še posebej pomembno pri letih, pri katerih se je dogajalo kroženje z visokim

časovnim intervalom beleženja vhodnih GPS-podatkov, kjer na koncu na mesto jasnega

krožnega gibanja dobimo nerazumljive in nerazpoznavne odrezave krivulje, ki ne odražajo

karakteristike gibanja v zraku. Zastavljeni cilj mora biti, da se po rekonstrukciji utegne

razbrati, kje približno je opazovani subjekt letel, kakšne so bile takrat karakteristike leta in,

če le možno, kakšna je bila krivulja letenja.

Po procesiranju in rekonstrukciji leta so na voljo še vedno zgolj točke v prostoru in

času – cilj je približati predstavitev leta jadralnemu pilotu, da bo zanj še posebej zanimivo.


To vključuje preračunavanja hitrosti, postavljanja točk, daljic in mnogokotnikov v prostor

v skladu z izbrano projekcijo.

1.3 Predpostavke in omejitve

Pri procesiranju podatkov je edina omejitev sam vir, ki pa ne predstavlja večjega

problema, saj so jadralci in padalci po svetu ustvarili veliko skupnost, ki med sabo deli

bogate izkušnje, h katerim spadajo tudi leti. Na spletu je tako na voljo ogromna baza letov,

saj je za pilote značilno, da si radi ogledujejo tudi tuje lete.

Predpostavljati moramo, da procesiran let vsebuje napake. To se rado zgodi pri

letih, ki so bili zapisani s starejšimi GPS-napravami, kjer je bila pogostost anomalije v

zapisanih točkah bistveno večja. To je potrebno upoštevati pred analizo leta, saj utegne

zanemarjena anomalija povsem popačiti končne rezultate, ki dostikrat niso popolnoma nič

robustni in jih že manjša odstopanja porušijo.

Glavnega problema, na katerega se bo diplomsko delo osredotočilo, se lotimo s

sledečo pomembno predpostavko: kroženje je konstantno. Kaj to pomeni, bomo razložili v

nadaljevanju, ko se bomo lotili fizičnega modela kroženja, za zdaj pa lahko omenimo, da je

idealno kroženje predstavljeno s konstantno kotno hitrostjo, zamaknjeno gibanje, ki

spominja na vijačnico ali vzmet, pa je posledica komponente vetra, ki konstantno gibanje v

krogu vektorsko zamakne v smeri vetra. Smer vetra je prav tako neznanka v enačbi, ki jo je

potrebno izračunati ali predvideti, torej smo omejeni z zgolj oceno komponente vetra, ne

pa tudi z dejanskimi podatki.

Predpostaviti je treba, da je rekonstrukcija težek problem in vsak primerek

predstavlja svojo specifično problematiko, za katero ni nujno, da je rešljiva. Zato bo

potreben lasten fizikalni model, ki bo generiral umetna kroženja, ki bodo nato predmet

obravnave pri uravnavanju rekonstrukcijskih algoritmov. Le-ti bodo nato po uspešnih

testiranjih prestavljeni na dejanske vzorce iz realnega življenja.

Omejeni smo z virom informacij o terenskih razmerah, nad katerimi je bil let

izvršen. Ne poznamo vremena, niti vetra. Vemo sicer lokacijo in točno pozicijo v vsakem

diskretnem trenutku leta, a moramo to tudi funkcionalno vizualizirati, pri čemer je

omejitev ravno ta vir informacij, od koder bi naj črpali. Natančni in kvalitetni viri so po


navadi dragi in redki, oba faktorja pa sta za komercialno rešitev pomembna. Dobre rastrske

karte niso dovolj dobra rešitev za pilote, ki se orientirajo po zelo specifičnih elementih na

zemljevidu – poleg lepljenja satelitskih slik na površje bo zagotovo potrebno razmisliti tudi

o vektorskih kartah, ki vsebujejo podatke v naborih mnogokotnikov, točk in relacij.

Količina tovrstnih vektorskih podatkov je ogromna. Z večanjem natančnosti in števila

raznovrstnih elementov v kartah se bistveno poveča sama velikost podatkov. Potrebno bo

ustrezno ravnanje s to količino, redukcija podatkov, redukcija na ravni samih poligonov ter

filtriranje glede na čas izrisa, saj si po vsej verjetnosti ne bomo želeli izrisati vseh

elementov ob vsakem trenutku in na vsaki dani višini.

V kolikor bomo operirali z velikimi datotekami, bo potrebno optimizirati tudi

mehanizme dostopanja do njih, hkrati pa optimizirati mehanizme branja zahtevanih

formatov. Ob ogromnih datotekah bo predvidoma treba razmisliti tudi o stiskanju z

namenom varčevanja virov.

Nazadnje je potrebno predvideti tudi, da gre za zelo širok spekter uporabnikov, ki

uporablja različne operacijske sisteme. Omejitev je zagotovo tudi prenosljivost, ki sicer ni

pogoj, je pa zagotovo eden izmed faktorjev, ki ga je potrebno upoštevati pri izbiri

razvijalnega okolja. Navsezadnje je to področje potencialno zanimivo tudi za vse

kompaktne naprave, kjer bi katera izmed nakazanih rešitev bila nadvse sprejemljiva.

1.4 Predvidene metode dela

Ker je za eno izmed omejitev postavljen čas razvoja, je potrebno izbrati

programsko razvojno okolje, ki omogoča tako imenovani RAD (rapid application

development), je hitro priučljivo (v kolikor bi končni produkt uporabljal kdo drug, ki ni

vešč izbranemu programskemu jeziku), lahko razumljivo, omogoča vrsto razširitev in

priključitev ter je, če je le mogoče, prenosljivo.

Za razvijalno okolje smo zato uporabili Visual Studio 2008 z ogrodjem .NET (.NET

Framework), kot programski jezik pa C#. Glavni razlogi za to so:

• hitrost razvoja,

• enostavnost in berljivost kode,


• prenosljivost,

• razširljivost.

Hitrost razvoja je mogoče upravičiti z relativno hitrim prehodom iz družine C-

jezikov in jezikov z notacijo C, ki velja za najbolj razširjeno. S prihodom ogrodja .NET se

propagira tako imenovana kamelja (CamelCase) notacija, ki omogoča bolj jasno in manj

dvoumno interpretacijo programske kode, hkrati pa se poslavlja t.i. madžarska notacija, ki

je bila značilna za zgodnje C in C++ začetke ter dandanes še vedno najde privržence, a je

za branje precej težja.

Za rekonstrukcijo podatkov je potrebna inovativnost, saj navadna interpolacija ne

zadosti vsem problemskim nišam. Preučitev različnih pristopnih strategij (tako imenovani

»od spodaj navzgor« (bottom-up) in »od zgoraj navzdol« (top-down) je obvezna, čeprav so

najbolj uporabne prav slednje. Med drugim so med njimi prirejene interpolacije, genetski

algoritmi in rekurzivni algoritmi tipa »deli in vladaj« ter različni drugi aritmetični

algoritmi.

1.5 Struktura diplomskega dela

V diplomskem delu bomo v prvem delu naredili pregled stanja. Pogledali si bomo

obstoječe rešitve, na hitro pretehtali njihovo uporabnost in zahtevnost za uporabo oziroma

nadgradnjo. Osredotočili se bomo na grafične algoritme, projekcijske sisteme,

rekonstrukcijske in genetske algoritme. Preučili bomo interpolacijo in druge postopke za

rekonstruiranje poti, opisane z diskretnim naborom točk. Dotaknili se bomo tudi

kartografskih projekcij, s pomočjo katerih bomo predstavili zabeležen let. Podrobno bomo

spoznali princip lokalizacije GPS, njegovo uporabo in merske karakteristike, ki nam bodo

pri rekonstrukciji podatkov izdatno pomagale. Ogledali si bomo tudi možnosti prikaza

terena ob vizualizaciji samega leta. Pri tem se bomo osredotočili predvsem na podatke s

strani Google Maps in Open Street Maps.

V nadaljevanju bomo preučili razvojno okolje, za katerega smo se odločili. Navedli

bomo zahteve in pretehtali razloge za odločitev. Prikazali bomo samo strukturo razvojnega

okolja, pokazali, zakaj je za nas pomembna, in prikazali smernice razvoja, kakršnega si s


izbranim naborom orodij želimo. Pogledali si bomo tudi prenosljivost aplikacij, hitrost

izvajanja in moderne principe objektno orientiranega programiranja.

Sledil bo pregled implementacije zastavljenih ciljev. Prikazali bomo procesiranje

podatkov, preučili standard IGC, ki definira format, v katerem je zapisanih večina letov

jadralnih letal in padalcev. Podrobno bomo spoznali strukturo formata in pokazali

implementacijo tovrstnega razčlenjevalnika, skupaj s praktičnim primerom vhodne

datoteke. Opozorili bomo na posebnosti, na katere moramo paziti, in definirali anomalije,

ki jih je v rekonstrukciji potrebno odpraviti.

Rekonstruiranje je razdeljeno na tri dele. V prvem bomo obravnavali lokacijske

anomalije, ki so posledica napake pri zapisovanju naprav GPS. V drugem delu bomo

reševali časovne anomalije, katerih izvor ravno tako leži v napačnem zapisovanju

podatkov. Tretji del, kjer se bomo lotili prevelikih časovnih intervalov, bomo zaradi

obsežnosti problema obravnavali bolj temeljito.

Za dobro razumevanje problema bomo definirali fizikalni model letenja, ki nam bo

pri rekonstruiranju izdatno pomagal. Preučili bomo dva različna pristopa reševanja

problemov in za vsakega izmed njiju podali implementacijo rešitve. Prikazali bomo

metodo krožnih lokov, ki sledi principu reševanja »od spodaj navzgor«. Podrobneje si

bomo pogledali interpolacijo kot eno izmed rešitev »od zgoraj navzdol«. Ob koncu bomo

prikazali še rešitev z genetskimi algoritmi. Prikazali bomo vse segmente evolucijskega

programiranja – funkcijo uspešnosti in kazenske funkcije, definirali genetske operatorje,

prikazali postopek iskanja začetnih približkov rešitev ali zasilne rešitve, ob tem pa

spoznavali različne algoritme, ki jih bomo na tej poti potrebovali. K temu spadajo metoda

minimalnega obsegajočega pravokotnika, iskanje konveksne lupine, Brentova

optimizacijska metoda in pristop »deli in vladaj«.

Na koncu bomo pregledali rezultate in naredili analizo. Predstavili bomo hitrost in

uspešnost uporabljenih algoritmov, hkrati pa kritično označili pomanjkljivosti. Naredili

bomo primerjavo z obstoječimi rešitvami in predstavili možne izboljšave ter zastavili

smernice za morebitni nadaljnji razvoj.

Končali bomo z navedenimi viri in priloženo izvorno kodo implementacije opisanih rešitev.


2 Pregled stanja

Preden se lotimo problema, velja narediti hitro analizo obstoječih rešitev, ki

zadostujejo našim potrebam, ne kršijo naših predpostavk in omejitev ter so trenutno na

voljo. Pri analizi trenutnega stanja pravzaprav iščemo rešitve na področju grafičnih

algoritmov, projekcijskih sistemov, predvsem pa tudi hitrostnih mehanizmov, nastavkih in

tehnikah hitrega procesiranja podatkov ter končno tudi na področju povratnih informacij

uporabnikov, ki se v glavnem ukvarjajo s končnimi aplikacijami.

Pri samemu procesiranju podatkov se je potrebno zanesti na lastne rezultate, saj

bodo pripravljene za posebno nišo uporabnikov, ki jim je morda važen samo posamezni

aspekt predstavljenega rezultata, kjer nam morebitne obstoječe rešitve ne morejo prav dosti

pomagati.

Podobno velja za rekonstrukcijo podatkov, pri čemer pa se je kljub temu vredno

opreti na določene obstoječe rešitve. Kot smo opisali, je vhodni podatek diskretno opisana

pot jadralnega letala ali padalca, kjer posamezna točka pomeni koordinato v

geopozicijskem sistemu. Če govorimo o koordinatah točke, mislimo na komponento x in y

oziroma longitudo in latitudo, medtem ko koordinato z oziroma višinski podatek

izpustimo. To storimo zaradi več razlogov, četudi je primarni ta, da tega podatka

pravzaprav ne potrebujemo. Če se vrnemo na opis problema, ki pravi, da nas pri

rekonstrukciji ovira izrazita diskretnost časa, ugotovimo, da velika razlika dveh sosednjih

vrednosti v večini primerov velja predvsem za koordinate x in y, ne pa tudi za višinske

podatke. Kot smo že povedali, se letalo ob dviganju povzpne v tako imenovani zračni žep

toplega predela zraka. V tem predelu kroži, dviganje pa poteka počasi – tako počasi, da je

razlika sosednjih koordinat z zanemarljiva v primerjavi s podatki v 2D projekciji. Zato

lahko pri rekonstrukciji tretjo dimenzijo zanemarimo. To pa seveda ne velja za prikaz,

zlasti če hočemo pripraviti vse nastavke za morebitno tridimenzionalno vizualizacijo leta

nad tlemi.

Pri odločitvi o zanemarjanju tretje komponente točke v prostoru nam izdatno

pomaga dejstvo o natančnosti starejših naprav GPS pri višinskih podatkih. Ta je precej

slaba, saj je še v začetku tisočletja za najnovejše naprave relativna napaka znašala 15

metrov. Ker si želimo zaobjeti tako novejše kakor tudi starejše posnetke letov, moramo to

dejstvo upoštevati. Toda zakaj pride do takšne napake?


Poglejmo si GPS (Global Positioning System) sistem. Kot že ime namiguje, gre za

satelitski navigacijski sistem, ki se uporablja za lokalizacijo (geopositioning) objektov na

površini zemlje. Zasnovalo ga je ameriško obrambno ministrstvo, tako da je sprva bilo

namenjeno zgolj v vojaške namene, a se je zavoljo dobre zasnove in seveda z zeleno lučjo

lastnikov začel uporabljati tudi v komercialnih vodah. Dobra zasnova se navezuje

predvsem na sam sistem lokalizacije, ki deluje na zelo enostaven način in ne potrebuje

posebno kompliciranih ali dragih komponent v posameznih sprejemnikih.

V vsakem trenutku kroži okoli zemlje 30 satelitov na oddaljenosti približno 20 tisoč

kilometrov. Vsak izmed njih je opremljen z atomsko uro, ta pa je kritična za samo

lokalizacijo sprejemnika. Iz imena je razvidno, da imamo v sprejemnikih GPS samo

sprejemnik signala, torej lahko dobivamo le paketke, ki jih ves čas pošiljajo sateliti. V

posameznem paketku so shranjene štiri informacije: čas oddaje paketa in satelitove

koordinate x, y in z. Ko sprejemnik GPS dobi te pakete, mora preračunati, kolikšen je

zamik med trenutnim in oddajnim časom satelita. Preko tega lahko nato določi, kakšna je

oddaljenost sprejemnika od satelita - signal namreč potuje s svetlobno hitrostjo, a ima

vendarle nezanemarljivo majhen zamik. Pozicijo sprejemnika GPS lahko približno

določimo (predpostavimo, da je nekje na zemeljski obli), zato bi v idealnem primeru bilo

dovolj, da dobimo signale iz treh satelitov, seveda pod pogojem, da je v našem

sprejemniku GPS atomska ura. Tega pa v večini primerov ni, zato potrebujemo dodatni

četrti satelit, ki popravi uro. Natančen čas je izrazito pomemben - zaradi relativnostne

teorije je občasno potrebno popraviti celo atomske ure na satelitu, saj le-te tečejo 38 µs

hitreje od tistih, ki se nahajajo na površju Zemlje.

Ker se podatki o položaju računajo iz ločenih komponent, dostikrat pride do napak.

Te napake so posledično radikalne narave. Ali je podatek relativno točen – torej je točen z

določeno toleranco odstopanja – ali pa je napaka tako radikalna, da pride do odstopanja

več 100 metrov ali še več.

Naslednji izmed razlogov, zakaj višinske podatke zanemarjamo, leži v hitrosti

samih algoritmov. Želimo si učinkovit, hiter in robusten algoritem. Hitrost se bistveno

poveča, ko zanemarimo eno izmed treh komponent, pri čemer je cena pogreška

zadovoljivo nizka. Robustnost pa se toliko bolj poveča, če lahko zanemarimo najbolj

občutljivo komponento v obliki višinskih podatkov.


Medtem ko se še vedno lahko pogodimo s tovrstno magnitudo merske napake

ameriškega pozicijskega sistema, je potrebno kljub vsemu preveriti alternativne storitve, ki

jih ponujajo drugod. Obstajata evropski in rusko-indijski ekvivalent, GALILEO in

GLONASS, a oba v tem trenutku še zaostajata za vzorčnim sistemom, četudi bosta v

prihodnosti zagotovo predstavljali resno alternativo.

Vrnimo se k rekonstrukciji. Diskretne poti ne moremo enostavno opisati same po

sebi, saj bi potencialno animacija zabeležene poti prinesla zgolj preskoke, ki bi bili

neestetski in v določenih primerih, ki se jih bomo lotevali kasneje, ne bi predstavljali

poteka leta, kakršen je bil v resnici. Tu se v začetku in pri trivialnih primerih najlažje

opremo na obstoječe algoritme in vsem dobro znano interpolacijo, ki izrazito diskretno pot

dopolni tako, da vstavi interpolirane vmesne točke med dvema diskretnima oziroma

sosednjima trenutkoma (točkama) v času. Še vedno gre za diskretno pot, navsezadnje bi

analitičen opis poti letala zahteval kompleksne izračune brez posebne praktične prednosti.

Vendar dobimo lep, na videz gladek opis poti, ki si jo želimo predstaviti.

Število obstoječih rešitev se na žalost drastično zmanjša, ko preidemo h

kompleksnejšim primerom, ki jih želimo rešiti. Ko hočemo opisati kroženje, včasih niti ne

vemo, da gre za dejansko kroženje, saj imamo za vhodne podatke diskreten nabor točk.

Kompleksen primer za nas pomeni izrazito velik časovni interval, navadno nad 10 sekund,

kar je značilno predvsem za stare naprave GPS, ter seveda kroženje. V tem primeru

dobimo nelogično in nerazumljivo postavljene točke, iz katerih moramo nato predvideti,

ali gre za kakšno posebno manevriranje, morebiti za kakšno anomalijo v delovanju naprave

GPS (tega zagotovo ne gre zanemariti), ali pa dejansko let predstavlja kroženje. Tu seveda

interpolacija ne pride v poštev, saj bi jo lahko uporabili predvsem v primerih, ko lahko

intuitivno sklepamo o vmesnih odsekih preletene poti. Tu bo potrebno uporabiti

kombinacijo inovativnih in manjši izbor že obstoječih rešitev.

Čisto mogoče je namreč, da letalo izvaja sunkovite manevre, ki so ob velikih

časovnih intervalih predstavljene zelo nerazumljivo. Hkrati je treba upoštevati, da so stare

GPS naprave podajale podatke hitreje, kakor so jih brale. Kako je to mogoče? Imejmo čas

T, ki je pretekel med prejšnjim C(n-1) in aktualnim C(n) prejetim podatkom. V času T je

naprava interpolirala podatke, ki pa so zgolj ocena ali približek, v času T pa je namesto


enega podala N podatkov, novi časovni interval pa je postal T/N. Tako je točnost položaja

treba dostikrat jemati z rezervo.

Stanje obstoječih rešitev pri vizualizaciji letov je po drugi strani bistveno boljše.

Sicer se moramo pri samem letu še vedno opreti na posamezne projekcijske tehnike,

vendar si lahko za prikaz terena izdatno pomagamo z že obstoječimi viri terenskih

poslikav, ki jih želimo uporabiti v ozadju prikaza našega leta. Tu pridemo do razpotja med

rastrskimi in vektorskimi mapami. Medtem ko so rastrske karte kolekcija slik oziroma

poslikav terena, vektorske karte predstavljajo skupek vektorskih podatkov, ki jih je šele

potrebno ustrezno obravnavati in narisati, preden za nas postanejo uporabne. Vendar so

ravno vektorski podatki tisti, ki so za nas zanimivi, saj jadranje dostikrat zahteva zelo

specifične informacije o terenu.

Pri pregledu za rastrske rešitve se lahko takoj ustavimo ob najbolj popularnem

ponudniku tovrstnih rešitev, Google Maps. Le-ti za svoje poslikave terena uporabljajo

posnetke, ki jih je zagotovila NASA. So precej natančni, četudi natančnost vsepovsod ni

uniformna – to denimo lahko opazimo pri večjih mestih, kjer je faktor povečave dostikrat

maksimalen, v nasprotju z redkeje poseljenimi predeli, kjer natančna povečava ni na voljo,

a je za nas precej velikega pomena. Dodaten problem nam predstavlja Googlovi pogoji

uporabe, ki nam sicer ne onemogočajo proste in zastonjske rabe njihovih kartografskih

ekstraktov, nam pa prepovedujejo uporabo v komercialni sferi. Za akademske potrebe v

diplomski nalogi bomo podatke lahko kljub vsemu uporabili. Google ima v te namene

pripravljen poseben vmesnik uporabniškega programa oziroma t.i. API (application

programming interface), s katerim lahko preko javascripta njihove storitve koristimo kar v

spletnem brskalniku. Po vsej verjetnosti pa nam to ne bo dovolj in si bomo želeli njihov

API prenesti v našo aplikacijo.

Kot rečeno pa si bolj kot rastrskih želimo vektorske podatke. Tu se opremo na

izjemno močno odprtokodno skupnost, ki upravlja projekt imenovan Open Street Maps.

Gre za »živ« organizem, saj se širi, obnavlja in verificira sam od sebe. Za vnašanje,

popravljanje in brisanje podatkov je namreč odgovorna skupnost sama.

Izris samih podatkov ravno tako že obstaja in je na voljo v več programskih jezikih.

Prvi izmed njih in hkrati najbolj pogost je Mapnik. Za tovrstno dvodimenzionalno

rasterizacijo potrebuje sicer okolje Linux, PostgreSQL in najrazličnejše knjižice C++, tako


da bi bili precej omejeni, v kolikor bi se odločili zanj. Po drugi strani je program hiter in

primeren za strežniške aplikacije, ki pa za nas niso zanimive.

Slika 1: Prikaz podatkov OSM z orodjem Mapnik

Druga alternativa po vrsti je Osmarender. Pri njej gre za transformacijo iz XML v

skalarno vektorsko grafiko oziroma format SVG (Scalable Vector Graphic), ki omogoča

morebitno popravljanje po dejanski transformaciji. To za nas ni posebno uporabno, saj s

takšno transformacijo v bistvu še ne napravimo ničesar, saj nam še vedno ostanejo

vektorski podatki, ki jih je potrebno šele izrisati. Oba načina se uporabljata v spletni

različici Open Street Map.


Slika 2: Prikaz podatkov OSM z orodjem Osmarender

Tretja alternativa se imenuje Kozmus in je plod dela slovenskega avtorja Igorja

Brejca. Ker uporablja za izris knjižice GDI+ ter .NET, je za nas zelo atraktiven, vendar ni

osnovan za hitro ali količinsko obdelavo podatkov. V našem primeru obstoječe rešitve

vendarle ne bodo tako pomembne, saj po eni strani potrebujemo precej specifične podatke,

po drugi pa bo količina le-teh tako majhna, da nam izris vektorsko opisanih poti oziroma

poligonov ne bo predstavljal potrebe po integraciji oziroma posegu po obstoječih rešitvah.


3 Razvojno okolje

Pri izbiri programskega jezika in razvojnega okolja nasploh si moramo ogledati,

kakšne so naše zahteve in katere rešitve temu potencialno ustrezajo.

Za nas so pomembni naslednji faktorji:

• razširljivost,

• hitrost razvijanja,

• meta programiranje,

• možnost naprednih prijemov objektno orientiranega programiranja in

• prenosljivost.

Izbrali smo si C# oziroma ogrodje .NET z razvijalnim okoljem Visual Studio 2008,

ki je bilo v času izvajanja projekta najnovejše integrirano razvojno okolje (integrated

development environment oz. v nadaljevanju krajše IDE) na tržišču. Zanj smo se odločili,

ker pokriva večino, če ne vseh naših zahtev, ki jih do razvijalnega okolja imamo. C# ima

podobno sintakso kakor Java, kakor tudi vrsto drugih značilnosti, ki so nekoč Javo naredile

najbolj obetaven programski jezik na tržišču. Pomemben faktor je povezljivost z različnimi

jeziki. Želimo si, da bi programi, ki so bili napisani izven ogrodja .NET, delovali tudi v

aplikacijah C#, kar je mogoče rešiti s komponentnim objektnim modelom oziroma tako

imenovanimi objekti COM (component object model) in dostopi do njihovih

funkcionalnosti.

Izvajalno okolje splošnih jezikov ali CLR (Common Language Runtime) je na

javanskem principu baziran virtualni stroj, ki skrbi za izvajanje vseh programov .NET. Vse

izvajanje se dogaja pod drobnogledom CLR, ki skrbi tudi za upravljanje s pomnilnikom,

varnost in izjeme, kar nam pri razvijanju izdatno olajša delo. Ogrodje .NET je prav tako

izrazito varen sistem, saj so prekoračitve obsega pomnilniškega vmesnika (buffer

overflows) obravnavane povsem ločeno in ne pustijo skoraj nič prostora za manipulacije

kode.

Neodvisnost jezikov je lastnost ogrodja .NET, pri kateri vsi vsebovani jeziki

uporabljajo skupen tipski sistem (Common Type System) ter razredna knjižnica tipov (Base

Type Library), zaradi česar so navezave med katerimi koli jeziki .NET neproblematični in


pravzaprav precej pogosti, kar sicer za naše aktualne zahteve ni potrebno, je pa vsekakor

dobrodošlo.

Ogrodje .NET je osnovano z idejo o prenosljivosti. Ker se dosti vzorcev izvajanja

kopira iz Jave, je tudi ideja o izvajanju programov .NET na različnih sistemih prioriteta.

Tukaj so snovalci programsko-razvijalnega paketa uvedli vmesni jezik ali IL (intermediate

language), ki se interpretira v zagonskem času. Teoretično je bila prenosljivost med

različnimi platformami zastavljena in predvidena že ob sami zasnovi prvega ogrodja .NET,

četudi Microsoft še do danes – vsaj uradno – ni podal nobenega alternativnega ogrodja

zunaj domene operacijskih sistemov Microsoft Windows. Tudi tu pa se lahko zatečemo k

odprtokodni skupnosti, ki je razvila ogrodje MONO – polno združljiv programski paket, ki

ga je moč pognati tako pod sistemih Linux, kakor tudi na manj razširjenih platformah, kot

so na primer Solaris ali FreeBSD.

Meta programiranje je močan konstrukt, ki se ga v .NET ogrodju lahko

poslužujemo. Četudi je vmesni jezik, v katerega prevedemo program v denimo jeziku C#,

samo-opisujoč, lahko kot programerji ustvarimo lastne metapodatke z uporabo atributov, ki

so povsem nov in moderen konstrukt v programskih jezikih. Atribute lahko uporabljamo

nad razredi, funkcijami ali spremenljivkami in s tem dvignemo opisno moč meta objekta

ali pa celo spremenimo potek izvajanja programa, v kolikor uporabljamo reflektivno

programiranje (reflection).

Kot rečeno, je tudi varnost v ogrodju .NET najvišja prioriteta, to pa hkrati pomeni,

da zaradi tega trpi hitrost izvajanja. Navadno v C# nimamo enakega dostopa do kazalcev,

kakor smo to vajeni v C oziroma C++ [Troelsen, 2007].

3.1 Arhitektura

Za lažji pregled si oglejmo strukturo ogrodja .NET (slika 3), ki opisuje najbolj

razširjeno verzijo, 2.0, na kateri temeljijo vse prihodnje verzije.


Slika 3: Struktura ogrodja .NET 2.0

Nasprotno od navadnega programskega jezika C, kjer so ukazi prevedeni direktno v

zbirni jezik, se izvorna koda vsakega programskega jezika .NET pretvori v vmesni jezik.

Za to je potrebna infrastruktura splošnih jezikov (Common Language Infrastructure ali

CLI), ki omogoča jezikovno-nevtralno podlago za razvoj in izvajanje aplikacij, vključno z

upravljalcem pomnilnika (garbage collector), upravljalcem varnosti in medoperacijsko

povezljivostjo. Te lastnosti ne veljajo izključno za en programski jezik, temveč opisujejo

več jezikov, ki jih ponuja ogrodje .NET. Implementacija te infrastrukture se imenuje

izvajalno okolje splošnih jezikov (common language runtime ali CLR) in je specifična za

Microsoftovo ogrodje .NET. Alternativne implementacije najdemo na drugih sistemih (npr.


ogrodje MONO za operacijske sisteme Linux), ki iz istega nabora programskih jezikov

.NET prevajajo in izvajajo (ali bolje rečeno interpretirajo vmesni jezik). Tu se že kažejo

principi prenosljivosti, ki pa še čaka na razcvet, saj so alternativne implementacije

prepuščene bolj ali manj odprtokodni skupnosti.

Upravljalec pomnilnika, dostikrat poimenovan kot smetar, skrbi za sproščanje

pomnilnika in s tem razbremeni razvijalce pri hitrem razvijanju aplikacij. Iz starejših

programskih jezikov C ali Pascal smo vajeni, da rezervacije in sproščanje pomnilnika

delamo sami, tu pa ogrodje .NET skrbi za to s pomočjo upravljane kopice (managed heap),

območja prostega pomnilnika, ki ga upravlja CLR. Klasično pojmovanje življenjske dobe

spremenljivke se zato spremeni: kolikor dolgo obstaja referenca na opazovani objekt, tako

dolgo bo CLR rezervirani del pomnilnika tudi ohranjal. To velja seveda za upravljano kodo

(managed code), ki ne vključuje prijemov na nižjem nivoju, kot na primer kazalcev. S

prehodom v neupravljano kodo moramo za upravljanje pomnilnika skrbeti sami.

Ogrodje .NET ima vgrajene posebne varnostne mehanizme. Dva tipična testa sta

validacija in verifikacija. Prva preko CLR preverja, ali so metapodatki o IL pravilni,

medtem ko verifikacija preverja zgolj, če napisana koda posega v tako imenovano

»nevarno« območje. Pod to območje štejemo med drugim tudi upravljanje s kazalci. Če

koda ne prestane obeh testov, program ne bo preveden. Prav metapodatki so močan

konstrukt, saj dosežejo, da je programska koda samoopisljiva, kar omogoča lažje reševanje

kompleksnejših problemov v programiranju. Ogrodje .NET prav tako skrbi za prekoračitev

obsega (buffer overflow), izgubo prostora v pomnilniku (out of memory) in podobne

probleme.

Za dostop aplikacij do podatkov skrbi komponenta ADO.NET (ActiveX Data

Object .NET). Predstavlja nabor manjših komponent za dostop in modifikacijo podatkov.

Sestoji iz podatkovne množice (Data Set) in ponudnika podatkov (Data Provider).

Podatkovna množica je (v smislu povezave do podatkovne baze) odklopljena kopija

podatkov v pomnilniku, lahko pa jih rečemo tudi preprosto lokalna kopija. Nad njo se

vršijo spremembe, le-te pa se po končanem sklopu ukazov storijo še nad tako imenovano

centralno podatkovno bazo. Ponudnik podatkov pa je odgovoren za vzpostavitev in

vzdrževanje povezave do podatkovne baze. ADO.NET je posebna izvedba že dolgo

obstoječih modelov ADO, ki pa so iz vidika učinkovitosti in hitrosti že zastarali.


Oddaljen dostop .NET je Microsoftov aplikacijski programski vmesnik (application

programming interface ali API) za medprocesno komunikacijo. Je naslednik tehnologij kot

so objektno povezovanje in vključevanje (object linking and embedding ali OLE). Še danes

zelo aktualen komponentni objektni model (component object model ali COM) pa so

temeljne komunikacije Windows (Windows Communication Foundation ali WCF), njegov

naslednik v ogrodju .NET 3.0. Omogoča povezave med različnimi programskimi jeziki in

oddaljenimi spletnimi aplikacijami.

V naslednjem nivoju sledijo ASP.NET, manjše ogrodje za razvoj spletnih aplikacij

v povezavi z vsemi prednostmi, ki jih ponuja .NET. V istem nivoju najdemo še gradnike

Windows (Windows Forms), grafični API, ki je skupen vsem programskim jezikom .NET.

Gradniki so takšni, kakršne najdemo v operacijskem sistemu Windows in niso prenosljivi

(alternativno implementacijo morajo vsa ogrodja priskrbeti sama). Nazadnje imamo v tem

nivoju še konzolo, ki omogoča programiranje na nižjem nivoju s pomočjo ukazne vrstice.

Razredna knjižnica .NET (base class library) vsebuje tipe razredov, ki so skupni

vsem jezikom .NET. Imenujemo jo lahko tudi knjižnica funkcionalnosti, saj omogoča

hitro in pregledno razvijanje enostavnih in kompleksnih aplikacij. Vsebovani razredi

ponujajo številne splošne in pogoste funkcionalnosti, kot na primer grafično oblikovanje,

dostop do datotek, metaprogramiranje itd.

Sem ne spadajo splošni tipi, ki jih najdemo v sistemu splošnih tipov (common type

system ali CTS). Specifikacija CTS definira vse možne podatkovne tipe in strukture, ki jih

podpira CLR. Definira tudi njihovo interakcijo, obenem pa jih ni mogoče modificirati ali

od njih dedovati. Na podlagi tega je dosežena interakcija med aplikacijami, napisanimi v

različnih jezikih .NET.

Naslednji nivo pa že ponuja specifikacijo vseh programskih jezikov .NET. V

prejšnjih nivojih je bilo definirano že večino podpornih komponent, tu pa so podana vsa

sintaktična in leksikalna pravila, ki označujejo programski jezik. Sem spadajo osnovni

objektno orientirani pojmi, kot so vidnost, sistem tipov in dedovanja, prekrivanje, pravila

poimenovanja, dogodki, izjeme itd. Tu je vsak jezik definiran sam zase, a še vedno

najdemo veliko skupnih točk med jeziki (med drugim tudi C++, C#, Visual Basic, J#) v

ogrodju. V novejših ogrodjih najdemo tudi funkcijski jezik F#, pa tudi grafični opisovalni


jezik WPF, ki temelji na XML notaciji, služi pa kot alternativa poprej omenjenim

gradnikom Windows.

3.2 Razširljivost

Razširljivost je sposobnost prilagajanja aplikacije na prihodnji razvoj. Pri tem

implementacija upošteva prihodnjo rast aplikacije. Ker si želimo, da naša aplikacija ohrani

možnost rasti, moramo to upoštevati tudi pri izbiri razvojnega okolja .NET.

Naše izbrano okolje nam omogoča tudi enostavno dodajanje komponent, ki jih

nismo razvili sami. Dostikrat se namreč zgodi, da v aktualnem razvoju ne moremo

predvideti, katere komponente bodo uporabljene v prihodnosti. V takšnim primerih ima

ogrodje .NET na voljo posebno komponento razširljivosti (AddIn component), s katero

nam ni treba vnaprej poznati podrobne strukture vključevalnega objekta. Poglejmo si

praktičen primer (programska koda 1).

static void Main()

{

// Predvidevamo, da bodo razširitve nameščene v aktualni mapi

String addInRoot = Environment.CurrentDirectory;

// Preverimo namestitev

AddInStore.Rebuild(addInRoot);

// Poiščemo ustrezne razširitve

Collection<AddInToken> tokens =

AddInStore.FindAddIns(typeof(Calculator), addInRoot);

// Sprožimo povpraševanje, katero razširitev naj vzamemo

AddInToken calcToken = ChooseCalculator(tokens);

// Aktiviramo izbrano razširitev z varnostnim nivojem za splet

Calculator calculator =

calcToken.Activate<Calculator>(AddInSecurityLevel.Internet);

// Uporabimo objekt iz razširitve, katerega vmesnik poznamo

RunCalculator(calculator);

}

Programska koda 1: Razširitve v ogrodju .NET

Najprej potrebujemo samo namestitev razširljive komponente. Najlažje jo

namestimo kar v mapi, kjer se bo nahajal naš aktualen program, ki ga želimo razširiti.

Poprej moramo seveda preveriti, ali je razširitev, ki si jo želimo namestiti, bila ustrezno


nameščena. Potem s povpraševanjem po želeni zbirki sprožimo iskanje. Ker se lahko

zgodi, da dobimo več možnih rezultatov kot odgovor na povpraševanje, moramo izbrati

pravega. Šele nato ga lahko aktiviramo, pri čemer podamo ustrezen nivo varnosti. Sedaj je

objekti pripravljen za uporabo.

Naša aplikacija utegne iti po drugi poti, saj se bo zelo verjetno sama vključevala v

druge že obstoječe programe. Z ogrodjem .NET je to mogoče narediti dovolj enostavno.

3.3 Hitrost razvijanja

Hitro razvijanje aplikacij je v današnjem informacijskem razvojnem svetu

izrednega pomena. Je metodologija, ki se osredotoča bolj na razvijanje prototipov in manj

na načrtovanje. Samo načrtovanje pri t.i. aplikacijah RAD je največkrat zajeto kar v samem

pisanju programske kode. Zaradi tega je aplikacija v večini primerov bolj fleksibilna in

dovzetna do potencialnih sprememb.

Te metodologije se bomo deloma posluževali tudi v našem diplomskem delu, pri

čemer pa načrtovanja ne bomo zanemarjali – takšno metodologijo bomo uporabili

predvsem pri samem pisanju kode, ne pa tudi ob raziskovanju.

Hitro razvijanje kode pride v poštev pri morebitnem nadaljnjem razvoju, ki ga bo

naša aplikacija deležna.

3.4 Meta programiranje

Meta programiranje je sinonim za pisanje programov, ki manipulirajo z drugimi

programi ali pa celo sami s seboj. Jezik, v katerem je napisan meta program, se imenuje

metajezik. Po drugi strani pa se jezik manipuliranega programa imenuje objektni jezik.

Sposobnost programskega jezika, da lahko samemu sebi predstavlja metajezik, se imenuje

refleksija (reflection) in je pomemben del ogrodja .NET.

Z refleksijo lahko počnemo veliko več, kot smo bili doslej vajeni. Lahko

generiramo primerke razredov v izvajalnem času (programska koda 2). Lahko prožimo

delegirane metode. Lahko dobimo natančne podatke o strukturi razreda objekta, ne da bi ga


poznali. Predvsem pa lahko dodajamo atribute k objektom, razredom, metodam in drugim

komponentam v ogrodju .NET. S tem povečujemo samoopisljivost naše aplikacije, širimo

njeno uporabnost in povečujemo enostavnost uporabe ter verjetnost, da se bo naša

programska koda v prihodnosti kdaj spet uporabila.

// ustvarimo objekt tipa DateTime

DateTime dateTime =

(DateTime)Activator.CreateInstance(typeof(DateTime));

// ustvarimo objekt tipa DateTime, tokrat s parametri

DateTime dateTime = (DateTime)Activator.CreateInstance(typeof(DateTime),

new object[] {

2008, 7, 4 });

Programska koda 2: Metaprogramiranje v Ogrodju .NET

V našem primeru se bomo posluževali predvsem atributov, ki jih lahko pripišemo

razredom, metodam in drugim elementom. To bomo storili predvsem zaradi hitrega

razvijanja, saj lahko iste funkcionalnosti dosežemo tudi na druge načine.

3.5 Napredno objektno orientirano programiranje

Objektno orientirano programiranje je stara programerska paradigma in del vsakega

kompleksnejšega programskega jezika, s katerim je moč ustvariti aplikacije za širšo rabo.

Ogrodje .NET osnovne pojme, kot so razred, objekt ali dedovanje, seveda realizira. Pri

naprednem objektno orientiranim programiranju pa ne gre toliko za lastnosti programskega

jezika, kakor za vzorce (design patterns), ki jih lahko tvorimo.

V grobem poznamo tri tipe:

• ustvarjalni vzorci,

• strukturni vzorci in

• vzorci obnašanja.

Ustvarjalni vzorci počnejo točno to, kar jim ime veleva – ustvarjajo objekte. Za nas

sta zanimiva predvsem enolični vzorec (singleton pattern) in vzorec proizvajalne metode

(factory method pattern). S pomočjo prvega lahko predstavimo razred, ki ni statičen, na

statičen način. Skrijemo konstruktor in definiramo metodo, ki vrne instanco objekta. Le-to


ustvarimo zgolj enkrat, tako da imamo vedno opravka samo z enim objektom, s čimer se

precej približamo principu statičnega razreda. Pridobimo pa še vse lastnosti navadnega

razreda, med drugim tudi zelo pomembno dedovanje, ki pri statičnih razredih po principih

objektno orientiranega programiranja seveda ni mogoče. Drugi vzorec proizvajalne metode

nam pomaga ustvariti objekt razreda. To je uporabno predvsem, ko uporabljamo vmesnike

namesto razredov – pri prireditvi bo spremenljivka tipa vmesnika dobila instanco razreda,

o katerem nam ne bo treba vedeti ničesar, razen tega, da implementira sam vmesnik. To bo

zelo praktično pri definiciji točke v prostoru, ki bo omogočala nadaljnje dedovanje

(osnovna točka bo imela 2 koordinati, točka v 3D prostoru bo imela še dodatno koordinato,

točka v času pa še časovno itd.).

Strukturni vzorci na enostaven način realizirajo relacije med entitetami. Uporabljajo

se pri maskiranju kompleksnih objektov za enostavnimi vmesniki, grupiranju objektov,

poenostavljanju kompleksnih vmesnikov in še kje. Vzorci obnašanja pa se po drugi strani

uporabljajo predvsem pri poenostavljanju kompleksnih funkcionalnosti. Kot lahko

opažamo, gre pri načrtovalnih vzorcih v glavnem za poenostavitev. Slednjih dveh v

diplomski nalogi ne bomo uporabili [Gamma, Design Patterns].

3.6 Prenosljivost

Lastnost prenosljivosti omogoča vmesni jezik, ki ga ogrodje .NET uporablja. Ta

vmesni jezik je skupen vsem alternativnim implementacijam sličnih ogrodij. Najbolj

razširjena alternativa ta hip je zagotovo ogrodje MONO, ki teče pod okoljem Linux in

omogoča, da lahko programe, napisane in prevedene v okolju Windows, zaženemo

kjerkoli, kjer je MONO tudi nameščen.

Ker si želimo, da našo aplikacijo požene čim več uporabnikov, moramo

programsko kodo pisati tako, da bo združljiva tudi z ogrodjem MONO, četudi jo bomo v

prvi vrsti zaradi hitrosti razvijanja pisali v Visual Studiu .NET pod okoljem Windows.

Združljivost z ogrodjem MONO se morda zdi trivialna, a je treba upoštevati dvoje pravil:

• prepovedano je vključevanje knjižic DLL, specifičnih za okolje Windows in

• držati se je potrebno konstruktov zadnje podprte verzije, to je ogrodje .NET 2.0.


Vključevanje knjižnic iz okolja Windows se lahko zgodi, če hočemo spremeniti vizualne

gradnike. Žal v ogrodju MONO ni veliko poudarka na atraktivnosti vizualnih komponent,

težko pa je prenosljivost narediti že za enostavno lastnost gradnika kot na primer

transparentnost.

Zastran tega so podprte vse kritične komponente, ki jih za nemoteno izvajanje

aplikacije potrebujemo. Zato se moramo držati zgolj podprtih vizualnih gradnikov in sproti

napisano kodo preverjati tudi v okolju Linux [Bornstein, 2004].


4 Zapis podatkov

Standard IGC je format, v katerem je zapisan let jadralnih letal. Gre za datoteko, ki

sestoji iz vrstic znakov, od katerih vsaka vrstica daje nabor informacij za najrazličnejše

stvari, bodisi je to točka v prostoru, informacija o vetru, glasnost motorja ali pa zgolj ime

pilota.

Format je bil sprva razvit s strani skupine zastopnikov IGC, proizvajalcev jadralnih

letal in številnih neodvisnih razvijalcev programske opreme, ki so se ukvarjali zlasti z

analizo poletov. Prvič so format potrdili leta 1995, od takrat pa se vseskozi razvija in

doživlja redne posodobitve. Znan je po vsem svetu, saj se uporablja pri vseh aktivnostih, ki

vključujejo kakršno koli obliko pozicijskega shranjevanja ob jadranju. Pomemben je postal

tudi pri raznih tekmovanjih, kjer ga je promovirala mednarodna jadralska zveza.

4.1 Podatkovne vrstice

Če si pogledamo format, ugotovimo, da za človeka ni enostavno berljiv, četudi

lahko iz njega razberemo vrsto relevantnih podatkov. Sestavljen je iz vrstic, kjer vsaka

pove kakšno informacijo. Če govorimo o vrstici A, govorimo o vrstici, ki se začne na črko

A in neha pri znaku za končanje vrstice (line terminator). Prva črka določa tudi tip

informacije, ki se nahaja v posameznih vrsticah. Poglejmo si jih:

• Vrstica A je vedno na prvem mestu, se pojavi samo enkrat in vsebuje informacije o

proizvajalcu snemalnika leta ter identifikacijo.

• Vrstica B (tabela 1) je za nas najpomembnejša, saj vsebuje informacije o točkah

(programska koda 3). Normalno se pojavlja največkrat v celotni datoteki. Določajo

jo čas, pozicija in dodatni podatki, ki jih določimo preko vrstice I.


Tabela 1: Struktura vrstice B

parameter velikost format opis parametra

čas UTC 6 zlogov HHMMSS veljavni numerični znaki od 0 do 9, pri čemer

HH stoji za uro, MM minuto in SS sekundo

latituda 8 zlogov DDMMmmmN

/S

Veljavni numerični znaki in N ter S, kjer DD

stoji za stopinje [-90°, 90°], MM za minute [0',

60'] in mmm za sekunde [0'', 60'']

longituda 9 zlogov DDDMMmmm

E/W

podobno kot pri Latitudi, a z enim znakom več

za prikaz stopinj [-180°, 180°]

tip točke 1 zlog A or V vsebuje 'A', če vsebuje točka tudi altitudo, sicer

'V'

altituda nad

morsko

gladino

5 zlogov PPPPP nadmorska višina v metrih

altituda

GNSS 5 zlogov GGGGG višina nad WGS84 elipsoidom

• Vrstica C označuje nalogo, ki jo mora letalo opraviti. To se uporablja pri

tekmovanjih, kjer ima letalo točno določene lokacije, ki jih mora preleteti, da

opravi nalogo.

• Vrstica D nam pove, da se uporablja diferencialni GPS, in se lahko pojavi na več

mestih v datoteki IGC, v kolikor uporabljamo več modulov GPS.

• Vrstica E stoji za dogodke (events), ki se med letom dogajajo v neenakomernih

intervalih.

• Vrstica F prikaže konstelacijo satelitov.

• Vrstica G definira varnost s kodiranjem v datoteki IGC.


• Vrstica H vsebuje splošne informacije o poletu (header).

• Vrstica I (tabela 2) je za nas ravno tako pomembna kot B vrstica, služi pa za

razširitev podatkov za omenjeno vrstico (programska koda 3).

Tabela 2: Struktura vrstice I

parameter velikost element opis parametra

število

razširitev 2 zloga NN

veljavni numerični znaki od 0 do 9, stojijo za

število razširitev v B vrstici

začetna

pozicija 2 zloga SS

končna

pozicija 2 zloga FF

3-črkovna

koda

razširitve

3 zlogi CCC alfa-numerični znaki

• Vrstica J deluje podobno kot I vrstica, vendar nudi razširitve za K vrstico.

• Vrstica K se pojavlja manj pogosto kot B in razkriva dodatne informacije preko J

vrstice, osnovana pa je iz časa ter razširitev.

4.2 Obvezni elementi in praktični primer

V datoteki IGC se morajo obvezno pojaviti sledeče vrstice v ravno takšnem

vrstnem redu: A, H, I, B, F in G. Izkušnje kažejo, da včasih dobimo slabo strukturirane

vhodne datoteke, zato se na to ne smemo preveč ozirati. Za nas so pomembne predvsem

točke leta, zato si poglejmo enostaven primer zapisa leta.


ALXN16306FLIGHT:1

HFDTE130706

HFFXA100

HFPLTPILOT:Janez Novak

HFGTYGLIDERTYPE:Ciriss_Std.

HFGIDGLIDERID:YU-4305

HFDTM100DATUM:WGS-1984

HFGPSGPS:JRC/CCA-450,16,max9000m

HFFTYFRTYPE:LXNAVIGATION,COLIBRI

HFRFWFIRMWAREVERSION:3.0

HFRHWHARDWAREVERSION:3.0

HFCIDCOMPETITIONID:05

HFCCLCOMPETITIONCLASS: Open Class

I013638ENL

B0927324520510N02027150EA0004600083488

B0927444520510N02027150EA0004600083496

B0927564520510N02027150EA0004600083472

B0928084520510N02027150EA0004600083464

B0928204520510N02027150EA0004600083488

B0928324520510N02027150EA0004700081472

B0928444520510N02027150EA0004700081488

B0928564520510N02027150EA0004800081488

B0929084520510N02027150EA0004800083496

B0929204520510N02027150EA0004700085496

B0929324520510N02027150EA0004800085488

B0929564520510N02027150EA0004900085472 Programska koda 3: Primer zapisa leta v formatu IGC

Podatki so seveda izmišljeni, gre pa za let Janeza Novaka, ki je letel s Ciriss_Std in

uporabljal napravo Colibri podjetja LxNavigation. Obstaja 12 zapisov njegovih lokacij, pri


čemer se ob vsaki lokaciji (vrstica B) še zapisuje glasnost motorja (ENL) preko razširitve v

vrstici I.

Poglejmo si praktični primer natančneje (programska koda 3). Naš zapis leta se

začne z vrstico A. Ta vrstica vsebuje podatke o zapisovalniku (LXN16306) in dodatne

informacije o letu (FLIGHT:1). Zapisovalniki lahko namreč zapisujejo več letov zapored,

kar pride do izraza pri letalih, ki so v lasti klubov in si jih deli več članov kluba.

Imamo samo eno vrstico A, zato pa je vrstic tipa H bistveno več. Intuitivno si lahko

razlagamo, da H pomeni glavo datoteke (header), vrstice pa nosijo informacije o že poprej

omenjenem Janezu Novaku, tipu letala (YU-4305), geodetskem sistemu (WGS-1984),

zapisovalniku GPS (JRC/CCA-450,16,max9000m) in o morebitnem tekmovanju (Open

Class). Teh vrstic je 12.

V nadaljevanju naletimo na pomembno vrstico I, ki služi kot razširitev vrstice B.

Drugi in tretji znak (01) določata število razširitev – v našem primeru je to ena. Četrti in

peti znak (36) definirata začetno pozicijo razširitve v vrstici B, šesti in sedmi (38) pa

končno pozicijo. Naslednji trije znaki (ENL) nam povedo tip razširitve – v našem primeru

je to glasnost motorja.

Sledijo dejanske lokacije letala v času. Imamo 12 vrstic B, podrobno pa si poglejmo

kar prvo (programska koda 3). Kot smo že zapisali v definiciji strukture, nam vrstica B

najprej poda čas v formatu UTC (coordinated universal time), kar v našem primeru

pomeni, da je čas lokacije 9:27:32. V nadaljevanju zvemo lokacijo, kjer je latituda enaka

45°20'510'' na severni polobli, longituda pa 20°27'150'' na vzhodni polobli. Znak 'A' nam

pove, da vrstica B vsebuje tudi višinske podatke, in sicer 46 metrov nad morsko gladino

oziroma 83 metrov nad WGS84 elipsoidom. Sedaj smo prebrali 35 znakov, kar se sklada s

podatki o prvi razširitvi, ki se začne pri 36. znaku in je dolga 3 znake. Tako nam 488

pomeni nivo glasnosti motorja, ki lahko zaseda vrednosti med 0 in 999. S tem smo

definirali lokacijo v času z vsemi obrobnimi informacijami [FAI, 2008].

4.3 Pretvorba in posebnosti

Glavni cilj pretvorbe je procesiranje stavka B in ustrezno obravnavo njegovih

razširitev preko vrstice I. Dogovorimo se, da definiramo število -1684 kot NODATA ali


NULL za osnovne tipe, saj je to število predstavljivo tako pod int, float in double tipom

oziroma je mogoče delati uspešne primerjave. Želimo si hitrega procesiranja podatkov, saj

nam je cilj isto kodo uporabiti tudi na prenosnih napravah, kjer je časovna zahtevnost velik

faktor.

Najprej je za nas aktualna vrstica I, na katero naletimo zagotovo pred vrstico B.

Razberemo število razširitev in si vsako shranimo. Hkrati definiramo za vsako razširitev

faktor množenja, s katerim bomo dejansko vrednost v vrstici B nato pomnožili. Praktični

primer tega lahko pokažemo pri vrednostih hitrosti in usmerjenosti – ker bi radi hitrost

beležili v metrih na sekundo, usmerjenost pa v radianih, v prvem primeru uporabimo faktor

f1, v drugem pa f2. Izračunamo ju po sledečih formulah:

�� = 13.6 ∗ 10š��

�� = �180

Pomen teh faktorjev pride do izraza, ko beremo dejanske podatke razširitev iz

vrstice B. Hitrosti, ki jih dobimo kot vrednost kilometrov na uro, želimo zapisati v metrih

na sekundo. Zato bomo vrednost razširitve iz vrstice B pomnožili z faktorjem f1. Z

vrednostmi, ki so izmerjene v stopinjah, kot sta longituda in latituda, si zaradi lažjega

računanja želimo zapisati v radianih. Zato bomo tovrstne prebrane razširitve iz vrstice B

pomnožili z f2.

Nadaljujemo z beleženjem točk iz vrstic B. Datum oziroma čas preberemo kot

celotno število in ga z aritmetičnimi operacijami razdelimo na komponente dan, mesec in

leto. Isto naredimo tudi za Longitudo in Latitudo skupaj. V nadaljnjem koraku bi lahko

prebrali še razširitve, vendar nas le-te za naše potrebe ne zanimajo.

Paziti moramo na posebnosti v obliki okvar sprejemnika GPS. Posledično bomo

opazili anomalije v točkah, saj se lahko zgodi, da bo v urejenem nizu katera izrazito

izstopala. To je potrebno popraviti v rekonstrukciji, skupno z neurejenim časovnim

intervalom. Pogosto se dogaja, da zapisovalnik poti zapiše točko T2 pred T1, čeprav je

časovno gledano letalo preletelo T1 pred T2. Posledica je neurejena črta, ki povsem popači

prikaz leta – to je v rekonstrukciji potrebno upoštevati.


Točke shranimo v seznam, imenovan »Flight«, ki bo osnova za kasnejše

procesiranje.


5 Rekonstrukcija

Pred seboj imamo seznam točk, diskreten nabor parov Longituda – Latituda,

zapisanih v radianih. V rekonstrukciji moramo odpravljati tri stvari:

• lokacijske anomalije,

• časovne anomalije in

• prevelike časovne intervale.

Lokacijske anomalije se dogajajo kot posledica napake pri zapisovanju GPS

naprav. Odpravljanje je dokaj enostavno, če predpostavimo naslednjo stvar: anomalija v

zapisu bo vedno izrazita. Ker imamo koordinate zapisane v radianih, vemo, da bodo

vrednosti v vsakem trenutku obsegale interval [–π, π] za longitude oziroma [− ��, ��] za

latitude. Intervali so določeni zaradi načina zapisa geoprostorskih koordinat, pri čemer

poldnevniki obsegajo interval [0, 180] stopinj na obeh hemisferah, vzporedniki pa [0, 360]

stopinj od juga proti severu. Definirane intervale dobimo tako, da stopinje pretvorimo v

radiane. Torej velja sledeče: imamo zapis koordinate izven teh meja, lahko z gotovostjo

trdimo, da gre za anomalijo.

Ker pa se na to ne smemo zanašati, uporabimo odstopanje v preleteni razdalji.

Beležimo zadnjih 10 razdalj in računamo aktualno. Če le-ta odstopa od povprečne za več

kot 30%, lahko zopet trdimo, da gre za anomalijo, ki jo je potrebno odstraniti. Odstranjeno

točko v času lahko sicer rekonstruiramo linearno (torej ji priredimo točko, ki razpolovi

daljico med prejšnjo in naslednjo – v tem primeru praktično ne storimo ničesar), lahko pa

jo interpoliramo. Interpolacijo si bomo podrobneje ogledali v rekonstrukciji časovnih

intervalov.

Časovne anomalije se dogajajo ob napakah vrstnega reda zapisovanja koordinat

GPS. Imejmo točko P1 v času T1 ter P2 v času T2, pri čemer je T1 < T2. Časovna anomalija

se zgodi, ko se točka P1 zaradi napake pri pisanju zapiše za P2. Te anomalije rešimo še

enostavneje kakor lokacijske, saj jih ni potrebno odstranjevati, temveč celoten nabor točk

enostavno uredimo. Ker pa bo šlo v večjem delu za že urejeno zaporedje točk, moramo

uporabiti takšen razvrščevalni algoritem, ki bo imel časovno odvisnost v najslabšem

primeru O(� ∗ log (�)). .NET ima vgrajeno hitro urejanje (quicksort), ki pa pri že

urejenem polju nima najboljših lastnosti, saj se njegova časovna odvisnost poveča na


O(��). Zato porabimo implementacijo urejevalnega algoritma s kopico (HeapSort), ki se v

naših pogojih obnaša najbolje.

Urejanje s kopico je v večini primerov in na večini konfiguracij počasnejše od

hitrega urejanja, vendar pa se od slednjega obnaša bolje, če je večino elementov v nizu že

urejenih. Urejanje s kopico ni stabilni urejevalni algoritem. To pomeni, da za več parov

ključ-vrednost, pri katerem bodo ključi isti, vrednosti pa ne, ne bo vedno zagotovljen

originalni vrstni red po sortiranju. Drugače povedano: imejmo omenjeni točki P1 in P2 s

časoma T1 in T2 pri pogoju, da je T1 = T2, kjer nam čas pomeni ključ, točka pa vrednost.

Algoritem je stabilen, če velja, da bo vrstni red P1 in P2 enak po urejanju. To za urejanje s

kopico ne drži, vendar za nas ne predstavlja bistvenega problema, saj bomo za ključe vzeli

čase Tn, kjer se bodo sosednji primerki vedno razlikovali za vsaj eno sekundo – kakor je

omejeno že v specifikacijah slehernega zapisovalnika GPS. Za razvrščanje s kopico bomo

uporabili obstoječo implementacijo (http://en.csharp-online.net/Heap_Sort) v C#.

Odprava prevelikih časovnih intervalov zahteva posebno pozornost, ki predstavlja

zlasti ob kroženjih dostikrat nerešljiv problem. Zato si bomo sprva pogledali fizikalni

model letenja ter nato razmislili o možnostih in metodah reševanja problema.

5.1 Fizikalni model letenja

Let jadralnega letala se od navadnega precej razlikuje. Jadralna letala so zmožna

precej sunkovitih premikov ter izrazitih kroženj. Pri gibanju, kjer je kotna hitrost nizka,

poti ni težko opisati. Dovolj je že, če točke med seboj povežemo v daljice, da dobimo bolj

jasno sliko o tem, kako je dejanski let potekal. Pri visoki kotni hitrosti pa temu ni več tako,

saj dobimo precej nenavadno sliko, ki ni več intuitivna.


Slika 4: Prikaz leta v ravnini xy

Poglejmo si let, ki ima visok časovni interval (slika 4). Na sliki je z rdečo debelejšo

krivuljo označena 2D projekcija leta, kakršna bi naj bila v resnici. Črne točke predstavljajo

znane podatke, medtem ko črna krivulja predstavlja interpolacijo celotnega nabora točk.

Hitro ugotovimo problem, ki nam ga visok časovni interval predstavlja – točke ne

opisujejo več dejanske poti gibanja.

Predpostavimo lahko, da se kotna hitrost glede na zrak ne spreminja, temveč je

konstanta. Bolje rečeno, letalo ob dviganju konstantno kroži z isto kotno hitrostjo (v

kolikor sam let preslikamo v 2D ravnino), za zamik kroženja pa je zadolžena komponenta

vetra.

V splošnem lahko opisano definiramo z vetrovnim trikotnikom, ki je grafična

predstavitev razmerja jadralnega letala in vetra.

Vetrovni trikotnik (slika 5) je definiran iz treh komponent:


• zračni vektor predstavlja gibanje letala glede na zrak,

• vetrovni vektor predstavlja gibanje zraka nad zemljo in

• zemeljski vektor predstavlja gibanje letala glede na zrak.

Slika 5: Vetrovni trikotnik

Vrnimo se na kroženje. Če upoštevamo dejstvo, da je kroženje konstantno in

predstavlja gibanje glede na zrak, moramo dodati samo še vetrovno komponento, ki

celotno kroženje zamakne v smer vetrovnega vektorja. Opisano gibanje letala glede na

zemljo predstavlja vetrovni trikotnik (slika 5).

5.2 Metode reševanja

Problem lahko rešimo na dva načina. Prvi je modularen in se imenuje »od spodaj

navzgor«. To pomeni, da obravnavamo točko po točko posebej in šele pri zadnji dobimo

zaključeno celoto. Drugi način je celostni in se imenuje »od zgoraj navzdol«. Pri tem

principu zaobjamemo nabor točk kot celoto in vršimo algoritme nad celotnim naborom

točk hkrati. Vse predpostavke, ki smo jih postavili pri definiciji fizikalnega modela, nam

pridejo prav predvsem pri slednjem principu. A sprva si bomo ogledali prvi, bolj intuitiven

pristop in metodo, ki smo jo razvili sami.


5.3 Metoda krožnih lokov

Metoda temelji na krožnih lokih. Predpostavimo, da naše gibanje zavzema obliko

krožnega loka, saj smo poprej definirali fizikalni model, ki pravi, da pri kroženju v

glavnem s preleteno potjo zasedamo obliko pravilnega kroga.

Bistvo metode krožnih lokov je, da povežemo točke med seboj s krožnimi loki. Pri

tem mora biti prehod med dvema krožnima lokoma v opazovani točki čim bolj gladek in

nepretrgan. Kako bi to dosegli?

Poznamo kot, pod katerim letalo vstopa v kroženje. Torej poznamo kot pri vhodni

točki krožnega loka. Center krožnega loka bo, v kolikor hočemo, da je prehod maksimalno

gladek, ležal nekje na premici, ki je pravokotna na smer gibanja, saj je centripentalna sila

ob kroženju ravno tako pravokotna. Vemo tudi, da bo oddaljenost centra od vhodne točke

enaka kot od izhodne točke, saj le tako lahko potegnemo lep krožni lok, ki se konča na

naslednji točki. Če torej povzamemo, predpostavimo, da:

• se center krožnega loka nahaja na ortogonalni premici, ki poteka skozi vhodno

točko in

• je dolžina daljice med centrom in vhodno točko enaka dolžini daljice med centrom

in izhodno točko (slika 6).

Slika 6: Predpostavke pri metodi krožnih lokov


Preostane nam torej zgolj, da izračunamo, kje leži center. Imamo torej vhodno

točko p1 (x1, y1), izhodno točko p2 (x2, y2) in središče c(x, y), katerega koordinati sta v

linearnem razmerju, saj center leži na premici s, ki je ortogonalna na smer gibanja v vhodni

točki. To premico torej definirata točki p1 in c. V ravninskem kartezičnem koordinatnem

sistemu je premica s graf linearne funkcije:

= !" + �

Zapišemo, da sta dolžini $�% in $�% enaki.

&(" − "�)� + ( − �)� = &(" − "�)� + ( − �)�

Namesto c(x, y) lahko zapišemo kar c(x, kx + n), saj smo predpostavili, da center

kroženja c leži na premici s. V enačbo namesto y vstavimo kx + n. Enačbo razrešimo tako,

da obe strani kvadriramo.

(" − "�)� + (!" + � − �)� = (" − "�)� + (!" + � − �)�

"� − 2""� + "�� + (!" + �)� − 2 �(!" + �) + ��= "� − 2""� + "�� + (!" + �)� − 2 �(!" + �) + ��

−2""� + "�� − 2 �(!" + �) + �� = −2""� + ""�� − 2 �(!" + �) + ��

−2""�� − 2 �(!" + �) + 2""� + 2! � + 2� � = −""�� − �� + �� + ��

−2""� − 2! �" − 2� � + 2""� + 2! �" + 2� � = "�� − "�� + �� − ��

"(−2"� − 2! � + 3"� + 2! �) + 2� � − 2� � = "�� − "�� + �� − ��

"("� − "� + ! � − ! �) + � � − � � = "�� − "�� + �� − ��

"("� − "� + !( � − �)) = "�� − "�� + �� − ��

" = "�� − "�� + �� − �� − 2�( � − �)2("� − "� + !( � − �))

Končna rešitev za center je torej c(x, kx+n), pri čemer koeficiente k in n dobimo iz

premice s, ki je pravokotna na smer gibanja v vhodni točki. Proces v naslednjem koraku

ponovimo tako, da izračunamo center c2 za krožni lok med točkama p2 in p3 (slika 7).

Nadaljujemo do konca vseh točk.


Slika 7: Demonstracija rekonstrukcije s krožnimi loki

V naslednjem koraku (slika 7) imamo definirane točke p1, p2 in naslednjo p3. Točke

so označene s črno piko, rdeča linija pa predstavlja generirane krožne loke. Zelene premice

s1 in s2 predstavljajo ortogonalne linije glede na smer vhodne točke, modre točke pa so

središča krožnih lokov. Če si pogledamo celotni proces na tem praktičnem primeru še

enkrat, naprej vzamemo točko p1 in ji določimo pravokotno premico s1. Tej premici

določimo koeficiente k in n. Nato po definirani formuli izračunamo center krožnega loka

na p2 in ga izrišemo. To ponovimo za vsako naslednjo točko, dokler nismo zaobjeli

celotnega nabora točk.


Slika 8: Rešitev kroženja z metodo ostrih krožnih lokov

Za zahtevne primere, kakršnega smo definirali na začetku poglavja, lahko naredimo

modifikacijo algoritma. Krožne loke lahko naredimo ostrejše tako, da pomaknemo center

krožnega loka nazaj v smeri razpolovišča kota. Obenem ne potegnemo več čistega

krožnega loka, saj bi rezultat bil preveč grob. Namesto tega dodamo nekaj referenčnih

točk, ki ležijo na generiranem krožnem loku, ostale pa skupaj s preostalim naborom

vhodnih točk interpoliramo. Rešitev začetnega specificiranega težkega primera prikazuje

slika 8.

5.4 Interpolacija

Interpolacijo smo skozi celotno diplomsko delo omenjali kot način nadomeščanja

manjkajočih podatkov. Posebej smo jo omenili pri premočrtnem gibanju, kjer samo gibanje

nima pospeškov, temveč je relativno predvidljivo, obenem pa smo jo uporabili tudi pri

prejšnji metodi krožnih lokov oziroma izpeljav le-teh.


Ob vsem tem pa je vredno poudariti, da je interpolacija že sama po sebi

rekonstrukcijska metoda, in sicer tipa »od spodaj navzgor«, a z nekaj vplivi tehnik tipa »od

zgoraj navzdol«, saj rekonstruiramo pot med vsakim parom sosednjih točk posebej.

Za naše potrebe smo se oprli na že obstoječo implementacijo Kubičnih B-zlepkov

(Cubic B-splines) (http://itrunk.googlecode.com/svn/trunk/SPLINE/Spline.h), ki

so nam generirali manjkajoče vmesne interpolirane točke.

5.5 Genetski algoritem

Genetski algoritem je metoda, ki oponaša naravni proces evolucije. Pomembno pri

genetskih ali evolucijskih algoritmih nasploh je, da se zavedamo dejstva, da v večini

primerov algoritem ne poda optimalne rešitve, temveč zgolj njen približek. Ravno tako je

potrebno imeti v mislih, da je verjetnost, da bomo v dveh zaporednih izvajanjih algoritma

dobili dva enaka rezultata, precej majhna oziroma skoraj nič. Pozitivna stran tovrstnih

algoritmov pa je, da generirajo rešitve, na katere človek redkeje pomisli.

Za uspešno delovanje tako evolucijskih kot genetskih algoritmov je potrebno:

• rešitve primerno predstaviti (predstavitveni problem),

• določiti funkcijo uspešnosti, ki oceni uspešnost oziroma kvaliteto rešitve in

• določiti genetske operatorje [Mernik, 2003].

Princip genetskih algoritmov je sledeč. Imamo populacijo osebkov ali kromosomov, ki

tvorijo genotip ali genom. Kromosomi so možne rešitve našega problema, ki ga zastavimo

v algoritmu, naša naloga pa je, da te rešitve ovrednotimo. To storimo s posebno funkcijo

uspešnosti, ki nam ovrednoti (evaluate) kromosom. Začetno populacijo moramo seveda

sprva generirati – temu pravimo inicializacija. Pri inicializaciji moramo paziti, da je

začeten nabor rešitev (kromosomov) oziroma populacija čim bolj splošna, če ne poznamo

nobenega spektra rešitev. Če pa se nagibamo k določeni veji rešitev, lahko podamo bolj

specifično začetno populacijo. Le-to nato ovrednotimo s funkcijo uspešnosti, nato pa

podvržemo genetskim operatorjem. Ti so popolnoma odvisni od nas, izbiramo pa lahko

med križanjem, mutacijo in selekcijo. Poglejmo si splošen psevdokod evolucijskega

algoritma (programska koda 4).


Psevdokod Evolucijski algoritem

• Inicializiraj populacijo

• Ovrednoti vsakega posameznika v populaciji

• Dokler ne bo končni pogoj (posameznik je dovolj dober ali čas je potekel) zadoščen:

o Izvedi selekcijo nad populacijo za izvajanje genetskih operatorjev

o Izvajaj genetske operatorje

o Ovrednoti populacijo

Programska koda 4: Evolucijski algoritem

5.5.1 Predstavitev rešitve

Naš cilj je iz nabora točk sestaviti smiselno kroženje. Ob tem se opremo na dejstvo,

da je kroženje pri dviganju letala konstantno, nanj pa vpliva zgolj komponenta vetra, ki

povzroči, da gibanje izoblikuje spiralo. Če vzamemo torej pot kot kromosom, ni smiselno,

da za pot uporabimo predstavitev z naborom točk. Namesto tega lahko pot opisujemo kot

tako imenovano dinamično kroženje. To kroženje pa lahko potem pretvorimo v nabor

vmesnih točk, ki sovpadajo z vhodnimi podatki. Poglejmo si zastavljeni opis kromosoma.

public class CircularPath

{

public PointF Center;

public Double Diameter;

public Double Speed; //counterclockwise if negative

public Double WindSpeed;

public Double WindFactor;

}

Vse, kar pri opisu poti potrebujemo, so center kroženja, polmer kroženja, kotna

hitrost (katere predznak pomeni, v katero smer letalo kroži) in komponenta vetra. Pri vetru

moramo upoštevati tako jakost kakor tudi vpliv. Jakost ali hitrost vetra določa zgolj, kako

hitro se bo kroženje gibalo v smeri vetra. Vpliv ali faktor vetra pa predvideva, da bo imelo

letalo največjo hitrost, ko bo tangenta kroženja enaka vektorju smeri vetra, najmanjšo pa,


ko bo tangenta kroženja nasprotna smeri vetra. Ker je ta odvisnost sinusna funkcija, bo ta

faktor nastopal prav v njej.

5.5.2 Funkcija uspešnosti

Evalvacija kromosoma oziroma funkcija uspešnosti nam v numeričnem smislu

ovrednoti kromosom. Naša naloga je, da definiramo tovrstno funkcijo, ob tem pa moramo

postaviti še kazensko funkcijo, ki bo tako rekoč kaznovala kromosom ob nepravih oblikah.

V praktičnih primerih to pomeni, da bi denimo kromosom, ki uprizarja rešitev

logaritemske enačbe, kaznovali z maksimalno kaznijo, če bi vmesna rešitev bila negativna.

Mi se bomo osredotočili na tri možne funkcije uspešnosti, ki pridejo v poštev. Prva je

najbolj intuitivna, najlažje pa bi jo označili kot prilagajanje. Funkcija bo preverila, kako

dobro se generirano kroženje prilagaja vhodnemu naboru točk, dejansko pa bo evalvacijska

vrednost seštevek minimalnih razdalj vhodnih točk do kroženja. Druga funkcija se bo

osredotočila na interne kumulativne razdalje med točkami. Izračunale se bodo razdalje

med vsakima sosednjima točkama, ki imata enolično referenco na eno od točk v vhodnem

naboru, razdalje same pa bodo podane v kumulativni ureditvi. Tretja funkcija bo

enostavnejša, saj bo preverjala zgolj vrstni red točk, po katerem bo kroženje zaobjelo

vhodni nabor točk.

5.5.2.1 Prilagajanje

Evalvacija prilagajanja je definirana kot seštevek minimalnih razdalj vhodnih točk

do generiranega kroženja. Za vsako vhodno točko se izračuna najmanjša razdalja do

generiranega kroženja, seštevek pa služi kot evalvacijsko število, ki nam pove, koliko je

kroženje »vredno«. Manjše kot je število, boljše je kroženje. Funkcijo eval lahko zapišemo

kot:

*+,-($,.ℎ) = 0 mindist(p8, path)<�=>

kjer je path generirano kroženje, p nabor vhodnih točk in n število le-teh. Funkcija mindist

za parametra prejme točko pi in generirano kroženje path, vrne pa najmanjšo razdaljo med


njima. Analitično je to funkcijo težje definirati, saj generirano kroženje oziroma koordinate

kroženja opišemo kot:

x = r cos(φ) + C φ cos(D)

y = r sin(φ) + C φ sin(D),

pri čemer r stoji za polmer kroženja, w za jakost vetra, D za smer vetra in φ za kot kroženja

oziroma kot, ki je ortogonalen na tangento kroženja. Ta kot teče v intervalu [0, ∞] in ga

uporabimo za realizacijo pomikanja kroženja v smeri vetra. Ker nastopa tako v

trigonometričnih funkcijah kot tudi izven njih, po analitični poti minimalno razdaljo od

poljubne točke do obravnavanega kroženja težje rešimo. Zato si pomagamo z fizikalnim

modelom, s pomočjo katerega smo na začetku generirali testne vzorce. Spremenimo

generirano kroženje v gosti diskretni nabor točk, da lahko minimalno razdaljo točke do

kroženja definiramo kot:

FG�HGI.($, J) = min>KLKM N("O − "P,L)� + ( O − P,L)�

Še vedno imamo vhodno točko v oziroma njeni koordinati xp in yp ter diskreten nabor m

točk generiranega kroženja g. Razdalje računamo sproti, ko generiramo nabor točk.

Če bo kroženje dobro, se bodo vhodne točke prilagajale generiranemu kroženju, minimalne

razdalje pa bodo majhne. Na primeru slabega kroženja (slika 9) pa lahko opazimo, da

posebej izstopata točki p2 in p3, ki sta od kroženja, ki je obarvano sivo, preveč oddaljeni.

Slika 9: Primer slabega kroženja po funkciji prilagajanja


5.5.2.2 Interne kumulativne razdalje

Interne kumulativne razdalje so bolj kompleksna funkcija uspešnosti in izpolnjujejo

dva namena: preverjajo preleteno razdaljo med dvema točkama in vrstni red obletelih točk.

Predpostavimo še nekaj: lahko predvidevamo, kako dolga bo pot med dvema

točkama v kroženju. Povprečno vrednost razdalj med diskretnim naborom vhodnih točk,

pomnožimo s faktorjem, ki ga določimo sami, da dobimo predvideno dolžino poti. Iz

testiranj se izkaže, da dovolj dobro deluje faktor ��, vendar je izbira prepuščena nam samim,

uporaba konstante π pa je tu zgolj naključna. S tem dobimo predvideno dolžino poti davg.

Ko torej vemo, kako dolgo lahko opazujemo posamezno vhodno točko pri

generiranem kroženju, pričnemo meriti razdalje. Vsakič, ko se z generiranim kroženjem

približamo kateri izmed vhodnih točk, preverimo, ali je razdalja do nje minimalna. Do tu je

postopek isti kot pri funkciji prilagajanja, vendar v tem primeru ne shranimo samo

minimalne razdalje do vhodne točke, temveč tudi doslej izmerjeno razdaljo, ki smo jo

opravili ob kroženju. Razdalje se tako predstavijo kot kumulativni seštevek. To predstavlja

prednost predvsem pri vrstnem redu obletelih točk, saj mora takšen kumulativni seštevek

biti po velikosti urejen seznam. Če se izkaže, da ni urejen po velikosti, pomeni, da je

kroženje napačno in se ne prilagaja vhodnim točkam.

Imejmo vhodni diskretni nabor m točk p. Pri točki p0 bo kumulativna razdalja 0, saj

s kroženjem še nismo opravili nobene poti. Pri točki p1 se bo shranila razdalja d1, za katero

si želimo, da bo absolutna razlika od davg čim manjša. Čim dobimo večje odstopanje, lahko

predvidevamo, da imamo opravka s slabim vzorcem. Pri točki p2 se bo shranila razdalja d2,

za katero velja, da je večja od d1 oziroma gre dejansko za razdaljo od točke p0. V

splošnem lahko zapišemo:

QH� − H�R� − HS PQ < U, H� > H�R�∀G ∈ [1, F] Vsaka naslednja razdalja je večja od prejšnje in absolutna razlika med sosednjima

dvema in povprečno predvidevano razdaljo naj bo za dobre vzorce manjša od ℰ, ki nam

predstavlja pragovno vrednost. Le-te dejansko ne potrebujemo, temveč nam služi samo kot

vodilo. Ko namreč obravnavamo vse vhodne točke in zapišemo vse kumulativne razdalje,

izračunamo varianco preletenih razdalj. Ker imamo razdalje zapisane v kumulativni obliki,

jih moramo najprej pretvoriti v relativne. Za poljubno razdaljo di bomo izračunali:


H� = H� − H�R�

To storimo za vse razdalje. Če nismo obravnavali vseh točk v pravilnem vrstnem

redu, bomo dobili tudi negativne razdalje, kar bo ravno tako pokazatelj, da vzorec ni

primeren. Ko pretvorimo vse razdalje, izračunamo mero razpršenosti razdalj s pomočjo

variance \�:

\� = 0(H� − HS P)M�=>

�

Vrednost variance je tudi rezultat vrednotenja vzorca po funkciji internih

kumulativnih razdalj. Manjša kot je varianca, bolj enakomerne so razdalje med točkami,

večja je verjetnost, da je generirani vzorec dober. Hkrati zagotovimo, da smo točke

ovrednotili v pravem vrstnem redu, saj bi bila sicer varianca bistveno večja. To se zgodi

pogosto (slika 10), zato tega ne smemo zanemariti:

Slika 10: Primer generiranega kroženja z napačnim vrstnim redom

S sivo obarvano generirano kroženje sledi vhodnim točkam po naslednjem vrstnem

redu: p1, p3, p2, p3, p4, p5, p6. Že pri točki p3 naletimo na problem, saj jo obletimo pred

točko p2, kar se pokaže pri negativni razdalji d3 in posledično visoki varianci.


5.5.2.3 Vrstni red točk

Ta funkcija je najenostavnejša. Vzdržuje se samo vrstni red prvič obletelih točk.

Ker je matematično malo verjetno, da bomo zadeli točne koordinate vhodnih točk, je

potrebno definirati prag oziroma krog okoli vhodne točke, za katerega velja, da stoji za

točko samo. To pomeni, da lahko kroženje preleti prag in bo za nas veljalo, kakor da je

preletelo točko samo. Ta funkcija nam ob napačnem vrstnem redu preletenih točk zagotovo

pove, da je kromosom neveljaven. Služi nam lahko pri začetnem filtriranju kromosomov,

kjer izloči vse vzorce z napačnim vrstnim redom, vendar nam lahko v genetskih algoritmih

včasih tudi slabe rešitve na dolgi rok pomagajo k boljšemu izidu, zato nam je ta funkcija

zgolj v oporo.

5.5.3 Genetski operatorji

Definirali smo kromosom in ga ovrednotili. Sedaj ga želimo spreminjati. Kot

rečeno, so temeljni genetski operatorji selekcija, križanje in mutacija. Poglejmo si na

našem konkretnem primeru, kako bomo definirali omenjene operatorje.

5.5.3.1 Selekcija

Selekcija je operator, ki je temelj genetskega algoritma. Določa, kdo preživi in kdo

ne, ali drugače povedano, definira novo generacijo kromosomov.

Poznamo več vrst selekcije. Najbolj temeljna je zagotovo proporcionalna

selekcija, pri kateri imajo najboljše možnosti preživetja tisti kromosomi, ki so ocenjeni

najbolje. To je lahko problematično, če se rešitve kaj hitro zatečejo v lokalni optimum. To

se zgodi v primeru, ko imamo v populaciji kromosom, ki je daleč najuspešnejši in ne vodi

h globalnemu optimumu. V tem primeru bo kaj hitro prevladal v celotni populaciji in našli

bomo samo lokalni optimum. Slabosti tega se izognemo z uporabo drugih vrst selekcij

(turnirske selekcije in selekcije z rangiranjem) [Mernik, 2003]. Druga možnost je, da

nevarnosti lokalnih optimumov upoštevamo ob inicializaciji začetne populacije, kjer ne

smemo predložiti lokalnega optimuma kot ene izmed rešitev.


V našem primeru pa ta nevarnost ni zelo visoka, saj lokalnih optimumov ni veliko.

Mi iščemo končne rešitve, ki so pravilne ali pa ne. Zato nam je ravno v interesu, da

podamo približek ali oceno globalnega optimuma v začetno populacijo – to pa je potrebno

poprej izračunati. Le-to si bomo pogledali v nadaljevanju, za sedaj pa definirajmo

proporcionalno selekcijo. Ta je za nas sprejemljiva, četudi ne moremo povsem ovreči

obstoja lokalnih optimumov. Brez dobrega začetnega približka bi kromosomi divergirali k

napačnim rešitvam, zato ostajamo pri tej izbiri.

5.5.3.2 Križanje

Križanje je operator, pri katerem vzamemo dva kromosoma, združimo njune

karakteristike in na ta način dobimo nov kromosom ali kromosoma. Ta operator je zelo

učinkovit pri dolgih sestavljenih rešitvah, vendar pri našem kompaktnem kromosomu ne

pride v poštev. Križanju se bomo zato v celoti izognili in ga omenjamo zgolj zaradi

celovitosti opisovanja genetskega algoritma.

5.5.3.3 Mutacija

Za nas najbolj aktualen genetski operator je zagotovo mutacija. Ob njej se

spreminjajo oziroma tako rekoč mutirajo lastnosti kromosoma, prav tu pa se kaže moč

naključja, saj se ravno tu (in poprej že tudi v inicializaciji) uporabljajo naključne vrednosti.

Pri mutaciji torej vzamemo karakteristiko kromosoma in jo spremenimo. To lahko

naredimo popolnoma naključno, vendar bi s tem iskali slepe rešitve, zato je ustaljena

praksa, da karakteristiko malenkostno spremenimo tako, da v poprej določenem tako

imenovanem varnem obsegu generiramo naključno vrednost, ki se tej karakteristiki

naposled tudi doda.

V našem primeru bo za nas aktualnih 6 različnih tipov mutacij:

• pomik centra kroženja v smeri vetra,

• pomik centra kroženja pravokotno na veter,

• sprememba polmera kroženja,

• sprememba kotne hitrosti,


• sprememba vetrovne moči in

• sprememba vetrovnega faktorja.

Pomikanje centra pomeni translacija celotne vijačnice v smeri pomika. To je

smiselno v mladih generacijah, ki še niso konvergirale v optimume in jih lahko

vzpodbudimo s tovrstnim operatorjem. Sprememba polmera kroženja povzroči, da se

kroženje zoža ali razširi, kar pa je aktualno pri skorajšnjih optimumih, ko nam manjka še

čisto malo do rešitve. Sprememba kotne hitrosti je smiselna kakor poprej rečeno prav tako

v začetnih fazah, kot tudi vetrovne modifikacije. Četudi slednje niso nujno del kroženja

temveč predstavljajo eksterni vpliv, jih vseeno vključimo v genetski algoritem, ker lahko

tako na njih tudi vplivamo.

5.5.4 Inicializacija

Veliko smo o inicializaciji povedali že v tem poglavju, največkrat pa je bila omenjena v

povezavi z nevarnostmi optimumov in pomembnosti izhodiščne točke. Ne moremo

popolnoma ovreči nevarnosti lokalnih optimumov. To lahko omilimo z ustrezno definicijo

evalvacijske funkcije, še bolj pomembno pa je, da zastavimo kazensko funkcijo, ki takšne

nevarnosti eliminira.

Cilj je torej generirati populacijo kromosomov, ki bo že iz starta čim bolj posnemala

kroženje, predstavljeno z vhodnim naborom točk. Torej moramo definirati začetni

približek centra kroženja, polmer in ostale karakteristike, ki pa so za kasnejše procesiranje

manj kritične. Kako se lotimo tega?

Sprva moramo definirati smer vetra. Čeprav bi lahko dobili informacije o tem iz druge

roke, se raje zanesemo na lastne podatke in skušamo smer izračunati sami. Pri tem si bomo

pomagali z metodo minimalnega obsegajočega pravokotnika. Kot vemo, je kroženje

konstantno in ga dejansko premika zgolj komponenta vetra. Če torej narišemo okoli vseh

vhodnih točk najmanjši možen pravokotnik, ki zaobjame vse vhodne točke, nam smer

daljše stranice pomeni smer vektorja vetra.


Slika 11: Definiranje smeri vektorja vetra

Oranžen pravokotnik (slika 11) opisuje minimalni obsegajoč pravokotnik nad

vhodnim naborom točk. V naslednjem koraku moramo določiti center kroženja in polmer.

Slednjega lahko aproksimiramo s polovično vrednostjo (slika 11) krajše stranice

minimalnega obsegajočega pravokotnika (d2), s tem pa tudi že definiramo center kroženja.

Obstaja pa tudi druga metoda, s katero lahko določimo center krožnice in polmer.

Projeciramo vhodne točke na premico (slika 12), pravokotno na smer gibanja oziroma

vetra. Povprečna vrednost projekcijskih točk (če predpostavimo, da imamo samo še eno-

dimenzionalno vrednost) oziroma težišče nam že pove približek centra kroženja in se po

navadi popolnoma sklada s centrom, definiranim s polovičnimi stranicami obsegajočega

pravokotnika.


Slika 12: Definiranje centra krožnice s projekcijo vhodnih točk na premico, pravokotno na smer gibanja

Določili smo center kroženja glede na pravokotno smer vetra. Kako pa zdaj

določimo lokacijo centra glede na smer vetra? Pri tem si pomagamo z enostavnimi

minimizacijskimi metodami, saj lahko kromosom (tako lahko naše generirane podatke že

poimenujemo, saj jih imamo dovolj) preprosto ovrednotimo. Tako dobimo preprosto

funkcijo z enim parametrom, ki predstavlja odmik centra v smeri vetra, rezultat funkcije pa

je enak rezultatu funkcije uspešnosti. Pri minimizaciji uporabimo Brentovo optimizacijsko

metodo, ki jo bomo podrobneje opisali v nadaljevanju. Dobljeno vrednost z naključnimi

manjšimi odstopanji podamo z inicializacijskim kromosomom.

Ostale parametre inicializiramo po želji, vendar je priporočljivo, da si zastavimo za

vsak parameter osnovne vrednosti, ki služijo kot izhodišče za nadaljnje iskanje.

5.5.5 Metoda minimalnega obsegajočega pravokotnika

Uporabili smo metodo minimalnega obsegajočega pravokotnika (minimum

bounding rectangle ali MBR). Za to potrebujemo nabor vhodnih točk, ki nam predstavlja

kar naš let, ki ga hočemo rekonstruirati. Seveda je aktualen samo tisti predel točk, ki

predstavlja kroženje in iz katerega želimo izračunati smer vetra.


Načinov izračunanja MBR je več. Mi se bomo oprli na metodo z rotirajočimi premicami

oziroma t.i. kalipri (slika 10). Le-ta se zelo pogosto uporablja za eficientne algoritme za

reševanje problemov v geometriji. V našem primeru se bomo oprli na sledeči izrek:

• MBR ima vsaj eno stranico kolinearno z enem od robov konveksne lupine nabora

točk. [Toussaint, 1983]

Algoritem konstruira pravokotnik v času O(n) za vsako stranico konveksne lupine

nabora vhodnih točk in izbere najmanjšega od le-teh v času O(n2). Ta problem lahko

rešimo v času O(n) z uporabo dveh parov kaliprov, ki sta pravokotna eden na drugega.

Slika 13: Prikaz rotirajočih kaliprov za izračun minimalnega obsegajočega pravokotnika

V prvem koraku izračunamo konveksno lupino nabora vhodnih točk. Na sliki 13

lahko vidimo konveksno lupino in štiri rotirajoče kalipre. Dejansko imamo vedno štiri

kalipre pi, pj, pk in pl. Kalipri niso nič drugega kot štiri usmerjene premice, ki imajo po

vsaka dve pravokotnici in eno vzporednico. Tako ima pi za vzporednico pk ter za obe


pravokotnici pj in pl. Presečišča kaliprov ali premic nam definirajo pravokotnik, ki ga

iščemo.

Spomnimo se, da mora imeti MBR vsaj eno stranico vzporedno z robom konveksne

lupine. Zato rotiramo kalipre tako, da bo vsaj eden vzporeden z omenjenim robom. Imamo

kote θi, θj, θk in θl. To so koti med usmerjenim kaliprom in naslednjim robom konveksne

lupine. Izberemo vedno najmanjšega izmed vseh kotov ( min { θθθθi, θθθθj, θθθθk, θθθθl } ) in vse

kalipre za ta kot zarotiramo. S tem dosežemo, da ima dobljeni pravokotnik vsaj eno

stranico kolinearno s konveksno lupino.

Za dobljeni pravokotnik izračunamo ploščino in si jo zapomnimo. Ponovimo

postopek in rotiramo tako dolgo, dokler ne naredimo 90 stopinjski obrat. S tem smo že

zaobjeli vse možne pravokotnike, tisti z najmanjšo ploščino pa predstavlja rezultat

algoritma.

Poglejmo si opisan algoritem podrobneje. Za vhod moramo predvidevati, da imamo

konveksno lupino vhodnega nabora točk. Izračunamo vse štiri ekstremne točke za poligon

in jih imenujmo xminP, xmaxP, yminP in ymaxP. Konstruiramo štiri premice P1, P2, P3 in

P4 za vse štiri ekstremne točke. Te premice definirajo dva para kaliprov.

Če ena ali več premic leži vzporedno z robom poligona, potem lahko izračunamo

ploščino pravokotnika, ki ga določajo presečišča vseh štirih premic. To vrednost shranimo

kot aktualni minimum. Sicer lahko tretiramo, da je trenutna minimalna ploščina aktualne

rotacije neskončna.

Rotiramo premice v smeri urinega kazalca tako dolgo, dokler ena izmed njih ni

vzporedna s kakšnim robom poligona, ki ga določa konveksna lupina vhodnega nabora

točk. Izračunamo ploščino novega pravokotnika sekajočih premic in jo primerjamo s staro

vrednostjo minimalne ploščine. Posodobimo to vrednost, če je to potrebno, in ponavljamo

rotacijo tako dolgo, dokler ne dosežemo obrat 90°. Končni rezultat je shranjena vrednost

minimalne ploščine.

Za izračun minimalnega obsegajočega pravokotnika uporabimo obstoječo rešitev

[http://softsurfer.com/Archive/algorithm_0112/algorithm_0112.htm].


5.5.6 Konveksna lupina

Kot smo že poprej omenili, potrebujemo konveksno lupino (slika 14) kot vhodni

podatek za izračun MBR s pomočjo rotirajočih kaliprov. Konveksna lupina pa je

minimalno število točk, ki lahko opiše množico točk tako, da zaobjame vse točke.

Slika 14: Primer konveksne lupine

Kot vidimo na sliki, so robne točke tiste, ki definirajo celotni lik, ki ga množica naredi.

Ravno tako so vse točke zaobjete v tem liku, kar je pogoj konveksne lupine. Algoritem je

sestavljen po sledečem principu.

• Vhodne točke uredimo po vrsti.

o Glede na to, da imamo točko v 2D prostoru, primerjamo dve točki naprej po

komponenti x, nato pa še po komponenti y. Tako je npr. P1(3,2) > P2(2,8) in

P3(2,9) < P4(3,8).

• Točke razdelimo na spodnjo in zgornjo polovico.

o Poprej določimo skrajno levo in skrajno desno točko – to sta kar prva in

zadnja točka v nizu vhodnih točk, saj smo jih že uredili.

o Izračunamo ploščino trikotnika, ki ga definirajo obe skrajni točki P1 in P2

ter opazovana točka Po. To storimo z naslednjo formulo:

S = x1 (y2 – yo) + x2 (yo – y2) + xo (y1 – y2)

o Rezultat tega izračuna je predznačena ploščina S. Če je pozitivna, je

opazovana točka v zgornji polovici, sicer pa v spodnji.


• Za vsako polovico sprožimo Grahamovo skeniranje in eliminiramo točke, ki niso

na lupini.

o Lahko predpostavimo, da je prava orientacija (sosledje) točk negativna

oziroma poteka v smeri urinega kazalca. Tako moramo, če sledimo točkam,

vedno delati tako imenovane desne zasuke. Zato računamo ploščino

trikotnika treh aktualnih sosednjih točk. Če je negativna, pomeni, da smo

naredili desni zasuk – srednja točka je zagotovo na lupini. Če pa je ploščina

pozitivna, smo naredili levi zasuk ali pa se gibljemo naravnost – v tem

primeru srednjo točko izvzamemo iz rešitve, saj zagotovo ni na lupini.

• Obe lupini združimo in vrnemo rezultat.

Za implementacijo konveksne lupine smo uporabili obstoječo kodo. [Peter Sestoft,

2001]

5.5.7 Brentova metoda

Pri inicializaciji smo omenili minimizacijske metode in se pri tem oprli na Brentovo

optimizacijo. Predvsem v numerični analizi je Brentova metoda popularna za iskanje

funkcijskih rešitev, saj združuje tako bisekcijsko kot tudi sekantno metodo ter inverzno

kvadratno interpolacijo. Ima zanesljivost bisekcije, a se približa hitrostim manj zanesljivih

metod. Osnovna ideja je uporaba sekantne metode ali inverzne kvadratne interpolacije, če

je to le mogoče, saj rešitve konvergirajo hitreje, v težjih primerih pa se uporabi bolj

robustna bisekcija.

Brentova metoda iskanja funkcijskih rešitev, ničel oziroma korenov je še ena v nizu

metod, ki za dano funkcijo f najde takšen x, da velja:

f(x) = 0

Spomnimo se sekantne metode. Definirati moramo prvi dve vrednosti b0 in b1, da

lahko poženemo metodo. Naslednja vrednost s se generira po sledeči formuli:

I = ]^ − ]^ − ]^R��(]^) − �(]^R�) �(]^)


Ker Brentova metoda vsebuje sekantno metodo, izhajajmo iz te formule. Ob vsaki

iteraciji algoritma se lahko izvrši tudi bisekcijska iskalna metoda. Če je bk trenutna rešitev

metode, je bk-1 rešitev v prejšnji iteraciji. Hkrati vodimo v vsaki iteraciji še spremenljivko

ak, ki ima nasprotno vrednost bk in se jo uporabi pri izračunu bisekcije:

I = ,^ + ]^2

Tretja metoda je inverzna kvadratna interpolacija:

I ≔ S `(a)`(b)(`(S)R `(a))(`(S)R `(b)) + a `(S)`(b)(`(a)R `(S))(`(a)R `(b)) + b `(S) `(a)(`(b)R `(S))(`(b)R `(a))

Brentova metoda je izpeljava starejše Dekkerjeve metode, ki uporablja zgolj sekantno in

bisekcijsko metodo. Dodan je tudi poseben test, ki preveri, ali je sekantna metoda prava

metoda za izračunavo približka v naslednji interaciji. Zadoščena morata biti dva pogoja:

• za določeno pragovno vrednost δ mora, v primeru da je prejšnji korak vseboval

metodo bisekcije, veljati:

| δ | < | bf − bfR�| • če pa je prejšnji korak vseboval interpolacijo, potem mora veljati:

| δ | < | bfR� − bfR�| • Prav tako mora veljati sledeči pogoj, če je v prejšnjem koraku bila uporabljena

bisekcija:

| δ − bf | < 12 | bf − bfR�| • sicer (v primeru interpolacije v prejšnjem koraku) pa velja pogoj:

| δ − bf | < 12 | bfR� − bfR�|


Za lažje razumevanje si poglejmo psevdokod:

• vhod a, b in podprogram za računanje funkcijske vrednosti f • izračunaj f(a) • izračunaj f(b) • if f(a) f(b) >= 0 then izhod end if • if |f(a)| < |f(b)| then swap (a,b) end if • c := a • set mflag • repeat until f(b or s) = 0 or |b − a| < prag

o if f(a) ≠ f(c) and f(b) ≠ f(c) then � I ≔ S `(a)`(b)(`(S)R `(a))(`(S)R `(b)) + a `(S)`(b)(`(a)R `(S))(`(a)R `(b)) + b `(S) `(a)(`(b)R `(S))(`(b)R `(a))

o else

� I ∶= ] − �(]) aRS `(a)R `(S) o end if o if s ni v intervalu (3a + b)/4 in b

or (mflag = 1 and |s−b| ≥ |b−c| / 2) or (mflag = 0 and |s−b| ≥ |c−d| / 2) or (mflag = 1 and |b−c| < |δ|) or (mflag = 0 and |c−d| < |δ|) then

� I ∶= Sha�

� mflag = 1 o else

� mflag = 0 o end if o izračunaj f(s) o d := c o c := b o if f(a) f(s) < 0 then b := s else a := s end if o if |f(a)| < |f(b)| then swap (a,b) end if

• end repeat • output b or s

Programska koda 5: Psevdokod Brentove metode

Imamo torej vhodna približka a0 in b0 (programska koda 5). Za ta dva približka

izračunamo funkcijske vrednosti f(a0) in f(b0), a0 in b0 pa moramo izbrati tako, da bosta

funkcijski vrednosti nasprotnega predznaka. S tem zagotovimo, da je rešitev v intervalu

[a0, b0].

Ko vstopimo v zanko, v prvem koraku vedno uporabimo linearno interpolacijo. Če

dobljeni koren ni v intervalu [3a0 + aij , b0] ali pa je izpolnjen eden izmed dveh poprej


definiranih pogojev, koren ni sprejet in ga moramo v aktualnem koraku poiskati z

bisekcijo. Za poiskan koren izračunamo še funkcijsko vrednost in preverimo, če nam ta

vrednost že zadošča. Sicer nadaljujemo, dokler ne dosežemo praga, kjer je rešitev za nas že

sprejemljiva.

Tudi pri implementaciji Brentove metode smo se oprli na obstoječo rešitev.

[http://www.rnfc.org/rhapsody/math/OPTIM_UNIVAR_MIN_MAX_LIBR.bas]

5.5.8 Generiranje kroženja

Kromosom, ki predstavlja naše kroženje, trenutno sestoji zgolj iz parametrov.

Zaradi težjih matematičnih konstruktov vse operacije s kroženjem (izračun razdalj in

podobno) ne bomo naredili po izključno analitični poti, temveč bomo generirali vmesne

točke, ki jih bomo nato interpolirali, da dobimo predstavitev dejanskega kroženja. Naše

kroženje bo tako:

• premočrtna enakomerno potojuča krožnica z relativno enakomerno kotno hitrostjo

o Izraz »relativno« se tu nanaša na celotno populacijo, saj je konta hitrost

skupna samo enem kromosomu in se skozi populacijo praviloma spreminja.

Tukaj faktorja vetra ne upoštevamo.

• premočrtna s sinusoidno se spreminjajočo se hitrostjo potujoča krožnica

o Tukaj pride do izraza faktor vetra, saj je premik centra kroženja v smeri

vetra sinusna funkcija.

V obeh primerih povečujemo vse parametre kromosoma (kot s kotno hitrostjo,

pozicijo centra kroženja s hitrostjo vetra v odvisnosti od vetrovnega faktorja) z diskretnimi

koraki, da dobimo diskreten nabor točk, ki nam predstavlja kroženje. Diskretni koraki so

tako majhni, da je relativna napaka zanemarljiva.

5.5.9 Zagon genetskega algoritma

Definirali smo vse potrebno za zagon genetskega algoritma. Predstavili smo

problem in ga transformirali za uporabo evolucijskih pristopov. Pripravili smo

inicializacijo in s tem začetne približne oziroma predvidevane rešitve, kamor hočemo, da


algoritem konvergira. Definirali smo funkcijo uspešnosti in kazensko funkcijo, pripravili

genetske operatorje. Sedaj sledi zagon algoritma in prilagajanje parametrov, kar je

potencialno dolgotrajen proces. Poglejmo si parametre za zagon:

• število generacij (koliko generacij želimo proizvesti) in

• velikost populacije (koliko kromosomov želimo, da ima ena populacija).

Pred zagonom si poglejmo celoten psevdokod našega genetskega algoritma

(programska koda 6). Najprej moramo izračunati začetni približek. To zahteva izračun

pričakovanega polmera krožnice in kotno hitrost, ki jo bo kroženje imelo. Ta kotna hitrost

je umetni konstrukt in se modificira v samem genetskem algoritmu na tak način, da se

najbolje prilagaja vhodnemu naboru točk. Pričakovani polmer pa dobimo, ko izračunamo

smer vetra. To namreč storimo z iskanjem minimalnega obsegajočega pravokotnika,

katerega daljša stranica je praviloma vzporedna s smerjo vetra. Krajša stranica nam da že

precej dober približek premera kroženja, saj celotno kroženje predstavlja zgolj premik

kroga v smeri vetra, dobljeno sled premika pa opisuje kar minimalni obsegajoči

pravokotnik (slika 9).

Določiti moramo še začetek kroženja, kar pomeni, da moramo hkrati definirati še

smer gibanja krožnice, ki je hkrati smer vetra. Da nam bo lažje, rotiramo koordinatni

sistem tako, da bo smer vetra vzporedna z ordinato (slika 15). Koordinato x začetne točke

dobimo, če vzamemo aritmetično sredino projeciranih vhodnih točk od p0 do pn (slika 15).

Približek koordinate y začetne točke izračunamo z Brentovo metodo iskanja korena enačbe

– za funkcijsko vrednost namreč vzamemo kar evalvacijsko funkcijo genetskega algoritma,

rešitev minimizacije pa bo kar y koordinata. S tem korakom bomo celotno kroženje

premikali v smeri vetra, dokler ne bomo presegli zadovoljivega praga evalvacijske

funkcije.


Slika 15: Rotacija koordinatnega sistema in projekcija točk na absciso

Imamo začetni približek, zato lahko generiramo začetne generacije z minimalnimi

odstopanji. Skladno z genetskim algoritmom (programska koda 4) del vsake generacije

mutiramo s poprej definiranimi genetskimi operatorji. S tem spreminjamo in prilagajamo

kroženje, na koncu pa ovrednotimo rezultat mutacije. Skladno z uspešnostjo posameznih

kromosomov izvršimo še selekcijo, kjer uporabimo elitizem in odstranimo 30 procentov

najslabših kromosomov.

Korake ponavljamo tako dolgo, dokler ne dosežemo zadovoljivega praga

evalvacijske funkcije.


• Računanje začetnega približka 1. Izračunavanje pričakovanega polmera krožnice 2. Izračunavanje pričakovane kotne hitrosti 3. Določitev začetne točke

� Rotacija koordinatnega sistema v smeri vetra (le navidezno za lažjo predstavo računanja)

� Aritmetična sredina v smeri poti za koordinato x � Brentova optimizacijska metoda za določanje začetka poti za

koordinato y • Evolucijsko prilagajanje

1. Generiranje začetnih približkov s pričakovanimi odstopanji 2. Mutacija

� Sprememba polmera � Sprememba kotne hitrosti (velja za +- [smer vrtenja]) � Sprememba začetne točke v smeri potovanja � Sprememba začetne točke v smeri, pravokotno na smer

potovanja 3. Evalvacija

� Seštevek najmanjših oddaljenosti vseh točk do generiranega kroženja

� Kaznovanje odstopanja od pričakovane dolžine kroženja � Vsak posameznik se urejeno uvrsti v seznam trenutne

generacije, da se ohranja urejen po evaluaciji 4. Selekcijski algoritem

� Elitizem – 30 % najslabših primerkov v generaciji odmre 5. Če je evaluacijska vrednost prvega primerka v trenutni generaciji

primerna ali pa smo zaključili maksimalno število ciklov oz. generacij, končamo; sicer se vrnemo na korak 2.

Programska koda 6: Psevdokod rekonstrukcijskega algoritma

5.5.9.1 Testni primeri

Za lažjo implementacijo je bilo smiselno, da smo na začetku za testiranje generirali

lastne vhodne podatke. To je trivialna operacija, saj potrebujemo samo kromosom,

katerega parametre si preprosto izmislimo. Za lažjo predstavitev si generirano kroženje

vizualiziramo. Na sliki lahko vidimo vse parametre, ki jih lahko prilagajamo, prav tako pa

lahko opazimo, da se že avtomatsko generira MBR nad danim naborom točk. Kot lahko

vidimo, se pri smeri vetra nismo zmotili (slika 16), čeprav smo imeli na voljo samo 8 točk.

Smer kaže iz zgornjega levega kota, kjer se kroženje prične, proti spodnjemu desnemu

kotu, kamor letalo nese veter.


Slika 16: Rekonstrukcija - testni primerek

Rekonstrukcijo poženemo s parametri 50 generacij in 75 kromosomi na populacijo.

Za funkcijo uspešnosti podamo minimalno oddaljenost od točk oziroma prilagoditveno

funkcijo, saj so ostale dve funkcijo uporabne samo za kontrolo obstoječe rešitve. Lahko

podamo tudi orientacijo kroženja, vendar smo to zaenkrat zanemarili (generirajo se

kroženja tako v pravo kot tudi v nasprotno smer urinega kazalca). V rezultatu, ki je

prikazan s sivo potjo (slika 17), lahko vidimo, da je kroženje, ki je začelo svojo pot v

zgornjem levem kotu in nadaljevalo v izračunani smeri vetra proti spodnjemu desnemu

kotu, zavzelo prav presenetljivo (a nikakor ne pogosto) vse točke, čeprav je zavzelo ravno

nasprotno smer kroženja, kot bi moralo (testni primerek je imel smer kroženja kakor urin

kazalec, generirani pa ravno nasprotno).


Slika 17: Rekonstrukcija – primer napačne rešitve testnega primerka

Rekonstrukcijo poženemo še enkrat, a tokrat vsilimo smer kroženja. Tokrat je

algoritem našel povsem dobro prilegajočo se rešitev (slika 18), kjer ne potrebujemo

posebnega interpoliranja točk. Moramo tudi vedeti, da so aktualni parametri rekonstrukcije

(50, 75) dokaj blagi v smislu računske zahtevnosti, zato lahko hitro najdbo rezultata

ocenimo kot uspešno.

Slika 18: Rekonstrukcija: primer dobre rešitve testnega primerka


5.5.9.2 Aktualni primeri iz realnega sveta

Ker so v realnem svetu problemi pogostokrat težji od teoretičnih, si poglejmo

primer dejanskega poleta letala, kjer je bil časovni interval kroženja 12 sekund, kar za

vizualizacijo ni posebej ugodno (slika 19). Črne točke predstavljajo diskreten nabor

vhodnih točk oz. znane koordinate, na katerih se je letalo med poletom nahajalo. Z rdečo

barvo je označena interpolacijska krivulja med vhodnimi točkami, a zaradi visokega

časovnega intervala med točkami prikaza bistveno ne izboljša.

Slika 19: Primer realnega kroženja z visokim časovnim intervalom

Rekonstrukcijo poženemo s 100 generacijami in 300 kromosomi. Levi stolpec

(slika 20) nam predstavlja rešen problem za kroženje v nasprotni smeri urinega kazalca,

desni (slika 20) pa pravi smeri. V obeh stolpcih imamo s sivo barvo prikazano generirano

rešitev, z modro barvo pa je na obeh vrhnjih slikah označena interpolacijska krivulja med

vhodnimi točkami – s tem lahko hitro razberemo sosledje točk. Za evalvacijsko funkcijo

uporabimo funkcijo prilagajanja, ki se od vseh izkaže najbolje.

Oba primera pustita odprto interpretacijo o tem, ali je rešitev prava ali ne, saj je ne

poznamo. Preverimo lahko zgolj s sosledjem točk (funkcija vrstnega reda točk), ki je pri

levem napačna, pri desnem pa prava. Lahko tudi izmerimo povprečno razdaljo, ki je bila

preletena med dvema točkama tik pred kroženjem – od razdalje med dvema točkama v


generiranem kroženju lahko odstopa nekaj procentov, sicer lahko sklepamo, da je

generirana pot napačna.

Slika 20: Primer rešitve realnega problema

5.5.10 Pristop »Deli in vladaj«

Ta pristop pride v poštev pri nenadnih sunkih. Včasih se namreč zgodi, da se

navidezni center kroženja zamakne. Takrat naš aktualni algoritem ne pride v poštev, saj gre

dejansko za dve različni kroženji. In če predpostavimo, da se to zgodi enkrat ali večkrat,

moramo naš algoritem ustrezno prirediti.

Tu pride na vrsto princip »deli in vladaj«, kjer naš problem razdeljujemo tako

dolgo, dokler ne naletimo na segment, ki je rešljiv. Rešljivosti pa na žalost ne moremo

preveriti takoj, temveč se moramo problema lotiti. Tako dejansko rešujemo problem samo

tako dolgo, za kolikor smo specificirali časovni prag reševanja. Nato problem razdelimo na

podprobleme. Točko razdelitve lahko določimo z binarnim cepljenjem, lahko pa jo

določimo tam, kjer menimo, da se je sunek dogodil. Vendar je ta metoda cepljenja oziroma


razdelitve zgolj teoretična in jo je še potrebno implementirati. Tako rešujemo več

problemov paralelno, katerim je skupna samo smer vetra, vsi ostali parametri pa lahko

malenkostno odstopajo.


6 Vizualizacija

Podatki o letu so opisani z geografskim koordinatnim sistemom, ki predvideva, da

lahko vsako lokacijo na Zemlji opišemo z naborom koordinat oziroma točk. Da let pravilno

izrišemo, moramo poprej definirati projekcijo, s katero bomo predstavili let.

6.1 Projekcija

Dvodimenzionalno projekcijo sveta lahko konstruiramo v dveh korakih:

• izberemo model, navadno sferoid ali elipsoid, ki aproksimira obliko zemlje in

• transformiramo geografske koordinate v kartezične (x,y).

Točke so navadno opisane z dvema ali tremi parametri za predstavitev horizontalne

komponente in z eno vertikalno komponento.

Najbolj intuitivna predstavitev horizontalne komponente premore dva parametra –

longitudo in latitudo – to pa lahko opišemo v kartezičnem koordinatnem sistemu kot točko

(x, y) oziroma (x,y,z), v kolikor upoštevamo višino. Pogoste pa so tudi horizontalne

predstavitve s tremi parametri, bolj znane pod imenom n-vektorji. Gre za tri-parametrično

nesingularno horizontalno pozicijsko predstavitev, ki se uporablja predvsem pri

matematičnih kalkulacijah in računalniških algoritmih. Geometrično gledano nam je

opisana točka enotski vektor, ki je pravokoten na referenčni elipsoid.

Referenčni elipsoid je matematično definirano površje, ki aproksimira geoid

oziroma druga geometrična telesa, ki se uporabljajo za predstavitev oblike Zemlje. Ker so

ti elipsoidi po navadi precej poenostavljeni in za kompleksno matematično ali algoritmično

rabo niso zahtevni, se zato pogosto uporabljajo pri geodetskih izračunih [Snyder, 1995].

Ker je horizontalni vektor, sestavljen iz treh komponent, normaliziran, je postavljen

v statični koordinatni sistem, ki je centriran okoli samega centra Zemlje. Velja za vsakršno

pozicijo na Zemlji in je matematično ekvivalenten dvokomponentnemu horizontalnemu

vektorju. Pri takšnem prikazu moramo predpostaviti, da je naš referenčni lik striktno

konveksen.


Poglejmo si komponente vektorja, izražene z bolj intuitivnim dvokomponentnim

prikazom:

�� = kcos(-,.G.lH,) cos (-m�JG.lH,)cos(-,.G.lH,) sin(-m�JG.lH,)sin (-,.G.lH,) n

Pretvorba trikomponentnega vektorja v dvokomponentni vektor:

-m�JG.lH, = ,.,�2(��o , �p�)

-,.G.lH, = asin(�q�) = ,.,�2(�q� , N(�p�)� + (�� )�)

V naših izračunih bomo redko uporabljali tovrsten prikaz, a je za hitrost realno-

časovnih izračunov takšna predstavitev koordinat vseeno bolj primerna in jo je potrebno

ohraniti za prihodnjo implementacijo algoritmov za analizo podatkov.

Poglejmo si za nas bolj pomembni dvokomponentni horizontalni vektor, ki definira

ekliptični koordinatni sistem. Prva komponenta, latituda, predstavlja kot med ekvatorsko

ravnino in premico, ki je pravokotna na referenčni elipsoid. Meri se po krogu, ki gre skozi

severni in južni pol ekliptike. Latituda lahko zavzame vrednosti samo v mejah -90° do

vključno 90° (slika 21), v kolikor za predstavitev vrednosti uporabljamo decimalne

stopinje. Nabori točk, ki imajo enake latitude, se imenujejo paralele ali vzporedniki in

tvorijo koncentrične kroge na površju Zemlje, vzporedno z ekvatorjem.

Slika 21: Projekcija sveta


Druga komponenta, longituda, predstavlja kot med referenčnim poldnevnikom

(sčasoma je to po mednarodni potrditvi postal Greenwich) in tistim poldnevnikom, ki gre

skozi opazovano točko. Poldnevniki tvorijo t.i. velike kroge in za razliko od paralel niso

vzporedni, temveč konvergirajo v severnem in južnem polu. Longitude lahko zavzamejo

vrednosti med vključno 0 in izključno 180°.

Pri mejah smo v obeh primerih uporabili decimalne stopinje. Te izražajo longitude

in latitude v decimalnih frakcijah, uporabljajo pa se v večini geografskih informacijskih

sistemih, internetnih kartografskih ponudnikov (med drugim tudi Google Maps) in GPS

napravah. Tipična predstavitev točke bi tako bila {46.558961, 15.641258}, kjer prva

komponenta (latituda) opisuje zemljepisno širino 46° 33' 32.259" (46 stopinj, 33 minut in

32.259 sekund) in zemljepisno dolžino 15° 38' 28.5288".

Zaradi pogoste uporabe kotnih funkcij bo za nas zanimiv tretji prikaz v radianih, pri

čemer je en radian razmerje med dolžino kotnega loka in polmerom. Opisano koordinato v

decimalnih stopinjah pomnožimo s posebno konstantno r�s>, ki po množenju znaša {

0.812607, 0.272991 } in opisuje lokacijo Fakultete za elektrotehniko, računalništvo in

informatiko.

Z opisom v radianih ugotovimo, da absolutne vrednosti koordinat ne bodo nikoli

presegale π za longitude oziroma r� za latitude, pri čemer moramo obvezno za opis

koordinat vzeti tip s pomično vejico in dvojno natančnostjo.

6.2 Transformacija

Imamo podatke o letu v radianih. Da jih izrišemo na zaslon, moramo narediti

transformacijo koordinat. Za prikaz želimo porabiti celoten zaslon, s tem tudi robove, zato

bo transformacija cilindrična. Oprli se bomo na znano Mercatorjevo projekcijo (slika 22),

ki je najbolj uporabna za računalniški prikaz podatkov.

Predpostavimo, da poznamo dimenzije prikazovalnega zaslona, kamor želimo

projecirati podatke. Določiti moramo posebne faktorje kx, ky, nx in ny, da bomo lahko

zapisali:

" = tm�JG.lH, ∗ !u + �p


= t,.G.lH, ∗ !� + ��,

pri čemer x in y predstavljata pozicijo piksla na zaslonu, Longituda in Latituda pa zapis

točke leta v času.

Slika 22: Primer Mercatorjeve projekcije

Pri Mercatorjevi projekciji lahko hitro ugotovimo, da je transformacija longitude

linearna, saj so odmiki posameznih poldnevnikov konstantni. Drugače pa je pri

vzporednikih, ki se spreminjajo sinusno glede na pozicijo v svetu. Če definiramo širino

zaslona kot w in višino zaslona kot h, lahko transformacijske faktorje zapišemo na sledeč

način:

!� = v��, !p = − cos(t,.G.lH,) !�

�� = ℎ2 − !� t,.G.lH,, �p = C2 − !p tm�JG.lH,

S temi enačbami lahko izvršimo transformacijo, ki je potrebna, da lahko let

izrišemo na zaslon.


6.3 Izris

Izris (slika 23) je posledica sledečih procesov:

• interpretiranje podatkov iz IGC datoteke,

• rekonstrukcija podatkov in

• transformacija na zaslon.

Slika 23: Vizualizacija leta

Dobimo lepo interpolirano pot letala, kakršna bi naj bila v realnosti. Ker je predmet

diplomske naloge rekonstrukcija in vizualizacija poleta, se ozadja nismo posebej dotikali,

zato je slika na prvi pogled zelo pusta. Vendar smo se obrobno dotaknili vektorskih

podatkov, ki nam predstavljajo površje zemlje (višinske konture, reke, ceste, železnice in

podobno). Definirali smo vse konstrukte, da tovrstne vektorske podatke prikažemo na

zaslon na isti način, kakor smo to naredili z letom. S tem vizualizacija dobi dodatne

razsežnosti, saj si lahko let bistveno bolje predstavljamo.

Let Janeza Novaka (programska koda 3) smo uspešno predstavili na zaslonu (slika

19). Odpravili smo vse anomalije, saj je krivulja leta prikazana zvezno in brez posebnih

zamikov, ki bi bili posledica napak zapisovalnika GPS.


7 Sklep

Rezultati rekonstrukcije so delno uspešni, saj ne dobimo vedno nedvoumne rešitve.

To je delno posledica genetskega algoritma, ki skoraj nikoli ne daje enakih rezultatov za

enake probleme, saj je osnovan na generatorju naključnih števil.

Če pregledamo rekonstrukcijo v celoti, lahko ugotovimo, da ugodno reši testne

primerke, ki smo jih generirali sami. Pri primerkih iz realnega sveta se algoritem ne obnese

najbolje, saj ga moramo upravljati ročno in še to ne zagotovi končne ugodne rešitve.

Pristop »Deli in vladaj« je smiseln in ponuja obetavno pot do rešitve, pri čemer je potrebno

poprej razdeljevalno metodo ustrezno implementirati.

Izboljšave so možne tudi pri ostalih specificiranih algoritmih, ki na določenih

odsekih niso popolnoma optimizirani, saj je omenjeni projekt še vedno v razvojni fazi, tako

da tovrsten nivo optimizacije še ni bil potreben. Če zanemarimo problem kroženja, smo

rekonstrukcijo leta izvedli v celoti.

Z interpretacijo vhodnih podatkov nismo imeli večjih težav, vendar smo morali v

sklopu rekonstrukcije vseeno zagotoviti odpravo anomalij in podobnih težav, povezanih z

zapisovalniki GPS. Vizualizacija je zahtevala definicijo projekcije, v prihodnje pa bo

nadgradnja zunaj te diplomske naloge zagotovo implementacija prikaza vektorskih

podatkov s površja Zemlje.


8 Priloge

8.1 Viri

N. Bornstein, E. Dumbill, Mono: A Developer's Notebook, O'Reilly, 2004.

FAI, Technical specification for IGC-approved GNSS flight recorders, 2008.

M. Mernik, Evolucijski algoritmi, Fakulteta za elektrotehniko, računalništvo in

informatiko, Maribor, 2003.

J. Snyder, Map Projections: a reference manual, Boston University, Massachusetts, 1995.

G. Toussaint, Solving Problems with the Rotating Calipers, School of Computer Science,

McGill University, Montreal, 1983.

A. Troelsen, Pro C# 2008 and the .NET 3.5 Platform, 4th Edition, Berkley, 2007.


Življenjepis

Ime in priimek: Simon Irmančnik

Rojen: 4. marca 1984 v Celju

Osnovna šola: 1991-1999 OŠ Braslovče

Srednja šola: 1999-2003 Šolski center Celje, Splošna in

strokovna gimnazija Lava

Fakulteta: 2003- Fakulteta za elektrotehniko,

računalništvo in informatiko,

Univerza v Mariboru,

univerzitetni program

Računalništvo in informatika,

smer Programska oprema

Fakulteta: 2008-2009 Fakulteta za strojništvo,

Tehniška Univerza v

Münchnu, izmenjava in

priprava na diplomsko nalogo

Rekonstrukcija in vizualizacija poletov letal in jadralcev

a in vizualizacija poletov letal in jadralcev

72

Rekonstrukcija in vizualizacija poletov letal in jadralcev

a in vizualizacija poletov letal in jadralcev 73

Documents

REKONSTRUKCIJA IN VIZUALIZACIJA POLETOV · PDF fileuniverza v mariboru fakulteta za elektrotehniko, ra ČunalniŠtvo in informatiko simon irman čnik rekonstrukcija in vizualizacija