kütyük, jekaeff hozzászólásai
Mielőtt kérdeznél, olvasd el ezt: gyakori kérdések és válaszok (FAQ)

új hozzászólás | témák listája

Összesen: 3611 db hozzászólás

Lapozás: előző | ... | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | ... | következő


jekaeffhozzászólásai | válasz erre | 2012.01.23 09:21:19 (61072)
(kicsit magas lett ez a kép, lenyesegethettem volna róla a reklámot)
[előzmény: (61071) jekaeff, 2012.01.23 09:17:49]

jekaeffhozzászólásai | válasz erre | 2012.01.23 09:17:49 (61071)
Ráadásul ő lítium ELEMEKRŐL kérdezett, és ez szerintem nem elírás akku helyett:

[előzmény: (61070) Old Fairy, 2012.01.23 09:08:08]

jekaeffhozzászólásai | válasz erre | 2012.01.17 15:13:32 (60961)
621db ilyen ládaleírás van, ha jól számolom. :o)

Beleszámolva, hogy az UTF8 miatt az ékezetesek két karaktert visznek el, beleszámolva a soremeléseket, beleszámolva, hogy a HTML formázások plusz bájtokat is elvisznek.

TOP 20

[előzmény: (60959) Csuhás, 2012.01.17 14:37:23]

jekaeffhozzászólásai | válasz erre | 2012.01.17 15:00:52 (60960)
Akkor gondolom a soremelés karakter is elvisz egy bájtot (ezekben UNIX-os soremelés van, ami csak 1 bájt).
[előzmény: (60959) Csuhás, 2012.01.17 14:37:23]

jekaeffhozzászólásai | válasz erre | 2012.01.17 14:20:30 (60958)
Egyszer régen talán már én is csináltam ilyen kimutatást a leíráshosszakról, unalmas óráimban (letöltve a fullos gpx-et, és azt elemezve).

Megjegyzem az is kérdés lehet, hogy mit nevezünk 1db karakternek. UTF-8 kódolás esetén ugyanis egy magyar ékezetes karakter 2 bájtot foglal, az ékezet nélküliek pedig egyet (lehet, hogy az államnevűekben a bájtszám a fix, amit a ládaleírásra vagy az egész láda összes adatára "költhet" a kütyü, és az ékezetes karakterek miatt nem volt képes még senki rendesen megállapítani a maximális hosszt). Az államnevűekben nem valahol 3-4000 karakter "körül" van a korlát?
[előzmény: (60956) Csuhás, 2012.01.17 13:50:33]

jekaeffhozzászólásai | válasz erre | 2012.01.17 11:25:12 (60948)
Nekem úgy rémlik korábbi hozzászólásokból, hogy a ládaleírás hosszára is van egy (pontosan nem tudni mekkora) limit - néhány ezer karakter -, és aztán lehet csodálkozni a terepen, amikor a leírás kellős közepén hirtelen félbeszakad egy mondat. :o)
[előzmény: (60946) Csuhás, 2012.01.17 10:51:03]

jekaeffhozzászólásai | válasz erre | 2012.01.01 20:36:38 (60809)
:o)))

Sokkal inkább az a helyzet, hogy a Microsoft néz mindenkit óvodásnak. Az például egy hülye vicc, hogy még a szerver operációs rendszereiken is alapban el vannak rejtve a kiterjesztések meg a rendszerfájlok. Tehát még a rendszergazdákat is ovisoknak nézik.
[előzmény: (60808) kovaripeti, 2012.01.01 19:21:46]

jekaeffhozzászólásai | válasz erre | 2012.01.01 17:51:39 (60807)
Kösz! ;)
[előzmény: (60806) BiharyG, 2012.01.01 17:50:49]

jekaeffhozzászólásai | válasz erre | 2012.01.01 17:49:49 (60805)
...kimaradt, hogy a fájlt mentése, és az esetleges ".txt" kiterjesztés levágása után nem árt futtatni is a REG fájlt. :D
[előzmény: (60803) jekaeff, 2012.01.01 17:46:59]

