Pripadne, pokud by to fakt byl jen divider, pak smaz vsechny jeho tagy (Nastroje tagu, smazat kategorii), odinstaluj soubory s polygony a pak spust divider. Mel by si polygony doinstalovat a otagovat spravne.
Rozhraní Geogetu je u mě v pořádku. Windows mám v anglické mutaci, regionální nastavení české a výchozí českou QWERTY klávesnici. CpTest nicméně nevychází dobře:
11188
Nastavení Win:
11189
11190
Na zmíněném linku postupuju podle sekce "Windows 8" (Win 10 tam není):
- jazykový balíček neřeším (link stejně není platný)
- formát data a času jsem v Geogetu nenašel - můžu poprosit o nasměrování?
- názvy souborů jsou v pořádku:
11191
Nedává mi smysl, proč by tagy byly poškozené jen u některých keší? (menšiny) A to chování je deterministické, vždy to poškodí tagy stejným způsobem u stejných keší.
Další akce bych zkusil, ale nevím, jak vyhodnotit podmínku "pokud by to fakt byl jen divider" - jak to poznat? Odinstalováním myslíš smazání obsahu složek ...\GeoGet\data\polygon\CZ okres\, resp. CZ kraj?
Default application language máš na angličtině. Soubory jsou v pořádku, ale ty názvu se berou z vnitřku souboru s polygonem a je kódovaný v ANSI. Proto se ti to zblbne.
Ergo, problém nejsou desítky, ale ta výchozí angličtina. Budu to muset i uvnitř polygonu překopat na unicode, a bude klid.
Který soubor myslíš? Protože když si otevřu např. Beroun.txt, tak mi editor říká, že vnitřek je v UTF-8. Říkal jsem si, že si to překonvertuju sám. :) Ale asi jde o něco jiného.
Jinak pokud uvolníš upravenou verzi, rád to předem otestuju a dám vědět, jestli je situace už OK.
EDIT: pro info - přehodil jsem default app language na češtinu, pro jistotu i restartoval stroj, nicméně Divider se chová stejně. I CpTest.exe má stejný výstup.
Taky je možné,vze jsem to už dávno udělal a problém je úplně jinde. Nejsem teď u počítače,cabych to mohl ověřit.
Každopádně dle cptestu nemáš správně nastavenou kódovou stránku pro non-unicode programy. Geogetu samotnému by to vadit už nemělo, ale někde něco hapruje. V každém případě, jakýkoliv neunicode program bude mít u tebe problém.
Která položka to je? Výstup CpTestu je značně spartánský.
Tuší někdo, kde se kódování pro non-unicode programy ve Win 10 nastavuje? S tímto systémem se seznamuju a nemůžu to tam najít. Ve Win 7 to bylo. Předpokládám, že tam má být CP-1250 (co jiného v našem prostředí).
EDIT: jak se zdá, tak toto se ve Win 10 nastavit nedá.
Nicméně... stejně mi přijde, že problém v Divideru je někde jinde, jak říkáš. Protože poškodí jen některé tagy a vždy u těch samých keší.
Jo, to je ono! Já to v tom bord... ehm, v té nepřehledné houštině nastavení nemohl najít. :rolleyes:
A víte co? Ono to pomohlo. Nastavil jsem to na Czech, pak si to vyžádalo restart a divider už tagy u keší nemrví a i výstup ze Statoru má správně češtinu. :) A přitom taková blbost. ;) Díky HaLuMovi i tobě za nasměrování!
CpTest už je taky OK:
PS: nejpodivnější v desítkách jsou ty dvojí ovládací panely - nad starými vystavěli nové, ze kterých se do starých mnohdy je nutné kvůli některým nastavením přesunout (jako výše)
Což znamená, že ty slovenské polygony ty názvy v UTF-8 nemají. Konkrétně ty, které ti blbly.
Slovenské okresy jsem na změny nekontroloval. Ostatně mám na Slovensku odlovených jen pár keší. Té poškozené diakritiky jsem si všiml jen u českých okresů (viz screenshot ze Statoru v prvním příspěvku)
btw před pár týdny jsem aktualizoval kamaráda na desítky, a překvapilo mě, že nemá referenční body s diakritikou. I jal jsem se je přejmenovat přímo v geohome.ini - rychlejší - ale gg je pořád nějak nechtěl. Když jsem je zeditoval přímo v GG, tak byla diakritika v geogome.ini ne nepodobná čínštině. celý problém byl v tom, že byl soubor uložen v nějakém jiném kódování. smazal jsem ho, nechal gg ať si ho vytvoří, nakopíroval původní obsah souboru s diakritikou a už to šlapalo.
nevím co tam bylo za kódování předtím a co je tam teď, ale asi to může souviset s přechodem gg na unicode před pár lety? že se ten soubor nepřemrmlal na správné kodování.
Nikdy jsem takovéto problémy nepozoroval, a to si s polygony a diakritikou dost hraju. Asi proto, že jsem nikdy nechtěl na počítači hybridní anglicko - české Windows.
Mimochodem, namátkou jsem se díval na české polygony - a nic v Unicode tam nenašel. A pokud vím, tak HaLuMa Unicode v polygonech nepodporuje, proto nemůžeme mít v názvu kraje / okresu některé francouzské písmena a také nemůžeme mít polygony například v cyrilici (azbuce).
Který soubor myslíš? Protože když si otevřu např. Beroun.txt, tak mi editor říká, že vnitřek je v UTF-8. Říkal jsem si, že si to překonvertuju sám. :) Ale asi jde o něco jiného.
Který editor ti to řekne ? Když se do toho souboru podívám něčím jednoduchým (například editor v mageru FAR), tak bych na začátku musel vidět takzvané BOM znaky, a ty tam nejsou !
A pokud vím, tak HaLuMa Unicode v polygonech nepodporuje, proto nemůžeme mít v názvu kraje / okresu některé francouzské písmena a také nemůžeme mít polygony například v cyrilici (azbuce).
Koukam konecne na to, a pravdu mas. Obsah souboru se skutecne nacita postaru, tedy skrzeva systemove ANSI kodovani. To pochopitelne neni dobre, protoze kdyz si chudak cizinec nainstaluje ceske polygony, bude jeho ANSI kodovani jine, a ceske znaky se pomrsi.
Zajimavost ale je, ze pokud se nenajde v textu definice polygonu jeho nazev, tak se bere nazev ze jmena souboru. (oseknutim pripony, pochopitelne.) A tam by Unicode mel fungovat uz ted, pokud to tedy mate nainstalovane na disku, ktery Unidoce v nazvech souboru podporuje.
Kazdopadne upravil jsem Geoget tak, aby umel nacitat definice polygionu i v UTF8 kodovani. Autodetekce probiha prave podle pritomnosti BOM na zacatku souboru. Takze kdyz se pak predelaji ty definice polygonu, melo by to vsem fungovat spravne.
