SASGIS

Веб-картография и навигация


View Revisions: Issue #1709 All Revisions ] Back to Issue ]
Summary 0001709: Возможность заменять версию тайлов при конвертировании кэша в хранилище с поддержкой версий
Revision 26-11-2012 19:09 by vasketsov
Description Задача номер раз: Необходимо иметь возможность при конвертации кэша из исходного хранилища указать конкретную версию, которая будет использоваться при заливке тайлов в целевое версионное хранилище.

Обоснование необходимости замены версии весьма очевидно:
а) исходное хранилище может быть вообще без поддержки версий;
б) формат версии (строковый) может быть разным в разных хрнилищах, так как само по себе хранилище не накладывает никаких ограничений на значение версии (например для бинга можно в принципе указать версию как 1134, так и g1134).

Задача номер два: то же самое, но дополнительно работаем только в рамках текущего выделения.

Цель - залить кусками по областям выделения исходя из даты тайлов файловый кэш в БД. Номер версии бинга, гугла и т.п. я найду по логам checker-а новых версий. По крайней мер для некоторых важных снимков хотелось бы не единой помойкой их залить, а с номером версии.

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

Вроде бы и можно в описанной задаче обойтись только копированием кэша (в смысле допиливания только диалога "Операции" -> "Скопировать" в виде новой галочки "Заменять версию на " + эдитки). Но надо заодно понять, вкорячивать ли заодно учёт версии в исходный и целевой кэши в менеджере версий.
Revision 26-11-2012 19:07 by vasketsov
Description Задача номер раз: Необходимо иметь возможность при конвертации кэша из исходного хранилища указать конкретную версию, которая будет использоваться при заливке тайлов в целевое версионное хранилище.

Обоснование необходимости замены версии весьма очевидно:
а) исходное хранилище может быть вообще без поддержки версий;
б) формат версии (строковый) может быть разным в разных хрнилищах, так как само по себе хранилище не накладывает никаких ограничений на значение версии (например для бинга можно в принципе указать версию как 1134, так и g1134).

Задача номер два: то же самое, но дополнительно работаем только в рамках текущего выделения.

Цель - залить кусками по областям выделения исходя из даты тайлов файловый кэш в БД. Номер версии бинга, гугла и т.п. я найду по логам checker-а новых версий. По крайней мер для некоторых важных снимков хотелось быне единой помойкой их залить, а с номером версии.

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

Вроде бы и можно в описанной задаче обойтись только копированием кэша (в смысле допиливания только диалога "Операции" -> "Скопировать" в виде новой галочки "Заменять версию на " + эдитки). Но надо заодно понять, вкорячивать ли заодно учёт версии в исходный и целевой кэши в менеджере версий.
Revision 26-11-2012 19:05 by vasketsov
Description Задача номер раз: Необходимо иметь возможность при конвертации кэша из исходного хранилища указать конкретную версию, которая будет использоваться при заливке тайлов в целевое версионное хранилище.

Обоснование необходимости замены версии весьма очевидно:
а) исходное хранилище может быть вообще без поддержки версий;
б) формат версии (строковый) может быть разным в разных хрнилищах, так как само по себе хранилище не накладывает никаких ограничений на значение версии (например для бинга можно в принципе указать версию как 1134, так и g1134).

Задача номер два: то же самое, но дополнительно работаем только в рамках текущего выделения.

Цель - залить кусками по областям выделения исходя из даты тайлов файловый кэш в БД. Номер версии бинга, гугла и т.п. я найду по логам checker-а новых версий. По крайней мер для некоторых важных снимков хотелось быне единой помойкой их залить, а с номером версии.

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

Вроде бы и можно в описанной задаче обойтись только копированием кэша (в смысле допиливания только диалога "Операции" -> "Скопировать" в виде новой галочки "Заменять версию на " + эдитки). Но надо заодно понять, вкорячивать ли заодно учёт версии в исходный и целевой кэши в менеджере версий.



Copyright © 2007 - 2024 SAS.Planet Team