Jakie są konsekwencje nieprawidłowych geometrii

15

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ą?

diciu
źródło

Odpowiedzi:

19

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
1
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,
1
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,
13

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