0001290: Поддержка вторичного read-only кэша (например, в формате SAS4WinCE)

Notes
(0006693) vasketsov (manager) 05-05-2012 10:32	>И я готов написать всё необходимое Объясняю на пальцах: 1. Хранилища наследуются от u_TileStorageAbstract.pas и все в u_TileStorage* (кроме u_TileStorageType* и u_TileStorageInfo*). 2. Примеры хранилищ только для чтения в виде DLL - это хранилища для Google Earth и GeoCacher. Если надо с DLL - интерфейс описан. Если надо без DLL - всё ещё проще. Необходимо сделать хранилище для SAS4WinCE (только для чтения или нет - тут полностью эквипенисуально). Лазалку после первого хранилища во второе нельзя делать в рамках хранилища и нельзя привязывать к настройкам хранилища или привязывать к SAS4WinCE. Это общая логика, при недоступности тайлов в первичном хранилище лезем во второе (и не только для чтения тайлов кстати). Поэтому эта логика должна быть сделана над хранилищами. А кроме того "вторичных" хранилищ может быть произвольно много (пример - родные кэши Google Earth на DVD по участкам на местности).

(0006695) Tolik (manager) 05-05-2012 10:36 edited on: 05-05-2012 10:50	То есть опять-таки задача разбивается на 2: 1. поддержка хранилища SAS4WinCE 2. поддержка вторичного кэша (любого из поддерживаемых типов). Пусть эта хотелка решает п.2, а по п.1 открыл ещё одну: 0001291.

(0006697) Garl (manager) 05-05-2012 10:37	Собственно вопрос: стоит режим интернет+кэш тайла нету в текущем кэше, зато он есть в запакованом, что должна сделать программа? 1 показать тайл из пакованного хранилища 2 не показывать и скачать тайл из интернета 3 показать из пакованного , а затем скачать и показать новый 4... что делать если тайла нету в интернете? что делать с .tne файлами. и ещё куча организационных вопросов...

(0006698) Garl (manager) 05-05-2012 10:39	кстати гдето была хотелка про альтернативный кэш, тоесть если нету в одном - то искать в другом. может тогда будет проще? делаем новый тип кэша в рид-онли и подключаем его как альтернативный...

(0006701) Tolik (manager) 05-05-2012 10:43 edited on: 05-05-2012 10:45	Нашёл нечто похожее: 0000392 Ответ №1. А в режиме Интернет - ответ 3. Или, может быть, 2.

(0006702) vasketsov (manager) 05-05-2012 10:53	Итак если предположить существование типа кэша для SAS4WinCE и подключения его как вторичного только для чтения: >Если стоит режим интернет+кэш, тайла нету в текущем кэше, зато он есть в запакованом Значит тайл есть (решение о наличии принимается по сей совокупности используемых хранилищ исходя из обобщённых координат тайла {x,y,z,v}). Его и показываем. >что делать с .tne файлами Создавать всегда в первичном хранилище. TNE - признак отсутствия тайла в интернете, так что это совершенно не зависит от наличия или отсутствия вторичного хранилища. А чтение TNE из вторичного хранилища скорее всего надо делать опцией (иначе если несколько вторичных хранилищ за разное время - дойдём до первого TNE и радостно свалим, а в более других может быть тайл).

(0006703) Dima2000 (developer) 05-05-2012 10:54	Тут я недопонимаю. В дистрибутиве ночнушек есть лишь libdb51.dll, более никаких dll про хранилища не вижу. Они или не входят в дистрибутив и поставляются отдельно, или я не понимаю принципа. Про хранилища в dll я ещё поизучаю, наследовать всю кучу методов из u_TileStorageAbstract для такой ограниченной задачи мне не нравится. Сделать понятие "второго хранилища" (зачем больше я пока не знаю, но пусть и 3-го, и 125-го) для всех типов кэша мне не кажется проблемой. Ну не будет их обычно и всё. Разумеется привязывать к SAS4WinCE я не прошу, пусть будет универсально. :) Просто для чтения хранилища SAS4WinCE класс я готов написать. В виде dll или в виде unit, это уже достаточно фиолетово. >Нашёл нечто похожее: 0000392 Ну и? Предложили ждать. Помнится плагины ждут уже года два, если не три. >вопрос Если тайл есть в основном - берём оттуда. Если нет, но есть во втором - берём оттуда. Если нет вообще - кирдык. Вообще, поведение не должно отличаться от текущего, только факт наличия тайла проверяется не одним битом (первым хранилищем), а двумя (первое OR второе). А вот сохраняется скачанный тайл в первое, и это логично. TNE файлы можно хранить как во втором (SAS4WinCE) хранилище (зачем?), так и в основном. И удалять из основного если тайл появился. Из второго они мешать не будут - тайл обнаружится в основном и второе спрашиваться не будет вообще.

(0006704) Dima2000 (developer) 05-05-2012 10:56	Да, согласен с vasketsov, во вторичные хранилища TNE вообще не сохранять. Только расход места.

(0006705) Tolik (manager) 05-05-2012 10:57 edited on: 05-05-2012 10:58	DLL для GE в ночнушки не вошёл, скачивается здесь: 0001195. 0000392 давно закрыт - ну и пусть, открывать не будем. Согласен с vasketsov - на tne во вторичном хранилище не обращать внимания, писать в первичное.

(0006706) Garl (manager) 05-05-2012 10:59	и ещё давайте определимся сразу: вторичные и последующие - они всегда рид онли или в них нужно(можно) писать?

