kütyük, adalbert1977 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: 372 db hozzászólás

Lapozás: előző | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | következő


adalbert1977hozzászólásai | válasz erre | 2013.06.29 17:49:12 (68361)
http://www.gpsvisualizer.com/elevation
[előzmény: (68360) -Atys-, 2013.06.29 17:46:08]

adalbert1977hozzászólásai | válasz erre | 2013.06.29 17:43:58 (68359)
Az a szám a Fenevad változó, világkorszakváltást jelző bélyege >-))
[előzmény: (68358) pube, 2013.06.29 16:34:00]

adalbert1977hozzászólásai | válasz erre | 2013.06.29 12:17:55 (68355)
[…] Sőt, én Windows alatt is minden mapset-et átkonvertálok *.gmap-osra. Kínlódik a szösz registry-irkálást követelő klasszikus mapset-tel! Igy a *.gmap végződásű mappát csak belehelyezem a „C:\ProgramData\Garmin\Maps” helyre vagy a „%USERNAME%\AppData\Roaming\Garmin\Maps” helyre, és már látja is a BaseCamp (vagy az utolsó MapSource, ha valaki még azt használja). Vagy a mappák *.gmap végződését egyszerűen átírom, és akkor már nem látja a BaseCamp.
[előzmény: (68354) adalbert1977, 2013.06.29 12:13:07]

adalbert1977hozzászólásai | válasz erre | 2013.06.29 12:13:07 (68354)
Egyetértek. Én is ezt mondom. De hogyha a turistautak térképeinek a mapset-jei IMG formátumban érkeznek, akkor – javítsatok ki, ha rosszul tudom – az IMG szettes állományt át kell konvertalni *.gmap-osra / *.gmapi-sra, ahhoz, hogy az OSX-es BaseCamp beolvassa. Ehhez kell a konverzió, amit pl. a JaVaWa MapConvertor elvégez.
[előzmény: (68351) yoggi, 2013.06.29 12:02:13]

adalbert1977hozzászólásai | válasz erre | 2013.06.29 11:56:13 (68350)
[…] S ha egyszer a JaVaWa MapConverter OSX-es váétozatával az IMG-s mapset-et *.gmap-osba konvertálta, áés látja az OSX-es BaseCamp-ben azután az OSX-es Garmin szoftverrel minden bizonnyal felküldheti a kütyüre.
[előzmény: (68348) adalbert1977, 2013.06.29 11:52:08]

adalbert1977hozzászólásai | válasz erre | 2013.06.29 11:52:08 (68348)
Sajnos, nincs OSX-em, így nem tudom a problémát magam előtt látni. De azért van két kérdés:
1) BootCamp??? Nem inkább BaseCamp?
2) Tegyük fel, hogy a kolléga a Garmin Basecamp OSX-es változatéra gondolt. Nos, ebben az esetben, ha jól tudom, az a gond, hogy a turistautak térképeinek a garminos kiadása IMG formátumban tölthető le, amit, ha nem tévedek, az OSX BaseCamp-je „nem szeret”. Viszont az IMG-s állomány átkonvertálható *.gmap-os mappastruktúrába (az elemi IMG egységek RGN csoportokká bontva) pl. a JaVaWa MapConverter program segítségével. A JaVaWa MapConverter-nek letölthető az OSX-es változata is: http://www.javawa.nl/mapconverter_en.html
[előzmény: (68345) Old Eye, 2013.06.29 11:26:57]

adalbert1977hozzászólásai | válasz erre | 2013.06.27 23:44:28 (68319)
Amit visszarak a törölt vagy formázott belső memóriára:
- \Garmin\system.xml
- \Garmin\startup.txt
- \Garmin\GarminDevice.xml
- a \Garmin\GPX\ struktúrája (amikor szükség lesz belőle egy-egy almappára)
- \Garmin\Filters\Geocache\Quick Filter.gff

Amit NEM rak vissza, de nélkülük többé-kevésbé hiányérzeted lehet:
- \Garmin\gmapbmap.img (földgömböt lefedő alaptérkép, melyről fontos biztonsági másolatot készíteni, mert az online frissítés tudtommal nem pótolja)
- \Garmin\gmaptz.img (időzóna térkép, melyet azonban a BaseCamp frissítője felrak/frissít neked, ha hiányzik)
- \Garmin\Garmintriangletm.ico (a garminos ikonocska a Windows intézőben)
- a \Garmin\Text\ tartalmát (a fordításért felelős fájlokat, melyeket azonban a BaseCamp frissítője felrak/frissít neked, ha hiányzanak)
- a \Garmin\Profiles\ tartalmát (a profilokat; hard reset esetén az alapértelmezettek közül csak a Recreational.gpf kerül vissza, vagy hard reset nélkül az épp aktuális; a BaseCamp online frissítője nem pótolja őket)
- a \Garmin\ExtData tartalma (arab vagy más idegen karakterek)
[előzmény: (68314) ramgab, 2013.06.27 20:23:47]

adalbert1977hozzászólásai | válasz erre | 2013.06.27 18:49:36 (68312)
Garmin GPS-vevő belső tárolójának formázásáról van szó? Többször formáztam már eTrex 20/30 és Oregon 450 belső tárolóját, és nem történt baj. Viszont bekapcsoláskor a rendszer nem ír újra fel minden egyes hiányzó rendszerfájlt. Tehát jól fog előtte egy biztonsági mentés. Ugyanakkor KÜLÖNBSÉGET kell tenni a meglévő partíció formázása ÉS az újraparticionálás között! Az utóbbi bonyodalmakat jelent, de az sem orvosolhatatlant. Lásd itt a részleteket: http://geocaching.hu/forum.geo?action=thread&id=kutyuk&message_id=402578
[előzmény: (68309) ramgab, 2013.06.27 17:43:16]

