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

hozzászólásai | válasz erre | 2010.01.17 19:42:50 (45863)
Az én véleményem nem változott, de van egy olyan érzésem, hogy mivel egy logika szerint már elkezdted megvalósítani a dolgot, úgysem fogod teljesen revideálni a módszered. :-)
[előzmény: (45855) jekaeff, 2010.01.17 16:25:58]

jekaeffhozzászólásai | válasz erre | 2010.01.17 16:25:58 (45855)
SRTM_HUN béta, csak a magasságszámolás új benne:

http://data.hu/get/2091347/SRTM_HUN_beta_magassag.exe.html

(Az alábbi gombokat kell választani az oldalon a letöltéshez: "Ingyenes" majd "Nem élek vele", majd végül a "Letöltés indítása" linken kell kattintani.)

A Gauss szűrő bekapcsolásával megjelennek a piros/kék/sárga zónák, amelyek azokat a szakaszokat jelölik, amit a program emelkedőnek/lejtőnek/sík területnek gondol. Ez jelenleg a vertikális szűrő viselkedését mutatja, vagyis azét a szűrőét ami a Gauss után lefutva az eddigi szintemelkedés-számolásnál is meghatározta, hogy mit tekintünk szintemelkedésnek és mit szintcsökkenésnek. Ha bekapcsoljátok a vertikális szűrő megjelenítését, most még beszédesebb, mit miért számol a program úgy ahogy azt teszi.

Vélemény?

(Én jelenleg úgy látom, hogy leginkább jóval erősebb vertikális szűrővel (4.5-5m körüli érték) nyilvánítja síknak azokat a területeket, amit síknak érzek. Ekkor viszont a "bonyolultabb", huplisabb dombtetőket is síknak minősíti, sajnos.)
[előzmény: (45853) jekaeff, 2010.01.17 12:44:03]

jekaeffhozzászólásai | válasz erre | 2010.01.17 12:44:03 (45853)
Csak legyen rá időm, ma is eléggé be vagyok táblázva...
[előzmény: (45852) 2010.01.17 10:35:44]

hozzászólásai | válasz erre | 2010.01.17 10:35:44 (45852)
Gondolom, majd úgyis leírod a megoldást, mind az emelkedés, mind a pihenő definiálása terén.
[előzmény: (45849) jekaeff, 2010.01.17 10:23:52]

jekaeffhozzászólásai | válasz erre | 2010.01.17 10:23:52 (45849)
Attól tartok, hogy egy akár ilyen szofisztikáltra megírt algoritmus is egy csomó téves döntést hozna. Sokszor "beragadna", ragaszkodván a sz eddigi mozgási trendhez. Ha meg állítható paraméterű lenne, még egy plusz macera lenne a felhasználó számára.

A tegnapi megoldásom (aminek a finomítását még ma megejtem, már sejtem is, hogy hogyan fogom megtenni) is egész tűrhető eredményt hozott, főleg ha "messziről nézzük":

[előzmény: (45848) Gabe, 2010.01.17 08:47:45]

Gabehozzászólásai | válasz erre | 2010.01.17 08:47:45 (45848)
Ha szabad kicsit belevau :)

Egy 1 km-es szakaszon +/- 2 m hullámzás nyugodtan minősíthető egyenesnek (vagy akár mérési hibának). Ez még gyalogosan, erdőben is ésszerű: egy árok, egy földkupac, egy kidőlt fa megkerülése talán nem annyira fontos.

A felvetett probléma azonban nyilván általánosabb - az emelkedés/süllyedés/egyenes kvantálási értéke alatti mozgások az utolsó elfogadott iránytangensnek megfelelő tartományba fognak kerülni. Ez a döntés most egy sima előrehaladó algoritmus alapján történik meg (a kvantumértéknek megfelelően).

"Jobb" képet - szerintem - akkor kapnánk, ha egy bizonyos (a pillanatnál nagyobb léptékű) tartományra eldöntenénk egy nagyléptékű iránytangenst, majd visszalépve kikeresnénk a tartomány széleit.

Egy ilyen "adaptívabb" jellegű algoritmus a konkrét esetben 22.4-ig emelkedést jelezne, majd onnan süllyedést (a jelenlegi kvantumoddal). Ha a szakaszhossz 100 m környékére lejönne, és ennek lenne prioritása (nem a kvantumnak), akkor kicsit hullámosabb is lehetne a követés.

