» GeoCacher

GeoCacher

Небольшой кэширующий прокси-сервер, предназначенный для эффективного он-лайн кэширования запросов GoogleEarth. Особенность запросов GE, которая заключается в объединении в одном запросе до 4-х различных файлов в произвольном порядке, не позволяла обычным кэширующим прокси-серверам (к примеру, HandyCache) что-либо отдавать из накопленного кэша. С GeoCacher-ом ситуаци кардинально противоположная: накопленный кэш эффективен на 100% - то что однажды было выкачано и попало в кэш, при повторном запросе будет отдано клиенту GE из кэша, и повторной закачки того же самого файла из интернета не будет.

Домашняя страница

Актуальное описание настроек и функций GC

GeoCacher 1.4.3.10 (от 20.03.2011)
Текущие изменения:
- улучшена функция тестирования битых тайлов изображений: все jpg распаковываются при помощи библиотеки ijl15.dll. Функцию распаковки можно отключить в ini, установив параметр TryDecodeJPEG=0.
- исправлена функция сервера для SAS: теперь нет необходимости принудительно включать режим "Любая версия из кэша" - он используется по-умолчанию для запросов у которых указана версия = 0
- обновлены zmp для SAS.Планеты - проекция карт задана при помощи EPSG кодов. По-умолчанию включено отображение тайлов в проекции Меркатора (в кэше SAS тайлы сохраняются в оригинальной проекции, а вот отображаются в Меркаторе).

GeoCacher - приложение с открытыми исходниками (обращайтесь в личку или на e-mail).

Полезные ссылки:

GoogleEarth.Local - версия GE способная работать с GeoCacher-ом абсолютно без интернета (даже авторизация из кэша!).

Кэш GoogleEarth для всех желающих - прогрузка кэша на заказ.

Обмен кэшем Google Earth

а чем это лучше внутреннего кэша GE?

Тем, что собственный кэш GE не более 2 Гб, а тут можно хоть весь веник забить. Назначение GeoCacher-а - экономия интернет трафика. Есть ещё люди, которым приходится следить за расходом трафика... а перекачивать уже однажды скачанное - вообще непозволительная роскошь.

Цитата:

собственный кэш GE не более 2 Гб, а тут можно хоть весь веник забить

ничего не понимаю. так вы же сами и описали метод как обойти это ограничение.

зачем городить прокси сервер, который будет кэшировать гигабайты тайлов, что неизбежно приведёт к большой фрагментации жесткого диска?

Ну, это как бы разные вещи: он-лайн кэширование и просмотр кэша. Тем более, что планируется в GeoCacher встроить функцию генерации KML файлов - налету, без необходимости предварительного создания KML-кэша, что гораздо удобнее и не потребует временных затрат от пользователя. Кэш будет в единственном числе, тот что у
GeoCacher-а, и CacheMaster научится распаковывать GE кэш в нужный GeoCacher-у формат.
В KML кэш попадают же только картинки, а у GE кроме картинок есть ещё множество файлов которые необходимо кэшировать: ральеф, границы, названия, 3D модели и т.д.

На счёт фрагментации - подумываю добавить SQLite в качестве базы для хранения тайлов в кэше GeoCacher-а.

А вообще, логика простая: пусть лучше у меня на венике лежат без дела гигабайты мелких файлов, чем я буду одни и те же данные перекачивать из инета по сто раз. Веник у меня большой, а вот инет - дорогой.

Цитата:

Кэш будет в единственном числе, тот что у
GeoCacher-а, и CacheMaster научится распаковывать GE кэш в нужный GeoCacher-у формат

Блин.. Хорошо бы )

Да, в скорости сделаю. Но уже и сейчас можно использовать распакованный GE кэш, главное правильно написать правила в RegExpr.ini. И не забыть, что в кэше GeoCacher-а файлы лежат в том виде, в каком пришли из инета - зашифрованные, т.е при распаковке файлов из кэша GE не указывать - Расшифровывать.

Если что непонятно по регулярным выражениям/правилам, спрашивайте, помогу.

Цитата:

правильно написать правила в RegExpr.ini.

дефолтовые не подойдут? От GC?
И кст, где они прописываются в распаковщике?
зы. есть ли возможность сохранять в "туда же" *.kmz?

В распаковщике почти вся сортировка жёстко вбита и не подлежит редактированию со стороны пользователя, поэтому только в новой версии можно будет что-то решительно изменить. Сейчас можно только подстроить сортировку GC под CM: адаптированный RegExpr.ini. Путь по-умолчанию C:\temp\CM_GE_4.xx\ При распаковке кэша GE никакой сортировки не указывать, на всякий случай: конфиг от CM. Если будете распаковывать кэш GE 5.0 то имена папок Sky и Mars нужно прописывать вручную (определяются не правильно). Тип данных History распакованный из кэша GE пока что использовать не получится.


Добавлено:

Цитата:

зы. есть ли возможность сохранять в "туда же" *.kmz?

Какие именно kmz имеются в виду

Ну например вот такого типа:
http://mw2.google.com/mw-earth-vectordb/places/2009_01_14/ru/0201.kmz

В принципе не сильно востребованно.. - структура и вес на скрине

Да, закэшировать можно всё что угодно, только что не стояла пока такая задача. Всё что каким-то боком относится к GE, я думаю, со временем будет закэшировано (и этот url тоже). Лично я, использую связку HandyCache + GeoCacher, причём GC стоит после HC как условный прокси на 2 url: kh.google.com и khmdb.google.com и соответственно их кэширует, а всё остальное кэширует HC (GE трафик ему не по-зубам, но со всем остальмым он справляется отлично).

А в случае обновления на гугле кешер поймёт что надо качать новое или будет старьё подсовывать?

Imperator
я так понял, что будет подсовывать старьё. так как он для того и разрабатывался чтобы избежать потерь трафика из-за частых обновлений гугля

Цитата:

я так понял, что будет подсовывать старьё. так как он для того и разрабатывался чтобы избежать потерь трафика из-за частых обновлений гугля

Нет!!! Никакой самодеятельности. Что гугл просит, то и отдаём (если есть в кэше, если нет - качаем). Если есть, но старой версии - всё равно качаем. При отдаче из кэше не идёт никакого анализа на предмет старый это снимок или нет, поиск выполняется чисто по ИМЕНИ файла, если имя запрашиваемого файла точно совпадает с именем файла в кэше, то он отдаётся. А имена, как известно, для разных версий, при обновлении на гугле - различны, даже для одной и той же территории (если она обновилась).

GC разработан, чтоб не качать одно и то же по сто раз при переполнении/потере собственного кэша GE, а при обновлениях данные уже другие, и это уже не одно и то же

zedxxx
А как его заставить работать не прописывая прокси в настройках всей системы? Чтобы только гугль ходил, а не вся винда.

Поскольку GE берёт настройки прокси с IE, и не имеет своих - то никак. Не знаю, умышленно это сделано или нет, но что есть, то есть.
Обычно, в инет я выхожу из Оперы - а там свои настройки прокси, т.е. можно идти мимо прокси, а в IE настройки вбиты чисто для гугла.

zedxxx
Есть ещё куча программ, которые берут настройки из IE.

Согласен.
Если вы знаете какой-то выход - предложите...

2 zedxxx
Может проблему можно решить так:
- научить работать прокси непосредственно с файлами dbCache.dat, в идеале - с несколькими. У меня, например папки кешей GE лежат более-менее упорядоченно по городам-странам и регионам. Логично подключать (переименованные?) файлы dbCache.dat к GC по мере их поступления (или необходимости: сегодня карта москвы, завтра Краснодара)
- научить GC эмулировать сервер Googla в офф-лайне (может быть с заменой версий на лету), несуществующие в кеше файлы заменять на какие-нибудь болванки, типа все 0 или 1
- для полного счастья, научить GC интеллектуально распаковывать инфу из нескольких dbCache.dat (с фильтрами по совпадению тайлов, принудительной заменой версий и т.п.)
- и уже вовсе инфернально - склеивать из нескольких dbCache.dat один с возможностью редактирования (удалением повторов , фильтрами всякими)
Это обеспечит решение проблемы с дефрагментацией диска (более двух гигов распакованного контента на флешке уже не перетащить без геморроя). Да и зачем она вообще, если можно тот же GC научить работать с SasPlanet? Ну это видимо фантастика