adalbert1977hozzászólásai | válasz erre | 2013.06.27 13:18:56 (68308)
Picit késtem a válasszal, mert közben tesztelgettem a küzyün az IMG-be helyezett raszter térképet.
1) A FIDfinder.exe képes ugyan megváltoztatni a FID-et (a termék, a MapSet Family ID-jét), ahogy több más program is képes erre (GMapTool, MapSetToolKit, JaVaWa GMTK stb.), de a FIDfinder.exe nem képes az elemi IMG-egységek (vagy .gmap-os formátumban az elemi RGN-es egységek) 8 karakteres azonosítóját (Map ID) megváltoztatni. A GMapTool megoldja.
2) Tapasztalataim szerint a raszteres IMG talán picit mintha gyorsabb lenne a JNX-nél, akkor és csakis akkor, ha valóban több rétegű (ha legyártod a kisebb felbontású rasztereket a többi nagyítási szintnek). (A KMZ sokkal gyengébb.)
3) Ami egyelőre rossz: a GPS vevő firmware-je nem támogatja tökéletesen. Pontosabban: nem tudja 200 m-es felbontás alatt megjeleníteni, akármit is próbálok a térkép legyártásakor. Ez nem túl nagy baj, hisz a legtöbb raszteres térkép esetében eleve nem adott ennél nagyobb felbontás, de akkor is hiányosság. A firmware hiányossága ez, hisz a BaseCamp ilyen szempontból is tökéletesen kezeli.
[előzmény: (68273) Zahy, 2013.06.25 21:52:39]

adalbert1977hozzászólásai | válasz erre | 2013.06.26 09:41:01 (68285)
Sajnos nem tudok egyet érteni :) Ha valaki valahogy, valamilyen formában hozzáfér a gépedhez, akkor nincs megállás, mehet az ámokfutás, semmi sem korlátozza. Nem érdemli meg a Microsoft a fikázást, hisz kezedbe adja a lehetőséget, hogy felszámold vagy szigorítsd a biztonsági állításokat. Tehát végül te uralod a gépet. Korábban (még a számomra egyáltalán nem rokonszenves nagy ubuntu-s nyomulás előtt) vagy 6 évig kizárólag csak Linux-ot használtam, amikor a merevlemezeim nem is láttak NTFS fájlrendszert meg Microsoft terméket. Gentoo, Slackware és SuSE voltak a leginkább használt rendszerek. Ostoba, Microsoft-fikázó, kékhalálozó GNU-dzsihádista voltam. A linuxok alapból sokkal restriktívebbek voltak, mint a Windows, és az úgy volt jó. Aztán jött az Ubuntu, a 'bug-untu' nyomulása a buta megoldásaival… [Végül azért szakítottam a linux desktop-pal, mert dilis a fejlesztése. A 'open' jelleg nagyon jó, de a 'free' jelleg túlméretezett és szétforgácsoló, kontraproduktív. Többezer forrásból összehegesztett, félévente változó rendszerből nem lehet olyan stabil környezetet teremteni, amire érdemben fejleszthetnének pl. a nagy kereskedelmi programgyártók. Mire befejeznék egy hatalmas program fejlesztését, mássá válik a kernel, az X szerver, az asztali környezet, a könyvtárak sokasága. Ezen kívül össze-vissza dúl, szétdobál, szétforgácsol a forkolás szabadságának barbársága. Félig kész programok roncstelepe a pálya nagy része.]
[előzmény: (68279) diego, 2013.06.26 07:06:17]

adalbert1977hozzászólásai | válasz erre | 2013.06.25 21:48:22 (68272)
Nálam az az első, hogy felhúzom maximumra. Sőt, a helyi policy-kban még tovább szigorítok egy kicsit. (Például bizonyos helyzetekben kérjen jelszót.) Fontos a biztonság.
[előzmény: (68270) diego, 2013.06.25 21:25:49]

adalbert1977hozzászólásai | válasz erre | 2013.06.25 14:47:24 (68261)
A napokban fedeztem fel azt, amit korábban is tudhattam volna. Módszer van arra, hogy tetszőleges méretű, 5-ös zoom-szintű, nem-vektoros, raszteres (pixeles) térképeket készítsünk Garmin GPS-vevőkre - nemcsak az erősen korlátozott KMZ formátum megkerülésével, de akár a JNX formátum mellőzésével is, vagyis anélkül, hogy foltozni kellene a firmware-t, tehát az eredeti firmware-rel, a garanciával kapcsolatos problémák felmerülése nélkül. A raszteres térkép magában a garmin-os IMG formátumban lesz. Orosz nyelvű kísérlet a raszteres térképet hordozó IMG megfejtésére ITT.

Mi kell hozzá?

A) Garmin MPC (Garmin MapSource Product Creator) - Minimum a 8.0 verzió. Jelen pillanatban a 8.3 a legutolsó. 8.0 alatt nem működik a dolog. A Garmin MPC egy drága program, de kérésre trial licenc (próba licenc) kapható hozzá. A jelenlegi leírásnak nem tárgya az MPC beszerzése. Ha megvan az MPC (a teljes licenc vagy próba licenc kíséretével), akkor oké, ha nem, akkor egyelőre nincs más mód a raszteres IMG legyártására.
B) Próba licenc esetén komoly gondot jelent, hogy minden egyes legyártott térkép-termék esetében a FID (Family ID) ugyanaz. De még ennél is nagyobb korlátozottság, hogy a termék FID-én kívül a tartalmazott elemi IMG (vagy RGN) egységek esetében a sorszám (Map ID) pontosan ugyanaz lesz. Ez egy 8 tagú szám, amely minden egyes egység esetében más kell hogy legyen a lehetséges kilencvenkilencmilliókilencszázkilencvenkilenezerkilencszázkilencvenkilenc közül. Mindez lehetetlenné teszi azt, hogy egyszerre több, MPC-vel készített, saját terméket használj. Éppen ezért próba licenc esetén szükség van még két-három programra a jelzett probléma orvoslására:
B1) cGPSmapper - Elégséges az ingyenes, free kiadás is.
B2) GMapTool
B3) MapSetToolKit - Ennek a használata nem szükségszerű, tehát megkerülhető, de kényelmi előnyöket nyújt.

1) Elindítod a Garmin MPC-t, és készítesz egy projektet, amit érdemes néha lementeni, hogy ne vesszenek el a beállítások.

2) A raszteres IMG tulajdonképpen egy vektor-raszter kevert térkép, ezért nélkülözhetetlen a vektoros térkép-összetevő. Mivel esetünkben egy tisztán raszteres térkép a cél, készítünk egy üresnek látszó vektoros állományt. A legegyszerűbb, ha beolvassuk a szóban forgó raszteres, kalibrált térképet (vagy térképcsempe-csoportot) egy GIS programba (például a nagyon sokféle formátumot kezelő Global Mapper-be, de más programot is használhatunk, mint például a nyílt forráskódú QuantumGIS-t), majd ezután néhány vektoros pontot helyezünk el a megjelenő raszteres térkép széleire. Ezután a néhány pontocskát tartalmazó vektoros állományt lementjük shapefile-ba (*.SHP). De még mentés előtt fontos, hogy létrehozzunk a pontok mindegyike számára egy új attribútumot, aminek a neve szükségszerűen „GRMN_TYPE” lesz, az értéke pedig minden pont esetében például „CUSTOMIZABLE_POINT_1024” lészen. Ez azért fontos, hogy kezelni tudja az MPC.

