turistautak.hu térképrészleteK+ jelzés GPS-szel
[ english
Előzmények

Tisztul_A_Visztulahozzászólásai | válasz erre | 2010.05.11 02:27:40 (48845)
Asszem én is negatív alak vagyok, mert nem hagylak élni...

Szóval bringázgatok a korábban említett útvonalon, de most jellemzően az emelkedő különböző pontjairól fordulok vissza [lehet fikázni :-), de jellemzően asztmatikus köhögés mellett:-( ]
A korábban említett magassági torzításon már túltettem magam, viszont indirekt módon újból belefutottam. A progimmal a grade-et nézegetem mostanában, de minden ilyen túra végén a Gauss féloldalassága kihat erre is, hiszen a trendszerű emelkedőn a track végét csillapítja. Ha nem vágnám szét két részre a visszafordulásnál, még rosszabb lenne a helyzet.

Egyébként olyan 8-10%-ról van szó, amit az utolsó 100 méteren fokoyatosan tompít le 3-3,5%-ra tévesen.

Továbbgondolva, a vissza nem fordulások esetén általában azért nincsen gond, mert egyrészt a természet általában ívelt (legalábbis belföldön még a hegycsúcsok sem annyira "hegyesek", másfelől az útépítők sem építenek ugratókat. A horhosok és bevágodásoknál már inkább elveszik pár méternyi "mélység" a Gauss miatt, de hát egy völgyben amúgy is rosszabb a vétel, tehát ott ez kisebb hiba, mint ami a vétel pontatlanságából jön.

Egyelőre úgy tompítottam a dolgot, hogy a Gausst levettem 100 méterről 50-re, aminél szerintem általában már felülbecsüli 10-15 méterrel a szintemelkedést, de aztán eszembe jutott, hogy a tükrözés mellett megoldás lehet(ne) az hogy ha nemcsak nem távolság alapú, hanem trackpontszám alapú Gauss-t is lehetne választani.

Az ajánlott 100 méteres esetén kétszer kb 25-30 pontot használ fel a tipikus 3-4 méteres távolság alapú trackelési beállítás mellett, azaz 50 méternél már csak ennek a felét. Ez még bringánál is igaz, hiszen 8-10%-nál nem jellemző a 15km/h-nál nagyobb sebesség felfelé.

Még egy dolog szól a pontszám mellett (akár kizárólagosan, akár szűrőként lenne használva).

Jómagam ugye jelenleg 1,5 méterest használok, tehát gyakorlatilag másodpercest. Ez lefelé nagy sebesség mellett már csak 7+7 ponttá (100m, 50-51 km/h) redukálja a Gauss-hoz használt pontokat, amikor a nagy sebesség amúgy is pontatlanabb vétellel jár(hat) együtt, míg síkon meg, amikor feltehetően jobb a vétel, dupla annyi pontot használ.

Tehát miért nem azt lehet beállítani, hogy

A) Hány pontot használjon fel előtte (ha van) és utána (ha van)

Vagy ami még jobb lenne

B) A mostani Gauss sugárt használva , DE MAXIMUM hány pontot használjon fel előtte (ha van) és utána (ha van)?

Így ha van nagy sebességű szakasz, akkor a Gausst nagyobbra veszem (pl 200m-re), de a pontok számának megadásával biztosítom, hogy csak nagy sebesség mellett legyen ez a sugár az effektív. Ha nincs ilyen kilógó száguldás, akkor elég a 100 m, s ha emellett trendben indulok vagy végzek, akkor alacsony pontszámmal csökkentem a hibát, máskülönben meg megadok rá egy nagy pontszámot, ami nem jelent effektív korlátott.

Még azt is látom magam előtt :-), hogy a három user profil pont alkalmas lenne erre a három esetre. Nem akarok tolakodó lenni, de talán ez a megoldás nem is jelentene akkora bonyolítást.

Na, egyelőre ennyi.
[előzmény: (47712) jekaeff, 2010.03.26 19:34:44]

