turistautak.hu

Előzmények

hozzászólásai | válasz erre | 2010.01.18 12:02:14 (45876)

"Ez a meredekség szűrő az én értelmezésemben nem közvetlenül a Gauss-on működne (a vertikális szűrő teljes figyelmen kívül hagyásával), mivel még abban is rengeteg "hamis" hupli van amelyek elég meredekek ahhoz hogy lejtőnek/emelkedőnek ítéltessenek, hanem a bétában látható kékre és pirosra színezett szakaszokat."

Persze, hogy nem közvetlenül a Gauss-on működne, kivéve ha a felhasználó a vertikális paramétert 0 m-re állítja, mert akkor praktikusan mégis a Gauss-on működne.

Ugye Te is így gondoltad az utolsó hsz-od utolsó bekezdését?

[előzmény: (45875) jekaeff, 2010.01.18 11:31:42]

jekaeff

hozzászólásai | válasz erre | 2010.01.18 11:31:42 (45875)

Én úgy értem, hogy:

- A szintemelkedés számolás úgy történik, ahogy eddig is, a felhasználó egyedi ízlése szerint variálja a két szűrőt.

- A lejtő/emelkedő/sík kiértékelés ugyanezen beállításokkal működne (ahogy a mostani bétánál is) PLUSZ még lenne egy meredekség szűrő (ami akár kikapcsolható is lehet, vagy 0%-ra állítva "kikapcsolttá" válik).

Ez a meredekség szűrő az én értelmezésemben nem közvetlenül a Gauss-on működne (a vertikális szűrő teljes figyelmen kívül hagyásával), mivel még abban is rengeteg "hamis" hupli van amelyek elég meredekek ahhoz hogy lejtőnek/emelkedőnek ítéltessenek, hanem a bétában látható kékre és pirosra színezett szakaszokat.

[előzmény: (45874) 2010.01.18 10:58:59]

	hozzászólásai \| válasz erre \| 2010.01.18 10:58:59 (45874)
Remélem tényleg csak viccelsz, s valójában érted, amit írtam. Ha nem, akkor megbeszélhetjük telefonon. [előzmény: (45873) jekaeff, 2010.01.18 10:46:12]

jekaeff	hozzászólásai \| válasz erre \| 2010.01.18 10:46:12 (45873)
Vagyis? :o) Én még arra is gondoltam, hogy az új bétában kékre és pirosra színezett szakaszok közül nem venném figyelembe a 0.5% meredekség alattiakat a lejtés/emelkedés/sík szakaszok megítélésénél. [előzmény: (45872) 2010.01.18 08:26:56]

hozzászólásai | válasz erre | 2010.01.18 08:26:56 (45872)

Nem pontosan fogalmaztam. Én ugyanazon az adathalmazon mérném a szomszédos pontok között, ami "egy esetleges" Gauss-simítás és "egy esetleges" vertikális szűrés után kijön, hiszen az a legjobb közelítés.

Azért írok "esetlegest", mert ez pl barometrikus magaságmérésnél hiába 100/2,5 m paraméterekkel megy végbe ma is automatikusan, ezt a felhasználó már ma is átállíthatja. Tehát ha a felhasználó a 2,5m-t leveszi 0-ra, akkor valójában csak a simított Gaussra történik (történne) a vizsgálat, ahogy a totál szintemelkedés vizsgálata is. Ha a Gauss-t leveszi mondjuk 1 m-re és a vertikálist 2,5m-en hagyja, akkor csak a vertikálisan szűrt adatokra történik a vizsgálat, ahogy a total szintemelkedés vizsgálata is. Ugyanígy lehet 1/0m-rel is dolgoztatni az SRTM_HUN-t, tehát bárminemű szűrés nélküll is.

Summa summárum, a totál szintemelkedés mérésének ugyanazzal a szűréssel (legyen az Gauss vagy vertikális vagy mind2) kell történnie, mint az emelkedés/lejtés/síkban közlekedés mérésének, csak utóbbinál van egy opcionális küszöb, ami nem szűr, csak feloszt.

[előzmény: (45870) jekaeff, 2010.01.17 21:18:55]

jekaeff	hozzászólásai \| válasz erre \| 2010.01.17 21:18:55 (45870)
Oké, de továbbra is az a gondom, hogy HOL méred azt a %-ot? A Gauss-simított görbén minden egyes szomszédos pont között (ha jól értem teljesen elvetnéd a vertikális szűrést)? Ezzel az lehet a baj, hogy még a simítás ellenére is több százalékos emelkedők jöhetnek létre olyan helyeken, ahol valójában tükörsima a terep. [előzmény: (45867) 2010.01.17 21:08:39]