PS: Версия GC от 19.02.09 мне показалась несколько перемудреной в смысле поведения при открытии-сворачивании окна. И всплывающее сообщение из трея о находке новой версии баз GE у меня не закрывается ничем

Добавлено:

Цитата:

А имена, как известно, для разных версий, при обновлении на гугле - различны, даже для одной и той же территории (если она обновилась).

Как же тогда клиент GE об этом узнает? Откуда он знает по каким именам формировать запрос ? Или там какая-нить хитропопость с генерацией имени от номера версии - тогда это можно использовать для переименования ранее скачанных файло. Думается, что файлы рельефа можно смело не менять (чаще раза в год хотя-бы;))

Цитата:

- научить работать прокси непосредственно с файлами dbCache.dat, в идеале - с несколькими

Именно этим на данный момент и занят Теперь у GC будет индексный файл, в который будет занесена инфа о тайлах, что храняться в dbCache.dat (количество кэшей, их расположение и имена, не ограничено!). Одновременно с этим, у GC появится возможность хранить свой кэш в одном/нескольких больших файлах - что позволит решить проблему тысячи мелких файлов. Индекс и свой кэш будут в SQLite.


Цитата:

- научить GC эмулировать сервер Googla в офф-лайне (может быть с заменой версий на лету), несуществующие в кеше файлы заменять на какие-нибудь болванки, типа все 0 или 1

Полная эмуляция пока что не представляется возможной (и наврят ли когда-то появится), если, конечно кто-то мне не объяснит как генерировать правильный ответ на запрос авторизации клиента GE (geauth). А пока, вполне возможно сделать режим: только кэш - для тайлов, но для авторизации нужен инет, а она происходит каждые ~10 мин.


Цитата:

- для полного счастья, научить GC интеллектуально распаковывать инфу из нескольких dbCache.dat (с фильтрами по совпадению тайлов, принудительной заменой версий и т.п.)
- и уже вовсе инфернально - склеивать из нескольких dbCache.dat один с возможностью редактирования (удалением повторов , фильтрами всякими)

Распаковка/склейка - это задачи CacheMaster-a. На всё, к сожалению, не хватает рук, и пока занимаюсь GC, CacheMaster курит в сторонке...


Цитата:

Или там какая-нить хитропопость с генерацией имени от номера версии

Какой именно выдавать запрос в инет, GE узнаёт из индексных файлов (q2-0123-q.xxx), причём, у самих индексных файлов xxx - текущая версия баз, которая, в свою очередь, берётся из файла dbRoot.v5, вот такая хитропопость

А насчёт: отдавать из кэша старое, вместо закачки новой версии, то такая возможность со временем появится. Пользователь сможет указать: регион, зум, тип файлов - и GC будет выдавать старые тайлы (если они есть), а если их нет, то на выбор - закачивать или нет.

Если у GC будет свой индексный файл, значит, как я понимаю, подразумевается процесс монтирования/размонтирования файлов dbCache.dat (внесение изменений в индекс GC). А нельзя ли использовать собственные индексы GE (dbCache.dat.index)?
Как пример - моя организация кэшей GE:
путь к кешу GE - C:\GoogleEarth
на анлимите (спасибо службе) ждем смену версий и за несколько дней в автомате и в рукопашную сливаем в кеш GE определенный регион (путь), страясь делать это более-менее упорядоченно, практикую в каждом кеше бланковый "облет" глобуса на 8-9 слое (метров 300 уходит).
- перемещаем папку GoogleEarth на другой (физический) диск и переименовываем её по смыслу выходит примерно так - H:\_GE_Cash\GoogleEarth_Dominicana_182, где _182 номер версии
- в каждой такой папке лежит одноименный файл !GoogleEarth_Dominicana.reg, который прописывает в реестре путь к кэшу GE именно сюда (чтоб в ручную не лазить)
- в каждой такой папке лежит сопутствующая региону инфа (KML-файлы, фотографии, ссылки на ресурсы в сети)
- таковых папок удобно делать, распределяя между друзьями с анлимитом определенные неповторяющиеся регионы
Я к тому, что при разработке GC если предусмотреть работу прямо целиком с папками GoogleEarth, используя насколько возможно, их индексные файлы это может облегчить сервисные телодвижения по перегруппировке набора кешей. Актуально это прежде всего для сетей, когда один или несколько кешей могут иметь "мерцающий" доступ.

