0001659: Выбор алгоритма закачки тайлов

Notes
(0009752) Tolik (manager) 26-10-2012 05:52	Точно, загружать тайлы сверху вниз, потом слева направо, при этом запрашивать только каждый N*M-ный тайл. Например, если скачиваем мегатайл размером 512х512, то и напросы слать на каждый второй по вертикали и каждый второй по горизонтали.

(0009754) Garl (manager) 26-10-2012 06:26	после скачивания мега тайла и нарезки на стандатрные тайлы запрос и так будет слаться на следующий отсуствующий.что нам и нужно

(0009755) Tolik (manager) 26-10-2012 06:34 edited on: 26-10-2012 09:58	Это, наверно, так только в режиме Интернет+кэш. А в реж. Инт. тыкает во все подряд. В приложении кадастр 3х3, который работает нормально и сейчас, только тормозит вроде, и приходится включать загрузку тайлов за пределами окна. И ошибки бегают по экрану Tile does not exist. P.S. тормозит, т.к. стоит MaxConnectToServerCount=1, его надо убрать, он не нужен.

(0009756) Garl (manager) 26-10-2012 06:46	а в режиме интернет тоже иногда интересен будет алгоритм "Улитки" например при классических тайлах 256*256

(0009757) Tolik (manager) 26-10-2012 06:47	А чем улитка отличается от короеда?

(0009758) Garl (manager) 26-10-2012 06:47	в обратную сторону :)

(0009759) Tolik (manager) 26-10-2012 06:48	А в чём профит?

(0009760) Garl (manager) 26-10-2012 06:49 edited on: 26-10-2012 06:59	профит в режиме интернет+кэш приатачил примеры. самый оптимальный "для мегатайлов" будет последовательный из левого верха в правый низ аки "печатная машинка"

(0009761) Tolik (manager) 26-10-2012 07:15 edited on: 26-10-2012 07:15	Ни к чему перебирать все, надо только верхний левый угол (красными стрелками). Как пиш.машинка или сасовская качалка (сначала сверху вниз) - без разницы.

(0009762) Tolik (manager) 26-10-2012 07:18	Улитка ничем не лучше короеда, т.к. при движении справа налево (на картинке algo.jpg 3 4 5 6 7) на каждом шаге будет скачиваться мегатайл и затирать то, что уже скачано.

(0009763) Dima2000 (developer) 26-10-2012 19:32	А стоит ли вообще заморачиваться для какой-то жалкой сотни тайлов при просмотре? Ну скачает в разы больше, подумаешь ... Или можно пойти вообще другим путём: ограничить временные рамки для запросов тайла с сервера - если тайл в кэше не старее 5 минут (к примеру), то сервер не запрашивать, а использовать из кэша (невзирая на режим). Время можно вынести и в ini. И работать будет с любым обходом. Задача оптимизации запросов сервера таким макаром решается.

(0009764) vdemidov (manager) 26-10-2012 19:41	Так это уже сейчас есть. В ини можно задать максимальный возраст тайла, который не будет перезакачиваться в режиме интернет. Параметр TileMaxAgeInInternet По умолчанию 1 минута.

(0009765) vasketsov (manager) 26-10-2012 19:48 edited on: 26-10-2012 19:49	>стоит ли вообще заморачиваться для какой-то жалкой сотни тайлов Когда сервер банит скажем после 30 запросов и надо менять прокси - ситуация выглядит несколько иначе. >Задача оптимизации запросов Это не только оптимизация. На примере росреестра - это и ещё генерация приемлемой картинки. Дело в том, что кадастровый номер отображается на каждой скачиваемой картинке. Если качать и резать как попало - после скачки мегатайла и его нарезки при сохранении только одного тайлика этот номер может быть как разрезан, так и отсутствовать вообще. В общем случае это критично для любых сервисов, где изображение зависит от размера картинки и не аддитивно.

(0009767) Tolik (manager) 27-10-2012 12:30	Да, речь идёт о генерации хорошей картинки, которая в данном примере занимает 9 тайлов. Есть ещё одна сложность: допустим, скачали все тайлы для текущего окна. Потом передвинули на 1 тайл влево. Теперь надо начинать скачку не с тайла 0,0 (т.е. верхнего левого угла), а с -2,0, чтобы не портить уже скачанную картинку. Доп.гемор.

(0009781) vdemidov (manager) 30-10-2012 11:35	ИМХО проще ввести поддержку тайлов разных размеров, чем разгребать все глюки с этой нарезкой.

(0009782) Garl (manager) 30-10-2012 12:03	ничего разгребать с нарезкой, просто хочется выбор алгоритмя по умолчанию или кооред или при скачивании(последовательное перебирание тайлов).

(0009783) Tolik (manager) 30-10-2012 12:07	Когда же наконец будет поддержка тайлов разных размеров? :) Конечно, было бы лучше сохранять 1 большой тайл вместо 9 маленьких!

(0009784) Tolik (manager) 30-10-2012 12:15	Хотя одно другому не мешает: можно сделать выбор короед/последовательное (я думаю, лучше столбцами, как качалка, это поможет отлаживать zmp так, чтобы качалось нормально).

(0010249) vdemidov (manager) 29-12-2012 10:36	Проблему мегатайлов это не решает. А короед ИМХО оптимален.

(0010508) vasketsov (manager) 04-02-2013 22:08 edited on: 04-02-2013 22:13	>На примере росреестра Как раз на примере росреестра сделал-таки, чтобы мегатайлы качались без перекрытия, пришлось отказаться в этом случае от "короеда" и грузить мегатайлы построчно. Зато картинка человеческая стала, когда делаешь 4x4, не подписывается номером каждый кусочек каждого участка. Для этого реанимировал недоубитый параметр IteratorSubRectSize=4,4,а также сделал IteratorSubRectAlign=2. Если 0 - всё по умолчанию, если не 0 (1 или 2) - то осуществляется точная привязка к размеру мегатайла (со смещением от произвольного места скачается разве что мышкой по одному). Если же не 1, а 2 - то будет дополнительно увеличен размер просматриваемой области, чтобы возможно даже было скачать например один левый верхний тайлик в режиме кэш+интернет при сдвиге окна влево и вверх. Ну и связанное с этим технически - загрузка одного из N тайлов. Тупо X mod N = 0 и то же самое для Y. Показано при поиске обновлений на картосервисах.

Users who viewed this issue
User List	Anonymous (3212x), ingener (1x), k-dmitriy (7x), rass (4x), VMatveev (2x), vdemidov (2x), zed (1x)
Total Views	3229
Last View	25-11-2024 00:07

Issue History
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	View Revisions
26-10-2012 06:41	Tolik	File Added: rosreestr_cadastr9.zmp.zip
26-10-2012 06:43	Tolik	Note Edited: 0009755	View Revisions
26-10-2012 06:45	Tolik	Note Edited: 0009755	View Revisions
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	View Revisions
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	View Revisions
26-10-2012 07:18	Tolik	Note Added: 0009762
26-10-2012 09:58	Tolik	Note Edited: 0009755	View Revisions
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	View Revisions
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	View Revisions
04-02-2013 22:19	vasketsov	File Added: Rosreestr4x4.jpg

Relationships

SASGIS