443 odpovědí na toto téma

[gord]

Nalezeno.

Zapoznamkuj v souboru CalcRegionTagSupport.Stator.pas, radek 17

[martin_tulak]

Nalezeno.

Zapoznamkuj v souboru CalcRegionTagSupport.Stator.pas, radek 17

 

Udelal jsem to (byl to tenhle radek: 'IEkraj': begin sCategory:='IS hluti';  end;). A ukazalo to jinou chybu - viz priloha.

Přiložené miniatury

• 

[gord]

Soubor MapGenFromTag.params.ini nahrad radek 13 radkem

VALUES=--- Vyšší územně správní celky|ATkraj - spolkové země Rakouska|CZkraj - kraje ČR|HUkraj - župy Maďarska|SKkraj - kraje Slovenska|--- Nižší územně správní celky|CZokres - okresy ČR|SKokres - okresy Slovenska|ATokres - okresy Rakouska|--- Městské části|BRmesto - městské části Brna|PAmesto - městské části Prahy|OSmesto - městské části Ostravy

(Chybi tam to Irsko)

[martin_tulak]

Diky! Opraveno, funguje, zadna chybova hlaska. Jen jsem to musel opravit v sekci Map_EN, protoze z historickych duvodu porad jeste generuji statistiky anglicky. Jeste jednou diky!

[MikiHamza]

Nazdar! Chtěl bych poprosit o pomoc s "putovní keškou" ve statistikách. 3.4.2015 jsem odlovil v Brně GC6ADF, která v té době měla souřadnice v Oregonu v USA. Při natažení do GeoGetu se to převzalo, takže ve statistikách (zatím) mám mezi odlovenými státy USA, což se mi nelíbí. Ve Statoru jsem měl pouze tuto kešku zadanou mezi těmi, které se nezapočítávají do výpočtu vzdálenosti. Chtěl jsem to ale opravit tak, abych ji měl umístěnou tam, kde jsem ji skutečně našel. Takže jsem změnil v GeoGetu ve vlastnostech bodu souřadnice a umístění (stát a kraj), Divider pak přidělil správné hodnoty tagů. I kontrola databáze pomocí diagnostického modulu ve Statoru proběhla bez chyb. Při tvorbě náhledu se ale tato keška chová podivně. Je započítaná do celkového počtu nalezených keší (%FoundCachesCount%), ale ne do počtu nálezů celkem (%FoundLogsCount%). Je započítána v tabulkách,např. SummaryByTypeInCountry, FindsByDay či DifficultyTerrain, ale není třeba v Milestones.

Experimentoval jsem s tagy i vlastnostmi kešky, ale nic nepomáhalo. Tak jsem kešku z GG vyhodil a znova načetl. Teď už není v USA, ale v Nizozemsku. Po znovunačtení se započítala do statistik dobře, akorát jsem místo nálezu v USA měl Nizozemí. Po dalších postupných úpravách, aby byla v ČR, se opět nezapočítává všude.

Nevím, jestli jsem problém popsal dostatečně srozumitelně, ale byl bych vděčen za jakoukoliv radu.

 

PS: když na upravenou databázi pustím GgStat, tak je to v pořádku

Tento příspěvek byl upraven od MikiHamza: 02 únor 2016 - 14:04

[Bour]

Ve vygenerovaných statistikách mě ukazuje odznáček The Favorite Cacher (BADGES) o 212 fav. bodů víc než na vlastních keších ve skutečnosti mám.

Kde a jak to lze opravit?

[kiReGPS]

Nazdar! Chtěl bych poprosit o pomoc s "putovní keškou" ve statistikách. 3.4.2015 jsem odlovil v Brně GC6ADF, která v té době měla souřadnice v Oregonu v USA. Při natažení do GeoGetu se to převzalo, takže ve statistikách (zatím) mám mezi odlovenými státy USA, což se mi nelíbí. Ve Statoru jsem měl pouze tuto kešku zadanou mezi těmi, které se nezapočítávají do výpočtu vzdálenosti. Chtěl jsem to ale opravit tak, abych ji měl umístěnou tam, kde jsem ji skutečně našel. Takže jsem změnil v GeoGetu ve vlastnostech bodu souřadnice a umístění (stát a kraj), Divider pak přidělil správné hodnoty tagů. I kontrola databáze pomocí diagnostického modulu ve Statoru proběhla bez chyb. Při tvorbě náhledu se ale tato keška chová podivně. Je započítaná do celkového počtu nalezených keší (%FoundCachesCount%), ale ne do počtu nálezů celkem (%FoundLogsCount%). Je započítána v tabulkách,např. SummaryByTypeInCountry, FindsByDay či DifficultyTerrain, ale není třeba v Milestones.
Experimentoval jsem s tagy i vlastnostmi kešky, ale nic nepomáhalo. Tak jsem kešku z GG vyhodil a znova načetl. Teď už není v USA, ale v Nizozemsku. Po znovunačtení se započítala do statistik dobře, akorát jsem místo nálezu v USA měl Nizozemí. Po dalších postupných úpravách, aby byla v ČR, se opět nezapočítává všude.
Nevím, jestli jsem problém popsal dostatečně srozumitelně, ale byl bych vděčen za jakoukoliv radu.
 
