SASGIS - SAS.Планета
View Issue Details
0001290SAS.Планета[All Projects] Хотелкаpublic05-05-2012 10:2409-10-2015 07:15
Dima2000 
 
normalfeatureN/A
confirmedopen 
WindowsXPProfessional SP3
110418 
50xxxx 
0001290: Поддержка вторичного read-only кэша (например, в формате SAS4WinCE)
Сделать тайловое хранилище, чтобы при отсутствии тайла на диске он искался в этом пакованом кэше? Можно будет постоянные области закачать, экспортнуть и пусть себе лежат большими файлами. А если появились новые снимки, то они будут лежать как обычно и дополнять пакованный кэш. И если вдруг какая ошибка в пакованном кэше, то всегда её можно замаскировать перезакачкой новых тайлов. У v_max между прочим именно так и работает, на жалкой WinCE! Значит много ресурсов на это дело не надо.
> Вы предлагаете более продвинутую фичу - чтение из дополнительного кэша при остутствии тайла в основном. То есть если нет в 1-м кэше, смотрим в 2-й, если там есть - выводим на экран.
Именно так.
И я готов написать всё необходимое, только встраивайте.

Обсуждение здесь: 0001285:0006681
SAS4WinCE, кэш, тайлохранилище
related to 0001291confirmed  Поддержка кэша SAS4WinCE 
related to 0002392closed vdemidov Использование 2-го (альтернативного) пути кэша 
Issue History
05-05-2012 10:24Dima2000New Issue
05-05-2012 10:32vasketsovNote Added: 0006693
05-05-2012 10:36TolikNote Added: 0006695
05-05-2012 10:37GarlNote Added: 0006697
05-05-2012 10:39GarlNote Added: 0006698
05-05-2012 10:43TolikNote Added: 0006701
05-05-2012 10:44TolikNote Edited: 0006701bug_revision_view_page.php?bugnote_id=6701#r3280
05-05-2012 10:45TolikNote Edited: 0006701bug_revision_view_page.php?bugnote_id=6701#r3281
05-05-2012 10:49TolikStatusnew => acknowledged
05-05-2012 10:49TolikSummaryПоддержка кэша в формате SAS4WinCE в качестве второго хранилища => Поддержка вторичного read-only кэша (например, в формате SAS4WinCE)
05-05-2012 10:50TolikNote Edited: 0006695bug_revision_view_page.php?bugnote_id=6695#r3283
05-05-2012 10:53TolikAdditional Information Updatedbug_revision_view_page.php?rev_id=3287#r3287
05-05-2012 10:53vasketsovNote Added: 0006702
05-05-2012 10:54Dima2000Note Added: 0006703
05-05-2012 10:56Dima2000Note Added: 0006704
05-05-2012 10:57TolikNote Added: 0006705
05-05-2012 10:58TolikNote Edited: 0006705bug_revision_view_page.php?bugnote_id=6705#r3289
05-05-2012 10:58TolikNote Edited: 0006705bug_revision_view_page.php?bugnote_id=6705#r3290
05-05-2012 10:59GarlNote Added: 0006706
05-05-2012 11:00TolikNote Added: 0006708
05-05-2012 11:01GarlNote Added: 0006709
05-05-2012 11:07TolikNote Added: 0006710
05-05-2012 11:07vasketsovNote Added: 0006711
05-05-2012 11:11PapazolNote Added: 0006712
05-05-2012 11:14vasketsovNote Added: 0006714
05-05-2012 11:15GarlNote Added: 0006715
05-05-2012 11:17vasketsovNote Edited: 0006714bug_revision_view_page.php?bugnote_id=6714#r3292
05-05-2012 11:18TolikNote Added: 0006716
05-05-2012 11:18GarlNote Added: 0006717
05-05-2012 11:19TolikNote Edited: 0006716bug_revision_view_page.php?bugnote_id=6716#r3294
05-05-2012 11:20TolikNote Added: 0006718
05-05-2012 11:20GarlNote Added: 0006719
05-05-2012 11:21GarlNote Added: 0006720
05-05-2012 11:22TolikNote Added: 0006721
05-05-2012 11:23TolikNote Added: 0006722
05-05-2012 11:26vasketsovNote Added: 0006723
05-05-2012 11:28GarlNote Added: 0006724
05-05-2012 11:29vasketsovNote Edited: 0006723bug_revision_view_page.php?bugnote_id=6723#r3296
05-05-2012 11:30Dima2000Note Added: 0006725
05-05-2012 11:31GarlNote Added: 0006726
05-05-2012 11:36TolikNote Added: 0006727
05-05-2012 11:36GarlNote Added: 0006728
05-05-2012 11:37Dima2000Note Added: 0006729
05-05-2012 11:37GarlNote Added: 0006730
05-05-2012 11:38TolikNote Added: 0006731
05-05-2012 11:38GarlNote Added: 0006732
05-05-2012 11:38vasketsovNote Added: 0006733
05-05-2012 11:39vasketsovNote Edited: 0006733bug_revision_view_page.php?bugnote_id=6733#r3298
05-05-2012 11:42TolikNote Added: 0006735
05-05-2012 11:42GarlNote Added: 0006736
05-05-2012 11:43TolikNote Edited: 0006731bug_revision_view_page.php?bugnote_id=6731#r3300
05-05-2012 11:43vasketsovNote Edited: 0006733bug_revision_view_page.php?bugnote_id=6733#r3301
05-05-2012 11:48vasketsovNote Added: 0006739
05-05-2012 11:50TolikNote Added: 0006741
05-05-2012 11:51Dima2000Note Added: 0006742
05-05-2012 11:53Dima2000Note Edited: 0006742bug_revision_view_page.php?bugnote_id=6742#r3303
05-05-2012 11:53TolikNote Added: 0006744
05-05-2012 12:02vasketsovNote Added: 0006747
05-05-2012 12:04GarlNote Added: 0006748
05-05-2012 12:04TolikNote Added: 0006749
05-05-2012 12:06GarlNote Added: 0006750
05-05-2012 12:12vasketsovNote Added: 0006753
05-05-2012 12:13vasketsovNote Edited: 0006753bug_revision_view_page.php?bugnote_id=6753#r3305
05-05-2012 12:15Dima2000Note Added: 0006754
05-05-2012 12:21vasketsovNote Added: 0006758
05-05-2012 12:28Dima2000Note Added: 0006760
05-05-2012 12:39GarlNote Added: 0006761
05-05-2012 12:39Dima2000Note Edited: 0006760bug_revision_view_page.php?bugnote_id=6760#r3311
05-05-2012 12:42vasketsovNote Added: 0006763
05-05-2012 12:45Dima2000Note Added: 0006764
05-05-2012 12:51Dima2000Note Added: 0006765
05-05-2012 12:55GarlNote Added: 0006766
05-05-2012 12:55GarlNote Edited: 0006766bug_revision_view_page.php?bugnote_id=6766#r3313
05-05-2012 12:55vasketsovNote Added: 0006767
05-05-2012 13:03vasketsovNote Added: 0006769
05-05-2012 13:04vasketsovNote Edited: 0006769bug_revision_view_page.php?bugnote_id=6769#r3315
05-05-2012 13:04Dima2000Note Added: 0006770
05-05-2012 13:07Dima2000Note Added: 0006771
05-05-2012 13:32Dima2000Note Edited: 0006771bug_revision_view_page.php?bugnote_id=6771#r3317
05-05-2012 18:12TolikNote Added: 0006794
05-05-2012 18:21vasketsovNote Added: 0006798
06-05-2012 04:22GarlNote Added: 0006821
06-05-2012 06:08TolikNote Added: 0006822
06-05-2012 06:19zedNote Added: 0006824
10-05-2012 21:38vasketsovNote Added: 0006934
10-05-2012 21:53Dima2000Note Added: 0006935
11-05-2012 04:11GarlNote Added: 0006936
11-05-2012 06:51vasketsovNote Added: 0006938
11-05-2012 07:02GarlNote Added: 0006939
11-05-2012 07:07vasketsovNote Added: 0006940
11-05-2012 07:08vasketsovNote Edited: 0006940bug_revision_view_page.php?bugnote_id=6940#r3411
11-05-2012 07:09GarlNote Added: 0006941
11-05-2012 08:18vasketsovNote Added: 0006947
11-05-2012 08:20vasketsovNote Edited: 0006947bug_revision_view_page.php?bugnote_id=6947#r3415
11-05-2012 08:21vasketsovNote Edited: 0006947bug_revision_view_page.php?bugnote_id=6947#r3416
11-05-2012 12:03Dima2000Note Added: 0006959
11-05-2012 12:03Dima2000Note Edited: 0006959bug_revision_view_page.php?bugnote_id=6959#r3429
12-05-2012 20:55vasketsovNote Added: 0007002
13-05-2012 09:01gpsMaxTag Attached: SAS4WinCE
22-06-2012 07:25vasketsovAssigned To => vasketsov
22-06-2012 07:25vasketsovStatusacknowledged => assigned
24-06-2012 10:58Dima2000Relationship addedrelated to 0001291
30-03-2014 17:13zedRelationship addedrelated to 0002392
30-03-2014 17:17zedTag Attached: кэш
31-03-2014 09:18vdemidovAssigned Tovasketsov =>
31-03-2014 09:18vdemidovStatusassigned => confirmed
31-03-2014 09:18vdemidovTarget Version => 50xxxx
09-10-2015 07:15vdemidovTag Attached: тайлохранилище
13-07-2019 14:30RIXXXIssue cloned: 0003497

