0001255: Добавить режим "Интернет без записи в кэш".

Notes
(0006341) Tolik (manager) 30-03-2012 05:17	Перечитал раз 5, пока понял, о чём речь. Короче, автор хочет режим "Интернет без записи в кэш". Мне кажется, это не нужно, если кому нужно - отпишитесь.

(0006342) vasketsov (manager) 30-03-2012 06:22 edited on: 30-03-2012 06:23	>В таком режиме с запрещённым обновлением кэша удобно визуально проверять есть ли на сервере снимки нужного разрешения Вы делаете мне смешно. Проверяем наличие папки - папки нет. Итого - и карта заполнения не работает, и при случае внутренний кэш раком встаёт. Если надо именно обновления - надо "просто" добавить опцию (ну или режим), чтобы режим "Интернет" не качал тайлы, если они уже есть в кэше и их даты попадают в настраиваемый диапазон дат. Диапазон дат в сасе уже есть. Ставим нижнюю в сегодня, верхнюю в 2099 - и понеслась. А чтобы случайное не попадало - тут надо либо отдельную папку с кэшем делать и убивать его потом, либо просить реализацию UNDO\REDO для замены тайлов.

(0006343) Tolik (manager) 30-03-2012 06:49	Вообще-то нужно. Например, есть оч.хороший кэш. Вышло обновление снимков, они, как это часто бывает, стали хуже. Кэш испорчен :(

(0006345) Dima2000 (developer) 30-03-2012 15:12	vasketsov, извините, вы не о том. Если есть хоть один тайл нужного зума, то папка зума на диске уже будет - это не признак отсутствия тайлов нужного зума в данной области. Или Вы предлагаете руками искать папку по тайловым координатам?! Я просил именно галку запрета обновления кэша. И всё. Кэшировать скачанные тайлы лишь в памяти, без записи в кэш на диск. Как раз чтобы не портить хороший кэш случайными тайлами. Можно будет сначала проверить что сервер отдаёт, а потом уже обновлять в кэше.

(0006351) vasketsov (manager) 30-03-2012 19:25	>Если есть хоть один тайл нужного зума, то папка зума на диске уже будет Это несколько расходится с "удобно визуально проверять есть ли на сервере снимки нужного разрешения".

(0006353) Dima2000 (developer) 30-03-2012 19:41	Эх, ну неужели непонятно, положим есть 500 городов в z19 и при этом 99% площади мира пусто. Папка z19 на диске есть, как по ней определить есть ли снимки 501-го города в z19? Да, по тайловым координатам можно, но это мазохизм. Да и речь вообще о другом. Не о папке в кэше, а о запрете его обновления при просмотре карты исключительно с сервера. Ну вот не хочу я его захламлять! Меня волнует наличие (и качество!) тайлов вовсе не в кэше, а на сервере. И хочу это проверять БЕЗ обновления кэша.

(0006354) vasketsov (manager) 30-03-2012 19:48	>ну неужели непонятно Чем точнее описана проблема, тем больше шансов быть понятым. А текст типа процитированного как раз сбивает с генеральной линии партии.

(0006356) Dima2000 (developer) 30-03-2012 19:57	Извините. Мне казалось Tolik кратко и ясно выразил моё желание и вариант использования.

(0006357) Garl (manager) 31-03-2012 04:54	что то я не пойму: а что мешает поменять путьк кэшу в настройках, и закачав туда новых тайлов понять нужны они вам или нет...

(0006358) Dima2000 (developer) 31-03-2012 12:46	Хм, до этого не додумался. Но так тоже неудобно, хотя и затрудняюсь объяснить чем, галка гораздо удобнее.

(0007015) gpsMax (manager) 13-05-2012 11:25	Меня давно смущает то, что режим "Интернет" пишет тайлы в кэш. При живом "Интернет+кэш" это выглядит непонятно.

(0013790) zed (manager) 13-02-2014 16:52	У меня появилась идея, как такой режим можно реализовать. Причём, довольно легко. 1. Доделать кэширование в памяти для тайлового кэша 0001200 2. В конфиг хранилища добавить опцию RAM-Only, при включении которой, хранилище не должно записывать тайлы на диск, а только держать их "в уме" 3. Добавить режим "Интернет + RAM", при включении которого, все карты должны установить флаг RAM-Only у своих хранилищ и не сохранять тайлы на диск. Просьбы о четвёртом режиме не использующем кэш на диске возникают постоянно, так что думаю, можно заняться.

(0013791) vdemidov (manager) 13-02-2014 18:21	Тогда нужно этот кэш реализовывать непосредственно в TTileStorageOfMapType и перестать передавать его в само тайлохранилище.

(0013792) zed (manager) 13-02-2014 18:57	Это усложнит доработку, к тому же я сейчас не уверен, что вообще из тайлохранилищ можно безболезненно удалить кэширование. Поэтому предложу оставить вопрос с TTileStorageOfMapType до лучших времён, когда четвёртый режим уже будет работать.

(0013793) vdemidov (manager) 13-02-2014 19:36	То есть ты предпочитаешь в пяти разных классах тайлохранилищ реализовывать обработку опции RAM-Only плюс в несколько классов вообще добавлять использование кэширования, а не реализовать это в одном месте и больше не возвращаться к этому? Странная логика.

(0013794) zed (manager) 13-02-2014 20:06	Ты вначале посмотри, реально ли перетянуть всё необходимое в TTileStorageOfMapType. Нотифаеры там, сбор информации о выделенной области и список версий. А то может оказаться, что станет невозможно использовать stand-along хранилища, как это сейчас делается в конвертере кэша. > плюс в несколько классов вообще добавлять использование кэширования На самом деле, только в один класс - тайловое хранилище. У остальных с этим уже давно всё в порядке.

(0013795) zed (manager) 13-02-2014 20:36	Хм, а можно пойти по иному пути: в TTileStorageOfMapType завести переменную FMemStorage: ITileStorage, которую инициализировать классом TTileStorageInRAM и использовать вместо реального хранилища, когда установлен флаг RAM-Only. Таким образом и дорабатывать тайловое хранилище не нужно и все готовые методы у нас будут, с нотифаером и прочими проверками. Этот вариант мне кажется будет оптимальным. По-крайней мере, кодить надо меньше и не нужно лезть в 5 классов и чего-то там вкорячивать.

(0013796) vdemidov (manager) 13-02-2014 21:09	Вот это уже умная мысль :)

