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

Mákoshozzászólásai | válasz erre | 2010.05.27 10:35:01 (49262)
Sőt! Napsütéses helyen van vs. árnyékban van...:-)
[előzmény: (49261) Togo, 2010.05.27 10:32:17]

Togohozzászólásai | válasz erre | 2010.05.27 10:32:17 (49261)
Nekem most felderengett egy általános iskolai fizikaóra képe, ahol a tanerő egy üvegcsövet keresztültolt egy gumidugón, ezt belenyomta egy lombikba, majd ezt az egészet csővel lefele befogatta egy lombikfogóba. Ezután egy üvegtartályba vizet töltött és abba belemerítette a az előbb összeállított dolog csövét. Mondta, hogy látszik, hogy a lombikban lévő légnyomás nem engedi be a csőbe a vizet. Majd rátette a kezeit a lombikra, aminek hatására elkezdtek buborékok jönni a csőből. Ekkor azt mondta, hogy a kézmeleg hatására a lombikban lévő levegő elkezdett tágulni és az így megnövő légnyomás hatására jön ki a levegő a csőből. Nem kizárt, hogy egy ugyanilyen hatás is megmutatkozik kézben tartott GPS nyomásérzékelőjén.
[előzmény: (49259) Csuhás, 2010.05.27 10:09:26]

Csuháshozzászólásai | válasz erre | 2010.05.27 10:09:26 (49259)
Minden relatív. Egy merevnek tűnő dobozon is lehet egy-két tized millimétert deformálni, ez okozhat a gombnyomással összemérhető változást. ( A gombok izolálása helyett egyszerűbb lehet a nyomás érzékelő elválasztása a ház belső légterétől, egy belső gumigyűrűvel.)
[előzmény: (49258) 2010.05.27 09:27:46]

hozzászólásai | válasz erre | 2010.05.27 09:27:46 (49258)
Viszont a készülékház megnyomását nem értem. A merev műanyagot mi értelme megnyomni?
[előzmény: (49256) Csuhás, 2010.05.26 22:20:49]

Csuháshozzászólásai | válasz erre | 2010.05.26 22:20:49 (49256)
A magasságmérő pici lyukja belül gondolom valami vízzáró de levegőt lassan áteresztő textillel van leragasztva. Ha megnyomod a gombot az megnöveli a házban a nyomást ami lassan egyenlítődik ki, és azt mérheti a szenzor. Ha igaz az ötletem akkor a készülékházat megnyomva is kilengést kell mutatnia, illetve a hosszan nyomott gomb elengedéskor ellentétes lengést kell mutasson. Egy próbát megér a dolog..
[előzmény: (49223) 2010.05.26 16:59:28]

hozzászólásai | válasz erre | 2010.05.26 16:59:28 (49223)
Magasság témában újabb megfigyelések. Már jó ideje foglalkoztat a barometrikus mérőre gyakorolható hatás a csix nyomógombjaival. Már két éve megfigyeltem ezt, most viszont módszerese(bbe)n teszteltem.

1. Finom gombnyomás: 2-3 m-re meg lehet úszni.
2. Agresszív, gyors, full gombnyomás: akár +/- 10 m-es kilengést is meg lehet közelíteni.
3. Nagy óvatos Page gombra nincs kilengés, viszont Enter-re még ekkor is.

Összefoglalva: vagy az én kütyüm nem kóser, vagy konstrukciós hiba, de az "alsó gombok" több zajt okoznak. Nem is gondoltam volna. Lehet, hogy alul van valahol a barometrikus mérő a készülékben?
[előzmény: (49153) jekaeff, 2010.05.22 01:23:17]

jekaeffhozzászólásai | válasz erre | 2010.05.22 01:23:17 (49153)
Majd ezt még kitalálom. A téves csúcs/völgy detektálások elkerülésére valami limitet gondoltam, hogy pl. legalább 10 méter emelkedő/lejtő volt előtte. Egyébként amit az utolsó bekezdésedben írtál, az szerintem nálam nem gond, amennyiben "trendváltáson" a vertikális szűrő töréspontjait értem, a kisebb hullámzásokkor (pl. 2.5m alatt) az úgysem következik be.

No de hol van ez még... Majd ha lesz időm. Persze gondolkodni lehet rajta.
[előzmény: (49152) 2010.05.22 01:05:34]