Notes
(0006693)
vasketsov   
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   
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.

(0006702)
vasketsov   
05-05-2012 10:53   
Итак если предположить существование типа кэша для SAS4WinCE и подключения его как вторичного только для чтения:

>Если стоит режим интернет+кэш, тайла нету в текущем кэше, зато он есть в запакованом
Значит тайл есть (решение о наличии принимается по сей совокупности используемых хранилищ исходя из обобщённых координат тайла {x,y,z,v}). Его и показываем.

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

>Нашёл нечто похожее: 0000392
Ну и? Предложили ждать. Помнится плагины ждут уже года два, если не три.

>вопрос
Если тайл есть в основном - берём оттуда. Если нет, но есть во втором - берём оттуда. Если нет вообще - кирдык. Вообще, поведение не должно отличаться от текущего, только факт наличия тайла проверяется не одним битом (первым хранилищем), а двумя (первое OR второе). А вот сохраняется скачанный тайл в первое, и это логично.
TNE файлы можно хранить как во втором (SAS4WinCE) хранилище (зачем?), так и в основном. И удалять из основного если тайл появился. Из второго они мешать не будут - тайл обнаружится в основном и второе спрашиваться не будет вообще.
(0006704)
Dima2000   
05-05-2012 10:56   
Да, согласен с 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 еще и по идеологическим соображениям: вот есть хороший кэш, скачанный с любовью :) , скопированныый на все компьютеры и розданный друзьям, его портить нельзя.
(0006711)
vasketsov   
05-05-2012 11:07   
>не входят в дистрибутив и поставляются отдельно
Так точно. На то есть основания. Если поискать тут тему - там и DLL найдутся (без исходников). Весь API есть в репозитории саса (открыт). Если надо добавления к нему - надо обсуждать в теме про новое хранилище.

