|
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 даже есть его реализация. Так что его оставалось просто адаптировать под наши нужды. В реальных юзкейсах, на реальных треках, где старый алгоритм лажал по полной, этот алгоритм работает отлично.
Старый алгоритм пока оставил для случая ручного "Выделения по пути". Там всегда можно поставить лишнюю точку и сгладить огрехи при желании. |
|
1.png (106,406) 26-07-2013 23:00