hozzászólásai | válasz erre | 2010.05.22 01:05:34 (49152)
Jól beszélsz. Arra már én is nagyon hajlok, hogy a korábban általam boncolgatott lassú fel és gyors le esetben felesleges a pontok darabszámát bevezetni.

Nekem is az jött ki korábban, hogy általában a 100 m jó sugárnak, viszont a csúcsoknál és völgyeknél az 50 m tetszik, mert így "alkalmanként" csak 1 m körüli a veszteség pl a Zemplén 700-as csúcsainál, ami lehetséges, hogy valójában nem is veszteség, viszont a 100m-nél már 3-5m alkalmanként. Ráadásul itt szép a trackem, nincsenek klasszikus tüskék, azaz nem indokolt, hogy a csúcsok teteje eltűnjön.

Az intelligenciát illetően a track végek is foglalkoztatnak. Még mindig. Ha sík, nincsen gond. Ha lejtő, akkor akár kezdő, akár vég, ott a pontok relatíve távol esnek egymástól, így kicsi az összsúlya azoknak a pontoknak, amik lehúzhatnák a kezdőpontot és fel a végpontot. Ha emelkedő, akkor viszont a kezdőpont felhúzása és a végpont lehúzása továbbra is valós probléma.

Talán ha ezt is trendváltásnak értelmezzük, akkor lekezelődne magától a fentiek miatt.

Viszont ha már bevezetted a bétákban a sik, emelkedő és lejtő fogalmát, akkor talán ezt kellene felhasználni ennél az intelligenciánál, s mégsem a trendváltást. Mert amúgy túl sok lenne az ilyen csúcs és völgy. Magyarán pl. csak akkor csökkenne le a Gauss sugár fokozatosan a felére, ha van olyan pont, hogy előtte emelkedőt érzékel az srtm és utána síkot vagy lejtőt, illetve előtte lejtőt és utána síkot vagy emelkedőt.
[előzmény: (49151) jekaeff, 2010.05.22 00:24:41]

jekaeffhozzászólásai | válasz erre | 2010.05.22 00:24:41 (49151)
Majd meglátjuk, szebb grafikonokat rajzolsz-e dinamikus ablakkal. ;)

Szerintem a sebességet nem kéne belekavarni. A pontok térbeli helyzete (milyen messze vannak egymástól) sokkal meghatározóbb tényező, FÜGGETLENÜL a sebességtől. Szerintem. Amúgy meg ezzel max 1-2 métert nyernél (és könnyen lehet, hogy ugyanennyi hibát is vinnél a rendszerbe). Én továbbra is maximum csak valami "hegycsúcs-völgymélye"-detektálást tudnék elképzelni mint intelligenciát, hogy ezeken a helyeken pl fokozatosan felére csökkenteni a Gauss szűrőt a csúcs/völgy felé közeledve. De ez is plusz hibákat vihetne be a számolásba, mivel több zaj is megmaradna ezeken a helyeken.
[előzmény: (49150) 2010.05.22 00:18:05]

hozzászólásai | válasz erre | 2010.05.22 00:18:05 (49150)
Nocsak. :-)
Ezt továbbra is vitatom ;-)
[előzmény: (49148) jekaeff, 2010.05.22 00:15:52]

jekaeffhozzászólásai | válasz erre | 2010.05.22 00:15:52 (49148)
...ír valami dinamikus ablakméretről is, de arra csak pontszám alapú esetben van (lenne) szűkség az összevissza távolságok miatt.
[előzmény: (49147) 2010.05.22 00:13:24]

hozzászólásai | válasz erre | 2010.05.22 00:13:24 (49147)
Az elsőt megtaláltad. :-)
[előzmény: (49146) jekaeff, 2010.05.22 00:01:37]

jekaeffhozzászólásai | válasz erre | 2010.05.22 00:01:37 (49146)
If we link the window size to a distance rather than number of points, we can achieve a more consistant weighting of relevant points in regards to our horizontal scale. ;)
[előzmény: (49145) 2010.05.21 23:38:25]

hozzászólásai | válasz erre | 2010.05.21 23:38:25 (49145)
Egy kis melléktermék időközben:

http://cullenking.com/2009/6/12/using-gaussian-and-sinc-filters-on-elevation-data

