FAQ
Előzmények

nemethadamhozzászólásai | válasz erre | 2009.09.16 21:14:51 (43287)
Tisztul_A_Visztula jól emlékezett, régen valóban szeptember utolsó vasárnapja volt az ideje a téli időszámításra átállásnak. Régi (W95) windowsoknak registry piszkálással kellett a szeptember vége helyett az október végét tanítani.
[előzmény: (43259) jekaeff, 2009.09.16 10:03:22]

jekaeffhozzászólásai | válasz erre | 2009.09.16 10:03:22 (43259)
1.) Nincs beégetve a magyarországi időzóna, a PC időzónája lapján számolja az eltérést a ZULU-tól.

2.) A március és az október azért van beleégetve, mert úgy szól a SZABÁLY, hogy március és október utolsó vasárnapjának hajnalán hajnali 2 ill. 3 órakor változik a nyári időszámítás. A sok macera azzal is volt, hogy kiszámoljam hogy az adott évben melyik az utolsó márciusi illetve októberi vasárnap.
[előzmény: (43257) 2009.09.16 09:52:27]

hozzászólásai | válasz erre | 2009.09.16 09:52:27 (43257)
Ha már szóba hoztad, hogy lesz hivatalos verzió, akkor lenne még egy szép témakör: az időzóna és a nyári időszámítás, hiszen a cmt helyi időben rögzít (legalábbis nálam), míg a time az UMT (igaz, hogy a Mapsource-ban meg lehet helyi időben is jeleníteni), mind a trackpointoknál, mind a waypointoknál.

Mivel a program nevében benne van az, hogy "HUN", ezért feltételezem, hogy be van égetve az is, hogy ha a cmt-ből dolgozol, ott egy órát le kell vonni (minimum).
Én a progim mostani verziójában nem akartam előre rögzíteni 10-20 év nyári időszámítási adatait (tehát hogy mikor kezdődik illetve végződik a nyári időszámítás), hanem készítettem egy checkbox-ot. Nálam ez ahhoz kell, hogy ha a time van meg, de a cmt nem, vagy fordítva, akkor a kölcsönös kitöltés után is konzisztens legyen a két mező.

Te hogyan oldottad meg? .......
................Pontosabban mivel nem voltam rest és a forrást most már megnéztem, úgy is kérdezhetném, hogy nem értem a UnixtoLocal alatti részt. Főleg az zavar be nálam ,hogy mit keres ott a március és az október mint fix adat, ha a konkrét nyári időszámítás kezdő és végnapokat úgy is "meg kell szerezni" valahonnan.

A "ConvertGarminShitToUNIXtime" teccik :-)) Beszédesebb bárminél.
[előzmény: (43254) jekaeff, 2009.09.16 07:45:30]

jekaeffhozzászólásai | válasz erre | 2009.09.16 07:45:30 (43254)
Nomindegy, majd meglátom, meg-e akarom-e-é-e valósítani ezt a csodás funkciót a (remélhetőleg hétvégén már tényleg elkészülő) legújabb hivatalos verzióban, vagy sem. De ha kész lesz, akkor is inkább úgy oldom meg, ahogy az előző hozzászólásom végén írtam a zárójeles szakaszban. Többször beolvasgatni a fájlt nem túl elegáns. Csak nem szívesen nyúlok be a program gyökereiig ilyesmi miatt, mert lassan már magam se tudom mit miért csinál a progi...
[előzmény: (43253) 2009.09.16 00:41:48]

hozzászólásai | válasz erre | 2009.09.16 00:41:48 (43253)
Egy uccsó megjegyzés a C-hez:

A megoldás a kétszeri fájlbeolvasás. Az első alapján megvan a track időintervalluma, amit a második beolvasásnál fel tudsz használni. ;-)

Én már csak tudom, hiszen már 4 fájllal dolgozik a progim :-))
[előzmény: (43252) jekaeff, 2009.09.16 00:14:20]

jekaeffhozzászólásai | válasz erre | 2009.09.16 00:14:20 (43252)
Huhhhh, még jó, hogy mindig ilyen egyszerűeket tudsz kérdezni. :P


