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:
Если мы проекцию менять не хотим, то ее можно не указывать. Преобразование из sqlite в шейпфайлы делается аналогично.
В качестве заключения: поддержка индекса R-tree для sqlite планируется, после реализации этой возможности можно будет полноценно использовать sqlite для хранения пространственных данных. Неоднократно упомянутый postgis является не более чем оберткой для внешних библиотек обработки пространственных данных, сделать аналогичную обертку для sqlite задача не слишком сложная. Далее, сейчас в браузеры встраивается поддержка sqlite, что позволяет работать с данными непосредственно на клиенте, используя javascript (в 3-й версии браузера мозилла встроенная поддержка, для других браузеров существуют плугины). Jabascript библиотеки для поддержки WKT также уже готовы, например, библиотека OpanLayers умеет отображать WKT-данные на карте. Для повышения быстродействия можно хранить данные в двоичном формате WKB на сервере и преобразовывать в WKT для удобства использования клиентами.
В противовес "тяжелым" реализациям идут так называемые файл-ориентированные и в первую очередь, разумеется, это шейпфайлы. Хранение данных в локальных файлах имеет очевидные преимущества в простоте управления ими, обеспечивает высокое быстродействие, не требует администрирования. Однако шейпфайлы не вершина эволюции, поскольку требуют целый набор файлов (минимум три файла) для хранения данных (пространственная информация, индекс объектов и атрибутивная информация, а также может создаваться файл с пространственным индексом и другие файлы). Вдобавок атрибуты хранятся в устаревшем формате 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 для удобства использования клиентами.
Comments
Митрич
mitrichtools на mail тчк ru