>наследовать всю кучу методов из u_TileStorageAbstract
Там их примерно штук 5 всего.

>мне не нравится
Неверный ответ. Если что-то надо сделать - надо разбираться и делать. Идей у всех полно. А нужна реализация.

>зачем больше я пока не знаю
Я уже приводил пример. Размер кэша Google Earth 2 гига. В реальности если грузить по границам снимков - сильно меньше. Если выгружать участки по снимкам за даты и складывать отдельно, а потом прицепить их как вторичные - получится самый быстрый версионный кэш из ныне доступных для саса, с мгновенным построением карты заполнения (время построения карты заполнения не зависит от разницы зумов).

>хранилища в dll я ещё поизучаю
Зачем? Может без DLL проще? Есть же фактически метод записи в хранилище (экспорт), надо только чтение сделать. Чего ради конкретно в DLL прятать? Хранилище в DLL априори сложнее в реализации. Например там чтобы не колупаться с диспетчерами памяти, есть лишние извращения, которые в простом случае просто не нужны.
(0006712)
Papazol   
05-05-2012 11:11   
Если в качестве источника тайлов присутствует Интернет, то всё должно происходить как раньше, то есть альтернативный кэш должен быть просто отключен. Иначе возможны ситуации, неподконтрольные пользователю.
В конце концов, альтернативный кэш создаётся из основного, и он может быть пересоздан в случае добавления новых снимков и т. п. Лишь в случаях, когда упаковываются неизменные данные, есть смысл удалить исходный кэш, а в случаях 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
(0006725)
Dima2000   
05-05-2012 11:30   
Я только "за" без 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 интересный.
(0006729)
Dima2000   
05-05-2012 11:37   
>проекция у нас от 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
(0006739)
vasketsov   
05-05-2012 11:48   
>Ну и что, что 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   
> Для начала - без пути, пусть пока файлы лежат в папке карты.
Не так. Пусть пока файлы лежат в той папке, которая прописана в параметрах программы - путь к кэшу.
(0006747)
vasketsov   
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   
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 не заливается в репо.