3) Ezt a majdnem teljesen üres shapefile-t hozzáadjuk az MPC projekthez. „Add Map” -> „Add Data Files” (hozzáadjuk a shapefile-t) -> elnevezzük a térképet („Map Name”) -> ügyelünk arra, hogy ebben az esetben ne válasszuk ki a „Basemap” minősítést -> OK.

4) Megismételjük az előbbi pontban jelzett térképhozzáadást, azzal a különbséggel, hogy ezúttal kiválasztjuk a „Basemap” minősítést is. Miért? Mert különben az MPC alaptérképként (háttérként) berakja a saját basemap-ját, amire a mi esetünkben egyáltalán nincs szükség.

5) Tehát van két majdnem üres vektors térkép egy „Basemap” (alaptárkép) és egy „Detailed Map” (részletes térkép). Ezek szerepe mindössze az, hogy egyáltalán létrejöjjön egy IMG fájl. Viszont nem akarnak mutatni semmit. Éppen ezért áttetszővé állítjuk az adott pontocskák stílusát. „Configure Map Builds” -> „Edit Feature Display Styles” -> „Custom Points” -> itt megkeressük a lista végén a „CUSTOMIZABLE_POINT_1024” elemet, kattintással megnyitjuk, és „Clear Image” (hogy áttetsző, vagyis láthatatlan legyen), majd pedig a „Label Properties”-nél legyen a „Size” = „No”, hogy a címkéjük se látszodjék -> „OK” -> „Done”.

6) A „Product Configuration” ablakocskában rákattintunk a „Basemap” fülre. Aztán ott „Scale and Simplification Settings” -> a „Number of Feature Layers” legyen 1-re húzva -> az „Approximate Scale of Layer One” legyen a lehető legmagasabb érték, azaz 20M. Mindezt azért tesszük, hogy az alaptérkép a lehető legjelentéktelenebb legyen, amikor BaseCamp-ben akarjuk nézegetni a raszteres térképünket. Merthogy az IMG-s raszteres térképnek ez is egy előnye: a BaseCamp-ben pontosan ugyanúgy használható, nézegethető, akár egy normál, vektoros térkép.

7) A „Product Configuration” ablakocskában rákattintunk a „Detailed” fülre. Ezen belül állítjuk be a tulajdonképpeni térképünket. Bejelölünk két dolgot: „Transparent Detailed Map”, és - ami nagyon fontos - „Contain Raster Image”. A „Contain Raster Image” bepipálása nélkülözhetetlen!

8) Majd itt is (a „Detailed” esetében is) kattintunk a „Scale and Simplification Settings”-re. Majd „Raster Configuration” -> és ott megadjuk a raszteres térkép különféle zoom-szintjeinek (nagyítási szintjeinek) az állományait. Jó esetben ugyanarról a térségről többféle felbontású raszteres térképeink is vannak (az egyik lehet akár műholdas felvétel is). Mindegyik állományt processzálni kell először. A processzálás (a garmin-os feldolgozás) forrása (input-ja) GeoTIFF formátumú kell hogy legyen. (Sokféle program képes a betájolt, bekalibrált raszteres térképek GeoTIFF-be konvertálására.) Az output egy sajátosan elnevezett JPEG-csempe-gyűjtemény lesz a megadott célmappában. Fontos megjegyzés következik: Ha mindössze egyetlen raszteres térképpel dolgozunk, akkor is érdemes több zoom-szintet (nagyítási szintet) leprocesszálni. Miért? Mert ilyen módon lényegesen gyorsabbá tehető majd a raszteres térkép nagyítása-kicsinyítése! Tehát szépen megadjuk ott a felületen a „Down Sample %” oszlopban a lekicsinyítés százalékban mért értékeit. (100% = az eredeti méret; 50% = fele méret stb.) A processzálást („Process Rasters”) rétegenként kell külön lépésekben elvégezni.

9) Mindegyik nagyítási szint processzálása után végül „Save”, és bezárjuk a „Raster Configuration” ablakot. Ezután a „Scale and Simplification Settings”-ben eljátszunk a zoom-szintekkel. Mindegyik szintnél („Layer”) adott a „Raster Config Name” oszlop, ahol minden nagyítási rétegnek megadjuk a neki megfelelő (optimális méretű) processzált raszteres állományt. Maximum 5 nagyítási réteg/szint lehetséges, ami ugyebár nagyon jó.

10) Miután mindent még egyszer átnézünk, és minden jónak tűnik, bezárjuk a „Product Configuration” ablakot, és jön a térkép kompilálása („Build”) a megadott helyre („Build Location”).

11) Az MPC még telepítő exe-t is fog készíteni. Trial licenc esetében ez egyáltalán nem érdekel bennünket, mert a trial korlátozottsága az, hogy minden termék FID-je, és - ami még rosszabb - minden termék elemi IMG-egységeinek (vagy RGN-egységeinek) a 8 karakteres sorszáma (Map ID) ugyanaz lesz. Ez azt eredményezi, hogy egyszerre csak egy MPC-vel létrehozott saját térkép csücsülhet a GPS vevőnkön, és a Basecamp is prüszköl, ha egyszerre több-mint-egy efféle térkép adott.

12) Éppen ezért az MPC trial licence esetén telepítjük a cGPSmapper-t. (Az ingyenes is bőven elégséges, hisz nem bonyolultabb, útvonaltervezős térképet készítünk.) Majd telepítjük a GMapTool programot is. Megnyítjuk a GMapTool-t -> „Options” fül -> „Advanced Options” bepipálva -> cGPSmapper útvonala megadva.

13) Ezután a GMapTool-ban „Files” fül -> „Add files” -> hozzáadjuk az MPC által készített IMG fájl(oka)t, de nem a basemap.img nevezetűt, hanem az(oka)t, amely(ek) esetében xxxxxxxx.img a név, vagyis 8 tagú szám a név, és a tetemesebb méret is jelzi, hogy tartalmazza a raszteres állományt. Ezután „Change” fül -> „Change Map ID” -> az ID-ben pedig megadunk egy tetszőleges, 8 tagú számértéket 00000001-től 99999999-ig. Majd „Change All”. Ezzel megváltozott az elemi IMG-egység(ek) (vagy RGN-egységeinek) sorszáma (Map ID-je)!