Про текущий GC. Окошко с сообщением о найденной новой версии не закрывается под W2000 под XP все нормально. Еще непонятка. Не меняется путь к каталогу с тайлами. В config.ini прописываю путь, но он слетает на умолчание C:\TEMP

Цитата:

В config.ini прописываю путь, но он слетает на умолчание C:\TEMP

Путь определяется не из config.ini а из правил в RegExpr.ini. А в config.ini - резервный путь, куда будут ложится тайлы не попавшие под сортировку в RegExpr.ini.


Цитата:

А нельзя ли использовать собственные индексы GE (dbCache.dat.index)?

Можно, но быстродействие сильно уменьшится, поэтому и будет свой единый индекс в котором будет инфа о 3-х типах кэша сразу: тайловом, GE, и собственном файловом кэше.

Добавление GE кэша в индекс идёт со скоростью ~ 1 Гб в минуту, данная операция единоразовая для данного кэша. В индексе будет записан полный путь к конкретному кэшу GE и контрольная сумма этого кэша. При первом обращении за тайлом к этому кэшу будет выполняться проверка его доступности и корректности (проверка CRC), если кэш недоступен или в нём произошли изменения - он переходит в разряд недоступных до следующего сеанса. А при следующем сеансе будет проведена аналогичная проверка. Поэтому, проблем с "мерцающими" кэшами быть не должно, единственное, чтоб GC смог увидеть кэш GE по сети - но тут уж постораемся.

Это на данный момент мне так видится, может быть позже, окажется лучшим хранить распределённый индекс - по кусочку возле каждого кэша, а в начале сеанса уже из доступных кусочков формировать в памяти единый индекс - благо, что это секундное дело. Поживём - увидим.

P.S. Кстати, если вы периодически подключаете к GE старые кэши - их контрольная сумма каждый раз будет изменяться. В GC будет опция - игнорировать CRC - но это на свой страх и риск. По личным наблюдениям ничего страшного быть не должно, т.к. изменяется либо только заголовок кэша, либо дописываются новые данные в конец файла (если вы вдруг вышли в инет с этим кэшем), так что по-идее всё должно быть в порядке.

