Jakie są konsekwencje nieprawidłowych geometrii

Zaimportowałem niektóre dane z bazy danych Postgis, a niektóre geometrie zostały zgłoszone jako nieprawidłowe (ST_IsValidReason zgłasza samo-skrzyżowanie lub samo-skrzyżowanie pierścienia).

Wydaje się, że na zapytania, które wykonuję, nie ma wpływu nieprawidłowy aspekt tych geometrii (używam tylko zapytań ST_Distance).

Jakie rzeczy psują się, gdy geometrie są nieprawidłowe?

Czy naprawianie tych geometrii „automatycznie” (bufor (geom, 0) lub ST_SimplifyPreserveTopology (geom, 0.0001)) jest opcją?

postgis geometry invalid-data

— diciu
źródło

Przechowywanie źle sformułowanych danych to zły pomysł, ponieważ nigdy nie można przewidzieć, kiedy i gdzie nastąpi awaria. Co więcej, zniekształcone dane mogą powodować błędy Heisenbugs , najbardziej błędne i iluzoryczne.

Myślę, że omawianie możliwego wyniku przechowywania nieprawidłowych geometrii jest nieco bezcelowe. Powiedziawszy to, konsekwencje mogą obejmować:

Błędne wyniki (tzn. ST_DistanceZwracają niedokładne lub zwykłe błędne liczby)
Problemy z wydajnością bazy danych: Przechowywanie zniekształconych danych może poważnie zaszkodzić wydajności bazy danych i utworzyć ogromny plik dziennika, ponieważ każde wywołanie funkcji spowoduje zapisanie dziennika w dzienniku i zakłóci zwykłą pracę bazy danych.
Awaria bazy danych.
Awarie aplikacji - spowodowane albo otrzymaniem zniekształconych danych z bazy danych, albo otrzymaniem nieuzasadnionego wyniku (na przykład ujemna odległość).
Zachowanie fantomowe (patrz link powyżej). To najgorsza konsekwencja ze wszystkich. Będziecie się dziać dziwne rzeczy. Spowolnienia, utrata danych, awarie, nieuzasadnione wyniki, długie przerwy, brak reakcji i wiele innych przekleństw. Być może nie będziesz w stanie ich wykryć ani powielić, ponieważ wszystkie znajdują się w kategorii „niezdefiniowana” w każdej dokumentacji.

Moja rada - jeśli małe bufory nie wpływają znacząco na spójność danych, użyj ich, aby zapobiec wystąpieniu któregokolwiek z powyższych. Utrzymuj ważność swoich danych.

— Adam Matan
źródło

Czy możesz trochę rozwinąć stosowanie małych buforów? W jaki sposób mogę to zrobić?

— diciu

ST_Buffer(the_geom, 0.0000001)może załatwić sprawę na skrzyżowaniu. Używaj go tylko wtedy, gdy konsekwencje nieco większej geometrii nie są poważne.

— Adam Matan,

Z mojego doświadczenia wynika, że poprawianie źle sformułowanych danych to dość dochodzenie. Ale choć jest to czasochłonne, zwykle jest warte wysiłku. ST_Buffer(the_geom, 0.0000001)Trik zdecydowanie pomaga.

— Chau,

Rzecz w tym, że ST_Buffer naprawia geometrię, ale wynik nie jest dokładnie tym, czego się spodziewałem - dla tego nieprawidłowego wielokąta tutaj ( openstreetmap.org/browse/way/51954364 ) ST_Buffer zwraca tylko lewy górny prostokąt. ST_SimplifyPreserveTopology wydaje się być bliżej tego, czego potrzebuję (poprawna geometria, ale jak najbliżej nieważnego oryginału). Jakieś wady korzystania z ST_SimplifyPreserveTopology?

— diciu

Ta geometria powinna być przetwarzana jako jeden MULTIPOLYGONz dwóch wielokątów, a nie jako pojedynczy POLYGON. Spróbuj uzyskać oryginalny WKT, jeśli to możliwe.

— Adam Matan,

Możesz przede wszystkim zapobiegać przedostawaniu się nieprawidłowych geometrii do bazy danych. Dla użytkowników PostgreSQL / PostGIS jest to proste w przypadku ograniczeń sprawdzania . Rozważmy na przykład tabelę public.my_valid_tablez kolumną geometrii wielokątów geom, użyj następującego kodu SQL / DDL:

ALTER TABLE public.my_valid_table
  ADD CONSTRAINT enforce_valid_geom CHECK (st_isvalid(geom));

Uwaga: ta tabela musi mieć prawidłowe wielokąty przed wymuszeniem ograniczenia.

Jeśli następnie spróbujesz wstawić / dodać nieprawidłową geometrię, zobaczysz błąd:

ERROR:  new row for relation "my_valid_table" violates check constraint "enforce_valid_geom"

— Mike T.
źródło