0001710: Автоматическое определение версии скачиваемого тайла

Notes
(0010046) vdemidov (manager) 27-11-2012 15:54	Мне совсем не интересно.

(0010048) Tolik (manager) 27-11-2012 18:34	Может не совсем в тему, но вопрос такой: Вот распихали тайлы в базу данных: в пункте А с версией 1, в п. Б - с в. 2 и т.д. Смотреть-то как из кэша? Каждый раз выбирать из меню правильную версию, иначе ничего не покажет? Или по умолчанию покажет любую (самую свежую) версию?

(0010049) vasketsov (manager) 27-11-2012 18:57	Сейчас покажет только запрошенную версию. Есть ряд настроек, чтобы показывало немного другую версию, чем запрошено (опции друг от друга независимые): 1. Если запрошена конкретная версия, и нет тайлов этой версии, и нет тайлов предыдущих версий, то можно вернуть тайл без версии. 2. Если запрошена конкретная версия, и нет тайлов этой версии, то можно вернуть тайл последней предыдущей версии. 3. Если запрошен тайл без версии, и нет тайла без версии, то можно вернуть тайл с последней существующей версией. Касается только чтения, запись и удаление тайлов всегда только в указанной версии (или соответственно без версии, если она пустая). Именно эти настройки и не вытащены пока что никуда (а их всё равно надо тащить и уметь менять без перезапуска, причём чтобы внутренний кэш в памяти чистился). И именно опция номер 3 как раз и позволит с пустой версией тащить из БД последний актуальный тайл. Во всех случаях понятия "последняя", "предыдущая" и вообще сравнение версий определяются настройкой сравнимости версий (для целочисленных версий это одно, для яндекса это другое). Возвращаясь к описанной задаче распарсивания exif из тайла налету для определения его версии, в принципе если совсем никому будет не интересно, я могу и в БД сделать на instead of триггере, вообще ничего в модели данных менять не придётся, только вот парсить жпеги в триггере не очень удобно.

(0010050) Garl (manager) 27-11-2012 19:11 edited on: 27-11-2012 19:17	интересен именно файловый вариант версий кэша, с учётом параметра Version из zmp ибо файловый самый понятный и простой в отладке. версии интересны как по запросу tid'y ДГ так и от BING кстати касаемо бинга были пропущены очень даже интересный и качественные снимки, а вот иметь их в вресиях было бы очень даже круто!

(0010051) rass (reporter) 27-11-2012 19:18	NMC Recency может показывать разные снимки приходящиеся на одно место? или только одно - определяемое серверов NMC Recency? и я так понимаю версий будет столько - сколько снимков?

(0010053) Garl (manager) 27-11-2012 19:25	NMC показывает те даты в которые попадает видимый вами снимок.