14) A MapSetToolKit segítségével létrehozzuk a BaseCamp-pel olvasható térkép-állományt („Mapset”-et). A MapSetToolKit-ot admin módban kell futtatni! A térkép-állomány („Mapset”) a GMapTool-lal is elkészíthető, de nem annyira kényelmes, főleg ha a láthatatlan pontok áttetszőségét biztosító stílus-fájl (TYP-fájl) beépítéséről is szó van. A MapSetToolKit-ban megadjuk a cGPSmapper útvonalát („cgpsmapper/cpreview folder”), valamint a „gmaptool program Optional)” útvonalát is (ami 64 bites Windows-ban általában ez: „C:\Program Files (x86)\GMapTool\gmt\gmt.exe”). Eme kezdeti beállítások után: „Select IMG” (megadjuk a GMapTool-lal módosított IMG fájlok mappáját) -> „Select all” -> Add „Select all” -> megadjuk a „Mapset directory”-t (ahová létrehozzzuk a térkép-állományt) -> „Mapset name” (elnevezzük) -> „Family ID” (vagyis tetszőleges, más termékben nem ismétlődő azonosító számot adunk neki) -> „TYP files” (ez fontos, hisz ezzel adjuk meg a pontok áttetszőségét biztosító stílust hordozó TYP fájlt) -> jobb oldalt bepipáljuk azt, hogy „Install in Mapsource” -> „START”.

15) Ennek nyomán ott lesz a BaseCamp-ben a(z akár 5 szintes) raszter térképünk. MapInstall-lal legyárthatjuk és felrakhatjuk a GPS vevőre való IMG fájlt (amely a TYP-et is magában foglalja), ami tehát egy raszteres térkép lesz (akár 5 szinttel, és akár hatalmas mérettel).
Nékem ez a metódus tűnik a legjobbnak raszteres térképekhez vagy műholdképekhez. A KMZ-s metódus igencsak korlátozott (lassúbb, kicsi mérethez korlátozott, nagyítási szinteket kizáró), a JNX-es módszer pedig a firmware megfoltozását követeli, amely azonban garanciavesztést jelent abban az esetben, ha úgy romlik el a GPS vevő, hogy nem tudjuk visszarakni az eredeti firmware-t.
[előzmény: (67928) adalbert1977, 2013.05.30 10:00:31]

adalbert1977hozzászólásai | válasz erre | 2013.06.25 09:41:35 (68251)
Miért ne lenne? Német nyelvű bemutató videó is készült már, márpedig az európai piacot jelent: http://www.pocketnavigation.de/2013/06/garmin-monterra-wurf-bruder/
[előzmény: (68250) diego, 2013.06.25 08:57:11]

adalbert1977hozzászólásai | válasz erre | 2013.06.24 22:14:35 (68249)
Ez bizony szép kis jószág :) . A csillagászati ár borítékolható, és mégis sokan megveszik majd.
Diego ismét izgulhat, vásárolhat, gyönyörködhet :)
[előzmény: (68235) reprocesszor, 2013.06.24 14:00:00]

adalbert1977hozzászólásai | válasz erre | 2013.06.24 14:38:09 (68240)
Túrázásra napszemüveget? Igen, érdemes. Havas helyre pedig kb. kötelező.
[előzmény: (68236) bikeforever, 2013.06.24 14:12:54]

adalbert1977hozzászólásai | válasz erre | 2013.06.24 01:05:01 (68232)
Szerintem sem érdemes érte fizetni. Nagyon gyenge, kis felbontású, kevés részletet tartalmazó, nem-útvonaltervetős térkép. A Kárpát-medencébe sokkal jobb az OpenMaps (
[előzmény: (68226) Yoss, 2013.06.23 21:01:10]

adalbert1977hozzászólásai | válasz erre | 2013.06.23 05:54:08 (68216)
1) A BaseCamp is hibátlanul gyárt nyomvonalat útvonalból. Jobb kattintás az útvonalra baloldalt a listán [vagy a kijelölö (select) eszközzel a térképen az útvonalra], és „create track from the selected route”. Egy másodperc az egész.
2) Ha pedig mindenáron útvonalként akarnék olyan pontos másolatot, ami nem változik a kütyün: a Basecamp-ben megszerkeszthető az útvonal; megváltoztatható a színe valami világosabbra; azután készíthető egy új útvonal a útvonalrajzoló eszközzel a korábbi világosan haladva, sok közbeeső pontot beékelve.
3) Viszont emez utóbbira egy másik célszerűbb, gyorsabb módszer is van BaseCamp-ben. Az 1)-ben jelzett módon nyomvonal gyártása útvonalból. Majd szintén villámgyorsan a fordított eljárás: útvonal gyártása nyomvonalból („create route from the selected track”). Itt fel is ajánlja, hogy vagy a track nagyszámú (!) pontjait használja fel maradéktalanul útpontokként a route-ban, vagy tetszőleges számú pont kérhető.
[előzmény: (68212) scele, 2013.06.22 21:59:54]

adalbert1977hozzászólásai | válasz erre | 2013.06.21 11:13:47 (68180)
Közben átolvastam, mit ír egy angol wiki arról a beállításról. Valóban, ahogy diego mondta, az az offroad tervezésre vonatkozik, hogy vagy az útba eső új pontokat ténylegesen elérve, vagy manuálisan visszaigazolva, vagy megadott távolságokra megközelítve a tervezés átugorjon a következő pontra. Viszont volt olyan tapasztalom, vagy annak képzelt illúzióm(?), mintha máskor is számítana. Amikor track-et jelöltem meg útvonalként, olyankor 10 m-re állítva azt a beállítást, mintha pontosabb lett volna az előrejelzés. Persze az is megtörténhet, hogy semmi köze hozzá, hanem valami más miatt akkor véletlenül épp pontosabb lett.
[előzmény: (68176) pockok, 2013.06.20 19:03:47]

adalbert1977hozzászólásai | válasz erre | 2013.06.19 14:42:20 (68166)
Vajon az újratervezés könnyedségét nem befolyásolja az „Offroad Transitions” („Lágvonalbeli átm.”) értéke a beállításokban? Sosem voltam tisztában azzal, hogy mi ez a beállítás, de rémlik valami olyasmi, hogy amikor hegyi terepen egy sokat kanyarodó nyomvonalat útvonalként választottam, ennek az értéknek a lecsökkentése (például 10 méterre) pontosabb előrejelzést eredményezett (a hátralévő távolságról). Amíg automatikuson volt, addig össze-vissza ugrált az előrejelzés (a hátralévő távolságról). Persze ez nem ugyanaz, mint az útvonaltervezés, de lehet, hogy ott is segít. (Ez nem biztos állítás, inkább kérdés és javaslat.)
[előzmény: (68163) yoggi, 2013.06.19 11:17:50]