jekaeffhozzászólásai | válasz erre | 2012.01.01 17:47:55 (60804)
... hmmmm, a vastagbetűs kiemelést elrontottam, de a fene se tudja megjegyezni, melyik fórumban mi a módi. :o)
[előzmény: (60803) jekaeff, 2012.01.01 17:46:59]

jekaeffhozzászólásai | válasz erre | 2012.01.01 17:46:59 (60803)
Mentsd le a fájlt, majd ellenőrizd, hogy a kiterjesztése .reg és nem .reg.txt.

Előfordulhat, hogy a fájl-kiterjesztések nem látszanak, ilyenkor ki kell kapcsolni az Intézőben (Windows Explorer) az "Ismert fájltípusok kiterjesztésének elrejtése" opciót. Ez az opció bekapcsolt állapotban két célközönségnek kedvez (noha alapesetben sajnos be van kapcsolva):

- az óvodásoknak
- a vírusoknak (mivel csak az utolsó "." utáni kiterjesztést rejti el az Intéző, be lehet csapni a felhasználót, pl .DOC fájlnak hazudni a vírust tartalmazó .EXE-t)
[előzmény: (60801) kovaripeti, 2012.01.01 15:41:47]

jekaeffhozzászólásai | válasz erre | 2012.01.01 14:45:10 (60798)
Sokkal olcsóbbat nem tudok, de 1290Ft-ot tudsz spórolni

http://www.argep.hu/product_537860.html

(Ügyelj arra, hogy rendeléskor az AA-akksival együtt csomagolt töltőt válaszd, ne az AAA-s verziót).
[előzmény: (60797) walky, 2012.01.01 14:31:32]

jekaeffhozzászólásai | válasz erre | 2011.12.29 21:15:13 (60767)
* Olvasnivaló: http://sylverrat.hu/faq/
* Térképek: http://turistautak.hu/garmin.php
* A térképeken belül legegyszerűbb megoldás, ha ezt a fájlt bemásolod a kütyü \GARMIN alkönyvtárába: LINK

[előzmény: (60766) laccoka, 2011.12.29 21:06:23]

jekaeffhozzászólásai | válasz erre | 2011.12.13 22:13:14 (60620)
- Lehet azért ez még akkuprobléma is. Bekapcsoláskor kicsit megugrik az áramfelvétel, ha gyenge az akku, akkor ez megviselheti. A 60CSx kijelzője ilyenkor "becsíkozódik", és úgy tűnik el kép. Tesztelése: új akkuval vagy elemmel, esetleg mini-USB kábellel egy PC-re dugni és úgy bekapcsolni a kütyüt (akár akku nélkül is működik ilyenkor, mivel ekkor az USB-ről veszi a tápot).
- Másik lehetőség: Hard reset, ha a kütyü csak "megbolondult" egy kissé valami miatt. A kütyü kikapcsolt állapotában Page + Enter lenyomva tart, majd Power lenyomása és felengedése. Az etrex rákérdez, hogy törölni akarod-e az összes beállításodat.
- Még memóriakártya (microSD) hiba lehetne, amit a kártya kivételével lehetne vizsgálni. De Venture HC nem kártyás, így ez kiesik.
[előzmény: (60619) csz58, 2011.12.13 21:48:46]

jekaeffhozzászólásai | válasz erre | 2011.12.04 18:51:50 (60553)
Itt azt írják, hogy akár 3-4x is érdemes megpróbálni azt a Webupdater-t: http://www.gpsfaqs.org/faqs/garmin/xseries/gvistahcx/Usage.html

60CSx-nél is volt ilyesmi probléma, azon külön is fel lehetett telepíteni a chipset firmware-t (GPSChipsetTypeG_300.exe). A Vista HCxfirmware-t is megtaláltam külön, de nem .exe, hanem RGN formátumban: http://www.gawisp.com/perry/chipset_firmware/Type_M/
[előzmény: (60552) zayd, 2011.12.04 18:39:01]