Однако, много мелких заподлючек разработчике ge понавтыкали ;( И опять сменили версию баз на 192, забодав. Просто катастрофически навязчивый сервис, опять качать глобус по-новой. Ведь это еще и время.
Мысль вот какая. А не халтурят-ли на Google отдавая старые тайлы под новыми именами? И, если да, то возможно ли на лету сравнивать тайлы из кеша GC, скажем по размеру или CRC (гдеб, её взять) и при совпадении все-равно отдавать из кеша прежние, переименовывая в запрашиваемое имя. Короче, чтоб у GC был режим принудительного подсовывания данных из набора кешей (для тех, кто на GPRS). Чтоб только за авторизацией ходить на Googl. Чтоб кнопка была "обновлять данные" пока нажата - работает как сейчас - качая новую версию с инет и складывает в кеш. Отпущена - принудительно подсовавает старье (с фильтром из каких версий предпочтительно). Пользователь рискует лишь тем, что создаст разношерстный кеш в GE, о чем его можно предупредить
И ещё вопрос. То-ли совпало, но как установил GC перестал грузиться слой Panoramio & Wikipedia. Ну не отображаются эти элементы хоть убей. Всё, кроме винды переустанавливал.

QQMATS
по размеру думаю можно, а вот по CRC - врядли

Цитата:

А не халтурят-ли на Google отдавая старые тайлы под новыми именами?

Ага, лично я считаю, что с первого до ~ 10-го уровня данные вообще не нужно обновлять... континенты-то у нас ещё не так быстро меняют очертания, как гугл новые версии штампует


Цитата:

возможно ли на лету сравнивать тайлы из кеша GC, скажем по размеру или CRC (гдеб, её взять)

Вот именно, где CRC-то взять, не загрузив предварительно файл? По размеру же, вполне можно попробовать, по-моему должно работать в 99%, если предварительно ввести фильтрацию по имени, зуму и т.д. Но чем больше будет кэш и чем больше будет снимков разной версии для одной и той же территории - тем больше будет "левых" совпадений.


Цитата:

Чтоб только за авторизацией ходить на Googl. Чтоб кнопка была "обновлять данные" пока нажата - работает как сейчас - качая новую версию с инет и складывает в кеш. Отпущена - принудительно подсовавает старье (с фильтром из каких версий предпочтительно).

Да, что-то вроде этого, в планах имеется


Цитата:

То-ли совпало, но как установил GC перестал грузиться слой Panoramio & Wikipedia

У меня Panoramio грузит нормально, а вот вики - действительно нет (это если использовать прямую связку GE - GC). Это предсказуемо, т.к. GC до нормального прокси ещё далеко... всё внимание пока что сосредоточено на 2-х url: kh.google.com и khmdb.google.com, а с остальным - как карта ляжет. Для надёги (и для кэширования снимков панорамио и проч.) рекомендую связку GE - HandyCache - GC. Да, неудобно - лишний прокси, но - хоть какой, но выход.

З.Ы. Возьму в команду опытного программиста, что исправит мой "огород" и поможет в развитии проекта. А в одиночку, без достаточного опыта и знаний - очень марудны процесс.

Тестовая версия GC с поддержкой чтения кэша GE налету: http://narod.ru/disk/6343143000/GeoCacher_20090305.rar.html
У GC появилась вкладка Кэш, где можно добавить папку с кэшем GE (которая может содержать подпапки).

Тест GC от 05.03.09

1. Импортируем кеш GE 157 версии: найдено более 196 тыс. тайлов (размер DAT-файла 1.2 ГБ, куча версий т.к. создавался при помощи HandyCach, сборная солянка)
проиндексировалось все быстро.
2. Импорт кеша 187 версии размер 2.1 ГБ. Найдено 21 тайлов в самом начале сканирования, остальное почему-то не увидел.
3. Импорт кеша 187 версии (ранее сохраненная копия предыдущего)
Сообщение: /Проиндексировано 1 файла(ов) GE кэша.
Всего найдено: 413225 тайлов. Размер добавленного GE кэша: 1864,1 Мб
///Случайно нажата клавиша "Добавить" тот же кеш проиндексирован повторно с тем же результатом. Вопрос, что происходит при повторном индексировании?
4. Сообщения после добавления следующих кешей:
Information
---------------------------
Кэш GE успешно проиндексирован и добавлен в базу доступных источников кэша.
Проиндексировано 1 файла(ов) GE кэша.
Всего найдено: 7406 тайлов. Размер добавленного GE кэша: 400,03 Мб
---------------------------
OK
---------------------------
---------------------------
Information
---------------------------
Кэш GE успешно проиндексирован и добавлен в базу доступных источников кэша.
Проиндексировано 1 файла(ов) GE кэша.
Всего найдено: 44838 тайлов. Размер добавленного GE кэша: 2000,03 Мб
---------------------------
OK
---------------------------
---------------------------
Information
---------------------------
Кэш GE успешно проиндексирован и добавлен в базу доступных источников кэша.
Проиндексировано 1 файла(ов) GE кэша.
Всего найдено: 84381 тайлов. Размер добавленного GE кэша: 327,93 Мб
---------------------------
OK
---------------------------
---------------------------
Information
---------------------------
Кэш GE успешно проиндексирован и добавлен в базу доступных источников кэша.
Проиндексировано 1 файла(ов) GE кэша.
Всего найдено: 26719 тайлов. Размер добавленного GE кэша: 171,64 Мб
---------------------------
OK
---------------------------
---------------------------
Information
---------------------------
Кэш GE успешно проиндексирован и добавлен в базу доступных источников кэша.
Проиндексировано 1 файла(ов) GE кэша.
Всего найдено: 39314 тайлов. Размер добавленного GE кэша: 229,14 Мб
---------------------------
OK
---------------------------
---------------------------
Information
---------------------------
Кэш GE успешно проиндексирован и добавлен в базу доступных источников кэша.
Проиндексировано 1 файла(ов) GE кэша.
Всего найдено: 72639 тайлов. Размер добавленного GE кэша: 362,31 Мб
---------------------------
OK
---------------------------

Вызывает настороженность несоответствие размера и количества найденных тайлов.

Вылетает окно следующего содержания:
The Delphi Inspiration
---------------------------
This application uses an unregistered demo version of DIFileFinder. Unregistered versions are intended for evaluation purposes only. Their use in distributed applications is strictly prohibited. For product and registration information please visit our Internet site: http://www.yunqa.de
---------------------------
ОК
С чего бы это??

Едем дальше. Запускаем Гугль версия Про 4.2 с Вашего сайта.
Порт в GC пришлось сменить с 8081 на 3127. Гугль запустился с третьего тыка. Кеш GE практически обнулен (около 5МБ) Полез по старым, гарантированно (и неоднократно) скачанных местах.
Ощущение прорыва уже есть;) Просто пестня, когда лезем туда, где скачивалась (на другом ПК) свежая версия.
(193). Счет: инет/кеш 20/5
Однако, когда дошел до местности, скачанной раньше траффик побежал быстрее. Похоже это те места, которые были в "криво" проиндексированных файлах.
Пока все в кайф, рождаются мысли по упорядочению кешей, что может стать моим скромным вкладом в дело портабилизации GE.
Установил GE-5.0 - кеш у него с нуля. После снова лезу по тем же местам. 95% траффика идет из кеша. В тех местах, где ранее дал гуглю спокойно догрузиться - все 100. Похоже проблема близка к решению
В резюме:
1. Почему не все кеши полностью обрабатываются.
2. Непонятно как "отключить" проиндексированный кеш. И что будет если его удалить/переместить
3. Непонятно, что происходит при многократном индексировании одного и того же кеша (по ошибке в моем случае)
4. Куда теперь GC девает то, что накачал, помимо прикрученных кешей.
5. GC как прокси мне показался несколько капризным (в сравнении с HC)
6. Хотелось бы маkенький ненавязчивый полупрозрачный мониторчик поверх окна GE.
7. Мануальчик небольшой, по путям и настройкам
8. И еще. Настройки может лучше вообще убрать в ини-файлы. Задолбался настраивать прокси через вкладки

