View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000086 | SAS.Планета | Хотелка / Feature request | public | 01-09-2010 02:24 | 29-08-2018 12:27 |
| Reporter | Chicatilo | Assigned To | feya | ||
| Priority | none | Severity | feature | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | 100707 | ||||
| Target Version | 120808 | Fixed in Version | 120808 | ||
| Summary | 0000086: Загрузка тайлов вдоль пути с заданным удалением (по сути, формирование выделения вокруг пути) | ||||
| Description | Хотелось бы иметь возможность "операций с выделенной областью" вдоль пути с заданным удалением. Т.е. по сути, нужно формирование полигонного выделения вокруг заданного пути. | ||||
| Tags | выделение, плагины | ||||
| has duplicate | 0000812 | closed | Tolik | Карты по маршруту |
| has duplicate | 0000814 | closed | zed | Новый тип выделения области: полосой |
| related to | 0001088 | closed | vdemidov | Ошибка при выделении области по треку и ширине |
| related to | 0002049 | resolved | zed | Необходимо переделать выделение области вокруг пути (трека) |
| related to | 0002450 | resolved | zed | При выделении области по треку внутри области получаются дырки |
|
|
Жду когда кто-нибудь реализует такой алгоритм. Как только кто-то предложит готовую процедуру получения полигона по пути и указанному расстоянию эта хотелка будет реализована. |
|
|
В каком виде задается путь? В каком виде задается полигон? В каком виде нужна процедура? |
|
|
Путь задается в виде массива LonLat точек. Полигон - такой же массив как и путь, только первая и последняя точки равны. Процедура желательно на Delphi. Получает массив и расстояние возвращает массив. |
|
|
Причина: Выделять полигонально такой путь неудобно: путь может быть извилистым, и придётся проходить его точками два раза: сначала с одной стороны дороги "туда", потом с другой стороны дороги "обратно". Расположение функции: Операции с выделенной областью - "Вытянутая область" (или что-то подобное) Как бы это работало: Выбираешь функцию "Вытянутая область"; запрашивается ширина полосы, которую можно задать количеством тайлов какого-то масштаба; и начинаешь вытягивать полосу по пути следования, от начального пункта до конечного. |
|
|
rsuan, тут беда вот в чём. vdemidov предыдущим сообщением недвусмысленно даёт понять, что хочет свести обход тайлов в полосе к обходу тайлов в произвольной области. Ну то есть не совсем к произвольной, а к области такого вида, которую сейчас программа может обработать. Формально это возможно, так как построение такой области равносильно объединению единичных областей (прямоугольников), полученных при "расширении" каждого отрезка пути во все стороны на некую величину. Однако программа пока что не умеет выполнять объединение областей. При объединении прямоугольников может получиться дырка в области выделения (например, трек идёт вдоль берега озера). Либо её надо уметь корректно облабатывать при операциях с выделенной областью (что по сути равносильно возможности выделения и скачки по kml с произвольным количеством несвязных областей и дырок в них), либо уметь соединять дырку и наружную область так, чтобы дырки формально не было (аналог - разрезание кольца, итеративно выполняется для всех дырок в полигоне). Поэтому пока что реализация через превращение такой полосы в полигон невозможна. Впрочем, интуитивно представляется, что это и не надо. Дело в том, что при операциях с выделенной областью программа тем или иным спобосом должна определить, входит или нет тот или иной тайл в область, надо ли его скачивать. Наверняка проверка для произвольного пути и расстояния не будет сильно сложнее проверки для произвольного полигона. То есть, возможно и не потребуется вообще создание полигона, равномощного пути+расстоянию. |
|
|
Прочитал, но так и не увидел никакой проблемы. Программа умеет по полигональному выделению вычислять, какие тайлы нужно скачать? Умеет. Ну а в нашем случае выделение будет представлять собой просто сумму таких полигональных областей, которые являются разнонаправленными прямоугольниками разной длины и одной ширины. Программе просто остаётся скачать тайлы для каждого из них, и всё будет перекрываться, не будет никаких дырок и пропусков. И довод того, что нам не нужен такой тип выделения - не распонял. Да и не хочу этого понимать, для автомобилиста такой тип выделения нужен, и сложность его программной реализации не выглядит убедительной. |
|
|
Если так сильно надо скачать "змею", можно сделать это и вручную, двигая карту мышью. Только вот опыт показывает, что зачастую как раз и не хватает пары-тройки тайлов в сторону от скачаной "змеи", а ничего уже не сделаешь, если ты в дороге. Это к вопросу о ширине захвата. С другой стороны, на мелком масштабе можно построить полигон, захватывающий нужную область, не ставя особо много точек, то есть не огибая каждый самый мелкий поворот дороги. Ну и что, если в каком-то месте будет более широкий захват, а в каком-то - поуже? В конце концов идеал - это когда есть полное покрытие местности. |
|
|
>Ну а в нашем случае выделение будет представлять собой просто сумму таких полигональных областей, которые являются разнонаправленными прямоугольниками разной длины и одной ширины. Программе просто остаётся скачать тайлы для каждого из них, и всё будет перекрываться, не будет никаких дырок и пропусков Будут тайлы, которые попадают более чем в один прямоугольник. А значит сложность алгоритма увеличится почти квадратично (так как придётся формально проверять, что тайл уже есть в списке), причём не один раз при построении области, а КАЖДЫЙ РАЗ при скачке хотя бы одного тайла по такому выделению. Очевидно, такой костыль не настолько необходим, чтобы его привносить в программу. Корректная реализация через полигоны без нормальной реализации объединения областей (выполняемого один раз ДО скачки) невозможна. >И довод того, что нам не нужен такой тип выделения - не распонял Да нужен он, нужен, не надо нервничать. Просто пока некому его сделать. Если есть workaround и проблема не критичная - она тут может жить годами. |
|
|
>Это к вопросу о ширине захвата Если представить себе ситуацию, что трасса грузится, чтобы по ней проехать с навигатором и сасом, то очевидно ширина захвата в (кило)метрах должна зависеть от зума. Призумился - на экран входит меньше (в километрах), но всегда загружено всё (да хоть даже с учётом числа тайлов за границей экрана). То есть как вариант - задавать расстояние в тайлах (буквально - размер экрана, не обязательно текущий). В таком виде через полигон как сейчас (обойдя трассу с двух сторон) сделано быть не может. |
|
|
> Если так сильно надо скачать "змею", можно сделать это и вручную, двигая карту мышью. Ну сами понимаете, это гораздо дольше. Или мы в мелком масштабе просто потыкаем точки, или в крупном будем крутить карту со скоростью передвижения автомобиля (я занимался этим, ой как неудобно и долго!..). > Будут тайлы, которые попадают более чем в один прямоугольник. А значит сложность алгоритма увеличится почти квадратично. Не согласен. У программы имеется "список" имеющихся тайлов в кеше, и при скачке тайлов выделенной полигональной области (при снятой галке "заменять старые файлы") программа без проблем проверяет их наличие и быстро пропускает те, которые уже есть. Так пусть во время скачки нашего нового типа выделения программа ведёт ещё один список тайлов, которые скачаны во время _данной_ загрузки, и проверяет их наличие вдобавок и по этому второму списку. Время, затрачиваемое на проверку наличия тайлов, увеличится максимум в 2 раза, что совсем не значительно на фоне того, как быстро проверяется сейчас при скачке полигональной области. Я понял, в чём может быть сложность у этого типа выделения. Сложность не в выборе, какие тайлы скачивать, а в "вырисовке" такой области на карте во время выделения, то бишь в определении точек получаемого полигона. Но и тут, думаю, всё решаемо. У соединяемых прямоугольников, для каждой из пары сторон (одна сторона одного прямоугольника и та же сторона второго, вторая сторона одного пр-ка и та же сторона второго) пусть определяются точки пересечения (у внутреннего угла стороны будут пересекаться, а у внешнего - точка пересечения будет находиться на продолжении сторон). Думаю, для определения точек пересечения отрезков формула существует. Таким образом точками, по которым строится выделение, будут эти получившиеся точки пересечения. |
|
|
> Если представить себе ситуацию, что трасса грузится, чтобы по ней проехать с навигатором и сасом, то очевидно ширина захвата в (кило)метрах должна зависеть от зума. Вот! Это и есть главное отличие новой фичи! Смысл не в том, чтобы нарисовать полигон вокруг трассы, а потом скачать, т.к. на больших зумах скачивать придётся очень много ненужных тайлов. Юзер должен нарисовать путь и указать, сколько тайлов надо скачать с каждой стороны (фактически, свой размер экрана, с запасом). Так что задача не сводится к "процедуре получения полигона по пути и указанному расстоянию". Ну или надо такой полигон формировать для каждого зума отдельно. |
|
|
Примерный алгоритм получения точек такого полигона. Простой пример из трёх точек: Нажал первую точку, программа просто её отобразила. Нажал вторую, получили вектор, вычисляются точки первого прямоугольника: - от первой точки вправо относительно вектора на половину ширины (точка A), - от первой точки влево относительно вектора на половину ширины (точка B), - от второй точки влево относительно вектора на половину ширины (точка C), - от второй точки вправо относительно вектора на половину ширины (точка D). Строится прямоугольник ABCD. Нажал третью точку, вычисляются точки второго прямоугольника, аналогично предыдущему, только фигурируют вторая и третья нажатые точки. Вычисляются точки пересечения сторон первого и второго прямоугольника (как было описано в предыдущем моём посте). Точки C и D заменяются на них, а "заканчивается" второй прямоугольник точками E и F, полученными при его вычислении. Строится полигон ABCEFD. |
|
|
А чего делать, если путь заворачивается в кольцо? Это уже будет не полигон как бы, внутренняя дырка мешает. |
|
|
Для программы это всё равно будет полигон, ведь присутствуют начальная, промежуточные и конечная точки. Т.е. пользователь начинает, продолжает и заканчивает выделять. |
|
|
Подумалось тут: если угол, образованный двумя отрезками, очень острый, то точка пересечения продолжений сторон вычисленного прямоугольника на внешнем углу будет стремиться к бесконечности, поэтому на внешнем углу лучше не вычислять точку пересечения, а просто задействовать точки самих вычисленных прямоугольников. А точкой на внутреннем углу, как и говорилось выше, пусть будет точка пересечения сторон прямоугольников. |
|
|
Можно создавать по пути не полигон, а итератор тайлов, то есть объект с методом function Next(out ATile: TPoint): boolean; В любом случае дата озвучена. Если никто не напишет свой алгоритм на делфи, она может только переноситься на более позднее время. |
|
|
Эх, как не хватает этого инструмента выделения... Столько дорог надо скачать... |
|
|
а кто-нибудь из программистов сможет подглядеть на гис-лабе, как они делают границы регионов именно такого типа. т.е. они "двоят" границу на +20- км. Кажется они это делают в qGis (исходники доступны). Я нефига не понимаю в программировании, а так бы сам нарыл. |
|
|
в общем сделал функцию преобразования линии в полигон с заданным "радиусом", теперь осталось за малым - добавить в интерфейс программы нужные кнопки. Меняю целевую версию на следущую. |
|
|
Вот спасибо огромное! Жду следующую версию! Надеюсь не только мне эта функция пригодится... |
|
|
Сделано. Добавлен новый тип выделения - линия. |
|
|
rsuan, следующую версию можно не ждать, качайте завтра "ночную" сборку. |
|
|
В ночных сборках то одно, то другое отваливается, увы. Хотелось бы какой-нибудь стабильной версии, без экспериментальных кусков на полпути. Мониторинг изменений в репозитории бы спас положение, но, во-первых, код программы закрытый, а, во-вторых, лично я не знаю, как это делать в меркуриале, TortoiseHg не имеет такой опции (хотя TortoiseSvn имеет). |
|
|
И что ж это в ночных версиях отваливалось в последнее время? Кое что по мелочи бывает, но обычно исправляется на следующий же день. |
|
|
>Мониторинг изменений в репозитории бы спас положение В ночных сборках есть лог коммитов. |
| 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 | => 45xxxx |
| 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 | |
| 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 | |
| 25-06-2011 17:10 | rsuan | Note Edited: 0003046 | |
| 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 | |
| 27-06-2011 22:59 | rsuan | Note Edited: 0003062 | |
| 27-06-2011 23:39 | rsuan | Note Edited: 0003062 | |
| 28-06-2011 02:57 | rsuan | Note Edited: 0003062 | |
| 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 | |
| 28-06-2011 13:20 | rsuan | Note Edited: 0003068 | |
| 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 | |
| 28-06-2011 15:36 | rsuan | Note Edited: 0003076 | |
| 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 | 45xxxx => 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 |
| 08-08-2025 13:24 | zed | Category | Хотелка => Хотелка / Feature request |