turistautak.hu

, 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: 1089 db hozzászólás

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

hozzászólásai | válasz erre | 2010.05.11 09:39:31 (48850)

Még egy kérdés, de ez csak mellékvágány:
ha egy olyan trekkem van, ami 1000 pontból áll, de az egész trekk egy 150 m-es úton történő oda-vissza járkálás, akkor (100 m-es sugár mellett) mind az 1000 pont Gauss simításához mind az 1000 pontot (különböző súllyal) felhasználja, mert a számított pont és a vizsgált pont (felhasználjam-e vagy sem) közötti légvonalbeli távolságot nézi
VAGY ez nem így van, mert a trekken mint "kiterített" szögletes úton nézi azt, hogy 100 méternél közelebb van-e?

Én az utóbbira tippelek, de ki tudja?!

[előzmény: (48849) jekaeff, 2010.05.11 09:10:37]

	hozzászólásai \| válasz erre \| 2010.05.11 02:49:43 (48847)
Bocs Robert, összetévesztettelek Mark-kal :-) Robert jó gyerek! [előzmény: (48843) 2010.05.11 01:48:30]

	hozzászólásai \| válasz erre \| 2010.05.11 02:32:45 (48846)
Bármilyen választ elfogadok, csak azt nem ,hogy ez sem lenne jó megoldás, mert mi van akkor, ha kimarad pár mp a kütyü hibájából (ld korábbi hsz-ainkat) [előzmény: (48845) 2010.05.11 02:27:40]

hozzászólásai | válasz erre | 2010.05.11 02:27:40 (48845)

Asszem én is negatív alak vagyok, mert nem hagylak élni...

Szóval bringázgatok a korábban említett útvonalon, de most jellemzően az emelkedő különböző pontjairól fordulok vissza [lehet fikázni :-), de jellemzően asztmatikus köhögés mellett:-( ]
A korábban említett magassági torzításon már túltettem magam, viszont indirekt módon újból belefutottam. A progimmal a grade-et nézegetem mostanában, de minden ilyen túra végén a Gauss féloldalassága kihat erre is, hiszen a trendszerű emelkedőn a track végét csillapítja. Ha nem vágnám szét két részre a visszafordulásnál, még rosszabb lenne a helyzet.

Egyébként olyan 8-10%-ról van szó, amit az utolsó 100 méteren fokoyatosan tompít le 3-3,5%-ra tévesen.

Továbbgondolva, a vissza nem fordulások esetén általában azért nincsen gond, mert egyrészt a természet általában ívelt (legalábbis belföldön még a hegycsúcsok sem annyira "hegyesek", másfelől az útépítők sem építenek ugratókat. A horhosok és bevágodásoknál már inkább elveszik pár méternyi "mélység" a Gauss miatt, de hát egy völgyben amúgy is rosszabb a vétel, tehát ott ez kisebb hiba, mint ami a vétel pontatlanságából jön.

Egyelőre úgy tompítottam a dolgot, hogy a Gausst levettem 100 méterről 50-re, aminél szerintem általában már felülbecsüli 10-15 méterrel a szintemelkedést, de aztán eszembe jutott, hogy a tükrözés mellett megoldás lehet(ne) az hogy ha nemcsak nem távolság alapú, hanem trackpontszám alapú Gauss-t is lehetne választani.

Az ajánlott 100 méteres esetén kétszer kb 25-30 pontot használ fel a tipikus 3-4 méteres távolság alapú trackelési beállítás mellett, azaz 50 méternél már csak ennek a felét. Ez még bringánál is igaz, hiszen 8-10%-nál nem jellemző a 15km/h-nál nagyobb sebesség felfelé.

Még egy dolog szól a pontszám mellett (akár kizárólagosan, akár szűrőként lenne használva).

Jómagam ugye jelenleg 1,5 méterest használok, tehát gyakorlatilag másodpercest. Ez lefelé nagy sebesség mellett már csak 7+7 ponttá (100m, 50-51 km/h) redukálja a Gauss-hoz használt pontokat, amikor a nagy sebesség amúgy is pontatlanabb vétellel jár(hat) együtt, míg síkon meg, amikor feltehetően jobb a vétel, dupla annyi pontot használ.

Tehát miért nem azt lehet beállítani, hogy

A) Hány pontot használjon fel előtte (ha van) és utána (ha van)

