0002049: Необходимо переделать выделение области вокруг пути (трека)

Notes
(0012207) vdemidov (manager) 26-07-2013 08:24	Тут возможны два варианта: 1. Оставить построение полигона в спроецировнном виде как есть сейчас. Тогда можно будет применять готовые библиотеки для работы на плоскости. Например в том же GR32 у полигона есть методы для этого и они сейчас используются для отрисовки толстых линий и толстых границ полигонов меток. 2. Так как сейчас есть методы проецирования точки, то можно сделать построение полигона вообще не зависящим от проекции (а только от датума), но тогда все операции придется делать самим.

(0012211) vasketsov (manager) 26-07-2013 09:50	>в том же GR32...для отрисовки толстых линий Кстати, да. Это ж фактически очень толстая линия получается. Вот только что на углах будет получаться... хотя по большому счёту пофигу, дуга или угол. >можно сделать построение полигона вообще не зависящим от проекции А что в этом конкретном контексте (выделения вдоль пути) выиграется от этого? Равномерность ширины полосы вокруг пути при сильно разных широтах, если трек протяжён с севера на юг?

(0012212) vdemidov (manager) 26-07-2013 10:01	>Кстати, да. Это ж фактически очень толстая линия получается. Вот только что на углах будет получаться... хотя по большому счёту пофигу, дуга или угол. Там вроде задается степень сглаживания, но проблему составляет то, что координаты не должны выходить за диапазон -32000..+32000, а это сложно. В пределах одного тайла это не проблема, а вот в пределах всего полигона возникнут вопросы. В новой версии GR32 вроде как полностью переделали работу с полигонами, но там еще не было стабильного релиза. >А что в этом конкретном контексте (выделения вдоль пути) выиграется от этого? Равномерность ширины полосы вокруг пути при сильно разных широтах, если трек протяжён с севера на юг? Ну это плюс всякие искажения, потому что в каждой точке меркатора свой масштаб да еще и разный по вертикали и горизонтали.

(0012213) Papazol (reporter) 26-07-2013 11:36	В существующем виде этой фичи ширина захвата задаётся в метрах/километрах, что противоречит задаче скачивания на каждом зуме только нужных тайлов. Как бы это исправить?

(0012214) vdemidov (manager) 26-07-2013 11:41	Сейчас все операции по области работают только с полигонами, что бы получить полигон по точке или пути нужно задавать расстояние в метрах или километрах. Если хочется переформулировать, придется все операции переписать. Так что в ближайшее время это не исправить никак, только сделать более правильное построение полигона.

(0012215) Papazol (reporter) 26-07-2013 12:06	Расстояние в метрах = 256(известное соотношение метры/пиксели)желаемое количество тайлов.

(0012216) vdemidov (manager) 26-07-2013 12:14	Ну так никто не запрещает, более того это будет даже проще чем сейчас. Нужно только просить ввода зума и количества тайлов, а не расстояния. Но я пока такой хотелки не встречал.

(0012217) Papazol (reporter) 26-07-2013 12:24	vasketsov в инциденте 000...86: >Если представить себе ситуацию, что трасса грузится, чтобы по ней проехать с навигатором и сасом, то очевидно ширина захвата в (кило)метрах должна зависеть от зума. Призумился - на экран входит меньше (в километрах), но всегда загружено всё (да хоть даже с учётом числа тайлов за границей экрана). То есть как вариант - задавать расстояние в тайлах (буквально - размер экрана, не обязательно текущий).< Зум и так задаётся, только уже в операциях с выделенной областью. Придётся его задавать дважды?

(0012218) vasketsov (manager) 26-07-2013 12:51	>более того это будет даже проще чем сейчас На самом деле надо оба варианта. И в хотелке было про оба варианта (в комментах, впрочем отдельной не было). Идеальный вариант - в диалоге указания ширины указать, в тайлах это или в километрах или вообще в угловых секундах каких-нибудь. Но пока что задача - нормалировать то, на что сейчас без слёз не взглянешь.

(0012219) vdemidov (manager) 26-07-2013 12:53	Я еще раз повторяю, во всех операциях с выделенной областью работа идет с уже заданным полигоном. Что бы полигон построить по пути нужно задать ширину тем или иным способом. Или в метрах, или в тайлах, или в попугаях, не важно, но это нужно делать до открытия окна операции с областью.

