View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001710SAS.Планета[All Projects] Хотелкаpublic27-11-2012 15:3705-12-2012 12:48
Reportervasketsov 
Assigned Tovasketsov 
PrioritynormalSeverityminorReproducibilityN/A
StatusresolvedResolutionfixed 
PlatformWindowsOSVistaOS VersionUltimate
Product Version.Nightly 
Target Version131111Fixed in Version131111 
Summary0001710: Автоматическое определение версии скачиваемого тайла
DescriptionДля некоторых тайлов может быть информация о версии внури.
Например для nokia map creator внутри в exif есть дата снимка.
При том что NMC Recency уже с момента "открытия" обновлялся.

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

В качестве версии можно брать просто максимальное значение из дат съёмок, прокатит даже для тайлов, где несколько снимков стыкуются, и при обновлении даст другую (будем надеяться что бОльшую) версию. Для отъявленных извращенцев наверняка есть даже идентификатор снимка, чтобы размножить тайл в хранилище по снимкам (стыковой записать под 2-мя и более версиями))))))). Имею в виду latestAcquisitionDate='2012-05-06 09:05:40.278' (кончик можно кастрировать).

Также запросто может храниться уникальная удобная (в качестве идентификатора версии) информация и в нерастровых тайлах.

Надо будет только допилить СУБД (покуда других версионных нет) в плане опции, чтобы для запроса без версии возвращать последнюю версию тайла. Даже не так, хранилище в СУБД это и так умеет, это надо только вытащить, чтобы это было доступно.

Собственно вопрос и касается 2-го абзаца. Это вообще кому-нибудь нужно/интересно?
TagsNo tags attached.
Attached Files

- Relationships

-  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 (1625x)
Total Views 1625
Last View 10-08-2020 08:06

- 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



Copyright © 2007 - 2020 SAS.Planet Team