sok szempontból is érdekes, de erről majd később
[előzmény: (49119) jekaeff, 2010.05.20 21:23:18]

jekaeffhozzászólásai | válasz erre | 2010.05.20 21:23:18 (49119)
Én sem értem, hogy annak idején hogyan csináltam, de látszólag tényleg jó. :o)))

Majd rászánok valamikor pár órát arra a 10 sorra (mármint a megértésére), ami a tényleges számolást végzi.
[előzmény: (49117) 2010.05.20 20:52:36]

hozzászólásai | válasz erre | 2010.05.20 20:52:36 (49117)
JEKAEFF

Nem felejtettem el a dolgot, ma gondolkodtam rajta. Az a helyzet, hogy visszaléptem legalább kettőt, s most már azon gondolkozom, hogy ha nem lenne meg a programod, én milyen simítást választanék, s miért?
Ameddig nem tudom levezetni, hogy a jelenlegi általános értelemben jó (márpedig az a chart-on látszik, hogy jó), pedig amit írsz, az furcsa, hiszen normalizálás nélkül nem megy a dolog (ha súlyokkal számolsz szorzatösszeget, de a súlyok összege kisebb mint 1, akkor mindenképpen fel kell szoroznod az eredményt valamennyivel), addig nem akarok továbblépni.
Először megnézem, hogy milyen simításokat használnak a szakirodalomban, s melyik mikor és miért jó.
Ha a normális eloszlás a nyerők között van, akkor megnézem még egyszer a forrását az srtm-nek.
S csak ezután térek vissza.

Konklúzió: ebben a témában eltűnök egy jó időre. :-)
[előzmény: (49028) jekaeff, 2010.05.17 20:54:56]

jekaeffhozzászólásai | válasz erre | 2010.05.17 20:54:56 (49028)
Ennél én primitívebben oldottam meg:



Mit nekem szórás meg efféle huncutságok. A Theta =1.5 szimpatikus volt, maximuma 1, és önhatalmúlag KIJELENTETTEM, hogy x=-5 és x=+5 esetén gyakorlatilag már szinte "0" az értéke. Tehát a "Gauss-sugár" ebben az esetben 5. Ezt kivetítem az adott méretű gauss sugárra és az origótól számolva az egyik irányban 10000 szeletre osztottam, az eredményeket egy tömbbe pakoltam. Ezek után ha egy 98.7m-re lévő pont G(x) értékét keresem, elegendő ebből a táblából kikeresni a hozzá legközelebb eső értéket. 100 méteres gauss sugár esetén az ilyen "kerekítési hiba" max. 0.5cm lesz "x" irányban ezt még elfogadhatónak tartottam.
[előzmény: (49024) 2010.05.17 20:21:23]

hozzászólásai | válasz erre | 2010.05.17 20:21:23 (49024)
1. A linken lévő képletet használod. Mármint az egy dimenziósat

2. Amikor bekéred a sugarat, azt úgy értelmezed mint a normális eloszlás szórását

3. Az hogy milyen pontokat veszel figyelembe, attól függ, hogy a számolt ponttól milyen messzire lévő pontokat veszed figyelembe. +/- szóráson belülieket vagy neadjisten +/- a szórás háromszorosán belülieket? Utóbbi esetben elhanyagolható az a hiba, ami a figyelembe nem vett kis súlyú pontokból következik, viszont előbbi esetben ez nem így van.
Én arra tippeltem, hogy az előbbi eset az, amit megvalósítottál, hogy ne legyen lassú a progid, meg erre utaltál nemrég indirekt módon ( http://turistautak.hu/forum.php?action=thread&id=kutyuk&message_id=270450). Így viszont jelentős a figyelembe nem vett pontok összsúlya, ha jól rémlik matekból, akkor olyan 33%.

4. Ezért írtam, hogy visszanormálsz 1-re, azaz amikor egy adott ponthoz figyelembe veendő másik pont magasságának a súlyát megkapod a normális eloszlásból pl 3.45%-ot, ezt beszorzod 1/(1-33%)-kal
[előzmény: (49021) jekaeff, 2010.05.17 19:54:56]

jekaeffhozzászólásai | válasz erre | 2010.05.17 19:54:56 (49021)
Mit csinálok a micsodával? :o)))
[előzmény: (49020) 2010.05.17 19:50:47]