(0012220) vasketsov (manager) 26-07-2013 13:02 edited on: 26-07-2013 13:04	>во всех операциях с выделенной областью работа идет с уже заданным полигоном На самом деле мы все понимаем, что работа идёт с итератором, запускаемым по выделенной области. И в этом смысле, если бы существовал итератор, который бы умел выплёвывать тайлы по треку (независимо от способа указания ширины) без построения полигона текущего выделения, он отлично бы работал наверное во всех операциях с выделенной областью. Даже сохранение-восстановление закачки было бы возможно (если сохранить все данные для восстановления итератора). Но поскольку такое поведение (работа по выделенной области без самой явно определённой выделенной области) не очень прозрачно для конечного юзера, приходится констатировать, что: >это нужно делать до открытия окна операции с областью Однако если мы говорим о задании расстояния вокруг пути в тайлах (а не в км или градусах), то вообще говоря сама по себе выделенная область в этом случае может быть прямым выхлопом по результатам работы такого вот неполигонального итератора. Насколько это через задницу в плане реализации - вопрос непростой.

(0012221) vdemidov (manager) 26-07-2013 13:16	>>во всех операциях с выделенной областью работа идет с уже заданным полигоном >На самом деле мы все понимаем, что работа идёт с итератором, запускаемым по выделенной области. Не всегда. Склейка идет без итератора. Плюс многие операции выполняются не по одному итератору, а по целому набору (много зумов, а при копировании еще и много карт). Но во многих случаях это правда и я давно хочу это переделать и слегка обобщить, просто толку от этого будет не сильно много. Плюс тогда странно будет работать сохранение последнего выделения.

(0012239) vasketsov (manager) 26-07-2013 23:00	Поигрался с шириной полилинии в свойствах метки (сделал ширину 20). Разные картинки широкой линии - это для разных зумов. Видно в правой части, что артефакты присутствуют, но терпимые. И ещё пример приаттачен - выделение полигоном как сейчас (1200м). Вертикальные линии - просто границы других меток (отключать их было лениво).

(0018394) zed (manager) 29-08-2018 12:15	Переделал, наконец, этот алгоритм. Как оказалось, есть общеизвестное решение данной задачи (гуглить Minkowsky sum) и используемой нами библиотеке Clipper даже есть его реализация. Так что его оставалось просто адаптировать под наши нужды. В реальных юзкейсах, на реальных треках, где старый алгоритм лажал по полной, этот алгоритм работает отлично. Старый алгоритм пока оставил для случая ручного "Выделения по пути". Там всегда можно поставить лишнюю точку и сгладить огрехи при желании.

Users who viewed this issue
User List	Anonymous (3706x), Oniman777 (1x), Parasite (1x), ygorigor (3x), Tolik (1x), ingener (1x), vdemidov (4x), Spojler (1x), zed (5x)
Total Views	3723
Last View	23-11-2024 08:09

Issue History
Date Modified	Username	Field	Change
26-07-2013 07:46	vasketsov	New Issue
26-07-2013 07:47	vasketsov	Relationship added	related to 0000086
26-07-2013 08:24	vdemidov	Note Added: 0012207
26-07-2013 09:50	vasketsov	Note Added: 0012211
26-07-2013 10:01	vdemidov	Note Added: 0012212
26-07-2013 11:36	Papazol	Note Added: 0012213
26-07-2013 11:41	vdemidov	Note Added: 0012214
26-07-2013 12:06	Papazol	Note Added: 0012215
26-07-2013 12:14	vdemidov	Note Added: 0012216
26-07-2013 12:24	Papazol	Note Added: 0012217
26-07-2013 12:51	vasketsov	Note Added: 0012218
26-07-2013 12:53	vdemidov	Note Added: 0012219
26-07-2013 13:02	vasketsov	Note Added: 0012220
26-07-2013 13:04	vasketsov	Note Edited: 0012220	View Revisions
26-07-2013 13:16	vdemidov	Note Added: 0012221
26-07-2013 23:00	vasketsov	Note Added: 0012239
26-07-2013 23:00	vasketsov	File Added: 1.png
26-07-2013 23:00	vasketsov	File Added: 2.png
26-07-2013 23:00	vasketsov	File Added: 3.png
26-07-2013 23:01	vasketsov	File Added: 4.png
26-07-2013 23:01	vasketsov	File Added: 5.png
26-07-2013 23:02	vasketsov	File Added: X.png
31-07-2013 08:13	vdemidov	Status	new => confirmed
31-07-2013 08:13	vdemidov	Product Version	=> 121010
31-07-2013 08:13	vdemidov	Target Version	=> 26xxxx
29-08-2018 12:15	zed	Note Added: 0018394
29-08-2018 12:16	zed	Status	confirmed => resolved
29-08-2018 12:16	zed	Fixed in Version	=> 181221
29-08-2018 12:16	zed	Resolution	open => fixed
29-08-2018 12:16	zed	Assigned To	=> zed
29-08-2018 12:16	zed	Target Version	26xxxx => 181221
29-08-2018 12:21	zed	Relationship added	related to 0002450
30-08-2018 11:32	zed	Relationship added	related to 0003364
29-05-2019 12:07	zed	Relationship added	related to 0003439
19-08-2019 08:00	zed	Relationship added	related to 0003544

SASGIS