(0013797) vdemidov (manager) 14-02-2014 07:37	Я тут подумал, и мне кажется, что это реализовывать до того как сделать ITileStorageChangeable не стоит. Представляешь ты включил закачку области и думаешь, что оно сохраняет в кэш, а потом переключил режим кэша и она стала вместо тайлохранилища сбрасывать только в RAM и сразу же затирать скачанное. Да и с остальными операциями будет странно смотреться.

(0013798) zed (manager) 14-02-2014 08:01	А я тут подумал, и мне кажется, что нужно заводить отдельное хранилище в MapType или вообще где-нибудь в глобале одно для всех карт сразу, и использовать его только для работы с гуи, когда включён четвёртый режим. Иначе будут глюки при операциях с выделенной областью и Changeable тут не спасёт.

(0013799) vdemidov (manager) 14-02-2014 08:26	Ну, смотри, я все еще считаю что с этим четвертым режимом столько мороки, что овчинка выделки не стоит. И лучше если будешь что-то делать в этом направлении, то в отдельной ветке, а там посмотрим что получается.

(0013801) vdemidov (manager) 17-02-2014 10:48	Что-то я не вижу способов относительно просто реализовать это не получив чудес.

(0013802) zed (manager) 18-02-2014 10:08	Да, оказывается всё немного сложнее. Как я понимаю, тот код что занимается отображением тайлов (кстати, в каком конкретно юните он живёт?), работает не с хранилищем, а с MapType (юзает методы LoadBitmap). Соответственно, помимо дополнительного стореджа для качалки, нам нужно передавать доп. флаг в методы загрузки битмапки (для отображения) по которому карта будет ходить в то или иное хранилище. Если всё так, то дополнительное хранилище нужно делать глобальным и единственным для всех карт (и очевидно, что существующий RAM кэш для этих целей не подходит) и передавать его в MapType как внешнее хранилище, в которое карта должна ходить, если ей передан спец. флаг в LoadBitmap или где оно там ещё понадобится.

