GPS logg fråga

[jester]

Hoho, jag har ett väldigt logiskt svar… Roade mig med att summera dom markerade raderna, och fick dryga 240m… Då räknade jag antal markerade rader, och dom är 11 stycken! Så programmet verkar måla upp en rad för mycket, helt enkelt (den sista raden).

[marden]

hoho …kan jag få ett logiskt svar varför den sista ska bort i första bilden och den första i den andra bilden då ?….

[mattias-j]

Men “min” (minimum) hastigheten i summeringen visar ju att 39,071 visst är med. Kolla i de nedre rutorna. Max visar 45 någonting men min visar ju 39 repan….?

[mattias-j]

Och exakt Mården, smaka på den….?

[jester]

Kollade bara på den första bilden. Maila Manfred för bättre svar, kanske?

Sent from my GT-I9100 using Tapatalk

[jester]

Mattias J;678620 wrote:

Men “min” (minimum) hastigheten i summeringen visar ju att 39,071 visst är med. Kolla i de nedre rutorna. Max visar 45 någonting men min visar ju 39 repan….?

Detta är ju antagligen samma bugg som gör att det ritas upp 11 rader, iofs. Men det märkliga är att jag får det inte rätt ens om jag summerar dom 10 bästa raderna. Kör du senaste versionen av programmet?

[mattias-j]

Japp, senaste programvaran. Kan det vara så att den använder 0,5 sec av översta och 0,5 sec av understa och att den därför visar 11 rader. Jag får inte heller siffrorna att stämma. Men det är ju bara doppler, vilket är 1 track per sekund…

[jester]

Mattias J;678661 wrote:

Japp, senaste programvaran. Kan det vara så att den använder 0,5 sec av översta och 0,5 sec av understa och att den därför visar 11 rader. Jag får inte heller siffrorna att stämma. Men det är ju bara doppler, vilket är 1 track per sekund…

Ja, vi skyller på doppler… 🙂

[mattias-j]

Så får det bli, den där jä..la Doppler 😀

[platon]

Kan inte hela gåtan men att det är 11 rader för 10 s är väl att första raden är 0s, andra raden 1 s osv…upp till 10s, alltså 11 rader.
Den borde sedan ta medelvärde för första och andra raden, andra o tredje, tredje o fjärde. Blir då 10 värden, en integral helt enkelt
/P

[mattias-j]

Visst är det en integral, men det förklarar fortfarande inte varför programmet inte plockar de bästa raderna. Borde ju börjat med noll en eller t.o.m två rader upp…

[klang]

I samband med att jag lekte med ett eget web-baserat “GPS result” så upptäckte jag just det här fenomenet. Min lilla php-snutt har inga problem med att hitta den bästa 10s, men om jag gör ett medelvärde för dessa 10 sample så får jag inte samma resultat som GPS results. Efter att provat alla möjliga varianter med interpolation etc så gav jag upp och skickade frågan till Manfred.

Tydligen så använder GPS results 11 samples och skapar en cubic spline, kolla upp det på Wiki:n om ni känner för att brottas med lite matematik. Oavsett så är syftet att skapa en “bågformad kurva” genom alla punkterna, d.v.s man estimerar helt enkelt hastigheten mellan de samplade tidpunkterna med antagandet att hastigheten förändras mjukt och fint enligt en viss funktion.

En smart idee, men det öppnar samtidigt upp för en frågeställning. Ska jag publicera mina resultat igen när jag uppgraderat till en ny version av GPS results? Finns det något annat program som har andra algoritmer som approximerar annorlunda och ger ännu bättre resultat?

Om man approximerar hastigheten mellan punkterna annorlunda kommer sålunda resultatet också bli annat. Jag kan tycka att det kanske borde vara på sin plats att “standardisera” algoritmerna som används… eller är det endast GPS results som är tillåtet för att publicera sina resultat?

Eller, om jag nu skulle hacka ihop ett program som approximerar hastigheten lite mer “positivt” antar jag att det skulle bli en stor säljare… 😉

[glader]

Mattias: Är inne på Platons linje och tycker att resultatet ser logiskt ut. Med cubic spline så blir det säkert rätt, orkar inte räkna ut det, men även med en enkel medelvärdesberäkning är det logiskt. Sekunden 08:28:21 till 08:28:22 har medelhastighet (40.179 + 40.918) / 2 = 40.548. Sekunden 08:28:31 till 08:28:32 har medelhastighet (42.279 + 39.071) / 2 = 40.675. Tror att man måste ha en ganska udda beräkningsmetod för att samplet 08:28:21 skall tas med. Grunden för en rimlig metod bör vara att ändpunkterna inte viktas lika mycket som en punkt i intervallet. Med det följer att man vinner mer på att ha 08:28:31 inne i intervallet än man förlorar på att byta ändpunkt från 08:28:21 till 08:28:32.

Klang: Visst är det väl så att GPS-speedsurfing måste godkänna programvaror som används? Rimligen är val av algoritm för uppskattning av hastighet del av processen. Men visst, ett program som ger högre speed skulle säkert vara en storsäljare 🙂 Själv skulle jag behöva 5-6 knop extra för att komma upp i Mattias fina exempel.

[mattias-j]

glader;683544 wrote:

Mattias: Är inne på Platons linje och tycker att resultatet ser logiskt ut. Med cubic spline så blir det säkert rätt, orkar inte räkna ut det, men även med en enkel medelvärdesberäkning är det logiskt. Sekunden 08:28:21 till 08:28:22 har medelhastighet (40.179 + 40.918) / 2 = 40.548. Sekunden 08:28:31 till 08:28:32 har medelhastighet (42.279 + 39.071) / 2 = 40.675. Tror att man måste ha en ganska udda beräkningsmetod för att samplet 08:28:21 skall tas med. Grunden för en rimlig metod bör vara att ändpunkterna inte viktas lika mycket som en punkt i intervallet. Med det följer att man vinner mer på att ha 08:28:31 inne i intervallet än man förlorar på att byta ändpunkt från 08:28:21 till 08:28:32.

Klang: Visst är det väl så att GPS-speedsurfing måste godkänna programvaror som används? Rimligen är val av algoritm för uppskattning av hastighet del av processen. Men visst, ett program som ger högre speed skulle säkert vara en storsäljare 🙂 Själv skulle jag behöva 5-6 knop extra för att komma upp i Mattias fina exempel.

Tack, Glader! Givetvis har du rätt, vad enkelt det blev när man ser det så 😀 Ibland kan man ju ha otur när man tänker….