jekaeffhozzászólásai | válasz erre | 2011.12.01 07:41:53 (60528)
Jaaaaaaa, úgy könnyű, hogy magyar tizedesvesszőt használsz.
Próbáld meg tizedesponttal, úgy viszont már szépen a Dunában landolsz! ;)
[előzmény: (60527) Mikulás trágársága elüldözött, 2011.11.30 21:29:04]

jekaeffhozzászólásai | válasz erre | 2011.11.30 19:49:41 (60523)
Kipróbáltam N47° 30.15' E19° 02.44' -el is (hátha csupán félreolvasásról van szó), de ez sem sem vált be... hacsak nem akarsz pancsolni egy kicsit az 5°C-os Dunában. :D
[előzmény: (60521) diego, 2011.11.30 19:23:12]

jekaeffhozzászólásai | válasz erre | 2011.11.30 19:39:09 (60522)
Az illető inkább vegyen egy rendes GPS-t vagy olvassa le a címet, ne szórakozzon kamu-koordinátákkal. :o)
[előzmény: (60521) diego, 2011.11.30 19:23:12]

jekaeffhozzászólásai | válasz erre | 2011.11.18 21:12:30 (60418)
Azért még az a kis fogyasztás is 650-700Ft-nyi villanyszámlát generál egy hónapban, ha ez számít valakinek! ;)

Alapul 19W-os "idle" fogyasztást feltételeztem napi 24 órában, 1db "Green" HDD-vel, ezen mérési adatok alapján (25W két HDD-vel). Ez csupán kb 16%-kal kisebb fogyasztás, mint amivel a hűtőszekrényünk beéri.

(Mostanában kissé rágyúrtam a fölös fogyasztók kiirtására...)
[előzmény: (60417) Zahy, 2011.11.18 20:57:37]

jekaeffhozzászólásai | válasz erre | 2011.11.17 21:17:45 (60394)
Mi újság az új telefonnal (Galaxy Xcover?), vannak már tapasztalatok?
[előzmény: (60393) Mikulás trágársága elüldözött, 2011.11.17 21:16:10]

jekaeffhozzászólásai | válasz erre | 2011.11.17 13:01:35 (60380)
Ártani nem árt, de ha csak 1000Ft-tal is drágább egy azonos tudású Sata3-as HDD, akkor már nem igazán éri meg azt venni. Az SSD-k közül is csak a leggyorsabbak képesek átlépni a 300MB/s-et.
[előzmény: (60379) scele, 2011.11.17 12:49:00]

jekaeffhozzászólásai | válasz erre | 2011.11.17 11:29:18 (60376)
Nahát, ez szomorú. :o)

Erre majd térjünk vissza, amikor a vinyók átlépik a 300MB/sec sebességet, ami a Sata2 felső határa. :DDD
Persze ha neked elég, hogy baromi gyorsan írsz/olvasol a vinyó cache-éből (ami max 32MB adatot képes fogadni, oszt' csókolom), akkor vegyél csak nyugodtan Sata3 vinyót.
[előzmény: (60373) scele, 2011.11.17 11:25:25]

jekaeffhozzászólásai | válasz erre | 2011.11.17 11:24:59 (60372)
...illetve itt érdemes nézelődni: http://www.argep.hu/main.asp?suche=2tb&sort=preis


Ha valahol nagyon jó árat látsz egy üzlet neve mellett, akkor ne örülj előre, csak kattints a linkre (üzletre), mire odaérsz, lehet, hogy már 2x-es ár fogad (az argep.hu nem képes lépést tartani az árvízzel).
[előzmény: (60370) scele, 2011.11.17 11:17:05]

jekaeffhozzászólásai | válasz erre | 2011.11.17 11:21:37 (60371)
Samsungokat nézegess, az ő áraikat érintették a legkevésbé az áradások.
[előzmény: (60370) scele, 2011.11.17 11:17:05]

jekaeffhozzászólásai | válasz erre | 2011.11.17 11:08:49 (60363)
Ha ennyire fontos a SATA3 sebesség, akkor már inkább SSD ;)
[előzmény: (60359) scele, 2011.11.17 11:01:40]