jekaeffhozzászólásai | válasz erre | 2010.03.26 19:34:44 (47712)
Meg lehetne próbálni a track 1. pontja előtti "R" (Gauss sugár) távolságra behazudni az első "R" méternyi szintprofil vízszintesen majd függőlegesen tükrözött szakaszát. Így a lejtő elé egy hasonló meredekségű lejtőszakasz kerülne, emelkedő esetén hasonló meredekségű emelkedő, sík esetén pedig hasonló jellegű sík szakasz.

De szerintem nem akarok ilyesmit... :o)
[előzmény: (47711) Tisztul_A_Visztula, 2010.03.26 19:23:23]

Tisztul_A_Visztulahozzászólásai | válasz erre | 2010.03.26 19:23:23 (47711)
2. Igen.
[előzmény: (47709) jekaeff, 2010.03.26 19:11:59]

jekaeffhozzászólásai | válasz erre | 2010.03.26 19:11:59 (47709)
1.) 13+10. De nem hinném, hogy ez okozza. Ha pl. ReadLn-nel olvasod a sorokat, a Lazarus jól kezeli a UNIX és a DOS újsort is.

2.) Ha meg síkon kezdesz akkor meg ez pont nagyon jó. Nemigen lehet máshogy megoldani elegánsan. Ha pl a legelső pontot magasságát meghosszabbítanám a 0. méter előtti Gauss-sugárnyi távolsággal (tehát pl -150 és 0 méter távolságot feltölteném a startpont magasságával), akkor ez valamennyire ellensúlyozná ezt a hatást ha lejtővel/emelkedővel indítasz, viszont ha pl sikon mész az elején és az első pont magassága nagy hülyeség, akkor ezt a hülyeséget túlhangsúlyoztatod az algoritmussal, és jó darabig érezteti majd a hatását a track elején.
[előzmény: (47707) Tisztul_A_Visztula, 2010.03.26 19:05:55]

Tisztul_A_Visztulahozzászólásai | válasz erre | 2010.03.26 19:05:55 (47707)
1. Én 13+10-zel emelem a sort. Az "IS" mire vonatkozik: arra ,hogy 13 és 10 van, vagy van más sorvége karakteed is???
2. Igen, de ha egy emelkedőn kezdesz, akkor egyből felrántja az elejét pár méterrel, ha meg lejtőn, akkor lefelé. Ugyanez igaz természetesen a végén is. De egyelőre nincs ötletem, hogy hogyan csinálnám jobban.
[előzmény: (47705) jekaeff, 2010.03.26 18:57:34]

jekaeffhozzászólásai | válasz erre | 2010.03.26 18:57:34 (47705)
1.) Lehet, hogy a soremelések zavarják az edzéspartner progidat ($0D és $0A is van nálam, tehát nem unix-os soremelés van, hanem dos-os). Vagy hogy nincs tracknév.

2.) Szándékos. Persze ilyenkor csak az utána következő magasságadatokkal átlagol. Az ok, ha mentegetni akarom magam: lusta kesser, aki nem nem törli az esetleges magasságtüskét (autokalibráció) a track elejéről. Egyébként miért pont erre a trackpontra ne vonatkoznának a szabályok? Az utolsó trackpont(ok) hasonlóképpen vannak kezelve, olyankor viszont csak a "múlttal" tud átlagolni a Gauss szűrő, a track végéhez érve egyre kevésebb "jövőbeli" trackpontot tud használni.
[előzmény: (47704) Tisztul_A_Visztula, 2010.03.26 18:50:13]

Tisztul_A_Visztulahozzászólásai | válasz erre | 2010.03.26 18:50:13 (47704)
OK, egyáltalán nem sürgős.

Nézegetve a kimenetet két dolog merült fel bennem.

1. Az edzés partnerem valamiért nmem szereti a geenrált fájlt. Mivel viszont a mapsource is beolvassa, ezért nekem kell megfejtenm a dolgot.

