0000086: Загрузка тайлов вдоль пути с заданным удалением (по сути, формирование выделения вокруг пути)

Notes
(0000164) vdemidov (manager) 01-09-2010 06:51	Жду когда кто-нибудь реализует такой алгоритм. Как только кто-то предложит готовую процедуру получения полигона по пути и указанному расстоянию эта хотелка будет реализована.

(0000165) Chicatilo (reporter) 01-09-2010 09:12	В каком виде задается путь? В каком виде задается полигон? В каком виде нужна процедура?

(0000166) vdemidov (manager) 01-09-2010 12:52	Путь задается в виде массива LonLat точек. Полигон - такой же массив как и путь, только первая и последняя точки равны. Процедура желательно на Delphi. Получает массив и расстояние возвращает массив.

(0003046) rsuan (reporter) 25-06-2011 17:00 edited on: 25-06-2011 17:10	Причина: Выделять полигонально такой путь неудобно: путь может быть извилистым, и придётся проходить его точками два раза: сначала с одной стороны дороги "туда", потом с другой стороны дороги "обратно". Расположение функции: Операции с выделенной областью - "Вытянутая область" (или что-то подобное) Как бы это работало: Выбираешь функцию "Вытянутая область"; запрашивается ширина полосы, которую можно задать количеством тайлов какого-то масштаба; и начинаешь вытягивать полосу по пути следования, от начального пункта до конечного.

(0003054) vasketsov (manager) 27-06-2011 07:43	rsuan, тут беда вот в чём. vdemidov предыдущим сообщением недвусмысленно даёт понять, что хочет свести обход тайлов в полосе к обходу тайлов в произвольной области. Ну то есть не совсем к произвольной, а к области такого вида, которую сейчас программа может обработать. Формально это возможно, так как построение такой области равносильно объединению единичных областей (прямоугольников), полученных при "расширении" каждого отрезка пути во все стороны на некую величину. Однако программа пока что не умеет выполнять объединение областей. При объединении прямоугольников может получиться дырка в области выделения (например, трек идёт вдоль берега озера). Либо её надо уметь корректно облабатывать при операциях с выделенной областью (что по сути равносильно возможности выделения и скачки по kml с произвольным количеством несвязных областей и дырок в них), либо уметь соединять дырку и наружную область так, чтобы дырки формально не было (аналог - разрезание кольца, итеративно выполняется для всех дырок в полигоне). Поэтому пока что реализация через превращение такой полосы в полигон невозможна. Впрочем, интуитивно представляется, что это и не надо. Дело в том, что при операциях с выделенной областью программа тем или иным спобосом должна определить, входит или нет тот или иной тайл в область, надо ли его скачивать. Наверняка проверка для произвольного пути и расстояния не будет сильно сложнее проверки для произвольного полигона. То есть, возможно и не потребуется вообще создание полигона, равномощного пути+расстоянию.

(0003055) rsuan (reporter) 27-06-2011 13:48	Прочитал, но так и не увидел никакой проблемы. Программа умеет по полигональному выделению вычислять, какие тайлы нужно скачать? Умеет. Ну а в нашем случае выделение будет представлять собой просто сумму таких полигональных областей, которые являются разнонаправленными прямоугольниками разной длины и одной ширины. Программе просто остаётся скачать тайлы для каждого из них, и всё будет перекрываться, не будет никаких дырок и пропусков. И довод того, что нам не нужен такой тип выделения - не распонял. Да и не хочу этого понимать, для автомобилиста такой тип выделения нужен, и сложность его программной реализации не выглядит убедительной.

(0003058) Papazol (reporter) 27-06-2011 15:10	Если так сильно надо скачать "змею", можно сделать это и вручную, двигая карту мышью. Только вот опыт показывает, что зачастую как раз и не хватает пары-тройки тайлов в сторону от скачаной "змеи", а ничего уже не сделаешь, если ты в дороге. Это к вопросу о ширине захвата. С другой стороны, на мелком масштабе можно построить полигон, захватывающий нужную область, не ставя особо много точек, то есть не огибая каждый самый мелкий поворот дороги. Ну и что, если в каком-то месте будет более широкий захват, а в каком-то - поуже? В конце концов идеал - это когда есть полное покрытие местности.