Vagy ami még jobb lenne

B) A mostani Gauss sugárt használva , DE MAXIMUM hány pontot használjon fel előtte (ha van) és utána (ha van)?

Í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.

Még azt is látom magam előtt :-), hogy a három user profil pont alkalmas lenne erre a három esetre. Nem akarok tolakodó lenni, de talán ez a megoldás nem is jelentene akkora bonyolítást.

Na, egyelőre ennyi.

[előzmény: (47712) jekaeff, 2010.03.26 19:34:44]

	hozzászólásai \| válasz erre \| 2010.05.11 01:51:04 (48844)
Ja, ezért mondják azt a garminék, hogy a 78-as sorozat a 76-os utóda, s áttételesen innen jön, hogy a 60-as árzuhanása után jöhet a 60+2=62. A 78-as alapján ki lehet nagy vsz-gel találni a 62-es sorozat speckóját. [előzmény: (48836) tibbi, 2010.05.10 21:54:51]

	hozzászólásai \| válasz erre \| 2010.05.11 01:48:30 (48843)
Egyébként ez a Robert gyerek elég negatív alak. Okos fickó lehet, de ha valamit nem tud, akkor a yahoo fórumon ír valami vicces általános megjegyzést, amivel gyakorlatilag 0-ra csökken a vsz-e, hogy más megpróbáljon agyalnia az adott felvetésen [előzmény: (48825) jekaeff, 2010.05.10 18:41:50]

	hozzászólásai \| válasz erre \| 2010.05.10 11:07:12 (48810)
nem is nemis :-) [előzmény: (48809) 2010.05.10 11:04:55]

	hozzászólásai \| válasz erre \| 2010.05.10 11:04:55 (48809)
Most, hogy visszafelé átfutottam a fórumot, úgy tűnik, hogy nemis volt szó a kb 2 hete bejelentett 78-as sorozatról, úgyhogy a 3 tagjának egyike: https://buy.garmin.com/shop/shop.do?cID=145&pID=63602#specsTab [előzmény: (48808) 2010.05.10 10:43:33]

hozzászólásai | válasz erre | 2010.05.10 10:43:33 (48808)

Érdekesség yahoo fórumról:
"Noticed in my sale flyer that REI will be selling the 60Csx for $199.99
beginning 05/21/2010 and running through 05/31/2010. Don't know if this beats
other pricing on-line but worth considering if you want one of these gps
work-horses!

With this steep (For Garmin) sale price I wonder if Garmin is going to be
phasing out the 60Csx."

" It's a serious hint. Last Thanksgiving REI was selling OR300s for $250. Now
you can't buy an ORx00 from REI, only ORx50s."

A 62-es (ill. 78-as) vonalhoz...

	hozzászólásai \| válasz erre \| 2010.05.08 13:30:13 (48788)
Én tavaly sokat jártam munkaügyben Törökországban, s ott gond volt azzal, hogy a két fajta i közül a pont nélkülire nem tudtam rákeresni. [előzmény: (48785) jekaeff, 2010.05.08 11:11:45]

	hozzászólásai \| válasz erre \| 2010.05.08 00:32:44 (48780)
Kurva jó! Ha a 6.12.4-et német dll-lel használom, akkor eltűnik a csupa nagybetű a feliratoknál, de megmarad helyesen az ű. Lehet, hogy angolul még a 6.13.2-ben sem hullámos az ő?? [előzmény: (48779) 2010.05.08 00:28:46]

	hozzászólásai \| válasz erre \| 2010.05.08 00:28:46 (48779)
Szóval a legutolsó helyes verzió az ő és ű szempontjából a 6.12.4 (még mindig csupa nagybetűkkel, tehát akkor állt vissza a nem csupa nagybetűre a garmin, amikor elcseszte az ő-t ás ű-t), úgyhogy a kérdésem a 6.13.2 helyett a 6.12.4-re illetve a 6.15.11-re vonatkozik [előzmény: (48778) 2010.05.08 00:09:05]

hozzászólásai | válasz erre | 2010.05.08 00:09:05 (48778)

Helyesen 6.11.5