adalbert1977hozzászólásai | válasz erre | 2013.06.17 20:17:12 (68161)
Fura hiba: Adott egy vonaltípus (stílus) egy saját Garmin TYP fájlban. És nem mindegy, hogy melyik a külseje és a belseje. (Felszíneket bezáró körvonal stílusáról van szó, amely nem szimmetrikus kinézetű, a vonal két oldala másképp néz ki, egyik a belső, a másik a külső.) Nos, BaseCamp-ben egy bizonyos irány rajzolódik (a kiálló háromszögek belül vannak), a GPS vevőn pedig pontosan a fordítottja (a kiálló háromszögek kívül vannak az eTrex képernyőjén). Örülnék, ha valaki esetleg megnézné a saját kütyüjén is (nem eTrex 20/30-on), hogy belül vagy kívül állnak ki a háromszögek a határvonalon a vonalazott felülethez képest.
IMG fájl
A TYP forrása (txt) - Megjegyzem, hogy a „UseOrientation=N/Y” változónak semmi köze ehhez a problémához. Nem tudom, mit tesz, de mindössze annyi a hatása, hogy rondább q a vonal a GPS-en, ha Y(Yes)-re állítom.

adalbert1977hozzászólásai | válasz erre | 2013.06.16 14:39:29 (68151)
Igen, layer-est. Olyannyira layer-es, hogy Oregon 450-ben a layer-ek külön be- és kikapcsolható térképként látszanak végül. (Az új eTrex egyként kezeli.)
[előzmény: (68150) 2013.06.16 14:11:00]

adalbert1977hozzászólásai | válasz erre | 2013.06.16 11:56:22 (68146)
A napokban frissítettem az OMP-t az „OpenMaps Garmin Manager”-rel. Több mint 500 img-t tartalmaz. A 100d-s cGPSmapper-rel volt kompilálva. Mindegyiken felfedezhető alul egy pont (small city osztályú) - igaz, zavaró név nélkül. Ezek kivétel nélkül az eTrex-emen is látszanak. (Leellenőriztem.) Tehát odarakja a cGPSmapper, igaz név (label) nélkül, hiába megvásárolt, fejlettebb verziójú a program.
[előzmény: (68144) 2013.06.16 11:43:06]

adalbert1977hozzászólásai | válasz erre | 2013.06.16 11:52:03 (68145)
Lehet, hogy csak a "TRE Size" számít, és a térképdarabolás kizárólag csak a sokkal gyorsabb újraszerkesztés-kijavítás-újrakompilálás valamint a részleges MapInstall végett szokásos?
[előzmény: (68141) 2013.06.16 11:36:05]

adalbert1977hozzászólásai | válasz erre | 2013.06.16 09:40:08 (68139)
[…] Az cGPSmapper-rel kompilált OpenMaps 527 darab IMG-kockájának mindegyikén is ott virít egy-egy pont (BaseCamp-ben vagy a Garmin kütyükön is látszanak). Ezek is "Small city/town (5-10K) (0xb00, point)" tulajdonságú pontok, amelyeknél a "0B xx xx 00" nincs kicserélve "28 00 00 00"-re, de legalább nincs tolakodóan látszó nevük. (A "28 00 00 00"-ra cserélés egy gyakorlatilag észrevehetetlen, láthatatlan "Label (0x2800, point)" tulajdonságú pontot eredményez.)
[előzmény: (68138) adalbert1977, 2013.06.16 08:52:27]

adalbert1977hozzászólásai | válasz erre | 2013.06.16 08:52:27 (68138)
[…] A 100d verziójú cGPSmapper-r használom. Ez az utolsó, és úgy tűnik nem is lesz több, mert befejeződött a fejlesztése. Nálam azt csinálja, hogy minden kompiláláskor a térkép legaljára odabiggyeszt egy pontot, méghozzá egy kisvárosnak („small city”) megfelelő pontot, amelynek a neve nem más, mint az a név, amellyel a cGPSmapper volt regisztrálva. Ez a „kisváros” az összes nagyítási szinten látszik, mégpedig ugyanazon a helyen, koordinátán. Ha GPSMapEdit-ben (Geopainting) megnyitom az IMG fájlt (ez az egyetlen program, ami megnyitja-megjeleníti a nem-NT-s IMG-ket), és kijelölöm az adott pontot, akkor a Properties->Source rávezet a kicserélendő „xx xx xx 00” láncra. Az első két betű általában azonos, de a többi utána mindig más, és semmilyen szabályosságot nem látok. Tehát ha mondjuk 25 kockára darabolok egy térképet, akkor 25 alkalommal kell a szertartást elvégezni, megkeresni a pontot, beazonosítani a számot, és végrehajtani a 'rmwmark 66010070.img -f "xx xx xx 00" -r "28 00 00 00"' parancsot. Türelmet követelő macera. Reméltem, hátha eleve ki lehet kapcsolni ezt pontcsinálást. Most sem értem, miért csinálja a cGPSmapper :(
[előzmény: (68136) 2013.06.15 23:37:17]

adalbert1977hozzászólásai | válasz erre | 2013.06.16 08:52:21 (68137)
Az IMG mérete nálam 13 MB. Feldaraboltam, méghozzá 2°x1°-os kockákra. (Amikor MapInstall-al kütyüre küldöm, akkor látható, hogy több kocka jelölhető ki.) Ekkora méretnél bizonyára felesleges, amit tettem, de remélhetőleg, nem is ront. Kérdés a számomra, hogy gyorsabb-e a darabolástól a kütyün a térképlapozás vagy sem. Minden nagy térkép így érkezik, darabokban. S csak azt nem tudom, hogy ez a sebesség növelése miatt van így, VAGY egyszerűen a térképkészítéssel áll összefüggésben, mert kényelmesebb kisebb adatokat szerkeszteni-változtatni-újrakompilálni térkép-rajzoláskor, -javításkor.
[előzmény: (68135) 2013.06.15 23:29:24]

adalbert1977hozzászólásai | válasz erre | 2013.06.15 17:09:14 (68133)
Van két kérdésem a Garmin térképkészítéssel kapcsolatosan:
1) MP fájlból kompilálok garminos térképet (IMG fájlt) a cGPSMapper-rel. (A nagy MP fájlt GPSMapEdit-be importált shapefile-okból szerkesztettem, de ez most lényegtelen.) A térkép Románia természetvédelmi területeit mutatja, nagyon pontos, részletes, nagy felbontású határvonalakkal és sokszögekkel. Tehát az alapterület jó nagy: Románia területe. A kérdés: Érdemes-e ezt a nagy MP-fájlt feldarabolni kisebb területekre a GPSMapEdit-ben, ahhoz hogy aztán több IMG fájl készüljön (avagy több GMP-s állomány, ha a gmap-os formátumban vesszük). Gyorsítja ez majd a térkép lapozását a cuccon (tehát ha majd a Garmin kütyüre feltöltött egyetlen IMG több, kisebb img-ből áll úgymond)? Van-e a feldarabolásnak gyakorlati haszna? Megfigyeltem ugyanis, hogy a nagy térképek kivétel nélkül mind így jönnek, feldaraboltan. Az OMP, meg a többi is.
2) Megfigyeltem, hogy a cGPSMapper minden kompilált IMG-be, pontosan az alsó szél tájékára berakja pontként (mégpedig kisvárosként!) a program tulajdonosának a nevét. Nem lehet ennek valahogy elejét venni?