(0003059) vasketsov (manager) 27-06-2011 15:56	>Ну а в нашем случае выделение будет представлять собой просто сумму таких полигональных областей, которые являются разнонаправленными прямоугольниками разной длины и одной ширины. Программе просто остаётся скачать тайлы для каждого из них, и всё будет перекрываться, не будет никаких дырок и пропусков Будут тайлы, которые попадают более чем в один прямоугольник. А значит сложность алгоритма увеличится почти квадратично (так как придётся формально проверять, что тайл уже есть в списке), причём не один раз при построении области, а КАЖДЫЙ РАЗ при скачке хотя бы одного тайла по такому выделению. Очевидно, такой костыль не настолько необходим, чтобы его привносить в программу. Корректная реализация через полигоны без нормальной реализации объединения областей (выполняемого один раз ДО скачки) невозможна. >И довод того, что нам не нужен такой тип выделения - не распонял Да нужен он, нужен, не надо нервничать. Просто пока некому его сделать. Если есть workaround и проблема не критичная - она тут может жить годами.

(0003060) vasketsov (manager) 27-06-2011 16:03	>Это к вопросу о ширине захвата Если представить себе ситуацию, что трасса грузится, чтобы по ней проехать с навигатором и сасом, то очевидно ширина захвата в (кило)метрах должна зависеть от зума. Призумился - на экран входит меньше (в километрах), но всегда загружено всё (да хоть даже с учётом числа тайлов за границей экрана). То есть как вариант - задавать расстояние в тайлах (буквально - размер экрана, не обязательно текущий). В таком виде через полигон как сейчас (обойдя трассу с двух сторон) сделано быть не может.

(0003062) rsuan (reporter) 27-06-2011 22:44 edited on: 28-06-2011 02:57	> Если так сильно надо скачать "змею", можно сделать это и вручную, двигая карту мышью. Ну сами понимаете, это гораздо дольше. Или мы в мелком масштабе просто потыкаем точки, или в крупном будем крутить карту со скоростью передвижения автомобиля (я занимался этим, ой как неудобно и долго!..). > Будут тайлы, которые попадают более чем в один прямоугольник. А значит сложность алгоритма увеличится почти квадратично. Не согласен. У программы имеется "список" имеющихся тайлов в кеше, и при скачке тайлов выделенной полигональной области (при снятой галке "заменять старые файлы") программа без проблем проверяет их наличие и быстро пропускает те, которые уже есть. Так пусть во время скачки нашего нового типа выделения программа ведёт ещё один список тайлов, которые скачаны во время _данной_ загрузки, и проверяет их наличие вдобавок и по этому второму списку. Время, затрачиваемое на проверку наличия тайлов, увеличится максимум в 2 раза, что совсем не значительно на фоне того, как быстро проверяется сейчас при скачке полигональной области. Я понял, в чём может быть сложность у этого типа выделения. Сложность не в выборе, какие тайлы скачивать, а в "вырисовке" такой области на карте во время выделения, то бишь в определении точек получаемого полигона. Но и тут, думаю, всё решаемо. У соединяемых прямоугольников, для каждой из пары сторон (одна сторона одного прямоугольника и та же сторона второго, вторая сторона одного пр-ка и та же сторона второго) пусть определяются точки пересечения (у внутреннего угла стороны будут пересекаться, а у внешнего - точка пересечения будет находиться на продолжении сторон). Думаю, для определения точек пересечения отрезков формула существует. Таким образом точками, по которым строится выделение, будут эти получившиеся точки пересечения.

(0003064) Tolik (manager) 28-06-2011 09:38	> Если представить себе ситуацию, что трасса грузится, чтобы по ней проехать с навигатором и сасом, то очевидно ширина захвата в (кило)метрах должна зависеть от зума. Вот! Это и есть главное отличие новой фичи! Смысл не в том, чтобы нарисовать полигон вокруг трассы, а потом скачать, т.к. на больших зумах скачивать придётся очень много ненужных тайлов. Юзер должен нарисовать путь и указать, сколько тайлов надо скачать с каждой стороны (фактически, свой размер экрана, с запасом). Так что задача не сводится к "процедуре получения полигона по пути и указанному расстоянию". Ну или надо такой полигон формировать для каждого зума отдельно.