PS: když na upravenou databázi pustím GgStat, tak je to v pořádku

 
Hezký studijní případ...   Pro nějakou diagnostiku ale potřebujeme údaje, které teď "po dalších postupných úpravách, aby byla v ČR" u keše máš. Jakou zemi a jaký správní celek (kraj) a jaké tagy (raději všechny). Taky by se hodilo vědět, co je "nezapočítává všude". Jestli jsou to ty výše vyjmenované moduly nebo které přesně. Díky...

Tento příspěvek byl upraven od kiReGPS: 02 únor 2016 - 14:23

[MikiHamza]

 
Hezký studijní případ...   Pro nějakou diagnostiku ale potřebujeme údaje, které teď "po dalších postupných úpravách, aby byla v ČR" u keše máš. Jakou zemi a jaký správní celek (kraj) a jaké tagy (raději všechny). Taky by se hodilo vědět, co je "nezapočítává všude". Jestli jsou to ty výše vyjmenované moduly nebo které přesně. Díky...

Díky moc za zájem, takže současný stav:

Geoget:

Stát - Czech Republic, Území státu - Jihomoravský kraj, bylo změněno, původně u kešky byl Stát - Netherlands, Území státu - Noord-Brabant

Souřadnice změněny na N 49° 10.680 E 016° 33.008, původně bylo nataženo z kešky N 51°41.911 E 005°15.668

Na základě takto změněných údajů pak Divider natáhl správně tagy, předtím tam žádné nebyly

CZ kraj = Jihomoravský

CZ mestska cast =Brno-Nový Lískovec

CZ okres = Brno-město

CZ Povereny urad = Brno

Dále změněn ještě tag timezone na Europe/Prague

Další tagy:

attribute=firstaid-yes

attribute=stealth-no

Elevation=294

favorites=198

FoundLogWordsCount=62

gcimage=X

import=GC.Live

mdCachingPoints=8

 

 

V GeoGetu mám 4149 odlovených kešek, stejně jako v profilu na gc.com. Mám v GeoGetu doplněno i 6 lab keší.

Takže ve statistikách vytvořených Statorem by měla být čísla pro nalezeno a nálezů celkem stejná, což bylo do té doby, než jsem provedl uvedené úpravy. Místo toho tam teď je:

MikiHamza má nalezeno 4149 keší (4148 nálezů celkem) a založeno 32 keší vlastních

Ve statistikách jsou správně asi všechny tabulky, aspoň ty, kde je uveden celkový počet keší, tj.:

DifficultyTerrain

FindsByDay

FindsByHour

SummaryByTypeInCountry

Špatně je počet kešek v modulech Milestones a CustomizedTable, která tvoří tabulku xTF.

 

Zajímavé je že ve statistikách u profilu na gc.com tato keška je započítaná všude, mimo map. Stejně tato keška chybí i na project-gc.com v mapách, jinak ve statistikách je (ale zas tam nejsou labky, takže počet keší je jen 4143).

 

Pokud by se tím chtěl někdo zabývat, mohu poslat jakýkoliv soubor. Na mém profilu je předchozí stav, kdy je o jednu kešku celkově méně, a uvedená keška je v USA.

 

Jak už jsem uvedl, proměnná %FoundCachesCount%, která je použita ve výše uvedeném tučném záhlaví statistik, je správně, ale tento výraz - %Evaluate(%FoundLogsCount%+%Calc_CacheLabCount%,0)% - podává špatné číslo

[honza.h]

Ahoj, rozkoukávám se v nastavování puntíkaté mapy a mám jeden dotaz... Když jsem si hrál se svou statistikou, ať jsem do parametru Area zvolil cokoli, vždy se mi zobrazily jen tečky bez mapového podkladu. Tak jsem si říkal, že je něco blbě v nějakým nastavení... Jenže když se teď dívám na profily jiných (gordici, kireGPS), vidím puntíkatou mapu taky bez podkladu. Uprostřed je jakýsi symbol ve smyslu, že se obrázek nenačetl... V čem by teda mohl být problém? Díky za rady...

[DrakMrak]

výpadek někde na servru geocaching.cz který ty obrázky generuje ... nebo něco takového

[kiReGPS]