adalbert1977hozzászólásai | válasz erre | 2013.06.11 17:18:10 (68091)
[off] A románok legendás frankofóniája egy mese. Kevesen beszélik a franciát, és egyébként is elég távol áll a románoktól a francia nyelv és kultúra, mindhiába adott a közös latin bázis. Az olasz nyelv közelebb áll, no és főleg a balkáni román nyelvek, vagy a kihalt dalmát nyelv. Illetve egyértelműen kimutatható valamilyen mértékű albán hatás is a román nyelvben. Néhány alapszó teljesen azonos, némi jelentés-csúszással: román copil = gyermek, albán kopil = kölyök, poronty; román bucuria = boldogság, albán bukuria = szépség. A román frankofónia politikai téren sem igazán állta meg a helyét. Miután az első világháború nyomán erőteljes francia segedelem révén létrejött Nagy-Románia, hogy Csehszlovákiával, Lengyelországgal és Jugoszláviával együtt a franciák ígéretes szövetségesei legyenek a németek háta mögött, azután a románok egy-kettőre Hitler kiszolgálóivá váltak, még jóval a második világháború előtt, Észak-Erdély visszacsatolása ellenére is, a magyarokénál jelentősebb katonai erőbevetéssel harcolva Hitler mellett, a Szovjetunió ellen, s majd csak 1944 késő nyara után váltak antifasiszta harcosokká. [/off]
[előzmény: (68090) perRetZ, 2013.06.11 16:17:55]

adalbert1977hozzászólásai | válasz erre | 2013.06.11 10:55:44 (68074)
Ha valaki betartja az egyszerű gtt fájlok xml szintaxisát, tehát nem piszkál a tag-ekbe a magpet által említett diszgráfiával :) , hanem a fordításnak fenntartott szövegrészekbe ír szavakat és számokat (egzotikus karaktereket, pl. >-t mellőzve), akkor egész biztosan nem lehet elrontani a kütyüt. Tegyük fel, hogy mégis valamit elrontott, egy tag-et elrondított: az otthoni próba alkalmával ad egy „cold reset” parancsot és szépen visszatér az angolhoz. A hibákat a Notapad++ szintaxis-kiemelő funkciója szépen jelzi (Language - XML). Sőt xml-szintaxisra érvényes hibakereső kiegészítő is van. Plugins - Plugin Manager - Show Plugin Manager - kiválasztod a hosszú sorból azt, hogy XML Tools és telepíted (Install) - Notepad++ újraindítva - Plugins - XML Tools - Check XML syntax now.

Yoss-hoz csatlakozva: én is mindent angolul használok, leginkább azért, mert könnyebb úgy problémák esetén a nagy nemzetközi fórumokon elboldogulni. De mivel többször olvastam panaszokat a rossz fordításról, gondoltam, felvetem a témát, mert nagyon egyszerű javítani. Bosszantó szövegrész kikeresése egy másodperc alatt, utána kijavítva.
[előzmény: (68070) R.Guszty, 2013.06.11 07:45:15]

adalbert1977hozzászólásai | válasz erre | 2013.06.10 22:45:52 (68067)
[…] Tehát kb. így nézne ki a munkafelület (magyar fordítás+kiegészítés német segédlettel): https://docs.google.com/file/d/0B3r05yyyslkqUEJtYmpIb0tYeU0/edit?usp=sharing . Nagyon egyszerű, és arra is jó, hogy az idegesítően rossz magyar fordításokat kijavítsuk.
[előzmény: (68066) adalbert1977, 2013.06.10 22:36:11]

adalbert1977hozzászólásai | válasz erre | 2013.06.10 22:36:11 (68066)
[…] Az egyik legjobban használható program ilyesmire szerintem a Notepad++ . Megnyitod vele a gtt fájl(oka)t, és utána Language -> XML, és onnantól kezdve nagyszerűen áttekinthető az egyébként xml gtt.
[előzmény: (68065) adalbert1977, 2013.06.10 22:31:26]

adalbert1977hozzászólásai | válasz erre | 2013.06.10 22:31:26 (68065)
A gtt szövegfájl módosításával nem lehet a kütyüt elrontani. Esetleg, legfeljebb az lehet a probléma, hogy a lefordítatlan kifejezéseknek megfelelő sorok hiányoznak, vagyis az angol eredetijük nincs beírva. Ebben az esetben az jelenthet megoldást, ha valaki például a minden bizonnyal hiánytalanul lefordított német, francia, spanyol stb. gtt-ből merítve egészíti ki a magyarul hiányzó kifejezéseknek megfelelő sorokat (illetve a sorok elhelyezkedését).
[előzmény: (68063) diego, 2013.06.10 19:41:15]

adalbert1977hozzászólásai | válasz erre | 2013.06.10 17:37:19 (68061)
Bárki szerkeszthet Hungarian.gtt fájlt :)
[előzmény: (68060) sala, 2013.06.10 16:30:06]

adalbert1977hozzászólásai | válasz erre | 2013.06.09 23:56:00 (68057)
Nem is olyan nagyon rossz. Hozza egy szerényebb kompakt vagy az okostelefonok átlagának a fotózós formáját. És hasznosabb ezt a fajta fotózást egy strapabíró gps-vevőbe építeni, semmint egy kényes telefonba. De a 6x0-as Oregonok akkor is túlárazottak per pill.
[előzmény: (68050) diego, 2013.06.09 20:56:35]

