% Diplomityö, the savotta, Kimmo Koskinen, kimmo.m.koskinen@lut.fi
% $Id: di.tex 85 2005-10-05 09:28:53Z viesti $
\documentclass[a4paper,11pt,oneside]{book}
\usepackage[latin1]{inputenc} % syöttökieli
\usepackage[finnish]{babel} % tavutus
\usepackage{graphicx} % kuvat
\usepackage{hyperref} % pdf -asetukset
%\usepackage{times} % Times -fonttipaketti
\usepackage[T1]{fontenc} % skanditavutus
\usepackage{setspace} % rivivälit
\usepackage{url} % URLit mukavemmin tavutettuina
\usepackage{verbatim} % \verbatiminput{}
\usepackage{tabularx} % solujen jako käyttävissä olevan tilan mukaan
\usepackage{nameref} % viittaukset nimilabelilla
\usepackage{glosstex} % lyhenteet .gdf -tiedostoon, käyttö: \ac{lyhenne}
\usepackage{placeins} % \FloatBarrier
\usepackage{parskip} % vasensuora-asettelu paragraafeille
\usepackage{textcomp} % Celsius -merkki
\usepackage[square,comma,numbers,sort&compress]{natbib} % Lähdeviiteasetuksia
\usepackage[left=40mm,top=35mm,right=20mm]{geometry} % marginaalit
% hyperref -juttuja pdf:ään
\hypersetup{pdfsubject={Diplomityö}}
\hypersetup{pdfauthor={Kimmo Koskinen}}
\hypersetup{pdftitle={Paikka- ja tilannetiedon hyödyntäminen sovelluksissa}}
% lyhenneluettelo suomeksi
\def\listacronymname{Lyhenneluettelo}
% samoin sisällysluettelo, babel-finnish sanoisi ``sisältö'' mutta kuulostaa hassulta...
\addto\captionsfinnish{\renewcommand{\contentsname}{Sisällysluettelo}}
% komennot joilla voidaan listata...
\newcommand*{\OrigChapter}{}
\let\OrigChapter\chapter
\newcounter{abstables}
\newcounter{absfigures}
\renewcommand*{\chapter}{%
\addtocounter{abstables}{\value{table}}%
\addtocounter{absfigures}{\value{figure}}%
\OrigChapter
}
% ...taulukoiden määrä...
\newcommand*{\AbsTables}{0}
\makeatletter
\AtBeginDocument{%
\AtEndDocument{%
\addtocounter{abstables}{\value{table}}%
\immediate\write\@mainaux{%
\string\gdef\string\AbsTables{\number\value{abstables}}%
}%
}%
}
\makeatother
% ...ja kaavioiden määrä
\newcommand*{\AbsFigures}{0}
\makeatletter
\AtBeginDocument{%
\AtEndDocument{%
\addtocounter{absfigures}{\value{figure}}%
\immediate\write\@mainaux{%
\string\gdef\string\AbsFigures{\number\value{absfigures}}%
}%
}%
}
\makeatother
% tavutusneuvoja
\hyphenation{kom-po-nent-ti}
% Ja tästä alkaa itse teksti
\begin{document}
\thispagestyle{empty}
\doublespacing
\large{LAPPEENRANNAN TEKNILLINEN YLIOPISTO}\\
\large{TIETOTEKNIIKAN OSASTO}\\
\vfill
\Large{PAIKKA- JA TILANNETIEDON HYÖDYNTÄMINEN\\SOVELLUKSISSA}
\normalsize
\vfill
Diplomityön aihe on hyväksytty Tietotekniikan \\
osaston osastoneuvostossa 17.08.2005\\
Työn tarkastajat: Jouni Ikonen, Kari Heikkinen\\
Työn ohjaaja: Kari Heikkinen\\
\vfill
Kimmo Koskinen\\
Orioninkatu 1 A 7\\
53850 Lappeenranta\\
kimmo.m.koskinen@lut.fi\\
050-5338 473
\newpage
\setcounter{page}{1}
\renewcommand{\thepage}{\Roman{page}}
\onehalfspacing
\section*{TIIVISTELMÄ}
Lappeenrannan teknillinen yliopisto
Tietotekniikan osasto
Kimmo Koskinen
\textbf{Paikka- ja tilannetiedon hyödyntäminen sovelluksissa}
Diplomityö
2005
56 sivua, \AbsFigures{} kaaviota, \AbsTables{} taulukkoa ja 4
liitettä.
Tarkastajat: Dosentti Jouni Ikonen, TkT Kari Heikkinen
Hakusanat: paikkatieto, tilannetieto
\hfill{}
\singlespacing
Erilaisten mobiiliverkkojen käytön yleistyessä nousee esiin
uudenlaisia sovellusalueita, kuten esimerkiksi paikkatietoiset
sovellukset. Mobiiliudesta johtuen sovellusten käyttötilanteet
vaihtelevat. Käyttötilanteista voidaan kerätä tietoa ja käyttää tätä
hyödyksi. Tilannetiedolla tarkoitetaan sovelluksen käyttötilanteeseen
tai käyttäjään liittyvää lisätietoa.
Paikka- ja tilannetietoisten sovellusten kehittäminen vaati monia
ohjelmistokehitystä tukevia järjestelmiä. Tilannetiedon väljän
määritelmän takia tilannetietoisten sovellusten kehitykselle ei ole
vielä selkeitä toimintamalleja. Tilannetietoisten sovellusten
kehitystä avustavia järjestelmiä on luotu etenkin tutkimuksessa, mutta
nämä eivät ole vielä yleistyneet laajempaan käyttöön. Paikkatiedon
käyttö sen sijaan on hyvinkin standardoitua, mutta paikkatieto nähdään
vain osana tilannetietoa.
Tässä diplomityössä toteutettiin paikka- ja tilannetiedon
sovelluskehitystä tukevia järjestelmiä, joilla paikka- ja
tilannetiedon hyödyntäminen sovelluksissa mahdollistettiin. WLAN
-verkosta saadun paikkatiedon hyödyntämiseen toteutettiin SOAP
-palvelurajapinta. Tilannetiedon hyödyntämiseksi toteutettiin MUPE
-sovellusympäristöön välittäjäkomponentteja paikka-, sää- ja
kuntopyörän harjoitustiedolle sekä RFID
-ha\-va\-in\-to\-tie\-doil\-le. Näitä komponetteja käytettiin
tilannetietoisten sovellusten luomiseen sekä tietoliikennetekniikan
laitoksen codecamp -kursseilla, että tilannetietoisessa
pelisovelluksessa. Työn tuloksena saatiin toimivia sovelluksia, ja
välittäjäkomponentit sovellusten luomiseen. Työn tuloksena voidaan
todeta, että ilman tilannetietoista sovelluskehitystä tukevia
komponentteja, olisi tämäntyyppinen sovelluskehitys huomattavasti
vaativampaa. Tukevat komponentit helpottavat sovelluskehitystä, mutta
helposti myös rajaavat kehitysmahdollisuuksia.
\newpage
\onehalfspacing
\section*{ABSTRACT}
Lappeenranta University of Technology
Department of Information Technology
Kimmo Koskinen
\textbf{Utilisation of Location and Context Information in Applications}
Masters Thesis
2005
56 pages, \AbsFigures{} figures, \AbsTables{} tables
and 4 appendices.
Supervisors: Docent Jouni Ikonen, Dr. Tech. Kari Heikkinen
Keywords: location information, context information
\hfill{}
\singlespacing
New application areas, such as location aware applications, are
emerging with the development of different mobile networks. Due to
mobility, the context in which applications are used varies. Context
information can be gathered and used in applications. Context
information means in this thesis information related to the user or
the usage of the application.
Supporting systems are needed for the development of location and
context aware software. Due to the loose definition of context
information, there are no distinguished functional frameworks for
developing context aware applications. System supporting context
awareness have been created in research but these are not in common
use. Usage of location information is more standardised but location
information is usually seen only as part of context information.
In this thesis, systems for supporting context aware software
development were implemented and used in software development. A SOAP
-interface was implemented to use WLAN cell positioning data. Context
information relaying components were implemented for MUPE -platform to
provide location, weather, fitness bicycle exercise data and RFID
proximity data. These software components were used in creating
context aware applications in the courses of the laboratory of
communications engineering and in a context aware game application.
The results of the work were functional applications and relaying
components for use in MUPE application development. As a result of the
work it can be concluded that context aware software development would
be much more demanding without software components that ease the
development process. Supporting components generalise the development
process but they can also restrict development possibilities.
\newpage
\section*{ALKUSANAT}
Tämä työ on tehty Lappeenrannan teknillisen yliopiston
tietoliikennetekniikan laitoksella sekä WLPR.NET että AMPERS
-projekteille.
Haluan kiittää työni tarkastajaa Jouni Ikosta hänen luomastaan hyvästä
työilmapiiristä tietoliikennetekniikan laitoksella. Hänen avullansa
sain kokemusta, jonka saavuttaminen on minulle ainutlaatuista. Haluan
kiittää myös ohjaajaani Kari Heikkistä hänen monista ideoistaan sekä
uusiin työalueisiin tutustuttamisesta.
Haluan kiittää myös tietoliikennetekniikan laitoksen monia
työntekijöitä, Tomi Lapinlampea, Harri Hämäläistä, Radek
Sp\'a\v{c}ilia, Aki Honkasuota, Arto Hämäläistä sekä monia muita,
joiden nimen unohdin mainita. Omalta osaltaan autoitte ja rohkaisitte
työskentelyäni tietoliikennetekniikan laitoksella ja annoitte monta
inspiraatiota.
Erityisesti haluan kiittää Katriina Saransaarta hänen tuestaan työtä
kirjoittaessani. Ilman häntä en olisi tähän pisteeseen päässyt.
\newpage
% riviväli 1,5
\onehalfspacing
% sisällysluettelo
\pagestyle{plain}
\tableofcontents
% lyhenneluettelo
\printglosstex(acr)
% luettelo kuvista
\listoffigures
% luettelo tauluista
\listoftables
% ja johdannosta se alkaa...
\pagestyle{headings}
\chapter{Johdanto}
\setcounter{page}{1}
\renewcommand{\thepage}{\arabic{page}}
Erilaisten mobiiliverkkojen käytön yleistyessä nousee esiin
uudenlaisia sovellusalueita. Tällaisia sovellusalueita ovat
esimerkiksi paikkatietoiset sovellukset. Mobiiliudesta johtuen
sovellusten käyttötilanteet vaihtelevat. Eri käyttötilanteista voidaan
myös kerätä tietoa ja käyttää tätä hyödyksi sovelluksissa. Käyttäjän
käyttötilanteeseen liittyvää tietoa voi olla esimerkiksi paikallisen
sään lämpötila. Tilannetiedolla (konteksti- tai asiayhteystieto)
tarkoitetaan sovelluksen käyttötilanteeseen tai käyttäjään liittyvää
lisätietoa. Paikkatieto nähdään usein osana tilannetietoa. Esimerkki
tilannetietoisesta sovelluksesta on vaikkapa kaupunkiopassovellus
matkapuhelimessa, joka nähtävyyden ohi käveltäessä muistuttaa läheisen
ravintolan lounastarjouksesta.
%Esimerkki tilannetietoisesta sovelluksesta !! tarkoitus saada lukija
%``kartalle''
%GUIDE -projekti
Paikkatiedon keräämiseen on kehitetty erilaisia tekniikoita. Näitä
ovat mm. satelliittipaikannus ja maanpäällisten
tietoliikenneverkkojen käyttäminen käyttäjien päätelaitteiden paikan
määrittämisessä. Riippuen käytetystä paikannusjärjestelmästä,
vaihtelee paikkatiedon saantitapa, tarkkuus, varmuus sekä kattavuus.
Tässä työssä tarkastellaan erilaisia paikantamiseen käytettävissä
olevia järjestelmiä, sekä esitellään WLAN -verkkoon kehitetty
paikannusrajapinta.
Tilannetiedolla voidaan käsittää hyvinkin monia asioita. Paikkatiedon
määrittelemä sijaintitieto voidaan nähdä yhtenä tilannetiedon osana.
Esimerkiksi käyttäjän kulloinenkin sijainti on osa käyttäjään
liittyvää tilannetietoa. Samoin käyttäjän sijainnissa vallitseva
lämpötila on esimerkki tilannetiedosta. \textit{Eri lähteistä
koostuvan tilannetiedon hyödyntäminen sovelluksissa vaatii
ymmärrystä eri tietojärjestelmistä (esimerkiksi tietotyypit,
rajapinnat, protokollat).} Tilannetiedon lähteet voivat olla
hyvinkin vaihtelevia riippuen tilannetiedon tyypistä. Eri lähteiden
käyttöä taas helpottavat ohjelmistoalustat, joilla tilannetiedon
käyttöä voidaan hallita. Tällaisen käytön hallintaan kuuluu mm.
yhtenäiset protokollat ja välittäjäohjelmistot (esimerkiksi
\ac{MUPE}\footnote{\url{http://www.mupe.net}}). Kun tilannetieto on
saatu sovellukseen, voidaan sillä laukaista toimintoja esimerkiksi
ennalta määritellyin säännöin. Esimerkiksi MUPE -ympäristö
mahdollistaa edellämainituin tavoin nopean sovelluskehityksen
\ac{MIDP} -laiteympäristössä. Erityisyys tällä alustalla on
tilannetiedon huomioonotto.
Diplomityön tavoitteena on analysoida paikka- ja tilannetiedon
keruujärjestelmiä, välitysjärjestelmiä (rajapinnat) sekä hyödyntämistä
sovelluksissa. Tavoitteet pyritään todentamaan sovelluksien avulla.
Työn arviointiosuudessa käydään läpi paikka- ja tilannetietoisten
ohjelmistojen kehityksessä esiin tulleita ongelmia käytettyjen
ohjelmistoalustojen ja metodien avulla.
Diplomityö on tehty LTY:n (Lappeenrannan Teknillisen Yliopiston)
tutkimuskeskus TBRC:n alaisessa \ac{AMPERS} -projektissa, jossa
kehitettiin sovelluksia MUPE -ympäristön avulla. Osa työstä on tehty
LTY:n Tietoliikennetekniikan Osastolla WLPR.NET -projektissa.
Paikkatiedon keräämiseen on käytetty WLPR.NET -projektissa luotua
\ac{WLAN} -verkkoa.
Tämä diplomityö koostuu viidestä kappaleesta. Ensimmäisessä
kappaleessa (johdanto) esitetään ratkaistava ongelma ja määritellään
ongelma-alue. Tämän lisäksi esitetään tavoitteet ja menetelmät joilla
ongelma pyritään ratkaisemaan. Toisessa kappaleessa analysoidaan
paikka- ja tilannetiedon nykytila. Kolmannessa kappaleessa todennetaan
tehdyt ratkaisut sovelluksien avulla. Neljännessä kappaleessa
arvioidaan toteutettuja ratkaisuja. Viidennessä kappaleessa esitetään
johtopäätökset.
\chapter{Paikka- ja tilannetieto}
Erilaisten mobiiliverkkojen yleistymisen johdosta tietoteknisiä
sovelluksia käytetään usein paikasta riippumatta eri
käyttötilanteissa. Päätelaitteiden sijainti pystytään olemassaolevin
keinoin päättelemään mahdollisesti usean eri järjestelmän avulla.
Paikkatiedon sisältö ja tarkkuus riippuu paikkatiedon hankintaan
käytetystä järjestelmästä. Seuraavassa kappaleessa tarkastellaan
paikkatiedon olemuksen määrittelyjä sekä erilaisia järjestelmiä,
joilla paikkatietoa voidaan kerätä.
Tilannetiedolla taas käsitetään yleisesti erilaisiin
käyttötilanteisiin liittyvää tietoa. Tämä tieto on yleisesti paljon
monimuotoisempaa kuin paikkatieto. Tämä näkyy myös erilaisten
tilannetietoisten sovellusten laajuudessa. Yleensä tilannetiedon
käsitetään olevan kuitenkin samassa asemassa paikkatiedon kanssa; sitä
voidaan käyttää palvelujen lisäarvona.
Paikka- ja tilannetieto voidaan yleensä liittää johonkin käyttäjään,
joka on luonnollinen henkilö. Monesti voi tulla tilanteita, jolloin
oman paikkatiedon antaminen muille ei ole haluttavaa, koska se
saattaisi loukata yksityisyyttä. Koska paikka- sekä tilannetieto ovat
käyttäjän henkilökohtaista tietoa, on otettava huomioon
henkilökohtaisen tiedon käsittelystä säädetyt lait ja määräykset.
Paikka- ja tilannetietojen yksityisyyttä on käsitelty myös
tieteellisessä tutkimuksessa. Esimerkiksi \emph{The Active Badge
Location System} -järjestelmässä \cite{want92active} tutkittiin
käyttäjien paikantamista ja paikkatiedon hyväksikäyttöä
infrapunalähettimien avulla. Tutkimuksessa rakennettiin
infrapunalähettimen sisältävien rintamerkkien seurantajärjestelmä,
jota käytettiin hyväksi mm. puhelinvaihteen työn helpottamiseksi
työntekijöiden paikantamisessa. Tutkimuksen aikana huomattiin, että
vaikka paikannusjärjestelmä olikin toiminnaltaan hyvä, eivät
työntekijät olleet vakuuttuneita henkilökohtaisen tietosuojan
hoitamisesta. Päähuomio oli, että järjestelmää pitää koekäyttää, että
käytön seuraukset tulisivat jokaiselle selväksi. Tutkimuksessa
huomioitiin myös, että yleinen käyttömuoto oli jättää infrapunalähetin
työpöydälle, kun oikeaa sijaintitietoa ei haluttu välittää. Onkin
huomattava että paikannusjärjestelmän paikantaman laitteen ja
käyttäjän välinen yhteys on häilyvä.
Suomen lainsäädännössä paikkatiedosta on säädetty 16.6.2004 voimaan
tulleessa Sähköisen viestinnän tietosuojalaissa \cite{tietosuojalaki}.
Tätä ennen paikkatietoa erityisesti käsittelevää lakia ole suomessa
ollut. Aiemmin paikkatietoa koskevia määrityksiä on jouduttu
tulkitsemaan sekä henkilösuojalain että lain yksityisyyden suojasta
televiestinnässä ja teletoiminnan tietoturvasta mukaan. Sähköisen
viestinnän tietosuojalaissa määritellään paikkatiedon olevan:
\begin{quote}
``tietoa, joka ilmaisee liittymän tai päätelaitteen maantieteellisen
sijainnin ja jota käytetään muuhun tarkoitukseen kuin verkkopalvelun
tai viestintäpalvelun toteuttamiseen''
\end{quote}
Paikkatiedoksi määritellään siis erityisesti paikannuspalveluissa
käytettävä käyttäjän paikkatieto. Pääpiirteet paikkatiedon käytöstä on
käsitelty luvussa 4. Lain mukaan ketään ei saa paikantaa ilman
suostumusta. Paikannukseen on siis saatava palvelukohtainen suostumus
ennen kuin paikannus voidaan aloittaa. Alle 15 -vuotiaan
paikannuspalveluiden käytöstä päättää huoltaja. Käyttäjän on myös
pystyttävä saamaan tietoa paikkatietojen tarkkuudesta, käytön
tarkoituksesta, kestosta sekä mahdollisuudesta luovuttaa paikkatietoja
kolmannelle osapuolelle. Käyttäjälle tulee olla myös helppo ja
maksuton tapa kieltää paikkatietojen käsittely. Hätätilanteesssa on
paikannuksen kuitenkin oltava aina mahdollista.
Hätäpaikannuksesta on säädetty myös yhdysvalloissa E911
-säännöksellä\footnote{\url{http://www.fcc.gov/911/enhanced/}}. Tämän
mukaan hätätilanteessa operaattorin tulee pystyä antamaan soiton
tehneen puhelimen sijainti. Euroopan laajuisesti vastaavaa on säädetty
Euroopan komission E112 -säädöksessä. Hätätilanteissa paikkatiedon
käyttö on hyvinkin oikeutettua. Yleisesti voidaan sanoa, että
paikkatiedon käsittelyssä tulisi noudattaa eettisiä sääntöjä, jotta
käyttäjien yksityisyyttä ei loukattaisi.
\section{Paikkatieto}
\label{sec:paikkatieto}
Jotta paikkatietoisia sovelluksia voitaisiin rakentaa, tarvitaan
paikkatiedolle määrittely. Paikkatiedon määrittely voi olla hyvinkin
sovelluskohtaista, riippuen sovelluksen käyttöalueesta, paikkatiedon
tarkkuudesta ja paikannettavista kohteista. Paikkatiedon määrittelyssä
tulisi erottaa paikkatietoa tuottavat järjestelmät ja paikkatietoa
kuvaavat tietorakenteet.
Paikkatiedolle on olemassa useita eri määrityksiä riippuen
käyttöyhteydestä. Esimerkiksi Sanastokeskus (TSK, Tekniikan
Sanastokeskus) on koostanut paikkatiedosta määrityksen
Paikannussanasto -julkaisussa \cite{paikannussanasto}. Paikkatieto on
tämän julkaisun mukaan määritelty seuraavasti:
\begin{quotation}
``\emph{paikannettua} kohdetta kuvaavan sijaintitiedon (1) ja
kohteen ominaisuuksia kuvaavien tietojen muodostama kokonaisuus''
\end{quotation}
Sijaintitiedolla (engl. location information) tarkoitetaan jonkin
kohteen sijaintia vertausjärjestelmässä (engl. reference system).
Vertausjärjestelmän avulla voidaan ilmaista yksiselitteisesti jonkin
kohteen sijainti. Vertausjärjestelmiä ovat mm. erilaiset
koordinaattijärjestelmät, kuten Suomessa käytössä oleva \ac{KKJ}
\cite{kkj}, mutta myös erilaiset katuosoitejärjestelmät.
Kohteen ominaisuuksia voivat olla vaikkapa väri tai kohteen koko.
Ominaisuustiedon liittäminen voi kuitenkin olla hyvin
sovelluskohtaista. Eri sovellukset hyödyntävät yleensä erilaisia
ominaisuustietoja ja kaikkia ominaisuustietoja ei voida olettaa
järkeväksi käsitellä kaikissa sovelluksissa.
Sijaintitiedon ilmaisemisen tarkkuuteen liittyvät sekä käytetty
vertausjärjestelmä että järjestelmä, jolla paikkatietoa kerätään.
Maailmanlaajuisesti katsottuna eri mailla on perinteisesti ollut omat
vertausjärjestelmänsä. Lisäksi maiden sisällä eri kaupungeilla voi
myös olla käytössä omat vertausjärjestelmänsä. Koordinaattipohjaiset
vertausjärjestelmät pohjaavat tiettyyn geodeettiseen datumiin.
Geodeettisillä datumeilla määritetään maapallon koko ja muoto sekä
käytetyn vertausjärjestelmän origo sekä orientaatio \cite{datumit}.
Eri vertausjärjestelmät voivat pohjata eri datumeihin, joka on
otettava huomioon tehtäessä muunnoksia koordinaatistosta toiseen.
\ac{EPSG} pitää kirjaa yleisimmistä koordinaattivertausjärjestelmistä
sekä parametreista, joita tarvitaan muunnoksiin eri koordinaatistojen
välillä\footnote{http://www.epsg.org/}. Muunnoksista voi aiheutua
virheitä riippuen tehdäänkö muunnos kahden eri datumia käyttävän
koordinaattivertausjärjestelmän välillä.
Vertausjärjestelmien moninaisuudesta johtuen yhteiselle
vertausjärjestelmälle on ollut tarve jotta paikkatietoa voitaisiin
käyttää maailmanlaajuisesti. \ac{WGS84} \cite{wgs84www} on
maailmanlaajuinen vertausjärjestelmä, joka on käytössä myös \ac{GPS}
-paikannusjärjestelmässä. Paikkatiedon käytön skaala ei kuitenkaan
aina ole maailmanlaajuinen. Esimerkiksi rakennuksien sisätilojen
paikkatietoa ei välttämättä ole mielekästä esittää
maailmanlaajuisella koordinaattijärjestelmällä. Rakennuksien sisällä
tarkkuudeksi voi riittää esimerkiksi huonekohtainen paikkatieto, mutta
tätä tietoa voi olla vaikea ilmaista käyttämällä esim. \ac{WGS84}
-koordinaattijärjestelmää. Huonekohtainen paikkatieto voi olla
mielekkäämpää sitoa vaikkapa rakennuksen pohjapiirustuksiin tai
huoneiden numerointijärjestelmään.
Sijaintitietoa, joka on esitetty yhdessä vertausjärjestelmässä, voidaan
käyttää myös muissa vertausjärjestelmissä, mikäli näiden
vertausjärjestelmien välillä voidaan tehdä muunnoksia. Esimerkiksi
Suomessa käytetetyn valtakunnallisen kartastokoordinaattijärjestelmän
(\ac{KKJ}) ja maailmanlaajuisen \ac{WGS84} -järjestelmän välillä on
mahdollista tehdä muunnos, jolloin paikkatietoa voidaan käsitellä
kummassakin järjestelmässä. Tämä voi olla hyödyllistä esimerkiksi
silloin kun käytössä on vain jommassa kummassa järjestelmässä
esitettyjä karttoja.
Paikkatiedon koostumus vaihtelee paikkatietoa tuottavien järjestelmien
välillä. Esimerkiksi solupaikannusjärjestelmä, kuten \ac{WLAN}
-solupaikannus, saattaa tarjota paikkatietona vain \ac{WLAN} -solun
tunnisteen. \ac{WLAN} -solun kattama alue taas voidaan kuvata jossakin
vertausjärjestelmässä. Näin saatu paikkatieto ei ole yksiselitteistä.
Myös soluhavaintoon voi liittyä epävarmuutta, esimerkiksi jos
havaintohetkestä on jo kulunut pitkä aika.
Epävarmuutta voi syntyä myös edellämainituista
koordinaattimuunnoksista. Eri vertausjärjestelmät voivat esittää
sijaintitietoa sisäisesti eri tavoin, jolloin koordinaattimuunnokset
eivät ole välttämättä yksiselitteisiä.
%
%\begin{itemize}
%\item EUREF-FIN, ETRS89, ITRS (sidottu epookkiin, 1989.0)
%\item KKJ
%\item http://www.maanmittauslaitos.fi/Default.asp?id=102
%\end{itemize}
\section{Paikkatiedon lähteet}
Paikkatiedon lähteinä toimivat erilaiset paikannusta tekevät
järjestelmät. Tuotetun paikkatiedon tietotyyppi voi vaihdella lähteenä
käytetyn järjestelmän mukaan. Esimerkiksi saatu sijaintitieto voi olla
esitetty eri koordinaattijärjestelmissä. Paikkatiedon
lähdejärjestelmiä on olemassa monia. Sekä pelkästään paikannuskäyttöön
kehitettyjä, että paikkatiedon tuottoon erilaisia olemassaolevia
tietojärjestelmiä hyödyntäviä järjestelmiä. Tämän työn aihepiirissä
tärkeimpiä järjestelmiä on käyty läpi seuraavissa kappaleissa.
\subsection{Satelliittipaikannusjärjestelmät}
Satelliittipaikannusjärjestelmissä määritetään maapallon pinnalla
olevien kohteiden sijainti maapalloa kiertävien satelliittien avulla.
Satelliittipaikannusjärjestelmistä tunnetuin lienee Yhdysvaltojen
puolustushallinnon kehittämä \ac{GPS} -paikannusjärjestelmä.
Satelliittipaikannusjärjestelmiä on erilaisia, mutta yleinen
määritelmä niille löytyy mm. Teknologian kehittämiskeskuksen (Tekes)
julkaisussa Paikannus mobiilipalveluissa ja sovelluksissa
\cite{tekes2003} (kpl 2.5, s.9):
\begin{quote}
``Satelliittipaikannus perustuu paikannussatelliittien lähettämään
ratatieto- ja aikamerkkisignaalien vastaanottoon ja vastaanottimen
sijainnin laskemiseen satelliittien etäisyyksien perusteella.''
\end{quote}
\ac{GPS} -järjestelmän lisäksi Euroopassa on kehitteillään Galileo
-niminen satelliittipaikannusjärjestelmä. Galileo -järjestelmän
kehittämisen syynä on mm. pyrkimys saada eurooppalaisten käyttöön
satelliittipaikannusjärjestelmä, joka ei ole riippuvainen yhdysvaltain
\ac{GPS} järjestelmästä. Yhdysvaltojen lisäksi
satelliittipaikannusjärjestelmiä on kehittänyt myös Venäjä, jolla on
käytössä \ac{GLONASS}
-sa\-tel\-liit\-ti\-pai\-kan\-nus\-jär\-jes\-tel\-mä\footnote{\url{http://www.glonass-center.ru/}}.
\ac{GLONASS} -järjestelmä ei tosin ole yhtä käytetty kuin \ac{GPS}
-järjestelmä.
Satelliittipaikannusjärjestelmät voivat tarjota hyvinkin tarkkaa
sijaintitietoa. Esimerkiksi GPS -järjestelmässä ilmakehän aiheuttamia
virheitä satelliittien lähettämän signaalin vastaanotossa voidaan
korjata \ac{DGPS} -järjestelmän avulla. \ac{DGPS} -järjestelmässä GPS
-vastaanottimelle välitetään korjaustietoa vastaanottimen
läheisyydessä sijaitsevalta korjausasemalta. Korjausasema lähettää
oman tarkan sijaintinsa ja GPS:n avulla lasketun sijainnin eron, jota
GPS -vastaanottimet voivat käyttää oman sijaintinsa korjaamiseen.
DGPS:n avulla voidaan päästä noin 2 metrin tarkkuuteen
(\cite{tekes2003}, s 10). DGPS -järjestelmällä tarkkuuden nostaminen
on ollut hyödyllistä etenkin ennen kuin GPS -järjestelmän
siviilipaikannuksen tarkkuutta häiritevä ``Selective Availability''
-ominaisuus\footnote{\url{http://www.ngs.noaa.gov/FGCS/info/sans_SA/docs/statement.html}}
poistettiin käytöstä. DGPS -järjestelmässä vastaanottimien tulee olla
korjausdataa lähettävien asemien läheisyydessä (370km
asti\footnote{\url{http://en.wikipedia.org/wiki/Differential_GPS}}).
Senttimetrien tarkkuuteen päästään \ac{RKT-GPS} -järjestelmällä,
mutta tässä järjestelmässä korjausdataa lähettävän aseman tulee olla
muutaman kilometrin läheisyydessä.
Satelliittipaikannusjärjestelmien ongelmana on huono kattavuus
kaupunkiolosuhteissa. Etenkin suuremmissa kaupungeissa korkeat
rakennukset häiritsevät satelliittien lähettämän signaalien
vastaanottoa. Sisätiloissa GPS -paikannusta ei voida yleisesti
käyttää. Kaupunkiolosuhteisiin on kuitenkin kehitetty tarkkuutta
parantavia ratkaisuja. Esimerkiksi Japanissa kaupunkiolosuhteissa
tehtävää paikannusta pyritään parantamaan \ac{QZSS} -järjestelmällä
\cite{qzss}. Tässä järjestelmässä GPS -satelliittien lähettämään
signaaliin yhdistetään QZSS -järjestelmän satelliittien lähettämä
signaali. QZSS -satelliitit ovat havaittavissa keskitaivaan suunnalta
ja muodostavat tiettyä aluetta seuraavan kiertoradan. GPS
-jär\-je\-stel\-mäs\-sä taas satelliitit ovat geostationäärisiä, eli
ne sijaitsevat maasta katsoen aina samassa paikassa.
\subsection{Verkkopaikannusjärjestelmät}
Paikkatietoa voidaan tuottaa erilaisia langattomia
tietoliikenneverkkoja hyväksikäyttämällä. Tukiasemapohjaisissa
tietoliikenneverkoissa päätelaitteet kommunikoivat paikallaan olevien
tukiasemien kanssa, jotka välittävät päätelaitteen lähetykset yleensä
langallisesti muihin tietoliikenneverkkoihin. Tällaisia verkkoja ovat
esimerkiksi \ac{GSM} -verkot. \ac{GSM} -verkoissa sijaintitietona
voidaan käyttää esimerkiksi päätelaitteen tiettynä hetkenä käyttämää
tukiasemaa. Samaan tapaan voidaan kerätä myös \ac{WLAN} -verkoista
sijaintitietoa.
Tarkempaa paikkatietoa verkkopohjaisissa paikannusjärjestelmissä
saadaan ottamalla huomioon esimerkiksi tukiasemien antennien kulmat
tai signaalin etenemiseen käyttämä aika. Tällä tavoin päätelaitteen
etäisyys ja suunta tukiaseman suhteen voidaan selvittää. Paikan
määrityksessä voidaan käyttää myös havaittua signaalivoimakkuutta eri
tukiasemista. Esimerkiksi Ekahau -yrityksen \cite{ekahau} \ac{EPE}
-tuote käyttää hyväksi signaalivoimakkuusinformaatiota WLAN -verkoissa
tapahtuvaan paikannukseen. Tuote perustuu WLAN -päätelaitteen
havaitsemiin signaalivoimakkuuksiin ja näiden korrelaatioon ennalta
laadittuun signaalikarttaan. \ac{EPE}:n avulla luodaan aluksi
signaalivoimakkuuskartta paikannusalueesta. Signaalikartan pohjana
käytetään paikannusalueena toimivan rakennuksen pohjapiirustusta.
Malliin voidaan liittää useampia pohjapiirustuksia kuvaamaan
rakennuksen eri kerroksia. Malliin määritetäään loogiset kulkureitit
rakennuksessa ``raiteiden'' avulla. Kulkureittien määrityksen
tarkoituksena on suurentaa paikannuksen tarkkuutta painottamalla
paikannustuloksia raiteiden avulla.
Signaalikartan muodostaminen tapahtuu keräämällä signaalinäytepisteitä
paikannusalueelta. Tämä tapahtuu kiertämällä haluttu alue esimerkiksi
kannettavan tietokoneen avulla. Halutun näytepisteen sijainnissa
osoitetaan nykyinen sijainti kartalta ja annetaan ohjelmiston kerätä
signaalivoimakkuusnäyte (\acf{RSSI}) sillä hetkellä kuulluista WLAN
-tukiasemista. Näyte tallentuu tietokantaan, jota myöhemmin käytetään
paikannusvaiheessa. Paikannusvaiheessa päätelaitteet mittaavat
signaalivoimakkuutta kuulemistaan tukiasemista ja lähettävät näytteet
palvelimelle, joka laskee näytteiden perusteella päätelaitteen
sijainnin pohjakartalla. \ac{EPE} soveltuu käytettäväksi sisätiloihin
ja sillä voidaan päästä jopa yhden metrin tarkkuuteen. \ac{EPE}
-palvelin tarjoaa sekä Java \ac{RMI} rajapinnan sekä \ac{TCP}
-protokollaa käyttävän rajapinnan paikannettujen päätelaitteiden
paikkatiedon kyselyyn. Esimerkiksi Java -rajapinnan kautta
paikkatietoa on mahdollista saada kahden sekunnin välein päivitettyinä
näytteinä.
Muita esimerkkejä verkkopohjaisista paikannusjärjestelmistä on
esimerkiksi Active Badge -järjestelmä \cite{want92active}, jossa
käyttäjiä paikannettiin kannettavien infrapunalähettimien avulla.
Infrapunalähetin sisällytettiin kannettaviin rintamerkkeihin.
Rintamerkkien lähettämää signaalia vastaanottavia antureita
kiinnitettiin huoneisiin ja yleisiin tiloihin. Antureita monitoroitiin
työasemilla, jotka kyselivät antureilta havaintoja
infrapunalähettimistä. Havainnot kerättiin talteen keskusasemalle,
josta infrapunalähetimien sijaintia voitiin kysellä.
Edellä esitetyistä verkkopaikannusjärjestelmistä Active Badge on
erityisesti paikannuskäyttöön suunniteltu. Ekahaun
korrelaatiopaikannusta käyttävä järjestelmä taas käyttää hyväkseen
olemassaolevia WLAN -verkkoja ja on täysin ohjelmistopohjainen
ratkaisu. \ac{GSM} -verkoissa on mahdollista pyrkiä parempaan
tarkkuuteen lisäämällä erillisiä paikannuskäyttöön tarkoitettuja
mittausyksiköitä. Esimerkiksi \ac{EOTD} -menetelmässä paikannus
perustuu tukiasemien lähettämien signaalien aikaerojen
havainnointiin\cite{tekes2003}. Tätä menetelmää käytettäessä
operaattorin verkkoon jouduttaisiin hankkimaan erillisiä \ac{LMU}
mittausyksiköitä. Lisäksi verkkopaikannusjärjestelmissä paikkatiedon
välittämiseen tarvitaan myös palvelu ja siten palvelinohjelmisto.
\subsection{Lähipaikannusjärjestelmät}
Lähipaikannuksella tarkoitetaan järjestelmiä, joissa paikkahavainnon
hankkimisen kantama on lyhyempi kuin edellä esitetyissä tekniikoissa.
Lähipaikantamiseen on esitetty käytettävän esimerkiksi
radiotaajuustunnisteita (\acf{RFID}). RFID -tunnisteissa on
mikropiiri, johon on tallennettu tunnisteen sisältämä tieto, yleensä
sarjanumero. Mikropiirin lisäksi tunnisteessa on antenni, jonka
avulla mikropiirin sisältämä tieto voidaan lukea. RFID -tunnisteet
voidaan jakaa aktiivisiin ja passiivisiin. Aktiivisissa tunnisteissa
on usein muistin lisäksi älykkyyttä ja kyky lähettää tietoa.
Passiiviset tunnisteet saavat mikropiirin toimintaan tarvittavan
energian induktiosilmukkana toimivasta antennista. Tunnisteen
lukijalaite tuottaa tällöin tunnisteen antenniin mikropiirin
tarvittavan energian. RFID -tekniikkaa käytetään useimmiten
tuotelähetyksien seurannassa ja tunnistamisessa, mutta tekniikkaa
voitaisiin käyttää paikantamisessa. Esimerkiksi Nokialla on olemassa
matkapuhelinmalleja, joihin on saatavissa RFID -tunniste
lisälaitteena. RFID -tunnisteiden käyttö olisi verrattavissa
esimerkiksi Active Badge -tunnisteisiin tai Ekahau -yrityksen
kannettaviin tunnisteisiin. Erona on käytetty radiotekniikka, RFID
-tunnisteiden lukuetäisyys vaihtelee taajuusalueen mukaan
(kosketusetäisyydestä eteenpäin). Lisäksi tunnisteiden taajuusalueet
vaihtelevat, eikä ole olemassa yhtä standardia, laajasti
käytettyä tunnistetekniikkaa.
Lähipaikannukseen voidaan luokitella myös Bluetooth -verkkoteknologiaa
käyttävä paikannus. Bluetooth on yleistymässä lyhyen kantaman
radiotekniikkana, jonka pääkäyttätarkoitus on toimia johtimien
korvaajana. Bluetooth -standardiin on kuitenkin sisällytetty määritys
paikannuskäytöstä \ac{LPP} profiilin avulla \cite{lpp}. \ac{LPP}
-profiilissa määritetään protokolla sekä käytäntö paikkatiedon
välittämiseen Bluetooth -laitteiden kesken. \ac{LPP} -määrityksessä
Bluetooth -laitteet voisivat hyödyntää toisia laitteita oman
sijaintinsa määrittämiseen, mikäli laite itse ei pysty määrittämään
sijaintiaan. Mikäli lähistöllä oleva laite pystyy vaikkapa GPS:n
avulla määrittämään sijaintinsa, voi tämän laitteen sijaintia kyselevä
laite päätellä yksinkertaisimmassa tapauksessa olevansa 10 metrin
päässä tästä havainnosta. Tarkempaan etäisyyden päättelyyn
jouduttaisiin soveltamaan monimutkaisempia algoritmeja, mahdollisesti
samantyyppisiä kuten verkkopaikannuksessa (esimerkiksi antennikulmat,
etenemisaika, signaalikartat ja korrelaatio). Pelkästään
signaalivoimakkuuden käytön on todettu olevan riittämätöntä etäisyyden
päättelyssä \cite{lulea}.
\ac{LPP}:ssa laitteet ovat joko asiakkaita
tai palvelimia ja ne voivat kysellä ja välittää paikkatietoa LPP:ssa
määritellyin keinoin. Bluetooth -verkkoa on sovellettu
paikannuskäyttöön mm. Raine Koposen diplomityössä \cite{koponen},
jossa toteutettiin Bluetooth -verkkoa käyttävä opastusjärjestelmä.
Diplomityössä toteutettiin Bluetooth -tukiasemaverkon avulla
opastesovellus, joka koostui kolmesta komponentista: Bluetooth
-tukiasemissa olevista opaste -ohjelmista, keskusopas -palvelimesta
sekä asiakkaana toimivasta asiakas-opas ohjelmistosta, jota käytettiin
kämmentietokoneella. Asiakas-opas -ohjelman avulla käyttäjä pystyi
kyselemään reittiä rakennuksen sisällä paikasta toiseen. Paikkatietona
käytettiin kulloinkin yhteydessä olevaa tukiasemaa (solupaikkatieto).
Työssä todettiin, että ongelmaksi muodostuu tukiasemien kattoalue. Ei
voida olla varmoja käyttäjän oikeasta sijainnista, mikäli
tukiasemien kuuluvuusalue on laaja.
\subsection{Sovelluskohtaiset paikkatiedon lähteet}
Paikkatiedon lähteenä voivat toimia myös järjestelmät, joita ei ole
suunniteltu paikantamista silmälläpitäen. Esimerkiksi
kalenterijärjestelmiä on käytetty paikkatiedon lähteenä. Erään
toteutuksen esittelevät Urs Hengartnet ja Peter Steenkiste
\cite{hengartner_steenkiste}. Toteutetussa järjestelmässä paikkatietoa
kerättiin sekä käyttäjän päätelaitteen (kannettava tietokone WLAN
-radiolla tai GPS -vastaanotin) paikantavan sovelluksen että
kalenteriohjelmiston avulla. Kalenterissa olevien tapaamisten
perusteella voitiin päätellä käyttäjän paikka ilman erillistä
paikannusjärjestelmää. Julkaisussa esitetään myös tietoturvan kannalta
tärkeä havainto: paikannusjärjestelmät eivät välttämättä ole yhden
tahon hallinnassa. Paikkatiedon välityksessä joudutaankin siis
luottamaan paikkatietoa välittäviin tahoihin. Myös paikkatiedon käytön
tulisi olla käyttäjän hallinnassa. Käyttäjän tulee voida päättää mikä
palvelu tai ketkä käyttäjät voivat saada hänen sijaintinsa
tietoonsa.
Useasta eri järjestelmästä hankitun paikkatiedon hallittua
yhteiskäyttöä kutsutaan ``sensor fusion'' -tekniikaksi
\cite{hightower02location}. Paikkatiedon hankkiminen ja mahdollinen
yhdistely eri lähteistä johtaa paikannusjärjestelmän hajauttamisen
harkintaan. Keskitetyn paikannusjärjestelmän (esimerkiksi Ekahau)
ongelmana on paikkatiedon saannin varmuus. Mikäli keskitetty
järjestelmä ei ole toiminnassa, ei paikkatietoa ole saatavilla.
Hajautetussa järjestelmässä saatavuus taas voitaisiin jakaa eri
lähteisiin. Paikkatiedon määritys vaihtelee järjestelmästä toiseen.
Esimerkiksi GPS -paikannuksessa paikan määritys tapahtuu
päätelaitteessa itsessään, kun verkkopaikannuksessa taas paikan
määritys tehdään verkkoninfrastruktuurin elementissä.
Ideaalitilanteessa saavutetaan parempi saatavuus paikkatiedolle
käyttämällä useampaa paikanmäärityslähdettä. Tämä ei kuitenkaan aina
ole mahdollista, esimerkiksi päätelaitteen rajoitusten takia.
Esimerkiksi moniradioiset laitteet ovat harvinaisempia ja akun kesto
rajoittaa radiolaitteiden käyttöä.
\subsection{Paikkatiedon palvelurajapinnat}
Jotta paikkatietoa voitaisiin käyttää erilaisissa sovelluksissa, tulee
se hankkia ja välittää sovellusten käyttöön. Sovelluskehitystä
edistävät tällöin rajapinnat, jotka määrittelevät protokollat ja
menettelytavat, joilla paikkatietoa voidaan hankkia.
Palvelurajapintojen avulla voidaan yleistää sovelluskehitystä ja
tehdä sovelluskehityksestä määritellympää.
Paikkatiedon hankintaan on määritelty erilaisia rajapintoja monien eri
tahojen toimesta. GPS -vastaanottimien tarjoamaa paikkatietoa voidaan
lukea vastaanottimesta riippuen esimerkiksi \ac{NMEA} -standardin
avulla\footnote{http://www.kh-gps.de/nmea.faq}. NMEA -standardit
määrittelevät sähköiset liitännät sekä tietotyypit, joilla erilaiset
merenkulkulaitteet välittävät tietoa.
Verkkopaikannusjärjestelmistä paikkatiedon hakuun rajapintoja ovat
määritelleet mm.
\ac{OMA}\footnote{\url{http://www.openmobilealliance.org}} ja
Parlay\footnote{\url{http://www.parlay.org/}}. \ac{OMA} on
matkaviestinnän alalla toimivien yritysten (operaattorit, laite- ja
verkkovalmistaja sekä palveluntuottajat) yhteenliittymä, jonka
tarkoituksena on luoda avoimia standardeja. Tällä tavoin pyritään
nopeuttamaan ja yhteinäistämään matkaviestintäverkkojen
palvelukehitystä. \ac{OMA}:n toiminta on jaettu työryhmiin, jotka
keskittyvät johonkin tiettyyn osa-alueeseen. Paikkatiedon
hyödyntämiseen keskittyy
\ac{LOC}\footnote{\url{http://www.openmobilealliance.org/tech/wg_committees/loc.html}}.
\ac{LOC} jatkaa entisen \ac{LIF} ja \ac{WAP} Forumin työtä ja määrittelee
standardeja paikkatiedon käyttöön matkaviestinverkoissa. \ac{LOC}
-työryhmä jatkaa mm. \ac{LIF}:n \ac{MLP} -protokollan määrittelyä.
\ac{MLP} on yleinen, verkkotekniikasta riippumaton protokolla, jonka
avulla voidaan kysellä mobiilien päätelaitteiden sijaintia. \ac{MLP}:n
määrityksessä langaton verkko sisältää palvelimen (Location Server)
jolta paikkatietoiset sovellukset (Location Based Applications)
tekevät kyselyjä \ac{MLP} -protokollan avulla. \ac{MLP} -protokolla on
\ac{XML} -pohjainen. Käytettävää siirtokerrosta ei ole erikseen
määritetty, mutta sidonta \ac{HTTP} -protokollalle on sisällytetty
määrityksiin.
Parlay on \ac{OMA}:n kaltainen usean yrityksen yhteenliittymä, joka
myös pyrkii määrittelemään avoimia rajapintoja sovelluskehitykseen
erilaisissa verkkoympäristöissä. Parlay 5.0 -specifikaatio on jaettu
15 osaan, joista osassa 6 (Mobility) määritellään rajapinta
paikkatiedon hakuun. Mobility -rajapinnassa on määritelty protokolla
ja rajapinnan luokkarakenne \ac{UML}:n avulla. Määrityksen mukana
toimitetaan myös \ac{WSDL} ja \ac{IDL} -dokumentit
rajapintakuvauksesta.
Paikkatiedon käyttöön sovelluksissa laatii määrityksiä myös
\ac{OGC}\footnote{\url{http://www.opengeospatial.org}}. Myös \ac{OGC}
on yritysten, valtion virastojen sekä yliopistojen yhteenliittymä, joka
kehittää julkisesti saatavilla olevia rajapintamäärityksiä. \ac{OGC}
ei ole keskittynyt pelkästään määrittelyihin, joita voitaisiin käyttää
paikkatiedon hakemiseen joltakin palvelimelta. \ac{OGC} on määritellut
monia ohjelmistokehitystä tukevia palveluja, esimerkiksi
koordinaattimuunnospalvelun \cite{wcts}.
\subsection{GIS (Geographical Information System) -järjestelmät}
Paikkatiedon (sijainti- ja ominaisuustieto) tehokkaaseen tallennukseen
ja käsittelyyn käytetään usein \ac{GIS} järjestelmiä.
Paikannussanastossa \cite{paikannussanasto} \ac{GIS} -järjestelmä on
määritelty seuraavasti:
\begin{quote}
``tietojärjestelmä, joka käsittelee paikkatietoa ja tukee
erityisesti sijaintitiedon (1) käsittelyä ja hallintaa ``
``Paikkatietojärjestelmä tukee sijaintiin perustuvaa indeksointia,
hakuja, analyysejä ja visualisointia.''
\end{quote}
Esimerkki GIS -järjestelmästä on GRASS (Geographic Resources Analysis
Support System )
-ohjelmisto\footnote{\url{http://grass.ibiblio.org/index.php}}. GRASS
-ohjelmistolla voidaan mm. visualisoida erilaista paikkatietoon
liittyvää dataa. Yksi esimerkki tällaisesta tiedon käsittelystä on
\ac{WLAN} -verkon kuuluvuuden visualisointi. Visualisoinnin lisäksi
paikkatiedon tallennusmenetelmät ovat tärkeässä asemassa tiedon määrän
kasvaessa. Tallennukseen käytetään erilaisia tietokantajärjestelmiä
jotka mahdollistavat myös tiedon haun. Haut voivat kattaa erilaisia
operaatioita, joilla paikkahakua voidaan rajata.
Paikkatietokantajärjestelmiä on toteutettu mm.
relaatiotietokantajärjestelmiin. Esimerkiksi PostGIS \cite{postgiswww}
on eräs \ac{GIS} -tietokantatoteutus, joka laajentaa PostgreSQL
\cite{postgresqlwww} olio-relaatiotietokantaa sisältämään
tietotyyppimääreet paikka- ja sijaintitiedolle. Relaatiotietokantojen
etuina on \ac{SQL} -kyselykieli, jolla voidaan tehdä hakuja
tietokannan sisältöön.
\section{Tilannetieto}
Vaikka paikkatiedon on tietyltä osin hyvin määriteltyä, sama ei päde
tilannetietoon. Tilannetiedolla tarkoitetaan yleisesti erilaisiin
sovellusten käyttötilanteisiin liittyvää tietoa. Esimerkiksi Dey
\cite{dey} on määritellyt tilannetiedon seuraavasti:
%\begin{quote}
% Context is any information that can be used to characterize the
% situation of an entity. An entity is a person, place, or object that
% is considered relevant to the interaction between a user and an
% application, including the user and application themselves.
%\end{quote}
\begin{quote}
``Konteksti on mitä tahansa informaatiota, jolla voidaan luonnehtia
jonkin olion tilannetta. Olio on henkilö, paikka tai objekti, jonka
katsotaan olevan merkityksellinen käyttäjän ja sovelluksen
vuorovaikutukseen, mukaanlukien käyttäjä ja sovellus itse.''
\end{quote}
Käyttötilanteet voivat etenkin mobiilisovelluksissa vaihtua usein.
Samaa sovellusta voidaan käyttää monessa eri tilanteessa ja
ympäristössä. Sama toiminto voidaan tehdä myös monella eri
sovelluksella eri ympäristöissä. Tiedettäessä sovelluksen
käyttöympäristö, voidaan sovelluksen toimintaa muokata
käyttöympäristön mukaiseksi. Vaihtoehtoisesti voidaan muokata eri
ympäristöjä käyttäjän toimintoihin sopivaksi.
Ongelmana on kuitenkin tilannetiedon muoto. Erilaisia käyttötilanteita
on monia, joten ennalta ei voida tietää mitä tietoa ja missä muodossa
käyttötilanteesta on saatavilla. Etenkin mobiilisovelluksia voidaan
käyttää monissa eri tilanteissa. Käyttötilanteeseen reagointi voidaan
jättää joko käyttäjän tehtäväksi tai pyrkiä toteuttamaan se
sovellukseen. Tilannetietoisia sovelluksia luotaessa on voitava
määrittää, miten sovellus toimii eri tilanteissa. Tämä voi johtaa
siihen, että sovellus räätälöidään ottaen huomioon vain halutut
tilannetiedot, esimerkiksi paikkatieto. Monimutkaisemmissa
tilannetiedon yhdistelmissä (esimerkiksi aika, paikka, säätila)
tarvitsee sovellus jonkinlaisen ehdollisen tavan käsitellä saatavissa
olevia tietoja. Esimerkiksi tiettyjen ehtojen täyttyessä tunnistetaan
käyttötilanne ja suoritetaan toiminto sovelluksessa. Ongelmaksi voi
tällöin tulla sääntöjen määrittely. Annetaanko käyttäjän määritellä
toimintasäännöt vai jätetäänkö tämä sovelluskehittäjän tehtäväksi?
%Tämä voidaan tehdä ottamalla jonkun asian
%muutos (esimerkiksi paikkatieto) huomioon sovelluksen toteutuksessa.
%Tällä tavoin voidaan luoda sovelluksia jotka reagoivat johonkin
%määrättyyn tietoon. Sovelluksen käyttäjän tulisi kuitenkin voida
%vaikuttaa sovelluksen toimintaan, jolloin tilannetiedon käytön
%hallinta tulisi olla sovelluksen käyttäjällä. Tämä menettelytapa on
%kuitenkin ristiriidassa yleiseen tilannetiedon käytön perusteluun,
%sovelluksen muokkautuvuuteen käyttötilanteen mukaan ilman että
%käyttäjälle luodaan lisätaakkaa.
Tilannetieto voi koostua erilaisesta ympäröivästä tiedosta. Tällaista
tietoa on esimerkiksi vallitseva säätila. Toisaalta tilannetieto voi
olla käyttäjään henkilökohtaisesti liittyvää tietoa, esimerkiksi
käyttäjän sijainti. Tilannetiedon käytössä tulisikin ottaa huomioon
käyttäjän yksityisyyden suoja. Esimerkiksi paikkatiedon käsittelyä on
lainsäädännössä rajoitettu. Erityisesti tilannetiedon käsittelystä ei
ole säädetty vielä lakeja. Mutta tilannetiedon luonteesta johtuen,
pitäisi noudattaa niitä säädöksiä mitkä käytettyä tietoa koskevat.
%Säätilan käyttö ei
%välttämättä ole mielekästä kaikissa sovelluksissa, mutta tilannetiedon
%käytön tulisikin olla tarpeeksi yleistä. Säätiedon lähteenä voi toimia
%esimerkiksi säätietopalvelu, joka kerää tietoa sensorien avulla.
%Tilannetietoon liittyykin yleensä erilaiset sensorit, jotka mittaavat
%ja aistivat jotakin ympäröivästä maailmasta. Sensoreihin voidaan lukea
%myöskin paikannukseen käytetyt sensorit. Paikkatieto (sijainti ja
%sijaintiin liittyvät ominaisuudet) on yksi monesti tärkeäksi koettu
%tilannetieto.
%
%Tässä luvussa kerrotaan mitä tilannetieto (kontekstitieto) on, miten
%se liittyy edellisessä luvussa kuvattuun paikkatietoon, mistä
%järjestelmistä tilannetietoa voidaan hankkia ja miten tilannetietoa
%voidaan välittää. blaa blaa\ldots
%
% Dey:n määritelmä
%
% säätieto, harjoitustieto, nämä pitänee esitellä jotta tulisi pohja
% toteutuskappaleeseen
\subsection{Tilannetiedon lähteet}
Tilannetiedon lähteinä voi toimia yleisesti ottaen mikä tahansa
sensori tai yleiskäyttöinen data. Sensorit ovat laitteita, jotka
mittaavat ja aistivat jotakin ympäröivästä maailmasta. Esimerkiksi
Dey:n \cite{dey} määritelmän perusteella tilannetiedon lähteiden
määrittely onkin melko laajaa. Tämä johtaa siihen, että tilannetietoa
käsittelevät järjestelmät ovatkin yleisiä työkaluja. Esimerkiksi
\ac{MUPE} -alustalle (esitelty kappaleessa \ref{sec:mupe}) rakennettu
tilannetiedon käsittelyrajapinta \ac{CEP} määrittelee vain yleiset
numeraaliset sekä merkkipohjaiset tietotyypit ja näiden
koostumuksellisen käytön.
\newpage
Tilannetiedon lähteenä voi toimia esimerkiksi vallitsevaa lämpötilaa
mittaava sensori tai tätä tietoa välittävä sääpalvelu (esim.
Ilmatieteen laitoksen sääpalvelu\footnote{\url{http://www.fmi.fi}}.
Tilannetiedon lähteenä voi toimia paikkatietoa tuottava järjestelmä,
joka raportoi käyttäjän liikkeistä tietyllä alueella. Esimerkiksi
\ac{GPS} -vastaanottimella varustettu päätelaite voi tuottaa
paikkatietoa käyttäjän liikkeistä ja tätä paikkatietoa voidaan käyttää
hyväksi sovelluksen suorituksen yhteydessä. Tilannetietoisena
sovelluksena ei kuitenkaan yleisesti käsitetä vain yhtä tiettyä tiedon
lähdettä käyttävää sovellusta. Esimerkiksi kuljetun reitin
seurantasovellusta ei yleisesti pidetä tilannetietoisena sovelluksena,
vaikka käyttäjän kulkureitin seuraaminen, ja sitä kautta käyttäjän
tilanteen seuraaminen, onkin tärkeässä asemassa.
Tilannetiedon lähteenä voi toimia joko yksittäinen sensori tai
palvelu. Palvelut, kuten säätietopalvelut, keräävät ja jalostavat
tilannetietoa. Tilannetiedon käyttöön voi liittyä myös rajoituksia,
joita palvelut asettavat. Esimerkiksi paikkatiedon hakuun tietystä
palvelusta voi liittyä käyttörajoituksia. Tällainen rajoitus voi olla
vaikkapa käyttäjän suostumus hänen paikkatiedon käyttöön.
%\begin{itemize}
%\item erilaiset sensorit, mitä muuta?
%\item tilanne/kontekstitieto on laaja käsite, miten sitä kannattaisi
% purkaa? (yleensä vielä nähdään tilannetiedon olevan ylikäsite, joka
% kattaa myös paikkatiedon\ldots)
%\end{itemize}
\subsection{Rajapinnat ja sovelluskehitys tilannetiedolle}
Erityisesti tilannetiedon käyttöön tarkoitettuja rajapintoja on vielä
vähän. Tämä johtunee osaksi siitä, että tilannetiedon käyttö
sovelluksissa ei ole vielä suuresti yleistynyt. Vielä ei olla varmoja
onko tällainen yleinen tiedon hyödyntämistapa sovelluskehityksen
yhteydessä hyödyllinen. Lisäksi ei olla varmoja ohjelmistokehityksessa
tilannetiedon huomioonottamistavoista.
Tutkimuksen saralla tilannetietoa on kuitenkin hyödynnetty laajalti.
Esimerkkejä löytyy Carnegie Mellon -yliopiston Aura
-projektista\footnote{\url{http://www.cs.cmu.edu/~aura/}}. Projektin
konseptivideossa (saatavilla projektin etusivuilta) visioidaan
ympäröivien tietokoneresurssien käyttöä aina tilanteeseen sopivimmalla
tavalla. Tämä tehdään siten, että käyttäjän huomio säilyy itse
käsiteltävässä asiassa, eikä pelkästään uuden tekniikan hallinnassa.
Tällä tavoin hyödynnettiin ympäröiviä, erilaisia tietoteknisiä
laitteita. Esimerkiksi käytävällä olevassa videotaulussa voidaan
näyttää käyttäjän ohikulkiessa käyttäjää kiinnostavaa tietoa.
Tilannetiedon käytöllä luodaan kokonainen järjestelmä, joka hallinnoi
ympäröiviä tietokoneresursseja käyttäjän auttamiseksi.
Tilannetietoa voidaan hyödyntää myös yhden tietyn sovelluksen
toiminnan kustomointiin. Tämä vaatii, että tilannetiedon olemassaolo
otetaan huomioon sovellusta rakennettaessa. Tilannetiedon
huomioonottaminen taas vaatii, että sovellukseen on ennalta tehtävä
toiminallisia määrityksiä tilannetietoa varten. Tämäntyyppinen
sovelluksen toiminnallisuuden laajentaminen olisi monesti turhan
paljon sovelluskehitystä rasittavaa, ellei olemassa ole työkaluja
tilannetiedon käsittelyn helpottamiseksi. Erään tällaisen
tilannetietoisten sovellusten kehitystyökalun tarjoaa \ac{MUPE}
-ympäristö (esitelty tarkemmin kappaleessa \ref{sec:mupe}).
Tilannetietoisten sovellusten prototypointi olisi useasti vaikeaa
ilman työkaluja tällaiseen tehtävään. Esimerkiksi paikkatiedon
simulointiin jouduttaisiin rakentamaan työkaluja ennen kuin
sovelluksen kehittäminen voidaan aloittaa. Työkaluja prototypointiin
on kehitetty mm. Topiary
-projektissa\footnote{\url{http://guir.berkeley.edu/projects/topiary/}}.
Topiaryn avulla voidaan projektin WWW -sivujen mukaan tehdä seuraavaa:
%\begin{quote}
% Topiary is a tool for prototyping location-enhanced applications.
% Topiary lets designers create a map that models the location of
% people, places, and things; use this active map to demonstrate
% scenarios depicting location contexts; use these scenarios in
% creating storyboards that describe interaction sequences; and then
% run these storyboards on mobile devices like PDAs, with a wizard
% updating the location of people and things on a separate device.
%\end{quote}
\begin{quote}
Topiary on työkalu paikatietoisten sovellusten prototypointiin.
Topiaryn avulla suunnittelijat voivat luoda kartan, joka mallintaa
ihmisten paikkojen ja tavaroiden sijainnin; käyttää tätä karttaa
demonstroimaan skenaarioita jotka kuvaavat paikan tilannetietoa;
käyttää näitä skenaarioita tarinoiden luomisessa, jotka kuvaavat
vuorovaikutussekvenssejä; ja ajaa näitä tarinoita mobiileissa
laitteissa, kuten PDA -laitteissa, velho -sovelluksen avulla jolla
päivitetään ihmisten ja tavaroiden sijainteja eri laitteella.
\end{quote}
Tilannetiedon simulointi on tärkeää sovelluskehityksen
testausvaiheessa. Simulointityökaluilla voidaan toimintaa testata
ilman varsinaista kohdeympäristöä. Tällöin toiminnan testaaminen on
nopeampaa. Tärkeää olisi kuitenkin myös se, että simulointityökalut
olisivat yleiskäyttöisiä, eivätkä rajoittaisi käyttömahdollisuuksia
vain simulointialustalle. Tällöin avoimet rajapinnat ovat hyvinkin
tärkeitä.
%\ac{MUPE} -alusta tarjoaa myös työkalut tilannetiedon simulointiin.
%Tilannetiedon välitys \ac{MUPE} -alustalle tehdää avoimesti
%määritellyn \ac{CEP} -protokollan avulla. \ac{CEP} -protokollan
%mukaista tilannetietoa voidaan simuloida erilaisilla
%simulointiyökaluilla. Tilannetietoisia sovelluksia rakennettaessa,
%tulisi päättää mille ohjelmistoalustalle ja mihin laitteeisiin
%sovellus tehdään. MUPE -alustan käyttö sitoo päätelaitteen \ac{MIDP}
%-alustoihin. Kuitenkin \ac{CEP} -protkolla on yleiskäyttöinen, ja sitä
%voidaan soveltaa muissakin ympäristöissä, joskin se pitäisi ensi
%implementoida muihin ympäristöihin.
Topiaryn lisäksi tilannetietoisten sovellusten kehittämistä on
tutkittu myös Context Toolkit
-projektissa\footnote{\url{http://www.cs.berkeley.edu/~dey/context.html}}.
Seuraava lainaus projektin WWW -sivuilta kertoo Context Toolkit
-sovelluskehitysympäristön tarkoituksen:
%\begin{quote}
% The Context Toolkit consists of context widgets and a distributed
% infrastructure that hosts the widgets. Context widgets are software
% components that provide applications with access to context
% information while hiding the details of context sensing.
%\end{quote}
\begin{quote}
Context Toolkit koostuu context widgeteistä ja hajautetusta
arkkitehtuurista, joka sisältää nämä widgetit. Context widgetit ovat
ohjelmistokomponentteja jotka antavat sovelluksille pääsyn
tilannetietoon samalla kun ne peittävät tilannetiedon havainnoinnin
yksityiskohdat.
\end{quote}
Context toolkit:n toimintaperiaate on samantyyppinen kuin graafisten
käyttöliittymien kehityksessä kätettyjen yleisten komponenttien (engl.
widget). Context toolkit tarjoaa komponentteja, joilla abstrahoidaan
tilannetiedon keräämiseen, tallentamiseen ja pääsynhallintaan
liittyviä operaatioita, siten että huomio pysyy itse ohjelmiston
kehityksessä. Graafisissa käyttöliittymissä käytetään usein yleisiä
komponentteja esim. dialogien rakentamiseen, jotta näitä komponentteja
ei jouduttaisi toteuttamaan erikseen jokaiseen graafiseen
sovellukseen.
%\begin{itemize}
%\item onko näitä?
%\item CEP, mutta pitäisi esitellä MUPE ensin, riippuu kuinka tarkkaan
% MUPE halutaan esitellä, varmaankin melkoisen tarkasti\ldots vaan
% voisikohan esittelyä jakaa\ldots
%\item context toolkit, deyn tutkimus, \url{http://www.cs.berkeley.edu/~dey/context.html}
%\item Topiary \url{http://guir.berkeley.edu/projects/topiary/}
%\item
%\end{itemize}
\section{MUPE (Multi User Publishing Environment) -alusta}
\label{sec:mupe}
\acf{MUPE} -ympäristö on monen käyttäjän mobiilisovellusten
kehittämiseen tarkoitettu alusta. Se koostuu asiakas- ja
palvelinosasta, jotka kommunikoivat keskenään \ac{XML} -rakenteisten
viestien avulla. Kuvassa \ref{fig:mupe-yleiskuva} on esitetty MUPE
-alustan komponenttirakenne.
\begin{figure}[h]
\centering
\includegraphics[width=\textwidth]{kuvat/mupe-yleiskuva.pdf}
\caption{\acf{MUPE} -alustan komponenttien yleiskuva.}
\label{fig:mupe-yleiskuva}
\end{figure}
Asiakasohjelma on rakennettu käyttäen \acf{J2ME} -ympäristön
\acf{MIDP} -kirjastoja. MIDP -kirjastojen versioille 1 ja 2 on oma
asiakasohjelmisto. Asiakasohjelma toiminta on selaintyyppistä; se
tulkitsee XML -kuvauskielellä muodostettuja käyttöliittymäkuvauksia ja
luo kuvauksen mukaisen käyttöliittymän toimintoineen. Palvelinosa
koostuu sekä väliohjelmisto (middleware ) -kom\-po\-nen\-tei\-sta että
sovelluslogiikan sisältävästä komponentista. Kuvassa
\ref{fig:mupe-yleiskuva} esitetyt ``middleware core'' -komponentit
kommunikoivat keskenään \ac{TCP} -yhteyksien avulla. \emph{Client
Manager} -kom\-po\-nent\-ti huolehtii asiakkaiden yhteyksien ylläpidosta.
Tällä hetkellä \emph{Client Manager} -komponentteja on sekä \ac{HTTP}
-protokollalle että MUPE:n omalle TCP -pohjaiselle protokollalle.
\emph{Context Manager} -komponentti huolehtii tilannetiedon
vastaanottamisesta \emph{Context Producer} -komponenteilta.
Tilannetietoa välitetään TCP -yhteyden yli \ac{CEP} -pro\-to\-kol\-lan
\cite{cep} mukaisissa \ac{XML} -viesteissä. \emph{World Manager}
-komponentti huolehtii varsinaisen MUPE -sovelluksen logiikan
suorituksesta.
MUPE -sovellus luodaan käyttämällä alustan tarjoamaa
perusluokkarakennetta ja tämän rakenteen rajapintoja. Kuvassa
\ref{fig:mupe-luokat} on esitetty MUPE -sovelluksen
perusluokkarakenne. Luokkarakenteen luokkia \emph{User}, \emph{Room},
\emph{Service} ja \emph{Item} kutsutaan sisältöluokiksi (content
classes) \cite{mupeservertech}, sillä ne muodostavat MUPE -palvelun
yleisen sisältörakenteen. Kyseinen luokkarakenne sisältyy kuvassa
\ref{fig:mupe-yleiskuva} esitettyyn \emph{MUPE Server} -kom\-po\-nent\-tiin.
Kuvan \ref{fig:mupe-yleiskuva} \emph{World Manager} ja \emph{MUPE
Server} komponenttien välinen rajapinta koostuu Java
luokkarajapinnasta. Käytännössä \emph{World Manager} -komponentti luo
perusluokkarakenteen avulla objekteja MUPE -sovellukseen, esimerkiksi
käyttäjät luodaan \emph{User} -luokkaa käyttäen.
\begin{figure}[h]
\centering
\includegraphics[width=\textwidth]{kuvat/mupe-luokat}
\caption{\acf{MUPE} -alustan sovelluksen perusluokkarakenne}
\label{fig:mupe-luokat}
\end{figure}
%\FloatBarrier
\emph{World Manager} -komponentti käyttää \emph{MUPE Server}
-komponenttiin luotua luokkarakennetta \emph{Parser} -luokan kautta.
Parser -luokan toiminnallisuus koostuu XML -viestin tulkitsemisesta.
Sekä \emph{Client Manager}- että \emph{Context Manager} -komponentit
lähettävät \emph{World Manager} -komponentille XML -viestejä, joita
Parser -luokan avulla tulkitaan. XML -viesteillä voidaan suorittaa
Java -metodikutsuja \emph{MUPE Server} -komponentin sisältämästä
sovelluksesta.
Luotaessa sovellusta määrittää \emph{World} -luokka tietyille
luoduille objekteille tunnistenumeron, jonka avulla luotuun objektiin
voidaan viitata XML -viesteissä. Tunnuksen saavia objekteja ovat
\emph{Base} -luokasta perityt objektit. Tietyillä objekteilla on
pysyvät tunnistenumerot. Näitä ovat \emph{World} (numero 0),
oletushuone (default room, numero 1) ja \emph{Context Manager} (numero
2). Näillä kolmella objektilla on erityisrooli MUPE:n
toiminnallisuudessa, esimerkiksi \emph{Context Manager} -objektia
vastaa \emph{Context Manager} -komponentti. Kyseisen komponentin
lähettämissä XML -viesteissä olevia Java -metodikutsuja kutsutaan
vastaavan nimisestä objektista \emph{MUPE Server} -komponentin sisällä
\footnote{Alun perin MUPE -sovelluksen sisältämä \emph{Context
Manager} -objekti oli nimeltään \emph{Superuser}. Kyseisellä
objektilla oli valtuudet tehdä metodikutsuja kaikista MUPE
-sovelluksen luokista. Myöhemmin osoittautui että \emph{Superuser}
-objektin käyttökohde oli pelkästään tilannetiedon käsittely, joten
kyseinen objekti nimettiin \emph{Context Manager} -objektiksi.}. XML
-kutsuissa kerrotaan objekti, josta kyseinen kutsu tehdään. Esimerkki
tällaisesta XML -kutsusta löytyy lähteestä \cite{mupeservertech}:
\begin{center}
\texttt{146645::clientAnswerCreator \{``Bob''\}}
\end{center}
Kyseisessä esimerkissä tehdään \emph{clientAnswerCreator} -metodikutsu
objektiin, jonka tunnusnumero on \emph{146645}. Kutsussa viedään
parametrina merkkijono ``Bob''. MUPE -sovellus vastaa XML -kutsuihin
yleensä uudella XML -dokumentilla, joka lähetetään takaisin kutsun
tehneelle asiakkaalle. Poikkeuksena on \emph{Context Manager}
-komponentti, jolle ei lähetetä tehtyjen kutsujen vastauksia.
\emph{Context Manager} -komponentin avulla MUPE -sovelluksiin voidaan
tuoda tilannetietoa ympäröivästä maailmasta. Tämä tapahtuu
muokkaamalla haluttu tilannetieto \ac{CEP} -pro\-to\-kol\-lan mukaisiin XML
-dokumentteihin. Tätä varten MUPE -alustalle joudutaan tekemään
jokaista tilannetiedon lähdettä vastaava tilannetiedon tuottaja,
\emph{Context Producer}.
Tilannetiedon tuottajakomponentit toimivat \ac{TCP} -palvelimina; ne
vastaanottavat \ac{TCP} -yhteyksiä MUPE -sovelluksilta ja välittävät
tuottamansa tilannetiedon \ac{CEP} -protokollan mukaisina XML
-viesteinä muodostetun TCP -yhteyden yli MUPE -sovelluksille.
Tilannetiedon lähteestä riippuen tilannetiedon tuottajan toteutus
vaihtelee. Periaatteessa tilannetiedon tuottaja toimii kuitenkin
eräänlaisena ``protokollamuuntimena'', joka muuntaa tilannetiedon
lähdejärjestelmän tietotyypit vastaamaan \ac{CEP} -protokollan
\cite{cep} määritystä. Tällöin MUPE -sovellukset voivat tulkita
yleistä \ac{CEP} -protokollan mukaista tietoa. MUPE -sovelluksen
käynnistyessä määritetään \emph{Context Producer} -komponentit, joihin
otetaan yhteys IP -osoitteen ja portin perusteella. Tämän jälkeen
\emph{Context Producer} -komponentin tehtäväksi jää välittää
tilannetiedon muutokset CEP -protokollan mukaisina XML -dokumentteina
kytkeytyneinä oleville \emph{Context Manager} -komponenteille. CEP
-protokollan määritys \cite{cep} tukee monia operaatioita, mutta
kaikkia näistä ei ole toteutettu tällä hetkellä MUPE -alustan
\emph{Context Manager} -komponentissa.
\emph{Context Manager} -komponentissa voidaan vastaanotetun
tilannetiedon perusteella suorittaa toimintoja MUPE -sovelluksen
toimintalogiikassa. Vastaanotetun tilannetiedon prosessointi kulkee
kolmessa vaiheessa, jotka on esitetty kuvassa
\ref{fig:mupe-context-manager}. Tilannetiedon prosessoinnin
eriyttäminen omaan komponenttiinsa mahdollistaa sen, että jokaiseen
MUPE -sovellukseen ei tarvitse erikseen tehdä komponenttia
tilannetiedon käsittelyyn.
\begin{figure}[h]
\centering
\includegraphics[width=\textwidth]{kuvat/mupe-context-manager}
\caption{\emph{Context Manager} -komponentin sisäisen toiminnan kaaviokuva. \cite{contextprogramming}}
\label{fig:mupe-context-manager}
\end{figure}
CEP -protokollan mukaisessa tilannetiedossa (\emph{Context Atom})
voidaan määrittää olio, johon tilannetieto liittyy (\cite{cep} s.
10-11). Kuvassa \ref{fig:mupe-context-manager} olevassa \emph{User
Map} -vaiheessa muutetaan oliotunniste sovelluksen käyttämäksi
tunnisteeksi. \emph{Context Manager} -komponentissa voidaan luoda
tilannetiedon tuottajakohtaisesti muunnosmäärityksiä, jossa tietyn
tilannetiedon tuottajan lähettämän tilannetietoa vastaavan olion
tunniste muunnetaan vastaamaan sovelluksessa olevaa objektia.
Esimerkki tällaisesta muunnoksesta on vaikkapa paikkatietoa
käsiteltäessä laitteen tunnisteen muuttaminen laitetta käyttävän
käyttäjän tunnisteeksi. Nämä muunnosmääritykset voivat sijaita
tiedostossa, joka luetaan muistiin \emph{Context Manager}
-komponentin käynnistyessä. Vaihtoehtoisesti \emph{World Manager}
-komponentti voi lähettää \emph{Context Manager} -komponentille XML
-viestin, jossa määritellään uusi tai poistetaan vanha muunnos.
Listauksessa \textrm{\thechapter.1} on esitetty esimerkki olion tunnisteen
muunnosmäärittelystä.
\begin{center}
\begin{verbatim}
WLAN-paikannusjarjestelma
00:02:2D:07:4A:14
Brian
\end{verbatim}
\center{Listaus \textrm{\thechapter.1}: Oliotunnisteiden muunnosmääritys}
\end{center}
Oliotunnistemääritysten käsittelyn jälkeen tilannetieto tallennetaan
\emph{Context Storage} -kom\-po\-nen\-tti\-in. Tallennuksen yhteydessä
ilmoitetaan \emph{Script Engine} -komponentille uuden tilannetiedon
saapumisesta. \emph{Script Engine} -komponentti sisältää XML -muodossa
määritettyjä skriptejä, joilla määritetään ``if-then-else''
-tyyppisesti ehtoja. Näissä ehdoissa voidaan viitata tallenettuihin
tilannetietoihin (CEP -protokollan ``Atomi''). Ehtojen täyttyessä
voidaan laukaista toimintoja MUPE -palvelimesta. MUPE -alusta sisältää
työkalut skriptien luomiseen. Listauksessa
\textrm{\thechapter.2} on esimerkki skriptistä, jossa
määritetään MUPE palvelimesta kutsuttavaksi metodikutsu
\emph{clientSetLocation} silloin kun CEP -atomissa nimeltä
\emph{LISLocation} tapahtuu muutos millä tahansa oliotunnisteelle.
\small{
\begin{verbatim}
\end{verbatim}}
\normalsize
Listaus \textrm{\thechapter.2}: Esimerkki tilannetiedon perusteella toimintoja laukaisevasta skriptistä.\\
Tilannetietoa voidaan lähettää MUPE -sovelluksille \emph{Con\-text
Pro\-ducer} -komponettien lisäksi simulaattoreilla. Simulaattorit
kommunikoivat \emph{World Ma\-na\-ger} -komponentin kanssa.
Simulaattorien avulla voidaan muodostaa nopeasti CEP -protokollan
mukaisia XML -dokumentteja, joiden sisältämiä CEP -protokollan
mukaisia tietorakenteiden arvoja voidaan simulaattorin avulla
vaihdella. MUPE -alustaan sisältyy graafinen työkalu simulaattorien
tekoon. Simulaattorit on jaoteltu neljään luokaan:
tapahtumapohjainen, aluepohjainen, 1D -jatkuva ja 2D -jatkuva.
Tapahtumapohjaisella simulaattorilla voidaan rakentaa yksittäisiä
tapahtumia simuloivia CEP -atomeja. Esimerkiksi kuun vaiheita
voitaisiin simuloida tällä tavoin. Aluepohjaisella simulaattorilla
voidaan laukaista tapahtumia määrittämällä tapahtumaa vastaava alue
annetulta pohjakartalta. Tämäntyyppinen simulaattori sopii
esimerkiksi huonekohtaista paikkatietoa tuottavan järjestelmän
simulointiin. Yksiulotteista, jatkuvamuotoista tietoa tuottavalla
simulaattorilla voidaan simuloida tietyn muuttujan vaihteluita
määritetyltä arvoväliltä. Tällainen arvoväli on esimerkiksi lämpötila.
Kaksiulotteista, jatkuvamuotoista dataa tuottavalla simulaattorilla
taas voidaan simuloida esimerkiksi koordinaattimuutoksia annetulta
pohjakartalta. Kuvassa \ref{fig:aluesimulattori} on esimerkki
aluepohjaisen simulaattorin käyttöliittymästä. Simulaattori on jaettu
kolmeen osaan. Ylimmäisessä osassa on simuloitavan alueen pohjakartta.
Pohjakartalle on määritetty alueet, jotka vastaavat simuloitavia CEP
-atomin tietoja. Toiseksi alimmaisessa osassa näytetään CEP -atomi,
joka vastaa tällä hetkellä valittua aluetta (sama alue näytetään myös
tummennetuilla reunoilla simulaattorin yläosassa). Alimmaisessa osassa
näytetään viimeksi MUPE -sovellukselle lähetetty CEP -atomi.
Simulaattoria voidaan käyttää vain samalla koneella, jossa itse MUPE
-palvelin ajetaan, sillä \emph{World Manager} -komponentti hyväksyy
vain lokaaleja yhteyksiä.
\begin{figure}[h]
\centering
\includegraphics[width=0.8\textwidth]{kuvat/aluesimulaattori.png}
\caption{Esimerkki aluepohjaisesta simulaattorista.}
\label{fig:aluesimulattori}
\end{figure}
\chapter{Toteutetut palvelut}
Tässä luvussa kuvataan toteutettuja järjestelmiä sekä palveluita,
joissa kerätään ja hyödynnetään paikka- sekä tilannetietoa.
Järjestelmien toteutuksessa on hyödynnetty Lappeenrannan Teknillisen
Yliopiston (LTY) tietoliikenteen laitoksen WLPR.NET -projektissa
rakennettua WLAN -verkkoa (myöhemmin WLPR.NET).
%\large{WLPR.NET -verkon kuvaus}
%\begin{itemize}
%\item tomin di (tosin ei voi viitata kun ei ole valmis..), vladki,
% radek, muita wlpr di -töitä?
%\item kannattaisi kertoa mitä paikkatietoisia palveluita projektiin
% kehitettiin ennen kuin nähtiin tarpeelliseksi yleisen rajapinnan
% luonti
%\end{itemize}
WLPR.NET kattaa LTY:n kampus -alueen, osan Lappeenrannan Skinnarilan
ja Sammonlahden kaupunginosista sekä myös muutaman alueen kaupungin
keskustasta. WLPR.NET -verkko on rakennettu \emph{Lappeenranta}
-mallin mukaisesti \cite{juutilainen02}, joka tarkoittaa että WLAN
-verkossa käyttäjät voivat vapaasti liittyä verkkoon. Verkko
itsessään tarjoaa vain alueelliset yhteydet. WLPR.NET -verkko on
operaattorineutraali, toisin sanoen, mikään yksittäinen
verkko-operaattori ei kokonaan omista tai hallinnoi verkkoa. Internet
-operaattoreita varten WLPR.NET -verkko tarjoaa
yhdysliikennepistemallin, jonka kautta Internet -operaattori voi
tarjota WLPR.NET -verkkoon Internet -yhteyttä. Käyttäjät voivat
vapaasti valita operaattorin, jonka kautta heidän Internet
-liikenteensä reititetään. Lisäksi WLPR.NET -verkko tarjoaa
mahdollisuuden paikallisiin palveluihin, joita voidaan alueverkkoon
rakentaa ilman että pääsy näihin palveluihin kulkisi Internet
-operaattorin kautta. Voidaankin sanoa, että tällaisen verkkomallin
rakentamisen perustana on ollut avoimen tietoyhteiskunnan kehitys,
jossa tietoverkkoon pääsy on avointa ja kaikille mahdollista.
%\large{wlpr -rakennekuva!!}
%Muita operaattorineutraaleja verkoja on myöskin kehitetty\ldots
\ac{LIS} -palvelun toimintaidea mukailee \emph{Lappeenranta} -mallissa
\cite{juutilainen02} esitettyä ideaa palvelurajapinnasta. Jotta
WLPR.NET -verkkoon liittyvät palveluntarjoajat olisivat tietoisia
verkon tarjoamista palveluista, tarjoaa verkko rajapintoja
palveluntarjoajien käyttöön. Palvelurajapinta toimii myös paikkana,
josta käyttäjät voivat nähdä verkossa toimivat palvelut. Verkon
itsensä tarjoama palvelu on tässä tapauksessa paikannuspalvelu, joka
pystyy kertomaan käyttäjien sijainnin verkon alueella.
Paikkatietopalvelu on verkon itsensä tarjoama, mutta palvelurajapinnan
tarkoitus on toimia myös pisteenä, jossa muutkin palveluntarjoajat,
kuin verkko itse, voivat mainostaa palveluitaan.
WLPR.NET -verkkoon on kehitetty solupaikannuspalvelu, jolla kerättiin
verkossa liikkuvien päätelaitteiden sijaintia tukiasemakohtaisesti.
Myös muita paikannusmekanismeja oli tutkittu \cite{seppanen}.
Kuitenkin ongelmana oli edelleen se, että tutkitut palvelut olivat
jäänee pääosin verkon ylläpidon käyttöön (esim. Mikko Hietalan
paikkatietoinen pikaviestinpalvelu \cite{hietala}). Palvelut
sijaitsivat verkon palvelimilla ja pääsy paikkatietoon vaati pääsyä
suoraan itse tietokantaan, jonne solupaikkatieto oli kerätty. Tämän
mallin ongelma on, että uusille kehitettäville palveluille jouduttiin
sallimaan pääsy suoraan itse tietokantaohjelmiston
pääsynhallintamekanismein (jotka sinänsä voivat olla hyvinkin
päteviä), mutta palvelunkehitys ei näin ollen ollut vapaata. Ongelma
on myös se, että suoralla tietokantayhteydellä paikkatietoinen palvelu
on hyvin riippuvainen solupaikkatiedon tietomallista. Tämä tietomalli
taas ei välttämättä ole sopiva itse palvelulle. Lisäksi, jos
paikkatiedon keräykseen ja tietomalliin tehdään muutoksia, joudutaan
samalla myös palvelua muuttamaan, vaikka tämä ei välttämättä olisi
tarpeellista. Palvelut joutuvat sitoutumaan myös vain solupaikkatiedon
käsittelyyn, vaikka paikkatiedon esitys karttamallilla voisi olla
sopivampaa.
Ongelmaksi voidaan kokea tämän tyyppisessä integroidussa mallissa se,
että paikkatiedon käsittelyssä jäivät monet parametrit huomioimatta.
Esimerkiksi paikkatiedon tarkkuus, varmuus ja paikkatiedon käytön
salliminen olivat kaikki asioita, jotka palvelujen tuli itse ottaa
huomioon. Palvelunkehitystä helpottaisi, mikä nämä parametrit olisivat
tarjottuina itse paikkatietopalvelusta käsin. \ac{LIS} -palvelun
kehittäminen nähtiin mahdollisuutena tuoda ratkaisu osaan näistä
ongelmista. \ac{LIS} ei kuitenkaan tarjoa ratkaisua kuin osaan näistä
ongelmista, mutta muut osuudet on jätetty jatkokehityksen varalle.
\section{Location Information System - LIS}
\label{sec:lis}
Location Information System (LIS) on palvelu, joka tarjoaa rajapinnan
paikkatietoisille palveluille. Palvelun tarkoitus on tarjota
rajapinta, joka mahdollistaa paikkatiedon käytön WLAN -verkossa.
Palvelu mahdollistaa myös paikkatiedon käytön hallinnan sekä toimii
yhteyspisteenä, jonka kautta käyttäjät voivat nähdä käytettävissä
olevat paikkatietoiset palvelut. LIS -palvelun toimintaa on kuvattu
julkaisussa \cite{lis} (Location Information System -- a Description
of a Positioning Middleware System).
%\subsection{LIS Arkkitehtuuri ja toteutus}
LIS -palvelun arkkitehtuurin yleiskuva on esitetty kuvassa
\ref{fig:lis-yleiskuva}. LIS koostuu paikkatiedon keruun muodostavasta
järjestelmästä, palveluille tarjotusta pyyntörajapinnasta sekä
palvelujen ja käyttäjien hallintarajapinnasta. WLAN -päätelaitteiden
paikkahavainnot kerätään tietokantaan ja LIS tarjoaa pääsyn tähän
tietoon \ac{SOAP} -rajapinnan kautta. \ac{SOAP} -rajapinnan rakenne on
kuvattu \ac{WSDL} -rajapintakuvauskielen avulla. \ac{WSDL}
-dokumentti, jossa rajapinta on kuvattu, on saatavissa WLPR.NET
-verkon WWW -sivujen kautta. LIS -palvelu on toteutettu käyttäen
Perl -ohjelmointikieltä sekä SOAP::Lite -kirjastoa \cite{soap-lite}
\ac{SOAP} -protokollan käyttämiseen.
\ac{SOAP} -protokollan valinta käytettäväksi rajapinnaksi
paikkatietokyselyille johtui suuresta sovelluskehitystyökalujen
määrästä. SOAP -protokollan toteuttavia kirjastoja oli saatavilla
useille eri ohjelmointikielille (mm. Perl, Java, C, C++). SOAP on osa
Web Services -arkkitehtuuria\cite{wsa}, joten kyseisen protokollan
valinta nähtiin hyvänä lähtökohtana verkkopalveluiden kehittämiseen.
\begin{figure}[h]
\centering \includegraphics[width=0.9\textwidth]{kuvat/lis-yleiskuva}
\caption{\ac{LIS} -yleiskuva.}
\label{fig:lis-yleiskuva}
\end{figure}
\subsection{Paikkatiedon keruu}
\ac{LIS} -järjestelmä käyttää \ac{WLAN} -verkosta saatavaa
solupohjaista paikkatietoa. \ac{WLAN} -verkkona on käytetty WLPR.NET
-projektin rakentamaa WLPR.NET -verkkoa. Paikkatietohavaintojen keruun
pohjana toimii käyttäjien \ac{WLAN} -tukiasemien käytön seuraaminen.
Tarkempaa paikkatiedon keruujärjestelmää ei toteutettu, sillä
solupaikannuksen hyödyntäminen nähtiin riittävänä. Toisaalta tarkemman
paikannusjärjestelmän käyttäminen olisi vaatinut huomattavasti enemmän
resursseja tai valmiin tuotteen (kuten Ekahau EPE) käyttämistä.
Kun käyttäjä muodostaa yhteyden WLAN -päätelaitteellaan (esimerkiksi
kannettava tietokone, jossa on 802.11b -standardien mukainen \ac{WLAN}
-radio) \ac{WLAN} -tukiasemaan, käy päätelaite läpi tilanvaihdokset, jotka
on määritelty \ac{IEEE}:n 802.11 -standardissa \cite{802.11} (kpl 5.5
Relationships between services). Tilanvaihdokset on esitetty kuvassa
\ref{fig:wlan-sta-tilat}.
\begin{figure}[h]
\centering
\includegraphics[width=\textwidth]{kuvat/wlan-sta-tilat.pdf}
\caption{WLAN -päätelaitteen tilakaavio.}
\label{fig:wlan-sta-tilat}
\end{figure}
\ac{WLAN} -päätelaitteet pitävät yllä kahta tilamuuttujaa,
\emph{assosiaatio} ja \emph{autentikaatio}. Assosiaatiolla
tarkoitetaan tilaa jossa on muodostettu yhteys \ac{WLAN}
-päätelaitteen ja tukiaseman välillä ja päätelaite voi välittaa dataa
\ac{WLAN} -verkossa. Autentikaatiolla tarkoitetaan tilaa, joka
ilmaisee onko päätelaitteella lupa liittyä \ac{WLAN} -verkkoon ja
välittää dataa verkossa.
Kun päätelaite liittyy verkkoon, autentikoituu laite ensin
tukiasemalle. WLPR.NET -verk\-os\-sa on käytössä 802.11 -standardissa
määritetty \emph{Open System Authentication} -au\-ten\-ti\-koin\-ti\-ta\-pa.
\emph{Open System Authentication} -autentikointitavassa ei ole
käytössä varsinaista autentikointialgoritmia, vaan tukiasema joko
sallii tai evää päätelaitteen autentikointipyynnön.
Autentikointipyynnön sallimisen perustana käytetään WLPR.NET -verkossa
\ac{RADIUS} -palvelua. Verkossa olevat tukiasemat, joista suurin osa on Orinoco
AP-1000 mallia, on konfiguroitu käyttämään autentikointiin RADIUS
-palvelua. Kun päätelaite yrittää liittyä WLPR.NET -verkkoon, siirtyy
se kuvan \ref{fig:wlan-sta-tilat} mukaan tilasta 1 tilaan 2. Tällöin
tukiasema lähettää autentikointipyynnön \ac{RADIUS} -palvelimelle. Jos
\ac{RADIUS} -palvelin vastaa myöntävästi pyyntöön, antaa tukiasema
päätelaitteelle ilmoituksen autentikoinnin onnistumisesta. Tämän
jälkeen päätelaite voi alkaa käyttämään verkkoa. Tällöin tapahtuu
assosiaatio tukiaseman kanssa. Myös päätelaitteen liikkuessa eri
tukiasemien välillä, autentikoituu päätelaite uudelle
tukiasemalle\footnote{802.11 standardi määrittelee myös myös
``esiautentikoinnin'' (Preauthentication), jossa päätelaite
autentikoituu havaitsemilleen tukiasemille etukäteen ennen
assosiointia. Tämä menettely nopeuttaa tukiasemasta toiseen
liikkumista (roaming), mutta voi myös haitata autentikointiin
perustuvaa paikkatietokeräystä.}.
\ac{RADIUS} -palvelu pitää lokia tehdyistä autentikointipyynnöistä.
Näin ollen lokitiedostoon muodostuu päätelaitteiden sijaintihistoria.
Nämä lokimerkinnät sisältävät autentikointipyynnön tehneen tukiaseman
\ac{IP} -osoitteen sekä autentikoidun päätelaitteen \ac{MAC}
-osoitteen. Päätelaitteen liikkuessa verkon alueella tukiasemasta
toiseen, voidaan laitteen liikkuminen päätellä lokin sisällöstä.
\ac{RADIUS} -palvelimen lokia seurataan WLPR.NET -verkossa
parseriohjelmalla, joka päivittää paikkatietohavaintoja kuvassa
\ref{fig:lis-yleiskuva} esitettyyn tietokantaan. Tietokanta sisältää
\ac{WLAN} -päätelaitteiden viimeisimmät sijaintihavainnot. Tämä
paikkatiedon keruumekanismi luottaa \ac{RADIUS} -palvelun toimintaan
edelläkuvatulla tavalla. Kuitenkin projektin aikana käyttöön otettiin
tukiasemia, joilla ei ollut mahdollista hallita autentikointiprosessia
\ac{RADIUS} -palvelun avulla. Näitä tukiasemia varten (mm. Nokia A032
tukiasemat) on WLPR.NET -projektissa toteutettu kyselymekanismi, jolla
väliajoin aktiivisesti kysellään tukiasemissa assosioituneena olevia
päätelaitteita. Kyselymekanismi on toteutettu WLPR.NET -projektissa
Perl -skriptillä, jossa on tukiaseman tyypistä riippuva toteutus
assosioituneiden päätelaitteiden hakuun (esim. \ac{HTML} -sivun
tulkinta Nokia A032 tukiasemasta). Kyselymenetelmän ongelma on se,
että tukiasemien siltaustauluissa saattaa olla tukiasemaa käyttävien
\ac{WLAN} -päätelaitteiden \ac{MAC} -osoitteita vielä senkin jälkeen,
kun päätelaite on siirtynyt käyttämään toista tukiasemaa.
Siirryttäessä käyttämään tukiasemaa, joka käyttää \ac{RADIUS}
-autentikointia, päivittyy uusi solusijaintitieto tietokantaan. Mutta
siirryttäessä takaisin sellaisen tukiaseman alueelle, jossa
\ac{RADIUS} -autentikointi ei ole käytössä, saatetaan tulkita, että
päätelaite olisi vielä vanhassa sijainnissaan ja päivitystä ei tehdä.
\subsection{WWW -hallintarajapinta}
WWW -hallintarajapinta toteutettiin \ac{PHP} ohjelmointikielen avulla
ja Apache 1.3 WWW -palvelinta käyttäen. Nämä työkalut valittiin sekä
hyvän dokumentaation, että aikaisemman kokemuksen vuoksi. Käyttäjät
hallitsevat paikkatietonsa käyttöä \ac{WWW} -pohjaisen
hallintarajapinnan kautta. Ennen kuin hallinta on mahdollista,
rekisteröityvät käyttäjät LIS -palveluun. Rekisteröinnin avulla
sidotaan käyttäjän identiteetti päätelaitteen \ac{WLAN} -radioon.
Rekisteröinnin toiminta on seuraava:
\begin{enumerate}
\item Käyttäjä ottaa WWW -selaimella yhteyden \ac{LIS} -palvelun
\ac{WWW} -palvelimelle ja aloittaa rekisteröintiprosessin.
\item Rekisteröintiprosessissa otetaan talteen käyttäjän \ac{IP}
-osoite.
\item \ac{WWW} -palvelimen \ac{ARP} -taulusta etsitään \ac{IP}
-osoitetta vastaava \ac{MAC} -osoite.
\item \ac{MAC} -osoite tallennetaan käyttäjän profiiliin.
\end{enumerate}
Rekisteröinnin jälkeen käyttäjä voi valita palvelut, joille hän
myöntää luvan oman paikkatiedon käyttöön. Käyttäjä voi myös myöhemmin
vaihtaa hänellä käytössään olevaa päätelaitetta ja ilmoittaa vaihdon
\ac{LIS} -järjestelmään. Käyttäjällä voi olla vain yksi laite
kerrallaan käytössä.
Palveluntarjoaja, joka haluaa hyödyntää \ac{WLAN} -verkon käyttäjien
paikkatietoa, rekisteröi palvelunsa \ac{LIS} -järjestelmään. Palvelut
tunnistetaan tunnuksesta, jonka palveluntarjoaja voi
rekisteröintivaiheessa määrittää. Palvelun rekisteröinnissä
palveluntarjoaja jättää palvelustaan kuvauksen \ac{LIS}
-järjestelmään.
%WWW -hallintarajapinnan toiminnoista on esitetty
%yhteenveto kuvassa \ref{fig:lis-www-rajapinta}.
%
%\begin{figure}[h]
% \centering
% \includegraphics[width=\textwidth]{kuvat/lis-www.pdf}
% \caption{\ac{WWW} -hallintarajapinnan operaatiot käyttäjäryhmittäin.}
% \label{fig:lis-www-rajapinta}
%\end{figure}
Kuvassa \ref{fig:lis-palveluntarjoaja} on esitetty palveluntarjoajan
käyttöliittymä. Palveluntarjoaja saa palvelutunnuksen
rekisteröitymisen yhteydessä salasanan, joka voidaan vaihtaa
käyttöliittymän toiminnolla. Samoin palvelu voidaan poistaa
käyttöliittymästä käsin. Mikäli palvelu käyttää SOAP -rajapinnan
ilmoitusmetodeja, tulee myös täyttää palvelun attribuuteissa (kuvassa
\ref{fig:lis-palveluntarjoaja} attributes -otsikon alla) olevat proxy
sekä XML -nimiavaruus. Proxy kertoo minne ilmoitus tehdään (\ac{HTTP}
-palvelin) ja XML -nimiavaruutta käytetään muodostettavissa SOAP
-viesteissä nimiavaruutena.
\begin{figure}[h]
\centering
\includegraphics[width=0.9\textwidth]{kuvat/lis-palvelu.png}
\caption{Palveluntarjoajan käyttöliittymä}
\label{fig:lis-palveluntarjoaja}
\end{figure}
Kuvassa \ref{fig:lis-kayttaja} on esitetty käyttäjien käyttöliittymä
paikkatiedon käytön hallintaan. Käyttäjät näkevät paikkatietoa
hyödyntävät palvelut ja voivat palvelukohtaisesti sallia tai kieltää
oman paikkatietonsa käytön. Käyttäjä saa tunnuksen
rekisteröintivaiheessa salasanan, joka voidaan muuttaa
käyttöliittymästä käsin. Käyttäjä voi myös poistaa tunnuksensa
järjestelmästä käyttöliittymästä käsin. Mikäli käyttäjän WLAN -laite
vaihtuu, voidaan se käydä päivittämässä käyttäjän profiiliin.
Kirjauduttaessa LIS -palveluun, näytetään käyttäjällä sillä hetkellä
käytössä olevan WLAN -laitteen MAC -osoite, joka voidaan tallentaa
profiilissa olevan tilalle. Tällöin käyttäjällä voi olla kerrallaan
käytössä vain yksi paikannettava laite.
\begin{figure}[h]
\centering
\includegraphics[width=0.9\textwidth]{kuvat/lis-kayttaja.png}
\caption{Käyttäjien käyttöliittymä}
\label{fig:lis-kayttaja}
\end{figure}
\FloatBarrier
\subsection{\acf{SOAP} -palvelurajapinta}
Palvelurajapinnan kautta palvelut voivat tehdä pyyntöjä käyttäjien
solusijainneista \ac{WLAN} -verkossa. Palvelut voivat myös kysellä
solusijainteihin liitettyjä tietoja (esim. solun tukiaseman
sijaintikoordinaatit). \ac{SOAP} -rajapinnan toiminnot on jaettavissa
kahteen osaan:
\begin{itemize}
\item \emph{Pyyntömetodit} \\
Näitä metodeja käytetään paikkatiedon kyselyyn. Kuvaukset
pyyntömetodeista parametreineen on esitetty taulukossa
\ref{tab:lis-pyynnöt}.
\item \emph{Ilmoitusmetodit (triggerit)} \\
Näillä metodeilla voidaan seurata yksittäisten käyttäjien liikkeitä.
Kun käyttäjän paikassa tapahtuu muutos, ilmoittaa LIS -palvelu tästä
uuden sijainnin tekemällä \ac{SOAP} -kutsun palveluun. Ilmoituksien
käsittelyyn liittyvät metodit on esitetty taulukossa
\ref{tab:lis-triggerit}.
\end{itemize}
\begin{table}[h]
\centering
\caption{LIS -palvelurajapinnan pyyntömetodit}
\begin{tabularx}{\textwidth}{|l|X|}
\hline
\multicolumn{1}{|c|}{\textbf{Metodi}} & \multicolumn{1}{c|}{\textbf{Kuvaus}} \\
\hline
GetUserLocation & Hakee annetun käyttäjän (tai \ac{MAC} -osoitteen) viimeisimmän sijainnin \\
\cline{2-2}
& \multicolumn{1}{c|}{\textbf{Parametrit}} \\
\cline{2-2}
&
\begin{tabular}[h]{lp{6cm}}
\textit{target}: & Haun kohde \\
\textit{caller}: & Haun tekijä (ei käytetty) \\
\textit{service}: & Palvelu joka tekee haun \\
\textit{password}: & Palvelun salasana \\
\textit{ttype}: & Kohteen tyyppi (käyttäjä, mac) \\
\textbf{paluuarvo}: & GetUserLocationResponse -elementti jossa sekä solu (\textit{location\_id}), että aikaleima (\textit{timestamp}) jolloin
havainto tehtiin elementteinä \\
\end{tabular} \\
\hline
\multicolumn{1}{|c|}{\textbf{Metodi}} & \multicolumn{1}{c|}{\textbf{Kuvaus}} \\
\hline
GetLocationInfo & Hakee tietoja annetusta solutunnisteesta \\
\cline{2-2}
& \multicolumn{1}{c|}{\textbf{Parametrit}} \\
\cline{2-2}
&
\begin{tabular}[h]{lp{6cm}}
\textit{location\_id}: & Solutunniste josta tietoa pyydetään \\
\textit{location\_type}: & Haetun tiedon tyyppi \\
\textit{service}: & Palvelu joka tekee haun \\
\textit{password}: & Palvelun salasana \\
\textbf{paluuarvo}: & Pyydetty tieto tietorakenteessa, joka sisältää pyyden
tiedon tyyppiset kentät \\
\end{tabular} \\
\hline
\multicolumn{1}{|c|}{\textbf{Metodi}} & \multicolumn{1}{c|}{\textbf{Kuvaus}} \\
\hline
GetLocationList & Hakee listan kaikista paikannusjärjestelmän soluista \\
\cline{2-2}
& \multicolumn{1}{c|}{\textbf{Parametrit}} \\
\cline{2-2}
&
\begin{tabular}[h]{lp{6cm}}
\textit{service}: & Palvelu joka tekee haun \\
\textit{password}: & Palvelun salasana \\
\textbf{paluuarvo}: & Taulukko solutunnisteista \\
\end{tabular} \\
\hline
\end{tabularx}
\label{tab:lis-pyynnöt}
\end{table}
\FloatBarrier
Pyyntömetodeissa voi kohteena käyttää käyttäjän nimeä tai \ac{MAC}
-osoitetta. Käyttäjän nimeä käyttämällä voidaan yksittäinen käyttäjä
identifioida, mutta \ac{MAC} -osoitteella identifioidaan vain
yksittäinen laite. Riippuen palvelusta, voi olla mielekästä käyttää
\ac{MAC} -osoitetta. Koska ei voida olla varmoja käyttösäännöistä,
jotka yksittäistä \ac{MAC} -osoitetta koskevat, käydään LIS
-palvelussa läpi mahdolliset laitteen käyttäjät. Kyselyssä pyydetty
tieto annetaan vain, mikäli kaikki mahdolliset laitteen käyttäjät
antavat tähän suostumuksen. On siis mahdollista, että yhdellä
laitteella on useampi käyttäjä, joita koskevat ristiriitaiset
käyttösäännöt.
Mikäli pyynnön kohteena olevalla \ac{MAC} -osoitteella identifoidulla
laitteella ei ole käyttäjää, sovelletaan oletussääntöjä. LIS
-palvelussa voidaan määrittää palveluita, joille paikkatieto voidaan
antaa joka tapauksessa. Tällainen palvelu voi olla esimerkiksi
hätäpalvelu, joka hätätilanteessa paikantaa käyttäjän ja pyrkii
auttamaan viranomaisia.
Pyyntömetodien käyttämät solutunnisteet on nimetty siten, että
tunnisteen alkuosa ilmaisee organisaation ja lopuosa sijainnin
organisaation tiloissa. Esimerkiksi LTY:n sisätiloissa olevan solun
nimi voi olla vaikkapa \emph{LTY\_6606}, jossa 6606 ilmaisee
tukiasemaa lähinnä sijaitsevan huoneen numeron. Solutunniste on
sinänsä yleinen ja yksilöi vain tukiaseman. Sijaintitiedon esittäminen
pelkällä solutunnisteella on vaikeaa, joten tunnisteisiin voidaan
liittää lisätietoa.
Solutunnisteeseen liittyväksi tietotyypeiksi on tällä hetkellä
määritetty kuvaus sekä solun tukiaseman sijaintikoordinaatit.
Sijaintikoordinaatteina on käytetty Lappeenrannan kaupungin
koordinaatistoa. Tukiaseman sijaintikoordinaatit ovat siten
käytettävissä mm. Lappeenrannan kaupungin
karttapalvelussa\footnote{\url{http://kartta.lappeenranta.fi}}. Solua
esittävä kuvaus pyrkii esittämään tukiaseman ympäristön
tekstipohjaisesti.
\begin{table}[h]
\centering
\caption{LIS -palvelurajapinnan ilmoitusmetodit}
\begin{tabularx}{\textwidth}{|l|X|}
\hline
\multicolumn{1}{|c|}{\textbf{Metodi}} & \multicolumn{1}{c|}{\textbf{Kuvaus}} \\
\hline
SetTrigger & Asettaa ``triggerin'' määritellylle käyttäjälle. Muutokset
käyttäjän liikkeissä raportoidaan takaisin triggerin asettaneelle palvelulle. \\
\cline{2-2}
& \multicolumn{1}{c|}{\textbf{Parametrit}} \\
\cline{2-2}
&
\begin{tabular}[h]{lp{6cm}}
\textit{target}: & Käyttäjä jota halutaan seurata \\
\textit{service}: & Palvelu joka tekee haun \\
\textit{password}: & Palvelun salasana \\
\textit{uri}: & Nimiavaruus josta josta ilmoituksen tekemiseen
käytettävää \emph{FireTrigger} -metodia kutsutaan \\
\textit{proxy}: & URL osoite josta ilmoitusmetodia kutsutaan \\
\textbf{paluuarvo}: & Triggerin tunnistenumero \\
\end{tabular} \\
\hline
\multicolumn{1}{|c|}{\textbf{Metodi}} & \multicolumn{1}{c|}{\textbf{Kuvaus}} \\
\hline
DeleteTrigger & Poistaa aiemmin asetetun ``triggerin'' \\
\cline{2-2}
& \multicolumn{1}{c|}{\textbf{Parametrit}} \\
\cline{2-2}
&
\begin{tabular}[h]{lp{6cm}}
\textit{trigger\_id}: & Seuranta-``triggerin'' tunnistenumero \\
\textit{service}: & Palvelu joka tekee haun \\
\textit{password}: & Palvelun salasana \\
\textbf{paluuarvo}: & Poistetun triggerin tunnistenumero \\
\end{tabular} \\
\hline
\multicolumn{1}{|c|}{\textbf{Metodi}} & \multicolumn{1}{c|}{\textbf{Kuvaus}} \\
\hline
FireTrigger & Ilmoitusmetodi, jolla palvelulle ilmoitetaan seuratun käyttäjän liikkeistä \\
\cline{2-2}
& \multicolumn{1}{c|}{\textbf{Parametrit}} \\
\cline{2-2}
&
\begin{tabular}[h]{lp{6cm}}
\textit{trigger\_id}: & Seuranta-``triggerin'' tunnistenumero \\
\textit{location\_id}: & Uusi solusijainti, jonne käyttäjä on liikkunut \\
\textbf{paluuarvo}: & Ei käytössä \\
\end{tabular} \\
\hline
\end{tabularx}
\label{tab:lis-triggerit}
\end{table}
\FloatBarrier
Ilmoitusmetodien päätarkoitus on mahdollistaa tietyn käyttäjän
seuraaminen. Ilmoitusmetodien käytöllä on tarkoitus antaa palveluille
mahdollisuus toimia ilmoituspohjaisesti sen sijaan, että käyttäjien
liikkeitä kyseltäisiin jatkuvasti. Jotta ilmoituksia paikan
vaihdoksesta voitaisiin vastaanottaa, tulee palvelun ensin
rekisteröidä halukkuus vastaanottaa ilmoituksia. Tämä tapahtuu
\emph{SetTrigger} -metodilla, jolla määritetään
käyttäjä, jota halutaan seurata. Kutsun jälkeen palvelu saa
tunnistenumeron, jolla palvelu voi identifioida asettamansa
ilmoituspyynnöt.
Kun määritetyn käyttäjän paikkatiedossa tapahtuu muutos, ilmoitetaan
tästä palvelulle \ac{SOAP} -rajapinnan avulla. Ilmoituksen vastaanottaminen
tapahtuu \emph{FireTrigger} -metodilla, jonka palvelun tulee
toteuttaa. Tällä hetkellä kuljetuskerroksena käytetään \ac{HTTP}
-pro\-to\-kol\-laa, joten \emph{FireTrigger} -metodin toteutuksen tulee olla
\ac{HTTP} -protokollaan sidottu. Kun paikan muutoksesta ilmoitetaan, LIS
kutsuu paikkatietoisen palvelun toteuttamaa \emph{FireTrigger}
-metodia. Kutsu tapahtuu muodostamalla \ac{SOAP} -protokollan mukainen XML
-dokumentti ja lähettämällä se \ac{HTTP} -protokollan avulla palvelun
määrittämälle \ac{HTTP} -palvelimelle.
\subsection{Tietokantarajapinta}
LIS -palvelu kommunikoi paikkatietokantana käytetyn PostgreSQL
-tie\-to\-kan\-nan kanssa Perl DBI -moduulin \cite{perl-dbi} avulla.
DBI -moduuli on standardi tietokantakirjastorajapinta Perl
-ohjelmointikielelle. DBI -moduuli määrittää metodit, muuttujat ja
käytännöt, jotka muodostavat yhtenäisen rajapinnan käytetystä
tietokannasta riippumatta. DBI -kirjaston metodeja käytetään
tietokannan tietojen hakuun ja päivitykseen.
Tietokantarajapinnassa on toteutettu myös toiminnallisuutta PostgreSQL
-tietokannan sisälle ilmoitusrajapinnan käyttötarkoituksiin.
Ilmoitusrajapinnassa käytetään PostgreSQL -tietokannan mahdollisuutta
ohjelmallisesti täydentää tietokannan toimintoja. Tietokannassa on
mahdollista laajentaa tietokannan toiminnallisuutta luomalla
funktioita (\cite{practical-postgresql}, s.290-291). PostgreSQL tukee
neljän tyyppisiä funktioita (\cite{postgresql7.2}, kappale 12.1):
\begin{itemize}
\item Kyselykieliset funktiot (kirjoitettu SQL -kielellä)
\item Proseduraaliset funktiot (funktiot jotka on kirjoitettu
esimerkiksi \\PL/pgSQL tai PL/Perl -kielillä)
\item Sisäiset funktiot
\item C -kielellä kirjoitetut funktiot
\end{itemize}
Ilmoitusmetodien toteutukseen käytettiin proseduraalisia
funktioita\footnote{Tietokantaan tallennetuista funktioista käytetään
myös nimitystä ``stored procedures''}. Proseduraalisissa
funktioissa PostgreSQL -tietokanta itse ei tulkitse funktion
lähdekieltä, vaan funktion lähdekielen tulkinta, syntaksin
analysointi, suoritus ja muut operaatiot annetaan funktion lähdekielen
mukaisen käsittelijän tehtäväksi. Tämä antaa mahdollisuuden käyttää
esimerkiksi Perl -kieltä tietokannasta käsin SQL -operaatioiden
yhteydessä.
Funktiolaajennuksien lisäksi käytettiin triggereitä. Triggeri on
funktio, joka suoritetaan ennen tai jälkeen jonkun muun taululle
tehdyn tapahtuman (\cite{practical-postgresql}, s.278-279).
Triggerifunktio voidaan määrittää laukaistavaksi esimerkiksi
tietokannan tietyn taulun päivittämisen (UPDATE SQL -lause)
yhteydessä. Triggerifunktion avulla voidaan tällä tavoin esimerkiksi
pitää lokia tietokannan tapahtumista. Triggerifunktio voidaan
toteuttaa PostgreSQL -tietokannan tukemilla funktionaalisilla
kielillä, poislukien SQL -kieli.
LIS -palvelun ilmoitusrajapinnan toteutuksessa hyödynnettiin PL/pgSQL
ja PL/Perl proseduraalisten kielten yhdistelmää. Kuvassa
\ref{fig:trigger} on esitetty ilmoitusmekanismin toiminta, sekä
toiminnan toteutukseen käytetyt proseduraaliset funktiot. Liitteessä
\ref{liite:plpgsql} on esitetty PL/pgSQL -trigger funktion toiminta ja
liitteessä \ref{liite:plperl} PL/Perl -välittäjäskriptin toiminta.
\begin{figure}[h]
\centering
\includegraphics[width=\textwidth]{kuvat/trigger.pdf}
\caption{Triggerien käyttö PostgreSQL -tietokannassa.}
\label{fig:trigger}
\end{figure}
\FloatBarrier
Kun paikkatietokantaan syötetään WLAN -laitteen sijaintitiedon
päivitys UPDATE -lau\-se\-el\-la, laukaistaan UPDATE -lauseeseen
yhdistetty PL/pgSQL trigger -funktio. Funktiossa vertaillaan ensin,
eroaako päivitettäväksi tarkoitettu uusi sijainti vanhasta
sijainnista. Mikäli sijainti eroaa, tarkistetaan onko kyseiselle
laitteelle triggereitä (tässä yhteydessä triggeri tarkoittaa
paikkatietoisen palvelun asettamaa seurantapyyntöä). Mikäli laiteelle
löytyy triggeri, suoritetaan PL/Perl -funktio (\ref{liite:plperl}),
joka vuorostaan välittää ilmoituspyynnön \ac{SOAP} -kutsuna LIS
-palvelulla. Kutsun parametreina välitetään uusi sijainti sekä
triggerin tunniste. LIS vuorostaan kutsuu paikkatietoista palvelua,
jolle ilmoitus välitetään kutsumalla palvelurajapinnassa määritettyä
\emph{FireTrigger} -metodia. \emph{FireTrigger} -metodi välittää
ilmoitusta haluavalle palvelulle uuden sijainnin sekä triggerin
tunnisteen. Tällä menettelyllä on mahdollista seurata
paikkatietopäivityksiä sitä mukaa, kun niitä tietokantaan päivitetään.
Järjestelmän huono puoli on lisäprosessointi, jota LIS -palveluun sekä
tietokantaan aiheutuu.
\subsection{Floating Note -viestipalvelu}
\ac{LIS} -palvelua käytettiin toteuttaamaan erikoistyönä WLPR.NET
-verkon käyttöön paikkatietoinen viestintäpalvelu, Floating Note
\cite{Multaharju04floatingnote}. Floating Note -palvelu on
paikkatietoinen viestintäpalvelu. Solupaikkatietoa käytetään luomaan
sijainteihin ``keskustelualueita''. Keskustelualueiden aluekohtaisessa
jaossa pyritään keskustelua ohjaamaan sijaintiin liittyviin aiheisiin.
Esimerkiksi lentokentällä keskusteluaiheet voivat liittyä lentokentän
toimintaan. Kuvassa \ref{fig:fnote} on esitetty esimerkkikuva
``Floating Note'' -viesteistä. Jokainen solusijainti muodostaa oman
keskustelualueensa.
\begin{figure}[h]
\centering
\includegraphics[width=\textwidth]{kuvat/notes.png}
\caption{Esimerkki paikkasidonnaisista Floating Note -viesteistä \cite{Multaharju04floatingnote}}
\label{fig:fnote}
\end{figure}
\FloatBarrier
Käyttäjät luovat tilin Floating Note -palveluun, jonka jälkeen he
voivat kirjoittaa viestejä. Tilin luonnin yhteydessä käyttäjä antaa
LIS -palveluun luoman identiteetin, jota käytetään paikannuspyyntöjen
tekemiseen. Kun käyttäjä kirjautuu palveluun, näytetään hänelle
nykyisessä sijainnissa olevat viestit. Viestit koostuvat otsikosta ja
tekstistä, johon voidaan myös liittää kuvia. Floating Note
-järjestelmä pitää kirjaa mahdollisista solusijainneista ja
solusijaintien kuvauksia voidaan myös muuttaa ylläpidon toimesta.
Järjestelmän ylläpitäjä huolehtii myös viestien ja kuvien
hallinnoinnista sekä niiden mahdollisesta poistamisesta.
Eri sijainteihin liitettyjä viestejä voidaan selata, joten viestintä
ei ole pelkästään sidottu yhteen sijaintiin. Palvelun toimintaideana
on kuitenkin luoda keskustelua, joka liittyisi tiettyyn sijaintiin.
\section{MUPE -alustan sovellukset}
Tilanne- ja paikkatiedon käyttöä sovellettiin MUPE -alustalla tilanne-
ja paikkatietoisten sovelusten kehittämiseen. Sovellusten
kehittämiseksi toteutettiin MUPE -alustan tilannetietorajapinnalle,
\acf{CEP}, tilannetiedon tuottajakomponentteja (\emph{Context
Producer}). Tilannetiedon lähteinä toimivat WLPR.NET WLAN -verkko,
ilmatieteen laitoksen sääpalvelu, Tunturi recumbent -kuntopyörä sekä
\ac{RFID} -tunnisteiden lukija. WLAN -verkosta kerättiin paikkatietoa
kahdella eri järjestelmällä. Nämä järjestelmät olivat kappaleessa
\ref{sec:lis} esitetty \ac{LIS} -järjestelmä sekä Ekahau -yrityksen
tuottaman \acf{EPE} 2.0. LIS -järjestelmän avulla saatiin kerättyä
solupohjaista paikkatietoa. Ekahau -järjestelmän avulla tuotettiin
LTY:n sisätiloista, erityisesti tietoliikennetekniikan laitoksen
läheisistä tiloista, rakennuksen pohjapiirustuksiin pohjaavaa
paikkatietoa. Toteutettuja tilannetiedon tuottajia käytettiin hyväksi
MUPE -sovellusten kehitykseen sekä LTY:ssä järjestetyn
Sovelluskehityksen erikoiskurssin aikana sekä Tribal Exchange
-peliprojektissa.
\subsection{Tilannetiedon tuottajat}
Kuvassa \ref{fig:contextproducers} on esitetty toteutus miten
tilannetietoa käsitellään MUPE -sovelluksen sisällä. \emph{MUPE
Server} -komponentin sisältämä \emph{Context Manager} -objekti
sisältää metodit, jotka käsittelevät vastaanotetun tilannetiedon
(esim. \emph{clientSetEkahauLocation()}). Haluttu tilannetieto
välitetään näiden metodien parametreisssa. \emph{MUPE Context Manager}
-komponettiin toteutettiin jokaista tilannetiedon tuottajaa varten XML
-skriptit, joiden avulla MUPE -sovelluksen \emph{Context Manager}
-objektin metodeja kutsutaan. Esimerkki näistä skripteistä on esitetty
liitteessä \ref{liite:lislocationrules}. Liitteessä olevaa skriptiä
käytettiin välittämään \ac{LIS} -palvelurajapinnalta pyydetty uusi
paikkatietonäyte MUPE -sovelluksen metodille \emph{clientSetLocation}.
\begin{figure}[h]
\centering
\includegraphics[width=\textwidth]{kuvat/mupe-tilannetieto.pdf}
\caption{Tilannetiedon tuottajien yleiskuvaus}
\label{fig:contextproducers}
\end{figure}
\FloatBarrier
Säätietoa haettiin Ilmatieteen laitoksen tarjoamalta WWW
-sivustolta\footnote{\url{http://www.fmi.fi}}, jolta löytyy
paikkakuntakohtaisesti säähaintotiedot. Tiedot päivittyvät tunnin
välein. Säätiedon tuottaja hakee määräajoin \ac{HTTP} -protokollan
avulla säähavaintosivuston ja parsii tästä sivusta säähavainnot. Kun
havainnot on parsittu, ne lähetetään yhteyden ottaneille MUPE
-sovelluksille CEP -protokollan mukaisina XML -viesteinä (CEP atomit).
Säähavaintoja voidaan lähettää MUPE -palvelimille tiheämmin kuin
tunnin välein, mutta tällöin havaintotiedot pysyvät samoina tunnin
sisällä.
LTY:n tietoliikenteen laitokselle oli hankittu PTD (Personal Trusted
Device) -tut\-ki\-mus\-pro\-jek\-tiin Tunturi recumbent -kuntopyörä.
Kuntopyörästä voidaan lukea sekä pyörän nopeus että pyörää sillä
hetkellä polkevan käyttäjän syke. Nämä tiedot luetaan
sarjaporttiliitännän avulla käyttäen Tunturin määrittämää protokollaa.
Harjoitustiedon (nopeus ja syke) lukua varten oli toteutettu
ohjelmistokomponentti, joka luki harjoitustietoa kuntopyörästä ja
vastaanotti TCP -yhteyksiä. TCP -yhteyksien kautta harjoitustiedon
välitykseen määriteltiin yksinkertainen protokolla, jolla voitiin
kysellä pyörän sen hetkistä nopeutta. Harjoitustieto muutettiin tämän
jälkeen CEP -protokollan mukaiseksi tilannetiedon
tuottajakomponentissa. Tilannetiedon tuottajakomponentti vuorostaan
palveli MUPE -sovelluksia lähettämällä nykyisen nopeuden ja sykkeen
CEP -protokollan avulla.
\ac{RFID} -tunnisteiden lukua varten LTY:n tietoliikenteen laitokselle
oli hankittu useita RFID -tunnisteita (henkilökorttipohjia sekä
avaimenperätunnisteita). Tunnisteiden lukuun käytettiin RFID -lukijaa,
jossa on sarjaporttiliitäntä, jonka kautta lukija ilmoittaa havainnon
lukijan editse (muutaman senttimetrin etäisyydeltä) viedystä RFID
-tunnisteesta. Tässä havainnossa kerrotaan mm. 16 tavun mittainen RFID
-tunnisteen yksilöivä tunnistenumero. Tunnisteiden luku toteutettiin
samantyyppisesti kuin harjoitustiedon luku kuntopyörästä.
Ohjelmistokomponentin avulla tulkittiin RFID -lukijan lähettämiä
havaintoja sarjaporttiliitännän kautta. Komponentti vastaanotti myös
TCP -yhteyksiä, joihin havaintotiedot välitettiin. Toteutetun
tilannetiedon tuottajakomponentin tehtäväksi jäi muodostaa TCP -yhteys
RFID -lukijaa käsittelevään komponenttiin ja lukea saatuja RFID
-havaintotietoja muodostetusta TCP -yhteydestä. Havaintotiedot
muunnettiin edelleen CEP -protokollan atomeiksi ja välitettiin MUPE
-sovelluksille.
Paikkatiedon välitykseen MUPE -sovelluksille käytettiin kahta
järjestelmää. LIS -so\-lu\-pai\-kan\-nus\-ra\-ja\-pin\-nal\-le
toteutettiin tilannetiedon tuottaja joka hyödynsi LIS -järjestelmän
pyyntömetodeja. Tilannetiedon tuottajakomponentille määritettiin
seurattavien WLAN -päätelaitteiden laiteosoitteet. Tämän jälkeen
tilannetiedon tuottajakomponentti kyseli määrätyin väliajoin
määritettyjen päätelaitteiden sijaintia LIS -järjestelmältä. LIS
-palvelun kanssa kommunikointiin käytettiin Apache Axis
-projektin\footnote{\url{http://ws.apache.org/axis/}} \ac{SOAP}
-toteutusta. Listauksessa \textrm{3.1} on esitetty esimerkki LIS
-järjestelmän tuottamasta paikkatiedosta \ac{CEP} -protokollan
mukaiseksi \ac{XML} -viestiksi muotoiltuna. CEP -viestissä kerrotaan
laiteosoitteella \emph{00:\-08:\-02:\-F6:\-01:\-7F} määritetyn käyttäjän olevan
solusijainnissa \emph{LTY\_6609}. Lisäksi CEP -viestiin on sisällytetty
havainnon aikaleima sekä kuvaus solusijainnista.
\begin{center}
\begin{verbatim}
2005-10-04 19:15:35.081464+03
LTY_6609
LUT, TITE building, 6th floor (Comlab)
\end{verbatim}
\center{Listaus \textrm{\thechapter.1}: Solupaikkatieto CEP -protokollan XML -muodossa.}
\end{center}
Kuvassa \ref{fig:lis-tilannetieto} on esitetty viestikaavio
paikkatiedon välityksestä LIS
-so\-lu\-pai\-kan\-nus\-jär\-jes\-tel\-mä\-stä tilannetiedon tuottajan
avulla MUPE -sovellukseen. Kaaviosta nähdään tilannetiedon
tuottajakomponentin (LIS Location Context Producer) tekemä pyyntö LIS
-järjestelmään parameterineen. Myös vastaus parameterineen on
esitetty. Tilannetiedon tuottajakomponentille voitiin määrittää
väliajat, jolloin kyselyjä annettujen laitteiden sijainneista tehtiin
LIS -järjestelmään. Laitteet puolestaan määritettiin XML
-kon\-fi\-gu\-raa\-tio\-tie\-dos\-tos\-sa.
\begin{figure}[h]
\centering
\includegraphics[width=0.8\textwidth]{kuvat/lis-tilannetieto.pdf}
\caption{Paikkatiedon välitysketju LIS -järjestelmästä}
\label{fig:lis-tilannetieto}
\end{figure}
\FloatBarrier
\acf{EPE} 2.0 -järjestelmän avulla toteutettiin tarkempaa,
koordinaattipohjaista paikkatietoa tuottava tilannetiedon tuottaja.
Paikkatiedon kartoitusalustana käytettiin LTY:n tieto- ja
sähkötekniikan rakennuksen kerroksia 2-7. Tilannetiedon tuottajan
toteutuksessa käytettiin \ac{EPE}:n tarjoamaa Java \ac{RMI}
-rajapintaa. Tilannetieton tuottaja toimi client -sovelluksena
\ac{EPE} -järjestelmään. \ac{EPE} -järjestelmä tuottaa kahden sekunnin
välein uusia paikkatietohavaintoja. Näistä havainnoista kerättiin mm.
koordinaatit, kerros, todennäköisin looginen sijaintialue sekä
todennäköisyys kyseisellä loogisella alueella sijaitsemiseen. Tiedot
muokattiin CEP -atomeiksi ja päivitettiin määrätyin väliajoin MUPE
-sovelluksille. EPE -järjestelmää käyttävä tilannetiedon tuottaja
poikkesi LIS -järjestelmää käyttävästä siten, että paikkatietoa ei
erikseen pyydetty lähettämällä pyyntö vaan sitä vastaanotettiin
jatkuvana virtana.
\subsection{Tribal Exchange -peli}
Edellä kuvattuja MUPE -alustalle toteutettuja tilannetiedon
tuottajakomponentteja hyödynnettiin Tribal Exchange -peliprojektissa.
Tribal Exchange (Trix) -peli toteutettiin AMPERS -projektissa yhdessä
Lapin Yliopiston (LaY) taiteiden tiedekunnan kanssa. Osuuteni
projektissa koostui suunnittelusta sekä erinäisten osien
toteutuksesta. Tärkein toteutukseen liittyvä komponentti omalta
osaltani oli tilannetiedon tuominen Trix -peliin. Tähän käytettiin
sekä edellä kuvattuja säätiedon että solupojaisen WLAN -paikkatiedon
(LIS) tuottavia tilannetiedon tuottajakomponentteja. Peliprojektin
määrittely aloitettiin lokakuussa 2004. Määrittelyyn sisältyi mm.
osapuolien tutustuttaminen MUPE -alustaan. Suunnittelua tehtiin
marraskuun 2004 ja tammikuun 2005 välisenä aikana, jolloin suurin osa
pelin eri toiminnoista lyötiin lukkoon. Suunnittelussa käytettiin
apuna AMPERS -projektin käyttöön asennettua MoinMoin Wiki
-palvelua\footnote{\url{http://moinmoin.wikiwikiweb.de/}}, johon
kerättiin eri suunnittelupalaverien tulokset. Kevät 2005 käytettiin
pitkälti pelin prototyypin rakentamiseen. Alkukesän 2005 aikana
peliprototyyppiin lisättiin suurin osa suunnitelluista toiminnoista.
Peliprojektin testauksesta ei vielä tällä hetkellä ole täyttä
varmuutta. Ilmeisesti Lapin Yliopistolla on kuitenkin tarkoitus
käyttää prototyyppiä jatkokehittelyyn.
Pelin ideana on yhdistää sekä fyysistä peliympäristöä että pelin
virtuaalimaailmaa toisiinsa. Pelaajat jaetaan heimoihin. Pelimaailma
koostuu pelikartasta, jossa jokaisella heimolla on taloja. Yksi
taloista on päämaja ja muut ovat heimolaisten asuinrakennuksia. Pelin
ideana on suojella asuinrakennuksia erilaisilta luonnonmullistuksilta.
Suojeleminen tapahtuu rakentamalla muuria talojen ympärille. Muurin
rakennusidea on johdettu vuonna 1991 julkaistusta Rampart -pelistä.
Peli on jaettu jaksoihin, joiden aikana pelaajien tulee suojella ilman
muuria olevat rakennukset. Jaksojen päättyessä tarkistetaan ovatko
heimojen asuinrakennukset ympäröity. Jos onnistuttiin, heimo saa uuden
asuinrakennuksen pelikartalle. Mikäli olemassaolevia rakennuksia ei
ole ympäröity, poistetaan ne pelikartalta. Kuvassa \ref{fig:trix} on
esitettu ruudunkaappaus pelitilanteesta. Kuvan tilanteessa MUPE
-asiakasohjelmaa ajetaan \ac{J2ME} Wireless Toolkit MIDP -emulaattorin
avulla. MUPE -asiakasohjelma on kytkeytyneenä Trix -pelipalvelimelle
ja kuvan tilanteessa vihreän heimon päämajasta osa on ympäröity
muurilla.
\begin{figure}[h]
\centering
\includegraphics{kuvat/trix_pieni.png}
\caption{Ruutukaappaus Tribal Exchange -pelistä.}
\label{fig:trix}
\end{figure}
\FloatBarrier
Jotta muuria voisi rakentaa, pelaajat keräävät pelin peluuympäristöstä
koodeja. Koodit ovat vapaaluontoisia merkkijonoja, jotka voivat
esiintyä esimerkiksi paperilapuilla. Koodit vastaavat pelimaailmassa
hyödykkeitä; joko muurin rakennuspaloja tai käyttöesineitä, joilla
voidaan raivata pelikartalla rakennustilaa muurille. Pelimaailman
maastossa voidaan rakentaa muuria vain tasaiselle maalle. Esteinä
toimivat vesi, kivet ja metsä. Käyttöesineitä on kolmea tyyppiä.
Hakulla voidaan hakata kivet pois muurin rakennusalueelta. Sahalla
voidaan kaataa metsää pois muurin rakennusalueelta. Dynamiitilla
voidaan tuhota sekä muuria, metsää että kiveä. Jokainen käyttöesine
voidaan käyttää vain kerran.
Koodeilla saatavat muuripalat kuuluvat jollekin pelin heimoista ja
vaihtelevat muotonsa mukaan (L, Z, I, O ja C -kirjainten mukaiset
muodot) sekä rakennusaineen mukaan. Muurityyppejä ovat olki, puu, jää
tai kivi. Muurityyppien kestävyys vaihtelee heikoimmasta (olki)
vahvimpaan (kivi). Muurin omistajaheimo määritetään palan värin
mukaan. Mikäli pelaajan koodilla hankkima muuripala on hänen oman
heimonsa pala, muuttuu se pelikartalle asettamisen yhteydessä
kivimuuriksi. Mikäli muuripala on jonkin toisen heimon omistama,
muuttuu se satunnaisesti joksikin muuksi heikommaksi muurityypiksi.
Samanmuotoisia muuripaloja voidaan yhdistellä keskenään. Mikäli kaksi
samanväristä (saman vieraan heimon omistuksessa olevaa) ja
samanmuotoista palaa yhdistetään, saadaan tulokseksi yksi oman heimon
omistuksessa oleva pala. Erivärisiä paloja yhdistellessä on 50\%
todennäköisyys saada tulokseksi oman heimon pala ja 50\%
todennäköisyydellä vieraan heimon pala. Pelissä voidaan myös tehdä
vaihtokauppaa muiden pelaajien kanssa. Muurinpalojen omistussuhteiden
onkin tarkoitus edistää pelaajien välistä interaktiota, sillä väärän
heimon palan voi laittaa huutokaupassa myytäväksi ja täten hankkia
lisää oman heimon paloja. Lisäksi peli sisältää keskustelualueen
(heimokohtaisen sekä julkisen), jonka kautta pelaajat voivat viestiä
toisten pelaajien tai heimon jäsentensä kesken. Trix -pelin toiminnot
on jaettu neljään toimintamoodiin jotka on esitetty taulukossa
\ref{tab:pelimoodit}.
\begin{table}[h]
\centering
\caption{Tribal Exchange -pelin toimintamoodit}
\begin{tabularx}{\textwidth}{|l|X|}
\hline
\multicolumn{1}{|c|}{\textbf{Pelimoodi}} & \multicolumn{1}{c|}{\textbf{Kuvaus}} \\
\hline
Inventaaariomoodi &
Inventaariossa pelaajalle esitetään hänen hallussaan olevat
käyttöesineet sekä muuripalat. Inventaarioon päätyvät myös
huutokaupassa sekä koodeilla saadut esineet. Inventaariossa
ollessa voidan myös etsiä koodeja käyttäjän nykyisestä
sijainnista.\\
\hline
Rakennusmoodi &
Rakennusmoodissa pelaajat voivat tarkastella 9*9 pikselin
kokoisista ruuduista koostuvaa pelikarttaa. Päätelaitteen ruudulla
esitetään aina niin suuri osa pelikarttaa kuin mahdollista.
Inventaariosta voidaan ottaa käyttöön muuri- tai hyödyke-esineitä
ja käyttää niitä rakennusmoodissa. Muuripaloja voidaan pyöritellä
myötä/vastapäivään ja asettaa vapaalle kartta-alueelle.
Hyödykkeitä (dynamiitti, hakku, saha) käytetään valitsemalla esine
inventaariosta ja viemällä se rakennusmoodissa käytettävän ruudun
ylle. Esimerkiksi sahan käyttäminen metsää sisältävässä ruudussa johtaa metsän
poistumiseen.\\
\hline
Vaihtokaupamoodi &
Vaihtokauppamoodissa pelaajat voivat jättää vaihtokauppatarjouksia
ja vastata muiden pelaajien jättämiin tarjouksiin. Mikäli pelaaja
hyväksyy vaihtokaupan, siirretään vaihtokaupassa vaihdetut esineet
vaihtokaupan osapuolien inventaarioihin. \\
\hline
Keskustelumoodi &
Keskustelumoodissa pelaajat voivat viestiä keskenään. Keskustelu on
jaettu kahteen alueeseen, pelaajan oman heimon keskiseen ja
yleiseen keskustelualueeseen. Pelaajat voivat vapaasti jättää ja
lukea viestejä. \\
\hline
\end{tabularx}
\label{tab:pelimoodit}
\end{table}
\FloatBarrier
Pelialueella on maastoesteiden lisäksi erilaisia tapahtumia, jotka
haittaavat muurin rakentamista. Näitä ovat metsäpalot ja kulkevat mammutit.
Metsäpaloja voi syttyä satunnaisesti ja ne tuhoavat levitessään
olkimuureja. Mammutit taas liikkuvat satunnaisesti ja syövät tielleen
osuvaa olkimuuria. Mammutit toimivat myös esteinä, jolloin ne
vaikeuttavat muuripalojen asettelua.
Koodeja voidaan etsiä myös paikkatiedon perusteella. Koodeille voidaan
määrittää sijaintitieto WLPR.NET -verkossa käytetyn WLAN
-so\-lu\-pai\-kan\-nus\-jär\-jes\-tel\-män avulla. Paikkatieto tuodaan
peliin LIS -rajapinnalle toteutetun tilannetiedon tuottajan kautta.
Pelaajat voivat määrittää käyttämänsä WLAN -pää\-te\-lait\-teen
laiteosoitteen (tai vaihtoehtoisesti nimen, mikäli käytetään MUPE:n
oliotunnisteiden muunnostaulukoita) omassa pelaajaprofiilissaan. Tämän
jälkeen pelaaja voi kysellä mahdollisia koodeja omasta, sen hetkisestä
sijainnistaan. Koodeja voi olla samassa sijainnissa useita, mutta
niistä voi käyttää vain yhden kerrallaan.
Käytön jälkeen koodi merkitään käytetyksi, joten muut pelaajat eivät
voi enää hankkia hyödykkeitä tällä koodilla. Koodeja voidaan lisätä
pelin ylläpidon toimesta pelimaailmaan lisää sitä mukaan, kun niitä
käytetään. Paikkatiedon käytöllä saavutetaan se hyöty, että koodeja ei
tarvitse jaella fyysisesti erillisille lapuille ympäri peliympäristöä.
WLAN -paikkatiedon käyttö taas rajoittaa mahdollisia päätelaitteita
tai näiden yhdistelmiä\footnote{Yhdistelmällä tarkoitetaan esimerkiksi
WLAN -radion omaanvan kannettavan tietokoneen ja puhelimen
yhdistelmää. Peliä voidaan pelata puhelimella, mutta koodeja voi
etsiä WLAN -kannettavan avulla.}.
Trix -pelimaailma yhdistetään reaalimaailmaan myös säätiedon käytöllä.
Säätietoa tuodaan peliin Ilmatieteen
laitoksen\footnote{\url{http://www.fmi.fi}} palvelua käyttävän
tilannetiedon tuottajan kautta. Säähavainnoista käytetään hyväksi
kolmea parametria: lämpötila, kosteus ja tuulen nopeus. Saataessa uusi
säähavainto suoritetaan näille kolmelle eri parametrille annettujen
ehtojen täyttyessä pelimaailmaan rakennetuille muuripaloille
kestävyysmuutoksia. Kestävyysmuutokset on määritetty MUPE:n
\emph{Context Manager} -komponentin skriptien avulla (liite
\ref{liite:weatherrules}). Lämpötila vaikuttaa vain jäämuurinpaloihin,
mutta kosteusprosentti vaikuttaa sekä olkeen että puuhun ja tuuli
olkeen, puuhun ja jäähän. Näin ollen kestävin komponentti on kivi.
Eri muurityyppeihin vaikuttavat sääparametrien muutokset on esitetty
taulukossa \ref{tab:saavaikutus}. Eri muurityypeillä on ennalta
määrätty kestävyysarvo, jonka loppuessa muuri sortuu. Pelaajien tulee
paikata sortuneet palat uusilla muuripaloilla.
\begin{table}[h]
\centering
\caption{Tribal Exchange -pelin sääparametrien vaikutus muurityypeittäin}
\begin{tabularx}{\textwidth}{|l|X|}
\hline
\multicolumn{1}{|c|}{\textbf{Lämpötila (\textcelsius)}} & \multicolumn{1}{c|}{\textbf{Vaikutus}} \\
\hline
> +30 & Jää: -4 \\
\hline
+20 - +30 & Jää: -3 \\
\hline
+10 - +20 & Jää: -2 \\
\hline
0 - +10 & Jää: -1 \\
\hline
-10 - 0 & ei vaikutusta \\
\hline
-20 - -10 & Jää: +1 \\
\hline
-30 - -20 & Jää: +2 \\
\hline
< -30 & Jää: +3 \\
\hline
\multicolumn{1}{|c|}{\textbf{Kosteus (\%)}} & \multicolumn{1}{c|}{\textbf{Vaikutus}} \\
\hline
0 - 60 & ei vaikutusta \\
\hline
60 - 80 & Olki: -1 \\
\hline
80 - 100 & Olki: -2, Puu: -1 \\
\hline
\multicolumn{1}{|c|}{\textbf{Tuulen nopeus (m/s)}} & \multicolumn{1}{c|}{\textbf{Vaikutus}} \\
\hline
0 - 2 & ei vaikutusta \\
\hline
2 - 4 & Olki: -1 \\
\hline
4 - 8 & Olki: -2 \\
\hline
> 8 & Olki: -3, Puu: -1, Jää: -1 \\
\hline
\end{tabularx}
\label{tab:saavaikutus}\label{tab:verylasttable}
\end{table}
\FloatBarrier
\chapter{Arviointi}
\label{chap:arviointi}
Tässä kappaleessa esitetään arviointia ja yhteenvetoa edellisessä
luvussa kehitetyistä palveluista, välittäjäkomponenteista ja
sovelluksista. Erityisiä mittauksellisia tuloksia ei arviointia varten
tehty, vaan arviointi pyritään tekemään rakenteellisesti. Tärkeimmät
havainnot työn tuloksien osalta käydään läpi.
\section{Käyttäjän ja päätelaitteen tunnistus}
\ac{LIS} -palvelussa käyttäjät tunnistetaan käyttäjätunnuksen avulla.
Käyttäjätunnuksien avulla tietyn käyttäjän sijaintia voidaan kysellä.
Tunnisteen luominen on tarvittavaa, sillä WLAN -verkoissa ei käyttäjän
tunnistamiseksi ole olemassa yhtenäistä tapaa, kuten esimerkiksi GSM
-verkoissa puhelinnumero. Käyttäjätunnuksella pyrittiin ottamaan myös
huomioon, että paikannuspalvelun käyttäjä voi useasti olla eri henkilö
kuin itse päätelaitteen (tai esim. GSM -liittymän) omistaja.
Käyttäjän identifiointi \ac{LIS} -palvelussa tunnuksen perusteella luo
tarpeen, että käyttäjän tunnusta tulee käyttää myös paikkatietoisessa
palvelussa, jotta käyttäjä voidaan identifioida. Käyttäjän
identifiointi voisi myös itsessään olla palvelu, jota LIS:n kaltainen
paikkatietorajapinta voisi tarjota. Tämä huomattiin Floating Note
-palvelua rakennettaessa, jolloin käytettiin myös käyttäjäprofiileja.
Tämä johti tilanteeseen, jossa käyttäjällä oli identiteetti sekä Floating
Note, että LIS -palvelussa. LIS -palvelun käyttäjätunnus
tallennettiin osaksi Floating Note -palvelun käyttäjäprofiilia.
Pelkästään LIS -palvelun käyttäjäidentiteetin käyttäminen olisi tässä
tilanteessa ollut järkevää, sillä paikkatietokyselyjä tehdään
kuitenkin kyseisen käyttäjän identiteetillä. Nyt käyttäjät joutuivat
luomaan ensin identiteetin LIS -palveluun ja vielä erillisen
identiteetin Floating Note -palveluun, jonka profiiliin LIS
-käyttäjätunnus tallennettiin.
LIS -palveluun rekisteröityneet käyttäjät koostuvat paikkatiedon
käyttöään hallitsevista käyttäjistä. Paikkatietoiset sovellukset
voisivat tunnistaa käyttäjiä myös LIS -palvelun käyttäjätunnuksien
perusteella. Käyttätunnus voitaisiin varmistaa vaikkapa LIS -palveluun
liitetyn RADIUS -autentikointipalvelun avulla.
Myös MUPE -sovelluksissa jouduttiin miettimään miten käyttäjä ja
käyttäjän päätelaite yhdistetään toisiinsa. Mikäli paikan
määrityksessä käytetään LIS -palvelun käyttäjätunnuksia, voitaisiin
samaa käyttäjätunnusta käyttää myös MUPE -sovelluksissa suoraan. Nyt
kuitenkin toteutuksissa päädyttiin erillisiin käyttäjätileihin sekä
MUPE että Floating Note -sovelluksissa. Molempien käyttäjätiliin
määriteltiin joko käyttäjän LIS -tunnus tai päätelaitteen MAC -osoite.
Käyttäjähallinta tulisi ottaa huomioon aina käsiteltäessä
henkilökohtaisia tietoja.
%LIS -palvelussa olevan käyttäjän
%identiteetin hyödyntäminen voitaisiin tehdä esimerkiksi RADIUS
%-palvelulla. Tällöin käyttäjän identiteettinä toimivaan
%käyttäjätunnukseen voidaan paikkatietoisessa palvelussa yhdistää
%profiilitietoja. Käyttäjän autentikointi toimisi vahvistamalla RADIUS
%-palvelun avulla käyttäjän oikeellisuus. RADIUS -autentikointia
%käytetään jo monessa palvelussa (esimerkiksi FIXME! FUNET ROAMING tai
%joku muu tms.), joten se on todettu toimivaksi järjestelmäksi ja
%RADIUS -protokollan toteuttavia ohjelmistokirjastoja on vapaasti
%käytettävissä.
% myös mupe -sovelluksissa jouduttiin miettimään miten käyttäjä ja
% laite yhdistetään toisiinsa. mupe -sovelluksissa tämä tehtiin
% sanomalla sovellukselle mikä käyttäjän laite oli. Mutta vastaava
% toiminto oli tehty jo LIS -järjestelmään! Tästä kannattaisi
% kirjoittaa, käyttäjän ja laitteen yhdistäminen on yleinen
% sovelluskohtainen ongelma.
\section{Paikkatietohavaintojen käyttö}
\ac{LIS} -paikkatietopalvelun ongelmaksi havaittiin paikkatietomallin
puute. Soluhavaintojen kytkeminen varsinaiseen sijaintiin tulisi tehdä
käyttämällä paikkatietomalleja, joita esiteltiin kappaleessa
\ref{sec:paikkatieto}. Toteutetussa palvelussa paikkatietomäärittelyjä
lisättiin kuitenkin vasta jälkeenpäin (esimerkiksi koordinaattien
yhdistäminen solusijainteihin). Rakennetuissa esimerkkisovelluksissa
oli siten vaikea yhdistää soluhavaintoja varsinaiseen paikkatietoon.
Puutteeksi koettiin myös soluhavaintojen erottelu. Esimerkiksi
tilanteessa, jossa kaksi WLAN -tukiasemaa ovat lähekkäin samalla
alueella (esimerkiksi silloin kun hetkellisesti halutaan kasvattaa
verkon kapasiteettia, vaikkapa tapahtuman yhteydessä jolloin WLAN
-verkolla on paljon käyttäjiä), voidaan käyttäjän paikasta saada kaksi
soluhavaintoa, jotka pitäisi yhdistää samaan paikkaan. Nyt kuitenkin
nämä soluhavainnot välitetään suoraan sovellukselle, joka voi tulkita
havaintoja erillisinä sijainteina. Esimerkiksi Floating Note
-järjestelmässä nämä havainnot loisivat kaksi erillistä, samalla
alueella olevaa, keskustelualuetta, mikä ei ole toivottua.
Paikkatiedon käyttö sovelluksissa tulisikin mieluiten perustua
paikkatietomalliin eikä pelkästään tiettyyn sovelluskohtaiseen
lähteeseen, koska sovelluskohtaisen havainnointitieto saattaa tuoda
esiin odottamattomia ongelmia. Paikkatietomalli taas määrittää
kehyksen, jossa sovellus voi toimia.
\ac{LIS} -järjestelmän testiluontoisuuden vuoksi käytettiin pelkästään
LIS:n pyyntömetodeja paikkatiedon välittäjäkomponenteissa MUPE
-ympäristön yhteydessä. Ilmoitusmetodit oltiin alunperin luotu
seurantasovellusten käyttöön, mutta näitä sovelluksia ei oltu
kehitetty WLPR.NET -projektin puitteissa, joten ilmoitusmetodien
kehitystä ei jatkettu. Ilmoitusmetodien nykyisessä toteutuksessa
PostgreSQL -tietokannasta käsin laukaistava \ac{SOAP} -ilmoituksen
lähetys hidastaa myös itse tietokannan toimintaa. Liitteessä
\ref{liite:plperl} esitetty välittäjäskripti laukaisee LIS -palvelussa
\ac{HTTP} -pyynnön ilmoituksen lopulliselle kohteelle. Vasta saataessa
\ac{HTTP} -pyyntöön vastaus jatkuu LIS -palvelun, sekä myös
välittäjäskriptin suoritus. Tämä aiheuttaa hidastumista myös
tietokannan toiminnalle. Toimintaa olisikin pitänyt parantaa
jonotusjärjestelmällä, jossa LIS -palvelu vain vastaanottaisi
ilmoituspyynnön ja sallisi PostgreSQL -tietokannassa olevan
välittäjäskriptin nopean paluun. LIS -palvelussa taas huolehdittaisiin
esimerkiksi tilanteista, jossa ilmoituksen kohde ei olekaan
saatavissa.
Pelkkien pyyntömetodien käyttö aiheutti enemmän liikennettä LIS
-palvelimelle kuin olisi ollut tarpeellista, sillä paikkahavaintoja
pyydettiin lyhyin (esimerkiksi viisi sekuntia) väliajoin. Toisaalta
kuormitus painottui enemmänkin itse tilannetiedon
välittäjäkomponenttiin, joka toimi palvelimena \ac{MUPE}
-sovelluksille. Näin tapahtui etenkin opetuskäytössä CodeCamp
-tapahtumissa, jossa yhtäaikaisesti välityskomponenttia saattoi
käyttää 5-10 \ac{MUPE} sovellusta.
\section{MUPE:n rajoitukset}
Vaikka \ac{MUPE} ympäristö on tarkoitettu sovelluskehitykseen
mobiileilla päätelaitteilla, on ympäristön toteutuksessa kuitenkin
seikkoja, jotka heikentävät \ac{MUPE}:n käyttöä mobiilissa
ympäristössä. Käyttöliittymien rakentamiseen tarkoitettu \ac{XML}
-skriptikieli johtaa monimutkaisemmilla käyttöliittymillä suurehkojen
\ac{XML} -dokumenttien muodostamiseen. Suuret XML -dokumentit ovat
hitaita siirtää esimerkiksi \ac{GPRS} -yhteyden yli. XML -dokumenttien
kokoa on kuitenkin pyritty pakkauksella pienentämään myöhemmissä MUPE
-alustan versioissa.
Lisäksi skriptikieli on osittain suppea toiminnallisuuksiltaan.
Esimerkiksi aritmeettisissa lausekkeissa ei ole automaattisia
muuttujia vaan välitulokset joudutaan tallentamaan erillisiin XML
-elementtien attribuutteihin. Tämä hidastaa sovelluskehitystä.
Skriptikielen opettelu vie myös aikaa, sillä XML -pohjaisen
scriptikielen toimintalogiikka poikkeaa perinteisistä
funktionaalisista ohjelmointikielistä. Tällä on kuitenkin hyvätkin
puolensa. Esimerkiksi toiminnallisuuksien perintä elementtien kesken
on helposti toteutettavissa. Eräs kehitystä hidastava tekijä oli myös
skriptikielen dokumentaatio, joka tämän diplomityöprojektin aikana oli
vaihtelevaa. Kaikkia toiminnallisuuksia ei oltu dokumentoitu. Lisäksi
alusta oli jatkuvasti kehityksen alla, joten erilaisia virheitä
huomattiin runsaasti. Kuitenkin on todettava, että alustalla tehtyjen
ohjelmistojen vaativuus alustaa kohtaa ei ollut aluksi tiedossa.
Alustan rajat tulivat siis vastaan esimerkiksi nopeatempoisten
sovellusten kehityksessä
MUPE -alustan jakelu tehtiin aluksi sekä asiakas- että
palvelinohjelmiston yksittäisinä pakettijulkaisuina. Myöhemmin
palvelin jaettiin kahteen kirjastoon, core ja content -osuuksiin. Core
-kirjasto sisälsi MUPE:n väliohjelmisto -toiminnallisuuden, eli
kommunikointimetodit palvelimen eri osien välillä. Content -osa
sisälsi alkuperäisen jakelun toteuttaman yksinkertaisen \ac{MUD}
-tyyppisen pelimaailman. Asiakasohjelma jaettiin \ac{MIDP} -alustan
mukaisiin versioihin, MIDP1 ja MIDP2 -paketeiksi. \ac{MUD}
-pelimaailman sisällyttämisen tarkoitus oli nopeuttaa palvelujen
kehitystä, sillä se sisälsi joitakin yleiskäyttöisiä
toiminnallisuuksia, kuten pelaajahahmon ja pelimaailman huoneiden
luonnin. Tämä saattoi antaa käsityksen, että MUPE -alusta oli sovelias
vain MUD -pelien rakentamiseen, vaikka näin ei ollut. Kuitenkin
MUPE -jakelusta puuttui yleisiä, monen pelaajan peleissä tärkeitä
käyttäjien hallinnointityökaluja. Tälläisiä olisi ollut pelaajien
listaaminen ja poistaminen ylläpidon toimesta.
\section{Code Camp -tapahtumat}
Code Camp -tapahtumat ovat LTY:n tietoliikenteen laitoksen käyttämä
opetusmetodi, jossa pyritään intensiivisellä ja tehokkaalla
ajankäytöllä opettamaan ja perehdyttämään opiskelijat kulloinkin
valittuun ohjelmistokehitysalustaaan. MUPE -alustaa käytettiin hyväksi
kahdessa Code Camp -tyyppisessä tapahtumassa. Näistä ensimmäinen
järjestettiin elokuussa 2004, \ac{WAWC04} -konferenssin yhteydessä. Tällöin
käytetiin hyväksi sekä Ekahau- että LIS -järjestelmistä paikkatietoa
tuottavia tilannetiedon tuottajakomponentteja. WAWC04 -tapahtumassa
toteutettiin 24 tunnin aikana paikkatietoisia sovelluksia. Tämän
tapahtuman järjestelyjä, kehitettyjä sovelluksia ja niiden arviointia
on käyty läpi tarkemmin julkaisussa Rapid Prototyping of
Location-Based Games with the Multi-User publishing Environment
Application Platform \cite{rapid}. Tilannetiedon tuottajia käytettiin
myös tammikuussa 2005 järjestetyllä sovelluskehityksen
erikoiskurssilla. Kurssi pidettiin viikon intensiivikurssina, jonka
aikana opiskelijat tutustuivat pelisuunnitteluun sekä tilannetiedon
käyttöön pelisovelluksissa. Kurssia varten kehitettiin tilannetiedon
tuottajat Tunturin recumbent -kuntopyörälle sekä RFID -lukijalle että
ilmatieteen laitoksen sääpalvelulle.
Tapahtumien avulla, etenkin WAWC'04:n yhteydessä, pyrittiin testaamaan
MUPE -alustaa sovelluskehitysympäristönä, joka mahdollistaisi
tilannetietoisten sovellusten nopean luomisen. Tapahtuman aikana noin
20 hengen osanottajajoukko, jaettuna viiteen ryhmään, loi viisi
sovellusta, jotka käyttivät erityisesti Ekahau -järjestelmän tuottamaa
paikkatietoa. Tapahtuman aikana toimin ylläpitäjänä tilannetiedon
välittäjäkomponenteille sekä avustin ja neuvoin ryhmiä \ac{MUPE}
-sovelluskehityksessä. Tapahtuman jälkeen ryhmiä haastateltiin
vapaaluontoisesti \ac{MUPE} -alustan käytöstä.
Ryhmien mielestä paikkatiedon käyttö \ac{MUPE} -alustalla oli helppoa,
sillä paikkatieto oli pitkälle jalostettu \ac{MUPE} -alustan avulla
(tieto oli käsiteltävissä Java -objektina). Vaikkakin toimivia
sovelluksia pystyttiin kehittämään 24 tunnin aikana, suurimmaksi
ongelmaksi havaittiin uuden alustan opettelu. Etenkin käyttöliittymien
luonti XML -skripteillä oli aluksi hidasta. XML -skripteillä luotujen
käyttöliittymien toiminnallisuuksien testaukseen ei ollut vielä
erillisiä työkaluja. Tämä taas hidasti virheiden havainnointia ja
siten kehitystä. MUPE -alustan sovellusmahdollisuudet olivat myös
vielä osittain rajoittuneita. Esimerkiksi käyttäjän ruudun tilanteen
päivitys vaati jatkuvaa muutosten kyselyä \ac{MUPE} -palvelimelta,
jolloin nopeita yksittäisiä päivityksiä pystyttiin tekemään vain
ruudun päivityskyselyiden lähetysaikavälien tarkkuudella. Tämä johtui
asiaskasohjelmistojen yhteyksiin käytetystä tilattomasta HTTP
-protokollasta, jolloin asiakasohjelmistolle ei voitu tehdä suoria
päivityksiä. Ongelma kuitenkin korjaatui myöhemmissä MUPE -alustan
versioissa HTTP -yhteyksien rinnalle rakennetulla yhteyden tilan
säilyttävällä TCP/IP -protokollalla. Kyseinen parannus on saatavilla
asiaskasohjelmiston \ac{MIDP} 2 -versiossa.
% arviointiin tai johtopäätöksiin
%Työn käytännön osuus on toteutettu melko laajalla aikavälillä. Vuoden
%2003 kesällä toteutettiin ensimmäinen versio \ac{WLAN}
%-paikkatietorajapinnasta (\ac{LIS}). Samalla toimin ohjaajana
%erikoistyölle, jossa luotiin \ac{LIS} -paikkatietorajapintaa
%hyödyntävä viestintäsovellus (Floating Note). Vuoden 2004 kesällä
%\ac{LIS} -paikkatietojärjestelmää käytettiin tuottamaan paikkatietoa
%\ac{MUPE} -sovellusalustan käyttöön. Samalla toteutettiin MUPE
%-alustalle myös Ekahau -paikkatietojärjestelmästä paikkatietoa
%tuottava komponentti. \ac{MUPE} -alustaa ja siihen toteutettuja
%paikkatietokomponentteja käytettiin myöhemmin sekä 2004 elokuussa
%järjestetyn \ac{WAWC04} -konferenssin yhteydessä että vuoden 2005
%tammikuussa järjestetyn Sovelluskehityksen erikoiskurssin yhteydessä.
%Sovelluskehityksen erikoiskurssia varten MUPE -sovellusalustan
%käyttöön toteutettiin useammasta lähteestä tilannetietoa tuottavia
%komponentteja. Lähteinä toimivat sää-, kuntopyörästä saatu
%harjoitustieto sekä \ac{RFID} -tunnistetieto.
\chapter{Johtopäätökset}
Tässä diplomityössä käsiteltiin paikka- ja tilannetiedon hyödyntämistä
sovelluksissa. Työssä perehdyttiin sekä paikkatiedon määrittelyyn,
paikannusjärjestelmiin ja paikkatiedon hyödyntämistä tukeviin
ohjelmistorajapintoihin. Työssä perehdyttiin myös tilannetiedon
määrittelyyn sekä tilannetietoa käsitteleviin järjestelmiin. Työssä
oli tavoitteena rakentaa erilaisia paikka- ja tilannetietoisten
sovellusten kehitystä tukevia järjestelmiä, sekä tuottaa näiden avulla
sovelluksia.
Työn tuloksena toteutettiin WLPR.NET -projektin parissa
solupaikannuspalveluun palvelurajapinta (Location Information Service,
LIS). Palvelurajapinnasta esitettiin julkaisu (\cite{lis})
Euromedia'2005 konferenssissa. Palvelurajapintaa hyödyntämään
toteutettiin erikoistyönä paikkatietoinen viestintäsovellus, josta
esitettiin myös julkaisu (\cite{Multaharju04floatingnote}) \ac{WAWC04}
konferensissa.
WLPR.NET -verkkoa hyödynnettiin myös Ekahau EPE (Ekahau Positioning
Engine) -sovelluksen avulla paikkatiedon tuottamisessa.
Sovelluskehitysalustana toimi \acf{MUPE} -alusta, johon toteutettiin
sekä LIS, että Ekahau EPE -järjestelmistä paikkatietoa tuottavat
komponentit. Näitä komponenttejä käytettiin \ac{WAWC04} konferenssin
yhteydessä järjestetyssä CodeCamp -tapahtumassa. WAWC04:n CodeCamp
-tapahtuman tuloksista esitettiin julkaisu (\cite{rapid}) \ac{IE05}
konferensissa. MUPE -alustalle toteutettiin myös laajemmin määriteltyä
tilannetietoa (säätieto, kuntopyörästä saatu harjoitustieto sekä RFID
-tun\-nis\-te\-tie\-to) tuottavia komponentteja. Näitä tilannetiedon
tuottajakomponentteja käytettiin MUPE -sovellus\-kehityksessä AMPERS
-projektin parissa ja LTY:n tietoliikennetekniikan laitoksen
Sovelluskehityksen erikoistyökurssilla opetuksessa. AMPERS -projektin
parissa toteutettiin myös edellämainittuja tilannetiedon
tuottajakomponentteja (sää- ja LIS -solupaikkatieto) hyödyntävä
tilannetietoinen pelisovellus.
Paikkatietoisten sovellusten kehitykseen tehdään jatkuvasti
standardointityötä sekä erilaisia työkaluja. Onkin nähtävissä, että
paikkatietoisten sovellusten kehitys hyötyy tästä työstä. Paikkatiedon
saatavuus kuitenkin vaihtelee paikannusjärjestelmän käytön mukaan.
Paikkatiedon tuottamiseen, hallintaan ja käsittelyyn tarvitaan monia
eri järjestelmiä, jotka ottavat myös yksityisyyden suojan huomioon.
Paikkatietoisten palvelujen kehittäminen esimerkiksi WLAN -verkkoihin
voidaan tämän työn perusteella todeta olevan suuritöinen projekti,
etenkin jos hallittavana on kokonainen sovellusketju paikkatiedon
keruusta, hallinnoinnista, välittämisestä ja hyödyntämisestä
sovelluksissa. Paikkatietorajapinnoissa todettiin kuitenkin \ac{WSDL}
-kuvausten ja \ac{SOAP} -protokollan käytön olevan toimiva ratkaisu
joka mahdollistaa sovellusten kehitysten usealla eri alustalla.
Valmiit tuotteet, kuten Ekahau, tarjoavat kuitekin paljon
jalostetumpaa ja tarkempaa paikkatietoa.
Tilannetietoisten sovellusten kehittäminen ei ole vielä laajalti
yleistynyttä. Tällaiset sovellukset käsittelevät usein monista eri
tietolähteistä kerättyä tietoa, joka liittyy sovelluksen
käyttötilanteeseen. Tilannetietoisten sovellusten kehittäminen olisi
myös suuritöistä ilman kehitystä tukevia ympäristöjä, kuten \ac{MUPE}.
Tilannetiedon välittäminen \ac{MUPE} -ympäristöön on alustan
ulkopuolinen toiminto, joka tapahtuu muuntamalla tieto \ac{CEP}
-protokollan muotoon. \ac{MUPE} -alustalle tilannetiedon tuomisessa
ovatkin tilannetiedon tuottajakomponentit tärkeässä asemassa.
Tilannetiedon simulointi muodostuu tärkeäksi asiaksi tilannetietoisten
sovellusten kehityksessä. Tilannetietoisia sovelluksia pitäisi pyrkiä
testaamaan lopullisessa ympäristössä, jotta voitaisiin tehdä
johtopäätöksiä sovelluksen toimivuudesta aidoilla päätelaitteilla ja
aidoissa käyttötilanteissa. Testiympäristön järjestely on kuitenkin
vaikeaa etenkin, jos sovelluksessa käytetään monia tiettyyn paikkaan
sitovia tilannetietoisia elementtejä. Esimerkiksi paikkatiedon
saatavuutta rajoittaa käytetyn paikannusjärjestelmän kattavuus.
Tällöin alustat kuten \ac{MUPE} tulevat tärkeiksi sovelluskehityksen
kannalta.
Ilman tilannetietoista sovelluskehitystä tukevia järjestelmiä olisi
tämäntyyppisten sovellusten kehittäminen huomattavasti vaikeampaa.
Monen eri tilannetiedon lähteen (esimerkiksi paikka, säätila,
mahdolliset tunnistejärjestelmät kuten RFID) yhtäaikainen hallinta
yhdessä sovelluksessa kasvattaisi sovelluksen kokoa huomattavasti.
Välittäjäalustoilla kuten \ac{MUPE} saadaan ohjelmistokehitystä
keskitettyä itse sovelluksen päätoimintoihin. Kuitenkin on todettava,
että sovelluskehitystä helpotettaessa myös helposti rajataan
toimintaympäristöä liian suppeaksi. Parhaimmillaan erilaiset
tilannetietoista sovelluskehitystä avustavat työkalut ovat itsenäisiä
komponentteja joita voitaisiin helposti lisätä mahdollisesti jo
olemassaoleviin sovelluksiin.
%\nocite{*} % näytetään kaikki lähdeviitteet vaikka niihin ei olisi viitattu
\bibliography{di} % lähdeviitteet
\addcontentsline{toc}{chapter}{Lähteet} % Otsikko sisällysluetteloon
\bibliographystyle{is-unsrt} % ISSN ja ISBN -numerot sisältävä viittaustyyli
% lähteet lajiteltu viittausesiintymän mukaisesti
% liitteet
\appendix
\addcontentsline{toc}{chapter}{Liitteet}
\renewcommand{\thechapter}{\arabic{chapter}} % diplomityöohjeen mukaisesti arabialainen numerointi
\chapter{PL/pgSQL trigger -funktio}
\label{liite:plpgsql}
\small{\verbatiminput{liitteet/loc_tgfunc.plpgsql}}
\chapter{PL/Perl välitysfunktio}
\label{liite:plperl}
\small{\verbatiminput{liitteet/lis_trigger_perl.pl}}
\chapter{MUPE Context Script säätiedolle}
\label{liite:weatherrules}
\small{\verbatiminput{liitteet/WeatherRules.xml}}
\chapter{MUPE Context Script LIS -järjestelmän solupaikkatiedolle}
\label{liite:lislocationrules}
\small{\verbatiminput{liitteet/LISLocationRules.xml}}
%\chapter{Location Information System WSDL -rajapintadokumentti}
%\tiny{\verbatiminput{interface.wsdl}}
\end{document}
% Muistiinpanoja
%
% - huom. vladkin maininta seppäsen antin paikannuspalvelun hitaudesta
% - LIS tarkoitettu demokäyttöön, ei laajasti hyödynnettäväksi
% - muutoin Perl -toteutus olisi parempi korvata tehokkaammalla järjestelmällä
% - missä MUPE tulisi esitellä?
%