hozzászólásai | válasz erre | 2010.05.17 19:50:47 (49020)
Tehát http://en.wikipedia.org/wiki/Gaussian_blur egy dimenzióban, VISZONT a sugáron (ami egyenlő szórás) kívüli pontokkal nem foglalkozol, azaz a negligált két farokból (pontok a sugárnál nagyobb messzeségben) fakadó súlyveszteség miatt visszanormálsz 1-re?
[előzmény: (49018) jekaeff, 2010.05.17 19:45:37]

jekaeffhozzászólásai | válasz erre | 2010.05.17 19:45:37 (49018)
Csak a távolság számít a súlyozásnál, az nem, hogy hányadik az adott pont.
[előzmény: (49017) 2010.05.17 19:37:20]

hozzászólásai | válasz erre | 2010.05.17 19:37:20 (49017)
Megtettem és igazad van. Ugyanis ezzel a módszerrel nem kaptam meg a dinamikus Gauss-sugárt, amire vágytam.
Azt akkor kaptam volna meg, ha nem csonkolnánk (hiszen most ez történik, ugye?), hanem a filterpontszámon belül eső szomszédokra vonatkozna a haranggörbe. Tehát ha a Gauss sugár 100 m és 1000000 pont van, akkor a sugár tényleg 100 m (ez most is így van), viszont ha leveszem a pontszámot 10-re, akkor azon esetekben ahol a tizedik szomszéd nagyobb mint 100m-re van, ott 100 m a sugár, ahol csak 30 m-re, ott 30 m lesz a sugár.

Tehát rosszul fogalmaztam meg korábban. De nem akarlak túráztatni a rossz specifikáció miatt, megnézem, mit lehet kihozni ebből pár más szintprofilú trekknél.

Mellesleg mi a pontos metódus a Gauss-nál? Kicsit későn kérdezem meg, tudom.
Mindig a számolt pont és a figyelembe veendő másik pont távolsága határozza meg a (számolt ponttól mérve a sugáron belül eső összes) figyelembe veendő pont súlyát a számolt pont magasságának számolása során vagy az is számít, hogy hanyadik szomszédről van szó????
[előzmény: (49015) jekaeff, 2010.05.17 19:19:24]

jekaeffhozzászólásai | válasz erre | 2010.05.17 19:19:24 (49015)
Azért majd hasonlítsd össze hasonló szintemelkedést számoló kisebb sugarú Gauss szűrőbeállítással (és max. 1.000.000 szomszédos pontra "szűkítve" :o) is... Szerintem minimális lesz a különbség a két grafikon alakja között és így megkérdőjelezhető ennek haszna.
[előzmény: (49014) 2010.05.17 19:15:59]

hozzászólásai | válasz erre | 2010.05.17 19:15:59 (49014)
A trendes szituban jól működik. Összességében 1-2 m-rel viszi el az összes szintemelkedést (ez valószínűleg szinte kizárólag a két végének új magassága miatt van), viszont az előny az, hogy már nincs annyira túlsimítva a vége. Hátrányként jött elő, hogy néha bizonyos 10-nél kisebb filter esetén létrejön egy túlzóan meredek pont az utolsó néhány pont között. Tehát mondjuk 5-nél és 7-nél nem jö elő, de 6-nál igen. Ez több mint érdekes, de ehhez sok tesztidő kell.
Csakúgy mint az ereszkedőkkel megáldott trekkek vizsgálatára.
[előzmény: (49012) 2010.05.17 18:46:32]

hozzászólásai | válasz erre | 2010.05.17 18:46:32 (49012)
Ha tudom, hogy közben dolgozol, nem gépelek ennyit. :-) Megnézem a bétát, kösz érte. Mondjuk a teszteléssel romba döntöttem a saját fejlesztésemet mára.
[előzmény: (49010) jekaeff, 2010.05.17 18:42:43]

jekaeffhozzászólásai | válasz erre | 2010.05.17 18:42:43 (49010)
Na jó, itt a javított verzió, utálok hibázni: http://data.hu/get/2556146/SRTM_HUN_Domdodom_beta2.exe.html
[előzmény: (49009) jekaeff, 2010.05.17 18:37:17]

