Лінії до полігонів

11

Мені не вдалося знайти "ім'я" алгоритму, який дозволив би перетворити рядки на багатокутники. Оскільки це питання перетинає ГІС та сфери обчислювальної геометрії та інформатики. Я не впевнений, що ще додати до суміші. Я неохоче надаю перелік того, що я шукав, оскільки я також хотів би знати, які інші люди вважають за свій перший вибір критеріїв пошуку.

Сценарій ... У мене є рядки (два пункти, необхідні для побудови лінії) ... кожен рядок з'єднаний принаймні з одним іншим рядком. Проміжний простір між з'єднаними лініями утворював би багатокутник. Найпростішим сценарієм був би трикутник ... прямокутник ... і можна було вийти за межі багатосегментних функцій.

Вибачте за будь-які неясні описи, але, як я вже сказав, я не хочу направляти можливі рішення вниз по шляху, який я вже відвідав, оскільки мене "перша думка" зацікавила як кінцеве рішення.

polygon algorithm geometry-conversion

— Герман Каррільо
джерело

Чи можуть збігатися лінії? Чи можуть перетинатися лінії? (тобто чи це чисто?) Якщо так, я сподіваюся, що виклик цього процесу Build не буде занадто конкретним додатком.

— Кірк Куйкендалл

Лінії зіткнення Кірка та інші "дефекти" були б видалені перед побудовою полігонів ... Я намагаюся знайти "ім'я алгоритму", яке, я впевнений, було реалізовано в різних ГІС-пакетах (наприклад, arcgis). Отже, коротко, врахуйте, що всі вироджені умови були вирішені, і вам залишаються чисті лінії (2-х точкові лінії), які збігаються у вузлах, з яких ви повинні мати можливість побудувати багатокутники. Ключовим є те, що лінії існують, немає вироджених умов і проміжний простір потрібно перетворити на багатокутники. Дякую

Чи є точки на площині чи на кулі?

— Кірк Куйкендалл

Кірк ... На площині метрика x, y координати, а не сферичні координати. Наприклад, скажімо, у вас є лінійні сегменти, які формували б діаграму voronoi, але все, що у вас є, - це сегменти, які формують її, але не фактична структура даних, що вела до неї. Коротше кажучи, кожен сегмент пов'язаний, і кожен сегмент унікальний.

4

Можливо, "заповнення площі"? Дивіться тут і тут .

Редагувати

Інша можливість - це обмежена триангуляція . (Посилання - на аплет Java, який дозволяє намалювати графік за допомогою миші, а потім ілюструє алгоритм розгортання площини для тріангуляції.) Результат будь-якої такої тріангуляції, незалежно від того, як вона проводиться, може бути легко оброблена в створіть бажані багатокутники: просто з’єднайте всі сусідні трикутники, які розділяють новостворений край.

Приклад

Оригінальний графік:

Оригінальний графік

Трикутний графік:

введіть тут опис зображення

— дзижчати
джерело

Білл Підбирається на голосування, оскільки я не стикався з цим ... не бажаючи обмежувати інші коментарі людей у різних дисциплінах.

Хоча багато в чому стосується растрових заливок, це найближча відповідь. У мене досі немає назви алгоритму, якщо він не прикріплений ні до растрових, ні до векторних, але алгоритму "розгортки" може бути достатньо, але я не можу на все життя зрозуміти, чому координати будуть відсортовані Y, а не X ( що легко реалізувати на більшості мов).

@Dan Сортування за y або x не має значення, як ви пропонуєте. Ви також впевнені, що алгоритми розгортки площин або розгортки ліній задіяні, але, на жаль, це загальна методика, яка охоплює майже всі процедури обчислювальної геометрії, тому це не підходящий термін для пошуку конкретно для вашого алгоритму. Зауважте, що ця конкретна проблема не є суто теоретично графічною, оскільки вона включає вбудовування полілінійного комплексу в площину (або сферу), і тому хороший алгоритм повинен підтримувати інформацію про вбудовування: саме тому це справді проблема заповнення області. на серці.

— whuber

5

У теорії графів ця операція називається обчисленням обличчя . Він пов'язаний з обчисленням дуалу даного графа.

Наприклад, у бібліотеці Java GeOxygène графік (званий CarteTopo ) має метод getFaces для отримання обличчя .

Це називається полігонізацією в СТС

— жульєн
джерело

Хороші посилання. Однак усі вони припускають, що проблема @ Дана вже вирішена: мати можливість назвати графік "планарним" означає, що ви вже визначили полігональні грані. Він хоче знати, як можна перетворити довільну колекцію дуг (у площині) в площинний графік чесного доброго. Це вимагає побудови репрезентації його "топології", такої як DCEL.

— whuber

Велике спасибі, ви є основою знань! Цікаво, як хтось може бути таким яскравим.

— липень

4

Хост-програмне забезпечення RepRap перетворює список сегментів рядків (у якомусь невідомому випадковому порядку) у список багатокутників, що звучить аналогічно тому, що ви намагаєтесь зробити.

Зокрема, алгоритм RepRap "кінцева відповідність" обробляє купу патологічних випадків.

На жаль, програмне забезпечення RepRap передбачає, що кожен кут має рівну кількість країв, що йдуть до нього - 2 рядки, що йдуть до кута на звичайному об’єкті; 4 рядки, що збираються разом, коли кут одного об'єкта торкається кута іншого об'єкта, і т. Д. Я не знаю, як важко було б адаптувати цей алгоритм для обробки діаграм вороного, який зазвичай має 3 ребра, що йдуть до кожного кута.

— Девід Кері
джерело