2. Már az első trackpont magasságát is lényeges befolyásolja a Gauss simítás. Ez szándékolt volt vagy csak nem gondoltál bele és az algoritmus "mindenkire" vonatkozik. Egyébként az automatikus barometrikussal kb 1,5-2m-t változtat.
[előzmény: (47703) jekaeff, 2010.03.26 18:46:27]

jekaeffhozzászólásai | válasz erre | 2010.03.26 18:46:27 (47703)
Nem ugyanaz okozza a nullával osztást, hanem a a lejtő-emelkedőszállítás miatt bekerült egyik új sor. Majd javítom, de ma már nem lesz rá időm valószínűleg.
[előzmény: (47701) Tisztul_A_Visztula, 2010.03.26 18:23:55]

Tisztul_A_Visztulahozzászólásai | válasz erre | 2010.03.26 18:23:55 (47701)
Az adatkiírás korrektnek tűnik, mert egybevetettem a kiírt fájl szintvonalát a kiírandó fájl Gauss vonalával és nem látok különbséget.

Viszont ebben a bétában nem jó, az, ami már a legutolsó nem bétában ki volt javítva, jelesül: ha a vertikális 0 méterre van állítva, akkor hibát jelez (=Access Violation)
[előzmény: (47689) jekaeff, 2010.03.26 10:34:51]

jekaeffhozzászólásai | válasz erre | 2010.03.26 10:34:51 (47689)
A mostani bétát is javítanom kell majd, ha hazaértem. Az egyik teszt-trackre nullával osztást írt. A lejtőmegállapító algoritmus a ludas, mert a meredekségi küszöböt állítva megszűnik a hiba. Lehet, hogy egyúttal külön kapcsolhatóvá is teszem a lejtőket jelző csillagozást, és így te is megnyugodhatsz, hogy nem rondítja el a Gauss-t (náha már fontolgatom, hogy nem is kéne ez a lejtő izé, vagy kell, csak jelölni nem kéne a grafikonon).

Pomáz-Dobogókőnél a távot sem ismerem, nem csak a bejárás módját. Így ha pl. 7 perces az útvonal, akkor a 6p34mp elég szép javulás.
[előzmény: (47688) Tisztul_A_Visztula, 2010.03.26 10:29:11]

Tisztul_A_Visztulahozzászólásai | válasz erre | 2010.03.26 10:29:11 (47688)
1. Jogos.

2. Nem is kérdezted, hogy mivel. Gyalog nem lett volna nagy kunszt. :-) Autóval meg felelőtlenség lett volna :-)) Sível meg esélytelen :-)))

3. Szintén jogos, tényleg ott van a záró nulla hetedikként. Az ele-s nyomozásom rémlett, s ráhúztam a gpx-ben lévő trekkpontok koordinátáira is.

4. Csakhogy bonyolódjon, a wpt-nél viszont Mapsource-szal szerkesztés után ugye 0 tizedesjegyű lesz az ele. Hála istennek a wpt-k latlon-ja még a Mapsource-szal szerkesztés után is 7 tizedesjegyű. Igaz ez akkor is, hogy ha a Mapsource csak 5-öt jelenít meg. Szóval Garmin=0 vagy 3 vagy 5 vagy 6 vagy 7.
[előzmény: (47683) jekaeff, 2010.03.25 22:23:14]

jekaeffhozzászólásai | válasz erre | 2010.03.25 22:23:14 (47683)
1.) Lehetne, de akkor megint ott lennék ahol a part szakad: most akkor melyiket tartsam élőn, melyik az igazi? :o) Azért a legutolsó bétából indultam ki, mert úgyis ebből lesz a következő hivatalos release.

2.) Dömdömöm... :P Akarommondani gratula! :o)

3.) Én egy memóriakártyás GPX fájlból néztem. Szerintem belső memóriában 32 biten tárolja a Lat/Lon/Ele-t, ezért mindhárom 7 tizedesjegyig látszik. Memóriakártyán: Lat/Lon: 6 tizedes, Ele: 3 tizedes.
[előzmény: (47682) Tisztul_A_Visztula, 2010.03.25 21:55:45]