(0003068) rsuan (reporter) 28-06-2011 13:14 edited on: 28-06-2011 13:20	Примерный алгоритм получения точек такого полигона. Простой пример из трёх точек: Нажал первую точку, программа просто её отобразила. Нажал вторую, получили вектор, вычисляются точки первого прямоугольника: - от первой точки вправо относительно вектора на половину ширины (точка A), - от первой точки влево относительно вектора на половину ширины (точка B), - от второй точки влево относительно вектора на половину ширины (точка C), - от второй точки вправо относительно вектора на половину ширины (точка D). Строится прямоугольник ABCD. Нажал третью точку, вычисляются точки второго прямоугольника, аналогично предыдущему, только фигурируют вторая и третья нажатые точки. Вычисляются точки пересечения сторон первого и второго прямоугольника (как было описано в предыдущем моём посте). Точки C и D заменяются на них, а "заканчивается" второй прямоугольник точками E и F, полученными при его вычислении. Строится полигон ABCEFD.

(0003075) gpsMax (manager) 28-06-2011 14:52	А чего делать, если путь заворачивается в кольцо? Это уже будет не полигон как бы, внутренняя дырка мешает.

(0003076) rsuan (reporter) 28-06-2011 14:59 edited on: 28-06-2011 15:36	Для программы это всё равно будет полигон, ведь присутствуют начальная, промежуточные и конечная точки. Т.е. пользователь начинает, продолжает и заканчивает выделять.

(0003083) rsuan (reporter) 28-06-2011 22:12	Подумалось тут: если угол, образованный двумя отрезками, очень острый, то точка пересечения продолжений сторон вычисленного прямоугольника на внешнем углу будет стремиться к бесконечности, поэтому на внешнем углу лучше не вычислять точку пересечения, а просто задействовать точки самих вычисленных прямоугольников. А точкой на внутреннем углу, как и говорилось выше, пусть будет точка пересечения сторон прямоугольников.

(0003086) vdemidov (manager) 29-06-2011 04:13	Можно создавать по пути не полигон, а итератор тайлов, то есть объект с методом function Next(out ATile: TPoint): boolean; В любом случае дата озвучена. Если никто не напишет свой алгоритм на делфи, она может только переноситься на более позднее время.

(0003663) rsuan (reporter) 02-09-2011 17:11	Эх, как не хватает этого инструмента выделения... Столько дорог надо скачать...

(0003665) zOn (reporter) 03-09-2011 09:15	а кто-нибудь из программистов сможет подглядеть на гис-лабе, как они делают границы регионов именно такого типа. т.е. они "двоят" границу на +20- км. Кажется они это делают в qGis (исходники доступны). Я нефига не понимаю в программировании, а так бы сам нарыл.

(0003699) feya (manager) 05-09-2011 15:25	в общем сделал функцию преобразования линии в полигон с заданным "радиусом", теперь осталось за малым - добавить в интерфейс программы нужные кнопки. Меняю целевую версию на следущую.

(0003730) rsuan (reporter) 06-09-2011 11:00	Вот спасибо огромное! Жду следующую версию! Надеюсь не только мне эта функция пригодится...

(0003737) feya (manager) 06-09-2011 11:49	Сделано. Добавлен новый тип выделения - линия.

(0003738) feya (manager) 06-09-2011 11:50	rsuan, следующую версию можно не ждать, качайте завтра "ночную" сборку.

(0003756) gpsMax (manager) 06-09-2011 20:06	В ночных сборках то одно, то другое отваливается, увы. Хотелось бы какой-нибудь стабильной версии, без экспериментальных кусков на полпути. Мониторинг изменений в репозитории бы спас положение, но, во-первых, код программы закрытый, а, во-вторых, лично я не знаю, как это делать в меркуриале, TortoiseHg не имеет такой опции (хотя TortoiseSvn имеет).

(0003762) vdemidov (manager) 07-09-2011 05:07	И что ж это в ночных версиях отваливалось в последнее время? Кое что по мелочи бывает, но обычно исправляется на следующий же день.

(0003778) zed (manager) 07-09-2011 16:47	>Мониторинг изменений в репозитории бы спас положение В ночных сборках есть лог коммитов.

Users who viewed this issue
User List	Anonymous (3357x), vdemidov (1x)
Total Views	3358
Last View	20-04-2024 07:00