jekaeffhozzászólásai | válasz erre | 2011.11.17 09:16:27 (60351)
Van, 6.11:

http://garmin.hu/naviguide-magyarorszag-v61

[előzmény: (60349) kutyu, 2011.11.17 08:57:27]

jekaeffhozzászólásai | válasz erre | 2011.11.15 10:18:01 (60297)
:o)))

Mármint az Xcovert?

Bármi előfordulhat, az Xcover-ől még nem jelent meg alaposabb teszt. Ki tudja, lehet, hogy épp a gyengébb műszaki tartalom miatt ez lesz az első okosteló, ami akár 3 napig is kibírja egy töltéssel. De még az is lehet, hogy a drabálisabb kinézett miatt jobban bírja az ütéseket/eséseket. Mintha a Defy-ről olvastam volna, hogy egy 1-2 éves gyerkőc simán beroppantotta a kamerát rajta, ahogy játszott vele. :o)
[előzmény: (60296) Mikulás trágársága elüldözött, 2011.11.15 10:09:38]

jekaeffhozzászólásai | válasz erre | 2011.11.15 09:13:23 (60294)
Jó darabig én is a Galaxy Xcover-re vártam, amíg rá nem jöttem, hogy:
- csúnyább mint a Defy+ (persze ez nyilván ízéls kérdése)
- nagyobb mint a Defy+ (pedig a kijelzője ugyanakkora)
- műszakilag gyengébb mint a Defy+ (kisebb felbontású LCD és kamera, lassabb processzor, gyengébb akku)

... így végül a Defy+ mellett döntöttem és azt nem veszem meg. :o)
[előzmény: (60292) yano6ard, 2011.11.15 07:37:39]

jekaeffhozzászólásai | válasz erre | 2011.11.14 21:55:17 (60279)
Kösz az első kézből származó infót, akkor most megspóroltál nekem 70kHUF-ot, amit így nem szórok el ilyen marhaságra. :o)
[előzmény: (60278) Yoss, 2011.11.14 21:53:10]

jekaeffhozzászólásai | válasz erre | 2011.11.14 21:49:22 (60277)
Az eddig elhangzottak alapján a 8-10-zel osztás a reális. :o)
[előzmény: (60274) Mikulás trágársága elüldözött, 2011.11.14 21:47:36]

jekaeffhozzászólásai | válasz erre | 2011.11.14 21:48:38 (60275)
De telefonként használva miért zabálná a kijelző az energiát?

Mondjuk csörög a teló, egy kicsit élvezkedik a hardvere, Chuck Norris pörög 3D-ben 200fps-sel vagy mittudomén, de ha a fülemhez emelem, akkor a proximity szenzor kikapcsolja a kijelzőt (és így ez az extra fogyasztó azonnal kiesik), nem?
[előzmény: (60269) Yoss, 2011.11.14 21:42:12]

jekaeffhozzászólásai | válasz erre | 2011.11.14 21:43:50 (60271)
Az a Defy specifikációjában volt. Itt 384 órát hazudtak. :o)
[előzmény: (60268) Mikulás trágársága elüldözött, 2011.11.14 21:41:49]

jekaeffhozzászólásai | válasz erre | 2011.11.14 21:31:53 (60266)
No, akkor még várok, amíg fejlődik az akkutechnológia.
Bár sajnos a telefonok is velük együtt fejlődnek, így a világ összes energiája nem lesz elég nekik.

Én amúgy minimális net-használatra gondoltam, ha az ember idegen helyen van, vagy unalmas workshop-on, akkor elfoglalja magát, vagy játszik valami egyszerű játékkal. Ezt leszámítva a telefont telefonálásra használnám. Így sem bírnak ki 1-2 napnál többet ezek a vacakok?
[előzmény: (60265) Yoss, 2011.11.14 21:27:07]

