Dados enormes de laser de nuvem de pontos no PostGIS - Armazenando e processando-os

Gostaria de saber como é possível armazenar enormes conjuntos de dados da nuvem de pontos digitalizados a laser no PostGIS, com o aspecto do tempo para processá-los. Eu sei, existe um objeto de geometria Pointno PostGIS. Mas, tanto quanto sei, salva cada ponto em um novo tupel, o que pode tornar a busca por qualquer ponto um processo muito lento, se alguns milhões ou mais deles estiverem armazenados.

Encontrei um artigo da HSR University of Applied Sciences Rapperswill, discutindo esse tópico. Ele sugere três maneiras de armazenar tais dados: Whole data in one tupel, Each point in one tupelou Splitting Data into Blocksque são referenciados por info-mesas, segurando o estende de cada bloco. Como a terceira maneira parece ser a mais útil para localizar pontos armazenados, será que alguém já fez alguma experiência com isso?

O artigo pode ser encontrado aqui: http://wiki.hsr.ch/Datenbanken/files/pgsql_point_cloud.pdf

Por fim, mas não menos importante, deparei-me com um projeto no github, que parece lidar com as maneiras da nuvem de pontos no PostgeSQL. Infelizmente, não há muita informação sobre isso na rede. Então, a mesma pergunta aqui: alguém já fez algumas experiências com isso? É utilizável para tais propósitos?

O projeto pode ser encontrado aqui: https://github.com/pramsey/pointcloud

Também ficaria feliz em ouvir outras sugestões, idéias ou experiências, se houver alguma. Mas devo admitir que as soluções não comerciais são preferidas.

postgis postgresql lidar

— Knutella
fonte

Você poderia dar uma idéia aproximada do que você quer dizer com enorme, e que tipo de informação da nuvem de pontos você precisa? Ou seja, apenas XYZ e intensidade, que poderiam, por exemplo, ser armazenados no MultipointZM bloqueado ou também em outros dados de atributos que provavelmente exigem que o Point obtenha valores exclusivos para cada medição de ponto separada?

— Torsti

guardo o lidar em multipontos de 10x10 metros por classificação. Nós usamos apenas os valores Z terra

— simplexio

@AndreSilva O objetivo é gerar perfis de superfície das estradas a partir dos dados. Por enquanto, transformamos pontos em grades DEM e usamos o PostGIS para armazená-los como blocos raster e SAGA para criar finalmente os perfis a partir dele. Ele é executado para fins de teste, mas também significa uma perda de precisão através da varredura dos dados antes da importação do banco de dados. Também a exportação das células da grade, cortada pelas linhas de perfil fornecidas, ocorre muito lentamente no PostGIS (graças a ST_Union). Seria bom se você pudesse recomendar ferramentas para tarefas semelhantes.

— knutella

@til_b: Bem, isso é exatamente o que eu estava falando ... Bom encontrar :)

— knutella

Fiz a mesma pergunta e juntei algumas peças para obter um protótipo funcional. Até agora, ele funciona muito bem , sem problemas de escalabilidade, de vários milhões a centenas de milhões de pontos com cerca de 20 atributos cada. Com tantos pontos, encontrar pontos dentro de uma área leva algumas centenas de milis . Leva quase o mesmo tempo para filtrar por carimbo de data / hora (hora exata da aquisição para mim). Nas gerais os perf são igual ou melhor do que em "LiDAR Data Management Pipeline, a partir de banco de dados espacial da população a visualização Web do Aplicativo" Os dados são compactados em DB (cerca de 1: 2

Respostas:

Há muita coisa na sua pergunta. A resposta curta é sim, é completamente possível armazenar enormes dados da nuvem de pontos no PostGIS e usá-los para processamento. Criamos um sistema tão completo que faz isso.

Este vídeo está um pouco desatualizado com seus números, mas tínhamos TBs de dados móveis / terrestres e aéreos em postgis acessíveis através de python para processamento no back-end e com um front-end na Web que permite a visualização e o download em 3D dos dados. https://vimeo.com/39053196

Tudo se resume a como você escolhe armazenar os dados no PostGIS e como os acessará. Uma boa solução para dados aéreos pode muito bem ser a grade de dados de alguma forma e usar multipontos para eficiência. No entanto, se você estiver trabalhando com dados móveis ou terrestres, onde a densidade de pontos pode estar entre 500-30000 + pontos por metro quadrado, essa abordagem não funciona. Então, tudo se resume a analisar seu hardware e o número de usuários simultâneos que você espera. Detalhes sobre isso podem ser encontrados em alguns de nossos artigos http://www.mendeley.com/profiles/conor-mc-elhinney/

— Conor
fonte

Olá, obrigado por tantas informações detalhadas. Os ides / testes oferecidos em seus trabalhos parecem realmente úteis! Levarei algum tempo para ver tudo, mas como eu vi em uma primeira leitura, eles já fornecem soluções completas. Muito obrigado pela adição! Além disso, o vídeo e o visualizador de PC baseado em navegador são bastante interessantes e parecem funcionar muito bem e sem problemas! Infelizmente, peguei minhas mãos em outras coisas. Espero continuar com os dados do PC em breve.

— knutella

O projeto Glimpse tem uma muito legal demonstração aqui: ncg.nuim.ie/glimpse/auth/login.php

— Kozuch

(A resposta é baseada nos comentários meus e de outras pessoas acima; realmente não a testou)

Armazene os pontos como MultiPointZM. O melhor tamanho da grade provavelmente depende dos padrões de acesso e você precisa fazer alguns testes. Uma grade regular com um índice espacial deve tornar as consultas muito rápidas. Se o acesso 3d for importante, o MultiPointZM poderá ser baseado em blocos 3D (1) em vez de uma grade de plano 2D, e se você tiver PostGIS> = 2.0, poderá usar &&& para consultas 3D rápidas.

Você também pode armazenar o padrão de grade em uma tabela separada, o que pode ser útil, por exemplo, ao atualizar os dados e validar que os blocos MultiPointZM permaneçam dentro de seus limites após edições, etc.

Armazenar registros de data e hora ou outros dados só seria possível para um bloco de cada vez, mas alguns dados binários / de categoria poderiam ser armazenados desagregando cada bloco por atributo se não houver muitas categorias e / ou atributos.

Se você precisar armazenar os dados como PointZM separado, uma chave estrangeira na tabela de grade + no índice B-Tree tornaria o carregamento apenas dos pontos específicos (provavelmente) muito mais rápido do que apenas fazer a fila diretamente da tabela, mesmo com um espaço espacial. índice.

(1) Se o intervalo de valores Z for pequeno (afinal, é uma estrada), isso provavelmente não faz sentido.

— Torsti
fonte

Eu acho que o seu 'resumo' chega muito bem como uma conclusão das propostas discutidas anteriormente. Como você disse, a maneira "correta" de carregar esses dados deve ser definida de acordo com as necessidades e as soluções propostas. Acabou não sendo impossível graças a tantas idéias. Isso me deu muita inspiração para meus trabalhos futuros sobre esse assunto. Muito obrigado!

— Knutella