Добавлено:
Попытка отключить инет на работающем GE-5.0.
Куча запросов типа
http://mw2.google.com/mw-earth-vectordb/places/2009_01_14/ru/02013310.kmz
Может их тоже надо кешировать? А то GE без них, похоже картинки не запрашивает.

Все кэши можно добавлять разово (если хранятся в одной общей папке), но для теста, конечно, было сделано правильно - т.к. можно увидеть статистику по каждому из добавленных кэшей. У себя я добавлял 14 кэшей за раз общим размером 4 Гига - нашлось ~320 тыс. тайлов.

Цитата:

Проиндексировано 1 файла(ов) GE кэша.
Всего найдено: 44838 тайлов. Размер добавленного GE кэша: 2000,03 Мб

Тут 2 Гига или всё же 200 Мб? Если 200 Мб, то всё ОК, а если же 2 Гига - то где-то была ошибка - уж слишком мало найдено тайлов.

Примерное количество тайлов в кэше GE можно определить, разделив размер файла dbCache.dat.index (в байтах) на 32. Примерное - потому, что GE некоторые дублирующиеся/устаревшие данные может в индекс не заносить. Если полученное число сильно отличается от того, что нашёл GC - была ошибка.

Цитата:

Вылетает окно следующего содержания:
The Delphi Inspiration

