Linee a poligoni

11

Non sono riuscito a trovare il "nome" dell'algoritmo che consentirebbe di convertire le linee in poligoni. Poiché questo problema attraversa il GIS e i campi della geometria computazionale e dell'informatica. Non sono sicuro di cos'altro aggiungere al mix. Sono riluttante a fornire un elenco di ciò che ho cercato poiché vorrei anche sapere quali altre persone considererebbero la loro prima scelta di criteri di ricerca.

Lo scenario ... Ho delle linee (sono necessari due punti per costruire una linea) ... ogni linea è connessa ad almeno un'altra linea. Lo spazio intermedio tra le linee collegate formerebbe un poligono. Lo scenario più semplice sarebbe un triangolo ... un rettangolo ... e si potrebbe passare oltre alle funzionalità multi-segmentate.

Ci scusiamo per le descrizioni vaghe, ma come ho già detto, non voglio guidare le possibili soluzioni lungo un percorso che ho già visitato, dal momento che sono interessato al "primo pensiero" quanto alla soluzione finale.

polygon algorithm geometry-conversion

— Germán Carrillo
fonte

Le linee possono coincidere? Le linee possono attraversare? (cioè è pulito?) In tal caso, spero di chiamare questo processo Build non sarebbe troppo specifico per l'app.

— Kirk Kuykendall il

Le linee di Kirk Coincident e altri "difetti" sarebbero stati rimossi prima della costruzione dei poligoni ... Sto cercando di trovare il "nome dell'algoritmo" che sono sicuro sia stato implementato in vari pacchetti GIS (ad esempio arcgis). Quindi in breve, considera che tutte le condizioni degenerate sono state affrontate e ti rimangono delle linee pulite (linee a 2 punti) che coincidono ai nodi che dovresti essere in grado di costruire poligoni. La chiave è che le linee esistono, non esistono condizioni degenerate e lo spazio intermedio deve essere convertito in poligoni. Grazie

I punti sono su un piano o su una sfera?

— Kirk Kuykendall,

Kirk ... Su un piano, metrica x, coordinate y, non coordinate sferiche. Ad esempio, supponiamo che tu abbia i segmenti di linea che formerebbero un diagramma voronoi, ma tutto ciò che hai sono i segmenti che lo formano, ma non la struttura dei dati effettiva che li ha condotti. In breve, ogni segmento è collegato e ogni segmento è unico.

4

Forse "riempimento area"? Vedi qui e qui .

modificare

Un'altra possibilità è la triangolazione vincolata . (Il collegamento è a un'applet Java che consente di disegnare un grafico con il mouse e quindi illustra un algoritmo di scansione del piano per triangolarlo.) Il risultato di tale triangolazione, indipendentemente da come viene eseguito, può essere prontamente elaborato per creare i poligoni desiderati: unisci semplicemente tutti i triangoli vicini che condividono un bordo appena creato.

Esempio

Grafico originale:

Grafico originale

Grafico triangolato:

inserisci qui la descrizione dell'immagine

— whuber
fonte

Bill Sta per votare perché non mi ero mai imbattuto in questo ... non volendo limitare altri commenti di persone di varie discipline.

Sebbene, in gran parte occupandosi dei riempimenti raster, questa è la risposta più vicina. Non ho ancora un nome di algoritmo a meno che non sia associato a raster o vettoriale, ma potrebbe essere sufficiente un algoritmo di "sweep", ma non riesco a capire per me il motivo per cui le coordinate verrebbero ordinate per Y anziché X ( che è facile da implementare nella maggior parte delle lingue).

@Dan L'ordinamento per y o x è irrilevante, come suggerisci. Hai anche ragione a dire che sono coinvolti algoritmi di sweep piano o sweep di linea, ma sfortunatamente questa è una tecnica generale che copre quasi tutte le procedure di geometria computazionale, quindi non è un termine adatto per cercare specificamente il tuo algoritmo. Si noti che questo particolare problema non è puramente teorico-grafico, poiché comporta un incorporamento del complesso polilinea in un piano (o sfera), quindi un buon algoritmo deve conservare le informazioni sull'incorporamento: ecco perché è davvero un problema di riempimento di area al cuore.