(0006708) Tolik (manager) 05-05-2012 11:00	Рид онли, иначе совсем непонятно, когда туда писать, когда сюда... Думаю, хватит и одного вторичного, последующие - это слишком большая нагрузка на моск :)

(0006709) Garl (manager) 05-05-2012 11:01	универсально иметь вторичный кэш в той же Berkley_DB ,а не только в SAS4WinCE

(0006710) Tolik (manager) 05-05-2012 11:07	Да, вообще любой тип, какая разница. Только read-only еще и по идеологическим соображениям: вот есть хороший кэш, скачанный с любовью :) , скопированныый на все компьютеры и розданный друзьям, его портить нельзя.

(0006711) vasketsov (manager) 05-05-2012 11:07	>не входят в дистрибутив и поставляются отдельно Так точно. На то есть основания. Если поискать тут тему - там и DLL найдутся (без исходников). Весь API есть в репозитории саса (открыт). Если надо добавления к нему - надо обсуждать в теме про новое хранилище. >наследовать всю кучу методов из u_TileStorageAbstract Там их примерно штук 5 всего. >мне не нравится Неверный ответ. Если что-то надо сделать - надо разбираться и делать. Идей у всех полно. А нужна реализация. >зачем больше я пока не знаю Я уже приводил пример. Размер кэша Google Earth 2 гига. В реальности если грузить по границам снимков - сильно меньше. Если выгружать участки по снимкам за даты и складывать отдельно, а потом прицепить их как вторичные - получится самый быстрый версионный кэш из ныне доступных для саса, с мгновенным построением карты заполнения (время построения карты заполнения не зависит от разницы зумов). >хранилища в dll я ещё поизучаю Зачем? Может без DLL проще? Есть же фактически метод записи в хранилище (экспорт), надо только чтение сделать. Чего ради конкретно в DLL прятать? Хранилище в DLL априори сложнее в реализации. Например там чтобы не колупаться с диспетчерами памяти, есть лишние извращения, которые в простом случае просто не нужны.

(0006712) Papazol (reporter) 05-05-2012 11:11	Если в качестве источника тайлов присутствует Интернет, то всё должно происходить как раньше, то есть альтернативный кэш должен быть просто отключен. Иначе возможны ситуации, неподконтрольные пользователю. В конце концов, альтернативный кэш создаётся из основного, и он может быть пересоздан в случае добавления новых снимков и т. п. Лишь в случаях, когда упаковываются неизменные данные, есть смысл удалить исходный кэш, а в случаях Google или Yandex обычный кэш должен остаться обязательно. Если альтернативный кэш достался кому-нибудь через скачивание/флешку/диск, то его всегда можно распаковать. Я за отдельный zmp для упакованного кэша.

(0006714) vasketsov (manager) 05-05-2012 11:14 edited on: 05-05-2012 11:17	>они всегда рид онли Ну из того что лично мне надо - да. Ибо "вот есть хороший кэш, скачанный с любовью" и никак иначе у меня нет. Но вообще через вторичные кэши легко реализуется любая версионность на любом типе кэша, хоть на файловом. Для этого только достаточно связать версию и кэш (и тогда как ни прискорбно - TNE писать в соответствующее вторичное хранилище). Собственно это буквально то же самое, что сделать версионным стандартный файловый кэш саса. >Думаю, хватит и одного вторичного Ни в коем случае. Это слишком искуственное ограничение. Делать - так сразу полноценно и нормально, с кучей плюшек и бонусов. >он может быть пересоздан в случае добавления новых снимков Если новые снимки тупо поверх старых - пересоздать его будет уже невозможно.

(0006715) Garl (manager) 05-05-2012 11:15	>Я за отдельный zmp для упакованного кэша. точнее выражаемся.. не понятно (с)

(0006716) Tolik (manager) 05-05-2012 11:18 edited on: 05-05-2012 11:19	Я тоже мало что понял из поста Papazol. Но мы не обсудили самое главное: как программа узнает, что для данной карты существует вторичный (третичный) кэш?

(0006717) Garl (manager) 05-05-2012 11:18	далее: проекции кэшей должны совпадать. но что делать если это не так?

(0006718) Tolik (manager) 05-05-2012 11:20	Почему они могут не совпадать? Например, скачали, экспортировали в другой формат - всё в точности совпадает.

(0006719) Garl (manager) 05-05-2012 11:20	>как программа узнает, что для данной карты существует вторичный (третичный) кэш? или лишние строки в zmp или как то рекурсивно: например zmp внутри cahae\sat или ещё подумать

(0006720) Garl (manager) 05-05-2012 11:21	>Почему они могут не совпадать? человеческий фактор! например : скачали кэш от яндекса и привязали его к гуглю!

(0006721) Tolik (manager) 05-05-2012 11:22	Лишние строки в параметрах карты... И опять вопрос - сколько лишних. Если сколько угодно - это сильно усложнит ГУИ.

(0006722) Tolik (manager) 05-05-2012 11:23	> скачали кэш от яндекса и привязали его к гуглю! А это уже к доктору :) Не стоит заморачиваться, по определению содержимое кэшей одинаково.