(0006754)
Dima2000   
05-05-2012 12:15   
>Пусть пока файлы лежат в той папке, которая прописана в параметрах программы - путь к кэшу.
Конечно, я не так выразился, извините. Для меня папка карты - это не zmp, а папка в кэше. :)

>Это подключение хранилища к карте.
Именно. И вообще речь не про карты идёт, а про кэш. Который настраивается в параметрах программы (а не карты!) и хранится в SASPlanet.ini. А уж какие карты в этом формате кэша хранить - дело пользователя.

>в тоже время это хранилище вполне может выступать самостоятельным кэшем
Ну так укажете его первичным и всё.

>zmp, т.к. он у меня совпадает с репозиторием
Именно, так и должно быть по идее.
(0006758)
vasketsov   
05-05-2012 12:21   
>Который настраивается в параметрах программы (а не карты!) и хранится в 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   
ИМХО: или универсально или никак :( сори
(0006763)
vasketsov   
05-05-2012 12:42   
>на уровень хранилища, без привязки к картам
Не врубаешься.

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

Погляди на указание относительных путей для кэшей гугла и яндекса, они на одном типе кэша сделаны, но в разных хранилищах. А потом попробуй в NameInCache указать полный путь типа C:\caches\mygoogle - общие настройки проигнорируются.

Некоторые типы кэша вообще не требуют указание общих настроек. Например для кэша GE можно оставить путь пустым, и указать его только в свойствах карты в поле NameInCache (или наоборот кстати).
(0006764)
Dima2000   
05-05-2012 12:45   
Жаль.
Отдельный zmp (с поддерживающей его dll) написать не проблема, но кому оно надо, лишь просмотр без докачки и обновления? Через экспорт это не то. Имхо такой вариант не нужен вообще. Нужно именно сцепление хранилищ в цепочку, с приоритетами.
(0006765)
Dima2000   
05-05-2012 12:51   
Про настройки более-менее понятно, непонятно почему смешиваются понятия карты и хранилища. Это же разные сущности. Первая описывает откуда что и как качать и как показывать, а вторая лишь хранит бинарные данные по ключу (координаты). Ни та ни другая в общем-то не должны и знать друг о друге. Я не про настройки путей в ГУИ, а про внутренности. Что есть много разынх вариантов настроек - хорошо, я за.
(0006766)
Garl   
05-05-2012 12:55   
разобъём это дело на 2 части:
1 научить планету читать и выводить тайлы из кэша \cache\<путь>\.d**
2 каким то образом подвязать к одному GUID карты другие GUID

(0006767)
vasketsov   
05-05-2012 12:55   
>Нужно именно сцепление хранилищ в цепочку
Оно и будет. Ты просто пока не разобрался.

>Отдельный 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). Минусы?

(0006770)
Dima2000   
05-05-2012 13:04   
>Не нравится кэш 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-й кэш через ГУИ тогда не будет?
(0006798)
vasketsov   
05-05-2012 18:21   
>через ГУИ тогда не будет?
Она появится как только кто-нибудь её сделает.
(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 прописывается.
(0006934)
vasketsov   
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   
10-05-2012 21:53   
П.10, опрос для записи начинается с первичного или со вторичного? Если первичное поддерживает запись, то будет ли запись в остальные?
Я как бы за запись в первое подходящее хранилище, начиная с первичного.

Ещё. При чтении тайла хранилища опрашиваются подряд начиная с первичного до нахождения тайла или .tne?

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

или ввести в ГУИ установку альтернативной папки


>10. Если вторичное хранилище допускает запись в него, то для записи
>используется первое (с учётом приоритета) доступное вторичное хранилище.
а что должно помешать записи в первичное хранилище?
(0006938)
vasketsov   
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   
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). В общей постановке задачи никаких ограничений на выбор типов для любых хранилищ (первичного или вторичных) не накладывается.

(0006959)
Dima2000   
11-05-2012 12:03   
Да, думаю если есть хранилища с разрешенной записью и поддерживающие version, то надо попытаться сначала записать в них (по порядку сцепления). Если такие кончились и не записалось, то обычным порядком с первичного и далее.
Аналогично и с записью TNE.

Ещё про version. Я согласен с Демидовым что хранилище не должно возвращать версию если оно её не сохранило. И возвращать запрошенную тоже не должно! Пусть возвращает или 0 или -1 или ещё какую константу (типа cUnknownVersion, определенную снаружи), недопустимую для версии. Это про неподдерживающие версии хранилища.

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