— whuber

5

Nella teoria dei grafi , questa operazione è chiamata calcolo delle facce . È correlato al calcolo del doppio di un dato grafico.

Ad esempio, nella libreria java GeOxygène , un grafico (chiamato CarteTopo ) ha un metodo getFaces per recuperare la sua faccia .

Questo si chiama poligonizzazione in JTS

— julien
fonte

Buoni collegamenti. Tuttavia, tutti presumono che il problema di @ Dan sia già stato risolto: essere in grado di chiamare un grafico "planare" significa che hai già identificato le facce poligonali. Vuole sapere come si fa a convertire una raccolta arbitraria di archi (nel piano) in un grafico planare onesto-alla bontà, in primo luogo. Ciò richiede la costruzione di una rappresentazione della sua "topologia", come un DCEL.

— whuber

Grazie mille whuber, sei una fonte di conoscenza! Mi chiedo come qualcuno possa essere così brillante.

— luglio

4

Il software host RepRap converte un elenco di segmenti di linea (in un ordine casuale sconosciuto) in un elenco di poligoni, che suona in modo simile a quello che stai cercando di fare.

In particolare, l' algoritmo RepRap "end matching" gestisce una serie di casi patologici.

Purtroppo il software RepRap presuppone che ogni angolo ha una ancor numero di spigoli che vanno ad esso - 2 linee che vanno ad un angolo di un oggetto normale; 4 linee che si uniscono quando l'angolo di un oggetto tocca l'angolo di un altro oggetto, ecc. Non so quanto sia difficile adattare questo algoritmo per gestire i diagrammi di voronoi, che di solito ha 3 bordi che vanno ad ogni angolo.

— David Cary
fonte

+1 Trova interessante! Attenzione però: sebbene questo software sembri in grado di risolvere molti problemi relativi alla connessione di linee in poligoni, potrebbe fare troppo : sembra che cerchi di semplificare anche le funzionalità, il che potrebbe essere un effetto indesiderato. (Ad esempio, può distruggere l'integrità topologica.)

— whuber

3

hai esplorato la base di codice di GRASS per una soluzione al tuo problema? -> http://old.nabble.com/Polyline-to-Polygon-operation-td20257839.html

— oeon
fonte

1

Grazie ... ma io non sono alla ricerca di uno specifico "confezionato" soluzione, ma l'algoritmo e / o il nome che sarebbe venuto le varie aree di GIS, Comp Geom e / o Comp Sci ... tenere le idee provenienti sottostanti

Stavo pensando di guardare specificamente il codice sorgente dietro i 2 processi citati nel mio link potrebbe aiutarti.

— oeon,

Immagino che dovrei installare il software per vedere il codice poiché non vedo alcun elenco su quelle pagine a meno che non mi manchi qualcosa.

1

È possibile sfogliare fonte ERBA on-line: trac.osgeo.org/grass/browser

— Sottosuolo

@underdark Grazie per il puntatore. Per quanto posso dire dalla main.cnella v.typefonte, tutto ciò che accade è che le caratteristiche sono ri-etichettati come i confini: si verifica alcuna elaborazione vera e propria. In retrospettiva questo non è troppo sorprendente: se (non lo so per certo) le funzioni vengono mantenute con informazioni topologiche 2D complete, tutto il calcolo per identificare le regioni poligonali ha luogo automaticamente durante la creazione o l'importazione delle caratteristiche e viene mantenuto per tutto tutte le operazioni di geoprocessing.

— whuber

3

ciao

Non credo che quello che stai cercando sia un algoritmo specifico. L'attività può essere piuttosto difficile o molto semplice a seconda del set di dati.

Dovresti dividere il problema in almeno 2 parti. 1) è più un problema di rete, come trovare anelli chiusi di linestring. 2) esprimere la stringa lineare chiusa come un poligono

