PostGIS обновлен до версии 1.5.0. С полным списком изменений и исправленных ошибок можно ознакомиться в трекере. Скачать новую версию можно на официальном сайте.
Главные изменения:
- Новый тип “geography” для нативного управления данными в геодезических координатах. Раньше был доступен только тип “geometry”, его главным недостатком является некорректная работа при пересечение полюсов или линии смены дат. Новый тип может быть полезен в проектах где используются данные в глобальном или континентальном масштабе. Новый тип поддерживается без дополнительных ухищрений например MapServer простым объявлением “init=epsg:4326”, или “proj=lonlat для слоя (LAYER). ?нтересно, что новая функциональность была заказана и финансирована анонимным заказчиком. Стоит отметить, что поддержка нового типа некоторыми функциями (например ST_Buffer или ST_Intersection – ограниченная, также операции с “geography” как правило более медленные. Поддержка геодезических координат до недавнего времени была доступна только в MS SQL Server 2008.
- Улучшенная производительность операций измерения расстояний между сложными объектами за счет использования более производительного алгоритма. По оценке разработчиков, для набора данных из 20 линий, 150 вершин каждая, время запроса уменьшилось с 2000 ms до 160ms. Более подробную информацию и описания алгоритмов можно найти в трекере.
- Чтение форматов GML и KML
- Улучшенный графический интерфейс для загрузки shape-файлов. Несмотря, что этот интерфейс был заявлен еще в 1.4, попытки скомпилировать его похоже никому не удались.
Важные изменения
- оператор =~ теперь означает равенство охватов, а не объектов
- GEOS 3.1 – минимальная допустимая версия GEOS
- GEOS 3.2 нужен для использования улучшенных буферных зон и функции ST_HausdorffDistance
- GEOS, LibXML2, и Proj4 теперь обязательные зависимости
Новые возможности
- Функция расчета расстояния Хаусдорфа. Этот способ заимствован из области распознавания образов и позволяет оценить насколько близки друг к другу объекты геометрически.
- Параметр для операции ST_Buffer позволяющий строить односторонние буферные зоны а также настраивать стили окончаний буферных зон (caps) и соединений (joins).
- Новые функции расчета и анализа расстояний ST_ClosestPoint, ST_DFullyWithin, ST_LongestLine, ST_MaxDistance, ST_ShortestLine.
- ?мпорт KML, GML через функции ST_GeomFromGML и ST_GeomFromKML
- Экстракция однородных коллекций с помощью ST_CollectionExtract
- Добавление значений измерений к линейным объектам с помощью ST_AddMeasure
- добавлены инструменты для ведения истории изменений в таблицах (George Silva)
- Поддержка Win32 и улучшение shp2pgsql-gui
- Возможность запуска ‘make check’ без запуска ‘make install”
- Поддерживающие функции для операций с данными в геодезических координатах:
- Операции на сфере
- ?ндексирование
- Выборки
- Сериализация (KML, GML, JSON)
- ST_Area, ST_Distance, ST_DWithin, ST_GeogFromText, ST_GeogFromWKB, ST_Intersects, ST_Covers, ST_Buffer и другие. Результаты, например измерения площади, для “geometry” возвращаются в единицах SRID. Для “geography” – в квадратных метрах.
- Обновление документации
- Поддержка транка PostgreSQL 8.5
Вот не совсем понимаю кому эти функции в СУБД нужны. Универсальные Г?С поддерживают несколько СУБД + локальные форматы, поэтому для унификации функционала реализуют все функции на клиенте, хотя бы для гетерогенных запросов к нескольким СУБД и чтобы результат вычислений не зависел от реализации в конкретной СУБД. ?ли реально много людей пишут свои специализированные Г?С с нуля на основе исключительно PostGIS?
Универсальные Г?С не всегда универсальны. Не думаю, что данные записанные в SQL Server при помощи ArcGIS можно прочитать из MapInfo (пример условный). А вот данные загруженные в PostGIS доступны из любой системы, поддерживающей его. Более того, для обработки этих данных наличие Г?С не обязательно, достаточно даже консольного клиента БД.
Когда я говорил про универсальные Г?С я имел ввиду не совместимость между собой, а единообразие работы в одной Г?С с несколькими разными СУБД и локальными файлами. А что касается MS SQL Server, гарантировать не могу, но по моему там также есть унифицированный формат хранения геометрии и работы с ним, как и в Oracle, MySQL, PostGIS, с недавних пор SQLite. Другое дело что в каждой Г?С есть уникальные возможности или ограничения не очень сочетающиеся с унифицированными форматами (надписи в mapinfo). ? наоборот, СУБД содержат информацию которая может ввести Г?С в замешательство. Например: по стандарту в одном слое могут быть как точки, полигоны, линии и вообще композитные объекты. Во многих же Г?С (ArcGIS QGIS) слои унифицированы по типам, либо точки либо линии. Как они себя ведут не проверял… Тоже касается всяких изысков, например в Oracle Spatial объекты в одной таблице могут иметь разные системы координат и разное представление(1d, 2d, 3d и кажись 4d), что сложно сочитается с идеологией большинства Г?С.
Есть клиентское ПО, есть серверное и то и другое может пересекающееся множество задач, что же тут непонятного? Разные задачи, аудитории и т.п., просить всех ставить кугис для просмотра карт нелогично, можно хранить данные в БД и рендерить для пользователей, тоже самое с инструментами анализа и т.п.