Tisztul_A_Visztulahozzászólásai | válasz erre | 2010.03.25 21:55:45 (47682)
Kosz, holnap megnezem. Nem lehet amugy siman atmasolni a betabol az ujdonsagokat a nem betaba? Marmint csak azt, ami a fajlkiirasrol szol.

Egyebirant ma elesben teszteltem az Edzo Partneremet es ennek koszonhetoen 6p34mp-cel meg is dontottem a Pomaz-Dobogoko tavot.

Harmadsorban meg a masik hsz-odra reagalva, nem 7 tizedesjegyig tarol a 60csx? Marmint a belso memoriaba, hiszen a kartyara csak 3-ig. 6 nekem nem remlik, de mar ma este nem tudom leellenorizni.
[előzmény: (47675) jekaeff, 2010.03.25 20:14:26]

jekaeffhozzászólásai | válasz erre | 2010.03.25 20:14:26 (47675)
Tisztul_A_Visztula!


SRTM_HUN béta, Gauss-simított track mentéssel kiegészítve:

http://data.hu/get/2378389/SRTM_HUN_20100325beta.exe.html (Ingyenes -> Nem élek vele -> Letöltés indítása)

Teszteld.

Megjegyzések:
- Érdemes a meglévő SRTM_HUN könyvtárába másolni a NEM_BÉTA mellé, ha route-ot is akarsz feldolgozni vele (ebben nincs benn a nagy SRTM datbázis, csak a főprogram)
- A Gauss simítási grafikon nem a megszokott, a legutóbbi tesztverzió miatt itt piros-kék-sárga csillagok rondítanak bele amik az emelkedést-lejtést-síkot jelzik (ezért egyelőre érdemes megtartani a NEM_BÉTÁT)
[előzmény: (47643) Tisztul_A_Visztula, 2010.03.25 13:02:06]

Tisztul_A_Visztulahozzászólásai | válasz erre | 2010.03.25 13:02:06 (47643)
Na ez az, a mutatókat nincs kedvem újból megtanulni.
[előzmény: (47642) jekaeff, 2010.03.25 12:48:30]

jekaeffhozzászólásai | válasz erre | 2010.03.25 12:48:30 (47642)
Majd megnézem ma otthon, ha tényleg olyan 5 perces meló mint amire gyanakszom, akkor a legutóbbi félkész bétát kiegészíthetem vele, és felrakhatom valahová...

(Nem olyan nehéz ám az a Gauss simítás, akár még te is be tudnád építeni a programodba. Persze kicsit macera, hogy előtte be kell olvasni a track összes pontját egy láncolt listába, hogy egy adott pontnak ismerd az R-sugarú "környezetét" amire a Gauss-nak szüksége van.)
[előzmény: (47641) Tisztul_A_Visztula, 2010.03.25 12:27:31]

Tisztul_A_Visztulahozzászólásai | válasz erre | 2010.03.25 12:27:31 (47641)
Nekem jól jönne 3D-s távolságszámításhoz a másik progiban illetve a Garmin Training Centerbe.
Az SRTM-et túratervre használom főleg, illetve túra után magasságellenőrzésre. Ha két progi lesz belőle, az nekem csak picit plusz macera, ha egy marad, az picit jobb.
[előzmény: (47634) jekaeff, 2010.03.24 21:48:36]

jekaeffhozzászólásai | válasz erre | 2010.03.24 21:48:36 (47634)
...egyébként vmi Oregonos fórumban mintha én is olvastam volna ilyen igényről. Szerintem ez annyira kilóg az SRTM_HUN "profiljából", hogy inkább külön programot érdemelne (kiollózva a Gauss simítást a programból egy újba). Hiszen akinek ilyesmi kell, annak nem sok szüksége van a program egyéb tudására, akinek meg szüksége van azokra, annak meg ez a felesleges.
[előzmény: (47633) jekaeff, 2010.03.24 21:32:57]

