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.
fonte
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/
fonte
(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.
fonte