jekaeffhozzászólásai | válasz erre | 2011.11.14 21:21:10 (60264)
egy egészen kicsit jobb cpu elfért volna benne - van olyan, de azt már Defy+ -nak hívják (és még az akksija is erősebb, meg az op'rndszere is modernebb, energiatakarékosabb (?)).

Gondolkodtam én is egy Defy+ megvásárlásán, de egyelőre kissé nagyon taszít a várható alacsony üzemidő. Persze papíron lehet hazudni 16 napokat, de eddig mindenhol 2-3 napról olvastam. Én pedig nem ehhez vagyok szokva... Sokkal inkább ahhoz, hogy amikor vasárnaponként felrakom a Samsung B2710-est a töltőre, akkor még van 3-4 egységnyi töltés az ötből. :o) Ha a Defy+ napi 10-20 perc telefonálással nem bírna ki legalább 4-5 napot, félő, hogy kissé falhoz vagdosós kedvemben lennék. Ahhoz meg egy kicsit drága a kütyü.
[előzmény: (60263) Yoss, 2011.11.14 20:57:01]

jekaeffhozzászólásai | válasz erre | 2011.11.14 10:00:51 (60207)
A Vista-nak gyengébb a GPS vevő egysége, kissé zártabb helyen (erdő, nagyváros) könnyebben elveszti a jelet, valamint lassabban is "találja meg" a műholdakat, mint az említett eTrex H. A 24MB-os térképmemória nem túl bőséges, de ha csak az éppen használt országrészt töltöd fel rá (pl. csak a Kelet- vagy Nyugat-magyarországi tájegységeket), akkor elég lehet.

Akkor már inkább egy eTrex Legend HCx, bár az már 48900Ft.
[előzmény: (60206) fodorpeter, 2011.11.14 09:54:24]

jekaeffhozzászólásai | válasz erre | 2011.11.11 08:42:20 (60197)
Már aki megteheti. ;)

A céges SIM kártyát használva nem én határozom meg, hogy milyen szolgáltatás legyen rajta (pl. internet).
[előzmény: (60196) Vicky-Misi-Jázmin, 2011.11.11 08:31:23]

jekaeffhozzászólásai | válasz erre | 2011.11.10 20:33:31 (60195)
Engem technikai okból taszít a TrekBuddy bitmap-es mívolta. A bitmap-es térkép hatalmas visszalépés a vektoroshoz képest. Gondolom nagyításnál mindenféle elmosódások meg recéződések jelennek meg (még akkor is, ha több mélységig generáltál szelvényeket), meg a betűk is csúnyák lesznek...

Ráadásul mivel a bitmap-es térképprogramoknál eleve elbuktad az úton történő navigáció lehetőségét, mivel szegény szoftver nem tudja kitalálni, hogy azon a képen mit kell úttestként értelmeznie. Igaz, a Mario Advisor se tud ilyet, de ha még egy kis időt szánt volna rá a programozó srác, akkor azt is tud(hat)ná. De sajnos a fejlesztése teljesen leállt, és már csak a net legmélyebb bugyraiból lehet előásni a programot is. Gondolom a Garmin is ejnye-bejnyézett, hogy egyáltalán elkészülhetett ilyen program. Mondjuk senki se tiltotta, hogy ŐK csináljanak ilyesmit, de nekik ez valószínűleg nem volt fontos piaci szegmens... :o)
[előzmény: (60194) Vicky-Misi-Jázmin, 2011.11.10 17:55:03]

jekaeffhozzászólásai | válasz erre | 2011.11.10 15:28:14 (60193)
Lehet, de egyik sem az igazi:

- bbtracker : csak nyomvonalrögzítésre
- TrekBuddy: bitmap-es térképeket jelenít meg, ill. trackrögzítésre is alkalmas. Vannak hozzá szép "skin"-ek, pl szintemelkedés és csökkenés, pillanatnyi sebesség, átlagsebesség szépen képernyőkbe szervezve. Én csak ezekkel használom. Mivel csak bitmap-es térképeket fogad, ezért térkép megjelenítésre nem is használom, roppant macerás a szelvények előállítása, amik aztán rengeteg helyet elfoglalnak a memóriakártyán.
- Mario Advisor: megjeleníti a Garmin térképszelvényeket (tehát vektoros, szépen nagyítható/kicsinyíthető), track is rögzíthető, de nem tudsz vele "navigálni". Sem légvonalban, sem úton tervezve. maximum helyesen rajzolja be a térképre, hogy épp hol vagy. A térkép görgetése elég lassú, a látható képernyő dupláját számolja ki egy-egy alkalommal, ha ebből "kifutsz", kb. 3 másodperc míg eláll az új nézet.

Ezeken felül igencsak bele kell nyúlni a készülék lelkivilágába, hogy kényelmesen használhatóak legyenek a programok. Mindenféle szervizmenükben mászkálva, meg a fájlrendszerében turkálva:

- Engedélyezni lehet, hogy a JAVA alkalmazások a háttérben is fussanak (pl. trackrögzítés). Ha kilépsz egy JAVA programból, akkor ezután megkérdezi, hogy fusson-e a háttérben. Ha viszont nem lépsz ki, csak pl 1 percig nem piszkálod a telefont akkor sajnos bekapcsol a képernyőzár ami felfüggeszti a program futását (tehát pl nem történik trackpont rögzítés, ill térkép mozgatás, amíg csak megint fel nem éleszted a telefont). Ha kilépsz a programból, akkor viszont a képernyőzár bekapcsolódása után is fut a program a háttérben).
- Ki lehet kapcsolni az idegesítő kérdéseket, hogy elérheti-e a JAVA program a memóriakártyát, illetve bekapcsolhatja-e a GPS-t.
[előzmény: (60192) Moda111459742, 2011.11.10 15:11:46]

jekaeffhozzászólásai | válasz erre | 2011.11.04 12:53:08 (60032)
:o)))))
[előzmény: (60031) diego, 2011.11.04 12:50:24]

jekaeffhozzászólásai | válasz erre | 2011.11.04 12:47:17 (60029)
Inkább az kéne, hogy az első 10 hozzászólás esetén egyből egy olyan rendkívül egyszerű oldalon találná magát a felhasználó, amin két link van: az egyik az eddig összegyűjtött tudásanyagra (FAQ) vinné tovább (felhívva a figyelmét, hogy egy tipikus kezdő kérdéseinek túlnyomó többségére meg fogja találni ott választ), a másik pedig a fórumra.
[előzmény: (60027) Mikulás trágársága elüldözött, 2011.11.04 12:30:12]

jekaeffhozzászólásai | válasz erre | 2011.11.01 02:17:46 (59865)
Igent tudtam, a döntésem okáról korábban már értekeztünk, itt:
http://turistautak.hu/forum.php?action=thread&id=kutyuk&message_id=271317
[előzmény: (59864) 2011.11.01 00:09:44]

jekaeffhozzászólásai | válasz erre | 2011.10.31 13:22:42 (59851)
Az a kérdés, hogy az ergométer szoftvere mennyire pontosan számolja a megtett utat.

Amennyire pontosan számolja, elvileg annyira pontosan állítja is be a Bushido-n a "meredekséget", nem? A HRM fájlba ő különben sem távolságadatot tesz, hanem sebességadatot, amit megszorozva az időintervallummal (5 sec) majd szummázva az addigi (hasonló elven számolt) távolsággal megkapod az aktuális távolságot.

Visszatérve a kérdésedre, hogy mennyire pontosan számolja a megtett utat: próbáltad már "összenézni" a Sporttracks-ben az eredeti GPX profilját és a Bushido-ét? Ha elég jól egybeesnek, akkor nincs probléma.
[előzmény: (59849) 2011.10.31 13:16:10]

