LINUX.ORG.RU

Вышел PostGIS 2.0.0

 , , ,


0

2

После 26 месяцев напряжённой работы вышла новая мажорная версия расширения СУБД PostgreSQL для работы с географическими объектами — PostGIS 2.0.0. PostGIS предоставляет набор типов и функций, которые позволяют использовать СУБД PostgreSQL в качестве бекенда для геоинформационных систем. Разработка PostGIS ведётся в соответствии со стандартами и спецификациями OpenGIS.

Список нововведений:

  • Поддержка растровых данных, растрового и векторного анализа.
  • Топологические модели с поддержкой общих границ.
  • Интеграция с typmod для автоматического создания таблицы geometry_columns.
  • 3D и 4D индексация.
  • Основанный на индексации быстрый поиск соседей.
  • Новые функции: ST_Split, ST_Node, ST_MakeValid, ST_OffsetCurve, ST_ConcaveHull, ST_AsX3D, ST_GeomFromGeoJSON, ST_3DDistance.
  • Улучшения в дампере и загрузчике шейп-файлов.
  • Поддержка мульти-файлового импорта и экспорта в GUI.
  • Геокодер оптимизирован для бесплатных данных US Census TIGER (2010).

>>> Подробности

★★★★★

Проверено: tazhate ()
Последнее исправление: Dendy (всего исправлений: 2)

Отлично, но тебе не кажется, что «мажорная версия может вызвать ненужные ассоциации, c Ю. Шевчуком, например.

ABW ★★★★★
()

3D и 4D индексация

Что такое 4D индексация? Назад во времени или в будущее? Или 4D - это индексация с запахом? O_o

medvetux
()

Кто уже успел опробовать хранение растровых данных? Как оно по скорости досутпа, компактности по сравнению с файлом?

drofan
()
Ответ на: комментарий от drofan

компактность

Тоже очень интересно, как с накладными расходами на хранение данных. Например, «традиционные» СУБД PostgreSQL, MySQL, BerkleyDB и т.д. на каждую строку отъедают на заголовок примерно по 30 и больше байтов. Вроде бы копейки, но если нужно хранить дофигища мелких сущностей типа ключ-значение, выходит, что около половины места на винтах теряется!

Пробовал HDF5, позиционируется как супер-пупер библа для хранения огромных объемов данных: сжатие, CRC32, йерархическая организация данных (*nix path), не зависит от количества оперативы и еще много фич . Копнул глубже - нет элементарной транзакционности и тулз для восстановления тоже. Скачок напряжения/ глюк ОС - конец твоим терабайтам!

Никто не знает, как можно компактно и НАДЕЖНО хранить терабайты числовых пар ключ-значение ?

anonymous
()
Ответ на: компактность от anonymous

raid + журналируемая файловая система. Круче некуда.

или raid + oracle без fs - тама всё строено говорят.

alx_me ★★☆
()
Ответ на: комментарий от Dobriy_i_Prostoy

Уж точно не в реляционной БД.

В NoSQL кластере (облаке).

baka-kun ★★★★★
()

вышел и сломал Django :))

anonymous
()
Ответ на: компактность от anonymous

Например, «традиционные» СУБД PostgreSQL, MySQL, BerkleyDB и т.д. на каждую строку отъедают на заголовок примерно по 30 и больше байтов.

Откуда ты такую херню берёшь? В реляционных СУБД да, примерно так и есть. В BerkeleyDB такого нет, там есть похожий оверхед на индекс к ключам. Соответственно, если не нужен произвольный доступ по ключам - тупо пиши всё в файл последовательно на журналируемую ФС и юзай датасинк. Ну а если таки нужны выборки по ключам - BerkeleyDB и, возможно, gdbm что нужно.

mashina ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.