(0006723) vasketsov (manager) 05-05-2012 11:26 edited on: 05-05-2012 11:29	>как программа узнает, что для данной карты существует вторичный (третичный) кэш? Например, размножение файла Params в zmp (Params1, Params2, ...): 1. Остаётся один zmp на одну карту. 2. Данные в Params ДОСТАТОЧНЫ (а часть лишняя), их чтение - стандартная процедура. 3. Это позволяет просто копировать Params из одного zmp в другой. 4. Бесплатно получается задание порядка обработки вторичных хранилищ. Минус - дублирование ненужных данных (пункт 2). Или секции в Params (по одной на вторичное хранилище, имена нумеруемые), в них указывать NameInCache и прочие параметры. Компактно и просто. >проекции кэшей должны совпадать. но что делать если это не так? Самое простое и очевидное решение - полностью игнорировать информацию о проекции для вторичных хранилищ. >это сильно усложнит ГУИ Вроде нам обещали динамические деревянные настройки... А вообще добрая половина настроек zmp в гуе отсутствует, так что это не повод.

(0006724) Garl (manager) 05-05-2012 11:28	внутри .zmp делаем папку include или cache и туда кладутся zmp для дополнтельных кэшей. эти дополнительные не должны выводится в менюшку, но по сути это рабочие zmp для кжша. по сути и выдумывать ничего не надо, и реализовывать проще. только с порядком отрисовки\использования надо определиться ... ну или .zmp\incl\01 .zmp\incl\02...999

(0006725) Dima2000 (developer) 05-05-2012 11:30	Я только "за" без dll, в виде unit. Мне так проще. >Я за отдельный zmp для упакованного кэша. А вот я против этого. 90% смысла именно в совместной работе пакованного кэша и кэша SAS. >универсально иметь вторичный кэш в той же Berkley_DB Да, это как прекрасный вариант. >проекции кэшей должны совпадать. А разве хранилища привязаны к проекциям?! Они же в тайловых координатах работают, по крайней мере 4 типа кэшей SAS. >как программа узнает, что для данной карты существует вторичный (третичный) кэш? Да по наличию файлов хранилища. Или вызовом class метода хранилища, который скажет что он есть в природе. Или ещё как. D zmp ничего дописывать не надо, хранилища относятся к SAS, а не картам. Из zmp берётся лишь имя папки хранилища и тип файлов, и вроде как всё.

(0006726) Garl (manager) 05-05-2012 11:31	такс! проекция у нас от cachetype зависит! и игнорировать не получится контрольный пример: есть у меня кэш в формате SAS и Berkley! сас - основной , Беркли - вторичный , соотвественно cachetype у них разный, и ошибиться в одну цифру - легко!

(0006727) Tolik (manager) 05-05-2012 11:36	Править zmp для подключения кэша не хочется, хочется добавить в Параметрах карты и сохранить в maps.ini Лучше просто добавить соответствующие параметры - NameInCache2 (3 т.д.) и CacheType2. Их можно будет использовать и в zmp, и в maps.ini, ну как обычно. И хорошо бы в NameInCache2 иметь возможность прописать полный путь (не помню, это сейчас можно?)

(0006728) Garl (manager) 05-05-2012 11:36	>>как программа узнает, что для данной карты существует вторичный (третичный) кэш? > Да по наличию файлов хранилища. к файлам привязываться не лучший вариант! вариант с размножением Params*.txt интересный.

(0006729) Dima2000 (developer) 05-05-2012 11:37	>проекция у нас от cachetype зависит! С какой радости?! Разве проекция не в zmp для карты указывается?! А тайлы карты могут храниться в любом типе хранилища. С тайловыми координатами, уже правильно спроецированными! Я или недопонимаю технологию хранения, или мы говорим вообще о разном.

(0006730) Garl (manager) 05-05-2012 11:37	> хочется добавить в Параметрах карты и сохранить в maps.ini а как некоторые дорвутся и начнут 100500 кэшей добавлять? представь размеры maps.ini

(0006731) Tolik (manager) 05-05-2012 11:38 edited on: 05-05-2012 11:43	Да, по наличию файлов, но сначала надо указать, где лежат эти файлы. И пихать их в ту же директорию - не лучший вариант, это может быть неудобно.

(0006732) Garl (manager) 05-05-2012 11:38	>Разве проекция не в zmp для карты указывается?! там указывается проекция отображения.

(0006733) vasketsov (manager) 05-05-2012 11:38 edited on: 05-05-2012 11:43	>проекция у нас от cachetype зависит Это шутка? >хранилища привязаны к проекциям В zmp хранится используемая для карты проекция. >там указывается проекция отображения Обе.

(0006735) Tolik (manager) 05-05-2012 11:42	Ну и что, что maps.ini вырастет. Сейчас всё хранится там, и менять принцип не стоит. Когда понадобится вместо него использовать БД или что-то ещё - это будет другая хотелка. Главное, это принёс файл на флешке, скопировал куда-то, указал путь (или хотя бы имя) и тип кэша в параметрах карты - и всё сразу появилось.

(0006736) Garl (manager) 05-05-2012 11:42	>>проекция у нас от cachetype зависит > Это шутка? упс, попутал с projection

(0006739) vasketsov (manager) 05-05-2012 11:48	>Ну и что, что maps.ini вырастет Да вообще не хотелось бы maps.ini трогать. При косяках с картами, URL-ами или при отладке картосервисов - это первое что убивается.

(0006741) Tolik (manager) 05-05-2012 11:50	Да, и сам часто стираю. Но можно вставить NameInCache2 и CacheType2 в свой zmp, если это надолго, а если по-быстрому - в параметры карты. Короче, как и со всеми другими параметрами.