Nem szenyózni akarok, csak ha már dual mapszósszal nyomom, akkor gondoltam, hogy megnézem a régieket. A 6.11.5 és a 6.11.6 mindegyike szenzációs, ugyanis a waypointokat gyorsan kezeli, amin nem lepődtem meg, hiszen a 6.13.7 is gyors ebben, viszont nemcsak hogy normális az ő és az ű, de ráadásul a 10000 trekkpontnál többel rendelkező gpx-eket is gyorsan megnyitja, szemben a 6.13.7-tel, ami egyfajta etalon verzióként van propagálva.

A 6.11.6 már magyarul is telepíthető, picit csúnya a csupa nagybetű, ezért megnézem a 6.13.2-t is, s ha az is gyors a nagy gpx-eket illetően, akkor lehet hogy ráállok kizárólag erre.

Van valami olyan dolog, amit a normál változáskövetési doksi elfelejt közölni, viszont a 6.13.2-ben nincs meg vagy ha hiba, akkor megvan, míg a 6.15.11-ben megvan, vagy ha hiba, akkor már nincs meg?

[előzmény: (20708) jekaeff, 2007.10.03 21:22:27]

	hozzászólásai \| válasz erre \| 2010.05.01 12:11:22 (48684)
Akkor most csodálkozom, mert felraktam ide is a 6.13.7-et és 9100 wp-vel tök gyors dolgozni. Mp-en belül lehet kijelölni mindet. [előzmény: (48683) 2010.05.01 12:00:14]

	hozzászólásai \| válasz erre \| 2010.05.01 12:00:14 (48683)
Leteszteltem gyorsan (1000, 1500 és 2250 wp-vel), s körülbelül négyzetes a lassulás, azaz 50%-kal több pont picivel több mint kétszeres idő. Konkrétan 2250-nél már picivel több mint fél perc az összes kijelölése. Ezen a gépen nincs 6.13.7-es, de csodálkoznék ha az gyorsabb lenne. [előzmény: (48682) 2010.05.01 11:50:52]

	hozzászólásai \| válasz erre \| 2010.05.01 11:50:52 (48682)
Én a 6.15.11-et tesztelem mondjuk bő egy hete és 1000 wp-ig egész tűrhető. Persze 20e pontnál már a CTRL+A-val kinyírtam. :-) [előzmény: (48675) jekaeff, 2010.04.30 22:29:25]

hozzászólásai | válasz erre | 2010.04.28 17:23:42 (48606)

Ugy erted, hogy sem usb hattertarkent, sem Portable Mediakent? Es az xp alatt az intezoben nem latod vagy az eszkozkezelo alatt sem. Az egyik fiamnak egy szar sony-ja van, nagyon instabilan latja az xp, ha latja akkor is oda-vissza cserelgetem az mtp es az usb driver-t. Ez lenne a tanacsom. Igaz, hogy ehhez latnia kell legalabb az eszkozkezezeloben.

Egyebkent meg a masik (Sansa Clip 2gb) mp3-sal is jo sokat jatszottam, mert annak a kapacitasa 1.85 giga (ami ertheto, hisz a rendszernek is kell kb 150 mega), viszont ha rateszek 1.2 giga zenet, akkor 1.4 giga foglalt helyet jelez. Dos alatt is nezegettem a dir parancs osszes attributuma mellett, de nem talaltam sem nagymeretu rejtett, sem nagymeretu rendszer fajlt. Aztan formaztam xp-vel, ranyomtam a zenet, akkor meg csak 1.2 giga volt foglalt, aztan, amikor a sansa indult s megtalalta a zneet, meg vmit telepitett, megint eltunt a 200 mega.

Vajh miert?

[előzmény: (48597) yoggi, 2010.04.27 20:35:01]

	hozzászólásai \| válasz erre \| 2010.04.26 12:21:04 (48588)
A leap second jelenséggel kapcsolatban szeretnék még valamit leszögezni. Hoppá, most látom, hogy a feleségem közele :-)) [előzmény: (48587) rekasi, 2010.04.26 10:22:38]

hozzászólásai | válasz erre | 2010.04.21 22:22:53 (48512)

Igen, így dual.

Én is ezt csináltam, de hiába másolom be a dll-t, akkor is csak angol, mert mivel nem telepítem, hanem csak kicsomagolom, így szerintem nem is keres nyelvi dll-t. A 6.13.7-nél még volt Mapsource_lang.dll, az újnál már csak a HUN, ENU stb van. Még úgy sem ment, hogy a HUN-t átírtam ENU-ra.

