an0nymТолько не MySQL - там из функций только работа с MBR, но не с самими полигонами.
MS SQL, Oracle - там точно всё есть, использовал, особой разницы не заметил.
Остальные не смотрел.
Oracle. Разница с MSSQL очень большая. Скажем так, MSSQL - это где-то 20% того, что есть в Oracle. Ну начните хотя бы с преобразования данных из одной системы координат в другую. Может я плохо искал, но ничего подобного не нашел. Я уже не говорю про поддержку всяких графовых моделей, линейной системы координат или привязанных спутниковых снимков.

Если честно сравнивать, то (поддержка геометрий в MSSQL)~=(Oracle Locator).
Locator - это бесплатное подмножество Spatial, входящее в любую редакцию Oracle (даже XE).

pkarklinAlexander RyndinOracle. Разница с MSSQL очень большая. Скажем так, MSSQL - это где-то 20% того, что есть в Oracle. Ну начните хотя бы с преобразования данных из одной системы координат в другую. Может я плохо искал, но ничего подобного не нашел. Я уже не говорю про поддержку всяких графовых моделей, линейной системы координат или привязанных спутниковых снимков.

Осталось только выяснить у автора топика, что он имел ввиду под "широкая поддержка геотипов и функций для работы с ними" и нужны ли ему эти 80%. ;)
:) я бы даже сказал не "нужны ли ему...", а "возможно ли что понадобятся...", ибо пока не нужны - берем Locator и пользуемся бесплатно. Понадобились - доплачиваем и пользуемся полным функционалом.

А если взять сейчас какой-нибудь MySQL, а потом понадобится 3D-поддержка и поддержка всяких хитрых типов данных, то придется мигрировать. А это, если перефразировать, равносильно 2 потопам. :))

an0nympkarklin,

думаю, автору как раз нужны только базовые типы POINT, LINE, POLYGON и MULTI* и функции по их пересечению, включению и т. п. (но не их MBRов). Но это не отменяет правильности сказанного Alexander Ryndin'ым .
да автор как-то уже потерялся :)

Артем1rilioАртем1,
слои были где-то от 20000 до 100000 объектов, простая их отрисовка, в общем, не тормозила.
Но когда стали активно пользоваться PostGIS-овскими функциями, тормоза стали заметны. В итоге вернулись на "просто Postgres" со своим форматом хранения и обработкой на сервере приложений.
Да, еще столкнулись с тем, что часто вполне корректные данные в SHP или VPF при импорте в PostGIS выдают ошибку при отрисовке (invalid geometry), приходилось править фактически вручную.

ага, понятно, спасибо.
у нас сейчас в слое порядка 200000 геометрий, правда тесно сосредоточенных по москве. Операция только одна применяется - intersects. И для отрисовки, и для идентификации объектов на карте. В принципе производительность устраивает. А по поводу неправильных геометрий - у нас такое тоже было, там в основном незамкнутые shell-ы и касающиеся края holes в полигонах, т.е. кто-то просто неправильно нарисовал полигон, не valid. Возможно, у вас такая-же ситуация.
А вы какими функциями PostGIS пользовались, которые затормозили приложение? Я почему спрашиваю, просто вижу, что функции postgis написаны на C, и сомневаюсь, что нам удастся на сервере приложений java-ском написать что-то более быстрое. А в следующем проекте мы планируем попробовать слой на 500 000 000 объектов. уже по всей планете. И такие проблемы с postgis-ом удручают. Планировали использовать sharding, но если на такое кол-во объектов в слое понадобится тысяча серверов - это конечно перебор.
зы: у нас БД вместе с сервером приложение крутятся на 2-хядерном проце и 4 гига памяти. все на centos.
могуче однако.