adalbert1977hozzászólásai | válasz erre | 2013.06.08 11:10:08 (68021)
http://youtu.be/iQJs0jDtUbI :)
[előzmény: (68020) adalbert1977, 2013.06.08 11:07:03]

adalbert1977hozzászólásai | válasz erre | 2013.06.08 11:07:03 (68020)
A zuhany(fürdőt) jelentő szó eredete francia: douche. A magyarban valahogy t-vé alakult. Ki tudja miért, hisz a németben is Dusch-sá vált a francia douche (-> német Duschgel). Na de visszatérve a témához: semmilyen veszélyt nem látok abban, ha valaki megmossa az egyébként vízálló Garmin cuccát csap alatt. Én mindig megmosom, ha koszosnak vagy zsírosnak találom, méghozzá szappannal. Az biztos, ha én vettem volna egy Oregon 600-ast, ez lett volna a legelső, amit kipróbálok, a kesztyűs használaton kívül, hogy miként viselkedik a nedves érintőképernyő.
[előzmény: (68019) perRetZ, 2013.06.08 09:38:56]

adalbert1977hozzászólásai | válasz erre | 2013.06.08 08:34:49 (68018)
De igen. Elnézést.
[előzmény: (68017) yadaysw, 2013.06.08 00:14:59]

adalbert1977hozzászólásai | válasz erre | 2013.06.07 21:59:51 (68016)
Rendszeresen megmosom csap alatt szappannal a gps-vevőmet. Semmi baja miatta, hisz vízálló. A dús pedig a csapnál is jóval szelídebben adagolja a vizet: enyhén permetezi, akár az eső. De természetesen te döntesz erről, nem más.
[előzmény: (68013) diego, 2013.06.07 21:24:25]

adalbert1977hozzászólásai | válasz erre | 2013.06.07 19:55:28 (68010)
Ha nem esik kint, fürdőszobai dús a készülékre, hadd lássuk, hogy kezelhető úgy? :)
[előzmény: (68009) diego, 2013.06.07 19:52:19]

adalbert1977hozzászólásai | válasz erre | 2013.06.07 15:40:27 (68000)
LOL És várjuk diego beszámolóját, tüzetes tesztjét (vizes kijelző tapizása stb…).
[előzmény: (67999) magpet, 2013.06.07 15:26:56]

adalbert1977hozzászólásai | válasz erre | 2013.06.03 09:47:03 (67960)
Hmmm, nem semmi, hogy kapható már. De szerintem most nem szabad megvenni ennyi pénzért. Bocsánat, de csak most jut el az elmémig friss, ropogós árának magánvalósága :) . Eddig mind csak a technikai részletei kötötték le a figyelmemet, s a nagy kérdés kapacitív kijelzőjének viselkedését illetően.
[előzmény: (67953) R.Guszty, 2013.06.03 07:52:00]

adalbert1977hozzászólásai | válasz erre | 2013.06.02 23:54:20 (67952)
Köszönöm a tapasztalat megosztását. Otthon mesterséges körülmények között is kipróbálhatod, hogy mi történik kevésbé érzékeny beállításnál. Pl. a tusfürdő permetezésével :) . A nedvességben való viselkedés fontos szempont. Ha az új Dakoták, Oregonok majd mind ilyenek lesznek, akkor teljesen kihullhatnak a keményebb, túrázós használat köréből. Egyébként honnan veszítek meg ezeket a 600-osakat? Nem csak augusztustól forgalmazzák:
[előzmény: (67949) KoLa, 2013.06.02 23:09:52]

adalbert1977hozzászólásai | válasz erre | 2013.05.31 16:12:45 (67936)
Épp ez a lényeg, hogy egyszerre több térkép közül váltogathass a kézsülékben. Egy programocska, amely barátságossá tesz több dolgot is: JaVaWa Device Manager Pl. 3-4 szinten lehetővé teszi az átnevezést (fájlnév, térképnév, szettnév, BC-név), be- és kikapcsolhatóvá teszi a készülékre helyezett térképek láthatóságát BaseCamp-ben, stb. Emez utóbbi azért is hasznos lehet, mert mapsource-os izélgetés nélkül is olvashatod tehát BaseCamp-ben az img formátumú térképeket. A nagy sebesség kedvéért pedig csinálhatsz például TruCrypt-tel egy virtuális garmin-kütyüt a merevlemezeden. Ekkor fontos a TrueCrypt-ben az a beállítás, hogy Settings -> Preferences -> „Mount volumes as removable media”, majd az adott virtuális TrueCrypt-es tárolón létrehozol egy Garmin nevű mappát, és onnantól Garminos kütyűnek látja a Basecamp, a MapInstall és a JaVaWa Device Manager.
[előzmény: (67933) runnner, 2013.05.31 13:12:46]

adalbert1977hozzászólásai | válasz erre | 2013.05.30 10:02:34 (67929)
[…] (Nyilván a képcsempék a kmz/jnx fájlon BELÜL vannak.)
[előzmény: (67928) adalbert1977, 2013.05.30 10:00:31]

adalbert1977hozzászólásai | válasz erre | 2013.05.30 10:00:31 (67928)
Kétféle garmin-os raszteres térkép létezik: KMZ és JNX

Vegyük őket sorba:
A. KMZ:
1) Startból használható, azaz nem kell a használatához megfoltozni a Garmin vevő firmware-jét.
2) Csupán egyetlen zoom-szint (nagyítási szint) lehetséges.
3) Kemény korlát: az egész(!) Garmin vevőn CSAK 100 darab képcsempe lehet. (A Montana esetében 500 darab.) Tehát nem kmz-s fájlként/térképként 100 darab csempe, hanem össz-vissz az egész kütyün. Ugyanakkor tudomásom szerint egy képcsempe maximális mérete 1024x1024 pixel lehet. Ergo a maximális térképméret: 100=10x10, vagyis 10240x10240 pixel.
4) Lassúbb.