Ahoj, rozkoukávám se v nastavování puntíkaté mapy a mám jeden dotaz... Když jsem si hrál se svou statistikou, ať jsem do parametru Area zvolil cokoli, vždy se mi zobrazily jen tečky bez mapového podkladu. Tak jsem si říkal, že je něco blbě v nějakým nastavení... Jenže když se teď dívám na profily jiných (gordici, kireGPS), vidím puntíkatou mapu taky bez podkladu. Uprostřed je jakýsi symbol ve smyslu, že se obrázek nenačetl... V čem by teda mohl být problém? Díky za rady...

 

Puntíkatá mapa je tvořena dvěma (či více při rozfázování let) obrázky přes sebe. Pokladová mapa se získává službou Google Static Maps. Přes ní jsou pak průhledné vrstvy s puntíky, které tvoří generátor zde na GC.CZ. Googlí služba má omezení v počtu map za určitý čas z jedné IP adresy. To co popisuješ, vzniká v situaci, kdy Google vyhodnotí, že byl limit překročen. Pak ať koukneš kam koukneš, všude uvidíš místo podkladové mapy symbol s čímsi přeškrnutým. Přes něj jsou vzorně puntíky z místního nelimitovaného generátoru.

 

Normálně k dosažení limitu nedochází. Je dosti vysoký, tuším 1000 map za 24 hodin. Problémem jsou sdílené IP adresy, především přístup přes mobilní data. Pro Googlovský server se mohou přístupy všech uživatelů ze sítě mobilního operátora jevit jako z jedné IP adresy. A limit je v čudu hned...

[kiReGPS]

V GeoGetu mám 4149 odlovených kešek, stejně jako v profilu na gc.com. Mám v GeoGetu doplněno i 6 lab keší.

Takže ve statistikách vytvořených Statorem by měla být čísla pro nalezeno a nálezů celkem stejná, což bylo do té doby, než jsem provedl uvedené úpravy. Místo toho tam teď je:

MikiHamza má nalezeno 4149 keší (4148 nálezů celkem) a založeno 32 keší vlastních

Ve statistikách jsou správně asi všechny tabulky, aspoň ty, kde je uveden celkový počet keší, tj.:

DifficultyTerrain

FindsByDay

FindsByHour

SummaryByTypeInCountry

Špatně je počet kešek v modulech Milestones a CustomizedTable, která tvoří tabulku xTF.

 

Zajímavé je že ve statistikách u profilu na gc.com tato keška je započítaná všude, mimo map. Stejně tato keška chybí i na project-gc.com v mapách, jinak ve statistikách je (ale zas tam nejsou labky, takže počet keší je jen 4143).

 

Pokud by se tím chtěl někdo zabývat, mohu poslat jakýkoliv soubor. Na mém profilu je předchozí stav, kdy je o jednu kešku celkově méně, a uvedená keška je v USA.

 

Jak už jsem uvedl, proměnná %FoundCachesCount%, která je použita ve výše uvedeném tučném záhlaví statistik, je správně, ale tento výraz - %Evaluate(%FoundLogsCount%+%Calc_CacheLabCount%,0)% - podává špatné číslo

 

Je zřejmé, že máš špatně počet nálezových logů. Proměnná %FoundCachesCount% obsahuje počet keší, které mají označený nález (včetně Lab keší). Proměnná %FoundLogsCount% naproti tomu obsahuje počet nálezových logů (tj. logů typu "Found it", "Attended" nebo "Webcam Photo Taken"). Labky logy nemají, proto se jejich počet v tučném výpisu přidává.

 

Potvrdit si to můžeš diagnostickým profilem. Ten vypíše i problémovou keš (zřejmě tu editovanou).

[MikiHamza]

Je zřejmé, že máš špatně počet nálezových logů. Proměnná %FoundCachesCount% obsahuje počet keší, které mají označený nález (včetně Lab keší). Proměnná %FoundLogsCount% naproti tomu obsahuje počet nálezových logů (tj. logů typu "Found it", "Attended" nebo "Webcam Photo Taken"). Labky logy nemají, proto se jejich počet v tučném výpisu přidává.

 

Potvrdit si to můžeš diagnostickým profilem. Ten vypíše i problémovou keš (zřejmě tu editovanou).

Už jsem to napsal v první příspěvku, že diagnostický modul nenahlásí žádnou chybu. Jazykem dotazů nevládnu, ale i tak jsem si našel definice výše uvedených proměnných, kde ta FoundCachesCount je jasná, tzn. bere z databáze keše, které mají gc.dtfound>0. Ale u proměnné FoundLogsCount je ten výraz na mne moc složitý a nerozumím mu, mimo té podmínky type="Found it" OR type="Attended" OR type="Webcam Photo Taken". Takže už dříve jsem pro sichr ještě jednou načetl logy, ale nic nepomáhá. Nedokážu rozklíčovat ty další výběrové podmínky. Dokázal by mi někdo přeložit ten výraz do srozumitelné podoby, např. proč je tam geolog gl namísto geocache gc oproti první proměnné?

 