Это случайность - слетела регистрация на компонент, подправил.

Цитата:

1. Почему не все кеши полностью обрабатываются.

Ошибки в GC.

Цитата:

2. Непонятно как "отключить" проиндексированный кеш. И что будет если его удалить/переместить

Ничего отключать не надо. Удаляйте/перемещайте наздоровье - всё будет грузится из инета.

Цитата:

3. Непонятно, что происходит при многократном индексировании одного и того же кеша (по ошибке в моем случае)

В индекс будут занесены те же данные ещё раз. Но это ни на что, кроме размера индекска, не повлияет (кстати, какой размер индекса в итоге получился?). Ну, это пока что, а в последствии, конечно, идентичные данные (даже из разных кэшей) попадать в индекс не будут.

Цитата:

4. Куда теперь GC девает то, что накачал, помимо прикрученных кешей.

Туда же, куда и раньше, через тот же RegExpr.ini. С собственным кэшем ничего не менял.

Цитата:

6. Хотелось бы маkенький ненавязчивый полупрозрачный мониторчик поверх окна GE.

Не получится - начинаются мерцания мониторчика. Попробуйте сделать главное окно полупрозрачным и запустите его поверх гугла - увидете. И так будет с любым полупрозрачным окном (окно гугла в 3D режиме обрабатывется видеокартой)

Цитата:

8. И еще. Настройки может лучше вообще убрать в ини-файлы. Задолбался настраивать прокси через вкладки

Так уже! Все настройки по ходу написания проги я вначале выношу в config.ini, а уже потом, по мере возможности появляются и закладки с чекбоксами и проч. Ищите внимательно - там всё есть: и порты и прокси.

Цитата:

Куча запросов типа
http://mw2.google.com/mw-earth-vectordb/places/2009_01_14/ru/02013310.kmz
Может их тоже надо кешировать? А то GE без них, похоже картинки не запрашивает.

Это какие-то внешние накладываемые слои (типа меток или панорамио, тот же обзор улиц) к снимкам поверхности Земли не относятся, в кэш GE эти данные не заносятся, и закэшировать их средствами обычных прокси (того же HC) никаких проблем не вызывает.

Цитата:

Все кэши можно добавлять разово (если хранятся в одной общей папке), но для теста, конечно, было сделано правильно - т.к. можно увидеть статистику по каждому из добавленных кэшей. У себя я добавлял 14 кэшей за раз общим размером 4 Гига - нашлось ~320 тыс. тайлов.

Маловато будет! У меня с одного кеша №3 1.8гб нашлось больше 400тыс. тайлов. Явно пропускает тайлы алгоритм обработки. Причем, судя по тому, что один из моих кешей "заклинило" в самом начале (21 тайл), можно предположить некий сбой сканирования, после которого далее индексация не идет, хотя процесс сканирования продолжается, счетчик процентов бежит, только число найденных тайлов не растет ;(
размер GCindex.db3 после перечисленных (с повторным) сканирований составил 89Мб.
По поводу кеширования kmZ-файлов мне кажется, стоит подумать, чтоб обходиться без дополнительных проксей. Как я понимаю, кеширование этих (и любых) файлов можно организовать внеся соответсвтующие изменения в D:RegExpr.ini. А вот брать их GC как будет?
PS На форуме проскакивала мысль, что GE-5/0 будет генерить запросы в офф-лайне. Не заметил. Ведет себя аналогично 4-м версиям.

Новая версия GC: http://narod.ru/disk/6533915000/GeoCacher_RC1.rar.html:
- исправлена ошибка неполного индексирования GE кэша;
- в индексный файл теперь не попадают одинаковые тайлы (для каждого тайла расчитывается его контрольная сумма CRC, что несколько замедляет процесс индексации)
- все не-GE url-ы кэшируются и для них работают правила из RegExpr.ini