DYNAMISK VISUALISERING AV GEO DATA MED HTML5 OCH JAVASCRIPT
Optimerade interaktiva webbkartor
DYNAMIC GEO DATA
VISUALIZATION IN HTML5 AND JAVASCRIPT
Optimized interactive web mapping
Examensarbete inom huvudområdet Datalogi Grundnivå 30 högskolepoäng
Vårtermin 2016 Fredrik Roslund
Handledare: Henrik Gustavsson
Examinator: Mikael Berntsson
Sammanfattning
Kan användandet av mobiltelefoner användas till positionsangivelser med godtagbar felmarginal? Kan ett mindre frekvent användande av GPS-signal användas för reducerad batteråtgång, och vilken teknik för rendering av grafiskt material belastar mobiltelefonens CPU på minsta sätt? Dessa frågor ställs och undersöks i detta arbete. Med bakgrund i Global Position Systems GPS, utreds positionering med hjälp av satelliter och triangulering av bl.a.
mobilmaster och Wifi-signal. Användandet av ett geografiskt API ger möjligheten att skapa ett lätt och hanterbart gränssnitt som återger positioner för en användare. Med stöd i HTML5 för Canvas och SVG-element renderas förlustfri vektoriserad grafik utan kravet att installera insticksmoduler från tredjepart. Med hjälp av JavaScript och HTML5 skapas en applikation som har till syfte att återge en spelares position på en renderad golfbana.
Nyckelord: GPS, Geografiskt API, Canvas, SVG, HTML5, JavaScript
Innehållsförteckning
1 Introduktion ... 1
2 Bakgrund ... 2
2.1 GPS ... 2
2.2 Geografisk positionerings API ... 3
2.2.1 W3C Geografiska API ... 3
2.3 Canvas Element och vektoriserade kartor... 6
2.4 Golfapplikationer ... 7
3 Problemformulering ... 8
3.1 Tillämpning ... 8
3.2 Problemet ... 8
3.3 Hypotes ... 9
3.4 Metodbeskrivning ... 9
3.4.1 Experiment ... 9
3.4.2 Alternativa Metoder ... 10
3.4.3 Forskningsetik ... 11
4 Genomförande ... 12
4.1 Förstudie ... 12
4.2 Applikationen ... 13
4.3 Progression ... 14
4.4 Piltostudie ... 14
4.4 Konklusion av pilotstudie ... 21
5 Utvärdering... 21
5.1 Presentation av undersökning... 21
5.2 Analys ... 27
5.3 Slutsatser ... 27
6 Avslutande diskussion ... 29
6.1 Sammanfattning ... 29
6.2 Diskussion ... 30
6.3 Framtida arbete ... 31
Referenser ...
1 Introduktion
Golf är en sport/ sällskapsspel som både innefattar fysiska samt psykiska prestationer i form av uthållighet och förmågan att uppehålla stort fokus under hela rundan. Sporten erbjuder en lagom fysisk ansträngning och uppfattas av många som ett perfekt sätt för rehabilitering och motionering. Att golfspelare använder sig av hjälpmedel för att förbättra sitt spel har på senare år blivit allt vanligare. Att kunna ta del av golfbanor och dess utseende mobilt och samtidigt ha möjligheten att se sin position på banan är ett uppskattat hjälpmedel (Kim, et al., 2011). Med hjälp av sensoravläsning och användargränssnitt i smarta mobiltelefoner ges möjligheten för en golfspelare att bl.a. kunna visualisera sin position på banan i realtid och planera sitt spel därefter.
Global Positioning System, i dagligt tal oftast benämnd som GPS är ett system som har många användningsområden. För att bestämma en position med hjälp av GPS mäts avståndet mellan ett antal satelliter med hjälp av triangulering. Avståndsmätning sker genom att mäta skillnaden i tiden det tar för varje satellits signal att nå mottagaren. Enligt D´Roza och Bilchev (2004) kan en mottagares position bestämmas genom att mäta ett flertal signalers restid från ett antal satelliter till en mottagare.
Att använda sig av applikationer som kontinuerligt lokalisera positioner med hjälp av GPS:en i smarta telefoner ökar snabbt batteriåtgången, detta går dock att reducera genom att använda lägre uppdateringsfrekvenser för GPS:en (Nawarathne, et al., 2014). Att använda lägre uppdateringsfrekvenser skapar dock ökade problem med signalbortfall vilket i sin tur kan leda till att noggrannheten vid positionsangivelser minskar.
Enligt Shin och Shin (2014) ges användaren samma användarupplevelse oberoende av plattform. Inte bara kan HTML5-baserade applikationer hitta positioner med mobiltelefonens inbyggda GPS utan de kan också ge ett kvalitativt användargränssnitt för användaren bl.a. med sin roterande canvas-funktion, även om det inte är en specifik mobilapplikation.
Med en applikation där canvas- eller SVG-grafik i form av golfbanor implementeras och
renderas lokalt i en webbläsare på klientsidan med hjälp av HTML5 och JavaScript ges en
ökad användbarhet och mindre statiska grafiska objekt. Att kunna förstora, dra eller vända
på den grafiska golfbanan skapar en realtidsupplevelse. Applikationen använder sig av ett
geografiskt API som har till uppgift att återge en spelares position på den renderade
golfbanan. Problemet med en applikation som både implementerar och renderar interaktiva
kartor samt återger geografisk position är att tillvägagångssättet kan vara avgörande. Att
rendera en karta på klientsidan genom att använda SVG-grafik eller via koordinater i ett
canvas element kan på olika sätt belasta den mobila enhetens CPU. För att en optimering av
applikationen ska kunna genomföras bör en jämförelse mellan de olika teknikerna (SVG och
canvas- koordinater), samt batteriåtgång och noggrannhet vid positionsangivelse hos GPS
vid olika uppdateringsfrekvenser utföras på olika fabrikat av mobiltelefoner, operativsystem,
göras.
2 Bakgrund
2.1 GPS
Global Positioning System, i dagligt tal oftast benämnd som GPS är ett system som har många användningsområden. För att bestämma en position med hjälp av GPS mäts avståndet mellan ett antal satelliter med hjälp av triangulering. Avståndsmätning sker genom att mäta skillnaden i tiden det tar för varje satellits signal att nå mottagaren. Enligt D´Roza och Bilchev (2004) kan en mottagares position bestämmas genom att mäta ett flertal signalers restid från ett antal satelliter till en mottagare. Först mäts restiden för en signal från en första satellit (figur 1(blå)). Med värdet från den första satelliten går det att beräkna en mottagares troliga position i en sfäriska yta med radien x. Sedan tas värdet från satellit nummer två för att ytterligare få en position i en sfäriska yta (figur 1(gul)). Genom att placera de båda sfärerna på varandra uppkommer det en elliptisk ring i mitten där de två sfärerna korsar varandra och en ny exaktare position uppnås, longitud och latitud (figur 1(orange). Värden tas sedan från ytterligare två satelliter, varav ett tas bort för att den t.ex. är för långt ifrån jorden (figur 1(grön)). När den tredje signalen är beräknad kan även altitud visas och en ännu mer exakt position (figur 1(röd)) uppnås. Figur 1 visar en förenklad modell.
Figur 1 GPS positions beräkning med användandet av en, två och tre satelliter (efter Roza & Bilchev, 2004, s. 21 & Wikipedia, https://en.wikipedia.org/wiki/World_map).
Smarta telefoner är idag en vanligt förekommande produkt och det medför att många människor bär med sig en GPS i fickan. Då en GPS ofta finns tillhands genom mobiltelefonen kan den hjälpa användare att navigera i världen genom att t.ex. visa rätt väg vid bilkörning, bestämma positioner och ge information vid utövandet av olika aktiviteter.
GPS data kan ibland samlas in via Wi-Fi, GSM eller Bluetooth tillsammans med annan information från mobiltelefonernas olika applikationer. Den informationen kan sedan användas i syften att klassificera användares användningsområden, rörelsemönster och/eller resesätt (Zhu, et al, 2015).
Då dagens smarta mobiltelefoner ofta är fyllda med olika typer av sensorer så som GPS, nätverksbaserade positioneringssystem och accelerometrar och resurskrävande applikationer skapas ett problem med att batteritiden ofta minskar snabbt. Detta kan ibland leda till att en kompromiss mellan energiförbrukning och noggrannhet sker. Detta går dock att reducera genom att använda lägre uppdateringsfrekvenser för GPS:en. Enligt Vallina-
Blå Longitud Gul Latitud Grön Altitud
a)
Rodriguez och Crowcroft (2013) så har möjligheten att använda sensoravkänning spelat en avgörande roll för den explosiva utvecklingen av mobiltelefoner dom senaste åren. Mobila applikationer behöver ofta information om positionering för att uppdatera och tillhandahålla relevant information till användaren. Nackdelen med den här typen av utveckling är att olika typer av sensoravläsning kan bli kostsam i form av ökad batteriåtgång.
2.2 Geografisk positionerings API
Det finns ett antal API:n på marknaden utvecklade av bl.a. Mozilla, Google, bing, mapquest, Yahoo och W3C (World Wide Web Consortium). Användandet av geografiska positionerings API:n kan implementeras med hjälp av en enkel applikation som tar reda på webbläsarens position. Geografiska positionerings API:n har till uppgift att ta emot information om den geografiska positionen hos en användares produkt/apparat. API:n tar ofta hjälp av en LBS (Location based service) som enligt Wu och Wu (2006) förser användare med positions- och kontextkänslig information i tjänster så som t.ex. kartor, väder och trafik.
De vanligaste signalerna förutom GPS som används för att bestämma en produkts position är IP-adress, Wi-Fi, Bluetooth, MAC-adress eller via radiofrekvens identifikation (RFID). De nämnda signalerna har dock oftast en sämre noggrannhet än GPS.
2.2.1 W3C Geografiska API
World Wide Web Consortium (W3C) har i ett försök att standardisera insamlingen av geografisk informationsdata skapat W3C Geolocation API. Här har W3C skapat ett API som är starkt kopplat till HTML5 och kan appliceras direkt i en webbläsare som stödjer detta (figur 2). Till dags dato stöds detta i de allra flesta senare utgåvor av webbläsare så som:
Internet Explorer 9, Firefox 3.5+, Chrome 5+, Safari 5+, Opera 10.6+, Android 2+ och Iphone 3+ vilket gör API’t relativt plattformsoberoende.
Enligt författarna av artikeln ”Uses of W3C’s Geolocation API” som publicerades 2010 används två primära tekniker för att bestämma geografiska positioner, positionering via IP- eller MAC-adress och triangulering via GPS, Wi-Fi eller mobilmaster (RFID). Fördelarna med att bestämma positionering via IP-adress är att tekniken oftast finns tillgänglig då den sker på serversidan, dock kan exaktheten vara något sämre. Att använda triangulering vid bestämmandet av positionering har fördelarna att olika tekniker används för att komplettera varandra t.ex. kan Wi-Fi användas inomhus där inte GPS fungerar och mobilmaster där GPS eller Wi-Fi inte har täckning (Pejić, Pejić, & Čović, 2010).
W3C Geolocation API är baserat på JavaScript och dess vanligaste metoder för att hitta en användares position sker asynkront vilket betyder att en begäran om att erhålla en specifik geografisk position (figur 2 (getCurrentPosition)) eller (figur 3 (watchPosition)) görs endast en gång sedan fortsätter programmet utan att ta hänsyn till om svar mottagits eller inte.
Enligt Pejić, et al., (2010) leder detta till att ”Callback” funktioner bör implementeras för att hantera både lyckade (figur 4 (sucessCallback)) och misslyckade anrop (figur 5 (errorCallback)).
Vid användandet av operationen getCurrentPosition görs ett försök att så snabbt som möjligt
ange en geografisk position. Detta skapar dock en sämre noggrannhet i resultatet då IP
adress eller Wi-Fi användas för att ge snabbare svar. I de fall där rörliga objekt behöver
positionsbestämmas eller där mer korrekt geografisk information inkommer finns
möjligheten att använda sig av operationen watchPosition där Callback-funktionen anropas ett flertal gånger för att kontinuerligt uppdatera en geografisk position.
Vid ett kontinuerligt användande av mobiltelefonens GPS ökar batteriåtgången. Den ökade batteriåtgången går dock att reducera genom att använda lägre uppdateringsfrekvenser för GPS:en. Att använda lägre uppdateringsfrekvenser skapar dock ökade problem med signalbortfall. Detta går dock att lösa till viss del genom att de sensorer som finns i en smart mobiltelefon har stöd för att beräkna troliga positioner vid fall där signal försvinner helt.
Detta omnämns ofta som: Incremental positioning based on Dead Reckoning. Uträknandet av den troliga positionen sker stegvist ökande från den senaste angivna positionen och/eller uträknad hastighet. Detta baseras på att föremålet fortfarande är i rörelse (Nawarathne, et al., 2014).
Figur 2 Exempel på positionsbegäran: getCurrentPosition
Kodstycket i figur 2 kontrollerar om webbläsaren har stöd för geografiskt API genom operationen navigator.geolocation och skapar en begäran om att få den aktuella positionen genom operationen getCurrentPosition om API:t stöds i webbläsaren. Vid lyckat anrop kallas successCallback eller vid misslyckat errorCallback.
Figur 3 Exempel på uppdaterad positionsbegäran: watchPosition
Kodstycket i figur 3 är en funktion innehållande operationen watchPosition som uppdateras automatiskt varje gång det avlästa positionsvärdet ändrar sig. Här används samma Callback- funktioner som i exemplet med getCurrentPosition.
function geoApi(){
if (navigator.geolocation) {
navigator.geolocation.getCurrentPosition(successCallback, errorCallback);
} else {
// Annars gör något annat }
}
function geoApi(){
if (navigator.geolocation) {
navigator.geolocation.watchPosition(successCallback, errorCallback);
} else {
// Annars gör något annat…
} }
Figur 4 Exempel vid lyckad positionsbegäran
Kodstycket i figur 4 hanterar ett lyckat positionsanrop. Här sparas de geografiska koordinaterna latitud, longitud och altitud samt den angivna positionens noggrannhet i variabler som sedan används för att skrivas ut.
Figur 5 Exempel på felhantering vid utebliven positionsangivelse
Kodstycket i figur 5 visar ett exempel på felhantering vid ett misslyckat positionsanrop.
Exemplet använder sig av en switch-funktion vilken tar hänsyn till vilket typ av fel som uppkommit.
function errorCallback(error) { switch(error.code) {
case error.PERMISSION_DENIED:
// Geolocation API stöds inte, gör något break;
case error.POSITION_UNAVAILABLE:
// Misslyckat positionsanrop, gör något break;
case error.UNKNOWN_ERROR:
// Okänt fel, gör något break;
} }
function successCallback (position) {
var latitude = position.coords.latitude;
var longitude = position.coords.longitude;
var altitude = position.coords.altitude;
var accuracy = position.coords.accuracy;
//Gör nånting med ovanstående t.ex.
alert('Min position är:' + latitude +' and long : ' +longitude );
}
2.3 Canvas Element och vektoriserade kartor
För att göra webbapplikationer mer oberoende av vilken webbläsare som används och/eller de begränsningar ett operativsystem kan skapa, har utvecklingen av HTML5 tagit fart.
HTML5 erbjuder stöd för utvecklare med en mängd nya element så som stöd för att rita ut grafik med hjälp av JavaScript i en canvas, användandet av SVG-grafik och videoelement.
Detta bidrar till en miljö där användare inte längre behöver installera en insticksmodul för att kunna exekvera och visualisera grafiskt material.
Enligt Shin och Shin (2014) ges användaren samma användarupplevelse oberoende av plattform. Inte bara kan HTML5-baserade applikationer hitta positioner med mobiltelefonens inbyggda GPS utan de kan också ge ett kvalitativt användargränssnitt (UI) för användaren bl.a. med sin roterande canvas-funktion, även om det inte är en specifik mobilapplikation.
Att enbart använda sig av SVG-grafik eller canvas-koordinater för att rita ut ett vektoriserat golfbanesystem (figur 6) fyller vissa kriterier gällande interaktiva kartor. Att geometriskt kunna förstora och rotera element utan att förlora upplösning eller att renderingsstiden ökar är att föredra, men att få en karta att verkligen stämma överens med verklighetens koordinater är en svår uppgift. Detta kan ett gränssnitt som t.ex. OpenLayers, Cartagen eller Google Maps API som genererar sina kartor efter dynamiskt uppdaterade koordinater lösa, och detta kan ge en bra fördel vid implementeringen av visualiserad positionsdata.
Figur 6 Exempel på SVG grafik och Canvas koordinater
I Figur 6 visas en golfbana utritat med SVG-grafik och ett exempel på canvas- koordinater för ett vattenhinder.
//--- //Group:Water_Hazards
//---
c.beginPath();
c.moveTo(135.2,245.1);
c.bezierCurveTo(135.2,262.9,134.3,277.4,116.4,277.4);
c.bezierCurveTo(84.1,263,84.1,263,84.1,245.1);
c.bezierCurveTo(98.5,212.8,98.5,212.8,116.4,212.8);
c.bezierCurveTo(135.2,227.2,135.2,227.2,135.2,245.1);
c.lineTo(135.2,245.1);
c.globalAlpha=1.0;
c.fillStyle="#000";
c.fill();
//--- //GroupEnd:Water_Hazards
//--- Water Hazard
Vid skapandet av mer personliga och specificerade kartor är användandet av vektoriserad grafik intressant då möjligheter för att skräddarsy och designa kartor efter utvecklarens tycke och smak finns. Genom att rendera en kartas grafik lokalt i ett canvas-element ökar användbarheten och gör kartor mindre statiska. Att kunna zooma, dra eller vända på kartor skapar en realtidsupplevelse i motsatts mot den mer konventionella tekniken som hämtar och laddar PNG, JPG eller GIF filer (som används i ett flertal datorbaserade kartapplikationer) från en server. Genom att applicera mappgrännsnit som t.ex. OpenLayers, Cartagen eller Google Maps tillsammans med W3C:s geologiska API eller som oberoende API:n, kan interaktiva kartor skapas genom att ladda data från olika kartkällor. Funktioner som skiftande utseende vid markering, klickfunktioner och stegfri skalning kan implementeras genom att applicera JavaScript-funktioner på enskilda kartobjekt.
2.4 Golfapplikationer
Golf är en sport/ sällskapsspel som både innefattar fysiska samt psykiska prestationer i form av uthållighet och förmågan att uppehålla stort fokus under hela rundan. Sporten erbjuder en lagom fysisk ansträngning och uppfattas av många som ett perfekt sätt för rehabilitering och motionering. Så här skriver Shin och Wunsche vid utvecklandet av sin golfsimulerade applikation för personer med reumatism ”Golf är en rekommenderad aktivitet för patienter som är diagnostiserade med reumatism, då det innebär promenader och mjuka rörelser till en måttlig mängd tid. Det finns även tillräcklig tid att vila sig emellan.” (Shin & Wunsche, 2013, s. 460).
Att på olika sätt kunna uppleva sitt spel är en värdefull tillgång för en golfspelare, då en strävan efter att alltid bli bättre finns. Att ha möjligheten att se hur golfklubban har svingats (se exempelvis Noiumkar & Tirakoat, 2013), hur långt en golfboll har slagits eller hur långt det är till olika hinder på banan har inneburit en revolution i utvecklandet av olika typer av golfapplikationer. Enligt Kim, et al., (2011) har de senaste årens utveckling inom datorteknik lyckats producera flertalet innovativa produkter där teknik och golf har slagits samman och skapat en helt ny marknad.
Med hjälp av sensoravläsning och användargränssnitt i smarta mobiltelefoner ges
möjligheten för en spelare att bl.a. kunna visualisera sin position på banan i realtid och
planera sitt spel därefter. Att i efterhand också kunna analysera valda spellinjer baserade på
utgångspositioner och vad som gjordes rätt eller fel skapar en bra grund att stå på i sin
fortsatta spelutveckling. För den motions eller rehabiliteringsintresserade finns möjligheten
att kunna se den totala sträckan och den tid som han/hon utfört genom att spela en runda
golf.
3 Problemformulering
3.1 Tillämpning
Att använda sig av hjälpmedel för att förbättra sitt golfande har på senare år blivit allt vanligare. Att kunna ta del av golfbanor och dess utseende mobilt och samtidigt ha möjligheten att se sin position på banan är ett uppskattat hjälpmedel (Kim, et al., 2011). En golfapplikation som baseras på att visualisera en spelares position och att ge information om banan, dess hinder och avstånd har till uppgift att underlätta spelet för en golfare och detta ställer krav. De krav som ställs är att en hög noggrannhet av position anges samt att en grafisk bana och dess hinder renderas utan svårigheter och med en hög hastighet. Att en spelare ska kunna klicka på en karta för att få information om olika artefakter på en viss bana ställer ytterligare krav på prestanda.
3.2 Problemet
Problemet med en applikation som både ska implementera och rendera interaktiva kartor samt geografisk position är att tillvägagångssättet kan vara avgörande. För att skapa ett oberoende av vilken plattform/OS som används implementeras applikationen med HTML5.
Enligt Shin och Shin (2014) ges användaren samma användarupplevelse oberoende av plattform. Inte bara kan HTML5-baserade applikationer hitta positioner med mobiltelefonens inbyggda GPS utan de kan också ge ett kvalitativt användargränssnitt för användaren. HTML5 erbjuder stöd för utvecklare med en mängd nya element bl.a. stöd för att rita ut grafik med hjälp av JavaScript i en canvas och användandet av SVG-grafik. Detta bidrar till en miljö där användare inte längre behöver installera en insticksmodul för att kunna exekvera och visualisera grafiskt material. Att rendera en karta på klientsidan genom att använda SVG-grafik eller via koordinater i ett canvas element kan på olika sätt belasta den mobila enhetens CPU och bör undersökas för bästa optimering gällande svarstider för respektive teknik.
Att använda sig av en applikation som kontinuerligt lokaliserar positioner med hjälp av GPS ökar snabbt batteriåtgången, detta går dock att reducera genom att använda lägre uppdateringsfrekvenser för GPS:en enligt, (Nawarathne, et al., 2014). Att använda lägre uppdateringsfrekvenser skapar dock ökade problem med signalbortfall vilket i sin tur kan leda till att noggrannheten vid positionsangivelser minskar. Detta bör undersökas vid utvecklandet av en applikation som kontinuerligt ska ange en golfspelares positions.
Den skillnad som kan uppstå vid användandet av olika mobila enheter kan bero på t.ex. ålder och/eller fabrikat och bör också jämföras. Att kunna ta del av golfbanor och dess utseende mobilt och samtidigt ha möjligheten att se sin position på banan är ett uppskattat hjälpmedel (Kim, et al., 2011). För att på bästa möjliga sätt få en upplevelse som motsvara de krav som finns, bör en optimering av grafisk rendering och information om geografisk position göras.
För att en sådan optimering ska kunna genomföras bör en jämförelse mellan de olika
teknikerna (SVG och canvas koordinater), samt batteriåtgång och noggrannhet hos GPS vid
olika uppdateringsfrekvenser utföras på olika fabrikat av mobiltelefoner.
3.3 Hypotes
Hypotesen är att svarstider vid rendering av vektoriserade kartor samt batteriåtgång minskar genom att använda canvas-koordinater och lägre uppdateringsfrekvens på GPS, utan att noggrannheten för positionsangivelser minskar.
3.4 Metodbeskrivning
3.4.1 Experiment
Experiment kommer att utföras för att kunna påvisa att svarstider för vektoriserade kartor samt batteriåtgång minskar vid användandet av canvas-koordinater och lägre uppdateringsfrekvens på GPS, utan att noggrannheten för positionsangivelser minskar. Ett flertal mätningar används i experimentet där variabler ändras och faktorer mäts för att sedan jämföras med en baseline. Så här säger Wohlin, et a,. (2012) om styrkan i att använda experiment:
Styrkan i ett experiment är att den kan undersöka i vilka situationer påståenden är sanna och den kan ge ett sammanhang där vissa standarder, metoder och verktyg rekommenderas för användning.
Wholin, et al., 2012, s 17
En applikation skapas där canvas-koordinater och SVG-grafik i form av golfbanor implementeras och renderas i en webbläsare på klientsidan med hjälp av HTML5 och JavaScript. Gränssnittet kommer att använda sig av W3C:s geografiska API som har till uppgift att återge en spelares position på den renderade golfbanan. Experimentet kommer att utgå från ett första fall av mätningar där en baseline skapas bestående av värden för renderingstid vid användandet av SVG-grafik, batteriåtgång samt noggrannheten vid positionsangivelse med hög uppdateringsfrekvens av GPS. Alla mätningar sker under en runda golf och under en förutbestämd tidsrymd. De värden som undersökningens baseline består av kommer sedan att användas för att jämföras med ytterligare ett antal mätningar där teknik för rendering bytts ut och uppdateringsfrekvens på GPS ändrats. Experimentet kommer att utföras på mobiltelefoner av och med fabrikaten/operativsystemen och webbläsare: SONY Z1/Android 5.1.1 och Firefox 46.0 samt IPHONE 6/iOS 9.1.1 och Firefox . Ett statistiskt värde kan sedan beräknas genom att jämföra de olika mätningarna. Genom att statistiskt säkerställa vilket val av renderingsteknik och parameterinställningar för uppdateringsfrekvens av GPS som ger bäst prestanda kan en optimering av applikation genomföras. Ett experiment i programvaruutveckling är enligt Wohlin, et al., (2012) en empirisk undersökning där manipulering av olika variabler sker på den undersökta modellen. Genom att ändra vissa variabler och hålla andra konstanta kan en effekt av utslaget mätas.
De variabler som kommer att mätas, ändras och jämföras är följande:
Renderingstiden för utritandet av golfbanegrafiken mäts vid användandet av SVG-
grafik respektive canvas-koordinater. Mätningarna ger totaltider för respektive
teknik som sedan används för att jämföra renderingshastigheten. Mätning utförs
med hjälp av en applikation som mäter hur lång tid det tar för en golfbana att
renderas vid användandet av de olika teknikerna, från att en begäran ges om att
ladda applikationen tills att det specifika objektet (golfbana) har exekverats.
Batteriåtgången hos de olika mobiltelefonfabrikaten mäts vid en parameterinställning för hög uppdateringsfrekvens respektive låg uppdateringsfrekvens på GPS. Mätningarna sker under en runda golf med förutbestämd tidsrymd. Mätningarna ger ett resultat över hur hög uppdateringsfrekvens motsvarande låg uppdateringsfrekvens på GPS påverkar batteriåtgången hos den specifika mobiltelefonen. Resultatet används sedan för att påvisa vilken inställning som ger upphov till minskad batteriåtgång, se exempelvis Nawarathne, et al., (2014). Mätningen sker visuellt genom att observera och notera mobiltelefonens batteriindikator vid golfrundans start och vid slutet av den förutbestämda tidsrymden för golfrundan. Problemet med att visuellt observera batteriåtgången via en batteriindikator är att den information som ges via en indikator inte alltid är helt trovärdig då det kan skilja sig mellan olika mobiltelefonfabrikat i vad en batteriindikator faktiskt visar och detta kan skapa en viss osäkerhet i resultatet. Dock ger jämförelsen ändå en viss antydan om vilken uppdateringsfrekvens som ger minskad battteriåtgång.
Noggrannheten vid positionsangivelser mäts med parameterinställning för hög uppdateringsfrekvens respektive låg uppdateringsfrekvens på GPS. Mätningen ger ett resultat över hur hög uppdateringsfrekvens motsvarande låg uppdateringsfrekvens påverkar noggrannheten vid positionsangivelser, se exempelvis Nawarathne, et al., (2014). Mätningarna sker under en runda golf med förutbestämd tidsrymd. För att en noggrannhet ska kunna uppmätas jämförs positionsangivelsen på en fristående GPS med positionsangivelsen på mobiltelefonen. Problemet med den här typen av mätning är att en nästan identisk runda golf behöver genomföras för att noggrannheten av positionsangivelserna ska kunna mätas på ett korrekt sätt och detta leder till en viss osäkerhetsfaktor.
Då experiment i sin verkliga miljö används för att undersöka vilken optimering som prestandamässigt fungerar bäst för applikationen kan det finnas ett antal problem som behöver deklareras. Enligt Wholin, et al., (2012) kan en av nackdelarna med att utföra experiment i sin verkliga miljö vara att resultatet kan variera beroende på experimentets omfång eller att experimentet utförs i en mindre kontrollerad miljö, vilket kan ge upphov till oförutsedda händelser som kan ha effekt på resultatet, men som kan vara svåra att utröna och förstå.
3.4.2 Alternativa metoder
De alternativa metoder som finns att tillgå utöver experiment är enligt Wholin, et al., (2012)
fallstudier, en studie som utförs för att studera en entitet i sin verkliga miljö inom en viss
tidsangivelse. Här samlas detaljerad data in från användare med hjälp av enkäter och deras
upplevelse om t.ex. utformning av kartor, klickbar information på banor, egenskaper för
zoom och positionsangivelse på bana. Insamlad information kan sedan ligga till grund för
förändringar vid val av teknik och parameterinställningar för att förbättra upplevelsen av
applikationen. Att genomföra en fallstudie för att ge svar åt vilken teknik eller
uppdateringsfrekvens på GPS som ger bäst prestanda eller minskad batteriåtgång är i den
här undersökningen inte nödvändig då appliceringen av vald teknik eller
uppdateringsfrekvens inte är kontextkänsligt. Dock kunde en fallstudie vara ett bra
komplement för att ytterligare utveckla en golfapplikation.
En användarstudie är en metod som skulle kunna användas för att få en klarare bild av vad som upplevs bra och dåligt ur en användares perspektiv. Att använda sig av en användarstudie i form av enkäter och intervjuer i den här undersökningen kan också vara ett bra komplement till experimentet då en användare kan uppleva prestanda på ett annat sätt än en utvecklare. Problemet kan dock vara att fokus hamnar på ”fel saker” om öppna frågor ställs till användaren. Detta är en metod som är tidskrävande och har ett behov av att ett tillräckligt stort antal personer inom rätt kategori studeras för att ett trovärdigt resultat ska kunna uppvisas.
Att skapa en simulerad miljö som ett alternativ till att gå runt på en golfbana är en alternativ metod till experiment. I fallet där svarstider vid användandet av canvas och SVG-teknik mäts och jämförs funkar en simulerad miljö bra. Men då batteriåtgången och noggrannheten vid positionsangivelser ska mätas och jämföras funkar det mindre bra då detta bör ske under verkliga förhållanden. GPS-koordinater ska hämtas in vid skiftande geografiska placeringar vid olika frekvenser och batteriåtgången kan då variera beroende på den geografiska positionens karaktär, detta gör att en simulering inte är aktuell för detta arbete.
3.4.3 Forskningsetik
I undersökningen måste testpersoner godkänna användandet av positionsangivelser i applikationen. Testpersoner kommer alltid att bli upplysta om att den deltar i en undersökning där data om dess geografiska position kommer att sparas och har då rätten till att avstå. Undersökningen kräver ett deltagande av testpersoner och att data samlas in, vilket leder till att information om användares geografiska positioner lagras för att senare användas för att jämföras med varandra. Dock kommer all data att avpersonifieras så att det inte går att härleda insamlad data direkt till någon specifik person. Data om någon specifik person kommer inte heller i någon form att publiceras i arbetet. Alla deltagare kommer tydligt att upplysas om och kan själva bestämma över sin medverkan. Vid medverkan godkänner alla deltagare att webbläsaren får tillgång till testpersonens geografiska position och att positionsdata sparas.
Återupprepning är en viktig del i undersökningen för att en god forskningsetik ska kunna uppnås. All källkod och anvisningar för hur applikationen har implementerats och hur undersökningen har genomförts återfinnas i arbetet. Den programkod som används baseras på öppen källkod och är tillgänglig för alla utvecklare/användare. Valet av geologiskt API, mobiltelefoner/operativsystem och webbläsare skapar en hållbar grund för undersökningen då de är vanligt förekommande hos utvecklare/användare men kan medföra problem då resultaten i undersökning ej bör kunna härledas till användningen av andra API:n, mobiltelefoner/operativsystem eller webbläsare. Att uppehålla objektiviteten i arbetet är dock en viktig del då ingen form av oredlighet får förekomma.
4 Genomförande
4.1 Förstudie
För att få idéer och inspiration till implementeringen av golfapplikationen genomfördes en förstudie. I ett första skede hittades inspirationen till arbetet genom artikeln ”Web GIS in practice VIII: HTML5 and the canvas element for interactive online mapping” av Boulos, et al., (2010) där författarna skapar en vektoriserad interaktiv karta utifrån ett mappgränsnitt baserat på HTML5. Artikeln ger en bra överblick och förståelse för hur skapandet av mer personliga kartor kan gå till och vad fördelen med att rendera dessa lokalt kan var.
För att kunna uppnå en god forskningsetik gällande upprepning av arbetet fanns ett egenställt krav om att skapa en oberoende, mindre resurskrävande applikation som lätt skulle kunna återskapas. För att uppnå dessa krav så lades fokus på att implementera applikationen i HTML5 och JavaScript. Att använda sig av ett geografiskt API som inte förknippas med eller utvecklats av ett specifikt företag var viktigt för att uppnå oberoende, valet blev då att använda W3C’s Geolocation API. W3C är enligt W3C (2016) en internationellt samverkande grupp där medlemmar, personal och andra intresserade jobbar tillsammans för att utveckla webbstandarder. För att bättre förstå hur det geografiska API:t fungerar har boken ”HTML5 Geolocation” av Anthony T. Holdener III (2011) varit en stor inspirationskälla.
Genom att observera utformningen av gränssnittet i applikationen OnTag Scorecard (2016) framkom en del idéer för applikationen. OnTag Scorecard implementerar ett Scorecard tillsammans med banguider och ett flertal funktioner bl.a. bokning av starttider. I applikationen har användaren även möjligheten att se avstånd till olika objekt på banan. Att snabbt kunna få information om olika avstånd ger även användaren en ökad upplevelse av applikationen.
Då arbetet till stor del baseras på att hämta information om geografiska positioner har Wikipedia (2015) varit till stor hjälp för att grundläggande förstå hur/vad det Globala Positions Systemet fungerar/är och om hur positionering med GPS och mobiltelefoner fungerar. Även D Roza och Bilchev’s (2004) artikel ”An overview of location-based services”
har gett en större förståelse för hur GPS data kan sparas, manipuleras och användas för olika typer av ändamål.
För att kunna rita ut en spelares position på en renderad golfbana krävdes det att de geografiskt angivna positionerna latitud och longitud konverterades till grafiska X och Y koordinater. Här har Anon 1 (2016) stackoverflow, varit till god hjälp för att finna en lösning på detta.
Då valet av teknik vid utritandet av de grafiska golfbanorna skulle kunna göras för applikationen, mättes och jämfördes renderingstider för olika renderingstekniker (SVG &
Canvas) under experimentet. I applikationen skapas ett objekt se figur 8, av en SVG-fil. För
att mätningarna på detta objekt skulle vara möjliga inhämtades kunskap om hur detta kunde
gå till. Med hjälp av JavaScript är det möjligt att plocka ut ett SVG element som befinner sig
inom en <object> tag, och här har Ben Frain (2016) varit till stor hjälp.
4.2 Applikationen
En golfapplikation där en spelares position återges på en renderad golfbana implementerades och optimerades efter resultat som framkom efter genomförda experiment. Experimenten genomfördes genom att mäta, ändra och jämföra olika paramerinställningar för bl.a. uppdateringsfrekvens på GPS och renderingstider för respektive renderingsteknik. För att experimenten skulle kunna utföras, utvecklades en prototyp till en golfapplikation byggd med HTML5, JavaScript och PHP.
Applikationen har till uppgift att hantera data om spelares geografiska positioner och visualisera dessa på en renderad golfbana. Genom att spara de insamlade geografiska positionerna vid olika typer av uppdateringsfrekvenser på GPS:en kunde en jämförelse sedan göras mellan de olika värdena. Information sparades även om den renderingstid som mätts upp för respektive renderingsteknik, allt för att kunna jämföra de olika tiderna med varandra. Applikationen ger användaren ett antal val där renderingsteknik, golfbana samt specifikt hål väljs. När specifikt hål valts renderas en vektoriserad bild av valt hål samt den geografiska positionen på banan. Information om avstånd till t.ex. bunkrar, vattenhinder och greener visas om spelaren väljer detta. I figur 7 återges bilder av applikationen under utvecklandet.
Figur 7 Bilder av applikationen under utvecklandet
4.3 Progression
Applikationen skapades först och främst för att användas på mobila enheter vilket ledde till att applikationen skulle kunna skalas och visa rätt proportioner oberoende av vilken storlek på mobil enhet som användaren valt att använda. Då utvecklandet av applikationen valts att göras utan inblandning av kostnadsalternativa företagsläsningar och istället på oberoende programkod behövdes detta göras manuellt genom att göra applikationen responsiv. Detta löstes till stor del genom att ange de flesta måttangivelser i programkoden till procentsatser istället för fasta mått. Procentsatserna skapar en miljö där skalningen av applikationen sker i förhållande till storleken till den mobila enheten.
En av de tekniker som användes för att rita ut golfbanorna i applikationen var SVG och detta gjordes till en början genom att använda JavaScript kommandot drawImage. Detta visade sig vara helt felaktigt då drawImage ritar ut pixelgrafik efter en angiven källbild. Källbilden kan vara en PNG, JPEG eller SVG-fil som t.ex. anges som källa i exemplet i figur 8. Värt att notera är att även om källan är vektoriserad så blir resultatet ändå i pixlar.
Figur 8 Funktion drawImage ritar pixelgrafik
För att kunna behålla SVG-koordinaterna, och på sätt även bevara bildens vektorgrafik och dess förlustfria skalbarhet blev lösning på detta att ett objekt av SVG-filen skapades.
Exemplet i figur 9 visar hur ett objekt elementet ser ut och hur deklarationen ser ut för typen av objekt i detta fall: image/svg+xml skapar en xml-fil med kod utifrån dataattributet.
Figur 9 Elementet objekt
Genom att skapa ett objekt av bilden läses filen in och konverteras till ett XML dokument innehållande SVG-filens stilmall och koordinater se figur 10. Att använda bildens koordinater skapar även bättre förutsättningar för att webbläsarens cache funktion sparar koden så att hastigheten för renderingen ökar till nästa tillfälle. Genom att använda SVG- filens struktur och element skapas även förutsättningen att med JavaScript manipulera och lägga till/ta bort element efter olika användarval.
function draw() {
var canvas=document.getElementById('canvas');
var context=canvas.getContext("2d");
var holeOne = new Image();
holeOne.src = 'courses/1.svg';
context.drawImage(holeOne, 0, 0);
}
<object id="svgpics" type="image/svg+xml" width="300px" height="500px" data=”courses/1.svg”>
</object>
[Exempel: progression och designval inom området grafik. Till en början användes ett
Figur 10 En skärmbild av SVG objektet
För att en markering av en spelares position ska hamna rätt på en helt fristående (ingen koppling i övrigt till något specifikt kartobjekt) karta av en golfbana krävs det att geografiska koordinater konverteras till pixelkoordinater se figur 11. Den utritade markeringen för en spelares position är en rent visuell effekt och har ingen som helst inverkan på renderingstiderna för de olika golfbanorna eller noggrannheten i de angivna geografiska positionerna som ska uppmätas. En markering av en spelares position sker helt fristående och har ingen direkt koppling till de objekt som används för att mätas på applikationen och har på så sätt ingen inverkan på det slutgiltiga resultatet av själva examensarbetet. Dock är det av största intresse att en korrekt markering av en spelares position går att utföra då användarupplevelsen ökar markant. Genom att anta att den projektion som används för visualiseringen av golfbanorna sker med termen Spherical Mercator vilket enligt Anon 2 (2016) i själva verket är en term som använts inom The Open Source GIS Community och beskriver projektionen av kartor som används av Google Maps, Microsoft, Yahoo och andra kommersiella GEO API leverantörer. Termen används för att beskriva när kartor behandlas som platta föremål. Med formeln för att konvertera en latitud och longitud position till pixel koordinater på en karta projekterade genom Spherical Mercator enligt figur 11 kan en position markeras. Dock baseras denna formel på att kartan som renderats centreras till den geografiska position som inhämtats.
Konvertering från geografiska till pixelkoordinater
Figur 11 Konvertering av geografiska koordinater till pixel koordinater
function plot (latitude, longitude) {
var longitude_shift = 0;//num, of pixels your map's prime meridian is offcenter.
var x_pos = 0;//if the map doesnt start at 0px x-position var y_pos = 0;//if the map doesnt start at 0px y-position var map_width = 300;
var map_height = 500;
// longitude: just scale and shift
var x = (map_width * (180 + longitude) / 360) % map_width + longitude_shift;
// latitude: using the Mercator projection
var lat = latitude * Math.PI / 180;// convert from degrees to radians
var y = Math.log(Math.tan((lat/2) + (Math.PI/4)));// do Merc. proj.(w/equator of 2pi units)
y = (map_height / 2) - (map_width * y / (2 * Math.PI)) + y_pos;// fit it to our map x -= x_pos;
y -= y_pos }
4.4 Pilotstudie
Vid pilotstudien användes applikationen för att spara och utföra mätningar. Genom att gå en bestämd sträcka på hål 1 och 2 på Mariestads Golfbana kunde att antal uppdateringar av den aktuella geografiska positionen göras. Geografisk data sparades från ett antal positioner utmed sträckan på banan (se figur 12), vid inställningar för både låg och hög frekvens på GPS. Insamlad data från respektive mätning (låg och hög frekvens) jämfördes med varandra samt med de geografiska koordinater som samlades in från den fristående handhållna GPS:en.
Figur 12 14st positioner där insamling av geografiska koordinater sker Då API funktionen watchPosition används för att kontinuerligt uppdatera en användares position, skapas ett möjligt problem med att inte kunna jämföra rätt positionsdata med varandra. Problemet kan vara att tidpunkten för positionsuppdateringar kan skilja sig åt beroende på t.ex. satellitåtkomst och signalstyrka. För att kunna jämföra noggrannheten av positionsangivelserna bör kanske data inhämtas på exakt samma ställe? Vid varje delposition på banguiden för hål 1 och 2 i figur 12 bör det kanske göras en manuell uppdatering av position? Som enskilda mätningar skapar detta inte något problem. Men då batteriåtgång även ska observeras vid låg respektive högfrekvent användande av GPS:en bör kanske insamlandet av batteridata göras under en separat runda utan manuella positionsuppdateringar? De inställningar som användes för låg respektive hög frekvens på GPS under pilotstudien visas i figur 13 och 14.
igh
Figur 13 Inställning för hög frekvens på GPS
Hål 1 Hål 2
var geo_optionsHF= {
enableHighAccuracy: true,//Demands best position available high use of GPS timeout : 45000,// Maximum length of time in ms, that the application will wait maximumAge: 60000// Accept a cached position , Max.age not more than spec. in ms };
Genom att i exemplet i figur 13 ange enableHighAccuracy: true talas det om att en positionsangivelse ska återges med största möjliga precision. Detta gör att användningen av GPS prioriteras. Hämtning av position kan ta längre tid och då ökar troligtvis även batteriåtgången. Timeout funktionen ger webbläsaren tid i millisekunder innan den anser att tiden för svar på positionsbegäran har gått ut och detta kan sedan behandlas på olika sätt. I detta fall görs det genom att tala om att en cachad position kan användas som inte har en mer än en max ålder på 60000 millisekunder. I fall där tiden gått ut för svar kan t.ex. en defaultHandler enligt figur 5 hantera vad som ska hända.
Figur 14 Inställning för låg frekvens på GPS
Genom att i exemplet i figur 14 ange enableHighAccuracy: false talas det om att en positionsangivelse ska återges på snabbast möjliga sätt. Detta gör att användningen av Wifi, GSM, Bluetooth eller IP/Mac-adress positionering prioriteras, hämtning av position går troligtvis fortare och batterianvändning minskar.
Den positionsdata som samlades in för låg och högfrekvent användande av GPS under pilotstudien återfinns i figur 15.
Hög Frekvens GPS Låg Frekvens GPS Longitude Latitude Longitude Latitude
Pos. 1 58,691 13,830 58,694 13,761
Pos. 2 58,691 13,830 58,694 13,793
Pos. 3 58,691 13,830 58,701 13,758
Pos. 4 58,691 13,830 58,701 13,758
Pos. 5 58,740 13,875 58,701 13,758
Pos. 6 58,694 13,793 58,701 13,758
Pos. 7 58,694 13,784 58,694 13,793
Pos. 8 58,690 13,763 58,694 13,793
Pos. 9 58,694 13,793 58,694 13,793
Pos. 10 58,694 13,793 58,694 13,793
Pos. 11 58,694 13,793 58,694 13,793
Pos. 12 58,694 13,793 58,694 13,793
Pos. 13 58,694 13,784 58,694 13,793
Pos. 14 58,690 13,763 58,694 13,793
N 14 14 14 14
Medel 58,696° 13,804° 58,696° 13,781°
Std Dev 0,013° 0,031° 0,003° 0,017°
P-Värde 96,81% 2,16%
Figur 15 Positionsdata från pilotstudien
var geo_optionsLF= {
enableHighAccuracy: false, //Demands quickest position available low use of GPS, first uses Wifi, GSM, Bluetooth or IP/Mac-adress
timeout : 45000,// Maximum length of time in ms, that the application will wait maximumAge: 60000// Accept a cached position , Max.age not more than spec. in ms
};
Genom att jämföra data som samlats in för låg respektive hög frekvens på GPS kunde en graf skapas som visar på skillnaden i noggrannhet, för longitud se figur 16 och latitud se figur 17.
Figur 16 Longitudskillnad mellan hög resp. låg frekvens på GPS
Figur 17 Latitudskillnad mellan hög resp. låg frekvens på GPS
För att mäta renderingstiden för SVG respektive Canvas-element användes funktioner ur API:t för performance timing se figur 18. Varje gång en ny golfbana renderades sparades renderingstiden i en extern textfil. Den data som sparats jämfördes sedan med varandra för att se vilken teknik som har snabbast renderingstid se figur 19.
Figur 18 Performance timing för SVG element
Figur 19 Renderingstider för SVG mot Canvas
var a = document.getElementById("svgpics");
// Get the SVG document inside the Object tag var svgDoc = a.contentDocument;
// Get one of the SVG items by ID;
courseRendTime = svgDoc.getElementById("Lager");
courseRendTime = + (window.performance.timing.loadEventStart - window.performance.timing.domLoading) + " milliseconds";
4.5 Konklusion av pilotstudie
Genom att studera den data som samlats in och de framställda grafer som utgör resultatet av pilotstudien kan det fastställas att de mätningar som utförts inte räcker till för att säkert kunna avgöra om det är någon skillnad eller inte i noggrannheten för positionsangivelser vid hög respektive låg frekvens på GPS, eller om det finns någon skillnad i renderingstid för SVG eller Canvasrenderad grafik. Dock är möjligheten till att mäta de önskade faktorerna fastställd.
Inför experimentet kommer ett antal variabler och faktorer att ändras för att säkerställa att rätt mätvärden inhämtas på ett korrekt sätt. Det antagande som gjordes under pilotstudien som innefattar idén om att manuella uppdateringar utav position kanske bör göras för att korrekt data från rätt position ska kunna jämföras med varandra visar sig vara felaktigt då tanken med arbetet bl.a. består av att se det geologiska API:ts noggrannhet vid positionsangivelser. Detta leder till att ingen manuell uppdatering kommer att göras under en ”mätrunda”. Alla delpositioner som mäts under en runda golf kommer att göras genom att manuellt spara det geografiska API:ts senaste positionsvärde när en delposition nås.
Värdet som sparas består av den senast automatiskt uppdaterade positionen. De värden som sparats kommer sedan att jämföras med både manuellt sparade värden vid olika inställningar för GPS frekvens, samt automatiskt sparade värden för senast uppdaterad position. På detta sätt är det möjligt att både jämföra skillnaden för noggrannheten vid olika frekvenser samt uppdateringsfrekvens (automatiskt sparade värden) och skillnaden i meter mellan positionsdata som sparats manuellt och positionsdata som sparats automatiskt. Detta kommer att redovisas ytterligare i avsnittet för experimentet.
Då experimentet ska kunna fastställa om det finns någon skillnad eller inte mellan de olika uppdateringsfrekvenserna vid positionsangivelser bör den senaste positionen som anges vara den absolut senaste och inte bestå av en cachad position som inställningarna i figur 13 och 14 tillåter. Inställningarna i figur 13 och 14 bör ändras och bestå av en variabel för timeout funktionen som ger API:t ökad tid till att utföra en positionsbegäran samt ett borttag eller att en ändring görs av funktionen maximumAge som tillåter en cachad position enligt exemplet i figur 20.
Figur 20 Ny inställning för villkoren i det geografiska API:t
Det sätt som används för att samla in mätvärden kommer att ändras inför experimentet.
Istället för att gå en sträcka från delposition 1 till 14 på hål 1 och 2 kommer hål 1:s delpositioner att mätas ett flertal gånger under ett visst antal varv. På detta sätt är det lättare att mäta skillnaderna i positionsangivelser och batteriåtgång för en individuell bana. Alla jämförelseberäkningar av de skillnader i latitud och longitudkoordinater som uppstår vid positionering kommer minst att bestå av 8 decimaler, och skillnaderna kommer sedan att presenteras i meter.
var geo_optionsHF= {
enableHighAccuracy: true,//Demands best position available high use of GPS timeout : 65000,// Maximum length of time in ms, that the application will wait //maximumAge: 0//
};
5 Utvärdering
5.1 Presentation av undersökning
Ett första steg i experimentet var att ta reda på de korrekta koordinaterna för hål 1:s delpositioner. Detta gjordes med en handhållen GPSmap 60CSx GARMIN se figur 21.
. Figur 21 GPSmap 60CSx Garmin
(http://www.materiel.net/gps/garmin-gpsmap-60csx-56581.html)
.
De koordinater som anges med en GPSmap 60CSx är av formatet ”Grader minuter.s” och behövdes först översättas till decimalformat då det geografiska API:t anger koordinater på sådant vis. För att konvertera användes formeln enligt figur 22.
Figur 22 Formel för ”Grader minuter.s” till decimalformat
Enligt Anon 2016, finns det 60 minuter i en grad och 60 sekunder i en minut; 3600 sekunder i en grad. Det finns 360 grader i en komplett cirkel eller sfär men i alla longitud och latitudmätningar är summan av de grader uttryckt som 2 halvor av 180 grader vardera.
Delpositionernas W/E/N/S° och decimalkoordinater återfinns i Appendix A.
Mätningarna skedde på Mariestads Golfbana över hål 1 och vid 5st delpositioner se figur 23.
Applikationen och en golfbil användes för att utföra mätningarna. Varje inställnings individuella mätning gjordes under 3st varv, a´15st delpositionsangivelser. Alla positionsangivelser sparades i en extern textfil. De värden som sparades återfinns i Appendix B. De olika faktorer och variabler som mättes var: SVG vid hög frekvens på GPS, SVG vid låg frekvens på GPS, Canvas vid hög frekvens på GPS och Canvas vid låg frekvens på GPS. Alla mätningar gjordes och sparades med webbläsaren Firefox 46.0 och med mobiltelefonerna SONY Z1/Android 5.1.1 samt en IPHONE 6/iOS 9.1.1.
Degrees Minutes.m to Decimal Degrees
.d = M.m / 60, Decimal Degrees = Degrees + .d
Figur 23 Delpositioner på hål 1
De sparade delpositionsangivelserna jämfördes sedan med de fastställda koordinaterna från den handhållna GPS:en. För att resultaten skulle vara tolkningsbara jämfördes noggrannheten vid de olika parameterinställningarna i meter. För att kunna göra detta behövdes en formel som konverterade koordinater till meter och som hade förmågan att avgöra avståndet mellan två olika positionsangivelser. Den formel som användes för att göra detta är en excelformel som översatts från en JavaScriptsfunktion baserad på ”Haversine” - formeln som kalkylerar ”cirkel” -avståndet mellan två punkter, den kortaste distansen över jordens yta ”fågelvägen”. Excelformel återfinns i figur 24.
Figur 24 Excelformel baserad på Haversine-formeln
(http://bluemm.blogspot.se/2007/01/excel-formula-to-calculate-distance.html)
Alla delpositioner mättes med de förutbestämda parameterinställningarna och noggrannheten jämfördes sedan med positionsangivelserna från den handhållna GPS.en, se tabellexempel i figur 25. Alla tabeller finns att beskåda i Appendix C.
=ARCCOS(COS(RADIANER(90-Lat1))*COS(RADIANER(90-Lat2))+SIN(RADIANER(90-Lat))*SIN(RADIANER(90- Lat2)) *COS(RADIANER(Long1-Long2))) *6371000 //Jordens meridian i meter
OneFive OneFour OneThree
OneTwo
OneOne
