View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001659 | SAS.Планета | Хотелка / Feature request | public | 26-10-2012 05:14 | 04-02-2013 22:19 |
| Reporter | Garl | Assigned To | vdemidov | ||
| Priority | high | Severity | major | Reproducibility | have not tried |
| Status | closed | Resolution | won't fix | ||
| Platform | Windows | OS | 7 | OS Version | Professional |
| Product Version | .Nightly | ||||
| Summary | 0001659: Выбор алгоритма закачки тайлов | ||||
| Description | В связи с тем что в Планете есть возможность качать "Мегатайл" и резать его на стандартные тайлы - возникает предложение: сделать настраиваемым алгоритм закачивания тайлов при просмотре, ибо алгоритм "Короеда" не оптимален в этом случае. Предложение добавить алгоритм обратный "короеду" аля "улитка" или просто загружать тайлы последовательно из левого верхнего в правый нижний тем самым мы оптимизируем работу с сервисами отдающие медлено и большими порциями. | ||||
| Tags | загрузка, короед | ||||
| Attached Files | |||||
|
|
Точно, загружать тайлы сверху вниз, потом слева направо, при этом запрашивать только каждый N*M-ный тайл. Например, если скачиваем мегатайл размером 512х512, то и напросы слать на каждый второй по вертикали и каждый второй по горизонтали. |
|
|
после скачивания мега тайла и нарезки на стандатрные тайлы запрос и так будет слаться на следующий отсуствующий.что нам и нужно |
|
|
Это, наверно, так только в режиме Интернет+кэш. А в реж. Инт. тыкает во все подряд. В приложении кадастр 3х3, который работает нормально и сейчас, только тормозит вроде, и приходится включать загрузку тайлов за пределами окна. И ошибки бегают по экрану Tile does not exist. P.S. тормозит, т.к. стоит MaxConnectToServerCount=1, его надо убрать, он не нужен. |
|
|
а в режиме интернет тоже иногда интересен будет алгоритм "Улитки" например при классических тайлах 256*256 |
|
|
А чем улитка отличается от короеда? |
|
|
в обратную сторону :) |
|
|
А в чём профит? |
|
|
профит в режиме интернет+кэш приатачил примеры. самый оптимальный "для мегатайлов" будет последовательный из левого верха в правый низ аки "печатная машинка" |
|
|
Ни к чему перебирать все, надо только верхний левый угол (красными стрелками). Как пиш.машинка или сасовская качалка (сначала сверху вниз) - без разницы. |
|
|
Улитка ничем не лучше короеда, т.к. при движении справа налево (на картинке algo.jpg 3 4 5 6 7) на каждом шаге будет скачиваться мегатайл и затирать то, что уже скачано. |
|
|
А стоит ли вообще заморачиваться для какой-то жалкой сотни тайлов при просмотре? Ну скачает в разы больше, подумаешь ... Или можно пойти вообще другим путём: ограничить временные рамки для запросов тайла с сервера - если тайл в кэше не старее 5 минут (к примеру), то сервер не запрашивать, а использовать из кэша (невзирая на режим). Время можно вынести и в ini. И работать будет с любым обходом. Задача оптимизации запросов сервера таким макаром решается. |
|
|
Так это уже сейчас есть. В ини можно задать максимальный возраст тайла, который не будет перезакачиваться в режиме интернет. Параметр TileMaxAgeInInternet По умолчанию 1 минута. |
|
|
>стоит ли вообще заморачиваться для какой-то жалкой сотни тайлов Когда сервер банит скажем после 30 запросов и надо менять прокси - ситуация выглядит несколько иначе. >Задача оптимизации запросов Это не только оптимизация. На примере росреестра - это и ещё генерация приемлемой картинки. Дело в том, что кадастровый номер отображается на каждой скачиваемой картинке. Если качать и резать как попало - после скачки мегатайла и его нарезки при сохранении только одного тайлика этот номер может быть как разрезан, так и отсутствовать вообще. В общем случае это критично для любых сервисов, где изображение зависит от размера картинки и не аддитивно. |
|
|
Да, речь идёт о генерации хорошей картинки, которая в данном примере занимает 9 тайлов. Есть ещё одна сложность: допустим, скачали все тайлы для текущего окна. Потом передвинули на 1 тайл влево. Теперь надо начинать скачку не с тайла 0,0 (т.е. верхнего левого угла), а с -2,0, чтобы не портить уже скачанную картинку. Доп.гемор. |
|
|
ИМХО проще ввести поддержку тайлов разных размеров, чем разгребать все глюки с этой нарезкой. |
|
|
ничего разгребать с нарезкой, просто хочется выбор алгоритмя по умолчанию или кооред или при скачивании(последовательное перебирание тайлов). |
|
|
Когда же наконец будет поддержка тайлов разных размеров? :) Конечно, было бы лучше сохранять 1 большой тайл вместо 9 маленьких! |
|
|
Хотя одно другому не мешает: можно сделать выбор короед/последовательное (я думаю, лучше столбцами, как качалка, это поможет отлаживать zmp так, чтобы качалось нормально). |
|
|
Проблему мегатайлов это не решает. А короед ИМХО оптимален. |
|
|
>На примере росреестра Как раз на примере росреестра сделал-таки, чтобы мегатайлы качались без перекрытия, пришлось отказаться в этом случае от "короеда" и грузить мегатайлы построчно. Зато картинка человеческая стала, когда делаешь 4x4, не подписывается номером каждый кусочек каждого участка. Для этого реанимировал недоубитый параметр IteratorSubRectSize=4,4,а также сделал IteratorSubRectAlign=2. Если 0 - всё по умолчанию, если не 0 (1 или 2) - то осуществляется точная привязка к размеру мегатайла (со смещением от произвольного места скачается разве что мышкой по одному). Если же не 1, а 2 - то будет дополнительно увеличен размер просматриваемой области, чтобы возможно даже было скачать например один левый верхний тайлик в режиме кэш+интернет при сдвиге окна влево и вверх. Ну и связанное с этим технически - загрузка одного из N тайлов. Тупо X mod N = 0 и то же самое для Y. Показано при поиске обновлений на картосервисах. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 26-10-2012 05:14 | Garl | New Issue | |
| 26-10-2012 05:15 | Garl | Tag Attached: загрузка | |
| 26-10-2012 05:15 | Garl | Tag Attached: короед | |
| 26-10-2012 05:52 | Tolik | Note Added: 0009752 | |
| 26-10-2012 06:26 | Garl | Note Added: 0009754 | |
| 26-10-2012 06:34 | Tolik | Note Added: 0009755 | |
| 26-10-2012 06:35 | Tolik | Note Edited: 0009755 | |
| 26-10-2012 06:41 | Tolik | File Added: rosreestr_cadastr9.zmp.zip | |
| 26-10-2012 06:43 | Tolik | Note Edited: 0009755 | |
| 26-10-2012 06:45 | Tolik | Note Edited: 0009755 | |
| 26-10-2012 06:46 | Garl | Note Added: 0009756 | |
| 26-10-2012 06:47 | Tolik | Note Added: 0009757 | |
| 26-10-2012 06:47 | Garl | Note Added: 0009758 | |
| 26-10-2012 06:48 | Tolik | Note Added: 0009759 | |
| 26-10-2012 06:49 | Garl | Note Added: 0009760 | |
| 26-10-2012 06:54 | Garl | File Added: algo.jpg | |
| 26-10-2012 06:57 | Garl | File Added: algo2.jpg | |
| 26-10-2012 06:59 | Garl | Note Edited: 0009760 | |
| 26-10-2012 07:13 | Tolik | File Added: algo2 NxM.jpg | |
| 26-10-2012 07:15 | Tolik | Note Added: 0009761 | |
| 26-10-2012 07:15 | Tolik | Note Edited: 0009761 | |
| 26-10-2012 07:18 | Tolik | Note Added: 0009762 | |
| 26-10-2012 09:58 | Tolik | Note Edited: 0009755 | |
| 26-10-2012 19:32 | Dima2000 | Note Added: 0009763 | |
| 26-10-2012 19:41 | vdemidov | Note Added: 0009764 | |
| 26-10-2012 19:48 | vasketsov | Note Added: 0009765 | |
| 26-10-2012 19:49 | vasketsov | Note Edited: 0009765 | |
| 27-10-2012 12:30 | Tolik | Note Added: 0009767 | |
| 30-10-2012 11:35 | vdemidov | Note Added: 0009781 | |
| 30-10-2012 12:03 | Garl | Note Added: 0009782 | |
| 30-10-2012 12:07 | Tolik | Note Added: 0009783 | |
| 30-10-2012 12:15 | Tolik | Note Added: 0009784 | |
| 29-12-2012 10:36 | vdemidov | Note Added: 0010249 | |
| 29-12-2012 10:36 | vdemidov | Status | new => resolved |
| 29-12-2012 10:36 | vdemidov | Resolution | open => won't fix |
| 29-12-2012 10:36 | vdemidov | Assigned To | => vdemidov |
| 29-12-2012 10:36 | vdemidov | Status | resolved => closed |
| 04-02-2013 22:08 | vasketsov | Note Added: 0010508 | |
| 04-02-2013 22:13 | vasketsov | Note Edited: 0010508 | |
| 04-02-2013 22:19 | vasketsov | File Added: Rosreestr4x4.jpg | |
| 08-08-2025 13:24 | zed | Category | Хотелка => Хотелка / Feature request |