relynokia

LeveragingGISTechnologiesforWeb-BasedSmartPlacesServicesCristianodiFloraandChristianPrehoferOceoftheCTO,Nokia,Finland{cristiano.
di-flora,christian.
prehofer}@nokia.
comhttp://www.
nokia.
comAbstract.
ThispaperdescribesourexperiencesandlessonslearntinbuildingaGeographicInformationSystem(GIS)specicallydesignedforindoorlocation-basedserviceswithinoursmartplacesinfrastructure.
Theproposedsystemwasbuiltbymashing-upcommodityOpenSourcesoft-wareandnovelresearchprototypesrealizedwithinourlabs.
TheoverallapproachreliesonintenseusageofstandardwebtechnologiesandREpre-sentationalStateTransfer(REST)APIsasawayofenablingeasymashupofo-the-shelfandproprietarycomponents.
Thekeydesignandimple-mentationaspectsofoursolutionaredescribedindetail,includingadis-cussiononhowwerepresentedandaugmentedtheconceptofindoorlocationwithinourservices.
Further,weshowhowweintegratedthemwithcommodityGISservicesoriginallydesignedforoutdoorscenarios.
Keywords:Indoor,GIS,SmartSpaces.
1IntroductionAsmartspaceisamulti-user,multi-device,dynamicinteractionenvironmentthatenhancesaphysicalspacebyvirtualservices[3].
Theseservicesenabletheparticipantstointeractwitheachotheraswellaswithotherobjectsinthesmartspace.
Indoorsmartspacesareofparticularinterestinthiscontextbecausepeoplespendmostoftheirtimeindoorratherthanoutdoor,whichinturnmakesthepotentialimpactofindoorLocation-BasedServices(LBS)muchbiggerthanthatofoutdoorLBS.
TherehasbeenconsiderableresearchandcommercialsuccessonoutdoorGPS-basedLBS,whichmotivatedustofocusonservicesforindoorsmartplaces.
ThispaperdescribesourexperiencesandlessonslearntinbuildingaGeographicInformationSystem(GIS)specicallydesignedforindoorlocation-basedserviceswithinoursmartplacesinfrastructure.
Whilemanyresearchprototypesarebuiltfromscratch,ourfocushereistounderstandhowexistingGIStechnologiescanbeusedforourmobile,indoorsolution.
Inthisway,weaimbothtoextendthescopeofGISsystemsandtousethemasstandardsforindoorsmartplaceappli-cations.
Theproposedsystemwasbuiltbymashing-upcommodityOpenSourcesoftwareandnovelresearchprototypesrealizedwithinourlabs.
Theoverallap-proachreliesonintenseusageofstandardwebtechnologiesandREpresentationalU.
Brinkschulte,T.
Givargis,andS.
Russo(Eds.
):SEUS2008,LNCS5287,pp.
256–267,2008.
cIFIPInternationalFederationforInformationProcessing2008LeveragingGISTechnologiesforWeb-BasedSmartPlacesServices257StateTransfer(REST)APIsasawayofenablingeasymashupofo-the-shelfandproprietarycomponents.
Thepaperisorganizedasfollows.
Section2discussestherationalebehindourworkandrelatedresearch.
ThekeydesignandimplementationaspectsofoursolutionaredescribedindetailinSections3and4,respectively,includingadiscussiononhowwerepresentedandaugmentedtheconceptofindoorlocationwithinourservices,aswellasonhowweintegratedthemwithcommodityGISservicesoriginallydesignedforoutdoorscenarios.
Section5concludesthepaperbyoutliningthemainlessonslearntandfutureresearchdirections.
2MotivationandBackgroundThereisconsiderableresearchonubiquitousandpervasivecomputing,alsore-centlyfocusingmoreoninternetofthingsorambientcomputing.
Manyresearchprojectshavedevelopedandtrialedubiquitousservices.
Also,severalprojectshavedevelopedsoftwareplatformsandframeworksforthispurpose.
Thereisextensiveliteratureonthis,forinstance[4]surveys29approachesupto2004.
Thissurveycoversmanysystemsfordistributedmobilecomputingandmostofthemconsiderlocationinformation,eventhoughpositioningtechnologywasnotwidelyspreadatthistime.
Thereisalsomorerecentworkonindoorpositioningservices,suchas[5,13],andalsoonsymboliclocationmodels,goingbeyondplaincoordinates[6].
GPSbasedLBShavebeenwidelysuccessfulandhavecreatedanenormousecosystemofapplicationsusingsuchservices.
Itcouldevenbearguedthattheeasyaccessofweb-basedmaptoolshasfueledtheintegrationofapplicationsbyusingthemashupapproach.
Forinstance,itisnowverycommonforweb-basedservicestoshowgeo-taggeditemsonamapapplication.
Theseinteractiveandintegratedweb-basedapplicationshavegainedenormousmomentumandarealsolabeledWeb2.
0technologies.
Web2.
0basicallymeansthatWeb-sitesareinteractive,thatusersareactuallycreatingcontent,andthatthecontentandapplicationscanbecombinedbyapplicationmashupandtaggingofcontent.
Thisissuehasbeennotedandresearchonusergeneratedcontentforubiq-uitoussystemshasbeendeveloped,e.
g.
in[7],focusingonannotatingandusergeneratedcontent.
Wethinkthatthereareanumberofmoreessentialresearchissuestowardsawidespreadeco-systemofindoorpositioningservices.
Inourview,thekeyissuesforthewidespreadusageofindoorpositioningservicesareasfollows:–establishingcommonstandardsandpracticesforindoorpositioningandmapserviceswhichareinteroperableandeasilyavailable;–integratingindoorpositioningservicesintoexistingweb-basedservices;–enablingmobile,contextawareapplicationswhichareeasytodeployanduse;–ensuringprivacyandsecurityregardingpersonaldatasuchaslocationin-formation.
258C.
diFloraandC.
PrehoferRegardingtherstitem,weseeseveralmissingpieces.
First,indoormapsarecurrentlynotwidelyavailableinwell-knownstandardformats,protocols,andpositioninginfrastructures.
WhileGPSisnowadayswidelyavailableoutdoors,thereisnosuchestablishedanddeployedindoorpositioningtechnology.
More-over,mostofthemneeddedicateddevice-sideorinfrastructure-sidehardware.
Indoorpositioninghasbeenusingverydierenttechnologiessuchasbluetooth,RFIDorWLANbased.
Evenfurther,therearenoestablishedstandardsforhandlingmapsandgeo-spatialdata,whereassuchstandardsareavailableforoutdoorLBS[12].
OurapproachhereistobuildonWLANbasedpositioning,whichweseeasawidelyavailabletechnologyandfurtherusesuchopenstan-dardsforgeospacialinformationsystemsforindoorsettings.
Regardingthesecondissueabove,integratingwithexistingservicesisamust,assuchservicesnotonlyprovideconsiderabletechnologybutalsotoolkitsandsubstantialamountofalreadyavailablegeospatialdataas,forexample,inout-doormapsapplications.
Thismayalsoincludepersonaldata,suchasprivatecontactsorpictures.
Wealsoobserveherethatmostoftheseapplicationmashupsusetechnologieswhicharesimpleandintegrateeasilyintowebapplications,suchasREpresentationalStateTransfer(REST)APIsandRSSfeeds.
Anotherproblemisthatdeployingmobileservicesisdicult,asthereisalargevarietyofdevicesanddierentoperatingsystems(indierentversion)onthemarket.
Furthermore,thesedevicescanbequitedierentintermsofresourceslikememoryandconnectivity.
Thisproblemhashamperedthede-ploymentofmobileservicesingeneral,anditismoresevereinourcaseaswealsowanttointegratepositioninginformationwithothercontextdata.
Wearefocusingonwebbasedapplicationsastheyareeasytoaccess,todeploy,andtomanage.
However,theydonothaveaccesstolocalcontextdataoftheuser.
Dierentoptionscanbechoseninthiscontext,basedondownloadableclientsoftwareforcontextcollectionaswellalsousingupcomingstandardsforbrowser-basedaccesstocontextdatasuchastheW3CDeliveryContextClientInterface(DCCI)initiative[16].
Wefocusinthispaperontheabovechallenges.
Insummary,weshowhowtouseGISsolutionsforindoorsettingsandshowhowthewebcanbeusedasaplatformfortheseservices.
Thiscoversconnectingtoservicesinotherwebbasedapplications.
Wealsodiscusshowtointegratecontextinformationintoourservice.
Asimilararchitectureformobiledevicesispresentedin[1],wherethelocationcontextdataissentseparatelytoaserver,whiletheserviceishostedfromawebserverwhichobtainsthecontextdatafromthisserver.
Thispaperfocusesonvisibilitymodelsanddoesnotcoverindoorpositioningaspectsasdonehere.
OtherworksonapplyingmobileGISsolutionsareforinstance[8],whichfocusesontourguideapplications.
[5]focusesonindoorGISformobiledevices,butdoesnotaddressapplicationmashupandplatformaspectsnorinteractiveJavaScriptfrontendsaswedohere.
Anotherchallenge,whichiscloselytiedwiththeaboveones,istoconnectwith(other)applicationsandenableapplicationmashupswhilepreservingprivacy.
TheissueisthatubiquitouscontextinformationistypicallyprivacysensitiveLeveragingGISTechnologiesforWeb-BasedSmartPlacesServices259andexistingapplicationmashuptechniquesdonotsupportthissuciently.
Wedonotcoverinfulldetailmoresecurewaysforapplicationmashup.
Here,weseeafewkeyingredientsemerging,suchasOpenIDandOpenAuth[19],whichrelyonnovelandmoreexible,decentralizedapproachestoauthenticationandauthorizationandthuscanprovideamashup-friendlysecurityinfrastructure.
3TheProposedWeb-BasedIndoorGIS3.
1TheWebasaPlatformforSmartPlacesBeforediscussinghowwedesignedandimplementedourindoorGIS,itisworthsheddingsomelightonthearchitectureoftheoverallwebbasedsmartspacesplatformthattheGISispartof.
Adetaileddiscussionofthisarchitecturegoesbeyondthescopeofthisarticle.
Theinterestedreadermayreferto[11]forfurtherdetailsaboutit.
Inthissub-sectionwewillfocusonthekeydesigndecisionsunderlyingthisarchitecture,andontheireectsandimplicationsontheproposedGISsolution.
Comparedtorelatedworkinthisarea,thedecisionsthatcharacterizeourapproachareasfollows:HTTP-basedcommunication:HTTPandwebservicesareusedasthepri-marymeansforintegratingsoftwareacrossdevicesinthesmartspace,simi-larlytowhatcurrentlyhappensontheInternet,whereHTTPformsthecrossplatformgluethatallowsmashupsacrosssuchanextremelyheterogeneousnetworkinfrastructureliketheInternet.
Reuseofexistingwebtechnology:akeyproblemwithexistingsolutionsintheubiquitousandpervasivecomputingresearchcommunityisthattheyarerarelyreusable.
Byrelyingonexistingwebtechnology,theinfrastructureopensuptoalargenumberofdevicesalreadyavailableinthecurrentmarket.
Multipleruntimesforapplicationexecution:Highendmobiledevicesarenowoeringamuchwiderrangeofruntimesforimplementingandrunningapplicationsandservices,includingtraditionalJavaandC++runtimesaswellassupportforPythonandotherscriptinglanguages.
Inthisway,plat-formdeveloperscanuseseveralruntimes.
Thismeansthatmanyexistingcomponentsusedonthewebcanbeusedinasmartspacecontextaswell.
Moreover,havingthebasiclocationenablersavailablethroughHTTPbasedcommunication,makesitpossibleandeasytomashuplocal(bothsituatedandondevice)andremotelocation-basedwebservicesalltogether.
Thesystemisorganizedinmultiplelayers,whicharedepictedinFigure1andbrieydescribedinthefollowing.
Itisworthnotingthat,asfarasindoorGIScomponentsareconcerned,inthissub-sectionwewillonlydescribetheirveryhigh-levelrolewithintheoverallSmartPlacesplatformpicture.
PleaserefertoSection4.
2forfurtherdetailsabouthowwedesignedtheGIScomponentsandwhatcommoditycomponentsweincludedinthem.
TheBasePlatform&Communicationlayercontainsseveralcommoditycommercialand/oropensourcecomponentsthatweseeasnecessarytorealizea260C.
diFloraandC.
PrehoferFig.
1.
Bird'seyeviewofourSmartPlacesplatform,includingserver-side(leftside)andclient-side(rightside)components.
GreyedboxesrepresentIndoorGIScompo-nents.
Whiteboxesrepresenteithercommodityopensourcecomponents(dashedbor-derboxes)orsmartplacesplatformspeciccomponents(solidborderboxes).
fullwebplatforminthesmartspace.
Usingcommoditywebcomponentsallowsustobringmanyfeaturestothesmartspacesuchas,forexample,easycreationanddeploymentofservicesusingwellknownauthoring/distributiontoolsandframeworkforwebapplications,usermanagementandsecuritysolutions,data-baseandcontentmanagementsystems.
Asfaraslocation-awarenesssupportisconcerned,theplatformcurrentlyincludesaMapsManagercomponent,whichisinchargeofprovidingCreateReadUpdateDelete(CRUD)primitivesforindoormapsdata,i.
e.
,rasterlayersrepresentingbuildingandoorplans,aswellasseveralfeatures(vector)layersrepresentingoortopologyelements(rooms,corridors,halls)andstaticPoints-of-Interests(e.
g.
,inanairportsmartplace,theycouldincluderestaurants,shops,check-indesks,terminals,gates,andothercategoriesofinteresttopeoplevisitingthatspace).
PlatformServicescanbecreatedbyusingthetechnologiesintheBasePlatform&Communicationlayer.
AfewtypicalplatformservicesareshowninFigure1.
TheyincludetwoactualindoorGIScomponents,namelyTopol-ogyServerandSmartPlaceDirectory.
TheTopologyServerisinchargeofprovidinglow-levelinformationaboutthephysicalstructureoftheavailablesmartplaces,suchasforexampledetailsabouthowagivenbuildingisstruc-turedinoors,wings,androoms.
Placesaremodeledbyusingahybridhier-archicallocationmodel[6],andeachphysicallocationisassignedaURIthatotherservicesandapplicationscanuseastagstoassociateitems(e.
g.
mediacontents,blogposts,userlocation)toacertainphysicallocation.
TheSmartPlaceDirectoryactsasamediatorbetweenSmartSpaceApplicationsandtheotherindoorGIScomponentsoftheplatform(i.
e.
,componentsbelongingLeveragingGISTechnologiesforWeb-BasedSmartPlacesServices261toeitherthePlatformServicesorBasePlatform&Communicationlay-ers).
ItprovidesasetofRESTAPIsthatallowSmartSpaceApplicationstoaccessotherPlatformServicesandBasePlatform&CommunicationfunctionalitythroughaconsistentandcommonAPI.
TheAPIallowsCRUDaccesstomostofthelocation-dependentdataavailableinthesmartplace,suchaspeoplelocation,location-speciccontents,andPOIs,inaweb-applicationfriendlyway.
Infact,itsupportsseveralwidelyadopteddata-interchangefor-mats,includingXML-basedformatslikeATOMandRSSfeeds,aswellasmorelightweightformatssuchastheJavaScriptObjectNotation(JSON).
Allthementionedcomponentssofarareintendedtobedeployedontheserver-side.
SmartSpaceApplicationsre-useandcombinethePlatformServicesfunctionalitywithotheron-devicefeaturesinordertoprovidemeaningfulandhelpfulfunctionalitytoend-users.
Thesemaybewebapplications,whichcanbeaccessedusingabrowserandwhichcanbehostedonthemobilewebap-plicationserver,oralternativelytheycanbeimplementedasstandaloneap-plicationswrittenusinganyoftheexistingdevicespecicdevelopmentkitsandthataccessthedeployedPlatformServicesthroughhttp-basedcommu-nication.
InFigure1weshowafewkeyexamplesofsuchapplications,whicharedescribedinthefollowing.
TheSmartPlaceBrowserrepresentsaverygenericentrypointtoavailableapplications,providinganAJAXAPIforSmartSpaceApplicationsdeveloperstocreatenewend-userapplications.
TheAPIexposesandleveragesthekeyabstractionsimplementedbyPlatformServicestoadeveloper-friendlyinterface.
Newapplications,suchastheIndoorMapViewer,Location-taggedContents,orFriendFinder,canbeeasilyimple-mentedontopofthisAPI,aswewillshowinSection4.
2.
Itisworthnotingthat,asFigure1clearlyshows,ourapproachisbasedonaverythin-clientmodel,inwhichnoparticularBasePlatform&Communica-tionorSmartSpaceApplicationscomponentsareassumedtobedeployedandpre-installedontheclient-side.
Infact,inordertousetheservices,theclient-sidejustneedstohaveawebbrowsercapableofrenderingrichwebapplications.
Additionalcomponents,suchasforexampletheIndoorLocationSensorinFigure1,mightberequiredinordertoenableusageofsomeapplications(liketheFriendFinder)ortoimproveuserexperiencewithotherapplications(e.
g.
,toautomaticallyadaptorinitializetheUIoftheIndoorMapViewerandLocation-taggedContentsapplicationsbasedontheactualindoorlocationoftheend-user).
3.
2TheAdoptedIndoor-PositioningTechniqueTheproposedsolutionreliesonanexperimentalWLANindoorpositioningtech-niqueunderresearchanddevelopmentatNokiaResearchCenter.
ThetechniqueisbasedonWLANscanningandonfurtherprocessingofthescanningresults,includingmeasurementofthereceivedsignalstrengthfromallreachableaccesspoints,fromwhichthecurrentlocationofthemobiledeviceiscalculated.
Allstepsareperformedontheterminalside,e.
g.
onend-userssmartphoneorPDA.
Intherestofthissub-sectionwewilljustshedsomelightonthekeyaspectsof262C.
diFloraandC.
PrehoferthistechniquethatarerequiredinordertounderstandtheherewithdescribedindoorGISsolution.
Theinterestedreadercanreferto[9]forfurtherdetailsonitsdesignandimplementation.
Oneinterestingaspectoftheadoptedindoorpositioningtechniqueliesinitsquickandeasydeploymentinout-of-the-labreal-worldsettings.
Infact,thetechniqueonlyrequiresa-prioriknowledgeofalistofknownWLANAPsalongwithinformationabouttheirphysicallocationinthetargetbuilding(whichistypicallyawell-knownpieceofinformationfor,butitdoesnotrequireanyo-linemeasurementsofthereceivedsignalstrengthnevertheless.
Inotherwords,noradiomapsofthetargetenvironmentandrelatedcalibrationofthealgorithmarerequired,whichinturnmakestheproposedsmartplacesinfrastructuremoreeasytoset-upthanotherstate-of-the-artsolutions[10].
TheoutcomeoftheproposedalgorithmisasymboliclocationinformationstructuredaccordingtothelocationmodelmentionedinSection3.
1.
Itisworthnotingthattheconceptsofbuilding,oor,andsectioncouldbeeventuallyre-placedbyotherconceptsandsemanticsifneeded.
Inotherwords,dierentsym-boliclocationmodelswithdierentgranularitiescouldbeadoptedasfarasthetechniqueisaccurateenoughtosupporttherequiredgranularity.
Forexample,inanenvironmentwithverylargesectionsandrooms,suchasashoppingmalloranairport,themodelcouldalsotakeintoaccounttheconceptofroomswithinasinglesection.
4ImplementationandPrototyping4.
1ImplementingtheIndoorGISPrototypeInSection3.
1weintroducedthemainindoorGIScomponentsataveryhigh-levelofdetail.
SincewewantedtocreateapracticalGISsolutionforindoorsmartspacesthatcouldworkalsofrommobiledevices,weneededtocombinetheweb-basedsmartspaceplatformandtheindoorpositioningtechnique,de-scribedinSection3.
1and3.
2,respectively,withadditionalcomponentsprovidingtraditionalGISfunctionality,suchasmaps,navigation,andgeo-spatialqueriessupporttocommercialmobiledevices.
IncompliancewithouroverallsmartspacesapproachdescribedinSection3,wedecidedtorelyonopenAPIsandprotocolssuitableforintegrationwithweb-basedapplicationsandservices.
Inthefollowingwediscussafewkeyim-plementationdecisionsthatweneededtotakewhenprototypingtheindoorGISpartofoursmartplacesplatform.
Inaddition,wealsoprovidefurtherdetailsabouthowindoorGIScomponentsinteractonewitheachotherinordertofullltheirresponsibilities.
Morespecically,wedescribehowweimplementedandprototypedourrstexampleofanindoorGISsystembasedonthedesignguidelinesandconceptsdescribedinSection3.
TheoverallarchitectureoftheimplementedprototypeisdepictedinFigure2.
WhenimplementingtherstprototypewehadtosatisfythekeyrequirementofprovidingsimpleRESTAPIsforotherservicestocreatecompositefunction-ality(mashups)outofthebasicbuildingboxesprovidedbyourplatform.
ToLeveragingGISTechnologiesforWeb-BasedSmartPlacesServices263Fig.
2.
ThearchitectureofourindoorGISimplementationprototype.
GreyedboxesrepresentIndoorGIScomponents.
Whiteboxesrepresenteithercommodityopensourcecomponents(dashedborderboxes)orsmartplacesplatformspeciccomponents(solidborderboxes).
Dashedlines,solidlines,anddash-dottedlinesrepresentinteractionrelatedtoIndoorMapViewer,Location-taggedContents,andFriendFindercasestudyapplications,respectively.
thisaim,weimplementedtheSmartPlaceDirectoryinthePythonprogram-minglanguagebyusingtheDjangowebapplicationframework.
UsingtheDjangoframeworkenabledustoquicklyimplementdierentfacadesforthesameback-enddata,inordertosupportCRUDinterfacestomanagelocation-dependentsmartplaceresourcesbasedonallthedatainterchangeformats(JSON,ATOM,RSS)mentionedinSection3.
1.
Similarly,mostoftherealizedwebserviceswereimplementedasDjangoapplications.
Thisgaveusalotofexibilityindesign-ingtheactualwebserviceinterfaceswewantedtousetoexposetheindoorlocation-dependentdatastoredinourback-end.
AsfarastheMapsManagercomponentisconcerned,wewantedtorelyasmuchaspossibleonestablishedstandardsforrepresentingindoorGISdata,suchasmaps,points-of-interests,andrelatedmeta-data:tothisaim,wedecidedtoadopttheOpenGeospatialConsortium(OGC)WebMapService(WMS)andWebFeatureService(WFS)[12]torepresentmapsandPOIsintheMapsMan-agercomponent.
Thisdecisionwasmotivatednotonlybytechnicalrequirements,butalsobyourhigherlevelgoalofevaluatinghoweasyandfeasiblewastheideaofusingcommodityGISsolutionstosupportindoorLBS.
Severalcommodityimple-mentationsofWMS/WFSserverswereavailableinboththecommercialandopensourcecommunity.
Afterevaluatingthedierentavailableoptions,wedecidedtoadopttheopensourceGeoserverplatform[14],whichprovidedquiteacompleteimplementationofWMSandWFSspecications.
Geoserverwasalsoverywellin-tegratedwithotherGIStools(suchas,forexample,uDig[17]orGRASSGIS[18]264C.
diFloraandC.
Prehoferstandalonetools,aswellaswithJavaScriptGISAPIssuchasOpenLayers[15]).
However,sincewewantedtorelyjustonWMSandWFSservices,GeoservercouldbeinprinciplebereplacedbyanyotherworkingimplementationoftheWMSandWFSspecications(liketheMapserversoftwareforexample),withoutaectingtherestoftheplatform.
Itisworthnotingthat,sinceGeoserversatisedalltherequirementswehadfortheMapsManager,itisindicatedinFigure2asacom-modityopensourcecomponent,andnotasanovelindoorGIScomponentaspre-viouslyindicatedintheconceptualdesigndiagramofFigure1.
Whendesigningoursolution,wewantedtoprovideveryopenAPIsforaccess-ingtheavailableIndoorGISdata(notonlyfromWMS/WFSsourcesbutalsofromotherexistingsolutions)frombothmobiledevicesandxed/desktopdevices.
Tothisaimwehadtoconsiderthat,althoughtheOGCwebservicesalreadyprovidedacomprehensivesetofAPIs,theirinterfaceswerenotveryfriendlytoJavaScript/Ajaxdevelopers.
Moreover,asalreadymentioned,wewantedtokeeptheAPIsasopenaspossible,soastonotprecludeinteroperabilityofoursolutionwithotherprotocolsdierentfromtheOGCWMS/WFSstandards.
Tosatisfysuchrequire-mentswedecidedtoadopttheopensourceOpenLayersJavaScriptAPI[15],whichprovidedquiteacomprehensiveanddeveloper-friendlysetofJavaScriptabstrac-tionstodealwithmostcommonGISfunctionality(e.
g.
,dynamiccreationofmapsbymashingupmapdatacomingfromdierentsources,DOMinterfacetomostofthesupportedGISdatarepresentationformats)whilesolvingalreadyalotofcom-moncross-browserissuesrelatedtodierencesinthelow-levelJavaScriptAPIsofdierentbrowserengines.
4.
2EvaluatingtheIndoorGISPrototypeInordertovalidateandtoreneourJavaScriptGISinterfaces,weimplementedacasestudyapplication,namelyIndoorMapViewer,whichcombinedourin-doorGISback-endservicesandaccessedthemthroughanOpenLayersinterface.
Similarly,inordertotesttheindoorlocationsensingfeature,weimplementedaFriendFinderapplicationwhichallowedend-userstochecktheirownfriends'location,toseeitonamap,andtoevaluatethedistancebetweenthemselvesandtheirfriendsinthesmartplace.
Inordertoshowindoormaps,theFriendFinderapplicationre-usedmostoftheIndoorMapViewerfunctionality.
Similarly,inordertovalidateandrenethelocation-basedsearchfunctionality,weimplementedaLocation-taggedContentscasestudyapplication,whichallowedend-userstogenerate,search,andretrievelocation-basedcontents,suchaspictures,videos,textdocuments,andblogpostsandcomments.
Theimplementedapplicationsallowedustoevaluateandrenetheweb-basedapproachtoindoorLBSserviceprovisioningtocommercialmobiledevices.
Theimplementedapplicationsconrmedthefeasibilityofusingwebtechnologiesforfastandeasydeploymentofsmartplacesservices.
MostofthetimewasspenttoimplementandrenethebusinesslogicofourindoorGIScomponents,andwewereabletoeasilydeployandruntheservicesonaheterogeneousdevicebase.
Asforserver-sidecomponents,wewereabletodeploythemonLinux,Windows,andAppleMacOsXdevices.
Theimplementedcasestudyexamples,realizedLeveragingGISTechnologiesforWeb-BasedSmartPlacesServices265asAjaxapplications,couldbeaccessedfrommobiledevices,includingNokiaS60devicesaswellasLinuxInternetTablets(NokiaN800andN810),andingeneralfromanydevicerunningawebbrowserthatincludedeithertheMozillaorSafariwebengines(includingdesktop/laptopclients).
AsfarasJavaScriptclientsforgeospatialservicesareconcerned,usingOpen-LayersraisedafewperformanceissuesforresourceconstraineddevicesliketheNokiaS60devices.
Theseissuesincludedatleastthefollowingproblems.
TherstproblemconsistedinthatdynamicmemoryfootprintrequirementsofOpenLay-ersarestilltoolargewithrespecttoanotnegligiblesetofcommercialdevices.
OpenLayersmapsinitializationrequiresabout2.
5MBofRAMmemorytobedy-namicallyallocated,andfurtherusageofsomespecialOpenLayerscontrolscaneasilyincreasetheamountofdynamicallyallocatedRAMupto5or6MB.
Thedynamicmemoryfootprintanalysisalsoshowedthatdynamicmemoryalloca-tioninOpenLayerscomponentshasnotbeenoptimizedformemoryconstraineddevices.
AlotofRAMresources,allocatedbyOpenLayerscode,werenotre-leased,thusleadingtofrequentandnotnegligiblememoryleaks,whichinturncausedalsomorerecentandpowerfuldevicestoreturnmemoryfullerrorswhentryingtovisualizesomeoftheimplementedapplications.
WhilethesedynamicmemoryissuesdonotcauseanyproblemsindesktoporInternetTabletdevices,oncertainlow-endorlessrecentdevices(e.
g.
NokiaN80orE70)itwasimpos-sibletoruntheimplementedapplications,duetothelimitedamountofRAMmemoryavailableonthosedevices.
Webelievethatthisproblemwillbesolvedinfuturedevices,sincetheamountofRAMmemoryavailableonsuchdevicesisrapidlyincreasing.
However,thememoryleakingproblemscanonlybesolvedwithadierentandmoreecientmemoryallocation/deallocationapproachinOpenLayersimplementation.
Webelievethatsimilarproblemsmayarisewhentryingtoreuseothercommoditylibraries,initiallydesignedfordesktopclients,formobilerichinternetapplicationsdevelopment.
AnotherproblemweexperiencedisrelatedtoOpenLayersdependencyonDOM2.
0APIs.
OpenLayersassumesacompleteDOM2.
0or3.
0modeltobesupportedbythebrowserengine.
Unfortunately,browserenginesevenonveryrecentdevices(liketheNokiaN95)donotfullysupportthesespecications.
ThiscreatedproblemswhenparsingsomeoftheXMLdocumentsreturnedbyoursmartplacesAPIthroughtheDOMAPI.
Theproblemwassolvedbyre-codingtheapplicationsinsuchawaythattheywererelyingonJSON-formattedinterfaceratherthanonATOM/RSSformatteddata.
Inthiswaywewereabletoguaranteethatallapplicationscouldstillworkonallthementionedtypesofdevices.
Suchamodicationhadalsothepositiveside-eectofimprovingtheperformanceoftheprovidedapplicationsduetothemorelight-weightlogicrequiredforparsingandcreatingthedata.
5LessonsLearntandFutureWorkThispaperdiscussedourexperienceswithbuildinganindoorGISbasedoncommodityGISstandardsandprotocolsandWeb2.
0applicationdevelopment266C.
diFloraandC.
Prehoferprinciples.
Weshowedthatthecombinationofscriptinglanguageswithwebap-plicationframeworks,suchasPythonandDjango,gaveusalotofexibilityindesigningtheactualwebserviceinterfaceswewantedtousetoexposeindoorGISdata.
WeimplementedafewcasestudyapplicationsontopoftheproposedGISsolution,whichconrmedthefeasibilityofusingwebtechnologiesforfastandeasydeploymentofsmartplacesservicesonaheterogeneoussetofcom-mercialo-the-shelfdevices.
AsfarasJavaScriptGISclientsareconcerned,wepointeditourthatusingcommoditylibraries,suchasOpenLayers,cancreateafewperformanceissuesforresourceconstraineddevices.
Moreover,commoditylibrariesmighthavenotbeendesignedbytakingintoaccountthelimitedRAMcapacityofmobiledevices.
Frequentandnotnegligiblememoryleakscreatedproblemsalsoonmorerecentandpowerfuldevices.
Overall,webelievethereisaclearneedinresearchandindustrytoagreeonstandardsforindoorLBS,withrespecttobothgeospatialdatarepresentationsandrelatedAPIstore-usetheminaWeb2.
0environment.
Existingoutdoor-relatedstandardsmightlaythegroundworkforsuchactivities,eventhoughtheyshouldbeextendedinor-dertosupportnotonlytheconceptoflocationasphysicalpositionbutalsosymboliclocationconcepts.
Ourfutureworkwillconcernrenementofthepo-sitioningtechniqueandrelatedlocationmodel,aswellasworkonmorethinclientsbettersuitedformobileusageintermsofmemoryconsumptionandUIparadigms.
Acknowledgments.
TheauthorswouldliketoacknowledgethecontributionsfromtheSmartPlaceprojectatNokiaResearch,inparticularJillesvanGurpandHeikkiMattila.
References1.
Simon,R.
,Fr¨ohlich,P.
:Amobileapplicationframeworkforthegeospatialweb.
In:WWW2007:Proceedingsofthe16thinternationalconferenceonWorldWideWeb,pp.
381–390.
ACM,NewYork(2007)2.
Griswold,W.
G.
,Shanahan,P.
,Brown,S.
W.
,Boyer,R.
,Ratto,M.
,Shapiro,R.
B.
,Truong,T.
M.
:Activecampus:Experimentsincommunity-orientedubiquitouscom-puting.
Computer37(10),73–81(2004)3.
Wang,X.
,Dong,J.
S.
,Chin,C.
Y.
,Hettiarachchi,S.
R.
,Zhang,D.
:SemanticSpace:aninfrastructureforsmartspaces.
IEEEPervasiveComputing3(3),32–39(2004)4.
Endres,C.
,Butz,A.
,MacWilliams,A.
:Asurveyofsoftwareinfrastructuresandframeworksforubiquitouscomputing.
Mob.
Inf.
Syst.
1(1),41–80(2005)5.
Candy,J.
:AMobileIndoorLocation-basedGISApplication.
In:5thInternationalSymposiumonMobileMappingTechnologies(MMT2007),Padua,Italy(2007)(lastcheckedon6.
5.
2008),http://giswww1.
bcit.
ca/georanger/candyjonathan.
pdf6.
Becker,C.
,Durr,F.
:Onlocationmodelsforubiquitouscomputing.
In:PersonalandUbiquitousComputing,vol.
9(1),pp.
20–31.
Springer,Heidelberg(2005)7.
Lopez-deIpina,D.
,Vazquez,J.
,Abaitua,J.
:Acontext-awaremobilemashupplat-formforubiquitousweb.
In:3rdIETInternationalConferenceonIntelligentEn-vironments,pp.
116–123(2007)LeveragingGISTechnologiesforWeb-BasedSmartPlacesServices2678.
Kim,J.
W.
,Kim,C.
S.
,Gautam,A.
,Lee,Y.
:Location-BasedTourGuideSystemUsingMobileGISandWebCrawling.
In:Kwon,Y.
-J.
,Bouju,A.
,Claramunt,C.
(eds.
)W2GIS2004.
LNCS,vol.
3428,pp.
51–63.
Springer,Heidelberg(2005)9.
Hermersdorf,M.
:IndoorPositioningwithaWLANAccessPointListonaMobileDevice.
In:InternationalWorkshoponWorld-SensorWeb(WSW2006),Boulder,CO,USA,October31(2006)(lastcheckedon6.
5.
2008),http://www.
sensorplanet.
org/wsw2006/9HermersdorfindoorposWSW2006final.
pdf10.
Haeberlen,A.
,Flannery,E.
,Ladd,A.
M.
,Rudys,A.
,Wallach,D.
S.
,Kavraki,L.
E.
:Practicalrobustlocalizationoverlarge-scale802.
11wirelessnetworks.
In:Pro-ceedingsofthe10thAnnualinternationalConferenceonMobileComputingandNetworking(MOBICOM2004),pp.
70–84.
ACM,NewYork(2004)11.
VanGurp,J.
,Prehofer,C.
,diFlora,C.
:ExperienceswithRealizingSmartSpaceWebServiceApplications.
In:1stIEEEInternationalPeer-to-PeerforHandheldDevicesWorkshopattheCCNC2008conferenceinLasVegas(2008)12.
OpenGISstandardsspecications,http://www.
opengeospatial.
org/standards13.
EkahauInc.
,http://www.
ekahau.
com/14.
Geoserverwebsite,http://geoserver.
org15.
OpenLayerswebsite,http://www.
openlayers.
org16.
DeliveryContextClientInterfaces(DCCI)1.
0,W3CCandidateRecommendatio(December2007),http://www.
w3.
org/TR/DPF/17.
uDig-User-friendlyDesktopInternetGIS,http://udig.
refractions.
net/18.
GRASS-GeographicResourcesAnalysisSupportSystem,http://grass.
itc.
it/19.
OAuthCore1.
0Protocol(December2007),http://oauth.
net/core/1.
0/