Viszont én a régit telepítettem, az újat nem, Te meg pont a fordítottjáról írsz. Lehet, hogy így kellene megpróbálnom, csak féltem, hogy ha felülvágom a registry-ben a bejegyzéseket az újnak a telepítésével, akkor a régi már nem keresi a dll-t, így az átváltozik angollá.

[előzmény: (48511) jekaeff, 2010.04.21 22:04:40]

	hozzászólásai \| válasz erre \| 2010.04.21 20:43:06 (48509)
Guruk! Ha dual Mapsource-t szeretnék, de mindkét esetben magyarul, akkor mi a legegyszerűbb (=minimalizált registry piszkálás) megoldás? Faq-ot már néztem.

	hozzászólásai \| válasz erre \| 2010.04.21 09:44:43 (48494)
Bocs, ma reggel úgy általában nem megy a pontos gépelés. [előzmény: (48493) 2010.04.21 09:44:00]

	hozzászólásai \| válasz erre \| 2010.04.21 09:44:00 (48493)
"Már az is fura, hogy a limit igazi mérete sincs hivatalosan deklarálva.." Mert nem tudják. Majd az ügyfeke által jelzett bug-ok alapján kiderül. [előzmény: (48488) Yoss, 2010.04.21 09:21:24]

hozzászólásai | válasz erre | 2010.04.21 09:39:10 (48492)

Észrevetem egy érdekességet azt illetően, amikor a 6.13.7-es Mapsource nagy gpx-ket nyit meg.

Megnyitottam mint mindig egy csixről leszedett gpx-et (1080 KB), s mivel tudtam, hogy nem lesz gyors, játszásiból mértem a mp-ket. 32 mp lett.
Majd Mapsource-ban két szegmensre vágtam, elneveztem őket (ékezetesen), aztán szintén gpxbe mentettem. Így 1250KB lett. Na miért is lett ennyivel nagyobb? Meg ha már nagyobb lett, akkor nézzük meg, hogy a mintegy 15%-kal nagyobb méret hányszorosára növeli a megnyitási időt?

Legnagyobb meglepetésemre a maga által elmentett gpx-et pár mp alatt megnyitotta a Mapsource. Aztán arra tippeltem, hogy ugye azért nagyobb a fájl, mert a koordináták 7. tizedesjegyét kitölti 0-val. illetve a magasságnál a 4-7. tizedesjegyeket is felltölti 0-val. Csináltam egy replace all-t notepad++-szal, így kézzel berakva a 0000-t az ele végére, de egyrészt így csak mintegy 40KB-tal nőtt a méret, másfelől meg továbbra is lassan nyitja meg.

Tehát a megynitást nem ez lassítja, hanem valsózínűleg a sor végi jelek. Itt tartok most eme meglehetősen öncélú vizsgálatban, hiszen itt van nekünk a 6.15-ös verziósorozat is. :-)

	hozzászólásai \| válasz erre \| 2010.04.19 10:45:33 (48415)
Megjegyzem, azért 10-20 wp esetén még érdemes lehet lefuttatni rá egy jól megírt algoritmust (mármint nem Mapource-ban persze). Mint a linkeden is szerepel, 10(vagy20) négyzet * 2 a 10-diken(vagy 20-dikon) vizsgálat elég. 100e-400millió vizsgálat. Előbbi egész gyorsan meglenne, utóbbi meg talán reggelre :-) [előzmény: (48408) Gabe, 2010.04.19 05:43:17]

	hozzászólásai \| válasz erre \| 2010.04.17 22:54:02 (48388)
Én is ezzel próbálkoztam, de egy sima é vagy á betűből is úgy konvertált, hogy krikszkraksz lett belőle. Mindegy, akkor jön a buhera (Assignfile és Fileexist esetén mindenképpen). Jó éjt! [előzmény: (48387) jekaeff, 2010.04.17 22:44:06]

hozzászólásai | válasz erre | 2010.04.17 22:36:59 (48385)