(0006742) Dima2000 (developer) 05-05-2012 11:51 edited on: 05-05-2012 11:53	Да, мысль про Maps.ini правильная. Добавить туда CacheType2, CacheType3 и т.д. с новым значением для SAS4WinCE и при желании ещё и (полный) путь к ним. Для начала - без пути, пусть пока файлы лежат в папке карты. И к первому тоже путь добавить. Если путь не указан - брать из SASPlanet.ini. Сразу несколько хотелок реализуются. Вставка в zmp мне не нравится, параметры карты не слишком привязаны к методу её хранения (ну кроме названия папки). В maps.ini лучше.

(0006744) Tolik (manager) 05-05-2012 11:53	> Для начала - без пути, пусть пока файлы лежат в папке карты. Не так. Пусть пока файлы лежат в той папке, которая прописана в параметрах программы - путь к кэшу.

(0006747) vasketsov (manager) 05-05-2012 12:02	>мысль про Maps.ini правильная Ни в коем разе. В Maps.ini сохраняется изменяемое из гуя. Именно поэтому он и грохается так часто (сохранилось - а потом приоритет у Maps.ini). Чтобы в Maps.ini делать запись вторичных хранилищ - надо сначала сделать полную настройку их из гуя. Оно кому-то реально надо? Ну тогда сперва должен быть форк репозитория и готовый реквест. Пока этого нет - даже говорить не о чем. А кроме того, Maps.ini - это хранилище изменений относительно zmp, а не самих данных. >в свой zmp, если это надолго Если исходить из того, что все данные карты в zmp хранятся - однозначно в zmp должна быть эта информация. В нескольких ParamsN.txt или в секциях - думаю пофигу, откуда прочитать NameInCache (+ максимум Version и пару флагов) - большой разницы нет. Надо понимать, что это не линк между картами. Это подключение хранилища к карте.

(0006748) Garl (manager) 05-05-2012 12:04	в тоже время это хранилище вполне может выступать самостоятельным кэшем, и даже с возможностью записи в неё.

(0006749) Tolik (manager) 05-05-2012 12:04	Я вот не люблю править свой zmp, т.к. он у меня совпадает с репозиторием. Если я в него добавлю свои примочки, я не смогу его пушить туда.

(0006750) Garl (manager) 05-05-2012 12:06	>Я вот не люблю править свой zmp, т.к. он у меня совпадает с репозиторием. аналогично, соответственно остаётся пользовательская папка nameincache=<>

(0006753) vasketsov (manager) 05-05-2012 12:12 edited on: 05-05-2012 12:13	>это хранилище вполне может выступать самостоятельным кэшем ? Может имеется в виду, что это хранилище может быть первичным для другой карты? >Если я в него добавлю свои примочки, я не смогу его пушить туда Если zmp как папка - дополнительные файлы ParamsN просто игнорируются и всё. В принципе даже можно сделать компромиссный вариант - имя файла Storages.txt, в нём или в Params - секции (по одной на хранилище). Если надо публиковать - создаём секции в Params, если не надо - в Storages. Соответственно Storages.txt не заливается в репо.

(0006754) Dima2000 (developer) 05-05-2012 12:15	>Пусть пока файлы лежат в той папке, которая прописана в параметрах программы - путь к кэшу. Конечно, я не так выразился, извините. Для меня папка карты - это не zmp, а папка в кэше. :) >Это подключение хранилища к карте. Именно. И вообще речь не про карты идёт, а про кэш. Который настраивается в параметрах программы (а не карты!) и хранится в SASPlanet.ini. А уж какие карты в этом формате кэша хранить - дело пользователя. >в тоже время это хранилище вполне может выступать самостоятельным кэшем Ну так укажете его первичным и всё. >zmp, т.к. он у меня совпадает с репозиторием Именно, так и должно быть по идее.

(0006758) vasketsov (manager) 05-05-2012 12:21	>Который настраивается в параметрах программы (а не карты!) и хранится в SASPlanet.ini Там типы кэшей, а не конкретные кэши.

(0006760) Dima2000 (developer) 05-05-2012 12:28 edited on: 05-05-2012 12:39	Я всё же хотел бы встроить кэш SAS4WinCE именно на уровень хранилища, без привязки к картам, картам про него знать вообще не надо, это дело лишь тайлового хранилища, что оно лезет не в одно место за тайлом, а в два (три, пять, 125). Ну или самой Планеты, что она спрашивает про тайл не одно хранилище, а два (3, ...). Сущности (карты и хранилища тайлов) надо разделять. :) И никакие zmp (и maps.ini?) менять не придётся. Фактически предлагаю лишь добавить ещё один уровень кэша в процессоры (второе хранилище), который на программы (карты) не влияет и им невидим. Возможно я не врубаюсь в идеологию Планету, сорри. PS. А чрезмерная универсальность уже не одну хотелку погубила, и тут и на форуме.

