GeoCacher

[zed]

Niki
Не путайте TileStorage_GC.dll.ini и TileStorage_GC.dll. Причём, ini нужен только если вы хотите чего-то особенного в плане настройки dll, но с настройками по-умолчанию всё работает и без него.

Не могу понять, откуда у вас проблемы, если есть пошаговая инструкция с картинками (!) как и что подключать. Единственное, что dll можно взять из этого тикета (заодно и высоту в статусной строке опробуете).

Всё ж работает из коробки!

[zed]

решил GeoCacher.exe т.к. автор объявил что на лету проекция меняется. но.. все встало. все перелистал и иинструкцию для новичков и тут.

Проекция на лету менялась в версии 1.3.xx. В 1.4.xx такого функционала нет и не планируется.

Из чейнджлога:

30.11.2010 - GeoCacher 1.4.3.4

исправлены ошибки
добавлена функция сервера (в комплекте идут zmp для SAS.Планета). Снимки отдаются только в оригинальной проекции.

21.06.2010 - GeoCacher 1.4.2.47

небольшая коррекция обработки dbRoot.v5 для нормальной работы с GE 5.1.LOCAL.

26.04.2010 - GeoCacher 1.4.2

добавлен GUI, включающий в себя монитор и настройки кэшера (добавил vvip);
убран пункт меню в трее Авторизация GE.LOCAL, за ненадобностью.

19.04.2010 - GeoCacher 1.4.2

исправлены ошибки
добавлена функция "Любая версия" (добавил vvip)
переработан трей (при участии vvip)
полная поддержка склеенных запросов для GE.LOCAL всех версий

14.10.2009 - GeoCacher 1.4

основной код программы почти полностью переписан с нуля, при этом часть функционала потерялась.

Что сделано:

тайловый кэш с сортировкой по 1024 тайла;
kml кэш;
чистка дбрут на предмет копирайтов и склеенных запросов;
умное сохранение дбрут (с автоматической распаковкой в xml);
поддержка GE.local (4.2 без склеенных запросов).

Чего нет:

монитора, статус строки;
поддержки файлового и GE кэша;
индекса.

21.05.2009 - GeoCacher 1.3.2 - финал линейки 1.3

исправлены ошибки

[Niki]

Проекция на лету менялась в версии 1.3.xx. В 1.4.xx такого функционала нет и не планируется.

07/08/2012 10:02 AM
zed
GE он их "на лету" растягивает (изменяет проекцию на Меркатора). Потому и качество картинки различное.
http://starmen.at.tut.by/sasplanet_ge_howto.htm

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


и распишите пжлт куда прописывать кеш созданный программой CacheMaster для GeoCacher, там уж точно ногу сломишь

[zed]

Вы откуда выдрали эту цитату? Дайте линк. И я не вижу в цитате упоминания, что проекцию изменяет GeoCacher.

и распишите пжлт куда прописывать кеш созданный программой CacheMaster для GeoCacher

Старанный вопрос, раз вы рапаковали GE кэш для GeoCacher-а, ну так и положите его туда, где остальной кэш лежит. GeoCacher-то установлен? Папочку cache у него видели? Вот там его кэш.

[zed]

Вы откуда выдрали эту цитату? Дайте линк. И я не вижу в цитате упоминания, что проекцию изменяет GeoCacher.

А вот, нашёл:

И с GM САС показывает тайлы "как есть", а с GE он их "на лету" растягивает (изменяет проекцию на Меркатора). Потому и качество картинки различное.

И что тут не понятно? САС на лету растягивает тайлы и выводит их на экран, при этом в кэше тайлы лежат в оригинальном виде.

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

[Niki]

В общем, у меня закончились приличные слова /.... Вдруг не судьба?

видимо так и есть, брошу затею с GeoCacher ))) а за CacheMaster огромное спс!

[vasketsov]

Надеюсь темой не ошибся...
Перетаскивание кэша саса в СУБД оказалось вполне пользительно для NTFS-а, однако остаётся кэш GC, в который мы умеем ходить и забирать оттуда тайлы через DLL.
И кэша GC у меня примерно на 100 гигов, судя по разнице между общим размером диска, остальным кэшем и свободным местом (измерять именно размер кэша GC я даже не рискую))), причём это я ещё слил без энтузиазма, только то что заведомо пригодится )).

Первая идея "лечения" в общем-то на поверхности: запихнуть кэш GC в новый тип кэша над SQLite (о необходимости которого давно ...), а потом соответственно выкинуть DLL для GC как ненужную, чтобы сас ходил в кэш GC напрямую (в любом случае я буду делать версионный кэша над SQLite, так что даты aka версии отлично туда лягут). Однако придётся пописать GC в плане нового кэша + сделать итератор для миграции кэша (правда итератор обещает быть несложным). Ну и в реальности будет ограничение, что для нормальной работы SQLite желательно, чтобы всё было локально. Кстати, возможно в SQLite получится кэш плотно утоптать, там размер страницы можно менять в существующей базе почти на лету (только вакуум прогнать), так что заводя новую БД для каждой версии, старые версии можно топтать размером страницы 512 и радоваться жизни и освободившемуся месту.