jekaeffhozzászólásai | válasz erre | 2010.03.24 21:32:57 (47633)
- Amit NAGYON könnyen meg lehetne csinálni (szerintem pár perc alatt, de persze ennek még utána kéne nézni) az az, hogy egyetlen track jelenjen meg kimenetként egy GPX-ben, amiben a simított magasságok szerepelnek.
- Picit macerásabb lenne, ha ezen felül még a waypoint-ok is kellenek.
- Még macerásabb lenne, ha több track-et tartalmazó gpx fájlnál ne egyesítve jelenjen meg az output egy track-ként, hanem megmaradjanak az eredeti track-határok (de ekkor is csak azok a track-ek szerepelnének az outputban, amiket feldolgozásra kijelölt a felhasználó).
[előzmény: (47631) Tisztul_A_Visztula, 2010.03.24 20:39:31]

Tisztul_A_Visztulahozzászólásai | válasz erre | 2010.03.24 20:39:31 (47631)
Ha már SRTM_HUN....
Lenne még egy felhasználói igény, szerintem ez nem nagy ügy. Megtudnád csinálni - amikor majd persze lesz kedved :-) - hogy a progi kimenetként legyártsa azt a gpx-et, ami teljesen megegyezik a bemenetivel, kivéve a trekkpontok magasságát, mert ez esetben a simított adat lenne kiírva?
Szerintem ezt én is könnyen meg tudnám csinálni benne, de nem szívesen járnék úgy, hogy egy másik jövőbeni feature miatt egy másik példányt kelljen használni. Neked meg ez szerintem nem több mint félóra. Ha tévednék, csak szólj, s akkor mégis nekiállok én.
[előzmény: (47604) jekaeff, 2010.03.24 06:53:48]

jekaeffhozzászólásai | válasz erre | 2010.03.24 06:53:48 (47604)
No megállj csak! :o)))

Nálam nincs magasságadat meg távolság se (ezek legalább +2 perc melót jelentenének). Viszont a trackpontok gyakorisága mindegy, MÚKODIK akárhány másodperces trackpont-távolság esetén is: szükség esetén két pont közé legenerálja a waypoint-okat (időarányos távolságban).
[előzmény: (47603) Tisztul_A_Visztula, 2010.03.24 02:04:44]

Tisztul_A_Visztulahozzászólásai | válasz erre | 2010.03.24 02:04:44 (47603)
Én is kész vagyok az első verzióval. Most terveztem meg a következő menetet holnapra: a kiírt időpontok mellett a név második felébe ciklusosan kerüljön be mindig a benchmark track magassági adata (ez nudli), majd a megtett távolság (ez már komolyabb, vagy lesek rólad vagy küzdök) illetve az átlagsebesség.
Tehát pl ........"0:40:05 h=455m", "0:40:10s=13.67","0:40:15 v=20.0","0:40:20 h=457m"....

Milyen SRTM_HUN?
[előzmény: (47595) jekaeff, 2010.03.23 19:39:45]

jekaeffhozzászólásai | válasz erre | 2010.03.23 19:39:45 (47595)
Tisztul_A_Visztula!

Kész vagy ezzel az egyedi waypoint-os edzéstrainer funkcióval?
Nekem sikerült 3 óra alatt összedobnom egyet (csak hogy ne az SRTM_HUN-n kelljen rágódnom). :o)
[előzmény: (47475) Tisztul_A_Visztula, 2010.03.20 22:43:58]

Tisztul_A_Visztulahozzászólásai | válasz erre | 2010.03.20 22:43:58 (47475)
Marianna-árok? ;-)

4. Így hogy leírtad a kulcsszót, egyből rájöttem, hogy a Forerunner-ek (vagy közülük néhány) is tudja a Virtual partner-t. A pár youtube videó inkább a paraméterezett ellenfelet mutatja be, így nem derült ki, hogy pontosan hogyan néz ki a korábbi trekkel versenyzés.