(0006761) Garl (manager) 05-05-2012 12:39	ИМХО: или универсально или никак :( сори

(0006763) vasketsov (manager) 05-05-2012 12:42	>на уровень хранилища, без привязки к картам Не врубаешься. Есть настройки типов кэшей (хранилищ). Общие в программе (для всех карт). Если настройки хранилищ, из которых конкретная карта берёт данные, и куда кладёт. Погляди на указание относительных путей для кэшей гугла и яндекса, они на одном типе кэша сделаны, но в разных хранилищах. А потом попробуй в NameInCache указать полный путь типа C:\caches\mygoogle - общие настройки проигнорируются. Некоторые типы кэша вообще не требуют указание общих настроек. Например для кэша GE можно оставить путь пустым, и указать его только в свойствах карты в поле NameInCache (или наоборот кстати).

(0006764) Dima2000 (developer) 05-05-2012 12:45	Жаль. Отдельный zmp (с поддерживающей его dll) написать не проблема, но кому оно надо, лишь просмотр без докачки и обновления? Через экспорт это не то. Имхо такой вариант не нужен вообще. Нужно именно сцепление хранилищ в цепочку, с приоритетами.

(0006765) Dima2000 (developer) 05-05-2012 12:51	Про настройки более-менее понятно, непонятно почему смешиваются понятия карты и хранилища. Это же разные сущности. Первая описывает откуда что и как качать и как показывать, а вторая лишь хранит бинарные данные по ключу (координаты). Ни та ни другая в общем-то не должны и знать друг о друге. Я не про настройки путей в ГУИ, а про внутренности. Что есть много разынх вариантов настроек - хорошо, я за.

(0006766) Garl (manager) 05-05-2012 12:55 edited on: 05-05-2012 12:55	разобъём это дело на 2 части: 1 научить планету читать и выводить тайлы из кэша \cache\<путь>\.d** 2 каким то образом подвязать к одному GUID карты другие GUID

(0006767) vasketsov (manager) 05-05-2012 12:55	>Нужно именно сцепление хранилищ в цепочку Оно и будет. Ты просто пока не разобрался. >Отдельный zmp (с поддерживающей его dll) написать не проблема Это только подтверждает написанное выше, не торопись рубить с плеча. >лишь просмотр без докачки и обновления Я уже приводил примеры. Не нравится кэш GE - можно взять любой старый неверсионный кэш (можно сделать версионность). Кроме того, как уже упоминалось, вторичное хранилище для одной карты может быть первичным для другой, и одновременно наоборот. >Через экспорт это не то Экспорт - это связь с SAS4WinCE. Это настолько частный случай, что обсуждать его смысла не имеет. Для примера - потенциально так подключается любой архив в zip или rar из раздачи снимков из соответствующих тем на форуме.

(0006769) vasketsov (manager) 05-05-2012 13:03 edited on: 05-05-2012 13:04	>почему смешиваются понятия карты и хранилища Не так. В настройках карты хранятся настройки её личного хранилища. >1 научить планету читать и выводить тайлы из кэша \cache\<путь>\.d** Вроде SAS4WinCE - это другая тема? >подвязать к одному GUID карты другие GUID Выше был пример с отдельным файлом Storages (сообщение от 05-05-2012 13:12). Минусы?

(0006770) Dima2000 (developer) 05-05-2012 13:04	>Не нравится кэш GE Пока не знаю, не смотрел я его. Меня больше волнует тип кэша по умолчанию Планеты, родной. Остальное всё да.) >1 научить планету читать и выводить тайлы из кэша \cache\<путь>\.d** Вот с этим я и готов помочь, чтобы Вас не загружать. Хотя совсем без советов видимо не обойдусь. ;-)

(0006771) Dima2000 (developer) 05-05-2012 13:07 edited on: 05-05-2012 13:32	>Вроде SAS4WinCE - это другая тема? Да тут всё спуталось, не без моей "помощи".))

(0006794) Tolik (manager) 05-05-2012 18:12	storages.txt или params2.txt - неплохой вариант, но возможности подключать 2-й кэш через ГУИ тогда не будет?

(0006798) vasketsov (manager) 05-05-2012 18:21	>через ГУИ тогда не будет? Она появится как только кто-нибудь её сделает.

(0006821) Garl (manager) 06-05-2012 04:22	кстати можно делать не params1.txt а например params1.add или ещё какое расширение и в параметрах меркуриала поставит игнорирование этого типа файлов (аля как *.bak) и всё! пушится в репо они не будут.

(0006822) Tolik (manager) 06-05-2012 06:08	О, это идея! Это в параметрах клиента настраивается?

(0006824) zed (manager) 06-05-2012 06:19	Это в файлике .hgignore прописывается.