Вторая идея "лечения" связана с новой версией GE (вроде там уже БД какая-то?), может в неё сразу ходить (собственно как делает DLL для GE), и проблем не будет?
зы. (оно как бы не отменяет кэш над SQLite, но хотя бы в плане "лечения" этой темы - немного "полегчает")

Движение в каком направлении может быть призвано потенциально небессмысленным? Ещё может какие мысли есть?

[zed]

Движение в каком направлении может быть призвано потенциально небессмысленным?

Да в общем-то все направления не бессмысленны. Делай в первую очередь как тебе это надо (почему-то про СУБД не упомянул?). SQLite не плох и проверен временем, LevelDB достаточно экзотичен - не поддерживает доступ из нескольких приложений, не очень понятно как там с устойчивостью к сбоям, да и несколько проблемно собрать dll под винду из официального источника. Но с другой стороны, рано или поздно с LevelDB в любом случае придётся иметь дело, чтобы обучить SAS читать кэш GE 7. Так что тут полная свобода.

Ещё может какие мысли есть?

О, этого с избытком Вообще, есть дикая мысль заняться велосипедостроением и изобрести своё гибридное хранилище. Цель - уйти от журналирования и лишней нагрузки на HDD (в том числе, уменьшить излишнюю дефрагментацию файлов БД) и при этом не потерять в надёжности хранения тайлов. Идея в том, чтобы разделить данные и их "индексы" на независимые сущности. Т.е. метаинформацию хранить в обычной БД (Беркли/SQLite/СУБД на выбор), а тайлы писать в этакие плоские контейнеры - относительно большие файлы, где-нибудь мегабайт по 100-200. Причём, специфика GeoCacher-а такова, что нам даже не нужно заботиться о возможности удаления тайлов из кэша - в общем случае там такая функция попросту отсутствует. Остаётся реализовать более-менее безопасную последовательную запись данных в эти контейнеры из разных процессов и нормально обрабатывать ситуацию ошибок записи вследствии сбоя в системе.
Тайловый кэш лидирует по быстродействию, надёжности и простоте, вот и хочется изобрести что-то похожее по характеристикам, но лишённое очевидного недостатка в виде тучи мелких тайлов.

Кстати, лично я для себя вычеркнул СУБД из списка БД, в которых можно хранить кэш. Так-то оно конечно удобно для многопользовательского доступа, но этот вариант по-моему самый опасный, с точки зрения потери данных. Бэкапы не сделаешь, и выходит что все яйца лежат в одной корзине.

P.S. И ещё, одно пожелание, если будешь делать кэш в виде какой-то БД, то по возможности предусмотри (опционально) чтобы можно было отказаться от версионности. Ну, в том смысле, чтобы в кэше не хранились старые версии, а только текущие и актуальные на данный момент тайлы. Т.е. чтобы при обновлении, старые тайлы замещались новыми.

[Shoorick]

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

На последовательную запись рассчитан формат tar.
Еще есть zip (как вариант, без компрессии) и др. Плюс в том, что не надо очередной формат придумывать.

[vasketsov]

(почему-то про СУБД не упомянул?)

Ну во-первых, потому что хранилище и DLL для взрослых СУБД уже есть, и если GC в какой-то далёкой версии после перехода на SQLite научится ходить в сасовы хранилища, работа с СУБД получится почти автоматической.
А во-вторых, потому что аудитория GC в том числе просто распаковывает кэш мастером, обойдя один снимок, зачем ей со взрослыми СУБД связываться.

Вообще, есть дикая мысль заняться велосипедостроением и изобрести своё гибридное хранилище

Однозначно самый простой способ - плагин для MySQL (см. в вики - сейчас это третий параграф в первой части). Там даже есть тип таблиц EXAMPLE.
В вообщем и целом opensource и всё такое, и даже книжки про такие плагины есть (и даже на торрентах есть))). Например так написан XtraDB против InnoDB.

Цель - уйти от журналирования и лишней нагрузки на HDD (в том числе, уменьшить излишнюю дефрагментацию файлов БД) и при этом не потерять в надёжности хранения тайлов