Viszont rátaláltam újból a Training Center ingyenes Garmin programra, ami a közelmúlt egyik verziófrissítése óta már elfogad gpx-et is az importban, így utólagosan lehet nézegetni idő vagy távolság függvényében a magasságot, sebességet, emelkedés szögét, sőt mindezt két trekknél is, kivéve szöget. Hogy miért nincsen idő függvényében távolság, az rejtély. Cooper-teszthez pl. nem az kellene??? Márcsak hogy a fitness témánál maradjak, s ne csix-esként érveljek.

Sőt rájöttem, hogy hogyan fogom megoldani egy egyszerű ötlettel fapadosan az edzéspartnert. Nézzük, miből élünk:

a) Akár 1000 útpont is belefér a csix-be.
b) Amikor az ember tesztpályán (nálam Pomáz-Dobogókő hegytető) kerekezik vagy fut, akkor a térképet úgysem kell bámulni
c) A Lazarussal egyszer már megbirkóztam a waypoint desc és cmt mezőinek buherálása kapcsán.

Tehát bemeneti képernyőn a betöltendő gpx (útpontok nélkül, ha van, akkor az nem kerül megőrzésre) illetve a "km kövek" sűrűsége mp-ben. Ha pl. 10 mp, akkor a trackpontok beolvasása alapján létrehozza az útpontokat a megfelelő helyen "00:00:10", "00:00:20"... névvel (mondjuk akár egy külön gpx-ben, amit Mapsource-szal betöltök a csix-be) amit kerekezés közben a csixet 5 m-re állítva már elég jó képet kapok arról, hogy hogyan állok. Annyi a dolgom, hogy a Trip Computer és a Map page között ugrálok, ha érdekel a dolog.

Természetesen el lehet játszani, hogy ha valamiért nem minden másodpercben van adat, akkor mit csináljon (de azt is lehet, hogy edzéskor az ember mindig 1 mp-ű rögzítésre állít). Vagy azzal, hogy beolvasás után megnézze, hogy a track milyen hosszú mp-ben és ezt elosztva a megadott sűrűséggel nem kapunk-e véletlenül 1000-nél nagyobb számot.

No, milyen ötlet?

Megj.: rally üzemmódra nem javasolt, sem az 5m-es zoom miatt, sem pedig a kijelző nézése és képernyők közötti váltások mint követelmények miatt.:-) Bár mitfahrer-rel egy kicsit más zoom-mal még erre is alkalmas lehet. :-))
[előzmény: (47473) jekaeff, 2010.03.20 21:43:41]

jekaeffhozzászólásai | válasz erre | 2010.03.20 21:43:41 (47473)
De vajon miért 31504 métert akarnának ábrázolni?

Gondolom volt egy kitűzött cél, hogy mekkora tartomány ábrázolására lenne szükség.
Legyen lehetséges egy kevés negatív tartománybeli ábrázolásra (Holt tenger: -418m) meg jó sok pozitív tartománybelire. Jókora ráhagyással úgy gondol(hat)ták, hogy legyen kb. 3x-os plusz tartomábny mindkét irányba a föld legmélyebb és legmagasabb pontjához képest. Tehát legyen -1500m és +30000m a két szélső érték.

Viszont jó lenne ezt a tartomány minél kisebb helyen tárolni. Lebegőpontosként illene mindenképp vagy 4 bájtot elpazarolni minden egyes magasságponthoz. Ráadásul macerás és időt rabló lebegőpontos számokkal dolgozni.

Nosza, akkor ábrázoljuk 2 bájton, így 65536 különböző magasságot rögzíthetünk, fél méternél is finomabb felbontással.

Tehát:
Magasság = Tárolt érték * (31500 / 65536) - 1500
[előzmény: (47471) Tisztul_A_Visztula, 2010.03.20 21:21:29]