+1 Цікава знахідка! Однак слідкуйте за тим, що, хоча це програмне забезпечення виглядає здатним вирішити багато проблем, пов’язаних із з'єднанням ліній в багатокутники, це може зробити занадто багато : схоже, воно також намагається спростити функції, що може бути небажаним побічним ефектом. (Напр., Це може зруйнувати топологічну цілісність.)

— блукання

3

Ви вивчали кодову базу GRASS для вирішення своєї проблеми? -> http://old.nabble.com/Polyline-to-Polygon-operation-td20257839.html

— оеон
джерело

1

Дякую ... але я не шукаю конкретного "упакованого" рішення, а основного алгоритму та / або його назви, який би прийшов у різні області ГІС, Comp Geom та / або Comp Sci ... тримати ідеї, що надходять

Я думав спеціально розглянути вихідний код за двома згаданими процесами в моєму посиланні, можливо, вам допоможе.

— oeon

Я думаю, мені доведеться встановити програмне забезпечення, щоб побачити код, оскільки я не бачу жодного списку на цих сторінках, якщо я щось не пропускаю.

1

Ви можете переглядати джерело GRASS в Інтернеті: trac.osgeo.org/grass/browser

— underdark

@underdark Дякую за вказівник. Наскільки я можу судити з main.cв v.typeджерелі, все , що відбувається в тому , що функції повторно позначені як кордони: ніякої фактичної обробки не відбувається. З ретроспективою це не надто дивно: якщо (я точно не знаю) функції підтримуються з повною 2D топологічною інформацією, то всі обчислення для ідентифікації полігональних областей автоматично відбуваються під час створення функції або імпорту та зберігаються протягом усього часу всі геопроцесорні операції.

— whuber

3

Привіт

Я не думаю, що ви шукаєте конкретний алгоритм. Завдання може бути досить складним або дуже простим, залежно від вашого набору даних.

Ви повинні розділити проблему щонайменше на 2 частини. 1) - це більше проблема мережі, як знайти закриті кільця рядків. 2) виразити замкнуту лінію рядка як багатокутник

Друга частина, яка є "перетворенням ліній у багатокутники", залежить більше від формату, ніж представлення полігона / рядків. Я маю на увазі перехід від:

ЛІНІСТРІНГ (1 1, 2 2)
ЛІНЕСТРІНГ (2 2, 2 1)
ЛІНЕСТРІНГ (2 1, 1 1)

до:
ПОЛІГОН ((1 1,2 2,2 1,1 1))

- це перетворення рядка на багатокутник, але це не те, про що ви говорите. Складніша частина - перша. Якщо у вас є спагеті з ліній, як їх замовити у вигляді закритих рядків.

Я думаю, що відповідь на це питання багато залежить від набору даних. Як запитує Кірк, якщо лінії можуть перетнути проблему, це набагато більше. Якщо ви знаєте, що всі "колекції ліній" є частиною закритого рядка, це стає простіше. Тоді ви можете захопити будь-яку лінію і пройтися по шляху, поки ви знову не повернетеся, а потім перейдіть до другого кроку.

Моя думка, що умова набору даних встановлює всі правила щодо того, як це зробити. Якщо ви хочете знайти всі можливі багатокутники в спагетті рядкових рядків, я припускаю, що для встановлення вершинних точок на всіх перехрестях, пошуку всіх можливих шляхів тощо, потрібно буде багато різних алгоритмів.

У PostGIS функція називається ST_Polygonize. Ця функція створює всі можливі багатокутники з рядків, які ви їй надаєте.

Це виконується GEOS, щоб ви могли знайти алгоритми позаду як в коді GEOS, так і в JTS.

Просто деякі думки

/ Ніклас

— Ніклас Авен
джерело

1

Ви можете спробувати пошукати алгоритм "Вперед зірка". Мені сказали, що це загальний характер, але єдині дискусії про це, які я коли-небудь читав, завжди стосувалися аркгізів. Можливо, погляньте на посилання, цитовані в цих конспектах лекцій для форварда.

— Кірк Куйкендалл
джерело

1

Я прокоментую тут, навіть якщо цей коментар стосується також інших запропонованих рішень: проблема не може бути представлена в мережі (або графіку). Він вимагає інформації про те, як лінії з'єднані в межах двовимірної поверхні . Таким чином, подання вперед / назад зіркою буде мало користі; DCEL або щось подібне потрібно.

— whuber

@whuber - Я припускав, що коментар Дена про те, що всі "дефекти" були видалені, означав, що лінії чисті. Таким чином, слід звести це до проблеми обходу графіків щодо пошуку всіх циклів у графі. Спочатку я думав, що Зірка вперед допоможе в алгоритмах, які обходять графік, беручи різкий правий поворот, можливий на кожному вузлі. Однак, дивлячись трохи більше, схоже, є кращі способи. stackoverflow.com/questions/261573/… Але все ж ця проблема передбачає, що проблема може бути повторно викладена у вигляді графіка.

— Кірк Куйкендалл

1

Знаходження циклів у графіку не те саме, що пошук граней у плоскому графіку. Розглянемо абстрактний графік з вершинами {a, b, c, d} та ребрами {a, b}, {a, c}, {b, c}, {b, d}, {c, d}. Основу для циклів складають a-> b-> d-> c-> a і a-> b-> c-> a. У плоскому вбудовуванні a -> (0,1), b -> (2,2), c -> (2,0), d -> (3,1) (де всі ребра є відрізками ліній), цикл а-> b-> D-> C-> а це НЕ особа, але якщо ми переміщаємо d до (1,1), то це особа. Це показує, чому поняття "обличчя" вимагає вбудовування графіка в площину і чому грані не можуть бути обчислені суто з абстрактної структури графіка.

— whuber