SASGIS - SAS.Планета |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0001710 | SAS.Планета | [All Projects] Хотелка | public | 27-11-2012 15:37 | 05-12-2012 12:48 |
|
| Reporter | vasketsov | |
| Assigned To | vasketsov | |
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | |
| Platform | Windows | OS | Vista | OS Version | Ultimate |
| Product Version | .Nightly | |
| Target Version | 131111 | Fixed in Version | 131111 | |
|
| Summary | 0001710: Автоматическое определение версии скачиваемого тайла |
| Description | Для некоторых тайлов может быть информация о версии внури.
Например для nokia map creator внутри в exif есть дата снимка.
При том что NMC Recency уже с момента "открытия" обновлялся.
Если бы была возможность после скачивания тайла где-то на уровне MapType и ДО попадания в хранилище (чтобы кэш в памяти знал о реальной версии тайла) автоматически определить его версию, и с этой версией его сохранить (в хранилище и в кэш в памяти), то для NMC можно было бы формально без возможности смены версии в УРЛе (а там для NMC нет версии тайла) реализовать версионное хранилище.
В качестве версии можно брать просто максимальное значение из дат съёмок, прокатит даже для тайлов, где несколько снимков стыкуются, и при обновлении даст другую (будем надеяться что бОльшую) версию. Для отъявленных извращенцев наверняка есть даже идентификатор снимка, чтобы размножить тайл в хранилище по снимкам (стыковой записать под 2-мя и более версиями))))))). Имею в виду latestAcquisitionDate='2012-05-06 09:05:40.278' (кончик можно кастрировать).
Также запросто может храниться уникальная удобная (в качестве идентификатора версии) информация и в нерастровых тайлах.
Надо будет только допилить СУБД (покуда других версионных нет) в плане опции, чтобы для запроса без версии возвращать последнюю версию тайла. Даже не так, хранилище в СУБД это и так умеет, это надо только вытащить, чтобы это было доступно.
Собственно вопрос и касается 2-го абзаца. Это вообще кому-нибудь нужно/интересно? |
| Steps To Reproduce | |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | |
| Attached Files | |
|
| 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 | bug_revision_view_page.php?bugnote_id=10050#r4914 |
| 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 | bug_revision_view_page.php?bugnote_id=10057#r4916 |
| 27-11-2012 21:36 | vasketsov | Note Added: 0010058 | |
| 27-11-2012 21:40 | vasketsov | Note Edited: 0010058 | bug_revision_view_page.php?bugnote_id=10058#r4918 |
| 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 | bug_revision_view_page.php?bugnote_id=10060#r4920 |
| 28-11-2012 04:22 | Garl | Note Added: 0010062 | |
| 28-11-2012 06:37 | Tolik | Note Edited: 0010059 | bug_revision_view_page.php?bugnote_id=10059#r4929 |
| 28-11-2012 06:38 | Tolik | Note Edited: 0010059 | bug_revision_view_page.php?bugnote_id=10059#r4930 |
| 28-11-2012 06:39 | Tolik | Note Edited: 0010059 | bug_revision_view_page.php?bugnote_id=10059#r4931 |
| 28-11-2012 06:39 | Tolik | Note Edited: 0010059 | bug_revision_view_page.php?bugnote_id=10059#r4932 |
| 28-11-2012 06:40 | Tolik | Note Edited: 0010060 | bug_revision_view_page.php?bugnote_id=10060#r4933 |
| 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 |
|
Notes |
|
|
|
|
|
|
(0010048)
|
|
Tolik
|
|
27-11-2012 18:34
|
|
Может не совсем в тему, но вопрос такой:
Вот распихали тайлы в базу данных: в пункте А с версией 1, в п. Б - с в. 2 и т.д. Смотреть-то как из кэша? Каждый раз выбирать из меню правильную версию, иначе ничего не покажет? Или по умолчанию покажет любую (самую свежую) версию? |
|
|
|
|
Сейчас покажет только запрошенную версию.
Есть ряд настроек, чтобы показывало немного другую версию, чем запрошено (опции друг от друга независимые):
1. Если запрошена конкретная версия, и нет тайлов этой версии, и нет тайлов предыдущих версий, то можно вернуть тайл без версии.
2. Если запрошена конкретная версия, и нет тайлов этой версии, то можно вернуть тайл последней предыдущей версии.
3. Если запрошен тайл без версии, и нет тайла без версии, то можно вернуть тайл с последней существующей версией.
Касается только чтения, запись и удаление тайлов всегда только в указанной версии (или соответственно без версии, если она пустая).
Именно эти настройки и не вытащены пока что никуда (а их всё равно надо тащить и уметь менять без перезапуска, причём чтобы внутренний кэш в памяти чистился). И именно опция номер 3 как раз и позволит с пустой версией тащить из БД последний актуальный тайл.
Во всех случаях понятия "последняя", "предыдущая" и вообще сравнение версий определяются настройкой сравнимости версий (для целочисленных версий это одно, для яндекса это другое).
Возвращаясь к описанной задаче распарсивания exif из тайла налету для определения его версии, в принципе если совсем никому будет не интересно, я могу и в БД сделать на instead of триггере, вообще ничего в модели данных менять не придётся, только вот парсить жпеги в триггере не очень удобно. |
|
|
|
(0010050)
|
|
Garl
|
27-11-2012 19:11
(edited on: 27-11-2012 19:17) |
|
интересен именно файловый вариант версий кэша, с учётом параметра Version из zmp
ибо файловый самый понятный и простой в отладке.
версии интересны как по запросу tid'y ДГ так и от BING
кстати касаемо бинга были пропущены очень даже интересный и качественные снимки, а вот иметь их в вресиях было бы очень даже круто!
|
|
|
|
(0010051)
|
|
rass
|
|
27-11-2012 19:18
|
|
NMC Recency может показывать разные снимки приходящиеся на одно место? или только одно - определяемое серверов NMC Recency?
и я так понимаю версий будет столько - сколько снимков? |
|
|
|
(0010053)
|
|
Garl
|
|
27-11-2012 19:25
|
|
|
NMC показывает те даты в которые попадает видимый вами снимок. |
|
|
|
|
>файловый самый понятный и простой в отладке
ну так вроде никто не заставляет и не запрещает ))
Мну залил бинга 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 |
|
|
|
|
>версии интересны как по запросу tid'y ДГ так и от BING
Эта хотелка вообще никак не связана с запросом доступных снимков с сервисов.
Она касается только автоопределения того, что скачанный тайл изменился, автоопределения его версии и помещения его в хранилище под нужной версией, не затирая предыдущую версию. |
|
|
|
(0010057)
|
|
rass
|
27-11-2012 20:22
(edited on: 27-11-2012 20:23) |
|
> У NMC есть неприятная особенность - дата снимка в exif на разных зумах может немного отличаться.
а может тогда версию определять не временем, а ID номером снимка?
Например:
<digitalglobe:featureInTileIdentifier>071bc581f5f2e47fa03e217388952f42:2011-07-16
Помотрел на разных уровнях он не меняется - он стабилный в пределах снимка.
|
|
|
|
(0010058)
|
|
vasketsov
|
27-11-2012 21:36
(edited on: 27-11-2012 21:40) |
|
>версию определять не временем, а ID номером снимка?
Формально это можно. Но только чтобы работал показ снимков последней версии из версионного хранилища при запросе без версии, необходимо уметь СРАВНИВАТЬ версии. Так что придётся в этом случае сравниваться по ДАТЕ-ВРЕМЕНИ версии, всё равно пихать это в дату версии (кроме запихивания уникального ID снимка), и заведомо придётся размножаться по ID снимка покуда само значение версии несравниваемое (при сохранении тайла, на котором более одного снимка, он относится к двум разным ID и датам). Ну и по правой кнопке перечисляться будут ID снимков )))))
зы. А нет, просто так не взлетит. Если был тайл с 2-мя снимками, и в него попал при обновлении край нового третьего снимка, предыдущие 2 не должны обновиться. Так что при обновлении тайла идентификатор его версии обязан меняться.
|
|
|
|
(0010059)
|
|
rass
|
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
|
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
|
|
28-11-2012 04:22
|
|
2 vasketsov: см личку на форуме.
>то как я уже объяснил, это приведёт к перезаписи старого тайла во всех трёх местах при появлении в рамках границы тайла четвёртого снимка,
так можно же и не переписывать тайл в режиме кэш+интернет. |
|
|
|
|
>не переписывать тайл в режиме кэш+интернет
либо хранилище ничего про этот режим не знает.
либо существующий тайл (а при запросе без версии из хранилища вернётся последняя версия) не будет перезаписан. |
|
|
|
|
|
Сделал в рамках доработки 1113 (для СУБД) для nokia. |
|