Які наслідки недійсних геометрій

Я імпортував деякі дані в базу даних Postgis, а деякі геометрії вважаються недійсними (ST_IsValidReason повідомляє про самоперетин або кільцеве самопересічення).

На запити, які я виконую, не впливає недійсний аспект цих геометрій (я використовую лише запити ST_Distance).

Які речі порушуються, коли геометрії недійсні?

Чи виправлення цих геометрій "автоматично" (буфер (geom, 0) або ST_SimplifyPreserveTopology (geom, 0,0001)) є варіантом?

postgis geometry invalid-data

— diciu
джерело

Зберігати неправильно сформовані дані - погана ідея, оскільки ви ніколи не можете передбачити, коли і де відбудеться збій. Більше того, неправильно сформовані дані можуть спричинити Heisenbugs , найбільш злий і ілюзивний тип помилок.

Я думаю, що обговорювати можливий результат зберігання недійсних геометрій трохи безглуздо. Зважаючи на це, наслідки можуть включати:

Неправильні результати (тобто, ST_Distanceповертаються неточні або просто неправильні цифри)
Проблеми з базою даних: Зберігання неправильно сформованих даних може серйозно пошкодити продуктивність бази даних та створити величезний файл журналу, оскільки кожен виклик функції запише помилку в журнал і порушить звичайну роботу бази даних.
Збої бази даних
Збої програми - або спричинені отриманням неправильно сформованих даних із бази даних, або отриманням необґрунтованих результатів (наприклад, негативна відстань).
Фантомна поведінка (див. Посилання вище). Це найгірший наслідок усіх. У вас трапляться дивні речі. Уповільнення, втрата даних, збої, необґрунтовані результати, довгі паузи, відсутність чуйності та багато інших прокльонів. Можливо, ви не зможете їх помітити або відтворити, оскільки всі вони підпадають під категорію "невизначено" у кожній документації.

Моя порада - якщо маленькі буфери не завдають істотної шкоди послідовності даних, використовуйте їх, щоб не допустити будь-якого з перерахованого. Зберігайте ваші дані дійсними.

— Адам Матан
джерело

Чи можете ви трохи зупинитися на використанні малих буферів? Як це зробити?

— diciu

ST_Buffer(the_geom, 0.0000001)може зробити трюк для самостійного перетину. Використовуйте його лише в тому випадку, якщо наслідки трохи більшої геометрії не є серйозними.

— Адам Матан

Мій досвід полягає в тому, що виправлення неправильно сформованих даних - досить розслідування. Але хоча це забирає багато часу, воно, як правило, варто докласти зусиль. ST_Buffer(the_geom, 0.0000001)Трюк безперечно допомагає.

— Чау

Справа в тому, що ST_Buffer фіксує геометрію, але результат насправді не такий, як я очікував - для цього недійсного багатокутника тут ( openstreetmap.org/browse/way/51954364 ) ST_Buffer повертає лише верхній лівий прямокутник. ST_SimplifyPreserveTopology, здається, наближається до того, що мені потрібно (дійсна геометрія, але максимально наближена до недійсного оригіналу). Будь-які недоліки використання ST_SimplifyPreserveTopology?

— diciu

Ця геометрія повинна оброблятися як MULTIPOLYGONдва полігони, а не як єдиний POLYGON. Спробуйте отримати оригінальний WKT, якщо це можливо.

— Адам Матан

Ви можете в першу чергу запобігти введенню недійсних геометрій у вашу базу даних. Для користувачів PostgreSQL / PostGIS це просто зробити з контрольними обмеженнями . Наприклад, розгляньте таблицю public.my_valid_tableзі стовпцем геометрії багатокутника geom, використовуйте наступні SQL / DDL:

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

Примітка. Ця таблиця повинна мати дійсні багатокутники перед застосуванням обмеження.

Якщо ви спробуєте вставити / додати недійсну геометрію, ви побачите помилку:

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

— Майк Т
джерело