|
Notes |
|
|
|
|
Жду когда кто-нибудь реализует такой алгоритм. Как только кто-то предложит готовую процедуру получения полигона по пути и указанному расстоянию эта хотелка будет реализована. |
|
|
|
|
В каком виде задается путь?
В каком виде задается полигон?
В каком виде нужна процедура? |
|
|
|
|
Путь задается в виде массива LonLat точек.
Полигон - такой же массив как и путь, только первая и последняя точки равны.
Процедура желательно на Delphi. Получает массив и расстояние возвращает массив. |
|
|
|
(0003046)
|
|
rsuan
|
25-06-2011 17:00
(edited on: 25-06-2011 17:10) |
|
Причина: Выделять полигонально такой путь неудобно: путь может быть извилистым, и придётся проходить его точками два раза: сначала с одной стороны дороги "туда", потом с другой стороны дороги "обратно".
Расположение функции: Операции с выделенной областью - "Вытянутая область" (или что-то подобное)
Как бы это работало: Выбираешь функцию "Вытянутая область"; запрашивается ширина полосы, которую можно задать количеством тайлов какого-то масштаба; и начинаешь вытягивать полосу по пути следования, от начального пункта до конечного.
|
|
|
|
|
rsuan, тут беда вот в чём.
vdemidov предыдущим сообщением недвусмысленно даёт понять, что хочет свести обход тайлов в полосе к обходу тайлов в произвольной области. Ну то есть не совсем к произвольной, а к области такого вида, которую сейчас программа может обработать.
Формально это возможно, так как построение такой области равносильно объединению единичных областей (прямоугольников), полученных при "расширении" каждого отрезка пути во все стороны на некую величину.
Однако программа пока что не умеет выполнять объединение областей. При объединении прямоугольников может получиться дырка в области выделения (например, трек идёт вдоль берега озера). Либо её надо уметь корректно облабатывать при операциях с выделенной областью (что по сути равносильно возможности выделения и скачки по kml с произвольным количеством несвязных областей и дырок в них), либо уметь соединять дырку и наружную область так, чтобы дырки формально не было (аналог - разрезание кольца, итеративно выполняется для всех дырок в полигоне).
Поэтому пока что реализация через превращение такой полосы в полигон невозможна.
Впрочем, интуитивно представляется, что это и не надо. Дело в том, что при операциях с выделенной областью программа тем или иным спобосом должна определить, входит или нет тот или иной тайл в область, надо ли его скачивать. Наверняка проверка для произвольного пути и расстояния не будет сильно сложнее проверки для произвольного полигона. То есть, возможно и не потребуется вообще создание полигона, равномощного пути+расстоянию. |
|
|
|
(0003055)
|
|
rsuan
|
|
27-06-2011 13:48
|
|
Прочитал, но так и не увидел никакой проблемы. Программа умеет по полигональному выделению вычислять, какие тайлы нужно скачать? Умеет. Ну а в нашем случае выделение будет представлять собой просто сумму таких полигональных областей, которые являются разнонаправленными прямоугольниками разной длины и одной ширины. Программе просто остаётся скачать тайлы для каждого из них, и всё будет перекрываться, не будет никаких дырок и пропусков.
И довод того, что нам не нужен такой тип выделения - не распонял. Да и не хочу этого понимать, для автомобилиста такой тип выделения нужен, и сложность его программной реализации не выглядит убедительной. |
|
|
|
|
|
Если так сильно надо скачать "змею", можно сделать это и вручную, двигая карту мышью. Только вот опыт показывает, что зачастую как раз и не хватает пары-тройки тайлов в сторону от скачаной "змеи", а ничего уже не сделаешь, если ты в дороге. Это к вопросу о ширине захвата. С другой стороны, на мелком масштабе можно построить полигон, захватывающий нужную область, не ставя особо много точек, то есть не огибая каждый самый мелкий поворот дороги. Ну и что, если в каком-то месте будет более широкий захват, а в каком-то - поуже? В конце концов идеал - это когда есть полное покрытие местности. |
|
|
|
|
>Ну а в нашем случае выделение будет представлять собой просто сумму таких полигональных областей, которые являются разнонаправленными прямоугольниками разной длины и одной ширины. Программе просто остаётся скачать тайлы для каждого из них, и всё будет перекрываться, не будет никаких дырок и пропусков
Будут тайлы, которые попадают более чем в один прямоугольник. А значит сложность алгоритма увеличится почти квадратично (так как придётся формально проверять, что тайл уже есть в списке), причём не один раз при построении области, а КАЖДЫЙ РАЗ при скачке хотя бы одного тайла по такому выделению. Очевидно, такой костыль не настолько необходим, чтобы его привносить в программу. Корректная реализация через полигоны без нормальной реализации объединения областей (выполняемого один раз ДО скачки) невозможна.
>И довод того, что нам не нужен такой тип выделения - не распонял
Да нужен он, нужен, не надо нервничать. Просто пока некому его сделать. Если есть workaround и проблема не критичная - она тут может жить годами. |
|
|
|
|
>Это к вопросу о ширине захвата
Если представить себе ситуацию, что трасса грузится, чтобы по ней проехать с навигатором и сасом, то очевидно ширина захвата в (кило)метрах должна зависеть от зума. Призумился - на экран входит меньше (в километрах), но всегда загружено всё (да хоть даже с учётом числа тайлов за границей экрана). То есть как вариант - задавать расстояние в тайлах (буквально - размер экрана, не обязательно текущий). В таком виде через полигон как сейчас (обойдя трассу с двух сторон) сделано быть не может. |
|
|
|
(0003062)
|
|
rsuan
|
27-06-2011 22:44
(edited on: 28-06-2011 02:57) |
|
> Если так сильно надо скачать "змею", можно сделать это и вручную, двигая карту мышью.
Ну сами понимаете, это гораздо дольше. Или мы в мелком масштабе просто потыкаем точки, или в крупном будем крутить карту со скоростью передвижения автомобиля (я занимался этим, ой как неудобно и долго!..).
> Будут тайлы, которые попадают более чем в один прямоугольник. А значит сложность алгоритма увеличится почти квадратично.
Не согласен. У программы имеется "список" имеющихся тайлов в кеше, и при скачке тайлов выделенной полигональной области (при снятой галке "заменять старые файлы") программа без проблем проверяет их наличие и быстро пропускает те, которые уже есть. Так пусть во время скачки нашего нового типа выделения программа ведёт ещё один список тайлов, которые скачаны во время _данной_ загрузки, и проверяет их наличие вдобавок и по этому второму списку. Время, затрачиваемое на проверку наличия тайлов, увеличится максимум в 2 раза, что совсем не значительно на фоне того, как быстро проверяется сейчас при скачке полигональной области.
Я понял, в чём может быть сложность у этого типа выделения. Сложность не в выборе, какие тайлы скачивать, а в "вырисовке" такой области на карте во время выделения, то бишь в определении точек получаемого полигона. Но и тут, думаю, всё решаемо. У соединяемых прямоугольников, для каждой из пары сторон (одна сторона одного прямоугольника и та же сторона второго, вторая сторона одного пр-ка и та же сторона второго) пусть определяются точки пересечения (у внутреннего угла стороны будут пересекаться, а у внешнего - точка пересечения будет находиться на продолжении сторон). Думаю, для определения точек пересечения отрезков формула существует. Таким образом точками, по которым строится выделение, будут эти получившиеся точки пересечения.
|
|
|
|
(0003064)
|
|
Tolik
|
|
28-06-2011 09:38
|
|
> Если представить себе ситуацию, что трасса грузится, чтобы по ней проехать с навигатором и сасом, то очевидно ширина захвата в (кило)метрах должна зависеть от зума.
Вот! Это и есть главное отличие новой фичи! Смысл не в том, чтобы нарисовать полигон вокруг трассы, а потом скачать, т.к. на больших зумах скачивать придётся очень много ненужных тайлов.
Юзер должен нарисовать путь и указать, сколько тайлов надо скачать с каждой стороны (фактически, свой размер экрана, с запасом).
Так что задача не сводится к "процедуре получения полигона по пути и указанному расстоянию". Ну или надо такой полигон формировать для каждого зума отдельно. |
|
|
|
(0003068)
|
|
rsuan
|
28-06-2011 13:14
(edited on: 28-06-2011 13:20) |
|
Примерный алгоритм получения точек такого полигона. Простой пример из трёх точек:
Нажал первую точку, программа просто её отобразила.
Нажал вторую, получили вектор, вычисляются точки первого прямоугольника:
- от первой точки вправо относительно вектора на половину ширины (точка A),
- от первой точки влево относительно вектора на половину ширины (точка B),
- от второй точки влево относительно вектора на половину ширины (точка C),
- от второй точки вправо относительно вектора на половину ширины (точка D).
Строится прямоугольник ABCD.
Нажал третью точку, вычисляются точки второго прямоугольника, аналогично предыдущему, только фигурируют вторая и третья нажатые точки. Вычисляются точки пересечения сторон первого и второго прямоугольника (как было описано в предыдущем моём посте). Точки C и D заменяются на них, а "заканчивается" второй прямоугольник точками E и F, полученными при его вычислении.
Строится полигон ABCEFD.
|
|
|
|
(0003075)
|
|
gpsMax
|
|
28-06-2011 14:52
|
|
|
А чего делать, если путь заворачивается в кольцо? Это уже будет не полигон как бы, внутренняя дырка мешает. |
|
|
|
(0003076)
|
|
rsuan
|
28-06-2011 14:59
(edited on: 28-06-2011 15:36) |
|
Для программы это всё равно будет полигон, ведь присутствуют начальная, промежуточные и конечная точки. Т.е. пользователь начинает, продолжает и заканчивает выделять.
|
|
|
|
(0003083)
|
|
rsuan
|
|
28-06-2011 22:12
|
|
|
Подумалось тут: если угол, образованный двумя отрезками, очень острый, то точка пересечения продолжений сторон вычисленного прямоугольника на внешнем углу будет стремиться к бесконечности, поэтому на внешнем углу лучше не вычислять точку пересечения, а просто задействовать точки самих вычисленных прямоугольников. А точкой на внутреннем углу, как и говорилось выше, пусть будет точка пересечения сторон прямоугольников. |
|
|
|
|
Можно создавать по пути не полигон, а итератор тайлов, то есть объект с методом
function Next(out ATile: TPoint): boolean;
В любом случае дата озвучена. Если никто не напишет свой алгоритм на делфи, она может только переноситься на более позднее время. |
|
|
|
(0003663)
|
|
rsuan
|
|
02-09-2011 17:11
|
|
|
Эх, как не хватает этого инструмента выделения... Столько дорог надо скачать... |
|
|
|
(0003665)
|
|
zOn
|
|
03-09-2011 09:15
|
|
а кто-нибудь из программистов сможет подглядеть на гис-лабе, как они делают границы регионов именно такого типа.
т.е. они "двоят" границу на +20- км. Кажется они это делают в qGis (исходники доступны). Я нефига не понимаю в программировании, а так бы сам нарыл. |
|
|
|
(0003699)
|
|
feya
|
|
05-09-2011 15:25
|
|
|
в общем сделал функцию преобразования линии в полигон с заданным "радиусом", теперь осталось за малым - добавить в интерфейс программы нужные кнопки. Меняю целевую версию на следущую. |
|
|
|
(0003730)
|
|
rsuan
|
|
06-09-2011 11:00
|
|
|
Вот спасибо огромное! Жду следующую версию! Надеюсь не только мне эта функция пригодится... |
|
|
|
(0003737)
|
|
feya
|
|
06-09-2011 11:49
|
|
|
Сделано. Добавлен новый тип выделения - линия. |
|
|
|
(0003738)
|
|
feya
|
|
06-09-2011 11:50
|
|
|
rsuan, следующую версию можно не ждать, качайте завтра "ночную" сборку. |
|
|
|
(0003756)
|
|
gpsMax
|
|
06-09-2011 20:06
|
|
В ночных сборках то одно, то другое отваливается, увы. Хотелось бы какой-нибудь стабильной версии, без экспериментальных кусков на полпути.
Мониторинг изменений в репозитории бы спас положение, но, во-первых, код программы закрытый, а, во-вторых, лично я не знаю, как это делать в меркуриале, TortoiseHg не имеет такой опции (хотя TortoiseSvn имеет). |
|
|
|
|
|
И что ж это в ночных версиях отваливалось в последнее время? Кое что по мелочи бывает, но обычно исправляется на следующий же день. |
|
|
|
(0003778)
|
|
zed
|
|
07-09-2011 16:47
|
|
>Мониторинг изменений в репозитории бы спас положение
В ночных сборках есть лог коммитов. |
|