Issue History
Date Modified	Username	Field	Change
01-09-2010 02:24	Chicatilo	New Issue
01-09-2010 06:51	vdemidov	Note Added: 0000164
01-09-2010 06:51	vdemidov	Status	new => acknowledged
01-09-2010 06:51	vdemidov	Product Version	=> 100707
01-09-2010 06:51	vdemidov	Target Version	=> 40xxxx
01-09-2010 09:12	Chicatilo	Note Added: 0000165
01-09-2010 12:52	vdemidov	Note Added: 0000166
06-04-2011 23:25	gpsMax	Tag Attached: выделение
06-04-2011 23:25	gpsMax	Tag Attached: плагины
06-04-2011 23:25	gpsMax	Summary	Загрузка тайлов по пути. => Загрузка тайлов по пути
06-04-2011 23:26	gpsMax	Summary	Загрузка тайлов по пути => Загрузка тайлов вдоль пути с заданным удалением (по сути, формирование выделения вокруг пути)
06-04-2011 23:26	gpsMax	Description Updated	View Revisions
11-04-2011 07:11	vdemidov	Status	acknowledged => confirmed
20-06-2011 21:23	gpsMax	Relationship added	has duplicate 0000812
25-06-2011 16:46	zed	Relationship added	has duplicate 0000814
25-06-2011 17:00	rsuan	Note Added: 0003046
25-06-2011 17:06	rsuan	Note Edited: 0003046	View Revisions
25-06-2011 17:10	rsuan	Note Edited: 0003046	View Revisions
27-06-2011 07:43	vasketsov	Note Added: 0003054
27-06-2011 13:48	rsuan	Note Added: 0003055
27-06-2011 15:10	Papazol	Note Added: 0003058
27-06-2011 15:56	vasketsov	Note Added: 0003059
27-06-2011 16:03	vasketsov	Note Added: 0003060
27-06-2011 22:44	rsuan	Note Added: 0003062
27-06-2011 22:45	rsuan	Note Edited: 0003062	View Revisions
27-06-2011 22:59	rsuan	Note Edited: 0003062	View Revisions
27-06-2011 23:39	rsuan	Note Edited: 0003062	View Revisions
28-06-2011 02:57	rsuan	Note Edited: 0003062	View Revisions
28-06-2011 09:38	Tolik	Note Added: 0003064
28-06-2011 13:14	rsuan	Note Added: 0003068
28-06-2011 13:19	rsuan	Note Edited: 0003068	View Revisions
28-06-2011 13:20	rsuan	Note Edited: 0003068	View Revisions
28-06-2011 14:52	gpsMax	Note Added: 0003075
28-06-2011 14:59	rsuan	Note Added: 0003076
28-06-2011 15:12	rsuan	Note Edited: 0003076	View Revisions
28-06-2011 15:36	rsuan	Note Edited: 0003076	View Revisions
28-06-2011 22:12	rsuan	Note Added: 0003083
29-06-2011 04:13	vdemidov	Note Added: 0003086
02-09-2011 17:11	rsuan	Note Added: 0003663
03-09-2011 09:15	zOn	Note Added: 0003665
05-09-2011 15:25	feya	Note Added: 0003699
05-09-2011 15:26	feya	Target Version	40xxxx => 120808
06-09-2011 11:00	rsuan	Note Added: 0003730
06-09-2011 11:49	feya	Note Added: 0003737
06-09-2011 11:49	feya	Status	confirmed => resolved
06-09-2011 11:49	feya	Fixed in Version	=> 120808
06-09-2011 11:49	feya	Resolution	open => fixed
06-09-2011 11:49	feya	Assigned To	=> feya
06-09-2011 11:50	feya	Note Added: 0003738
06-09-2011 20:06	gpsMax	Note Added: 0003756
07-09-2011 05:07	vdemidov	Note Added: 0003762
07-09-2011 16:47	zed	Note Added: 0003778
24-01-2012 11:17	gpsMax	Relationship added	related to 0001088
10-10-2012 11:50	Tolik	Status	resolved => closed
26-07-2013 07:47	vasketsov	Relationship added	related to 0002049
29-08-2018 12:27	zed	Relationship added	related to 0002450

SASGIS