430 odpovědí na toto téma

[HaLuMa]

To opravdu vypadá na zpomalený počítač, než na konkrétní problém zrovna s mapou.
Může být zpomalený i vyráběním zálohy Geogetu, vyžití to disk... A jestli je pomalý, pocítíš to.

[Kreten8]

Ne počítač ničím zpomalený není, když se podívám na mapy.cz, tak tam vše funguje rychle.

[Kreten8]

Když si spustím správce úloh a kliknu na + u zoomu, tak na 5 vteřin mi to vytíží jedno jádro na 100% a to nepovažuji za normální, normálně se ten zoom udělá okamžitě.

[HaLuMa]

To ti ale nevyresime, to je otazka javascriptu ve tvem prohlizeci vs. Google Maps API.

[dejwy]

Že by "povedená" aktualizace antiviru?

[HaLuMa]

Nebo aktualizace prohlížeče, nebo aktualizace mapového engine u Googlu,...

[Kreten8]

No nevím čím to je, ale v práci to je ještě horší, to mi ten zoom vytíží to jedno jádro na 100% po dobu 10 vteřin. A o jediné změně, která v poslední době proběhla co vím jsou aktualizace Windows, ale to si myslím, že už je před delší dobou a po nich že mi to ještě fungovalo.

[HaLuMa]

Tak to zkus v jiném prohlížeči. Prostě si otevři mapu, spusť jiný prohlížeč a dej do něj to URL, co vidíš v tom původním.

[Kreten8]

No asi Microsoft něco udělal s IE11, ve kterém mám problémy, ve Firefoxu i Chrome to funguje normálně. No co se dá dělat, holt budu používat jiný prohlížeč. V GeoGetu se asi nedá říct, že má používat jiný než výchozí prohlížeč?

Tento příspěvek byl upraven od Kreten8: 17 leden 2019 - 10:31

[HaLuMa]

V nastaveni mu muzes rict libovolne EXE, ktere ma volat misto vychoziho prohlizece.

[Kreten8]

Jo jsem slepej, nějak jsem to  přehlídnul.

[Arne1]

Lisi se tim, ze pro nektere mapy od googlu se dost zmenily parametry predavane pluginem. Je to vynuceno politikou googlu.

Návod se prakticky nezměnil, takže by sekvence parametrů měla být stejná. Ale když použiju 4.5 tak mám puntíky rozsypané po celém okně.

Ostatně - ve tvém profilu máš taky puntíkaté mapy které jsou stejně náhodně rozsypané.

[gord]

Jo, diky. Hledal jsem nejake problemy a nechal tam nastavene nahodne puntiky misto uctu. Opravim to. Ale nemuzu to dat primo na server, jde to pres admina, takze asi az zitra.

[gord]

Tak by to melo byt uz v poradku. Ja uz mam sve puntiky spravne. :-)

 

Co se tyka tech parametru proti verzi 4.4. tak ty jsou vicemene stejne, jen neco malo je navic (stavajici Stator to nepouziva, az nova verze). Nicmene v brzke dobe prestanou puntikate mapy pres verzi 4.4 chodit (pokud nejsou v cache na serveru), protoze verze 4.4. nema upravene volani googlovskych map pro jejich restrikce.

[martin_tulak]

Vec: data eventu. Neco zrejme zmenil GS (nebo jsem neco prehledl). Kdyz si (je to asi tyden dva, co to vidim) dam do GG PQ, kde mam prazske eventy, tak se mi to zobrazi s jinym datem (obvykle o den pozdeji). V PQ je skutecne pozdejsi datum - ale to bude asi neco s casovou zonou, pocitam. Konkretne: event GC82MY1 ma v PQ tohle:

 

<wpt lat="50.035233" lon="14.313483">

    <time>2019-02-03T02:15:00Z</time>

    <name>GC82MY1</name>

 

a v GG se to objevi jako 3. unora. Kdyz tomuto eventu udelam v GG "Update geocache", tak se to zmeni na 2. unora (coz je nas cas, kdy tento event sklutecne probehl). Vypada to tedy, ze GG dostava (nebo dela) jinak data z PQ a jinak pres API. Ono se neco podobneho take objevilo ve forech u GSAKu nedavno. Diky za vysvetleni, co je vlastne jinak a jak to ma byt.

[gord]

Nevim, jak je to v tomto konkretnim pripade, ale obecne lze rici, ze GS ma v casech a casovych zonach mirne receno zmatek. Dlais jednoznacnou veci je, ze data, ktera dava do PQ a ktera posila pres API nejsou shodna. Takze bych klidne odhadoval, ze se zmenama zadavani data a casu u eventu upravil v potrebnem smeru jen data odesilana do API (v horsim pripade upravil odesilani do obou kanalu, ale upravil to ruzne. Ani tomu bych se v jejich pripade moc nedivil.)

[HaLuMa]

To bude tim, ze u eventu ted nove zacali pridavat i cas pocatku eventu. Coz by bylo super, kdyby to udelali spravne.

 

Podivej se na ten cas v PQ. To 'Z' na konci casu znamena ZULU, tedy cas na nultem poledniku. Neco tu nehraje, ze?

 

Ano, maji ten cas zapsany uplne blbe, v nejakem uplne jinem casovem pasmu, nez rikaji. Protoze cas "2019-02-03T02:15:00Z" opravdu neni "2.2.2019 18:15 CET".

[Kreten8]

Nevím co je to za problém, ale nálezy do GeoGetu importuji pomoci souboru geocache_visits.txt z Oregonu 650 a u některých kešek mi chybí čas - je tam 00:00, přitom v tom souboru ten čas uvedený je a když si u kešky smažu nález a naimportuji znovu, tak se mi naimportuje správně i s časem. Vidím to jako problém, neboť občas ten soubor geocache_visits.txt v navigaci smažu, aby nebyl moc veliký a pak u těch starších kešek mi ten čas chybí a už si ho nemůžu znovu naimportovat.

[martin_tulak]

Tento problem asi neni problem ale feature :-) . Ptal jsem se na to pred casem autora, protoze bych to take chtel mit jinak. Pochopil jsem, ze GG ten cas pridava jen u kesek, ktere vytvari v databazi, nikoliv u tech, ktere jen aktualizuje. Byl bych radeji, kdybych mohl z Oregonu dat i cas, i kdyz v GG keska uz je jako nalezena a pokud nema cas 00:00. Vubec nejlepsi, kdyby tohle slo nastavit, zda to tak chci nebo ne.

[Kreten8]

Pochopil jsem, ze GG ten cas pridava jen u kesek, ktere vytvari v databazi, nikoliv u tech, ktere jen aktualizuje.

To určitě ne, neboť já mám všechny kešky v databázi a jen aktualizuji datum a čas nálezu tím importem z geocache_visits.txt