Arra már időközben rájöttem, hogy ha elfogadom, hogy a legújabb Lazarust használom, s inkább én is buherálom a FileName-t, akkor nincs gond a Mapsource számára. Csakhogy ezt a Lazarust pl. azért sem szeretem, mert a Resource-ot alapból rosszul hozza létre. Ki kell lépni a Lazartusból, .lrs fájl törlése, Lazarus indul, projekt be, build all, s csak ekkor aktualizálódik az .lrs a forrásnak megfelelően. Szóval elég nehézkes.

De a lényeg: ha a régi, ANSIs Lazarus-szal szeretnék dolgozni, akkor mit kell tennem, hogy a Mapsource megegye azt az ékezetes nevű útpontot tartalmazó gpx-ket, amit Writeln(...)-kel a progim létrehoz???

Ide nem értve a kézi megoldásokat illetve a gpsbabel parancssorként történő meghívását.

[előzmény: (48384) jekaeff, 2010.04.17 22:30:13]

	hozzászólásai \| válasz erre \| 2010.04.17 22:07:53 (48382)
Szóval helyesen: "Azt érted pontosan, hogy a Mapsource-ba miért nem lehet olyan gpx-ket beolvasni, ami ékezetes nevű útpontokat tartalmaz???" [előzmény: (48381) 2010.04.17 22:07:16]

hozzászólásai | válasz erre | 2010.04.17 22:07:16 (48381)

Jekaeff

Új ékezetes probléma

Azt érted pontosan, hogy a Mapsource-ba miért nem lehet olyan gpx-ket beolvasn, ami ékezetes nevű útpontokat tartalmaz.
Visszaolvastam a fórumban az Ansi és UTF8 vonalon, megnéztem a mapsource változáskövetését

"◦Removed the restriction that the names of waypoints, routes, tracks, map sets, etc. can only have characters which are English letters & numbers, blank spaces, +, and -. Users can now enter any character for these labels. However, the ability to enter and display these characters correctly is now dependent on the language settings for the user's operating system "

illetve túrtam a netet, de nem áll össze a kép. Nem vagyok otthon a karakterek terén, de annyit kiteszteltem, hogy ha a gpsbabel-lel gdb-re konvertálok, akkor a Mapsource megeszi. Ha save as-zel gpx-ként elmentem, akkor is megmarad a gpx-ben az ékezet, sőt notepad++-szal át is lehet írni, mondjuk ő-ről ú-ra, a Mapsource akár egy ilyen átírás után is megeszi már akár gpx-ként is.

Viszont ha az eredeti gpx-ket nézem, akkor azt notepad++-szal szerkesztve sem lehet becsalni az ékezetet. Azt látom, hogy a bájtok számába keresendő a dolog, azt tudom is, hogy az UTF8 az több bájton tárol, mint az Ansi, csak azt nem tudom, hogy Lazarus-ban mit kellene csinálnom, hiszen a konverziós függvények elrontják a gpx-ben a name mezőt, de ha nem konvertálok, akkor nem olvassa be a Mapsource.

Valamilyen megoldás nincs Lazarusban? Mi a fenét csinál a gdb formátum, ami megmarad a gpx formátumban is?

[előzmény: (48376) 2010.04.17 19:07:50]

	hozzászólásai \| válasz erre \| 2010.04.17 19:07:50 (48376)
Megértelek. Én is beleöltem már jó sok időt, de a nyári időszámítás automatizálására nem bírtam rávenni magam: http://kepfeltoltes.hu/100417/977472828_j_k_p_www.kepfeltoltes.hu_.jpg [előzmény: (48375) jekaeff, 2010.04.17 19:00:18]

	hozzászólásai \| válasz erre \| 2010.04.17 18:27:11 (48374)
Viszont most ugrik be, hogy az Intel Core Duo-s gépen nem is biztos, hogy használtam ékezetet a gpx fájlnevekben. bocs ;-) [előzmény: (48373) 2010.04.17 18:26:14]

	hozzászólásai \| válasz erre \| 2010.04.17 18:26:14 (48373)
Tényleg csak a vas különbözik (no meg a BIOS értelemszerűen), mert mindent ugyanazokról a telepítőkről tettem fel. Tehát NTFS mindkettő. [előzmény: (48369) jekaeff, 2010.04.17 18:14:35]

	hozzászólásai \| válasz erre \| 2010.04.17 18:24:53 (48372)