[előzmény: (45845) jekaeff, 2010.01.16 20:22:06]

jekaeffhozzászólásai | válasz erre | 2010.01.16 20:22:06 (45845)
Hát, én igyekszem. :o)

Azért még akadnak gondok... Ahogy írtam, megpróbáltam a szintemelkedés/szintcsökkenés számlálókoz kötni a sík/emelkedő/lejtő szakaszok hosszmérését.

Ezzel csak az a baj, ami az alábbi tesztábrán is látszik. A program szerint:
- az emelkedő piros
- a lejtő kék
- a sík sárga

Bal oldalról jövünk egy emelkedőn. Vannak kisebb visszahullámzások benne, azt nem számolja be az emelkedésbe/csökkenésbe, mivel nem lépik át a 2.5m-es küszöbértéket. Eléri a plafont 162m-nél, után kezd lejteni de a szintcsökkenés számolás csak a 2.5m-es csökkenés átlépésével kezdődik, és mivel a számláló ekkor lódul meg, egészen addig azt hiszi a program, hogy vízszintes a terep. Így mindig egy picit hosszabbak lesznek a "vízszintesnek vélt" szakaszok, mint valójában.

[előzmény: (45844) Saughassy, 2010.01.16 19:04:43]

Saughassyhozzászólásai | válasz erre | 2010.01.16 19:04:43 (45844)
Hajráhajrá, álmaim programja készül. :) Ha lesz public beta, szolj.
[előzmény: (45831) jekaeff, 2010.01.16 15:26:34]

jekaeffhozzászólásai | válasz erre | 2010.01.16 15:26:34 (45831)
Tisztul_A_Visztula!

Dolgozok az SRTM_HUN részletes statisztika paneljén, ez még csak képernyőterv (nem képes még ilyeneket számolni a program, ezek most még kézzel beírt értékek), de végül valami ilyesmi lenne, legalábbis erre törekszem:



...esetleg még szerepelhetne a statisztikában a pihenők darabszáma és azok átlagos hossza.

A pihenőkkel van egyébként is a legnagyobb gond: volt már programom a "megállások" jelzésére (a "PihenoK" programom waypoint-okat gyártott oda, ahol megállást észlelt), akkor olyan módszerrel állapította meg a megállást, hogy ha egy beállított küszöbérték alá csökkent a sebesség, akkor oda gyártott egy WP-ot, jelölve benne a pihenő hosszát (amíg az adott pihenő tartott). York már akkor is jelezte, hogy hasznos lenne egy küszöbérték másodpercben, hogy az annál rövidebb "pihenőket" (amik inkább csak megtorpanások) ne számolja be a program, így gondoltam most is hasznos lenne.

Persze ez a sebesség alapú pihenés-detektálás sem tökéletes. Elképzelhetőnek tartom, hogy egy helyben állva, rossz égbolt-rálátás esetén olyan nagyokat imbolyog a pozíció, hogy az már átlépi a beállított sebesség küszöböt. A pihenős programomat is csak a távolság alapú (3m) rögzítésre állított 60CSx-em track-jein próbáltam, nem tudom, hogy egy 1 másodperces alapú rögzítés esetén nem-e-é-e lenne túl gyors az imbolygás rossz vételi körülmények között.

Gondolkoztam más megoldáson is, pl hogy állás az, ha 20 másodpercen belül nem távolodik legalább 10 méterre egy előző trackponttól az emberfia, de ezzel is adódhatnának gondok.

Aztán az is lehet, hogy tojnom kéne az imbolygásra, mert a 60CSx is beszámolja azokat mozgásként (a mozgásidőbe is), becsülettel. :o)
[előzmény: (45701) 2010.01.12 12:43:12]

hozzászólásai | válasz erre | 2010.01.12 12:43:12 (45701)
Tudtok olyan programról, ami tracket elemez olyan módon, hogy többek között a csix-hez hasonlóan kiírja a Moving average speed-et (min sebesség) és a Moving time-ot?

Megj-ek:
- Ismerem a Trackan-t, de unom a plt-be konvertálást mindig. (gpx és/vagy gdb input-os progi kellene)
- Találtam egy német nyelvűt, de ott a minimum 1 perc állásidő és ezeket keresi



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