jekaeffhozzászólásai | válasz erre | 2011.10.31 12:57:34 (59848)
Ha jól értem elméletileg az ergométeren letekert útvonal szintprofilja teljesen azonos kellene legyen az eredeti GPX szintprofiljával.

Ezesetben nekem rém egyszerűnek tűnik a megoldás: a Bushido_Post_Processor.exe -nek két bemeneti fájlra lenne szüksége:

- fitlog (sőt én a helyedben a HRM-et használnám, és csak a program kimenete lenne fitlog!)
- "eredeti" simított gpx

Szépen beolvasnád a simított GPX-et (láncolt listába, vagy akár dinamikus tömb ismegfelel, ha az jobban kézreáll), majd pedig sorról-sorra olvasva a fitlog (vagy esetleg HRM, ahogy ajánlottam) fájlt az megkeresed (a láncolt listában/dinamikus tömbben) az aktuális távolsághoz tartozó magasságadatot (itt nyilván egy rém egyszerű lineáris interpoláció kell a hozzá legközelebbi két szomszédos trackpontból). Ezután a programból előállítod az új fitlog fájlt.

Ha egyből a HRM fájlt olvasnád, kimaradna két felesleges lépés: Sporttracks-ban HRM megnyitás majd FITLOG exportálás. Elegendő lenne csupán az általad előállított FITLOG fájlt beolvasni. Sőt, ha már a két fájl összedolgozásáról beszélünk, akár még GPS koordinátákat is rendelhetsz minden egyes fitlog-beli trackponthoz. Bár a Föld gömbölyű de egy-egy trackpont közt nem lesz akkora távolság, hogy ne lenne megfelelő a lineáris interpoláció külön a Lat és külön a Lon adatokra.

Én így csinálnám. Sőt: most, hogy megvan a simító algoritmus akár az SRTM_HUN is kihagyható a játékból (bár az legalább ad egy vizuális visszacsatolást, ha megnézed egymáson az eredeti és a simított grafikont).
[előzmény: (59846) 2011.10.31 11:16:39]

jekaeffhozzászólásai | válasz erre | 2011.10.31 09:56:20 (59844)
http://www8.garmin.com/manuals/eTrexLegendHCx_OwnersManual.pdf

(Magyar leírás nincs elektronikus formában, kár kérdezősködni, úgyis az lesz rá a válasz, hogy "meg lehet venni a boltban." De az angolból ugyanúgy meg lehet érteni az alapokat.)
[előzmény: (59843) don10178, 2011.10.31 09:53:18]

jekaeffhozzászólásai | válasz erre | 2011.10.31 09:28:34 (59842)
"... túl alacsonyra jön ki az eredeti maximális emelkedési szög"

No és HONNAN tudod, mennyi volt az eredeti maximális emelkedési szög? Hacsak nem földmérő cuccokkal számoltad, akkor a kütyü hazudhatott menet közben bármilyen fals értéket. Pl. a szinte tükörsima terepen végzett edzéseim esetén is (40km, 5m-nyi szintemelkedéssel!) elég meglepő maximális emelkedési szögeket ír ki a végén a Polar pulzusmérőm az edzésösszesítőben (3-4%, néha 5-8%-os max. lejtőszöget is!), noha az 5 másodperces finomságú grafikonján semmi "gyanús" nem látszik. A Gauss inkább csak az emelkedők elejéből és végéből csippent le valamennyit, hacsak nem nagyon rövid az emelkedő, a maximális meredekséget érintetlenül kellene hagyja (ellenőrizz le egy ilyen edzést az SRTM_HUN-ban, megjelenítve az eredeti és a simított szintmetszetet is).
[előzmény: (59840) 2011.10.31 09:08:28]

jekaeffhozzászólásai | válasz erre | 2011.10.30 18:16:23 (59819)
Hát nem tudom, a dinamikus tömb nekem sose volt szimpatikus. Mégis csak egy tömb. Az meg olyan BASIC-es. :o)

