View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001255 | SAS.Планета | Хотелка / Feature request | public | 29-03-2012 17:00 | 20-04-2020 21:23 |
| Reporter | Dima2000 | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | confirmed | Resolution | reopened | ||
| Platform | Windows | OS | XP | OS Version | Professional SP3 |
| Product Version | 131111 | ||||
| Target Version | 45xxxx | ||||
| Summary | 0001255: Добавить режим "Интернет без записи в кэш". | ||||
| Description | Хочется быстрого включения/выключения обновления кэша, даже при работе с интернетом в качестве одного из источников. В документаци не видел, что кэш обновляется всегда. Может это и подразумевается, но иногда это лишнее, обновление кэша, чтобы его не захламлять случайными данными. С отключенным обновлением кэша тайлы будут кэшироваться лишь в памяти, не на диске. Для малых сдвигов карты памяти достаточно. И плевать на траффик! Сейчас вообще не понимаю как без временной модификации zmp запретить обновление кэша при просмотре тайлов с интернета. Ну не создавать же два zmp на каждую карту и слой с общим кэшем с запретом в одном его обновлять ... Хотя как заплатка этот выход и сойдёт. В таком режиме с запрещённым обновлением кэша удобно визуально проверять есть ли на сервере снимки нужного разрешения. Или работать в "бездисковой" конфигурации, только по сети. Да и не только. | ||||
| Tags | No tags attached. | ||||
| related to | 0001586 | confirmed | Сделать раздельные режимы для основной карты и слоёв | |
| parent of | 0001200 | resolved | zed | Добавить кэширование тайлов на уровне тайлохранилища |
| parent of | 0002333 | confirmed | Добавить нотифаеры в качалку видимой области | |
| has duplicate | 0003279 | closed | zed | Не сохранять загруженные тайлы в папке кэша, если в качестве источника выбран только интернет |
| Not all the children of this issue are yet resolved or closed. | ||||
|
|
Перечитал раз 5, пока понял, о чём речь. Короче, автор хочет режим "Интернет без записи в кэш". Мне кажется, это не нужно, если кому нужно - отпишитесь. |
|
|
>В таком режиме с запрещённым обновлением кэша удобно визуально проверять есть ли на сервере снимки нужного разрешения Вы делаете мне смешно. Проверяем наличие папки - папки нет. Итого - и карта заполнения не работает, и при случае внутренний кэш раком встаёт. Если надо именно обновления - надо "просто" добавить опцию (ну или режим), чтобы режим "Интернет" не качал тайлы, если они уже есть в кэше и их даты попадают в настраиваемый диапазон дат. Диапазон дат в сасе уже есть. Ставим нижнюю в сегодня, верхнюю в 2099 - и понеслась. А чтобы случайное не попадало - тут надо либо отдельную папку с кэшем делать и убивать его потом, либо просить реализацию UNDO\REDO для замены тайлов. |
|
|
Вообще-то нужно. Например, есть оч.хороший кэш. Вышло обновление снимков, они, как это часто бывает, стали хуже. Кэш испорчен :( |
|
|
vasketsov, извините, вы не о том. Если есть хоть один тайл нужного зума, то папка зума на диске уже будет - это не признак отсутствия тайлов нужного зума в данной области. Или Вы предлагаете руками искать папку по тайловым координатам?! Я просил именно галку запрета обновления кэша. И всё. Кэшировать скачанные тайлы лишь в памяти, без записи в кэш на диск. Как раз чтобы не портить хороший кэш случайными тайлами. Можно будет сначала проверить что сервер отдаёт, а потом уже обновлять в кэше. |
|
|
>Если есть хоть один тайл нужного зума, то папка зума на диске уже будет Это несколько расходится с "удобно визуально проверять есть ли на сервере снимки нужного разрешения". |
|
|
Эх, ну неужели непонятно, положим есть 500 городов в z19 и при этом 99% площади мира пусто. Папка z19 на диске есть, как по ней определить есть ли снимки 501-го города в z19? Да, по тайловым координатам можно, но это мазохизм. Да и речь вообще о другом. Не о папке в кэше, а о запрете его обновления при просмотре карты исключительно с сервера. Ну вот не хочу я его захламлять! Меня волнует наличие (и качество!) тайлов вовсе не в кэше, а на сервере. И хочу это проверять БЕЗ обновления кэша. |
|
|
>ну неужели непонятно Чем точнее описана проблема, тем больше шансов быть понятым. А текст типа процитированного как раз сбивает с генеральной линии партии. |
|
|
Извините. Мне казалось Tolik кратко и ясно выразил моё желание и вариант использования. |
|
|
что то я не пойму: а что мешает поменять путьк кэшу в настройках, и закачав туда новых тайлов понять нужны они вам или нет... |
|
|
Хм, до этого не додумался. Но так тоже неудобно, хотя и затрудняюсь объяснить чем, галка гораздо удобнее. |
|
|
Меня давно смущает то, что режим "Интернет" пишет тайлы в кэш. При живом "Интернет+кэш" это выглядит непонятно. |
|
|
У меня появилась идея, как такой режим можно реализовать. Причём, довольно легко. 1. Доделать кэширование в памяти для тайлового кэша 0001200 2. В конфиг хранилища добавить опцию RAM-Only, при включении которой, хранилище не должно записывать тайлы на диск, а только держать их "в уме" 3. Добавить режим "Интернет + RAM", при включении которого, все карты должны установить флаг RAM-Only у своих хранилищ и не сохранять тайлы на диск. Просьбы о четвёртом режиме не использующем кэш на диске возникают постоянно, так что думаю, можно заняться. |
|
|
Тогда нужно этот кэш реализовывать непосредственно в TTileStorageOfMapType и перестать передавать его в само тайлохранилище. |
|
|
Это усложнит доработку, к тому же я сейчас не уверен, что вообще из тайлохранилищ можно безболезненно удалить кэширование. Поэтому предложу оставить вопрос с TTileStorageOfMapType до лучших времён, когда четвёртый режим уже будет работать. |
|
|
То есть ты предпочитаешь в пяти разных классах тайлохранилищ реализовывать обработку опции RAM-Only плюс в несколько классов вообще добавлять использование кэширования, а не реализовать это в одном месте и больше не возвращаться к этому? Странная логика. |
|
|
Ты вначале посмотри, реально ли перетянуть всё необходимое в TTileStorageOfMapType. Нотифаеры там, сбор информации о выделенной области и список версий. А то может оказаться, что станет невозможно использовать stand-along хранилища, как это сейчас делается в конвертере кэша. > плюс в несколько классов вообще добавлять использование кэширования На самом деле, только в один класс - тайловое хранилище. У остальных с этим уже давно всё в порядке. |
|
|
Хм, а можно пойти по иному пути: в TTileStorageOfMapType завести переменную FMemStorage: ITileStorage, которую инициализировать классом TTileStorageInRAM и использовать вместо реального хранилища, когда установлен флаг RAM-Only. Таким образом и дорабатывать тайловое хранилище не нужно и все готовые методы у нас будут, с нотифаером и прочими проверками. Этот вариант мне кажется будет оптимальным. По-крайней мере, кодить надо меньше и не нужно лезть в 5 классов и чего-то там вкорячивать. |
|
|
Вот это уже умная мысль :) |
|
|
Я тут подумал, и мне кажется, что это реализовывать до того как сделать ITileStorageChangeable не стоит. Представляешь ты включил закачку области и думаешь, что оно сохраняет в кэш, а потом переключил режим кэша и она стала вместо тайлохранилища сбрасывать только в RAM и сразу же затирать скачанное. Да и с остальными операциями будет странно смотреться. |
|
|
А я тут подумал, и мне кажется, что нужно заводить отдельное хранилище в MapType или вообще где-нибудь в глобале одно для всех карт сразу, и использовать его только для работы с гуи, когда включён четвёртый режим. Иначе будут глюки при операциях с выделенной областью и Changeable тут не спасёт. |
|
|
Ну, смотри, я все еще считаю что с этим четвертым режимом столько мороки, что овчинка выделки не стоит. И лучше если будешь что-то делать в этом направлении, то в отдельной ветке, а там посмотрим что получается. |
|
|
Что-то я не вижу способов относительно просто реализовать это не получив чудес. |
|
|
Да, оказывается всё немного сложнее. Как я понимаю, тот код что занимается отображением тайлов (кстати, в каком конкретно юните он живёт?), работает не с хранилищем, а с MapType (юзает методы LoadBitmap). Соответственно, помимо дополнительного стореджа для качалки, нам нужно передавать доп. флаг в методы загрузки битмапки (для отображения) по которому карта будет ходить в то или иное хранилище. Если всё так, то дополнительное хранилище нужно делать глобальным и единственным для всех карт (и очевидно, что существующий RAM кэш для этих целей не подходит) и передавать его в MapType как внешнее хранилище, в которое карта должна ходить, если ей передан спец. флаг в LoadBitmap или где оно там ещё понадобится. |
|
|
> Как я понимаю, тот код что занимается отображением тайлов (кстати, в каком конкретно юните он живёт?), работает не с хранилищем, а с MapType (юзает методы LoadBitmap). Правильно понимаешь. И мне это уже давно не нравится. Нужно выковыривать этот код в отдельные IBitmapLayerProvider получающие тайлохранилище, кэш и тд. Но все руки не доходят. |
| 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 | |
| 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 => 45xxxx |
| 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 |
| 08-08-2025 13:24 | zed | Category | Хотелка => Хотелка / Feature request |