SASGIS - SAS.Планета |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0002049 | SAS.Планета | Рефакторинг | public | 26-07-2013 07:46 | 19-08-2019 08:00 |
|
| Reporter | vasketsov | |
| Assigned To | zed | |
| Priority | normal | Severity | tweak | Reproducibility | always |
| Status | resolved | Resolution | fixed | |
| Platform | Windows | OS | Vista | OS Version | Ultimate |
| Product Version | 121010 | |
| Target Version | 181221 | Fixed in Version | 181221 | |
|
| Summary | 0002049: Необходимо переделать выделение области вокруг пути (трека) |
| Description | Необходимо АККУРАТНО посмотреть, чего наделано в доработке 0000086.
Особенных знаний внутренностей саса не надо, там по идее только математика, так что как помощь от новичков, вполне сойдёт, хотя зубры справятся быстрее ))).
Анамнез: при выделении вокруг реальных длинные треков с изгибами:
а) всегда образуются некие "выстрелы" и "ёжики", торчащие острыми углами в разные стороны;
б) граница выделения содержит множество самопересечений;
в) даже там где ничего такого страшного нет, линия выделения получается недостаточно сглаженная. |
| Steps To Reproduce | |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | | related to | 0000086 | closed | feya | Загрузка тайлов вдоль пути с заданным удалением (по сути, формирование выделения вокруг пути) | | related to | 0002450 | resolved | zed | При выделении области по треку внутри области получаются дырки | | related to | 0003364 | resolved | zed | Добавить счётчики производительности алгоритмов построения полигона по пути/треку | | related to | 0003439 | closed | vdemidov | Выделение вдоль пути создаёт область с границами не везде параллельными пути | | related to | 0003544 | resolved | zed | Операция создания области по треку работает совершенно неудовлетворительно |
|
| Attached Files |  1.png (106,406) 26-07-2013 23:00
https://bugtracker.sasgis.org/file_download.php?file_id=1453&type=bug
2.png (22,833) 26-07-2013 23:00
https://bugtracker.sasgis.org/file_download.php?file_id=1454&type=bug
3.png (3,670) 26-07-2013 23:00
https://bugtracker.sasgis.org/file_download.php?file_id=1455&type=bug
4.png (10,758) 26-07-2013 23:01
https://bugtracker.sasgis.org/file_download.php?file_id=1456&type=bug
5.png (12,243) 26-07-2013 23:01
https://bugtracker.sasgis.org/file_download.php?file_id=1457&type=bug
X.png (66,242) 26-07-2013 23:02
https://bugtracker.sasgis.org/file_download.php?file_id=1458&type=bug
|
|
| 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 | bug_revision_view_page.php?bugnote_id=12220#r5587 |
| 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 |
|
Notes |
|
|
|
Тут возможны два варианта:
1. Оставить построение полигона в спроецировнном виде как есть сейчас. Тогда можно будет применять готовые библиотеки для работы на плоскости. Например в том же GR32 у полигона есть методы для этого и они сейчас используются для отрисовки толстых линий и толстых границ полигонов меток.
2. Так как сейчас есть методы проецирования точки, то можно сделать построение полигона вообще не зависящим от проекции (а только от датума), но тогда все операции придется делать самим. |
|
|
|
|
>в том же GR32...для отрисовки толстых линий
Кстати, да. Это ж фактически очень толстая линия получается. Вот только что на углах будет получаться... хотя по большому счёту пофигу, дуга или угол.
>можно сделать построение полигона вообще не зависящим от проекции
А что в этом конкретном контексте (выделения вдоль пути) выиграется от этого? Равномерность ширины полосы вокруг пути при сильно разных широтах, если трек протяжён с севера на юг? |
|
|
|
|
>Кстати, да. Это ж фактически очень толстая линия получается. Вот только что на углах будет получаться... хотя по большому счёту пофигу, дуга или угол.
Там вроде задается степень сглаживания, но проблему составляет то, что координаты не должны выходить за диапазон -32000..+32000, а это сложно. В пределах одного тайла это не проблема, а вот в пределах всего полигона возникнут вопросы. В новой версии GR32 вроде как полностью переделали работу с полигонами, но там еще не было стабильного релиза.
>А что в этом конкретном контексте (выделения вдоль пути) выиграется от этого? Равномерность ширины полосы вокруг пути при сильно разных широтах, если трек протяжён с севера на юг?
Ну это плюс всякие искажения, потому что в каждой точке меркатора свой масштаб да еще и разный по вертикали и горизонтали. |
|
|
|
|
|
В существующем виде этой фичи ширина захвата задаётся в метрах/километрах, что противоречит задаче скачивания на каждом зуме только нужных тайлов. Как бы это исправить? |
|
|
|
|
|
Сейчас все операции по области работают только с полигонами, что бы получить полигон по точке или пути нужно задавать расстояние в метрах или километрах. Если хочется переформулировать, придется все операции переписать. Так что в ближайшее время это не исправить никак, только сделать более правильное построение полигона. |
|
|
|
|
|
Расстояние в метрах = 256*(известное соотношение метры/пиксели)*желаемое количество тайлов. |
|
|
|
|
|
Ну так никто не запрещает, более того это будет даже проще чем сейчас. Нужно только просить ввода зума и количества тайлов, а не расстояния. Но я пока такой хотелки не встречал. |
|
|
|
|
vasketsov в инциденте 000...86:
>Если представить себе ситуацию, что трасса грузится, чтобы по ней проехать с навигатором и сасом, то очевидно ширина захвата в (кило)метрах должна зависеть от зума. Призумился - на экран входит меньше (в километрах), но всегда загружено всё (да хоть даже с учётом числа тайлов за границей экрана). То есть как вариант - задавать расстояние в тайлах (буквально - размер экрана, не обязательно текущий).<
Зум и так задаётся, только уже в операциях с выделенной областью. Придётся его задавать дважды? |
|
|
|
|
>более того это будет даже проще чем сейчас
На самом деле надо оба варианта.
И в хотелке было про оба варианта (в комментах, впрочем отдельной не было).
Идеальный вариант - в диалоге указания ширины указать, в тайлах это или в километрах или вообще в угловых секундах каких-нибудь.
Но пока что задача - нормалировать то, на что сейчас без слёз не взглянешь. |
|
|
|
|
|
Я еще раз повторяю, во всех операциях с выделенной областью работа идет с уже заданным полигоном. Что бы полигон построить по пути нужно задать ширину тем или иным способом. Или в метрах, или в тайлах, или в попугаях, не важно, но это нужно делать до открытия окна операции с областью. |
|
|
|
(0012220)
|
|
vasketsov
|
26-07-2013 13:02
(edited on: 26-07-2013 13:04) |
|
>во всех операциях с выделенной областью работа идет с уже заданным полигоном
На самом деле мы все понимаем, что работа идёт с итератором, запускаемым по выделенной области.
И в этом смысле, если бы существовал итератор, который бы умел выплёвывать тайлы по треку (независимо от способа указания ширины) без построения полигона текущего выделения, он отлично бы работал наверное во всех операциях с выделенной областью. Даже сохранение-восстановление закачки было бы возможно (если сохранить все данные для восстановления итератора).
Но поскольку такое поведение (работа по выделенной области без самой явно определённой выделенной области) не очень прозрачно для конечного юзера, приходится констатировать, что:
>это нужно делать до открытия окна операции с областью
Однако если мы говорим о задании расстояния вокруг пути в тайлах (а не в км или градусах), то вообще говоря сама по себе выделенная область в этом случае может быть прямым выхлопом по результатам работы такого вот неполигонального итератора. Насколько это через задницу в плане реализации - вопрос непростой.
|
|
|
|
|
>>во всех операциях с выделенной областью работа идет с уже заданным полигоном
>На самом деле мы все понимаем, что работа идёт с итератором, запускаемым по выделенной области.
Не всегда. Склейка идет без итератора. Плюс многие операции выполняются не по одному итератору, а по целому набору (много зумов, а при копировании еще и много карт). Но во многих случаях это правда и я давно хочу это переделать и слегка обобщить, просто толку от этого будет не сильно много. Плюс тогда странно будет работать сохранение последнего выделения. |
|
|
|
|
Поигрался с шириной полилинии в свойствах метки (сделал ширину 20).
Разные картинки широкой линии - это для разных зумов.
Видно в правой части, что артефакты присутствуют, но терпимые.
И ещё пример приаттачен - выделение полигоном как сейчас (1200м).
Вертикальные линии - просто границы других меток (отключать их было лениво). |
|
|
|
(0018394)
|
|
zed
|
|
29-08-2018 12:15
|
|
Переделал, наконец, этот алгоритм. Как оказалось, есть общеизвестное решение данной задачи (гуглить Minkowsky sum) и используемой нами библиотеке Clipper даже есть его реализация. Так что его оставалось просто адаптировать под наши нужды. В реальных юзкейсах, на реальных треках, где старый алгоритм лажал по полной, этот алгоритм работает отлично.
Старый алгоритм пока оставил для случая ручного "Выделения по пути". Там всегда можно поставить лишнюю точку и сгладить огрехи при желании. |
|