Geoget 2.10.6

Nudíte se doma? Hrajte si s novou verzí Geogetu 2.10.6!

  • odstraněn import LAB GPX, web již tyto soubory neposkytuje
  • opted-out user nepřepisuje při aktualizaci stávající data
  • podpora pro soubory polygonů v UTF-8 (autodetekce dle BOM na začátku souboru)
  • drobné opravy a úpravy

Potvrzuju, že otevření složky s přílohou přímo z okna keše už nezpůsobí, že kačer přijde o neuloženou poznámku. Díky! :)

Díky moc. Vyzkouším večer po práci, až odložím pracovní počítač a posunu se na pohovku s Geogetím počítačem. Že jsem tak smělý, pořešils, prosím, nějak červená kolečka na mapě?

Tak z těch drobností jsem se koukl na názvy států ve filtru - ano, opraveno.

A začal jsem přemýšlet, jak předělat jména polygonů do UTF - a zatím jsem bezradný. Polygony mi kompletně dělá dávkový soubor (.BAT) a v něm nemohou být UTF informace. Momentálně mne napadá jediná možnost - názvy polygonů mít jako jediný řádek v pomocném souboru, který by se do výsledného polygonu vkopírovával. Což je realizovatelné, jenom to nebude přehledné. Upravil jsem polygony Andorry, kde je jedno území se znaky které potřebují UTF (za chvíli to pošlu na server).

V té souvislosti - ať mne HaLuMa opraví, jestli se mýlým - předpokládám, že bude vhodné opravit všechny polygony, které mají non-ASCII název, protože v jiném než česko/slovensko/polském prostředí Windows se asi zblázní.

Tak na to napsat plugin, ktery budto udela to, co ti dela ten bat, jen to udela v UTF nebo vezme vysledne soubory a ty prevede do UTF.

Kolečka na mapě jsem poresil, jen se bojím, že jsem to zapomněl dát do instalacky…

Zkus dát na začátek Batu prikaz:

chcp 65001

Tím by se měl přepnout do UTF-8.

Jinak ano, chce to opravit všechny polygony, minimalbe ty, které mají non-ascii názvy.

Zkus dát na začátek Batu prikaz:

chcp 65001

Tím by se měl přepnout do UTF-8.

Teď si nedovedu představit, čemu by to pomohlo, vzteká se to totiž na BOM (a to i v případě, kdy tu code page změním předem).

Ale není to nepřekonatelný problém, pokud toho není moc tak se UTF sekvence dají vkopírovat do BATu jednorázově - je to sice škaredé, ale vyhoví. 

Anebo - pokud bude BOM na začátku aby se to dalo editovat, tak se to vztekne na první příkaz, ale to je většinou poznámka, takže je to jen o té škaredé hlášce.

Teď zase nerozumím já tobě. Já myslel, ze chceš mít v bát řetězce v utf, abys je mohl zapisovat do výsledného textaku. Na to přece samotný bat nemusí začínat na bom. Pak je to jen o používání vhodného textového editoru. Ale možná fakt jen nechápu šíří problému.

Jinak ano, chce to opravit všechny polygony, minimalbe ty, které mají non-ascii názvy.

Tak, a půjdeme striktně na všechny, anebo dáme výjimky pro přehlásky ? V daném okamžiku by to stačilo, ale obecně by to asi bylo špatně.

Teď zase nerozumím já tobě. Já myslel, ze chceš mít v bát řetězce v utf, abys je mohl zapisovat do výsledného textaku. Na to přece samotný bat nemusí začínat na bom. Pak je to jen o používání vhodného textového editoru. Ale možná fakt jen nechápu šíří problému.

Rozumněls správně, jen neznám editor který by mi tam dal UTF znaky a nedal tam BOM. Ale je pravda, že nemám nastudovanou tu spoustu textových editorů která existuje. Vždycky mi stačil integrovaný editor ve FARu doplněný obyčejným Notepadem.

Ja tyhle specialitky dělám v PSPad.

pripadne i TextPad, NotePad++, tipuji, ze i Lime by to melo zvladat.

A co treba predelat ty BAT do Powershellu, ten by to mel zvladat v UTF snad taky.

Btw. BOM je vyzadovan pouze pro UTF-16, pokud se nepletu. Pro UTF-8 neni povinny a popravde v UTF-8 prinasi vic skody nez uzitku.

Bom u utf8 se standardně používá právě na autodetekci tohoto formátu.

Jinak bom není vyžadován nikde, pokud nepotřebuješ autodetekovat formát a poradí bytu…

Už jsem se kdysi ptal, ale nějak to zapadlo - nešlo by zrychlit načítání listu? Načtení 130000 záznamů trvá 14 minut - a to je fakt hodně dlouho. Nějaké quick&dirty řešení, když použiju SQLite engine pro výběr podle obsahu v jiné tabulce, je to mnohem rychlejší.)

A taky pro každou Kes hledáš waypointy a listingy, vyrábís počítaná pole a hromady dalších operaci, které tam jsou potřeba? Nějaký výkon taky padne na oběť objektových střev, což se už několikrát hodně hodilo zachránilo to mě duševní zdraví. Taky záleží na filtrech, co používáš. Některé potřebuji nemalý strojový čas.

Občas se mi i tam daří nějaká menší optimalizace. Ale že bych teď vytáhl špunt, a ono to běželo dvakrát rychleji, to nemohu sloužit.

Jestli to nebude i hardwarem. Mých 123000 záznamů se zobrazí za necelou minutu. Jen nevím, jaký by mělo vliv např. ubrat sloupce nebo nenačítat waypointy?

On bude mít Taxoft trochu větší databázi, že jo? Takže se všechno nahledava v mnohem větších tabulkách…

Bom u utf8 se standardně používá právě na autodetekci tohoto formátu.

Jinak bom není vyžadován nikde, pokud nepotřebuješ autodetekovat formát a poradí bytu…

ok. holt si to pamatuji z Javy, ze ta to nedavala pokud zdrojak v UTF-8 zacinal BOM. ale jak se divam, tak to uz pred 10 lety fixnuli:) a byl to problem v JDK6. Sakra to uz je doba.