(0013803) vdemidov (manager) 18-02-2014 10:33	> Как я понимаю, тот код что занимается отображением тайлов (кстати, в каком конкретно юните он живёт?), работает не с хранилищем, а с MapType (юзает методы LoadBitmap). Правильно понимаешь. И мне это уже давно не нравится. Нужно выковыривать этот код в отдельные IBitmapLayerProvider получающие тайлохранилище, кэш и тд. Но все руки не доходят.

Users who viewed this issue
User List	Anonymous (3700x), k-dmitriy (4x), WWasily (2x), vdemidov (2x), ingener (2x), ramadnio (1x), netsky (1x), Alexander (1x), zed (1x)
Total Views	3714
Last View	23-11-2024 09:34

Issue History
Date Modified	Username	Field	Change
29-03-2012 17:00	Dima2000	New Issue
30-03-2012 05:17	Tolik	Note Added: 0006341
30-03-2012 06:22	vasketsov	Note Added: 0006342
30-03-2012 06:23	vasketsov	Note Edited: 0006342	View Revisions
30-03-2012 06:49	Tolik	Note Added: 0006343
30-03-2012 15:12	Dima2000	Note Added: 0006345
30-03-2012 19:25	vasketsov	Note Added: 0006351
30-03-2012 19:41	Dima2000	Note Added: 0006353
30-03-2012 19:48	vasketsov	Note Added: 0006354
30-03-2012 19:57	Dima2000	Note Added: 0006356
31-03-2012 03:44	Tolik	Status	new => acknowledged
31-03-2012 03:44	Tolik	Summary	Галку в меню источника 4-м пунктом для запрета обновления кэша => Добавить режим "Интернет без записи в кэш".
31-03-2012 04:54	Garl	Note Added: 0006357
31-03-2012 12:46	Dima2000	Note Added: 0006358
31-03-2012 13:55	vdemidov	Status	acknowledged => resolved
31-03-2012 13:55	vdemidov	Resolution	open => won't fix
31-03-2012 13:55	vdemidov	Assigned To	=> vdemidov
31-03-2012 13:55	vdemidov	Status	resolved => closed
13-05-2012 11:25	gpsMax	Note Added: 0007015
13-02-2014 16:52	zed	Note Added: 0013790
13-02-2014 16:53	zed	Assigned To	vdemidov =>
13-02-2014 16:53	zed	Status	closed => confirmed
13-02-2014 16:53	zed	Resolution	won't fix => reopened
13-02-2014 16:53	zed	Target Version	=> 140303
13-02-2014 16:54	zed	Relationship added	parent of 0001200
13-02-2014 16:56	zed	Relationship added	related to 0001586
13-02-2014 18:21	vdemidov	Note Added: 0013791
13-02-2014 18:57	zed	Note Added: 0013792
13-02-2014 19:36	vdemidov	Note Added: 0013793
13-02-2014 20:06	zed	Note Added: 0013794
13-02-2014 20:36	zed	Note Added: 0013795
13-02-2014 21:09	vdemidov	Note Added: 0013796
14-02-2014 07:37	vdemidov	Note Added: 0013797
14-02-2014 08:01	zed	Note Added: 0013798
14-02-2014 08:26	vdemidov	Note Added: 0013799
17-02-2014 10:48	vdemidov	Note Added: 0013801
17-02-2014 10:49	vdemidov	Relationship added	parent of 0002333
17-02-2014 10:49	vdemidov	Product Version	.Nightly => 131111
17-02-2014 10:49	vdemidov	Target Version	140303 => 40xxxx
18-02-2014 10:08	zed	Note Added: 0013802
18-02-2014 10:33	vdemidov	Note Added: 0013803
30-09-2017 15:32	zed	Relationship added	has duplicate 0003279

SASGIS