Ну и получишь свою реализацию NoSQL, зачем? Собственно СУБД и решает задачу индексирования, кэширования, отката, восстановления после сбоев, параллельного доступа,...
Если очень хочешь такое, и не хочешь возиться с реляционными СУБД (почти полностью окученными в моей DLL, исключая Teradata и совсем уж редких зверюшек типа Linter, Ingres,...) - используй нереляционные (вики про них знает куда больше меня, так что перечислять их не буду, но в статье NoSQL исчерпывающая информация для понимания, и ссылки есть). Там будет просто "ключ-значение", ровно как сейчас в файловой системе или в BDB. Вставил в ключ версию последним полем - получил версионность и халявное перечисление версий для тайла. Не вставил - нет версионности. Если по версиям организовал список значений для ключа - боюсь что всё значение для ключа будет блокироваться целиком, не знаю насколько это допустимо, а может это как раз самое то что нужно.
В общем велосипед не нужен совсем, всё уже украдено придумано до нас. Главное чтобы была транзакционность и было востановление после сбоев.
ps. Здесь под NoSQL я понимаю сам подход к построению БД не на основе SQL, а не обязательно именно NoSQL в отдельных проектах типа MySQL.
pps. Лично мне подход NoSQL чужд, я классический реляционщик, так что может чего и напутал про NoSQL.

Тайловый кэш лидирует по быстродействию, надёжности и простоте

По быстродействию чтения - сравнимо, пока что объёмы относительно небольшие и один пользователь, и только локально, иначе у файлового шансов нет (в том числе проверка полномочий пользователя при каждом открытии каждого файла тоже не совсем бесплатная). По записи - простой тест с копированием кэша в файловый и в СУБД даёт разницу во времени заливки более чем на порядок (а при запуске "ФС в ФС" после "СУБД в СУБД" - так просто начинает нервировать). По построению карты заполнения и прочим возможным операциям, там где работают индексы - файловый кэш просто бьётся в паркинсоне после продолжительного курения в сторонке. Причины понятны: продуманный кэш в памяти, индексы, отсутствие фрагментации, отложенная запись или прямой доступ к диску,...
По надёжности - взрослые СУБД существенно надёжнее, если конечно востановление после сбоев есть (а оно есть не везде, например на некоторых подсистемах MySQL его нет, в BDB судя по всему нет,..). В принципе если кэш в такой СУБД, где есть поддержка транзакций и восстановление после сбоев, делать бэкап кэша необходимо разве что на случай смерти HDD (поскольку кэш сас не mission critical). В остальных ситуациях типа пропадания питания, вылета саса или сервера БД, голубого экрана и т.п. - ничё не похерится.
То есть это я не к тому, что бэкапы не нужны, а к тому, что даже кэш без бэкапов надёжнее файлового кэша. А уж скорость создания бэкапа для СУБД катастрофически выше (bulk), чем обойти все файлики в кэше.

Бэкапы не сделаешь, и выходит что все яйца лежат в одной корзине

Во-первых, приличные СУБД случайно ещё надо умудриться сломать, тогда как файловый кэш ломается просто по достижению 50 млн тайлов ))) а это число, скажем, меньше чем число тайлов только на bing и dg по квадрату P-40 (и при этом скорость работы PostgreSQL совершенно не изменилась, что в начале, что после наполнения данными).
Во-вторых, все приличные СУБД умеют делать бэкапы (некоторые правда быстрее скопировать руками, остановив инстанс, но это другой разговор), настраивать это по расписанию, бэкапировать не всё, инкременально,..особенно в этом преуспел PostgreSQL - так что как раз с файловой системой не сравнится.
В-третьих, бэкапом может быть просто экспорт из саса в архив или другой кэш, откуда в случае факапа данные можно быстро и просто вытащить. Но повторяю, это нужно только для клинически важных данных, без которых сразу жизнь будет не мила. Если раньше не делались бэкапы с файлового кэша и это устраивало, сам по себе перенос кэша в СУБД не может привести к необходимости бэкапирования.
В-четвёртых, даже в случае поломки, формат файлов данных известен (если это конечно открытая БД, или саса БД как oracle допускает хождение по логам, так как чаще всего реальная "поломка" возникает потому что логи не пролазят в БД), так что для ценных данных можно пробовать восстановить данные (если автоматическое восстановление после сбоев не устраивает, и данные ни откуда больше не взять, и бэкапа нет).
В-пятых, точно также на своём велосипеде будешь терять по полснимка, если в случае ошибки будешь весь файл выкидывать, и не будет атоматического восстановления после сбоев.
Файловая система рулит только если HDD совсем уж какой-то ненадёжный, сыпицца и теряе байты или находить новыйе, тогда можно адресно похерить файлик и ещё пождать и поработать с другими, пока те не помрут. Или пока тайлов мало, из-за чего накладные расходы на сервер дОроги. Даже для обмена кэшем, есть возможность сразу экспортировать его в архив.

если будешь делать кэш в виде какой-то БД, то по возможности предусмотри (опционально) чтобы можно было отказаться от версионности

Ну это как раз просто: новый номерок (типа 91 вместо 9), и непролёт v в хранилище ниже ITileStorage. В этом случае даже указание v в свойствах карты не поможет ))
Тем более если версии картосервиса лежат отдельным справочником - резервирование 0 для "без версии" даст возможность переключать режим хоть даже на лету.

На последовательную запись рассчитан формат tar

Мы не умеем дописывать файлы в tar, только в zip.