View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002049SAS.ПланетаРефакторингpublic26-07-2013 07:4619-08-2019 08:00
Reportervasketsov 
Assigned Tozed 
PrioritynormalSeveritytweakReproducibilityalways
StatusresolvedResolutionfixed 
PlatformWindowsOSVistaOS VersionUltimate
Product Version121010 
Target Version181221Fixed in Version181221 
Summary0002049: Необходимо переделать выделение области вокруг пути (трека)
DescriptionНеобходимо АККУРАТНО посмотреть, чего наделано в доработке 0000086.
Особенных знаний внутренностей саса не надо, там по идее только математика, так что как помощь от новичков, вполне сойдёт, хотя зубры справятся быстрее ))).

Анамнез: при выделении вокруг реальных длинные треков с изгибами:
а) всегда образуются некие "выстрелы" и "ёжики", торчащие острыми углами в разные стороны;
б) граница выделения содержит множество самопересечений;
в) даже там где ничего такого страшного нет, линия выделения получается недостаточно сглаженная.
TagsNo tags attached.
Attached Filespng file icon 1.png [^] (106,406 bytes) 26-07-2013 23:00


png file icon 2.png [^] (22,833 bytes) 26-07-2013 23:00


png file icon 3.png [^] (3,670 bytes) 26-07-2013 23:00


png file icon 4.png [^] (10,758 bytes) 26-07-2013 23:01


png file icon 5.png [^] (12,243 bytes) 26-07-2013 23:01


png file icon X.png [^] (66,242 bytes) 26-07-2013 23:02

- Relationships
related to 0000086closedfeya Загрузка тайлов вдоль пути с заданным удалением (по сути, формирование выделения вокруг пути) 
related to 0002450resolvedzed При выделении области по треку внутри области получаются дырки 
related to 0003364resolvedzed Добавить счётчики производительности алгоритмов построения полигона по пути/треку 
related to 0003439closedvdemidov Выделение вдоль пути создаёт область с границами не везде параллельными пути 
related to 0003544resolvedzed Операция создания области по треку работает совершенно неудовлетворительно 

-  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 (2127x), Oniman777 (1x), Parasite (1x), ygorigor (3x), Tolik (1x), ingener (1x), vdemidov (4x), Spojler (1x), zed (5x)
Total Views 2144
Last View 09-08-2020 02:49

- 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 => 25xxxx
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 25xxxx => 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



Copyright © 2007 - 2020 SAS.Planet Team