No mindegy, az imént már elküldtem a rogyásig kommentezett megoldásomat, ezek szerint kár volt rászánnom azt a másfél órát. :D
[előzmény: (59815) 2011.10.30 17:45:22]

jekaeffhozzászólásai | válasz erre | 2011.10.30 13:12:40 (59809)
Hmmm, most kipróbáltam egy olyat, hogy 200.000 elemen végigmenve minden elemre képezek egy szummát az őt megelőző és őt követő 20 elem egy adott értékével. Ezzel próbáltam utánozni a gauss szűrés során alkalmazott megoldást. Meglepő, de a TList 4-5x gyorsabb volt mint a saját megoldásom.

Mivel ez azonban még ilyen nagyon magas elemmennyiség mellett is csupán 109 milliszekundum kontra 547 milliszekundum futásidőt jelentett, ezért most nem írom újra az egész SRTM_HUN-t. :o) Nagyon mélyen bele kellene turkálni a lelkivilágába.
[előzmény: (59796) bpeti68, 2011.10.30 07:42:57]

jekaeffhozzászólásai | válasz erre | 2011.10.30 10:08:39 (59801)
Illetve úgy nézem, nem is fordított sorrendben szúrom be az elemeket, hanem rosszalkodtam, és átírtam a gyári unit megfelelő sorát, hogy nekem tetsző módon múkodjon. Szerintem elég bután csinálták az eredetit: sokkal gyakoribb, hogy az ember egyből a grafikon végére szúrjon be egy elemet (és emiatt jobb az én megoldásom, ami hátulról előrefelé haladva keresi, hová kell beszúrni azt), minthogy valahová középre. Amennyiben pedig középre szúrna be valaki, statisztikai alapon az én meoldásom pont ugyanolyan gyors, mint a gyári.
[előzmény: (59800) jekaeff, 2011.10.30 09:59:09]

jekaeffhozzászólásai | válasz erre | 2011.10.30 09:59:09 (59800)
Pl. egy TList leszármazott elemeinek törlése is nagyságrendekkel gyorsabb visszafelé mint előre.

Sőt, nem véletlenül adom hozzá a grafikon Y értékeit hátulról előrefelé haladva (X koordináta szerint) az SRTM_HUN-ban, mert így sokkal gyorsabb. :o)

Normál sorrendben haladva ugyanis a 10000. pont beszúrásakor megvizsgálná az előző 9999 pontot, hogy tényleg kisebb-e az X értékük, és csak miután ezen végigérve elhitte, hogy nem vagyok hülye és nem valahová (X koo szerint) középre karok beszúrni egy újabb grafikonpontot, utána csinál valamit. Hátulról előrefelé haladva viszont már rögtön az első lépésben sikerélménye van a gyári függvényábrázolásnak, és így a működés is jóval gyorsabb (főleg 10000-es nagyságrend esetén).
[előzmény: (59799) bpeti68, 2011.10.30 09:50:15]

jekaeffhozzászólásai | válasz erre | 2011.10.30 08:46:38 (59798)
...például érdekes tapasztalat volt, amikor az SRTM_HUN-ban a szűrő-értékeket (Gauss és vertikális) közvetlenül a megfelelő FloatSpinEdit ojjektumok Value tulajdonságaiból (vagy mifenéiből) vettem az összehasonlításoknál.

Valahogy úgy, hogy:

if FloatSpinEdit1.Value < VizsgaltErtek then CsinaldEztMegAzt

Érdekesmód radikális gyorsulást értem el azzal az egyszerű trükkel, hogy:

Var a : double

...

a:=FloatSpinEdit1.Value;
if a < VizsgaltErtek then CsinaldEztMegAzt
[előzmény: (59797) jekaeff, 2011.10.30 08:20:50]

Lapozás: előző | ... | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | ... | következő

Egy lapon megjelenő sorok száma:


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