SQL Server 2008+: Miglior metodo per rilevare se due poligoni si sovrappongono?

Question

Abbiamo un'applicazione che ha un database pieno di poligoni (attualmente memorizzati come punti), che un'applicazione .NET tira fuori e controlla se si sovrappongono.

I venuto in mente che sarebbe stato molto più bello di convertire queste matrici di punti a poligono / polilinea oggetti all'interno del database e l'uso di SQL per ottenere un bool di tempo si sovrappongono o meno.

ho visto diversi metodi suggeriti per fare questo, ma non degli esempi forniti erano abbastanza in linea con le mie esigenze.

sarei molto felice di ricevere input da quelli così gentile da offrire la loro esperienza.

Ulteriori:

In risposta alle domande: E 'davvero 2D. e sì qualsiasi incrocio dei due è considerata vera. I poligoni sono n punti e può essere concava. I poligoni saranno salvate come 1 per fila (dopo la conversione dei dati delle applicazioni) come poligoni (vale a dire il tipo di poligono .. si potrebbe essere chiamato qualcos'altro spaziale / geom la mia memoria non è dalla mia parte in questo momento)

Answer 1

È possibile utilizzare .STIntersection con .STAsText () per test per la sovrapposizione di poligoni. (Io odio la terminologia Microsoft ha utilizzato (o chi impostato le condizioni standard). "Commovente", nella mia mente, dovrebbe essere un banco di prova per se o non due geometria / geografia forme si sovrappongono a tutti, non solo condividere un confine.)

In ogni caso ....

Se @RadiusGeom è una geometria che rappresenta un raggio da un punto, il seguente restituirà un elenco di tutte le due poligoni dove un incrocio (una geometria che rappresenta l'area in cui le due forme geometriche si sovrappongono) non è vuoto.

SELECT CT.ID AS CTID, CT.[Geom] AS CensusTractGeom
FROM CensusTracts CT
WHERE CT.[Geom].STIntersection(@RadiusGeom).STAsText() <> 'GEOMETRYCOLLECTION EMPTY'

Se il campo geometria è spazialmente indicizzato, questo viene eseguito abbastanza rapidamente. Ho eseguito questo su 66.000 record degli Stati Uniti TC in circa 3 secondi. Ci può essere un modo migliore, ma dal momento che nessun altro aveva una risposta, questo era il mio tentativo di una risposta per voi. Speranza che aiuta!

Answer 2

calcolare e memorizzare il rettangolo di delimitazione di ogni poligono in una serie di nuovi campi all'interno della riga che è associato con quel poligono. (I suppone che si abbia uno,. In caso contrario, crearne uno) Quando il vostro dotnet applicazione ha un poligono e è alla ricerca di poligoni sovrapposti, si può recuperare dal database solo i poligoni i cui rettangoli di delimitazione si sovrappongono, con un relativamente semplice istruzione SQL SELECT. Quei poligoni dovrebbero essere relativamente pochi, quindi questo sarà efficace. Poi, il dotnet applicazione in grado di eseguire il poligono più fine sovrapposizione calcoli al fine di determinare quali di quelli veramente sovrapposizione.

Answer 3

Va bene, ho avuto un'altra idea, così mi distacco come una risposta diversa. Credo che la mia risposta precedente, con i poligoni che delimitano probabilmente ha qualche merito da solo, anche se è stato quello di ridurre il numero di poligoni recuperati dal database da una piccola percentuale, ma questo è probabilmente meglio.

MSSQL supporta l'integrazione con il CLR dalla versione 2005. Ciò significa che si può definire un tipo di dati in un assieme, registrare l'assembly con MSSQL, e da quel momento in poi MSSQL sarà di accettare il tipo di dati definiti dall'utente come un tipo valido per una colonna, e sarà invoca vostra assemblea per eseguire operazioni con il vostro tipo di dati definito dall'utente.

Un articolo esempio per questa tecnica su CodeProject: Creazione definiti dall'utente tipi di dati in SQL Server 2005

Non ho mai usato questo meccanismo, in modo da non so dettagli su di esso, ma presumo che si dovrebbe essere in grado di definire sia una nuova operazione sul tipo di dati, o forse sovraccarico alcune operazioni esistenti come "meno-che" , in modo da poter verificare se un poligono interseca l'altro. Questo rischia di accelerare le cose un sacco.