среда, 19 марта 2008 г.

sqlite в ГИС

Никого уже не удивить пространственными расширениями для баз данных - ими давно обзавелись многие коммерческие СУБД и открытые догоняют. Например, для постгреса это модуль PostGIS, о котором я уже не раз упоминал. Возможностей в нем и в самом деле много, а вот с остальным беда - например, производительность отрисовки данных с пространственным индексом из БД примерно в 10 раз ниже отрисовки из шейпов с пространственным индексом. Печально и заставляет задуматься. Кроме того, отнимает время администрирование БД. Перечисленные проблемы относятся к любой из подобных реализаций, поскольку клиент-серверная модель взаимодействия требует определенной платы за предоставляемые возможности (как и все в этом мире, в сущности).

В противовес "тяжелым" реализациям идут так называемые файл-ориентированные и в первую очередь, разумеется, это шейпфайлы. Хранение данных в локальных файлах имеет очевидные преимущества в простоте управления ими, обеспечивает высокое быстродействие, не требует администрирования. Однако шейпфайлы не вершина эволюции, поскольку требуют целый набор файлов (минимум три файла) для хранения данных (пространственная информация, индекс объектов и атрибутивная информация, а также может создаваться файл с пространственным индексом и другие файлы). Вдобавок атрибуты хранятся в устаревшем формате dbase. Об xml-форматах промолчим, поскольку xml это лишь формат обмена информацией (о чем часто забывают и работают с ним напрямую, что приводит к множеству проблем). Отличной реализацией будет хранение данных в базе данных, представляющей из себя единственный файл. И такая база есть - SQLite. Заметим, что в настоящий момент имеются некоторые серьезные ограничения - sqlite не поддерживает R-tree индекс, что делает невозможным построение пространственного индекса (с версии 3.6.0 поддерживает). Тем не менее, в определенных случаях использовать sqlite для хранения пространственных данных вполне можно. Например, если поиск по координатам объекта не требуется и нужен поиск только по атрибутивной информации, или если необходимо хранить только точечные объекты, или просто объем данных небольшой.

Как индексировать точечные объекты, можно прочитать вот здесь
Re: [sqlite] Spatial searches.

Хранить координаты удобно в формате WKT (Well-known text).

Также существуют утилиты для обработки данных, сохраненных в sqlite в формате WKT
SQLite RDBMS

OGR SQL.

А от небольшой пример сохранения данных из шейпфайлов в sqlite:

ogr2ogr -s_srs "EPSG:32638" -t_srs "EPSG:32638" -f SQLite out.db nn_tsp.shp

ogr2ogr -s_srs "EPSG:32638" -t_srs "EPSG:4326" -f SQLite out.db nn_tsp.shp


Если мы проекцию менять не хотим, то ее можно не указывать. Преобразование из sqlite в шейпфайлы делается аналогично.

В качестве заключения: поддержка индекса R-tree для sqlite планируется, после реализации этой возможности можно будет полноценно использовать sqlite для хранения пространственных данных. Неоднократно упомянутый postgis является не более чем оберткой для внешних библиотек обработки пространственных данных, сделать аналогичную обертку для sqlite задача не слишком сложная. Далее, сейчас в браузеры встраивается поддержка sqlite, что позволяет работать с данными непосредственно на клиенте, используя javascript (в 3-й версии браузера мозилла встроенная поддержка, для других браузеров существуют плугины). Jabascript библиотеки для поддержки WKT также уже готовы, например, библиотека OpanLayers умеет отображать WKT-данные на карте. Для повышения быстродействия можно хранить данные в двоичном формате WKB на сервере и преобразовывать в WKT для удобства использования клиентами.

понедельник, 17 марта 2008 г.

Картографические приложения с помощью библиотеки OpenLayers

Гора не сходится с горой,
Но жизнь свершает круг,
И старый недруг нам порой
Милей, чем новый друг.
Вадим Шефнер
"Лачуга должника"


Некоторое время тому назад мы уже знакомились с технологией создания картсервера с помощью одноименного приложения mapserver. И все было хорошо - великолепная отрисовка множества векторных и растровых слоев, работа с разнообразными проекциями и источниками данных. Пользовательских интерфейсов для mapserver тоже хватает - и на яваскрипт, и флэшовые, и на ява-аплетах, не говоря уже про простой хтмл. Сложность только одна - где бы взять необходимые нам векторные данные, широко доступное изобилие которых наблюдается на территории западных стран? Вот эта мелочь и является камнем преткновения. Ну еще чисто технические сложности - нужны подготовленные к публикации данные, файл проекта с описанием свойств карты и всех слоев (map-файл), что в общем тоже требует много времени. Сегодня мы поговорим о решениях для бизнеса - есть у нас задача по визуализации сети торговых точек, или трэков со спутниковых навигаторов или... Рассмотрим прикладной аспект - есть данные с географической привязкой, которые надо отобразить на карте и как можно меньше заморачиваясь на саму карту и все с ней связанное. Бизнес сегодня успешно глобализуется, так что карты города уже мало, нужно работать как минимум с картой региона, а то и страны или картой всей планеты. да и деловая жизнь все ускоряется - пользователю необходим простой и вместе с тем функциональный и надежный инструмент. И такой инструмент уже есть, нужно лишь научиться с ним обращаться.

