Como você trata os recursos 3D parciais no PostGIS?

10

Temos recursos de dados de pesquisa que contêm informações 3D parciais.

O exemplo mais comum seria um LineString 2D representando uma estrada, que contém informações de elevação em determinados pontos em que foi pesquisada. Outros exemplos incluem formas de telhado - Um MultiLineString em que alguns pontos-chave têm uma elevação atribuída a partir do plano de construção, mas não todos.

Usando o PostGIS, qual modelo de dados você recomendaria para armazenar esse tipo de informação, para mantê-lo o mais acessível possível, sem perder ou gerar informações interpoladas?

postgis data 3d model

— relet
fonte

2D LineString representando uma estrada, que contém a elevação - de modo que é 3D - uso ST_Force_3D para os seus dados - postgis.refractions.net/documentation/manual-1.5SVN/...

— Mapperz

Uma coordenada 0 z não está correta e não representa o mesmo valor que a fonte de dados. ST_Force_3D não funcionará para nós. A ideia é ter um mapeamento bidirecional correto entre a fonte de dados e nosso banco de dados.

— relet

2

Você pode armazenar os valores Z não medidos como 'nan'::float8. Por exemplo:

SELECT ST_AsText(g), ST_X(g), ST_Y(g), ST_Z(g), ST_Z(g) <> 'nan'::float8 AS has_z
FROM (
  SELECT ST_MakePoint(1, 2, 'nan'::float8) AS g
  UNION SELECT ST_MakePoint(4, 5, 6) AS g
) AS f;

       st_astext       | st_x | st_y | st_z | has_z
-----------------------+------+------+------+-------
 POINT Z (1 2 1.#QNAN) |    1 |    2 |  NaN | f
 POINT Z (4 5 6)       |    4 |    5 |    6 | t
(2 rows)

No entanto, isso pode causar problemas, pois os valores de NaN nem sempre são testados ou manipulados pelos desenvolvedores de software. Por exemplo, o PostGIS não pode analisar a versão WKT acima

SELECT 'POINT Z (1 2 1.#QNAN)'::geometry;

ERROR:  parse error - invalid geometry
LINE 1: SELECT 'POINT Z (1 2 1.#QNAN)'::geometry;
               ^
HINT:  "POINT Z (1 2 1.#Q" <-- parse error at position 17 within geometry

— Mike T
fonte

1

Crie uma coluna de geometria secundária com três dimensões para conter os vértices da cadeia de linhas que possuem os valores de três ordenadas (triplas). Para que esse esquema funcione, as seguintes suposições são assumidas:

a cadeia de linhas é válida, não contém pontos duplicados
geometrias são cadeias de linhas
deve haver pelo menos dois vértices com coordenadas 3d em uma determinada geometria para que seja elegível para ser armazenado em uma coluna de geometria secundária
um gatilho preencherá a coluna de geometria secundária para mantê-la ACID.

A geometria válida deve ser suficiente para não permitir pontos duplicados em cadeias de linhas e nenhuma interseção automática. Portanto, cada coordenada se comportará como uma chave de primery para identificar o vértice na geometria de origem.

Isso também está correto no modelo relacional:

não haverá redudância, o vértice sem informação não apareceu na coluna de geometria secundária
as alterações nos dados de origem serão propagadas para os dados derivados pelo gatilho.
somente as informações consideradas verdadeiras serão armazenadas no banco de dados, nenhum dado artificial será criado.

Para o caso de várias linhas, as coisas podem ser um pouco mais difíceis, já que agora deve ter uma tabela adicional com uma chave primária composta:

o rowid (gid, um identificador exclusivo) da geometria de origem
a posição geometryN dentro da MultiGeometry fornecida que deve ser verificada dentro do intervalo [1-N]
uma chave estrangeira para a tabela relacionada rowid (gid)
uma função de disparo / verificação para garantir que o intervalo seja válido

A chave primária acima evitará inserções de índices de geometria duplicados para uma determinada geometria. O gatilho / verificação impedirá índices inválidos. Também as linhas aqui devem ser de dados de origem, dada a chave estrangeira. Todas as regras anteriores se aplicam.

Uma simplificação seria o uso de uma coluna adicional, mas não da geometria de tipo, mas do mesmo tipo de valor Z declarado como matriz.

— cavila
fonte