(0010054) vasketsov (manager) 27-11-2012 19:51	>файловый самый понятный и простой в отладке ну так вроде никто не заставляет и не запрещает )) Мну залил бинга 3.5 гига _для_проверки_ по последнему обновлению в postgresql - превышение физического размера хранилища postgres-а (на диске) над прямой суммой размера всех тайлов в БД - прядка 100 мегабайт (для сравнения можете сами проверить в свойствах корневой папки своего кэша, что у вас будет). Сейчас уже 6 гигов почти - физически это 362 файла и 3 папки (сейчас сервер потушен). Из-за того, что таблицы кластеризованы, лишнее на индексы - только 4 байта на тайл под его размер, зато хранятся они как раз в порядке указанного индекса. Из-за индекса по идентификатору тайла, его версии и размеру карта заполнения строится не в пример быстрее, чем при хождении по папкам. Создание резервной копии БД (или таблиц в ней) и восстановление в случае сбоя - тривиальнейшая операция, выполняемая не в пример проще, чем при работе с файловой системой. Вы всё ещё кипятите? Да ради бога. Никто не заставляет. >касаемо бинга Разумеется бинг - первый кандидат на заливку в версионное хранилише, так как имеется номер версии + нет возможности скачать предыдущие версии. Даже если захочется сменить СУБД, операция копирования кэша уже работает для СУБД (если сейчас сгенериться из репо). Я уже погонял тайлы десятками тыщ между СУБД и ФС - вторая просто отдыхает по скорости работы. >NMC Recency может показывать разные снимки приходящиеся на одно место? Не совсем верный вопрос. Поэтому отвечу не совсем коротко: 1. В URL для NMC Recency НЕТ возможности указать номер версии. С точки зрения саса это означает, что уж точно скачать предыдщую никак не получится. 2. На NMC Recency уже были обновления. При искачке новых тайлов указать какое-то новое разумное значение для новой версии невозможно. Хотя бы потому что об обновлении ничего неизвестно. Пока не качнёшь тайл - не узнаешь, что он обновился. >я так понимаю версий будет столько - сколько снимков? У NMC есть неприятная особенность - дата снимка в exif на разных зумах может немного отличаться. Поэтому в рамках автоопределения версии тайла придётся обрезать хвост. Насколько его обрезать, и будут ли снимки (возможно с разных аппаратов), которые попадут в один и тот же час (или даже минуту) - дискуссионно. В любом случае версий будет никак не больше чем снимков, но даже это не должно напрягать, так как список версий получается по конкретной координате, а существование нескольких снимков одного места за один момент с нескольких спутников маловероятно. -------------- - статистика по нескольким сереньким снимкам с NMC Recency + большой кусок от 13 и ниже в дефолтном файловом кэше для сравнения: Размер: 4.65 ГБ (4 997 070 809 байт) На диске: 5.04 ГБ (5 420 531 712 байт) Файлов: 208858 Папок: 1389

(0010055) vasketsov (manager) 27-11-2012 19:55	>версии интересны как по запросу tid'y ДГ так и от BING Эта хотелка вообще никак не связана с запросом доступных снимков с сервисов. Она касается только автоопределения того, что скачанный тайл изменился, автоопределения его версии и помещения его в хранилище под нужной версией, не затирая предыдущую версию.

(0010057) rass (reporter) 27-11-2012 20:22 edited on: 27-11-2012 20:23	> У NMC есть неприятная особенность - дата снимка в exif на разных зумах может немного отличаться. а может тогда версию определять не временем, а ID номером снимка? Например: <digitalglobe:featureInTileIdentifier>071bc581f5f2e47fa03e217388952f42:2011-07-16 Помотрел на разных уровнях он не меняется - он стабилный в пределах снимка.

(0010058) vasketsov (manager) 27-11-2012 21:36 edited on: 27-11-2012 21:40	>версию определять не временем, а ID номером снимка? Формально это можно. Но только чтобы работал показ снимков последней версии из версионного хранилища при запросе без версии, необходимо уметь СРАВНИВАТЬ версии. Так что придётся в этом случае сравниваться по ДАТЕ-ВРЕМЕНИ версии, всё равно пихать это в дату версии (кроме запихивания уникального ID снимка), и заведомо придётся размножаться по ID снимка покуда само значение версии несравниваемое (при сохранении тайла, на котором более одного снимка, он относится к двум разным ID и датам). Ну и по правой кнопке перечисляться будут ID снимков ))))) зы. А нет, просто так не взлетит. Если был тайл с 2-мя снимками, и в него попал при обновлении край нового третьего снимка, предыдущие 2 не должны обновиться. Так что при обновлении тайла идентификатор его версии обязан меняться.

(0010059) rass (reporter) 27-11-2012 21:58 edited on: 28-11-2012 06:39	> всё равно пихать это в дату версии (кроме запихивания уникального ID снимка) указанный параметр EXIF содержит ID:Date снимка <digitalglobe:featureInTileIdentifier> 071bc581f5f2e47fa03e217388952f42:2011-07-16 </digitalglobe:featureInTileIdentifier> <digitalglobe:featureInTileIdentifier> 071bc581f5f2e47fa03e217388952f42:2011-07-16,9a177642c15c392f3db96e9832202b4c:2011-05-17 </digitalglobe:featureInTileIdentifier> <digitalglobe:featureInTileIdentifier> 071bc581f5f2e47fa03e217388952f42:2011-07-16,9a177642c15c392f3db96e9832202b4c:2011-05-17, ac2e2b3395b309be49fa0bd0acd63d94:2010-11-08 </digitalglobe:featureInTileIdentifier> нижние два параметра с переходом двух и трех снимков в одном тайле переходные тайлы записывать в каждую версию (edited by Tolik: добавил пробелов для читабельности)