B. JNX:
1) A használatához meg kell foltozni a Garmin vevő firmware-jét. Foltozó program itt. Foltozható firmware-ek litásja itt. A megfoltozható firmware-ek könnyedén letölthetők itt. A foltozás a garancia elvesztését jelenti. Pontosabban: ha úgy romlik el a Garmin vevőd, hogy meg se nyekken, és nem tudod számigéphez csatlakoztatni, hogy visszatedd rá az eredeti, foltozatlan firmware-t, akkor nincs garancia.
2) Összesen 5 zoom-szint (nagyítási szint) lehetséges, ami egy nagyon jó dolog, mert pl. ugyanarról a régióról kalibrálhatsz eltérő felbontású raszteres térképeket, azért hogy közelítve részletesség is adott legyen, de távolítva áttekinthetőség is legyen. Az 5 szint közül akár műholdképes is lehet. A SAS.Planet nagyon jó program weben böngészhető térképek (pl. műholdfelvételek) lementésére. Letölthető itt.
3) Zoom-szintként (nagyítási szintként) 50000 darab képcsempe lehetséges. Tehát nem az egész készüléken, és nem térképként vagy fájlonként, hanem egy bizonyos térkép egy bizonyos fájljának egyetlen nagyítási szintjében. Ha egy térkép nagyon nagy, és valamely nagyítási szinten 50000-nél több a képcsempe, akkor a dolog kitrükközhető azzal, hogy több-volumenű jnx fájlokat készítünk. Erre a korábban említett SAS.Planet képes.
5) Fürgébb.
[előzmény: (67925) fehérkút, 2013.05.30 08:56:07]

adalbert1977hozzászólásai | válasz erre | 2013.05.29 19:29:03 (67919)
Ami az SD kártyán nem a megfelelő helyen van (garminos mappa-hierarchia), mindaz láthatatlan marad a készülék számára. Főbb helyek:

/Garmin/ = Ide helyezed a térképeket *.img formátumban. A készülék saját belső adattárolójáról azonban ne másold ide a gmapbmap.img és a gmaptz.img térképeket (az alaptérképet és az időzóna-térképet).

/Garmin/GPX/ = Ide helyezed a feltöltendő nyomvonalakat, útvonalakat, útpontokat (többnyire *.gpx formátumban). Ugyanakkor tudnod kell, hogy a készülék által megírt nyomvonalak, útvonalak, útpontok a belső adattárolóra íródnak, nem az SD kártyára. Akkor is, ha pl. egy SD kártyára feltöltött track-et archiválsz: archiváláskor az SD kártyáról átkerül a belső adattárolón belül a /Garmin/GPX/Archive/ mappába. Tehát a készülék mindent a belső adattárolóra ír. Az SD kártyát csak olvassa.

/Garmin/CustomMaps/ = Ide helyezed a *.kmz formátumú raszteres térképeket.

/Garmin/CustomMaps/BirdsEye = Ide helyezed a *.jnx formátumú raszteres térképeket, amennyiben megfoltoztat ez ügyben a firmware-t.

/Garmin/POI/ = Ide helyezed a saját POI-kat *.gpi formátumban, melyeket pl. a Garmin POI Loader alkalmazással készíthetsz.

/Garmin/JPEG/ = Ide helyezed a saját képeket *.jpeg fprmátumban.

Stb…

Jó műszer az eTrex 30! Nékem tetszik. Érzékeny, pontos. A szobámban egy Oregon 450 sokszor elvesztette a műholdakat felsős időben, míg a mellette lévő eTrex 30 sose, GPS-only módban sem (GLONASS nélkül sem). A 2.90-es firmware borzasztóan bug-os volt, és az erőst felhúzott, de nagyon hamar kiadták a 3.00-ás frissítást, amiben több – általam is jelentett – hibát kijavítottak. Persze a 3.00-ás sem tökéletes, de nagyon érdemes arra frissíteni.
[előzmény: (67913) fehérkút, 2013.05.29 15:22:20]

adalbert1977hozzászólásai | válasz erre | 2013.05.25 07:01:06 (67867)
[…] A jelzett eljárás tulajdonképpen a linuxos hdparm programocskára épül: https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase , de a Parted Magic linuxos liveCD előnye az, hogy barátságos, könnyen kezelhető grafikus programfelületet ad hozzá…
[előzmény: (67866) adalbert1977, 2013.05.25 06:56:11]

adalbert1977hozzászólásai | válasz erre | 2013.05.25 06:56:11 (67866)
A Parted Magic linux-os liveCD nemcsak az előbbi kommentemben jelzett eljárásra praktikus, hanem – mivel SSD-kről is beszéltünk tegnap, tegnapelőtt – az összekutyulódott, agyonírt, nem-trimmelt (nem-„tisztott”) SSD-k tartalmának gyári állapotba (gyári teljesítményre) való visszahozatalára is, amelyet persze nem érdemes esztelenül gyakran alkalmazni, hanem csak akkor, ha valóban szükséges. Kalauz (filmes illusztrációval együtt) itt: http://www.overclock.net/t/1227597/how-to-secure-erase-your-solid-state-drive-ssd-with-parted-magic
[előzmény: (67865) adalbert1977, 2013.05.25 06:48:29]

adalbert1977hozzászólásai | válasz erre | 2013.05.25 06:48:29 (67865)
»mkfs.vfat -I /dev/sdd«

Még mielőtt esetleg valaki arra csábul, hogy kihasználja mind az 1.8 gigát, a linuxban járatlanoknak: a /dev/sdd-ben az utolsó d betű esetleges. Ott lehet /dev/sdb, /dev/sdc, /dev/sde stb. is, attól függően, hogy hány adathordozó cuccot lát a rendszer, és a sorozatban hányadikként van felismerve az Oregon beépített tárolója. Tehát nehogy valaki automatikusan adja ki a /dev/sdd-re a nem-szokványos (particionálás nélküli) formázási parancsot, nehogy ezzel egy másik lemez tartalmát gyalulja le. A legegyszerűbb ha letölti a Parted Magic liveCD-t innen: http://partedmagic.com/ , arról külön be-boot-ol, a GParted grafikus felületű programmal leellenőrzi, hogy melyik /dev/sd* az Oregon belső adattárolója. S majd csak azután adja ki a parancsot a konzolban (linuxos „command prompt”-ban). Ha szokványos módon particionáljátok a tárolót, akkor az Oregon nem fogja felismerni. Partíciós táblázat nélküli „partíciót” kér a nulladik szektortól kezdődően. Hogy mindez a(z esetleg még meglévő) garanciát miként befolyásolja, nem tudom. A barátomat nem érdekelte a garancia, mert úgyis kellett neki a JNX-folt a firmware-re.
[előzmény: (67770) adalbert1977, 2013.05.20 20:48:44]

adalbert1977hozzászólásai | válasz erre | 2013.05.25 06:11:04 (67864)
Érdekes :) Mármint az érdekes, hogy akkor miért árulták-adták fele akkora kapacitással.
[előzmény: (67863) gusty, 2013.05.24 23:30:38]

Lapozás: előző | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | következő

Egy lapon megjelenő sorok száma:


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