Начнем с постановки задачи: требуется полнофункциональный кроссплатформенный и веб-ориентированный интерфейс (ajax), работа с картой должна быть быстрой и не заставлять ждать загрузки очередной карты и не нагружать сервер даже при одновременной работе многих пользователей (растровая мозаика), а также возможность отображать и изменять произвольные векторные данные (асинхронная подгрузка данных в форматах kml,georss,wkt). Все это доступно при использовании клиентской библиотеки OpenLayers, которая на самом деле умеет намного больше. Но сегодня мы не будет интересоваться интеграцией своих карт с картами гугл и работой с mapserver (да, можно и его карты использовать, да еще и разными способами - как запрашивая через cgi-интерфейс нужные картинки и метаинформацию, так и взаимодействуя со встроенными WMS/WFS серверами), а ограничимся самым простым и эффективным решением нашей задачи.

Вот пример, иллюстрирующий использование растровой подложки для интерактивного отображения так называемых "точек интересов" (POI). Элементы мозаики, на которые разделен растр, являются обычными статичными изображениями, и их может эффективно публиковать практически любой веб-сервер (aolserver, nginx, lighttpd, thttpd, etc.) и кэшировать прокси-сервер и сам браузер пользователя. Таким образом, достаточно любого хостинга и нет требований к ресурсам сервера (разве что к объему жесткого диска, но в наше время терабайтных винчестеров карта размером в сотни мегабайт кажется сущей безделицей). Отображение точек интересов происходит интерактивно - при переходе к просмотру очередной части карты отправляется асинхронный запрос к серверу на получение файла со списком нужных объектов для отображаемых квадрантов карты. Этот файл может быть как статическим, так и динамическим - в любом случае его размер обычно невелик по сравнению с размером растровой подложки карты. Работая с сервером в локальной сети или через прокси можно комфортно перемещаться по карте и масштабировать ее, не тратя время на ожидание загрузки данных.

Для любознательных - протестировав отрисовку разных наборов данных (точки, линии, полигоны) я убедился в том, что в течении секунды успевают отрисоваться объекты из многих тысяч точек, так что отображение векторной информации в браузере пользователя не мешает работе. Притом используемый мною браузер Iceweasel (Mozilla Firefox) 2.0.0.11 далеко не самый быстрый на сегодня.

Множество примеров доступно на официальном сайте проекта OpenLayers, там же можно скачать как саму библиотеку, так и примеры.

Замечу еще, что работа с проецированными растрами поддерживается, хотя немного странно, проще всего работать в системе координат EPSG:41001. Для построения пирамиды из растра (файл привязки не обязателен) можно воспользоваться утилитой GDAL2Tiles Project.

Код на яваскрипт для клиентской части занимает одну-две страницы, так что подробно на этом останавливаться смысла не вижу, тем более, что примеров много и они работают :-)

Визуализация данных при помощи PyNGL

Попалась на глаза статья, посвященная визуализации научных данных с помощью питоновских библиотек. Не то чтобы я сторонник питона, но отход от использования явы в ГИС-приложениях и смежных областях очень радует, ибо мое отношение к яве "ни за что и никогда". К питону претензия только одна - язык объектный, что чревато всякими нехорошими эффектами (наподобии проблемы с параллельным выполнением кода, отсутствия средств для генерации кода и его последующего выполнения и проч.). Зато вызывает уважение, что питон сумел потеснить перл и яву, на фоне этих артефактов объектная модель питона смотрится привлекательно. Как раз вот сегодня пользовался утилитами из комплекта FWTools, а если быть точным, то питоновской оберткой к gdal, в очередной раз ругался на странную с моей точки зрения идеологию разбора параметров командной строки :-)

А вот и сама статья статья

вторник, 4 марта 2008 г.

Руководство по GRASS 6.0

В сети появился русский перевод руководства по GRASS 6.0.

Учебное руководство по ГИС GRASS 6.0

Вот еще статья там же появилась:
Использование Doxygen для работы с исходным программным кодом ПО ГИС

Честно сказать, имею большие сомнения в эффективности предлагаемого подхода, но тем не менее и он имеет право на жизнь. Особенно для тех, кто и математику не знает и софт писать не умеет, не говоря уже про чтение исходников. Т.е. для решения разовой задачи вроде ничего, а для серьезного проекта лучше действовать более системно, имхо.

(C) Alexey Pechnikov aka MBG, mobigroup.ru