128 odpovědí na toto téma

[HaLuMa]

Klid, eventy urcite budou mit svoje hejblatko.

[HaLuMa]

...krom toho, stare eventy by mely byt davno archivovane. Archivovane kese se standardne taky neukazuji, leda ze si to heblatkem zapnes.

[HaLuMa]

Debata na tema oznacovani archivovanych kesi presunuta sem: http://www.geocachin...esi-s-novym-api

Tento příspěvek byl upraven od HaLuMa: 04 květen 2019 - 15:07

[taxoft]

Dovoluji si upozornit, že právě bylo publikováno školení GeoGetu, které bude zaměřeno na změny vyvolané novou verzí API a také na nový mapový modul.

 

Zájemci nechť se hlásí zde: https://coord.info/GC87D01

[mpik]

Zajímavé, ale bohužel v této době se do Prahy nedostanu.

[gord]

Narazil jsem na problem. Nejak se mape nechce kreslit kesky, vzdy jen flek, jako by jich tam bylo moc. V tomto pripade ale kazdy flek obnasi opravdu jen jedinou kesku.

 

 

 

https://ctrlv.cz/QtQr

 

EDIT: Jedna se o zobrazeni kesi GC85W5H, GC8558M, GC87378, GC86HD0, GC85ZFB, GC8557N, GC8445Y

Tento příspěvek byl upraven od gord: 06 květen 2019 - 13:10

[HaLuMa]

To je vlastnost, klicove totiz je, kolik by tam pri tomto zoomu mohlo byt zobrazeno kesi. Kdyz moc, prepne se to na heatmapu. A tohle se zjistuje z informaci, ktere ani neni mozne filtrovat. A az kdyz zjisti, ze tech kesi v danem uzemi je dostatecne malo, tak teprve pro ne si zjisti podrobnejsi informace a muze je filtrovat.

[gord]

No, to je trochu dost zavadejici, to "mohlo byt zobrazeno". Tohle jsou kese v okne a vic jich tam neni. Kazda je (skoro) na jinem konci Prahy a na mape videt nejsou. To je dost neprijemne.

 

EDIT: Tak me napada ... nejake zaskrtavatko, ktere by potlacilo heat mapu ... Ja mel i v te stare to shlukovani uplne vypnute ...

Tento příspěvek byl upraven od gord: 06 květen 2019 - 14:08

[HaLuMa]

Ony videt jsou, jen musis jeste o fous prizoomovat.

[HaLuMa]

Ale ja neco zkusim vymyslet, neboj.

[vkvkvk]

Podařilo se mi vyloudit chybuSyntaxError: JSON.parse: expected double-quoted property name at line 841 column 41 of the JSON dataggmap.js:547:33

    onreadystatechange http://localhost:54545/ggmap/ggmap.js:547

(poté ještě varování Will-change memory consumption is too high. Budget limit is the document surface area multiplied by 3 (979200 px). Occurrences of will-change over the budget will be ignored. ggmap.html)

Chyba naskakuje při každé změně zoomu znovu.

posílá požadavek http://localhost:545...ofound,onlylist

a vrací se hodnota:

{

 "count": 163,

 "cache": [

  { "k": 517, "id": "GC4AF4B", "x": 50.461867, "y": 13.361283, "t": "Traditional Cache", "cs": 0, "us": 0, "df": 0, "l": 1, "fi": 0},

  { "k": 643, "id": "GC2YF5C", "x": 50.476483, "y": 13.421517, "t": "Multi-cache", "cs": 0, "us": 0, "df": 0, "l": 1, "fi": 0},

  { "k": 2843, "id": "GC3PG0Y", "x": 50.474083, "y": 13.320483, "t": "Traditional Cache", "cs": 0, "us": 0, "df": 0, "l": 1, "fi": 0},

  { "k": 2848, "id": "GC4F1H3", "x": 50.467067, "y": 13.392883, "t": "Multi-cache", "cs": 0, "us": 0, "df": 0, "l": 1, "fi": 0},

  { "k": 2856, "id": "GC4TYR8", "x": 50.476467, "y": 13.3694, "t": "Traditional Cache", "cs": 0, "us": 0, "df": 0, "l": 1, "fi": 0},

  { "k": 19633, "id": "GC5TN4T", "x": 50.456383, "y": 13.318417, "t": "Traditional Cache", "cs": 0, "us": 0, "df": 0, "l": 1, "fi": 0},

  { "k": 21975, "id": "GC575J0", "x": 50.474867, "y": 13.325233, "t": "Traditional Cache", "cs": 0, "us": 0, "df": 0, "l": 1, "fi": 0},

  { "k": 29317, "id": "GC6X9YG", "x": 50.467417, "y": 13.3809, "t": "Multi-cache", "cs": 0, "us": 0, "df": 0, "l": 1, "fi": 0},

  { "k": 30293, "id": "GC62KE2", "x": 50.47445, "y": 13.391317, "t": "Unknown Cache", "cs": 0, "us": 0, "df": 0, "l": 1, "fi": 1},

  { "k": 56357, "id": "GC7WEDA", "x": 50.45575, "y": 13.356367, "t": "Traditional Cache", "cs": 0, "us": 0, "df": 0, "l": 1, "fi": 0},

  { "k": 61171, "id": "GC7YZNH", "x": 50.4783, "y": 13.394567, "t": "Unknown Cache", "cs": 0, "us": 0, "df": 0, "l": 1, "fi": 0},

  { "k": 62042, "id": "GC81CDP", "x": 50.4568, "y": 13.353067, "t": "Unknown Cache", "cs": 0, "us": 0, "df": 0, "l": 1, "fi": 1},

  { "k": 62254, "id": "GC82M23", "x": 50.46125, "y": 13.414033, "t": "Traditional Cache", "cs": 0, "us": 0, "df": 0, "l": 1, "fi": 0} ],

 "wpt": [

  { "k": 51, "id": "GC2YF5C", "x": 50.4777, "y": 13.422267, "t": "Parking Area", "f": 1, "cs": 0, "df": 0},

  { "k": 52, "id": "GC2YF5C", "x": 50.476483, "y": 13.421517, "t": "Stages of a Multicache", "f": 1, "cs": 0, "df": 0},

  { "k": 3311, "id": "GC4F1H3", "x": 50.467067, "y": 13.392883, "t": "Question to Answer", "f": 1, "cs": 0, "df": 0},

  { "k": 3312, "id": "GC4F1H3", "x": 50.46705, "y": 13.391883, "t": "Question to Answer", "f": 1, "cs": 0, "df": 0},

  { "k": 3313, "id": "GC4F1H3", "x": 50.4668, "y": 13.39345, "t": "Stages of a Multicache", "f": 1, "cs": 0, "df": 0},

  { "k": 3319, "id": "GC4TYR8", "x": 50.47845, "y": 13.37025, "t": "Parking Area", "f": 1, "cs": 0, "df": 0},

  { "k": 7047, "id": "GC4F1H3", "x": 50,46573, "y": 13,38888, "t": "Stages of a Multicache", "f": 0, "cs": 0, "df": 0},

  { "k": 12067, "id": "GC4AF4B", "x": 50.4591, "y": 13.36055, "t": "Parking Area", "f": 1, "cs": 0, "df": 0},

  { "k": 20046, "id": "GC5TN4T", "x": 50.455117, "y": 13.3205, "t": "Reference Point", "f": 1, "cs": 0, "df": 0},

  { "k": 30063, "id": "GC6X9YG", "x": 50,46483, "y": 13,38325, "t": "Stages of a Multicache", "f": 0, "cs": 0, "df": 0},

  { "k": 30986, "id": "GC62KE2", "x": 50.474133, "y": 13.390317, "t": "Parking Area", "f": 1, "cs": 0, "df": 0},

  { "k": 30987, "id": "GC62KE2", "x": 50.47445, "y": 13.391317, "t": "Final Location", "f": 1, "cs": 0, "df": 0},

  { "k": 69569, "id": "GC7YZNH", "x": 50.4783, "y": 13.394567, "t": "Stages of a Multicache", "f": 1, "cs": 0, "df": 0},

  { "k": 69570, "id": "GC7YZNH", "x": 50.476567, "y": 13.39695, "t": "Parking Area", "f": 1, "cs": 0, "df": 0},

  { "k": 70551, "id": "GC81CDP", "x": 50.4566844298601, "y": 13.3532824103432, "t": "Final Location", "f": 0, "cs": 0, "df": 0},

  { "k": 70661, "id": "GC82M23", "x": 50.461315, "y": 13.414033, "t": "Parking Area", "f": 1, "cs": 0, "df": 0} ]

}

 

Používám Win7 ve VirtualBoxu, prohlížeč FF Develoer Edition 67.0b16

[vkvkvk]

Myslím, že jsem zjistil příčinu:

{ "k": 7101, "id": "GC50QCR", "x": 50,49627, "y": 13,36543, "t": "Stages of a Multicache", "f": 0, "cs": 0, "df": 0},

  { "k": 7102, "id": "GC50QCR", "x": 50,49495, "y": 13,3696, "t": "Stages of a Multicache", "f": 0, "cs": 0, "df": 0},

  

Místo teček jsou v souřadnicích čárky.

[vkvkvk]

Jedná se o waypointy, které jsem dělal já. Mám pocit, že jsem je svým pluginem přetahoval z DB L4C. Pro vkládání používám objekt TWpt, tak jsem čekal, že si vstupy ohlídá a případně mě odkáže do někam.

[HaLuMa]

To rozhodne musi vadit, nicmene jsem si jisty, ze Geoget by tam tu carku do databaze sam nedal. Nemohlo se ti to tam dostat do dat nejak jinak?

Hm, to mas recht, tam by si to ohlidat mohlo, hodim na to oko.

[gord]

Stator ti urcite tohle jako chybu nahlasi (v diagnostickem profilu).

[vkvkvk]

HaLuMa: otázka,

• zda kontrolovat data na vstupu do DB (jistě),
• nebo při generování json, aby bylo validní.
• Případně by mapa při parsování mohla říci: "Sorry vole error máš v DB blbá data". Možná by to stačilo, pokud by následovala rada, jak podezřelou hodnotu dohledat - Mě to bonzla vývojářská konzole, ale to není pro všechny.

 

Já jdu hledat nejjednodušší způsob, jak si data opravit. SQL používám nejraději přes klikátka, ale jak mu říci vem hodnotu x, dej tečku místo čárky a vrať zpátky, to zatím netuším. Svých waypointů mám 409 a ručně by to byl opruz. Asi to odnese nějaký plugin.

 

P. S.: Stator nepoužívám, jelikož bych měl depku jak lov flákám.

[HaLuMa]

Tak predne, kdyz si sam zadavas souradnice bylo by dobre pouzivat metody LatNum a LonNum. Tim se vyhnes pripadnym podobnym omylum. Takze napavy by mohl zvladnum malicky plugin, ktery ostupne probehne ty waypointy, u kazdeho z nich precte souradnice v textovem formatu, prevede je na cislo pomoci StrToFl, a vysledek das do toho LatNum nebo LonNum a ulozis.

 

Jinak ano, pri ukladani bych tohle mel kontrolovat. To je bez debat.

 

Validace pri generovani dat pro mapu neni dobry napad. Ja tam schvalne optimalizuji jak divý, aby to bylo co nejrychlejsi, a pak to zabiju tim, ze budu u kazde souradnice testovat, jeslti si nekdo nenacpal do sloupce se souradnici nesmysl?

 

Chybu pri parsovani ti ale nijak neosetrim, nic ti nenapisu, protoze ja ten JSON neparsuju. Javascript umi sam o sobe prevest ten JSON na javascriptovy objekt, a osetrovani chyb u toho neumim. Nezapomen, ze jde opet o maximalni moznou rychlost, ze tam takhle predavam treba i nekolik milionu zaznamu. To neni dobre misto na to se s daty nejak mazlit.

 

Zduraznuji, ze toto neni problem bezneho uzivatele, ale jen toho, kdo si si ta data sam nestandardne rozbil. (byt nevedomky). Kvuli tomu nema smysl vsem ostatnim tu mapu zpomalit, ne?

[vkvkvk]

Za LatNum a LonNum díky. Opravím si svůj skript. Data jsem si už opravil pluginem. Mapa šlape jak hodinky.

 

Ošetřením parsování jsem myslel zabalit to do TRY CATCH, jelikož to hází standardní výjimku. Uživateli sdělit, že má binec v datech. Je mi jasné, že nemůžeš napsat udělala to tahle keška, tento WP. Tohle je asi z hlediska výkonu nejlepší.

Případně do budoucna plugin na kontrolu dat.

[mikeant]

Dnes jsem poprvé vyzkoušel novou mapu keší. Běhá opravdu parádně svižně, jsem nadšen. Jen opravdu v místech s hustějším osazením keší jsou ty waypointy opravdu nepřehledné. S tím bych se i smířil, ale nešlo by prosím alespoň obnovit původní funkcionalitu poskakování waypointů při ukázání na některý z nich patřící ke stejné keši, či ikonku keše? Hledal jsem finálku vyluštěného otazníčku a v té záplavě wp okolo to dalo docela práci...

[HaLuMa]

To je vec, ktera se tam jeste vubec nestihla udelat, ale je rozhodne v planu, neboj.