(0006934) vasketsov (manager) 10-05-2012 21:38	Накачал с т@рра$@рв@ра разного нужного барахла - решил делать это как только появится время, так сразу, т@рра$@рв@р сильно повысил приоритет этой доработки для меня лично. Накидал тезисы. Читаем. Комментируем. Дополняем. Спрашиваем и отвечаем. И т.п. 1. Первичное хранилище - хранилище для карты, указанное в секции Params в файле params.txt. 2. Вторичное хранилище - любое другое подключенное к карте хранилище, кроме первичного. 3. Параметры первичного хранилища - любые параметры из секции Params в файле params.txt, связанные с хранилищем тайлов. 4. Настройка вторичных хранилищ осуществляется в файле params.txt и/или в файле storages.txt. 5. Настройка единичного вторичного хранилища осуществляется в рамках одной секции. Имена всех секций для настройки вторичных хранилищ начинаются с 'Storage'. Приоритет использования вторичных хранилищ определяется сортировкой имён секций. При этом все соответствующие секции в params.txt имеют приоритет над секциями в storages.txt. 6. В секциях Storage доступны любые параметры первичного хранилища. В том числе: NameInCache - путь до кэша. Version - для связи вторичного хранилища с конкретной версией. ContentType - тип тайлов в кэше. CacheType - тип хранилища. Usesave - разрешено сохранение в хранилище. Usedel - разрешено удаление из хранилища. А также следующие параметры: Name - произвольное текстовое имя. Enabled - включение и отключение использования хранилища. Zoom - для указания, что хранилище содержит только тайлы определённого зума. Нумерация от 1 до 24. 7. Необходимо добавить параметр UseTNE (значения 0 или 1). Если 0 - в хранилище не сохраняются маркеры TNE (независимо от общей настройки). Если 1 - в хранилище сохраняются маркеры TNE (независимо от общей настройки). Если параметра нет - значит используется общая настройка (как сейчас). Параметр должен быть доступен в том числе для первичных хранилищ. (Противопоказания раздельной настройки TNE?) 8. Параметры проекции не используются для вторичных хранилищ, параметры проекции определяются по первичному хранилищу. 9. Если в NameInCache указан относительный путь - путь считается относительно: а) NameInCache первичного хранилища; б) PrimaryPath типа хранилища (существующая настройка); в) SecondaryPath типа хранилища (создать при необходимости). (необходимо выбрать, возможно по-разному для params.txt и storages.txt) 9. Если для вторичного хранилища указано Usesave=0 - это хранилище используется в режиме "только для чтения" независимо от остальных параметров. В этом случае недопустимы любые изменения в хранилище тайлов. То же самое, если вообще не указано Usesave (считаем 0 значением по умолчанию). 10. Если вторичное хранилище допускает запись в него, то для записи используется первое (с учётом приоритета) доступное вторичное хранилище. Доступность определяется исходя из значений параметров UseTNE, Enabled, Version, Zoom (и возможно других). Этот же алгоритм используется в случае удаления тайла (то есть удаление тайла выполняется только в рамках конкретной версии не более одного раза). В принципе даже в случае чтения тайла алгоритм будет такой же: доступными для чтения считаются все хранилища, если Enabled<>0 или не указано. 11. Функциональность перечисления версий для хранилища необходимо реализовать на уровне выше, чтобы можно было перечислять версии вторичных хранилищ. В этом случае перечисляются все версии (Version), указанные для всех доступных для чтения вторичных хранилищ. К ним добавляются версии, которые получаются существующей процедурой перечисления версий тайла для первичного хранилища и для вторичных хранилищ без Version.

(0006935) Dima2000 (developer) 10-05-2012 21:53	П.10, опрос для записи начинается с первичного или со вторичного? Если первичное поддерживает запись, то будет ли запись в остальные? Я как бы за запись в первое подходящее хранилище, начиная с первичного. Ещё. При чтении тайла хранилища опрашиваются подряд начиная с первичного до нахождения тайла или .tne? Остальное вроде всё логично.

(0006936) Garl (manager) 11-05-2012 04:11	>9. Если в NameInCache указан относительный путь - путь считается относительно: > а) NameInCache первичного хранилища; > б) PrimaryPath типа хранилища (существующая настройка); > в) SecondaryPath типа хранилища (создать при необходимости). > (необходимо выбрать, возможно по-разному для params.txt и storages.txt) а если использовать как сейчас? относительно папки cache просто этот же вторичный кэш (можно)нужно использовать и как первичный, приналичии правильного zmp или ввести в ГУИ установку альтернативной папки >10. Если вторичное хранилище допускает запись в него, то для записи >используется первое (с учётом приоритета) доступное вторичное хранилище. а что должно помешать записи в первичное хранилище?

(0006938) vasketsov (manager) 11-05-2012 06:51	>опрос для записи начинается с первичного или со вторичного? Первичное всегда имеет наивысший приоритет. С первичного. >Если первичное поддерживает запись, то будет ли запись в остальные? Возможно и будет, а возможно и нет. Например если установлены параметры Version\Zoom для вторичного с поддержкой записи - данные для конкретной пары Version\Zoom будут падать именно туда, если некуда - в первичное. Согласен что надо как-то попонятее сформулировать, но идея именно такая. >опрашиваются подряд начиная с первичного до нахождения тайла или .tne? До нахождения либо тайла либо tne. Фишка в том, что если для хранилища не нарисовано руками UseTNE=1 - туда за TNE никто и не полезет, так что такие маркеры TNE будут игнорирваться. >относительно папки cache У этого метода есть один существенный минус. Нельзя нормально целиком опубликовать zmp и кэш в относительных путях, если там несколько папок: 1. Есть папка Terra$erver, в ней до жуткой матери папок вида yyyy-mm-dd-place, чтобы "снаружи" кэш был в одной папке (а уже внутри неё - кэшики) и всё не засиралось. 2. Если относительно cache (или относительно любого единого общего SecondaryPath) - придётся дублировать Terra$erver во всех вторичных NameInCache, что конечно идиотизм. 3. Если относительно NameInCache первичного хранилища - например для обычного гугла можно создать папки с именами версий прямо внутри папки GoogleSat или как она там в кэше зовётся. В примере с Terra$erver - просто относительные папки вида yyyy-mm-dd-place. 4. Если в относительном пути задать лишнее двоеточие - вылетим на уровень cache (если конечно NameInCache первичного хранилища прямо под cache). Если же NameInCache первичного хранилища не относительный - вообще не приходит в голову смысл создания "относительных" папок (от cache) для вторичных для "неотносительного" первичного хранилища (путь NameInCache тупо задан полностью произвольный). Так что хотелось бы понять, в каком случае для вторичных хранилищ реально необходимо задание относительного пути (от cache), когда это невозможно сделать относительно NameInCache первичного. Допускаю что чего-то не догоняю. >ввести в ГУИ установку альтернативной папки Описанную проблему это не решит. >а что должно помешать записи в первичное хранилище? Флаги типа Usesave=0 или установка Version. См. выше комментарий в этом сообщении.

(0006939) Garl (manager) 11-05-2012 07:02	>>а что должно помешать записи в первичное хранилище? > Флаги типа Usesave=0 или установка Version. ну по дефолту запись в первичное(основное) должна быть включена.