Tisztul_A_Visztulahozzászólásai | válasz erre | 2010.03.20 21:21:29 (47471)
1. Ez az én trükköm! :-)

2. Nagyon szép próbálkozás, de a helyzet az, hogy 0,4807129-et keresünk. :-)

Egyébként 31504-et elosztva egészen pontosan megkapjuk a számomat. Javítsd ki a progit! ;-) Mindenesetre 1000 hála, ha igazad van, én már nagyon befixáltam az agyam a barometrikus lépésközbe. De vajon miért 31504 métert akarnának ábrázolni? Tuti, hogy a légnyomás nem játszik? Ne felejtsd el, hogy nagyobb lépések esetén nem pontosan 2-szeres vagy 6-szoros a differencia.

4. Utánanézek...

5. Nem mondtam, hogy én fel bírok tekerni 10 fokon (ha jól emlékszem, 17% körül lehet), viszont 50-nel képes vagyok lejönni egy ilyen lejtőn :-). De mondokk egy életszerű példát: a Holdvilág-árokban lendületesen fellépdelsz a létrán pár mp alatt. A progi szerint 0,1 km/h alatt marad a sebességed, viszont a vertikális sebesség miatt valójában akár 1,8-2-vel is repeszthetsz a valóságban.
[előzmény: (47467) jekaeff, 2010.03.20 19:35:03]

jekaeffhozzászólásai | válasz erre | 2010.03.20 19:35:03 (47467)
Tehátakkorlá suk!

1. Dömdödöm.

2. Volt egy gyanúm, és úgy látom bejött. A megoldás ott található a GMXT2GPX nevű programomban: 31500/65536=0.48065185546875... És még annyit megsúgnék hogy -1500-tól +30000m-ig képes ábrázolni a magasságot a Garmin ezzel a két bájtosan tárolós trükkel.

3. Mér hőmérsékletet, bár az mintha a belső kvarc frekvenciakorrekciója miatt kéne neki, hogy pontosabb tudjon lenni.

4. Van. A bringás EDGE sorozat (virtuális edzőpartner vagy miszösz funkció). Tán még valamelyik futós is, de baromi lusta vagyok utánanézni.

5.
a.) Hasonló okokból választotta a Polar a 10-zel szorzást, mint amit a 2. pontban is írtam a Garminnál. Egyszerűbb az egészeket kezelni, mint a lebegőpontosakat. Ráadásul kis számoknál sokkal helytakarékosabb tud lenni az ilyen trükkös "pszeudo-lebegőpontos" adattárolás. Főleg a régebbi Polar pulzusmérőknek rendkívül kis memóriájuk volt, az S710i-mnek pl 16kByte (igen, kilo!!!). Minden bittel spóroltak, a sebesség-magasság-pulzus adatoknál ha jól emlékszem voltak nem egész bájtot elfoglaló számok is, pl sebesség 10 vagy 12 bit, nem emlékszem már. És ebben a csöppnyi memóriában így is elfért 11 óra 10 percnyi edzés sebesség-pulzus-magasság adata, 5 másodperces felbontással. A mostani Polaromat már úgy reklámozzák, hogy óriási memóriája van. Naja, 256 kByte-os... :o)))
b.) 2D-vel számolok. 10 fokos lejtő már eszetlen meredek. Általában százalékban szokás egyébként számolni, nem fokban, 10% kevésbé meredek mint a 10 fok, de ott is igen hamar becsokizol, ha megpróbálsz rajta felfelé tekerni.

6. Csak ennyi kérdés volt? :o)))
[előzmény: (47465) Tisztul_A_Visztula, 2010.03.20 16:40:42]

Tisztul_A_Visztulahozzászólásai | válasz erre | 2010.03.20 16:40:42 (47465)
JEKAEFF

Főleg Neked szól ez a dal.... :-)

1. Múltkorában teszteltem a csix-et barométerként (fixed elevation, auto calibration off), s úgy tűnik, hogy a kijelzőn akkor is ingadozik a magasság.

