Передача данных точечным объектам2

Question

Тема конечно избитая, но есть ряд интересных моментов. Описываю: Есть набор определенных полигональных объектов (один шейп файл), в атрибутах которого есть поле с кодом, условно определяющее пространственное расположение полигона на карте. И есть точечный шейп файл, загруженный по географическим координатам с кодом, где якобы должен находиться (то есть код полигона). Задача - проверить реальное место положения точек и посчитать статистику "попаданий" точек именно в те полигоны, где они и должны быть. С одной стороны всё просто, функция Spatial join. И работа с запросами в таблице. НО! задача усложнилась, для статистики мне нужно ввести поправку точности GPS. Пусть будет 30 метров. И посчитать "попадания" точек в полигон с таким же кодом в радиусе 30 м. Я думал, что в функции SJ в графе радиус задается радиус поиска, но как-то это не так работает, так и не могу разобраться. Для примера ввел радиус 1000 км и количество попаданий стало 0! Подскажите пожалуйста что мне с этой задачей делать!

Answer 1

Надеюсь я понятно описал проблему? Еще есть вопрос, кто-нибудь разбирался зачем в spatial join радиус и что он делает? В хелпе как-то не понятно написано

Answer 2

Дык, всеж написано. Search Radius = "The distance over which the analysis is performed. A distance of 0 (default) means that only features that physically touch are matched. A distance of -1 means that the analysis will search as far as it needs to find a match. It is only valid to use -1 as a distance for joins that use a nearest join option". Словом, это для ограничения выриантов выбора. Если радиус поставить, не для каждого элемента отыщется сосед.

В вашем случае непонятно, как быть вообще, что вы собственно хотите. Если вам нужен код полигона, в который попадает точка, то SR нужно оставить 0, чтобы получить одно значение.

Если вы хотите понять, какие еще соседние полигоны находятся от точки на расстоянии, тогда да, надо искать радиусом. Но сочетаний может быть много, и не факт, что SJ сработает как надо. Обычно он выдает 1-1 - каждому объекту один ближайший (+дистанцию до него), остальное неоднозначное дело. Поставьте 1-M, может, сработает, как вы хотите, хотя не уверен.

Может быть, если не получается, то проще нарисовать буфер вокруг каждой точки размером с точность GPS, пересечь с полигонами и проанализировать возможные сочетания, в т.ч. и по площади пересечения - это покажет вероятность попадания намного лучше, чем простое линейное отстояние. Если задача в этом.
    

Answer 3

Задача в другом, Пример: я отправляю вас по определенному адресу (номер дома например), даю gps. Ваша задача прийти в этот дом и снять координаты. Далее по этим координатам я определяю в том ли доме вы находились. Если вы "наврали" и не дошли до этого дома, я вас наказываю. Вы сопротивляетесь и говорите что gps не точно определила координаты. В таком случае я должен проверить есть ли в радиусе, допустим 50м, тот дом в который вы должны прийти. Если есть, то погрешность допустимая и скорее всего вы действительно в этом доме были, если нет, то вы там действительно небыли. Вот такая вот задача. Правда я лесом занимаюсь, пришлось выдумывать про адреса Точки в любом случае находятся внутри полигонов, только не всегда внутри тех, в которых должны быть

Answer 4

Еще желательно бы узнать расстояние от данной точки до ближайшей границы полигона в котором она должна находиться, но это я думаю уже проще

Answer 5

задача примерно понятна, но уже нужно и поточнее формулировать, так что дома не подойдут. Я представляю точность GPS, и у вас получается, что дело выглядит так:
1. ваша точка попадает в лесной контур. а) в тот - работа окончена б) не в тот - идем далее;
2. Проверяем, есть ли "тот" контур на заданном расстоянии;
3. Итп. итд.

В такой вашей процедурной формулировке придется сочинять отдельный скрипт. Однако я вам предложил другую постановку, СРАЗУ найти ВСЕ контура в радиусе 50 метров. Это возможно операциями buffer и intersect, БЕЗ применения Spatial Join - а чего вы собственно на нем зациклились? Анализ соседства в ГИС может проходить десятками способов. Таким образом для каждой точки вы получаете список контуров в окрестности 50 метров. После этого вы сами по таблице отбираете точки, где условие попадания никак не выполняется. Это уже несложный SQL-запрос с группировкой (размер окрестности можно, кстати, варировать параметром, если у вас есть данные по точности на момент съемки координат).

Если вы будете настаивать на получении расстояния от точки до полигона, то, наверное, придется до конца добивать вариант Spatial Join 1-Many. Еще экономный вариант - сразу соединить точку с требуемым полигоном по коду, а не по положению. Далее для всех пар полигон-точка рассчитать кратчайшие расстояния, но понадобится уточнить суть объекта "полигон" - насколько он простирается.

Да и еще надо знать, у вас задача одноразовая или на каждый день, ну и какие исходные данные... А то может проще на VB пересочинить ;)

Answer 6

Спасибо за расширенный ответ. В принципе подойдет buffer и intersect. Единственная проблема в том, что задача действительно практически на каждый день. На SJ зациклился потому, что это проще и быстрее, в конечном итоге всегда хочется сделать работу нажатием одной кнопки. Если формулировать точнее, то задача выглядит так: Ребята в лесу закладывают сеть пробных площадей. Их основная задача по бумажной карте прийти в определенный лесной участок, заложить пробную площадь, снять её координату. Моя задача проверить действительно ли они заложили пробу в нужном участке с учетом точности gps, если ошиблись, то на какое расстояние. По сути SJ c sql запросом позволяет определить в тот ли полигон они попали, это плюс. А вот поправку на точность gps видимо придется делать отдельно буфером с запросами, это минус (просто я думал что радиус в SJ как раз является радиусом поиска, хотя не понятно что он ищет). Расстояние до нужного полигона тоже придется делать отдельно. Сочинять скрипт нет смысла, так как задача хоть и не одноразовая, но сезонная (точки получаем раз в год). Вот такие дела, но все равно спасибо! Я хоть определился что можно сделать

Answer 7

Все-таки сделал SJ, действительно достаточно было указать 1- Many, и создать запрос на выборку тех точек, у которых совпадают атрибуты с полигонами. Теперь буду с расстояниями думать. Еще раз спасибо! Тема закрыта.

Answer 8

Да, SJ наиболее мощный инструмент. Но в нем не все сочетания (точки-точки, точки-линии, точки-полигоны и т.п) не для всех операций адекватно работают. Раз уж у вас получилось, расскажите, действительно ли в итоговой таблице расстояния от точек до ближайшей границы соседних полигонов (нескольких).

До полигона, в который попадает данная точка, по описанию должно быть расстояние 0 - что не всегда удобно.

Вот здесь есть как запускать SJ командной строкой, но судя по тому, что вы поставили двоечку в названии темы, вы это обсуждение видели ;)
    
    

Answer 9

В итоговой таблице вообще почему-то нет расстояний. Может нужно в базу геоданных все сначала перевести. По логике если точка попала в нужный выдел, расстояние и будет равно 0. Хотя я думаю можно посчитать расстояние просто до ближайшей границы полигона, если их в линии перевести. Да, кстати, появляется поле Join Count в котором странные цифры (0; 1; и 2). Так и не понимаю что они означают.

Answer 10

Странно, расстояния должны быть.
насчет нулей - да, именно линиями. Бывает, и на точки приходится полигоны разваливать для получения адекватной информации... Странные цифры - а это не может быть количество найденных полигонов для каждой точки???