День добрый!

Есть база объектов с координатами. Возникает необходимость проверять принадлежность точки некоторой области. Область задается произвольным многоугольником.
Есть ли смысл использовать геометрические типы (polygon, point) для решения этой задачи?
Увидел функцию geometry_contain, обрадовался. Оказалось зря - при определении принадлежности, полигон "достраивается" до прямоугольника, и таким образом, функция возвращает неверный результат. Например:

Можно ли как-то обойти эту аппроксимацию какими-то стандартными средствами?
И еще, есть ли документация по использованию геометрических функций, а то может я коряво их использую?

Не суть, это ничего не изменит, типы воспринимаются адекватно и без явного преобразования. На посгисе искал, ничего толкового не нашел. Если ткнете - буду признателен.

Ёш , здорово!
У меня 7.4.
Пробовал вот это:
- не годилось; Ваше же работает, спасибо!
А для мультиполигонов есть такое?

Iz ,
Ну то, что @ работает с геометрическими типами постгреса, Ёш наглядно показал, так что тут вопрос отпал. Собсно, неадекватно работает функция geometry_contain, а она, как я полагаю уже постгисовская. Кроме нее в базе создалось (при подключении библиотеки и последующем выполнении скрипта, как описано тут ) еще куча функций, описания которых мне найти, к сожалению, пока не удалось. Функцию geometry_contain предполагалось использовать для принадлежности точки постгивскому мультиполигону, аналога которого в геометрических типах постгреса, как я понял, нет. Вариант, конечно, проверять принадлежность точки каждому полигону из мультиполигона. Но если есть способ проще - логично бы его использовать.
Данные плоские, порядка 200 000 точек (точки, вершины полигонов, точки путей и тп), помимо contains еще будет необходимо, как минимум, находить точки пересечения.

Послушав iz a, создал поле po_point геометрического постгресовкого типа point.
Написал функцию f_pol(varchar(5)), которая из точек собирает область, типа polygon.
Теперь надо, например, вывести все точки принадлежащие некоторой области OBL01:
Запрос работает ну очень медленно. Индексов по полю нет, а, видимо, нужны.
Докуметацию я, конечно, почитываю, но пока толком не разобрался.
Если кто сталкивался, подскажите, как это все делается.

Quadrix,
Спасибо, ту документацию я уже читал и на русском и на английском. И, насколько я понял, в последних версиях postgis+geos функция типа пересечения или принадлежности уже включает "обрамляемую" contains. Вот только собсно с функций постгиса и начался этот топик. Сейчас, все-таки пытаюсь разобраться с постгрисовскими геометрическими типами - их бы еще проиндексировать как-нить. А функцию я слегка изменил, добавив immutable - стало работать значительно быстрее, и, в общем-то, пока терпимо.
А вот с индексами пока еще вопрос открыт.

QuadrixПо какому критерию или чем не устраивают индексы типа r-tree или gist? Может быть Вы имеете в виду нечто вроде "доменных" индексов? Т.е. плоскость делится на участки (прямоугольники), с которыми сопоставляются объекты внутри них.
Боже упаси, не надо пока никаких доменных индексов. ) Обычные бы построить. Не хочет постгрес строить чета индексы по полю типа point. Грит надо создать или указать класс операторов. Приоритеты немного смещались - не успел разобраться, как это сделать. Так что буду благодарен, если объясните.

Про immutable - я так понял, это позволяет вычислять функцию один раз, и потом проводить сравнения с ее результатом, а не вычислять ее заново для каждой строчки. Ну это мое понимание, мб я и не прав, но работает, в моем случае, значительно быстрее.

IMMUTABLE indicates that the function always returns the same result when given the same argument values; that is, it does not do database lookups or otherwise use information not directly present in its argument list. If this option is given, any call of the function with all-constant arguments can be immediately replaced with the function value.

Ну вообще-то, я думал об индексах типа gist или r-tree. В postgis gist-овый индекс строится по типу geometry, в том числе, если в поле geometry содержатся точки. Думается, что это возможно и с геометрическими типами postgres'a. 8.3 без проблем строит gist-индекс по типу polygon, например (в 7.4 не хочет).
Собственно, сравнения для координат и не нужны. Нужен, прежде всего, оператор принадлежности @.
Сейчас из 200 000 точек, принадлежащие заданному полигону точки, перебором находятся за 2-4 секунды. Хотелось бы побыстрее. Если есть какие-то мысли - в студию, буду весьма признателен.