Полигоны в линии в рамках GDB

Question

Подскажите братцы... Дожил до седых волос, не могу найти казалось бы простую функцию. В полигоны пожалуйста (ArcMap 8.3), а как же обратно? Неужели только через coverage???

Answer 1

а в полигоны как в 8.3?

Answer 2

Сам не пробовал, но название вдохновляет

http://arcscripts.esri.com/details.asp?dbid=12942

Answer 3

Сам пробовал =)

http://arcscripts.esri.com/details.asp?dbid=13443

 

Answer 4

2Jazz: ArcCatalog/New/Polygon Class from lines... Разумеется, чистка топологии на совести утопающего :)

2All: За скрипты братцы спасибо... щас покачаю/попробую. Но я-то думал, я один такой бестолковый - оказывается, в ЕSRI тоже их полно

Answer 5

В благодарность докладаю результаты - последний скрипт работает хорошо. По дороге выяснилось, что линии можно делать и проще - достаточно "переклеить" их из полигонального Feature Сlass. Однако эти линии совершенно нетопологичны, набор колец, как оно и ожидалось после ArcView, наложенных на границах полигонов. Правило Must not Intersect (Overlay) находит кучу ошибок. Исправить их средствами GeoDatabase вряд ли эффективно - собственно пересечения GDB может чистить пачкой, применяя Split, а вот наложения, естественно, отказывается (только вручную, предлагает каждый раз выбирать одну из линий). О так от.

Шейп, прокаченный через coverage в GDB, таких недостатков не имеет - линии уже разбиты на стыках и все дубликаты вычищены, известны полигоны - прародители (LefftPoly, RightPoly). Так что не спешите выбрасывать старый добрый ArcINFO. К чести GDB можно сказать, что и одни, и другие линии преобразуются в полигоны одинаково успешно, и топологических ошибок по дороге не возникает.

Answer 6

2geologic - не сбросишь, что бы ты хотел и что получил (фрагментик, либо любую графику) на xbb@mi-perm.ru по моему без примера только по тексту трудно разобраться. Есть идеи улучшить TypeConvert, проблема меня заинтересовала, может не сразу, а постепенно постараюсь ее решить.

Answer 7

Да не стоит голову забивать, программа хорошая. Просто изучаю GDB как новый формат данных, и по дороге выяснилось, что ближе он к шейпам, чем к покрытиям. Вряд ли стоит заниматься топологией слегка, там ведь нужен боле-мене полноценнный инструментарий. Кстати, для шейпов он уже есть - EditTools. Удаление двойных линий там как элемент предварительного редактирования присутствует. Осталось дождаться его версии для GDB...

[Обидно, конечно, что никакие элементы топологии не заложены в самом понятии GDB. Впрочем, возможно, это было обусловлено задачами хранения гео-объектов в базе данных. Каждая строка - следовательно и объект - по требованиям БД должны быть автономны.]

Фу, елки-палки, перечитал и устыдился - ведь может показаться, что я что-то в этом понимаю. В общем, если надо, пиши(те), постараюсь еще как-то помочь. А пример... Обычная ГИС-топология - линейная или полигональная - и была перед глазами как задача. Но если надо частный момент решить, могу напрячься и сформулировать, конечно. Может оказаться интересным для отдельных задач.

Answer 8

Поздняк, уже сделано =) По поводу понимания - кому то и горшки обжигать надо, не всем же миры творить (ну разве что виртуальные).  А как разработчик с 20 летним стажем точно знаю, что мнение юзера это и начальная, и конечная инстанция.

Добавили команду remove duplicates, сейчас доку подправим, к вечеру выложим. Мне самому это больше нужно, чтобы точки при построении изолиний не двоились, а то при разных значениях в углах полигонов такая бяка вылезает.

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

Answer 9

[Обидно, конечно, что никакие элементы топологии не заложены в самом понятии GDB. Впрочем, возможно, это было обусловлено задачами хранения гео-объектов в базе данных. Каждая строка - следовательно и объект - по требованиям БД должны быть автономны.]

Не совсем так - реляционная база данных - это как раз взаимодействие между таблицами. И как частный случай - между записями внутри таблицы. Пример - реализация дерева на основе таблицы, когда одни записи в одной и той же таблице ссылаются на другие.

GDB как раз просто не реализует всей этой кухни в полной мере.

Причины, похоже, есть, правда о них можно только догадываться.

Answer 10

[

Я GDB-то и ругаю. Хотя за скорость работы наоборот, надо хвалить...:)

Возможности субд по поддержанию целостности трудно оспорить... С этим вроде нынче все разумно даже в аксессе. Но реальную пользу эти усилия приносят, когда используется встроенный механизм ограничений (constraints). Объявил правило - а дальше хоть трава не расти, СУБД "сама" следит за выполнением при любом варианте доступа. В части топологии использование такого подхода в GDB не предусмотрено...  Геометрия проверяется де-факто. Где-то ESRI даже излагались  аргументы в пользу этого... И вполне разумные, но...

Интересно узнать, а возможности других РСУБД используются аналогично? Т.е. любая скотина (с паролем :) может нагрянуть в базу SDE на Oracle, например, порушить там геометрическую целостность и обнаружится это только после плановой проверки? :) Или есть возможность запретить отдельные нетопологичные операции? Делать двойные (наложенные) линии, например? В принципе, механизм триггеров должен это позволять, готова ли ГИС-часть ими эффективно пользоваться?

Это так, мысли вслух.