Persze aTSpeedButton-nál meg ugye nincs Taborder, mert nem erre való. [előzmény: (48370) 2010.04.17 18:22:25]

	hozzászólásai \| válasz erre \| 2010.04.17 18:23:01 (48371)
Akkor lesz újabb béta is... :-) [előzmény: (48368) jekaeff, 2010.04.17 18:01:39]

	hozzászólásai \| válasz erre \| 2010.04.17 18:22:25 (48370)
Ja, labilis ez a free pascal világ. Ha régi verziót használsz, akkro lemondhatsz a TButton fontjának színezéséről, aztán a TBitBtn-éról is, nagy nehezen ráleltem a TSpeedButton-ra, ahol tényleg színez. Ha meg az ember verziót követ, akkor jön az UTF8. [előzmény: (48367) jekaeff, 2010.04.17 17:55:33]

hozzászólásai | válasz erre | 2010.04.17 17:31:57 (48366)

Kösz a választ. Akkor megmarad így, esetlenül.

Viszont én is beszívtam az ékezetes dolgot. Eddig a 0.9.24-es Lazarusszal dolgoztam, s most áttértem a 0.9.28.2-re. Elő is jött az a hiba, hogy valamelyik gépen nem szereti az ékezetet tartalmazó fájlnevet, míg a másik megbírkózik vele. Ugyanaz a két oprendszer, csak egyik esetben egy régi AMD Athlon a proci, míg a másik valamilyen Intel Core Duo.

Utána az AMD-s gépen előkerestem egy 0.9.24-essel fordított exe-t, simán ette az ékezetet, majd ugyanazt a forrást a 0.9.28.2-sel újrafordítva már nem.

Mivel múltkor felismerted, hogy Ansi és UTF-8 közötti a probléma, ezért gondoltam, hogy megkérdezem, hogy Te tisztán látod, hogy mi a megoldás? Milyen dolgokat kell átírni a forrásban?
Nem akarok lemondani az ékezetekről, viszont úgy látom, hogy az új forrásomat már nem fordítja le rendesen a régi, 0.9.24-es Lazarus, azaz meg kell barátkoznom a 0.9.28.2-sel.

[előzmény: (48364) jekaeff, 2010.04.17 16:58:47]

hozzászólásai | válasz erre | 2010.04.17 16:37:49 (48363)

Jekaeff

Továbbdolgoztam a "szörnyemen", s ennek apropóján úgy alakítottam át, hogy a simítás miatt meghívja (TProcess-ként) az SRTM_HUN exe-jét.

Nézegettem felületesen a forrást is, de mint már egyszer említettem, a mutatók messze állnak tőlem, hamar feladtam. Mekkora meló szerinted "kilopnom" a simítást? Ki lehet könnyen szedni egy procedure-ként mondjuk két paraméterrel (forrásfájl neve és a Gauss simítás paramétere) meghívva?

	hozzászólásai \| válasz erre \| 2010.04.13 16:13:51 (48285)
Figyelmetlen voltam en is, mert ez nem is tunt fel sophegyi hsz-ban. Pedig ezt en hagytam sajat magamnak jova. Mondjuk a lenyegen nem valtoztat: a fejlesztesi otletek jelenleg (=iden) nem jo a ketoldalu kommunikaciora hibak vagy fejlesztesek eseten. [előzmény: (48284) zayd, 2010.04.13 15:23:11]

	hozzászólásai \| válasz erre \| 2010.04.13 15:20:35 (48283)
Miért ez igény és nem hiba: http://www.turistautak.hu/dev.php?id=172 ?? Engem arra biztattak, hogy mehetnek a hibák is. Nem mintha látszódna a workflow.... [előzmény: (48282) sophegyi, 2010.04.13 11:22:47]

	hozzászólásai \| válasz erre \| 2010.04.13 11:10:34 (48281)
Írd be ide: http://www.turistautak.hu/dev.php :-(( [előzmény: (48277) sophegyi, 2010.04.13 10:09:50]

	hozzászólásai \| válasz erre \| 2010.04.11 21:19:32 (48193)