2. Megnéztem egy biciklis trackem gpx-ét, s észrevettem, hogy a magasság 0,4807129 m-ként ugrik. Ha egy egységgel, akkor mindig ennyi a különbség, ha egyszerre többet, akkor meg ennek az értéknek a majdnem egész számú (pl. 5,9989-szeres) többszörösével. Első tippem az volt, hogy vmelyik nem metrikus rendszerből számol át, de ilyen más rendszert nem sikerült beazonosítom, ezért most arra tippelnék, hogy a barométer mérésközéből adódik ez a távolság. Viszont miért pont 0,48...m? Ráadásul ugyanennyi 600m-es magasságban és 150 m-en is, miközben a légnyomás a magasság növekedésével nem lineárisan csökken.

3. Aztán az is eszembe jutott, hogy a csix az mér külső hőmérsékletet? Hiszen máskülönben nem lenne pontos a barometrikus adatokból számolt magasságadat, mivel a levegő sűrűsége azért függ a hőmérséklettől is, s azt nem lehet feltételezni, hogy adott magasságon mindig ugyanolyan hőméfrséklet van. A test üzemmódban van egy hőmérséklet adat, de az nem pontos, mert a készülék bemelegedésével ez az adat akkor is nő, ha közben nem mozgok.

4. Van olyan Garmin, ami arra van kitalálva, hogy ha ugyanazon a nyomvonalon sportolsz, akkor információt adjon folyamatosan, hogy most gyorsabb vagy-e, mint múltkor? Tehát megnézi, hogy a betöltött bázistrekk kezdőidőpontjához képest hány mp telt el a bázistrekknek az aktuális helyzetedhez képest legközelebbi pontjának időpontjáig, s ez kevesebb vagy több, mint az aktuális trekkednek az aktuális időtartama. Vagy megfordítva hány m-rel vagy lemaradva/előnyben.

5. Gondolkoztam azon, hogy a csix gpx-ével minimum utólag azért lehet elemezni a dolgot. Sőt meg lehet nézni, hogy adott helyen gyorsabb vagy lassabb vagy mint múltkor. Aztán ma belebotlottam a HRM-es progidba, mert a sebesség és a magasság egymás mellé tétele ötleteket adott. Ránézve a HRM-re, felvetődött a kérdés: miért nem "22.5" formában van tárolva a 22,5 km/h-s sebesség, s miért "225"-nek?
Emellett a pontok közötti sebességet csak simán a 2D-s koordináták közötti távolság alapján számolod vagy a magasságot mint harmadik koordinátát is figyelembeveszed?
Bringánál természetesen elég a 2D, de mondjuk sziklás szakaszon, ahol fel- és lelépések is előfordulnak, ott már lehet hogy a 3D az igazi. Sőt ha bringával gurulsz le egy 10 fokos lejtőn 50 km/h körül, már ott is mintegy 0,8 km/h-s torzítás van.
Mindegy a kérdés az, hogy 2D vagy 3D, amivel számolsz.

Természetesen örülnék, ha bárki rámozdulna bármelyik pontra, hiszen lehet, hogy vmit nagyon benéztem.


Bejelentkezés név:  jelszó:   tárolás [regisztráció]

Felhasználónevedet és jelszavadat a geocaching.hu oldalon is használhatod!

[ kezdőlap ] [ térkép ] [ + felmérések ~ ] [ + útvonalak ~ ] [ + poi ~ ] [ belépés ] [ faq ] [fórum] [email]

A weboldal működése és tartalma folyamatos fejlesztés alatt áll, köszönettel vesszük az észrevételeket a fejlesztési ötletek oldalon.
A turistautak.hu-ra feltöltött track-eket és a letölthető térképeket, azaz térképi adatbázist az ODbL licencnek megfelelően bárki használhatja.
Minden egyéb anyag előzetes írásbeli engedély nélkül csak magáncélra használható fel. jogi tudnivalók