(0006940) vasketsov (manager) 11-05-2012 07:07 edited on: 11-05-2012 07:08	>по дефолту запись в первичное(основное) должна быть включена Несомненно. Если флагов нет - в первичное пишем, в остальные не пишем. >Первичное всегда имеет наивысший приоритет. С первичного Походу я погорячился. Вот как надо: Если а) для карты установлена Version и указано хотя бы одно вторичное с Version либо б) хотя бы одно вторичное с Zoom тогда такие вторичные обрабатываются перед первичным. В изначальной постановке (резервный архив только для чтения) таких вторичных не будет, так что ничего не отъедет.

(0006941) Garl (manager) 11-05-2012 07:09	а объясните на пальцах про version как оно работает сейчас? или это поле ещё не задействовано

(0006947) vasketsov (manager) 11-05-2012 08:18 edited on: 11-05-2012 08:21	>объясните на пальцах про version Сейчас поле Version используется в ночнушках: 1. При сохранении тайлов в хранилище (правда 100% записывающих хранилищ пока что неверсионные) - всегда передаётся в хранилище (но далее по сути игнорируется, с Беркли отдельная история как я понял, версия хранится, но тайл с новой версией перезаписывает старый). 2. При скачке тайлов (очевидно независимо от типа хранилища) - если в скрипте формирования УРЛа оно используется (как строковая переменная Version). 3. При чтении тайлов из хранилища - в хранилище передаётся запрашиваемый Version от карты, но в результате возвращён может быть другой Version (например для GE). Соответствено в контексте обсуждаемой доработки, если для вторичного хранилища указано Version - в нём только данные конкретной Version. 4. Ну и переключение Version в контекстном меню - но это тут неактуально, это отдельная хренотенька. 5. Кэширование тайлов в памяти внутри саса осуществляется с учётом Version, но это тоже тут отдельный вопрос. Ещё вариант недоступности записи в первичное хранилище - это если тип кэша такой установлен, что в него нельзя писать (например GC или GE). В общей постановке задачи никаких ограничений на выбор типов для любых хранилищ (первичного или вторичных) не накладывается.

(0006959) Dima2000 (developer) 11-05-2012 12:03 edited on: 11-05-2012 12:03	Да, думаю если есть хранилища с разрешенной записью и поддерживающие version, то надо попытаться сначала записать в них (по порядку сцепления). Если такие кончились и не записалось, то обычным порядком с первичного и далее. Аналогично и с записью TNE. Ещё про version. Я согласен с Демидовым что хранилище не должно возвращать версию если оно её не сохранило. И возвращать запрошенную тоже не должно! Пусть возвращает или 0 или -1 или ещё какую константу (типа cUnknownVersion, определенную снаружи), недопустимую для версии. Это про неподдерживающие версии хранилища.

(0007002) vasketsov (manager) 12-05-2012 20:55	>недопустимую для версии Для версии допустимо всё кроме пустой строки. В смысле интерфейса - теоретически можно вернуть NIL. Но сути это не меняет. Версия - произвольная строка.

Users who viewed this issue
User List	Anonymous (6811x), vdemidov (3x), zed (1x)
Total Views	6815
Last View	21-11-2024 17:29

