Jak traktujesz częściowe funkcje 3D w PostGIS?

10

Mamy funkcje z danych ankietowych, które zawierają częściowe informacje 3d.

Najczęstszym przykładem jest 2D LineString reprezentujący drogę, która zawiera informacje o wysokości w niektórych punktach, w których była badana. Inne przykłady obejmują kształty dachu - MultiLineString, w którym niektóre kluczowe punkty mają przypisane rzędne z rzutu budynku, ale nie wszystkie.

Korzystając z PostGIS, który model danych zaleciłby Pan do przechowywania tego rodzaju informacji, aby był jak najbardziej dostępny, bez utraty lub generowania interpolowanych informacji?

relet
źródło
2D LineString reprezentujący drogę, która zawiera wzniesienie - czyli 3D - użyj ST_Force_3D do swoich danych - postgis.refractions.net/documentation/manual-1.5SVN/…
Mapperz
Współrzędna 0 z jest niepoprawna i nie reprezentuje tej samej wartości co źródło danych. ST_Force_3D nie będzie dla nas działać. Chodzi o to, aby mieć prawidłowe mapowanie dwukierunkowe między źródłem danych a naszą bazą danych.
relet

Odpowiedzi:

2

Możesz zapisać niezmierzone wartości Z jako 'nan'::float8. Na przykład:

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)

Może to jednak sprawić kłopoty, ponieważ wartości NaN nie zawsze są testowane lub obsługiwane przez twórców oprogramowania. Np. PostGIS nie może przeanalizować powyższej wersji WKT

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.
źródło
1

Utwórz kolumnę geometrii wtórnej z trzema wymiarami, aby utrzymać wierzchołki linii, która ma wartości trzech rzędnych (potrójnych). Aby ten schemat działał, przyjmuje się następujące założenia:

  • oznaczenie linii jest ważne, nie zawiera zduplikowanych punktów
  • geometrie są liniami
  • muszą istnieć co najmniej dwa wierzchołki ze współrzędnymi 3d w danej geometrii, aby można było elegancko przechowywać je w kolumnie geometrii wtórnej
  • wyzwalacz wypełni kolumnę geometrii wtórnej, aby pozostała ACID.

Geometria, która jest poprawna, powinna wystarczyć, aby nie dopuścić do powielania punktów w liniach liniowych i braku przecięcia. Tak więc każda współrzędna będzie zachowywać się jak klucz pierwotny w celu identyfikacji wierzchołka w geometrii źródłowej.

Jest to również poprawne z modelu relacyjnego:

  • nie będzie redudancji, wierzchołek bez informacji nie pojawił się w kolumnie geometrii wtórnej
  • zmiany danych źródłowych będą propagowane do danych pochodnych przez wyzwalacz.
  • tylko informacje uznane za prawdziwe będą przechowywane w bazie danych, nie będą tworzone żadne sztuczne dane.

W przypadku multilinestringu sprawy mogą być nieco trudniejsze, ponieważ teraz musi istnieć dodatkowy stół z kompozytowym kluczem podstawowym:

  • rowid (gid, unikalny identyfikator) geometrii źródłowej
  • pozycja geometrii N wewnątrz danej MultiGeometrii, którą należy sprawdzić, która znajduje się w przedziale [1-N]
  • klucz foreing do powiązanej tabeli rowid (gid)
  • funkcja wyzwalania / sprawdzania, aby upewnić się, że interwał jest prawidłowy

Klucz podstawowy powyżej zapobiegnie wstawianiu zduplikowanych indeksów geometrii dla danej geometrii. Wyzwalanie / sprawdzanie zapobiegnie nieprawidłowym indeksom. Również wiersze tutaj muszą pochodzić z danych źródłowych, biorąc pod uwagę klucz obcy. Obowiązują wszystkie poprzednie zasady.

Uproszczenie polegałoby na zastosowaniu dodatkowej kolumny, ale nie o dobrej geometrii, ale o tym samym typie wartości Z zadeklarowanej jako tablica.

Cavila
źródło