AddVariableToList(' FoundLogsCount','Set in StatorGen.ggp','GENERATOR',Geoget_DB.GetTableString(
      'SELECT count(finder) pocet FROM geolog gl'
      +' WHERE finder='''+GEOGET_OWNER+''' COLLATE NOCASE AND'
      +'  (type="Found it" OR type="Attended" OR type="Webcam Photo Taken")'
      +' AND '+ReplaceString(sCachePrefixForSql,'gc.','gl.')
      ));

[gord]

gl misto gc: protoze logy jsou nacitany z tabulky geolog (po formalni strance oznacene jako gl). Tabulka geocache (gc) zadne logy neobsahuje (viz prehled dat ulozenych v databazi)

[MikiHamza]

gl misto gc: protoze logy jsou nacitany z tabulky geolog (po formalni strance oznacene jako gl). Tabulka geocache (gc) zadne logy neobsahuje (viz prehled dat ulozenych v databazi)

Díky za informaci. Zkusím dál bádat. Vzhledem k tomu, že uvedená keška "vypadla" i z FTF tabulky a milníků, tak mi to připadá na ztrátu vazby mezi geocache a geolog pro danou kešku. Asi se budu muset naučit ty SQL dotazy

[gord]

Tabulkia FTF nema s logy nic spolecneho, to je veci TAGu FTF. A milniky zavisi na tom, jak mas nastaveno razeni nalezu (kombinace datum+cas+id lodu). Neni treba se naucit SQL, ale je treba vedet, co mas ulozeno v databazi.

[MikiHamza]

Tabulkia FTF nema s logy nic spolecneho, to je veci TAGu FTF. A milniky zavisi na tom, jak mas nastaveno razeni nalezu (kombinace datum+cas+id lodu). Neni treba se naucit SQL, ale je treba vedet, co mas ulozeno v databazi.

S těmi FTF a milníky to bylo myšleno tak, že po "zmizení" té jedné kešky z počtu zalogovaných došlo k posunu, takže když dříve bylo FTF na kešce 4000, tak potom bylo na kešce 3999. Stejně tak u milníků.

 

Jinak děkuji všem za podněty, na jejichž základě jsem se v tom začal babrat od začátku. Do nové prázdné databáze jsem načetl znovu všechny nalezené, změnil postupně (tj. v několika krocích, přičemž po každém jsem udělal náhled statistik) potřebné údaje u inkriminované kešky, a bylo to v pořádku. Neměl jsem ale načtené žádné logy. Takže jsem pak pustil Logator (jelo to cca 2 hodiny), a i potom to bylo v pořádku. Takže jsem pak doplnil labky a ručně doplnil data zalogování a zatím to je furt v pořádku. Takže teď to zkusím na ostré databázi. Když podobné věci řeším se zákazníky, a podaří se vyřešit problém bez toho, že by člověk zjistil příčinu, tak jim tvrdím, že za to můžou trpaslíci. Ti, jak každý ví, jsou ze všeho nejhorší, a jsou ukryti v každém počítači.

[gord]

Tak to je snad logicke, ze kdyz ze seznamu  kesi vypadne jedna, tak je vse posunuto, ne?

 

Ja ti nebudu tvrdit, ze za to muzou trpaslici. Muzou za to data v databazi. To je jednoznacne.

[kiReGPS]

Podle toho, co MikiHamza psal, jen "přesadil" keš z Nizozemí do Čech. Žádnou nemazal. Podle všeho měl jen odlišný počet nálezových logů. Ale těžko říct, když nový pokus na čisté louce dopadl OK.

 

Já bych tipoval trpaslíky... 

[gord]

V prvnim prispevku psal, ze ji smazal a nacetl znovu. Netusim, jaky mel puvodne log v databazi (opravdu stare logy vubec nemely logid), takze znovu nacteni kese vubec nemuselo byt schopno vratit se do puvodniho stavu. Nepise nic o nastaveni pro urceni poradi logu a na primou otazku neodpovedel (nebo jsem to nezaznamnenal). Ted pise o tom, jak si vyklada pojem "nezarazuje se do milniku" a nejak mi to nekoresponduje s prvnim jeho prispevkem. Takze opravdu bez dat tezko neco predjimat.

 

EDIT: TIP: Pokud nastavis krok milniku na 1, pak uvidis vsechny kese v zapocitavanem poradi.

Tento příspěvek byl upraven od gord: 03 únor 2016 - 14:46