jekaeffhozzászólásai | válasz erre | 2010.05.17 18:37:17 (49009)
Annyi hiba vana programban, hogy kisebb-egyenlőt írtam a kisebb helyett, így mindig eggyel több szomszédos pontot enged meg jobbra és balra mint amennyit szeretnél. Tehát 5-öt beállítva limitnek 6max a szomszédos 6-6 pontot használja fel (plusz az aktuális, "középső" pontot). Ezért fordulhat elő, hogy 0-ra állítva a Gauss görbe nem fedi az eredetit. Már kijavítottam, feltölthetem azt is, de szerntem tesztelni ez is jó lesz.
[előzmény: (49008) jekaeff, 2010.05.17 18:28:13]

jekaeffhozzászólásai | válasz erre | 2010.05.17 18:28:13 (49008)
...illetve bizonyos esetekben szebbet, más esetben szinte megkülönböztethetetlen a két output.
[előzmény: (49007) jekaeff, 2010.05.17 18:25:37]

jekaeffhozzászólásai | válasz erre | 2010.05.17 18:25:37 (49007)
Már kész is (volt rá 10 percem): http://data.hu/get/2556006/SRTM_HUN_Domdodom_beta.exe.html

SZERINTEM a Gauss-t olyan kicsire állítva (ezen megoldás helyett), hogy hegytetőkön hasonló eredményt produkáljon, sokkal szebb eredményt produkál.
[előzmény: (49006) 2010.05.17 18:20:35]

hozzászólásai | válasz erre | 2010.05.17 18:20:35 (49006)
Azt felejted el, hogy nem kötelező a pontos limit effektív használata. Én is írtam, hogy "megadok rá egy nagy pontszámot, ami nem jelent effektív korlátott."

Az általad említett esetet én egyébként sem élem meg, így nem is kellett gondolkoznom rajta, mert a biciklis hegyre fel mindig visszafordulással jár. Néha a tetőn, néha előbb. De az első bekezdés a lényeg.
A nagyon bétának is örülnék, de türlemesen megvárhatom azt is, míg a többi dolgot a listádon rendberakod.
[előzmény: (49002) jekaeff, 2010.05.17 15:51:16]

jekaeffhozzászólásai | válasz erre | 2010.05.17 15:51:16 (49002)
Node:
- Felmész a hegyre csigalassan
- Leszáguldasz, mint a villám

Pont alapú szűrésnél ennek az lesz az eredménye, hogy pl. max 5 pontos limitet beállítva a "bal oldalból" figyelembe vesz a Gauss 10 métert, a "jobb oldalból" pedig 25m-t (mivel itt ritkábbak lesznek a pontok). Nem értem, hogy ez az asszimetria miért hozna pozitív eredményt. Arra gondolsz, hogy a "nagy súlyú" pontokból így több marad? Nem vagyok biztos benne, hogy ez valami csodaszép kimenetet produkálna, de összedobhatok egy nagyon-bétát. A völgy meg így is szívás, mert az érkezési lendülettel mész fel a következő emelkedőre, a völgy mélyén így mindenképp ritkák lesznek a pontok és nagyon "csonkolódik majd.
[előzmény: (49000) 2010.05.17 15:07:54]

hozzászólásai | válasz erre | 2010.05.17 15:07:54 (49000)
Több gr: igen csakorlatilag két chart egymás tetején (ennyire tellett tőlem :-) Jobboldali skála: mint pl. a Garmin Training Center-nél.

Szakaszadatok: A fordítotnak csak akkor van értelme (s én erre gondoltam), ha vmilyen technológiai okból a normál logikát nem tudod megvalósítani. Az értelme pedig a következő: bár kicsit próbálkozni kell, mielőtt megtalálod azt a két szakaszvéget, ami tetszik Neked, de a folyamatosan aktualizálódó két függőleges vonal egyfajta vfolyamatos visszajelzést ad. Érted?? :-) Tehát ha nem tudod leprogramozni, hogy kijelölhessen a user egy szakaszt, akkor programozd le azt, hogy két bevitt adatot megjelenítsen a chart-on két plusz vonallal

