View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001283 | SAS.Планета | Хотелка / Feature request | public | 27-04-2012 19:35 | 15-11-2012 05:27 |
| Reporter | vasketsov | Assigned To | vasketsov | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Platform | Windows | OS | Vista | OS Version | Ultimate |
| Product Version | 110418 | ||||
| Target Version | 120808 | Fixed in Version | 120808 | ||
| Summary | 0001283: Нарезка скачиваемого изображения на тайлы (расширение кропа) | ||||
| Description | В общем покуда Te$$ase$ve$ не скурвился, реализовалась следующая фича. Грузим врукопашную тайл - добавляю тайл справа и слева, получается 768x256. Соответственно искажений нет. Левый кусок с ватермарками отбрасывается - вуаля, остаток делим и сохраняем сразу 2 тайла без ватермарков. На предыдущем этапе было 512x256 (пока Te$$ase$ve$ это не забанил) и обычный crop - но так намного круче и быстрее, так как прилетают 2 тайла за один раз, и проfuckивать половину информации с простым старым crop-ом конечно никуда не годится. Также наверняка можно грузануть большой жпег и порезать налету на тайлы. Но я тестил только горизонтальные полоски. Если не будет искажений (что очевидно определяется в первую очередь источником) - флаг в руки и успехов. Параметры в zmp (со значениями) целочисленные: CutCountX=0 (число кусков по X, необязательный параметр) CutCountY=0 (соответственно по Y) CutSizeX=0 (размер куска по X, если не задано - берётся 256 из параметров) CutSizeY=0 (соответственно по Y) CutTileX=0 (положение запрошенного тайла в общей картинке по X) CutTileY=0 (соответственно по Y) Также строковый параметр: CutToSkip=(0,0),(0,-1) Это список исключаемых тайликов после нарезки, чтобы не пролетали ватермарки. Если значение меньше нуля - считается относительно соответствующего Count (то есть в случае значения выше - исключаются левый верхний и левый нижний тайлы соответственно). Пример: -TILERLEFT=256 -TILERRIGHT=512 -TILERTOP=0 -TILERBOTTOM=256 CutSizeX=256 CutSizeY=256 CutTileX=1 CutTileY=0 CutToSkip=(0,0) Для сравнения заминусован старый вариант с простым кропом и 512x256. Новый вариант (768x256) самостоятельно определяет на сколько тайлов делиться, и правильно всё сохранит, в зависимости от DefaultURL (ну и нужного кода в скрипте по расчёту BBOX конечно, то есть от L отнимаем (R-L), а к R придбавляем (R-L)*(k-2), где k для описываемого случая равно 3). Обращаю внимание, что это не какая-то хитрая настройка для одного конкретного ресурса типа Te$$ase$ve$. Просто она создалась покуда дрючился Te$$ase$ve$. В принципе если ресурс работает через BBOX и медленно - можно его также грузить несколько тайлов за один запрос. Счётчик закачанных тайлов конечно будет думать что качаем по одному - но это однако совсем не критичная беда. | ||||
| Tags | No tags attached. | ||||
|
|
а ещё ватермарки есть у D1g1t@lGl0bе и тоже жаба душит качать кучу лишней информации. |
|
|
Предвкушаю, как будет плющить закачивалку отображаемых тайлов. Оно будет по многу раз одно и то же качать :) ибо запускает закачку нескольких тайлов в паралельных потоках. |
|
|
>по многу раз одно и то же качать Ну по идее это делается прежде всего не закачивалки отображаемого, а по выделенной области. Ну и конечно надо строить мегатайл так, чтобы дополнительные тайлы были справа и снизу, чтобы при дальнейшей скачке только что закаченные тайлы уже не перекачивались. Кстати и росреестр тоже можно облагородить. Были жалобы что на каждом тайле кадастровые номера дублируются. Сейчас можно сделать чтобы кадастровый номер был не на каждом тайле. |
|
|
Решил попробовать на слое кадастр, скачивать кусками 512х512 и резать на 4 тайла. Получается, но есть вопросы: 1. САС вычисляет URL для каждого тайла, получается, что одни и те же тайлы скачиваются по 4 раза. 2. поэтому добавил в скрипт, чтобы URL генерился только на чётные X и Y, но тогда бегают ошибки Tile not exists, а по краям иногда остаётся непрорисованный ряд тайлов (по понятной причине). 3. Не совсем понятно описание параметров, что там обязательно, а что нет. Можно ли выкинуть в данном сл. CutCountX=2 CutCountY=2 CutSizeX=256 CutSizeY=256? Как сделать всё красиво? [PARAMS] pnum=6 GUID={87428D7B-7DFA-4C98-9993-A8F3AA456608} asLayer=1 ParentSubMenu=Росреестр ParentSubMenu_en=Rosreestr ParentSubMenu_uk=Росреестр name=Кадастровые границы 4 (rosreestr.ru) name_en=Cadastre map 4 (rosreestr.ru) NameInCache=rosreestr_cadastr4 DefURLBase=http://maps.rosreestr.ru/ArcGIS/rest/services/CadastreNew/Cadastre/MapServer//export?dpi=96&transparent=true&format=png&bboxSR=102113&imageSR=102113&size=512,512&f=image ContentType="image/png" Ext=.png projection=1 sradiusa=6378137 sradiusb=6378137 separator=0 UseDwn=1 Sleep=0 DefHotKey=0 CutCountX=2 CutCountY=2 CutSizeX=256 CutSizeY=256 CutTileX=0 CutTileY=0 var i:integer; xy:TPoint; topLeftM,bottomrightM,LL:TDoublePoint; begin if (GetX mod 2 = 0) and (GetY mod 2 = 0) then begin xy.x:=GetX*256; xy.y:=GetY*256; LL:=Converter.Pos2LonLat(XY,GetZ+7); topLeftM:=Converter.LonLat2Metr(LL); xy.x:=(GetX+2)*256; xy.y:=(GetY+2)*256; LL:=Converter.Pos2LonLat(XY,GetZ+7); bottomrightM:=Converter.LonLat2Metr(LL); ResultURL:=GetURLBase+'&bbox='+RoundEx(topLeftM.x,8)+','+RoundEx(topLeftM.y,8)+','+RoundEx(bottomrightM.x,8)+','+RoundEx(bottomrightM.y,8); end end. |
|
|
так 2,3,4 тайлы не качаются ибо они уже есть в кэше. |
|
|
Качаются, наверно, сас не знает, что они есть. А может, потому, что качает не сверху вниз и слева направо, а как попало (точнее, по спирали) (при просмотре) |
|
|
у меня пропускает. Обработка файла: T:\GoogleMV\cache\lgbm\z18\78\x80174\46\y47583.jpg ... Скачивание... (Ok!) Обработка файла: T:\GoogleMV\cache\lgbm\z18\78\x80174\46\y47584.jpg ... Данный файл уже имеется в кэше Обработка файла: T:\GoogleMV\cache\lgbm\z18\78\x80174\46\y47585.jpg ... Данный файл уже имеется в кэше Обработка файла: T:\GoogleMV\cache\lgbm\z18\78\x80174\46\y47586.jpg ... Данный файл уже имеется в кэше Обработка файла: T:\GoogleMV\cache\lgbm\z18\78\x80174\46\y47587.jpg ... Данный файл уже имеется в кэше Обработка файла: T:\GoogleMV\cache\lgbm\z18\78\x80174\46\y47588.jpg ... Скачивание... |
|
|
А я про брожение по карте. |
|
|
MaxConnectToServerCount=1 спасёт всех |
|
|
Да, кстати, для закачки это надо (наверно). Но для просмотра не помогает. Если выкинуть if (GetX mod 2 = 0) and (GetY mod 2 = 0) то вообще мусор получается. |
|
|
> по краям иногда остаётся непрорисованный ряд тайлов Это решается настройкой программы: Download tile off-screen=1 Но это некрасиво. |
|
|
ну да он берёт левый пустой тайл и перетирает несколько правых. по логике всё правильно, а по юзабилити не айс. надо бы как то проверять на tileexist |
|
|
Tolik, надо строить мегатайл так, чтобы дополнительные тайлы были справа и снизу, чтобы при дальнейшей скачке только что закаченные тайлы уже не перекачивались. Это прежде всего для качалки по выделенной области в один поток. Чтобы корректно работало для многопоточной качалки на экран - надо допиливать проверку перезаписи существующих тайлов для каждого вырезанного кусочка. Ну или очередь на скачку строить с учётом формы таких "мегатайлов". Что не то чтобы даже лениво, а вообще неправильно и некрасиво. Потому что через CutToSkip можно брать вообще из "мегатайла" только отдельные нужные куски, даже не являющиеся связной областью. Это некий такой грязный хак. Работающий не во всех случаях жизни. Иногда гадящий сбоку на существующие тайлы. Но просто реализуемый и иногда крайне полезный ввиду неидеальности работы сервисов. Но исключительно под присмотром. В официальных zmp публиковать его не надо. >САС вычисляет URL для каждого тайла Да. Из всех тайлов, подлежащих скачке, будет построена очередь из урлов, и вся она будет пробовать скачаться, так как качать или нет отсутствующие - определяется по одному каждому тайлу. >получается, что одни и те же тайлы скачиваются по 4 раза Нет. Скачиваются не тайлы, а их "полуфабрикаты", этакие "мегатайлы". Тайлы (порезанные) только записываются в кэш. Один тайл может быть записан в кэш 4 раза, это верно. >Можно ли выкинуть в данном сл. CutCountX=2 CutCountY=2 CutSizeX=256 CutSizeY=256 Нельзя. То что там в запросе 512 - резалке тайлов по барабану. Оно не обязано быть кратным размеру тайла. |
|
|
Качалка, кстати, работает хорошо, тайлы появляются квадратиками по 4. Но верхний ряд и левый столбец не выкачиваются, если у них нечётный номер. |
|
|
>надо бы как то проверять на tileexist При сохранении каждого уже нарезанного кусочка проверять, что если тайл уже такой есть - ни при каких условиях его не перезаписывать что ли? Но тогда перекачка кэша с этими настройками не будет работать никогда. |
|
|
так есть режим только "интернет"(переписываем) и "интернет+кэш"(не переписываем) и ctrl-ins == переписываем все з.ы. с другой стороны этой плюшкой(МегаТайлами) пользуется пока всего 3 человека :) |
|
|
Опять же, если выкинуть if (GetX mod 2 = 0) and (GetY mod 2 = 0) , САС будет на каждый тайл скачивать большой квадрат, что не имеет смысла. Так что надо контролировать не запись в кэш скачанных кусочков, а само скачивание. То есть заставить САС генерить запросы не на каждый тайл, а только 1 раз на весь объединённый квадрат. И не таким убогим способом (как мой if), а на уровне кода. P.S. Мегатайлами будут пользоваться миллионы :) , если сделать нормальный кадастр, т.к. уже сейчас он выглядит гораздо лучше, чем обычно. Только "Tile not exists" бегают. Кстати, исправьте, пожалуйста, на "Tile does not exist". |
|
|
Ещё один вопрос: 4. Нарезка происходит с потерей качества? |
|
|
Естественно с потерей. Все обрезки выполняются с полной перепаковкой. |
|
|
Ну если использовать только для скачки (без перезаписи!), то работает хорошо (и if не нужен, т.к. на имеющийся в кэше тайл запрос не генерится). Мегатайлы 3х3 даже лучше, чем 2х2. Но для бродилки в таком виде не годится. |
|
|
>То есть заставить САС генерить запросы не на каждый тайл, а только 1 раз на весь объединённый квадрат Ума не приложу как это идеально обеспечить. Говорю ж, там можно из мегатайла писать тайлы в кэш совершенно произольные, хоть буквой Г. Даже если просто большие квадратики писать целиком (без CutToSkip) - всё равно будет криво, например, на стыке соседних областей, закачиваемых по отдельности. Хотя конечно для простых случаев алгоритмически это не сложно. Достаточно генерить к закачке только урлы по координатам, сравнимым по модулю CutCountX и CutCountY с угловой координатой (MinX,MinY для простоты), тогда если без извращений - оно и получится. Но тут я пас, я итератор в глаза не видел. Или в скрипте как-то понимать и разруливать, это для бродилки генерится урл, или для скачки по области, но исключительно на уровне самодеятельности и вообще не факт что это корректная процедура, и непонятно что показать по "ПКМ - скопировать адрес тайла", да и одиночные тайлы среди двушек и трёшек будут выглядеть совсем уж неуместно ((. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 27-04-2012 19:35 | vasketsov | New Issue | |
| 27-04-2012 19:37 | vasketsov | Assigned To | => vasketsov |
| 27-04-2012 19:37 | vasketsov | Status | new => assigned |
| 28-04-2012 03:47 | Garl | Note Added: 0006495 | |
| 28-04-2012 13:03 | vdemidov | Note Added: 0006497 | |
| 28-04-2012 14:16 | vasketsov | Note Added: 0006498 | |
| 05-05-2012 16:43 | vasketsov | Status | assigned => resolved |
| 05-05-2012 16:43 | vasketsov | Fixed in Version | => 120808 |
| 05-05-2012 16:43 | vasketsov | Resolution | open => fixed |
| 14-05-2012 08:32 | vdemidov | Product Version | 120808 => 110418 |
| 14-05-2012 08:32 | vdemidov | Target Version | => 120808 |
| 14-09-2012 09:12 | Tolik | Note Added: 0008907 | |
| 14-09-2012 09:14 | Tolik | Note Edited: 0008907 | |
| 14-09-2012 09:14 | Garl | Note Added: 0008908 | |
| 14-09-2012 09:14 | Tolik | Note Edited: 0008907 | |
| 14-09-2012 09:16 | Tolik | Note Added: 0008909 | |
| 14-09-2012 09:18 | Garl | Note Added: 0008910 | |
| 14-09-2012 09:18 | Tolik | Note Edited: 0008909 | |
| 14-09-2012 09:19 | Tolik | Note Added: 0008911 | |
| 14-09-2012 09:20 | Garl | Note Added: 0008912 | |
| 14-09-2012 09:24 | Tolik | Note Added: 0008913 | |
| 14-09-2012 09:30 | Tolik | Note Added: 0008914 | |
| 14-09-2012 09:30 | Garl | Note Added: 0008915 | |
| 14-09-2012 09:33 | vasketsov | Note Added: 0008916 | |
| 14-09-2012 09:33 | Tolik | Note Added: 0008917 | |
| 14-09-2012 09:35 | vasketsov | Note Added: 0008918 | |
| 14-09-2012 09:40 | Garl | Note Added: 0008919 | |
| 14-09-2012 09:41 | Garl | Note Edited: 0008919 | |
| 14-09-2012 09:46 | Tolik | Note Added: 0008920 | |
| 14-09-2012 09:49 | Tolik | Note Edited: 0008920 | |
| 14-09-2012 09:52 | Tolik | Note Edited: 0008920 | |
| 14-09-2012 10:09 | Tolik | Note Added: 0008921 | |
| 14-09-2012 10:18 | vdemidov | Note Added: 0008922 | |
| 14-09-2012 10:28 | Tolik | Note Added: 0008923 | |
| 14-09-2012 10:53 | vasketsov | Note Added: 0008924 | |
| 10-10-2012 11:40 | Tolik | Status | resolved => closed |
| 08-08-2025 13:24 | zed | Category | Хотелка => Хотелка / Feature request |