|
Notes |
|
|
|
>И я готов написать всё необходимое
Объясняю на пальцах:
1. Хранилища наследуются от u_TileStorageAbstract.pas и все в u_TileStorage* (кроме u_TileStorageType* и u_TileStorageInfo*).
2. Примеры хранилищ только для чтения в виде DLL - это хранилища для Google Earth и GeoCacher. Если надо с DLL - интерфейс описан. Если надо без DLL - всё ещё проще. Необходимо сделать хранилище для SAS4WinCE (только для чтения или нет - тут полностью эквипенисуально).
Лазалку после первого хранилища во второе нельзя делать в рамках хранилища и нельзя привязывать к настройкам хранилища или привязывать к SAS4WinCE. Это общая логика, при недоступности тайлов в первичном хранилище лезем во второе (и не только для чтения тайлов кстати). Поэтому эта логика должна быть сделана над хранилищами. А кроме того "вторичных" хранилищ может быть произвольно много (пример - родные кэши Google Earth на DVD по участкам на местности). |
|
|
|
(0006695)
|
|
Tolik
|
05-05-2012 10:36
(edited on: 05-05-2012 10:50) |
|
То есть опять-таки задача разбивается на 2:
1. поддержка хранилища SAS4WinCE
2. поддержка вторичного кэша (любого из поддерживаемых типов).
Пусть эта хотелка решает п.2, а по п.1 открыл ещё одну: 0001291.
|
|
|
|
(0006697)
|
|
Garl
|
|
05-05-2012 10:37
|
|
Собственно вопрос:
стоит режим интернет+кэш
тайла нету в текущем кэше, зато он есть в запакованом,
что должна сделать программа?
1 показать тайл из пакованного хранилища
2 не показывать и скачать тайл из интернета
3 показать из пакованного , а затем скачать и показать новый
4...
что делать если тайла нету в интернете?
что делать с .tne файлами.
и ещё куча организационных вопросов... |
|
|
|
(0006698)
|
|
Garl
|
|
05-05-2012 10:39
|
|
кстати гдето была хотелка про альтернативный кэш, тоесть если нету в одном - то искать в другом.
может тогда будет проще?
делаем новый тип кэша в рид-онли и подключаем его как альтернативный... |
|
|
|
(0006701)
|
|
Tolik
|
05-05-2012 10:43
(edited on: 05-05-2012 10:45) |
|
Нашёл нечто похожее: 0000392
Ответ №1.
А в режиме Интернет - ответ 3. Или, может быть, 2.
|
|
|
|
|
Итак если предположить существование типа кэша для SAS4WinCE и подключения его как вторичного только для чтения:
>Если стоит режим интернет+кэш, тайла нету в текущем кэше, зато он есть в запакованом
Значит тайл есть (решение о наличии принимается по сей совокупности используемых хранилищ исходя из обобщённых координат тайла {x,y,z,v}). Его и показываем.
>что делать с .tne файлами
Создавать всегда в первичном хранилище. TNE - признак отсутствия тайла в интернете, так что это совершенно не зависит от наличия или отсутствия вторичного хранилища. А чтение TNE из вторичного хранилища скорее всего надо делать опцией (иначе если несколько вторичных хранилищ за разное время - дойдём до первого TNE и радостно свалим, а в более других может быть тайл). |
|
|
|
|
Тут я недопонимаю. В дистрибутиве ночнушек есть лишь libdb51.dll, более никаких dll про хранилища не вижу. Они или не входят в дистрибутив и поставляются отдельно, или я не понимаю принципа.
Про хранилища в dll я ещё поизучаю, наследовать всю кучу методов из u_TileStorageAbstract для такой ограниченной задачи мне не нравится.
Сделать понятие "второго хранилища" (зачем больше я пока не знаю, но пусть и 3-го, и 125-го) для всех типов кэша мне не кажется проблемой. Ну не будет их обычно и всё. Разумеется привязывать к SAS4WinCE я не прошу, пусть будет универсально. :) Просто для чтения хранилища SAS4WinCE класс я готов написать. В виде dll или в виде unit, это уже достаточно фиолетово.
>Нашёл нечто похожее: 0000392
Ну и? Предложили ждать. Помнится плагины ждут уже года два, если не три.
>вопрос
Если тайл есть в основном - берём оттуда. Если нет, но есть во втором - берём оттуда. Если нет вообще - кирдык. Вообще, поведение не должно отличаться от текущего, только факт наличия тайла проверяется не одним битом (первым хранилищем), а двумя (первое OR второе). А вот сохраняется скачанный тайл в первое, и это логично.
TNE файлы можно хранить как во втором (SAS4WinCE) хранилище (зачем?), так и в основном. И удалять из основного если тайл появился. Из второго они мешать не будут - тайл обнаружится в основном и второе спрашиваться не будет вообще. |
|
|
|
|
|
Да, согласен с vasketsov, во вторичные хранилища TNE вообще не сохранять. Только расход места. |
|
|
|
(0006705)
|
|
Tolik
|
05-05-2012 10:57
(edited on: 05-05-2012 10:58) |
|
DLL для GE в ночнушки не вошёл, скачивается здесь: 0001195.
0000392 давно закрыт - ну и пусть, открывать не будем.
Согласен с vasketsov - на tne во вторичном хранилище не обращать внимания, писать в первичное.
|
|
|
|
(0006706)
|
|
Garl
|
|
05-05-2012 10:59
|
|
|
и ещё давайте определимся сразу: вторичные и последующие - они всегда рид онли или в них нужно(можно) писать? |
|
|
|
(0006708)
|
|
Tolik
|
|
05-05-2012 11:00
|
|
Рид онли, иначе совсем непонятно, когда туда писать, когда сюда...
Думаю, хватит и одного вторичного, последующие - это слишком большая нагрузка на моск :) |
|
|
|
(0006709)
|
|
Garl
|
|
05-05-2012 11:01
|
|
|
универсально иметь вторичный кэш в той же Berkley_DB ,а не только в SAS4WinCE |
|
|
|
(0006710)
|
|
Tolik
|
|
05-05-2012 11:07
|
|
Да, вообще любой тип, какая разница.
Только read-only еще и по идеологическим соображениям: вот есть хороший кэш, скачанный с любовью :) , скопированныый на все компьютеры и розданный друзьям, его портить нельзя. |
|
|
|
|
>не входят в дистрибутив и поставляются отдельно
Так точно. На то есть основания. Если поискать тут тему - там и DLL найдутся (без исходников). Весь API есть в репозитории саса (открыт). Если надо добавления к нему - надо обсуждать в теме про новое хранилище.
>наследовать всю кучу методов из u_TileStorageAbstract
Там их примерно штук 5 всего.
>мне не нравится
Неверный ответ. Если что-то надо сделать - надо разбираться и делать. Идей у всех полно. А нужна реализация.
>зачем больше я пока не знаю
Я уже приводил пример. Размер кэша Google Earth 2 гига. В реальности если грузить по границам снимков - сильно меньше. Если выгружать участки по снимкам за даты и складывать отдельно, а потом прицепить их как вторичные - получится самый быстрый версионный кэш из ныне доступных для саса, с мгновенным построением карты заполнения (время построения карты заполнения не зависит от разницы зумов).
>хранилища в dll я ещё поизучаю
Зачем? Может без DLL проще? Есть же фактически метод записи в хранилище (экспорт), надо только чтение сделать. Чего ради конкретно в DLL прятать? Хранилище в DLL априори сложнее в реализации. Например там чтобы не колупаться с диспетчерами памяти, есть лишние извращения, которые в простом случае просто не нужны. |
|
|
|
|
Если в качестве источника тайлов присутствует Интернет, то всё должно происходить как раньше, то есть альтернативный кэш должен быть просто отключен. Иначе возможны ситуации, неподконтрольные пользователю.
В конце концов, альтернативный кэш создаётся из основного, и он может быть пересоздан в случае добавления новых снимков и т. п. Лишь в случаях, когда упаковываются неизменные данные, есть смысл удалить исходный кэш, а в случаях Google или Yandex обычный кэш должен остаться обязательно.
Если альтернативный кэш достался кому-нибудь через скачивание/флешку/диск, то его всегда можно распаковать.
Я за отдельный zmp для упакованного кэша. |
|
|
|
(0006714)
|
|
vasketsov
|
05-05-2012 11:14
(edited on: 05-05-2012 11:17) |
|
>они всегда рид онли
Ну из того что лично мне надо - да. Ибо "вот есть хороший кэш, скачанный с любовью" и никак иначе у меня нет.
Но вообще через вторичные кэши легко реализуется любая версионность на любом типе кэша, хоть на файловом. Для этого только достаточно связать версию и кэш (и тогда как ни прискорбно - TNE писать в соответствующее вторичное хранилище). Собственно это буквально то же самое, что сделать версионным стандартный файловый кэш саса.
>Думаю, хватит и одного вторичного
Ни в коем случае. Это слишком искуственное ограничение. Делать - так сразу полноценно и нормально, с кучей плюшек и бонусов.
>он может быть пересоздан в случае добавления новых снимков
Если новые снимки тупо поверх старых - пересоздать его будет уже невозможно.
|
|
|
|
(0006715)
|
|
Garl
|
|
05-05-2012 11:15
|
|
>Я за отдельный zmp для упакованного кэша.
точнее выражаемся..
не понятно (с) |
|
|
|
(0006716)
|
|
Tolik
|
05-05-2012 11:18
(edited on: 05-05-2012 11:19) |
|
Я тоже мало что понял из поста Papazol.
Но мы не обсудили самое главное: как программа узнает, что для данной карты существует вторичный (третичный) кэш?
|
|
|
|
(0006717)
|
|
Garl
|
|
05-05-2012 11:18
|
|
далее:
проекции кэшей должны совпадать.
но что делать если это не так? |
|
|
|
(0006718)
|
|
Tolik
|
|
05-05-2012 11:20
|
|
|
Почему они могут не совпадать? Например, скачали, экспортировали в другой формат - всё в точности совпадает. |
|
|
|
(0006719)
|
|
Garl
|
|
05-05-2012 11:20
|
|
>как программа узнает, что для данной карты существует вторичный (третичный) кэш?
или лишние строки в zmp
или как то рекурсивно: например zmp внутри cahae\sat
или ещё подумать |
|
|
|
(0006720)
|
|
Garl
|
|
05-05-2012 11:21
|
|
>Почему они могут не совпадать?
человеческий фактор!
например : скачали кэш от яндекса и привязали его к гуглю! |
|
|
|
(0006721)
|
|
Tolik
|
|
05-05-2012 11:22
|
|
|
Лишние строки в параметрах карты... И опять вопрос - сколько лишних. Если сколько угодно - это сильно усложнит ГУИ. |
|
|
|
(0006722)
|
|
Tolik
|
|
05-05-2012 11:23
|
|
> скачали кэш от яндекса и привязали его к гуглю!
А это уже к доктору :)
Не стоит заморачиваться, по определению содержимое кэшей одинаково. |
|
|
|
(0006723)
|
|
vasketsov
|
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
|
|
05-05-2012 11:28
|
|
внутри .zmp делаем папку include или cache
и туда кладутся zmp для дополнтельных кэшей.
эти дополнительные не должны выводится в менюшку, но по сути это рабочие zmp для кжша.
по сути и выдумывать ничего не надо, и реализовывать проще.
только с порядком отрисовки\использования надо определиться ...
ну или .zmp\incl\01 .zmp\incl\02...999 |
|
|
|
|
Я только "за" без dll, в виде unit. Мне так проще.
>Я за отдельный zmp для упакованного кэша.
А вот я против этого. 90% смысла именно в совместной работе пакованного кэша и кэша SAS.
>универсально иметь вторичный кэш в той же Berkley_DB
Да, это как прекрасный вариант.
>проекции кэшей должны совпадать.
А разве хранилища привязаны к проекциям?! Они же в тайловых координатах работают, по крайней мере 4 типа кэшей SAS.
>как программа узнает, что для данной карты существует вторичный (третичный) кэш?
Да по наличию файлов хранилища. Или вызовом class метода хранилища, который скажет что он есть в природе. Или ещё как.
D zmp ничего дописывать не надо, хранилища относятся к SAS, а не картам. Из zmp берётся лишь имя папки хранилища и тип файлов, и вроде как всё. |
|
|
|
(0006726)
|
|
Garl
|
|
05-05-2012 11:31
|
|
такс! проекция у нас от cachetype зависит! и игнорировать не получится
контрольный пример:
есть у меня кэш в формате SAS и Berkley! сас - основной , Беркли - вторичный , соотвественно cachetype у них разный, и ошибиться в одну цифру - легко! |
|
|
|
(0006727)
|
|
Tolik
|
|
05-05-2012 11:36
|
|
Править zmp для подключения кэша не хочется, хочется добавить в Параметрах карты и сохранить в maps.ini
Лучше просто добавить соответствующие параметры - NameInCache2 (3 т.д.) и CacheType2. Их можно будет использовать и в zmp, и в maps.ini, ну как обычно.
И хорошо бы в NameInCache2 иметь возможность прописать полный путь (не помню, это сейчас можно?) |
|
|
|
(0006728)
|
|
Garl
|
|
05-05-2012 11:36
|
|
>>как программа узнает, что для данной карты существует вторичный (третичный) кэш?
> Да по наличию файлов хранилища.
к файлам привязываться не лучший вариант!
вариант с размножением Params*.txt интересный. |
|
|
|
|
>проекция у нас от cachetype зависит!
С какой радости?! Разве проекция не в zmp для карты указывается?! А тайлы карты могут храниться в любом типе хранилища. С тайловыми координатами, уже правильно спроецированными!
Я или недопонимаю технологию хранения, или мы говорим вообще о разном. |
|
|
|
(0006730)
|
|
Garl
|
|
05-05-2012 11:37
|
|
> хочется добавить в Параметрах карты и сохранить в maps.ini
а как некоторые дорвутся и начнут 100500 кэшей добавлять? представь размеры maps.ini |
|
|
|
(0006731)
|
|
Tolik
|
05-05-2012 11:38
(edited on: 05-05-2012 11:43) |
|
Да, по наличию файлов, но сначала надо указать, где лежат эти файлы.
И пихать их в ту же директорию - не лучший вариант, это может быть неудобно.
|
|
|
|
(0006732)
|
|
Garl
|
|
05-05-2012 11:38
|
|
>Разве проекция не в zmp для карты указывается?!
там указывается проекция отображения. |
|
|
|
(0006733)
|
|
vasketsov
|
05-05-2012 11:38
(edited on: 05-05-2012 11:43) |
|
>проекция у нас от cachetype зависит
Это шутка?
>хранилища привязаны к проекциям
В zmp хранится используемая для карты проекция.
>там указывается проекция отображения
Обе.
|
|
|
|
(0006735)
|
|
Tolik
|
|
05-05-2012 11:42
|
|
Ну и что, что maps.ini вырастет. Сейчас всё хранится там, и менять принцип не стоит. Когда понадобится вместо него использовать БД или что-то ещё - это будет другая хотелка.
Главное, это принёс файл на флешке, скопировал куда-то, указал путь (или хотя бы имя) и тип кэша в параметрах карты - и всё сразу появилось. |
|
|
|
(0006736)
|
|
Garl
|
|
05-05-2012 11:42
|
|
>>проекция у нас от cachetype зависит
> Это шутка?
упс, попутал с projection |
|
|
|
|
>Ну и что, что maps.ini вырастет
Да вообще не хотелось бы maps.ini трогать. При косяках с картами, URL-ами или при отладке картосервисов - это первое что убивается. |
|
|
|
(0006741)
|
|
Tolik
|
|
05-05-2012 11:50
|
|
|
Да, и сам часто стираю. Но можно вставить NameInCache2 и CacheType2 в свой zmp, если это надолго, а если по-быстрому - в параметры карты. Короче, как и со всеми другими параметрами. |
|
|
|
(0006742)
|
|
Dima2000
|
05-05-2012 11:51
(edited on: 05-05-2012 11:53) |
|
Да, мысль про Maps.ini правильная. Добавить туда CacheType2, CacheType3 и т.д. с новым значением для SAS4WinCE и при желании ещё и (полный) путь к ним. Для начала - без пути, пусть пока файлы лежат в папке карты. И к первому тоже путь добавить. Если путь не указан - брать из SASPlanet.ini. Сразу несколько хотелок реализуются.
Вставка в zmp мне не нравится, параметры карты не слишком привязаны к методу её хранения (ну кроме названия папки). В maps.ini лучше.
|
|
|
|
(0006744)
|
|
Tolik
|
|
05-05-2012 11:53
|
|
> Для начала - без пути, пусть пока файлы лежат в папке карты.
Не так. Пусть пока файлы лежат в той папке, которая прописана в параметрах программы - путь к кэшу. |
|
|
|
|
>мысль про Maps.ini правильная
Ни в коем разе.
В Maps.ini сохраняется изменяемое из гуя.
Именно поэтому он и грохается так часто (сохранилось - а потом приоритет у Maps.ini). Чтобы в Maps.ini делать запись вторичных хранилищ - надо сначала сделать полную настройку их из гуя. Оно кому-то реально надо? Ну тогда сперва должен быть форк репозитория и готовый реквест. Пока этого нет - даже говорить не о чем. А кроме того, Maps.ini - это хранилище изменений относительно zmp, а не самих данных.
>в свой zmp, если это надолго
Если исходить из того, что все данные карты в zmp хранятся - однозначно в zmp должна быть эта информация. В нескольких ParamsN.txt или в секциях - думаю пофигу, откуда прочитать NameInCache (+ максимум Version и пару флагов) - большой разницы нет.
Надо понимать, что это не линк между картами. Это подключение хранилища к карте. |
|
|
|
(0006748)
|
|
Garl
|
|
05-05-2012 12:04
|
|
|
в тоже время это хранилище вполне может выступать самостоятельным кэшем, и даже с возможностью записи в неё. |
|
|
|
(0006749)
|
|
Tolik
|
|
05-05-2012 12:04
|
|
|
Я вот не люблю править свой zmp, т.к. он у меня совпадает с репозиторием. Если я в него добавлю свои примочки, я не смогу его пушить туда. |
|
|
|
(0006750)
|
|
Garl
|
|
05-05-2012 12:06
|
|
>Я вот не люблю править свой zmp, т.к. он у меня совпадает с репозиторием.
аналогично, соответственно остаётся пользовательская папка nameincache=<> |
|
|
|
(0006753)
|
|
vasketsov
|
05-05-2012 12:12
(edited on: 05-05-2012 12:13) |
|
>это хранилище вполне может выступать самостоятельным кэшем
?
Может имеется в виду, что это хранилище может быть первичным для другой карты?
>Если я в него добавлю свои примочки, я не смогу его пушить туда
Если zmp как папка - дополнительные файлы ParamsN просто игнорируются и всё. В принципе даже можно сделать компромиссный вариант - имя файла Storages.txt, в нём или в Params - секции (по одной на хранилище). Если надо публиковать - создаём секции в Params, если не надо - в Storages. Соответственно Storages.txt не заливается в репо.
|
|
|
|
|
>Пусть пока файлы лежат в той папке, которая прописана в параметрах программы - путь к кэшу.
Конечно, я не так выразился, извините. Для меня папка карты - это не zmp, а папка в кэше. :)
>Это подключение хранилища к карте.
Именно. И вообще речь не про карты идёт, а про кэш. Который настраивается в параметрах программы (а не карты!) и хранится в SASPlanet.ini. А уж какие карты в этом формате кэша хранить - дело пользователя.
>в тоже время это хранилище вполне может выступать самостоятельным кэшем
Ну так укажете его первичным и всё.
>zmp, т.к. он у меня совпадает с репозиторием
Именно, так и должно быть по идее. |
|
|
|
|
>Который настраивается в параметрах программы (а не карты!) и хранится в SASPlanet.ini
Там типы кэшей, а не конкретные кэши. |
|
|
|
(0006760)
|
|
Dima2000
|
05-05-2012 12:28
(edited on: 05-05-2012 12:39) |
|
Я всё же хотел бы встроить кэш SAS4WinCE именно на уровень хранилища, без привязки к картам, картам про него знать вообще не надо, это дело лишь тайлового хранилища, что оно лезет не в одно место за тайлом, а в два (три, пять, 125). Ну или самой Планеты, что она спрашивает про тайл не одно хранилище, а два (3, ...). Сущности (карты и хранилища тайлов) надо разделять. :)
И никакие zmp (и maps.ini?) менять не придётся.
Фактически предлагаю лишь добавить ещё один уровень кэша в процессоры (второе хранилище), который на программы (карты) не влияет и им невидим.
Возможно я не врубаюсь в идеологию Планету, сорри.
PS. А чрезмерная универсальность уже не одну хотелку погубила, и тут и на форуме.
|
|
|
|
(0006761)
|
|
Garl
|
|
05-05-2012 12:39
|
|
|
ИМХО: или универсально или никак :( сори |
|
|
|
|
>на уровень хранилища, без привязки к картам
Не врубаешься.
Есть настройки типов кэшей (хранилищ). Общие в программе (для всех карт).
Если настройки хранилищ, из которых конкретная карта берёт данные, и куда кладёт.
Погляди на указание относительных путей для кэшей гугла и яндекса, они на одном типе кэша сделаны, но в разных хранилищах. А потом попробуй в NameInCache указать полный путь типа C:\caches\mygoogle - общие настройки проигнорируются.
Некоторые типы кэша вообще не требуют указание общих настроек. Например для кэша GE можно оставить путь пустым, и указать его только в свойствах карты в поле NameInCache (или наоборот кстати). |
|
|
|
|
Жаль.
Отдельный zmp (с поддерживающей его dll) написать не проблема, но кому оно надо, лишь просмотр без докачки и обновления? Через экспорт это не то. Имхо такой вариант не нужен вообще. Нужно именно сцепление хранилищ в цепочку, с приоритетами. |
|
|
|
|
|
Про настройки более-менее понятно, непонятно почему смешиваются понятия карты и хранилища. Это же разные сущности. Первая описывает откуда что и как качать и как показывать, а вторая лишь хранит бинарные данные по ключу (координаты). Ни та ни другая в общем-то не должны и знать друг о друге. Я не про настройки путей в ГУИ, а про внутренности. Что есть много разынх вариантов настроек - хорошо, я за. |
|
|
|
(0006766)
|
|
Garl
|
|
05-05-2012 12:55
|
|
разобъём это дело на 2 части:
1 научить планету читать и выводить тайлы из кэша \cache\<путь>\.d**
2 каким то образом подвязать к одному GUID карты другие GUID
|
|
|
|
|
>Нужно именно сцепление хранилищ в цепочку
Оно и будет. Ты просто пока не разобрался.
>Отдельный zmp (с поддерживающей его dll) написать не проблема
Это только подтверждает написанное выше, не торопись рубить с плеча.
>лишь просмотр без докачки и обновления
Я уже приводил примеры. Не нравится кэш GE - можно взять любой старый неверсионный кэш (можно сделать версионность). Кроме того, как уже упоминалось, вторичное хранилище для одной карты может быть первичным для другой, и одновременно наоборот.
>Через экспорт это не то
Экспорт - это связь с SAS4WinCE. Это настолько частный случай, что обсуждать его смысла не имеет. Для примера - потенциально так подключается любой архив в zip или rar из раздачи снимков из соответствующих тем на форуме. |
|
|
|
(0006769)
|
|
vasketsov
|
05-05-2012 13:03
(edited on: 05-05-2012 13:04) |
|
>почему смешиваются понятия карты и хранилища
Не так. В настройках карты хранятся настройки её личного хранилища.
>1 научить планету читать и выводить тайлы из кэша \cache\<путь>\.d**
Вроде SAS4WinCE - это другая тема?
>подвязать к одному GUID карты другие GUID
Выше был пример с отдельным файлом Storages (сообщение от 05-05-2012 13:12). Минусы?
|
|
|
|
|
>Не нравится кэш GE
Пока не знаю, не смотрел я его. Меня больше волнует тип кэша по умолчанию Планеты, родной.
Остальное всё да.)
>1 научить планету читать и выводить тайлы из кэша \cache\<путь>\.d**
Вот с этим я и готов помочь, чтобы Вас не загружать. Хотя совсем без советов видимо не обойдусь. ;-) |
|
|
|
(0006771)
|
|
Dima2000
|
05-05-2012 13:07
(edited on: 05-05-2012 13:32) |
|
>Вроде SAS4WinCE - это другая тема?
Да тут всё спуталось, не без моей "помощи".))
|
|
|
|
(0006794)
|
|
Tolik
|
|
05-05-2012 18:12
|
|
|
storages.txt или params2.txt - неплохой вариант, но возможности подключать 2-й кэш через ГУИ тогда не будет? |
|
|
|
|
>через ГУИ тогда не будет?
Она появится как только кто-нибудь её сделает. |
|
|
|
(0006821)
|
|
Garl
|
|
06-05-2012 04:22
|
|
|
кстати можно делать не params1.txt а например params1.add или ещё какое расширение и в параметрах меркуриала поставит игнорирование этого типа файлов (аля как *.bak) и всё! пушится в репо они не будут. |
|
|
|
(0006822)
|
|
Tolik
|
|
06-05-2012 06:08
|
|
|
О, это идея! Это в параметрах клиента настраивается? |
|
|
|
(0006824)
|
|
zed
|
|
06-05-2012 06:19
|
|
|
Это в файлике .hgignore прописывается. |
|
|
|
|
Накачал с т@рра$@рв@ра разного нужного барахла - решил делать это как только появится время, так сразу, т@рра$@рв@р сильно повысил приоритет этой доработки для меня лично.
Накидал тезисы. Читаем. Комментируем. Дополняем. Спрашиваем и отвечаем. И т.п.
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. |
|
|
|
|
П.10, опрос для записи начинается с первичного или со вторичного? Если первичное поддерживает запись, то будет ли запись в остальные?
Я как бы за запись в первое подходящее хранилище, начиная с первичного.
Ещё. При чтении тайла хранилища опрашиваются подряд начиная с первичного до нахождения тайла или .tne?
Остальное вроде всё логично. |
|
|
|
(0006936)
|
|
Garl
|
|
11-05-2012 04:11
|
|
>9. Если в NameInCache указан относительный путь - путь считается относительно:
> а) NameInCache первичного хранилища;
> б) PrimaryPath типа хранилища (существующая настройка);
> в) SecondaryPath типа хранилища (создать при необходимости).
> (необходимо выбрать, возможно по-разному для params.txt и storages.txt)
а если использовать как сейчас? относительно папки cache
просто этот же вторичный кэш (можно)нужно использовать и как первичный, приналичии правильного zmp
или ввести в ГУИ установку альтернативной папки
>10. Если вторичное хранилище допускает запись в него, то для записи
>используется первое (с учётом приоритета) доступное вторичное хранилище.
а что должно помешать записи в первичное хранилище? |
|
|
|
|
>опрос для записи начинается с первичного или со вторичного?
Первичное всегда имеет наивысший приоритет. С первичного.
>Если первичное поддерживает запись, то будет ли запись в остальные?
Возможно и будет, а возможно и нет.
Например если установлены параметры 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
|
|
11-05-2012 07:02
|
|
>>а что должно помешать записи в первичное хранилище?
> Флаги типа Usesave=0 или установка Version.
ну по дефолту запись в первичное(основное) должна быть включена. |
|
|
|
(0006940)
|
|
vasketsov
|
11-05-2012 07:07
(edited on: 11-05-2012 07:08) |
|
>по дефолту запись в первичное(основное) должна быть включена
Несомненно. Если флагов нет - в первичное пишем, в остальные не пишем.
>Первичное всегда имеет наивысший приоритет. С первичного
Походу я погорячился. Вот как надо:
Если
а) для карты установлена Version и указано хотя бы одно вторичное с Version
либо
б) хотя бы одно вторичное с Zoom
тогда такие вторичные обрабатываются перед первичным.
В изначальной постановке (резервный архив только для чтения) таких вторичных не будет, так что ничего не отъедет.
|
|
|
|
(0006941)
|
|
Garl
|
|
11-05-2012 07:09
|
|
а объясните на пальцах про version
как оно работает сейчас? или это поле ещё не задействовано |
|
|
|
(0006947)
|
|
vasketsov
|
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). В общей постановке задачи никаких ограничений на выбор типов для любых хранилищ (первичного или вторичных) не накладывается.
|
|
|
|
|
Да, думаю если есть хранилища с разрешенной записью и поддерживающие version, то надо попытаться сначала записать в них (по порядку сцепления). Если такие кончились и не записалось, то обычным порядком с первичного и далее.
Аналогично и с записью TNE.
Ещё про version. Я согласен с Демидовым что хранилище не должно возвращать версию если оно её не сохранило. И возвращать запрошенную тоже не должно! Пусть возвращает или 0 или -1 или ещё какую константу (типа cUnknownVersion, определенную снаружи), недопустимую для версии. Это про неподдерживающие версии хранилища.
|
|
|
|
|
>недопустимую для версии
Для версии допустимо всё кроме пустой строки. В смысле интерфейса - теоретически можно вернуть NIL. Но сути это не меняет. Версия - произвольная строка. |
|