Trackpontok: még jó trekket nem láttam intelligens trekkelés mellett (igaz, hogy ezt tuhu rajzolóként mondom). Idő alapú trekkelésnél szinte ugyanaz van, mint nálam, aki mega kis távolságot választott, hiszen a nagy és kis sebességből fakadó kevés vagy sok pont van Gauss-on belül mnidkét esetben előfordul.
Továbbra is fenntartom, hogy a trackpontszámnak az az értelme, amikor egy trekken belül előfordulnak nagy sebességkülönbségek, ezért a Gauss sugarú körben lévő pontok száma drasztikusan ingadozik. Természetesen nekem titokban még a hegyen visszaforduláskor is jól jönne.

A http://www.turistautak.hu/forum.php?action=thread&id=kutyuk&message_id=270422 postból a lényeg még mindig:
"Í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."

[előzmény: (48997) jekaeff, 2010.05.17 14:43:10]

jekaeffhozzászólásai | válasz erre | 2010.05.17 14:43:10 (48997)
Több grafikon:
- Egymás elé és mögé: úgy érted ahogy most is van a normál/gauss/vertikálisnál? Nem múkodik, mivel nincs kettős Y tengely, nem lehet az egyik Y tengely "m" a másik pedig "km/h". Ráadásul ránagyítanál egy hegycsúcsra és esetleg emiatt nem látnád a pillanatnyi sebességgörét, mert az "nem volt benn a zoomban"
- Átlátszó háttér: szerintem nem lehet ilyet, de még majd megnézem. Az esetben két külön "Chart" lenne egymás tetején, de ezzel az a baj, hogy nem zoomolódnának együtt, csak mindig a "felül lévő" (vagy aktív) zoomolódna.
- Jobboldali skálázás: ezt nem is értem (dömdödöm), de szerintem csak baloldalt lehet.

Szakaszadatok:
- Én úgy gondoltam, hogy megfelelő zoom mellett jelölné ki a user a szakasz elejét és végét (az általad is említett függőleges vonalak jelölnék a szakaszt). A fordítottban nem sok logikát látok, hogy a usert adná meg, hogy a 10.550-11.480km köszti szakaszra lenne ő kíváncsi.

Trackpontok:
- Szerintem az eredmény nem sokan különbözne attól, mintha a Gauss sugarat kisebbre vennéd, mivel a gaussnak az a lényege, hogy súlyozottan veszi figyelembe a környező pontokat. A messze lévő pontoknak már alig van "súlyuk", ha viszont a közelebbre lévőket tartanád meg csupán egy "darabszám-szűrővel", akkor szerintem nagyon hasonló lesz a helyzet a sugár csökkentéséhez. No és mi van azokkal a "szerencsétlenekkel" akik nem távolság, hanem idő vagy "intelligens" alapont trackelnek? :o)
- Én inkább valamiféle "adaptív Gauss" megoldáson gondolkozom, ami felismerné a hegyeket/völgyeket (csak azokat tekintené azoknak amik a vertikális szűrésen is átcsúsznának, tehát pl. minimum 2.5 m magasak) és a hegycsúcs közelében lecsökkentené a Gauss sugarat. Ezzel az lehet a baj, hogy a hegytetőn nagyobb serephez jutna a mérési zaj is.
[előzmény: (48993) 2010.05.17 12:35:41]

hozzászólásai | válasz erre | 2010.05.17 12:35:41 (48993)
JEKAEFF

A vasárnapi meló annyit segített, hogy most tudtam 15 perc brainstromingot játszani.

Több grafikon: nem lehetne esetleg egymás fölé (azaz elé és mögé) tenni két grafikont? Vagy ha nem, akkor úgy megoldani, hogy az egyik háttere mindig átlátszó legyen? Esetleg a sorrend is változtatható lenne egy tickbox-szal vagy radio buttonnal? A jobboldali skálázást csak engedi a Lazarus/Free Pascal...

Szakaszadatok: ha jól értem, ezzel nincsen gond. Ha mégis, akkor megfordítanám a logikát. Kis ablakban induló és záró távolság kijelölése (no meg az általad említett adatok kiszámolása), a grafikonon meg két függőleges vonallal jelölni a szakasz két végét.

Egyéb: múltkor írtad a Gauss tükrözést, meg a megfordulós problémám, s utóbbival kapcsolatban említetted, hogy a pontszámmal való játszás rossz megoldásnak tűnik számodra. Ezen gondolkoztál, s azért nem "dorongoltad a földbe", mert szerinted sem tévút?
[előzmény: (48948) jekaeff, 2010.05.15 13:05:07]

