Enormi dati laser a nuvola di punti in PostGIS - Archiviazione ed elaborazione

Mi chiedo come sia possibile archiviare in PostGIS enormi set di dati di nuvole di punti scannerizzati a laser, tenendo conto dell'aspetto temporale per l'elaborazione. Lo so, esiste un oggetto geometria Pointin PostGIS. Ma per quanto ne so, salva ogni punto in una nuova tupel, che può rendere la ricerca di un determinato punto un processo molto lento, se ne vengono memorizzati alcuni milioni o più.

Ho trovato un articolo di Rapperswill della HSR Universtiy of Applied Sciences, che parlava di questo argomento. Suggerisce tre modi per archiviare tali dati: o Whole data in one tupel, a cui fanno riferimento tabelle informative, che contengono le estensioni di ciascun blocco. Dato che la terza via sembra la più utile per localizzare i punti memorizzati, mi chiedo se qualcuno abbia già fatto delle esperienze con esso?Each point in one tupelSplitting Data into Blocks

Il documento è disponibile qui: http://wiki.hsr.ch/Datenbanken/files/pgsql_point_cloud.pdf

Ultimo ma non meno importante, mi sono imbattuto in un progetto su github, che sembra gestire i modi delle nuvole di punti in PostgeSQL. Purtroppo non ci sono molte informazioni al riguardo in rete. Quindi la stessa domanda qui: qualcuno ha già fatto delle esperienze con esso? È utilizzabile per tali scopi?

Il progetto può essere trovato qui: https://github.com/pramsey/pointcloud

Sarei anche felice di conoscere altri suggerimenti, idee o esperienze, se ce ne sono. Ma devo ammettere che si preferiscono soluzioni non commerciali.

C'è molto nella tua domanda. La risposta breve è sì, è completamente possibile archiviare enormi dati della nuvola di punti in PostGIS e utilizzarli per l'elaborazione. Abbiamo creato un sistema così completo che fa questo.

Questo video è un po 'obsoleto con i suoi numeri, ma avevamo TB di dati mobili / terrestri e aerei in postgis accessibili tramite Python per l'elaborazione nel back-end e con un front-end Web che consente la visualizzazione 3D e il download dei dati. https://vimeo.com/39053196

Dipende da come scegli di archiviare i dati in PostGIS e da come accederai. Una buona soluzione per i dati aerei potrebbe essere quella di grigliare i dati in qualche modo e utilizzare i punti multipli per l'efficienza. Tuttavia, se stai lavorando con dati mobili o terrestri in cui la densità dei punti può essere tra 500-30000 + punti per metro quadrato questo approccio non funziona. Quindi si tratta di esaminare il tuo hardware e il numero di utenti simultanei che ti aspetti. Dettagli al riguardo sono disponibili in alcuni dei nostri articoli http://www.mendeley.com/profiles/conor-mc-elhinney/

(La risposta si basa sui miei e altri commenti sopra; non l'ho davvero testato)

Memorizza i punti come MultiPointZM. La dimensione della griglia migliore dipende probabilmente dai modelli di accesso e su questo devi fare alcuni test. Una griglia regolare con un indice spaziale dovrebbe rendere le query abbastanza veloci. Se l'accesso 3d è importante, MultiPointZM potrebbe essere basato su blocchi 3D (1) anziché su una griglia di piano 2D, quindi (se hai PostGIS> = 2.0) potresti utilizzare &&& per query 3D veloci.

È inoltre possibile memorizzare il modello di griglia in una tabella separata, il che potrebbe essere utile, ad esempio, quando si aggiornano i dati e si convalida che i blocchi MultiPointZM rimangano entro i limiti dopo le modifiche, ecc.

La memorizzazione di timestamp o altri dati sarebbe possibile solo per un blocco alla volta, ma alcuni dati binari / di categoria potrebbero essere archiviati disaggregando ciascun blocco per attributo se non ci sono troppe categorie e / o attributi.

Se alla fine dovessi archiviare i dati come PointZM separato, una chiave esterna nella tabella della griglia + indice B-Tree renderebbe il caricamento solo dei punti specifici (probabilmente) molto più veloce rispetto alla semplice richiesta diretta della tabella, anche con una spaziatura indice.

(1) Se l'intervallo dei valori Z è piccolo (dopo tutto è una strada), probabilmente non ha senso.