Szasz! Használtam 4 gigás kártyán 2 gigánál nagyobb térképfájlt, s semmi gond sem volt vele. Az hogy ma már nem teszem, nem abból fakad, hogy nem működött volna. 8 gigással nem volt tapasztalatom, de arról is olvastam, hogy másnál működött szintúgy 2 gigásnál nagyobb fájl esetén. Az is kb 3 gigás lehetett. [előzmény: (48186) hubidubi, 2010.04.11 18:14:33]

	hozzászólásai \| válasz erre \| 2010.04.09 11:00:37 (48116)
Megnéztem, aki 60cx-szel volt ebben az időpontban, annál ez a pár mp hiányzik, aki meg Airis-szel, annál nem volt gond. [előzmény: (48110) jekaeff, 2010.04.09 09:35:01]

	hozzászólásai \| válasz erre \| 2010.04.09 10:56:46 (48115)
Kösz, de már többször írtam a témáról, s nálam az egnos az bizony disabled [előzmény: (48111) Csuhás, 2010.04.09 09:52:27]

	hozzászólásai \| válasz erre \| 2010.04.09 09:03:17 (48106)
Bocs, nem aludtam ki magam. Azt hittem, hogy elküldtem az én trekkemet, s végig azt hittem, hogy azt elemezted. Szóval Te is trekkeltél tegnap ugyanakkor... [előzmény: (48105) jekaeff, 2010.04.09 08:58:44]

	hozzászólásai \| válasz erre \| 2010.04.09 08:10:09 (48101)
Amúgy nem 1 db -14 mp-es? [előzmény: (48099) jekaeff, 2010.04.08 23:18:28]

hozzászólásai | válasz erre | 2010.04.09 08:08:50 (48100)

Azért kíváncsi lennék, hátha valaki tegnap ugyanebben az időben loggolt. Valaki!

Mivel eddig nem szembesültem mínuszos sebességgel (most a minimum sebesség alapján tűnt fel a dolog), azt gondoltam, hogy a 4.00-ról 3.60-ra visszaállítás okozhatta. Aztán rájöttem, hogy ez valszeg hülyeség, hiszen eleve a gps fw verzióját kellene nézni, az meg 3.00 maradt. Ebből viszont ráébredtem arra, hogy úgy általában hülyeség volt visszaállnom 3.60-ra, hiszen nekem azal az érzetemmel volt gond, hogy tendenciózusan egyfelé húz a csix pár métert, azt meg szerintem nem befolyásol(hat)ja a fw, csak a gps fw-e. Jól gondolom, ugye?

[előzmény: (48099) jekaeff, 2010.04.08 23:18:28]

	hozzászólásai \| válasz erre \| 2010.04.08 20:58:03 (48092)
Meg egy bug egy közvetlenül a 60csx-ről letöltött gpx-ben. Tehát semmilyen progival sem piszkálva. Mind a kártyára, mind a belső memóriába így hozta létre a trekket. Ld ...:14 mp után ....:34 mp-et http://kepfeltoltes.hu/100408/_j_k_p_www.kepfeltoltes.hu_.jpg

	hozzászólásai \| válasz erre \| 2010.04.08 20:41:51 (48091)
Kiteszteltem Neked. Az ékezetes karaktereket nem szereti. Egy á betű beszúrása után már nem írja ki mentéskor a nevet. Lehet, hogy mást sem szeret. Sajnos Pomázban van á. :-) [előzmény: (47803) jekaeff, 2010.03.30 19:47:35]

	hozzászólásai \| válasz erre \| 2010.04.08 19:06:07 (48088)
Mint kozismert, a domdodom megfelelo hangsullyal ejtve pontosan kifejezi azt is, hogy valaki tisztaban van azzal, hogy a Marianna-arok rossz nyom volt. Egyebkent mi a peronak dugjak igy el ezt a speckot? [előzmény: (48086) jekaeff, 2010.04.08 18:48:09]

	hozzászólásai \| válasz erre \| 2010.04.08 19:03:29 (48087)
Az a helyzet, hogy ezzel kezdtem :-), de ez 9. [előzmény: (48084) olahtamas, 2010.04.08 18:02:03]

	hozzászólásai \| válasz erre \| 2010.04.08 16:38:09 (48083)
Bájdövéj. Azzal most szembesültem, hogy maximum 10 waypointot tudok feltölteni proximity infóval (így találtam rá a linkelt spec-re), viszont mit jelenthet az, hogy 10 nearest? [előzmény: (48082) 2010.04.08 16:12:57]

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

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