jekaeffhozzászólásai | válasz erre | 2010.05.15 13:05:07 (48948)
Tisztul_A_Visztula!

Kicsit kísérletezgettem az SRTM_HUN-nal, hogy hogyan nézne ki ha lenne sebesség- és/vagy lejtőszög grafikon is a normál szintprofilon felül. Az ugyanazon grafikonon belüli ábrázolás nem tűnik megoldhatónak: a Lazarus nem támogatja az egynél több Y-tengely használatát. Különben pedig ilyenkor egyéb gondok is keletkeznének, pl. zoomoláskor ha úgy jelölöd ki a nagyítandó területet, előfordulhatna, hogy csak a magasságprofil látszik a sebességgrafikon meg nem, vagy fordítva (a pulzusmérőm szoftvere ezt úgy oldja meg, hogy csak vízszintes tengely mentén lehet zoomolni).



De ezzel a külön grafikonnal is vannak gondok: nehezen megoldhatónak tűnik, hogy együtt zoomolódjon a két grafikon (és a sebesség csak vízszintes tengely mentén zoomolható legyen). Meg jó lenne, ha dinamikusan változtatható lehetne, hogy mekkora területet kapjon a sebesség, és mekkorát a magasságprofil a képernyőből (pl 70% területet a magasságprofil, 30%-ot a sebesség). És valahová el kéne férjen a lejtőszög grafikon is. Esetleg kikapcsolható lenne, ill útvonalterv esetén ezeknek a plusz grafikonoknak nincs is értelmük. Szóval nem biztos, hogy akarok én ilyet... :o)

Az egész ott merült fel, hogy gondolkodtam egy olyan lehetőségen, hogyaszongya lejtőszög mérés üzemmód:

Az egeret mozgatva a grafikon mentén egy kis ablakban mutatta volna:
- starttól megtett táv
- pillanatnyi sebesség
- pillanatnyi lejtőszög (az előző trakckpont és az aktuális trackpont magasság- és távolságkülönbsége alapján)

Egy kattintás után pedig egy adott szakaszra lehetett volna átlagstatisztikát látni ugyanolyan kis ablakban:
- szakaszhossz (esetleg szakasz elejének távolsága is a starttól)
- a szakasz átlagsebessége
- a szakasz átlag lejtőszöge.


Ötlet? :o)
[előzmény: (48871) 2010.05.11 19:59:41]

hozzászólásai | válasz erre | 2010.05.11 19:59:41 (48871)
Öcsém, nem kedvre van Neked szükség, hanem egy menedzserre! :-)))) Az idődet illetően nem nyilatkozok, de annyit elárulok, hogy a beépített embereim még nem is kezdték el a "nekem is tetszik, sőt élni sem tudnék nélküle" fedőnevű projektet. :-)
[előzmény: (48870) jekaeff, 2010.05.11 17:53:22]

jekaeffhozzászólásai | válasz erre | 2010.05.11 17:53:22 (48870)
Nem gondoltam volna, hogy ilyen széles a felhasználói tábor.
Bárcsak időm/kedvem lenne legalább ennyi a fejlesztésre! :o)
[előzmény: (48868) -bj-, 2010.05.11 17:28:12]

-bj-hozzászólásai | válasz erre | 2010.05.11 17:28:12 (48868)
Én is használom, csak nem reklámozom. :-)
[előzmény: (48865) 2010.05.11 16:04:14]

hozzászólásai | válasz erre | 2010.05.11 16:04:14 (48865)
Légy üdvözölve! Legalább Jekaeffnek jól esik, hogy már legalább 2 ember használja azt a fícsört, amit csak 1 ember kért tőle.
[előzmény: (48863) mngc, 2010.05.11 13:05:57]

mngchozzászólásai | válasz erre | 2010.05.11 13:05:57 (48863)
Rengeteg itt a hozzászólás. Egy kicsit el vagyok veszve, lehet, hogy korábban ezt már megoldották. Van egy gpx fájlom, amiben a magasság nagyon szór, gyakorlatilag használhatatlan. Rátaláltam a jekaeff féle SRTM_HUN-ra. Nagyon jól működik, felül lehet vele bírálni a hamis magasság adatokat, szép grafikát készít. De hogyan lehet vele visszaírni az eredeti gpx fájlba a javított értékeket? Vagy erre más programot kell használni?


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