(0010060) vasketsov (manager) 27-11-2012 22:16 edited on: 28-11-2012 06:40	Если предлагается "071bc581f5f2e47fa03e217388952f42:2011-07-16,9a177642c15c392f3db96e9832202b4c:2011-05-17, ac2e2b3395b309be49fa0bd0acd63d94:2010-11-08" пихать как версию - то мы так ширины поля не напасёмся. Если же предлагается пихать в версию только 071bc581f5f2e47fa03e217388952f42:2011-07-16 - то как я уже объяснил, это приведёт к перезаписи старого тайла во всех трёх местах при появлении в рамках границы тайла четвёртого снимка, идентфикатор и дата которого также добавятся в этот список. Впрочем максимальная дата снимка на тайле тоже не панацея. На бинге есть места, где новые снимки (в смысле версии) подложены под старые. Чем NMC хуже ))) (Tolik и сюда добавил пробел)

(0010062) Garl (manager) 28-11-2012 04:22	2 vasketsov: см личку на форуме. >то как я уже объяснил, это приведёт к перезаписи старого тайла во всех трёх местах при появлении в рамках границы тайла четвёртого снимка, так можно же и не переписывать тайл в режиме кэш+интернет.

(0010068) vasketsov (manager) 28-11-2012 09:09	>не переписывать тайл в режиме кэш+интернет либо хранилище ничего про этот режим не знает. либо существующий тайл (а при запросе без версии из хранилища вернётся последняя версия) не будет перезаписан.

(0010129) vasketsov (manager) 04-12-2012 22:29	Сделал в рамках доработки 1113 (для СУБД) для nokia.

Users who viewed this issue
User List	Anonymous (2583x)
Total Views	2583
Last View	21-11-2024 09:57

Issue History
Date Modified	Username	Field	Change
27-11-2012 15:37	vasketsov	New Issue
27-11-2012 15:54	vdemidov	Note Added: 0010046
27-11-2012 18:34	Tolik	Note Added: 0010048
27-11-2012 18:57	vasketsov	Note Added: 0010049
27-11-2012 19:11	Garl	Note Added: 0010050
27-11-2012 19:17	Garl	Note Edited: 0010050	View Revisions
27-11-2012 19:18	rass	Note Added: 0010051
27-11-2012 19:25	Garl	Note Added: 0010053
27-11-2012 19:51	vasketsov	Note Added: 0010054
27-11-2012 19:55	vasketsov	Note Added: 0010055
27-11-2012 20:22	rass	Note Added: 0010057
27-11-2012 20:23	rass	Note Edited: 0010057	View Revisions
27-11-2012 21:36	vasketsov	Note Added: 0010058
27-11-2012 21:40	vasketsov	Note Edited: 0010058	View Revisions
27-11-2012 21:58	rass	Note Added: 0010059
27-11-2012 22:16	vasketsov	Note Added: 0010060
27-11-2012 22:21	vasketsov	Note Edited: 0010060	View Revisions
28-11-2012 04:22	Garl	Note Added: 0010062
28-11-2012 06:37	Tolik	Note Edited: 0010059	View Revisions
28-11-2012 06:38	Tolik	Note Edited: 0010059	View Revisions
28-11-2012 06:39	Tolik	Note Edited: 0010059	View Revisions
28-11-2012 06:39	Tolik	Note Edited: 0010059	View Revisions
28-11-2012 06:40	Tolik	Note Edited: 0010060	View Revisions
28-11-2012 09:09	vasketsov	Note Added: 0010068
04-12-2012 22:29	vasketsov	Note Added: 0010129
04-12-2012 22:29	vasketsov	Assigned To	=> vasketsov
04-12-2012 22:29	vasketsov	Status	new => assigned
04-12-2012 22:30	vasketsov	Status	assigned => resolved
04-12-2012 22:30	vasketsov	Fixed in Version	=> 131111
04-12-2012 22:30	vasketsov	Resolution	open => fixed
05-12-2012 12:48	vdemidov	Target Version	=> 131111

Relationships

SASGIS