hozzászólásai | válasz erre | 2010.01.17 21:08:39 (45867)

Más szavakkal, szerintem az ötletek között elveszett a lényeg. Bocs, ha erősen fogalmaztam, de talán most igazam van.

Az általam javasolt %-os küszöb pedig nem optimalizálási megoldás, sokkal inkább egy már optimalizált magasságprofil esetén a személyes érzetünk leképezése.

Ez már tényleg nem tartozik a tárgyhoz, de ha ezt így beépíted, azaz simán a simított adatokhoz hozzá rendelsz egy %-os küszöböt, amit a júzer megváltoztathat, akkor pl. én mást fogok aszfalton bringázásnál és mást terepen gyaloglásnál beállítani, hiszen az aszfalt simább, ott kisebb emelkedés is valóban emelkedés, míg a terepen lépegetés számomra nagyobb értéknél válik emelkedéssé a terep lokális egyenetlensége miatt (előbbi ráadásul folyamatosabb, hiszen a kerék gurul, míg a bakancs pozíciója diszkrétebb)

[előzmény: (45865) 2010.01.17 21:00:37]

hozzászólásai | válasz erre | 2010.01.17 21:00:37 (45865)

Ha tökéletes lenne a helymeghatározás, akkor nem kellene a szakaszhosszról beszélni, hiszen mindig csak a track két egymás utáni pontja közötti magasságkülönbséget kellene nézni. Hiszen az "ele" 7 tizedesjegyű, ezért bármilyen kicsi %-os vagy ezrelékes emelkedési küszöbre értelmesen lehet megvizsgálni, hogy meghaladja-e azt, még akkor is, ha valaki 1 mp-es rögzítés mellett baromi lassan gyalogol, s mondjuk csak 0,36 km/h-val megy, azaz trackpontonként csak 10 cm-t, aminek az 1 ezreléke 0,0001 m, tehát még mindig csak a negyedik tizedesjegynél járnánk egy 1 ezrelékes küszöb esetén. Ennyit a felesleges elméletről, ami azért mégsem haszontalan.

Ahogy már írtam, szvsz nem kell a szakaszhossz törődni, ha a Gauss simított track-re (esetleg vertikális szűrővel) engeded rá a vizsgálatot. Hiszen a simítás paraméterezhető, így kvázi már hosszabb szakaszt vizsgálsz, még ha a távolabbi értékek kisebb súllyal is szerepelnek.

Még egyszerűebben, csupán azt kell eldöntened, hogy mi a hiteles simítás, hiszen ez az optimális magasságprofil alapja, ami már létezik az SRTM_HUN-ban. Ha pedig ennél jobbat nem tudsz a Gauss simítással és a vertikális szűrővel és egyéb ötletekkel a magasságprofilnál, akkor miért tudnál jobbat az emelkedés/lejtés/sík kérdésnél. Valójában ugyanazt a kérdést vizsgálod, nem de?

[előzmény: (45864) jekaeff, 2010.01.17 20:27:56]

jekaeff

hozzászólásai | válasz erre | 2010.01.17 20:27:56 (45864)

A %-os dolog is jó ötletnek tűnik, node mekkora szakaszon kéne azt vizsgálni?
Ha lefixálom, hogy pl 100m-es szakaszon, akkor mi van, ha 100m-en belül volt egy jókora hupli?

A mostani megoldásnak az az egy előnye mindenképp megvan, hogy ugyanazon az elven működik, mint a szintemelkedés-számolás, így nem születhetnek ellentmondó eredmények. Viszont nem vagyok elégedett a "sík-érzékelési képességével". A korábbi (hibás) megoldásom hosszabb sík területeket kalkulált, mivel a "trendváltás" (emelkedő után lejtő vagy fordítva) után a legelső 2.5m magasságkülönbségig (amennyiben ez volt a vertikális szűrő értéke) még síknak tekintette a terepet. Az viszont nem mutatott valami szépen hegyes-völgyes terepen, mivel minden emelkedő és lejtő egy kis "sík" sárga szakasszal kezdődött.

[előzmény: (45863) 2010.01.17 19:42:50]

	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]

jekaeff

hozzá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]

jekaeff	hozzá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]

jekaeff

hozzá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]

Gabe

hozzá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]

jekaeff

hozzá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]

Saughassy	hozzá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]

jekaeff

hozzá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

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