La seconda parte, che "converte le linee in poligoni", dipende più dal formato che dalla rappresentazione poligonale / linestring. Intendo andare da:

LINESTRING (1 1, 2 2)
LINESTRING (2 2, 2 1)
LINESTRING (2 1, 1 1)

a:
POLYGON ((1 1,2 2,2 1,1 1))

sta convertendo la linea in poligono, ma non è quello di cui stai parlando, immagino. La parte più difficile è la prima. Se hai uno spaghetti di linee, come ordinarli come linee chiuse.

Immagino che la risposta a questa domanda dipenda molto dal set di dati. Come chiede Kirk, se le linee possono attraversare il problema è molto più grande. Se sai che tutte le "raccolte di linee" fanno parte di una stringa lineare chiusa, diventa più facile. Quindi puoi prendere qualsiasi linea e camminare lungo il percorso fino a quando non torni di nuovo e quindi passare al passaggio due sopra.

Il mio punto è che la condizione del set di dati imposta tutte le regole su come farlo. Se vuoi trovare tutti i possibili poligoni in uno spaghetto di linestring, suppongo che ci saranno molti algoritmi diversi per mettere i punti di vertice in tutti gli incroci, cercare tutti i possibili percorsi e così via.

In PostGIS la funzione si chiama ST_Polygonize. Questa funzione crea tutti i possibili poligoni dalle stringhe di linea che gli vengono fornite.

Questo viene eseguito da GEOS in modo da poter trovare gli algoritmi dietro sia nel codice GEOS che nel codice JTS.

Solo alcuni pensieri

/ Nicklas

— Nicklas Avén
fonte

1

Potresti provare a cercare l'algoritmo "Forward Star". Mi è stato detto che è generico, ma le uniche discussioni a riguardo che abbia mai letto erano sempre riferite ad arcgis. Forse guarda i riferimenti citati in queste note di lezione per la stella in avanti.

— Kirk Kuykendall
fonte

1

Commenterò qui, anche se questo commento affronta anche alcune altre soluzioni proposte: il problema non può essere rappresentato in una rete (o grafico). Richiede informazioni su come le linee sono collegate all'interno di una superficie bidimensionale . Quindi le rappresentazioni di stelle avanti / indietro sarebbero di scarsa utilità; è necessario un DCEL o qualcosa del genere.

— whuber

@whuber - Supponevo che il commento di Dan che tutti i "difetti" fossero stati rimossi implicasse che le linee fossero pulite. Come tale, dovrebbe essere possibile ridurre questo a un problema di attraversamento di grafici nel trovare tutti i cicli in un grafico. All'inizio ho pensato che la stella in avanti avrebbe aiutato gli algoritmi che percorrevano un grafico prendendo la svolta a destra più nitida possibile su ciascun nodo. Tuttavia, guardando un po 'di più sembra che ci siano modi migliori. stackoverflow.com/questions/261573/… Tuttavia, ciò presuppone che il problema possa essere ri-dichiarato come grafico.

— Kirk Kuykendall,

1

Trovare i cicli in un grafico non equivale a trovare le facce in un grafico planare. Considera il grafico astratto con vertici {a, b, c, d} e bordi {a, b}, {a, c}, {b, c}, {b, d}, {c, d}. Una base per i cicli è costituita da a-> b-> d-> c-> a e a-> b-> c-> a. Nell'incorporamento planare a -> (0,1), b -> (2,2), c -> (2,0), d -> (3,1) (dove tutti i bordi sono segmenti di linea), il ciclo a-> b-> d-> c-> a non è una faccia, ma se spostiamo d su (1,1), è una faccia. Questo mostra perché il concetto di "faccia" richiede che il grafico sia incorporato nel piano e perché le facce non possano essere calcolate puramente dalla struttura astratta del grafico.

— whuber