| Anonymous | Login | Signup for a new account | 23-11-24 08:13 UTC | |
| All Projects | SAS.Планета | Домен, сайт, форум, багтрекер | Доработка карты (ZMP) | Переводы и локализации | Прочее |
| My View | View Issues | Change Log | Roadmap | Search |
| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| 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-го абзаца. Это вообще кому-нибудь нужно/интересно? | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files | |||||||||
 Relationships |
|
 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. |
|
Notes |
| Users who viewed this issue |
|
| User List | Anonymous (2589x) |
| Total Views | 2589 |
| Last View | 23-11-2024 08:13 |
| Users who viewed this issue |
|
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 |
|
Issue History |
| My View | View Issues | Change Log | Roadmap | Search |
| Copyright © 2007 - 2024 SAS.Planet Team |