Issue History
Date Modified	Username	Field	Change
05-05-2012 10:24	Dima2000	New Issue
05-05-2012 10:32	vasketsov	Note Added: 0006693
05-05-2012 10:36	Tolik	Note Added: 0006695
05-05-2012 10:37	Garl	Note Added: 0006697
05-05-2012 10:39	Garl	Note Added: 0006698
05-05-2012 10:43	Tolik	Note Added: 0006701
05-05-2012 10:44	Tolik	Note Edited: 0006701	View Revisions
05-05-2012 10:45	Tolik	Note Edited: 0006701	View Revisions
05-05-2012 10:49	Tolik	Status	new => acknowledged
05-05-2012 10:49	Tolik	Summary	Поддержка кэша в формате SAS4WinCE в качестве второго хранилища => Поддержка вторичного read-only кэша (например, в формате SAS4WinCE)
05-05-2012 10:50	Tolik	Note Edited: 0006695	View Revisions
05-05-2012 10:53	Tolik	Additional Information Updated	View Revisions
05-05-2012 10:53	vasketsov	Note Added: 0006702
05-05-2012 10:54	Dima2000	Note Added: 0006703
05-05-2012 10:56	Dima2000	Note Added: 0006704
05-05-2012 10:57	Tolik	Note Added: 0006705
05-05-2012 10:58	Tolik	Note Edited: 0006705	View Revisions
05-05-2012 10:58	Tolik	Note Edited: 0006705	View Revisions
05-05-2012 10:59	Garl	Note Added: 0006706
05-05-2012 11:00	Tolik	Note Added: 0006708
05-05-2012 11:01	Garl	Note Added: 0006709
05-05-2012 11:07	Tolik	Note Added: 0006710
05-05-2012 11:07	vasketsov	Note Added: 0006711
05-05-2012 11:11	Papazol	Note Added: 0006712
05-05-2012 11:14	vasketsov	Note Added: 0006714
05-05-2012 11:15	Garl	Note Added: 0006715
05-05-2012 11:17	vasketsov	Note Edited: 0006714	View Revisions
05-05-2012 11:18	Tolik	Note Added: 0006716
05-05-2012 11:18	Garl	Note Added: 0006717
05-05-2012 11:19	Tolik	Note Edited: 0006716	View Revisions
05-05-2012 11:20	Tolik	Note Added: 0006718
05-05-2012 11:20	Garl	Note Added: 0006719
05-05-2012 11:21	Garl	Note Added: 0006720
05-05-2012 11:22	Tolik	Note Added: 0006721
05-05-2012 11:23	Tolik	Note Added: 0006722
05-05-2012 11:26	vasketsov	Note Added: 0006723
05-05-2012 11:28	Garl	Note Added: 0006724
05-05-2012 11:29	vasketsov	Note Edited: 0006723	View Revisions
05-05-2012 11:30	Dima2000	Note Added: 0006725
05-05-2012 11:31	Garl	Note Added: 0006726
05-05-2012 11:36	Tolik	Note Added: 0006727
05-05-2012 11:36	Garl	Note Added: 0006728
05-05-2012 11:37	Dima2000	Note Added: 0006729
05-05-2012 11:37	Garl	Note Added: 0006730
05-05-2012 11:38	Tolik	Note Added: 0006731
05-05-2012 11:38	Garl	Note Added: 0006732
05-05-2012 11:38	vasketsov	Note Added: 0006733
05-05-2012 11:39	vasketsov	Note Edited: 0006733	View Revisions
05-05-2012 11:42	Tolik	Note Added: 0006735
05-05-2012 11:42	Garl	Note Added: 0006736
05-05-2012 11:43	Tolik	Note Edited: 0006731	View Revisions
05-05-2012 11:43	vasketsov	Note Edited: 0006733	View Revisions
05-05-2012 11:48	vasketsov	Note Added: 0006739
05-05-2012 11:50	Tolik	Note Added: 0006741
05-05-2012 11:51	Dima2000	Note Added: 0006742
05-05-2012 11:53	Dima2000	Note Edited: 0006742	View Revisions
05-05-2012 11:53	Tolik	Note Added: 0006744
05-05-2012 12:02	vasketsov	Note Added: 0006747
05-05-2012 12:04	Garl	Note Added: 0006748
05-05-2012 12:04	Tolik	Note Added: 0006749
05-05-2012 12:06	Garl	Note Added: 0006750
05-05-2012 12:12	vasketsov	Note Added: 0006753
05-05-2012 12:13	vasketsov	Note Edited: 0006753	View Revisions
05-05-2012 12:15	Dima2000	Note Added: 0006754
05-05-2012 12:21	vasketsov	Note Added: 0006758
05-05-2012 12:28	Dima2000	Note Added: 0006760
05-05-2012 12:39	Garl	Note Added: 0006761
05-05-2012 12:39	Dima2000	Note Edited: 0006760	View Revisions
05-05-2012 12:42	vasketsov	Note Added: 0006763
05-05-2012 12:45	Dima2000	Note Added: 0006764
05-05-2012 12:51	Dima2000	Note Added: 0006765
05-05-2012 12:55	Garl	Note Added: 0006766
05-05-2012 12:55	Garl	Note Edited: 0006766	View Revisions
05-05-2012 12:55	vasketsov	Note Added: 0006767
05-05-2012 13:03	vasketsov	Note Added: 0006769
05-05-2012 13:04	vasketsov	Note Edited: 0006769	View Revisions
05-05-2012 13:04	Dima2000	Note Added: 0006770
05-05-2012 13:07	Dima2000	Note Added: 0006771
05-05-2012 13:32	Dima2000	Note Edited: 0006771	View Revisions
05-05-2012 18:12	Tolik	Note Added: 0006794
05-05-2012 18:21	vasketsov	Note Added: 0006798
06-05-2012 04:22	Garl	Note Added: 0006821
06-05-2012 06:08	Tolik	Note Added: 0006822
06-05-2012 06:19	zed	Note Added: 0006824
10-05-2012 21:38	vasketsov	Note Added: 0006934
10-05-2012 21:53	Dima2000	Note Added: 0006935
11-05-2012 04:11	Garl	Note Added: 0006936
11-05-2012 06:51	vasketsov	Note Added: 0006938
11-05-2012 07:02	Garl	Note Added: 0006939
11-05-2012 07:07	vasketsov	Note Added: 0006940
11-05-2012 07:08	vasketsov	Note Edited: 0006940	View Revisions
11-05-2012 07:09	Garl	Note Added: 0006941
11-05-2012 08:18	vasketsov	Note Added: 0006947
11-05-2012 08:20	vasketsov	Note Edited: 0006947	View Revisions
11-05-2012 08:21	vasketsov	Note Edited: 0006947	View Revisions
11-05-2012 12:03	Dima2000	Note Added: 0006959
11-05-2012 12:03	Dima2000	Note Edited: 0006959	View Revisions
12-05-2012 20:55	vasketsov	Note Added: 0007002
13-05-2012 09:01	gpsMax	Tag Attached: SAS4WinCE
22-06-2012 07:25	vasketsov	Assigned To	=> vasketsov
22-06-2012 07:25	vasketsov	Status	acknowledged => assigned
24-06-2012 10:58	Dima2000	Relationship added	related to 0001291
30-03-2014 17:13	zed	Relationship added	related to 0002392
30-03-2014 17:17	zed	Tag Attached: кэш
31-03-2014 09:18	vdemidov	Assigned To	vasketsov =>
31-03-2014 09:18	vdemidov	Status	assigned => confirmed
31-03-2014 09:18	vdemidov	Target Version	=> 50xxxx
09-10-2015 07:15	vdemidov	Tag Attached: тайлохранилище
13-07-2019 14:30	RIXXX	Issue cloned: 0003497

SASGIS