A.)

i) Magyarán ha meghamisítod a waypoint adatait, akkor nem úgy működik a program ahogy szeretnéd? ;)

Egyébként részben te magad is megválaszolod ezt az ii) pontban: ha mozgattad a pontot, azért tetted, mert jól tudtad, hogy az wp valójában nem ott volt, hanem közelebb egy másik trackponthoz, így elveszted ugyan az időkódot, de még pontosabb pozíciója is lesz a wp-nak a szintprofilon. Nagyon rossz helyre azonban eredeti helyén sem került volna a wp, mert nem egyszerűen "befűzöm" azt olyankor wp-ot a track-be, mert akkor meghosszabbodna a trackhossz! Ehelyett az időben előtte ("A") és mögötte ("B") következő trackpont közti egyenesre illesztem, olyan arányban, amilyen távolságának aránya A-tól és B-től (ez ugyan nem a legtökéletesebb módszer, de nem volt kedvem olyasmivel szórakozni, hogy merőlegest bocsátok egy ellipszoid felszínén lévő egyenesre).

Tehát igazából csak a magasság kozmetikázásakor van gond, ezt elismerem. :o)

ii) Lásd előbb

iii) Akár le is okézhatod, azért találták ki a Ctrl+Z-t hogy az ilyen hibás döntések visszavonhatóak legyenek.


B.) Még az oda-vissza utaknál sem gond, ha fejben tartod, hogy ha már kozmetikázol, akkor úgy igazítsd a wp pozícióját, hogy a megfelelő útszakaszhoz legyen közelebb (bár szemre sajnos nem feltétlenül látszik, hogy melyik az oda és melyik a visszaút, kicsit esetleg nyomozni kell).


C.) Valaki egyszer azt írta nekem, hogy a tag-ek pozíciója kötött a GPX fájlon belül. No, nemcsak azoké kötött, hanem az ojjektumoké is: először jönnek a wp-ok, és csak utána a track-ek. Tehát a wp-ok beolvasásakor még nem lehet tudni mi az érvényes intervallum és mi nem. Főleg, ha több track-et is tartalmaz a GPX fájl, és galádul csak néhányat pipálsz ki feldolgozásra.

Persze meg lehetne jegyezni mind a három dátumot is és később a track-en való végiglépkedéskor, amikor megpróbálom illeszteni a trackpontok közé, akkor mindegyik dátumra vizsgálni, hogy illeszkedik-e az előző és a következő trackpont közé mint időkód. Majd ha valamelyik illeszkedik, abba is lehet hagyni az adott pont illesztését. Bár ez jócskán megbonyolítja a dolgokat, mert minden waypoint-nál két plusz dátumot is nyilván kell tartani, nomeg egy mutatót, hogy a három dátum közül melyik az igazi (vagy egy negyedik dátum mezőt, amibe besoroláskor automatikusan bekerülne az "igazi" dátum).

ÁÁÁÁÁÁÁÁ, ez nem hangzik túl egyszerűnek ...pedig esküszöm, hogy én minden nyakatekert dologra megpróbáltam felkészíteni a programot, de a felhasználóktól minden kitelik! :P

(Esetleg még azt lehetne, hogy csak a track-ek beolvasása után amikor már ismerem az "érvényes" intervallumokat, akkor próbálom meg dekódolni a garmi idióta dátumformátumát a komment mezőkben és ha az jobban illeszkedik mint a "time" tag-ek közé írt dátum - már ha volt ilyen -, akkor azzal felülírom wp dátumát.)
[előzmény: (43243) 2009.09.15 22:32:43]

hozzászólásai | válasz erre | 2009.09.15 22:32:43 (43243)
A) Ha pontosan írtad le az algoritmus logikáját, akkor elveszik a cmt-ben lévő tökéletes időpont információ, ha van time mező, de az trackelés előtti/utáni (ld 60csx).
Hiszen Beolvasás 1) szerint minden OK, viszont Wpt besorolása 1)-en megbukik az adott útpont time mezőjének értéke automatikus besorolás mellett és csak közelít.

Tehát ha módosítasz Mapsource-ban 60csx-es track útpontot.:

