SASGIS - SACS.Планета |
View Issue Details |
|
ID | Project | Category | View Status | Date Submitted | Last Update |
0001709 | SACS.Планета | [All Projects] Хотелка / Feature request | public | 26-11-2012 19:05 | 09-08-2013 15:13 |
|
Reporter | vasketsov | |
Assigned To | vasketsov | |
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | closed | Resolution | fixed | |
Platform | Windows | OS | Vista | OS Version | Ultimate |
Product Version | | |
Target Version | | Fixed in Version | 130803 | |
|
Summary | 0001709: Возможность заменять версию тайлов при конвертировании кэша в хранилище с поддержкой версий |
Description | Задача номер раз: Необходимо иметь возможность при конвертации кэша из исходного хранилища указать конкретную версию, которая будет использоваться при заливке тайлов в целевое версионное хранилище.
Обоснование необходимости замены версии весьма очевидно:
а) исходное хранилище может быть вообще без поддержки версий;
б) формат версии (строковый) может быть разным в разных хрнилищах, так как само по себе хранилище не накладывает никаких ограничений на значение версии (например для бинга можно в принципе указать версию как 1134, так и g1134).
Задача номер два: то же самое, но дополнительно работаем только в рамках текущего выделения.
Цель - залить кусками по областям выделения исходя из даты тайлов файловый кэш в БД. Номер версии бинга, гугла и т.п. я найду по логам checker-а новых версий. По крайней мер для некоторых важных снимков хотелось бы не единой помойкой их залить, а с номером версии.
Если я правильно понимаю логику менеджера кэша, он работает не по выделению, а по физически существующим тайлам в хранилище (если файлы сильно разрежены, это даёт выигрыш). Однако покуда полноценных версионных хранилищ не было, концепцию менеджера кэша в части поддержки версий можно (было) трактовать по-разному. Конвертируется кэш вообще всех версий в хранилище, или же только какой-то одной (без версии, если она пустая, покуда версия относилась только к скачке). Или же менеджер кэша принципиально неприменим при необходимости конвертации неверсионного кэша (пусть юзер даже и имеет верную информацию о версиях рядом) в версионный.
Вроде бы и можно в описанной задаче обойтись только копированием кэша (в смысле допиливания только диалога "Операции" -> "Скопировать" в виде новой галочки "Заменять версию на " + эдитки). Но надо заодно понять, вкорячивать ли заодно учёт версии в исходный и целевой кэши в менеджере версий. |
Steps To Reproduce | |
Additional Information | |
Tags | No tags attached. |
Relationships | related to | 0001966 | resolved | zed | SAS.Планета | В "Управлении кэшем" сделать возможным задавать версию для исходного и целевого кэшей |
|
Attached Files | |
|
Issue History |
Date Modified | Username | Field | Change |
26-11-2012 19:05 | vasketsov | New Issue | |
26-11-2012 19:07 | vasketsov | Description Updated | bug_revision_view_page.php?rev_id=4902#r4902 |
26-11-2012 19:09 | vasketsov | Description Updated | bug_revision_view_page.php?rev_id=4903#r4903 |
27-11-2012 12:25 | vasketsov | Note Added: 0010043 | |
27-11-2012 14:25 | vdemidov | Note Added: 0010044 | |
27-11-2012 15:04 | vasketsov | Note Added: 0010045 | |
27-11-2012 15:07 | vasketsov | Note Edited: 0010045 | bug_revision_view_page.php?bugnote_id=10045#r4911 |
28-11-2012 12:10 | Dima2000 | Note Added: 0010077 | |
05-12-2012 13:05 | vdemidov | Summary | Конвертирование кэша в новую версию => Возможность заменять версию тайлов при конвертировании кэша в хранилище с поддержкой версий |
10-12-2012 06:39 | vdemidov | Status | new => confirmed |
10-12-2012 06:40 | vdemidov | Product Version | .Nightly => 120808 |
10-12-2012 06:40 | vdemidov | Target Version | => 16xxxx |
30-06-2013 20:35 | vasketsov | Project | SAS.Планета => SACS.Планета |
30-06-2013 20:36 | vasketsov | Status | confirmed => resolved |
30-06-2013 20:36 | vasketsov | Fixed in Version | => .Nightly |
30-06-2013 20:36 | vasketsov | Resolution | open => fixed |
30-06-2013 20:36 | vasketsov | Assigned To | => vasketsov |
30-06-2013 20:37 | vasketsov | Relationship added | related to 0001966 |
20-07-2013 08:44 | vdemidov | Issue cloned: 0002036 | |
09-08-2013 14:59 | vasketsov | Fixed in Version | .Nightly => 130803 |
09-08-2013 15:13 | vasketsov | Status | resolved => closed |
08-08-2025 13:24 | zed | Category | Хотелка => Хотелка / Feature request |
Notes |
|
|
Однако это даже забавно, что _каждый_ создатель _каждого_ класса TThreadExportToXXX (на минуточку - класс оределяет КУДА валим тайлы) почитает за честь написать свой итератор одних и тех же тайлов в выделенной области ИСХОДНОЙ карты. |
|
|
|
Ну чисто теоретически, в разных экспортах порядок обхода может требоваться разный. Поэтому вполне логично что экспорт сам создает себе итератор. А вот его реализацию почему каждый городит свою это уже не ко мне вопрос. |
|
|
(0010045)
|
vasketsov
|
27-11-2012 15:04
(edited on: 27-11-2012 15:07) |
|
Ну мой вопрос касался конкретно копирования в хранилище, где порядок тайлов не важен, а не экспорта в специфичные форматы.
Короче забацал ThreadExportToStorage, в принципе будет пахать для любых целевых хранилищ. Покуда туда не пропихнули генерилку хранилищ по типу кэша - он зовётся только для СУБД.
В принципе если там "виртуализировать" сохранение тайла - можно вообще все экспорты отнаследовать, для которых порядок залетания не важен. Не поверю, что в каждом экспорте со своей реализацией procedure ProcessRegion; override; важен порядок залетания.
|
|
|
|
О, а я и не знал что для экспорта можно менять порядок обхода, делал для проивольного порядка. |
|