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

Janóhozzászólásai | válasz erre | 2010.01.18 20:05:37 (45882)
"Elvileg működik, bár lassan már megint ott tartok, hogy nem tudom hogy mitől... :o) "

Tudom, hogy nem könnyű betartani, de ilyenkor általában az a legjobb megoldás, ha kb. egy napig rá se nézel, és utána egyből rájössz mi az ábra...:-)
[előzmény: (45881) jekaeff, 2010.01.18 19:50:01]

jekaeffhozzászólásai | válasz erre | 2010.01.18 19:50:01 (45881)
A mai termés: http://data.hu/get/2095862/SRTM_HUN_20100118beta.exe.html

A többi szűrő környékéra alulra besuvasztottam a %-os izét.
Elvileg működik, bár lassan már megint ott tartok, hogy nem tudom hogy mitől... :o)
Ha beválik, ki kell nyomtatnom a forráskódot és letisztázni, mert kezdek belekeveredni.

Abban viszont igazad volt (most már értem miért), hogy ezzel ki lehet emelni a bizonyos %-nál meredekebb lejtőszakaszokat.

[előzmény: (45880) 2010.01.18 15:06:52]

hozzászólásai | válasz erre | 2010.01.18 15:06:52 (45880)
Én arra a trendvizsgálatra gondoltam, ami az első mondatodban szerepel: "egy kék ill. piros szakasz első és utolsó pontja között (távolság- és magasságkülönbségük alapján)."

Hiszen az egy újabb trendvizsgálat lenne (csak most nem abszolút, hanem, egy %-os), ha nem szomszédos pontokról van szó. Trendvizsgálatot egy másik trendre rárakva szerintem már nagyobb a torzítás, mint nem rárakva.

Nem véletlenül javasoltam a telefont :-) Fizettem volna :-))
[előzmény: (45879) jekaeff, 2010.01.18 14:35:03]

jekaeffhozzászólásai | válasz erre | 2010.01.18 14:35:03 (45879)
Azt még nem döntöttem el, hogy két-két pont között vizsgáljam-e a %-ot, vagy egy kék ill. piros szakasz első és utolsó pontja között (távolság- és magasságkülönbségük alapján).


Ööööö... a "trendvizsgálat" a vertikális szűrő szerves része. Úgyhogy ha valaki vertikálisan szűr, akkor van trendvizsgálat.


Még egyszer dióhéjban a vertikális szűrő működéséről:

1.) Adott egy indulási magasság.

2.) Amint ettől a magasságtól a beállított küszöbnél (pl. 2.5m) nagyobb mértékben kisebb vagy nagyobb lesz a magasság, meghatározódik az aktuális "trend". Pl. lejtő kezdődik ha (legalább 2.5m-rel) kisebb volt az érték mint az addigi bázisérték.

2/a.) Ha ennél még kisebb értékkel találkozik a program akkor tovább növeli a szintcsökkenés-számláló értékét (az addigi legmélyebb pont és az aktuális pont magasságkülönbségével) és az új érték lesz a minimum, a "lejtő alja" marker

2/b.) Ha ennél a legutóbbi minimumnál nagyobb-egyenlő értékkel találkozik, de az eltérés a küszöbértéknél (+2.5m) kisebb, akkor még nem vált át emelkedő trendbe, és nem könyveli el sem szintemelkedésként, se szintcsökkenésként

2/c.) Ha a legutóbbi minimumnál nagyobb értékkel találkozik és ez az érték MEGHALADJA a küszüböt (+2.5m), akkor emelkedővé válik a trend és elkezdődik a szintemelkedés számolás

3.) A 2. ponthoz hasonlóan itt a "hegycsúcs" marker tologatódik egyre feljebb, és mindig csak a legutóbbi max. magassághoz képest történő növekedés mértékével nő a szintemelkedés számláló. Természetesen ha egy legalább 2.5m-es csökkenéssel találkozik a program, ismét "lejtő" trend kezdődik.
[előzmény: (45878) 2010.01.18 13:07:31]

hozzászólásai | válasz erre | 2010.01.18 13:07:31 (45878)
Jó hír, hiszen akkor már eleve nem voltunk egymástól messzire a koncepciót illetően. Én viszont ezt a 3. paramétert továbbra sem hívnám szűrésnek, mert a szűrésnél valamit kvázi eldobsz, inkább felosztó küszöbértéknek vagy szeparációs paraméternek.

Akkor ugye a szomszédos pontokat fogod nézni (természetesen Gauss és vertikális utáni magassági adatokkal :-) ) és nem lesz trendvizsgálat sem? Nekem úgy tűnt, hogy 45845-nél még nem így volt, a bétánál már nem tudtam eldönteni.

Egyébként a Gauss-nál tényleg azért írtam 1 m-t, mert 0-nál elszállt. Legalábbis régen, amikor eccer kipróbáltam.
[előzmény: (45877) jekaeff, 2010.01.18 12:33:07]

jekaeffhozzászólásai | válasz erre | 2010.01.18 12:33:07 (45877)
Pontosan. Tehát az eddigi két paraméter "tetejére" jönne ez a szűrés.

Ha azok bármelyikét kinullázták (bár lehet, hogy ez a Gauss-nál jelenleg nullával osztást eredményez és programkifagyást, de ezt orvoslom majd egy plusz sor beírásával), akkor az adott szűrőt nem veszi figyelembe.
[előzmény: (45876) 2010.01.18 12:02:14]

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]

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

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

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

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

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