i) A név és szimbólum változásnál nem rendel hozzá semmt a time-hoz, de ha a koordinátákat vagy a magasságot módosítod vagy csak véletlenül rákattintasz a mélység, hőmérséklet, közelség ismeretlen előtt lévő tickbox-okra, akkor létrejön a time.

ii) Az SRTM_HUN szempontjából a a koordináta módosításnál nem is baj, ha a cmt már nem számít, hiszen mozgattad a pontot. Ha viszont otthon rájössz, hogy ismered a pontos magasságát egy adott csúcsnak, akkor még véletlenül sem érdemes átírni.

iii) Ha rossz helyre kattintasz a wp szerkesztése közben, akkor szigorúan cancel, mert más különben elmenti a time-t

B) Az egész fejtegetés tényleg csak az oda-vissza jellegű túráknál releváns.

C) Miért nem úgy működik a progi automatikus beállítás mellett a beolvasás, hogy
1. time, ha van és intervallumon belül van, KÜLÖNBEN (az értelmességét tényleg nem kell vizsgálni, ahogy Te is írod, bár ha rosszul írtam meg free pascalban a progimat, akkor a "de miért ne lenne az"-ra meg is van a válasz :-))) )
2. cmt, ha van és értelmes és intervallumon belül van KÜLÖNBEN
3. desc, ha van és értelmes és intervallumon belül van KÜLÖNBEN?

Tehát már a beolvasásnál vizsgálva az időintervallumon belülre esést?

[előzmény: (43229) jekaeff, 2009.09.15 19:34:01]

jekaeffhozzászólásai | válasz erre | 2009.09.15 19:34:01 (43229)
Nem egészen így múkodik, talán így egyszerűbb leírva:


Beolvasás:

1.) Ha van [time] mező, akkor azt tekinti a program a waypoint dátumának (ha nem megfelelő formátumú, akkor szívás, ezt nem vizsgálom külön - de miért ne lenne az?)

2.) Ha nincs time mező ÉS a [cmt] VAGY a [desc] mező egyikében szerepel "érvényes" nyakatekert-garmin-dátum, akkor azt használja waypoint dátumként (ha a [cmt] megfelelő, akkor a [desc]-el már nem is foglalkozik a program)


Wpt besorolása:

1.) Ha a fenti három mező valamelyikéből sikerült értelmes dátumot fabrikálni és NEM erőltetett távolság szerinti besorolás van beállítva (automatikus helyett), akkor program megpróbálja a trackpontok dátuma alapján besorolni a wpt-ot a track megfelelő pontjára vagy két pont közé.

2.) Ha az előző besorolás nem sikerült (a track-időintervallumon kívül esik a vizsgált waypoint dátuma) és NEM erőltetett időpont szerinti besorolás van beállítva (tehát automatikus vagy távolság-alapú), akkor a program trackpontoktól mért távolság alapján próbálja besorolni a wpt-ot, a legközelebbi trackpontra.
[előzmény: (43227) 2009.09.15 19:01:04]

hozzászólásai | válasz erre | 2009.09.15 19:01:04 (43227)
JEKAEFF

Még mindig waypointok!

Ha jól értettem, akkor az SRTM_HUN nem foglalkozik a time mezővel, amennyiben annak az értéke nem a garmin alapformátumú dátuma+időpontja VAGY ha az kívül esik a track kezdete és vége által meghatározott idősávból, ez esetben a cmt mező alapján dolgozik a progi

Ha jól értettem, akkor az SRTM_HUN nem foglalkozik a cmt mezővel, amennyiben annak az értéke nem a garmin alapformátumú dátuma+időpontja VAGY ha az kívül esik a track kezdete és vége által meghatározott idősávból, s ez esetben megkeresi a legközelebbi trackpontot.

De mi van akkor, ha a time is jó, meg a cmt is. Melyiket preferálja a program???

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

Felhasználónevedet és jelszavadat a turistautak.hu oldalon is használhatod!

[fejlesztési ötletek] [grafikonok] [szavazások] [jogi tudnivalók] [e-mail] [impresszum]