По приходу в одну контору, которая занимается разработкой карт, схем и планов, меня очень удивила одна вещь: не было централизованного хранилища всех материалов. Пользователи работали каждый со своими наработками. И если возникала потребность что-то взять из другого проекта – приходилось или бежать с «флэшечкой», или копировать файлы по сети. Что создавало неимоверное количество «мусора» в виде дубликатов разной свежести на множестве рабочих станций.После наблюдения всего этого хаоса, я решил все это дело «причесать» и сделать централизованным хранение картографического материала, с разграничением прав доступа к отдельным проектам, да еще и с мониторингом изменений, внесенных в проекты.
Выбор пал на СУБД PostgeSQL с расширением PostGIS, позволяющее хранить в базе географические данные (геометрию объектов). Одним из определяющих факторов выбора – возможность программных продуктов, с которыми работают пользователи, работать с БД без дополнительных «костылей». Плюсом можно отметить открытость проекта и возможность многопользовательской работы с одним и тем же слоем.
О самой СУБД рассказывать не буду – и так уже много понаписано, как хорошего, так и плохого. Как и не буду говорить о ее настройке.
Остановлюсь моментом на самом расширении PostGIS.
PostGIS был выпущен в 2001 году компанией Refractions Research и составляет конкуренцию коммерческим решениям, являясь при этом свободным программным продуктом с открытым исходным кодом. Основным достоинством PostGIS является возможность использования языка SQL совместно с пространственными операторами и функциями. Кроме простого хранения данных, PostGIS позволяет осуществлять любые виды операций над ними.
Собственно, далее займемся самой организацией хранения пространственных данных в БД. Для удобства визуализации структуры взят pgAdmin3.
Специфика работы с цифровыми картами такова, что для получения полноценной карты требуется несколько слоев, содержащих различные объекты. Например, для города нужны минимум два слоя: здания и дороги. Допустим, что городов у нас несколько, и каждый содержит независимые друг от друга данные. Для каждого из городов создаем отдельную схему в БД:
CREATE DATABASE goroda OWNER postgres;
CREATE SCHEMA gorod1 OWNER postgres;
CREATE SCHEMA gorod2 OWNER postgres;
Далее заносим в созданные схемы уже имеющиеся данные по ним, используя для этого один из свободных загрузчиков: shp2pgsql, OGR2OGR, QuantumGIS SPIT, загрузчик shp для PostGIS и другие.
Назначаем хозяина таблиц:
ALTER TABLE road1 OWNER TO postgres;
ALTER TABLE building1 OWNER TO postgres;
В итоге получаем следующий вид:
Кроме таблиц road1 и building1 в схеме public образовались еще две: geometry_columns и spatial_ref_sys. Таблица geometry_columns хранит информацию о таблицах базы данных, содержащих пространственную информацию. Таблица spatial_ref_sys содержит числовые идентификаторы и текстовые описания систем координат, используемых в пространственной базе данных.
С хозяином таблицы разобрались, теперь дело за пользователями. Для начала создадим их:
CREATE USER user1 WITH PASSWORD 'psswd1';
CREATE USER user2 WITH PASSWORD 'psswd2';
Выставляем им права на пользование данными таблицами:
GRANT SELECT ON TABLE road1 TO user1;
GRANT SELECT ON TABLE building1 TO user1;
В данном виде права представляются только на чтение.
Для редактирования можно выставить следующие права:
UPDATE – возможность изменять уже существующие объекты;
INSERT – добавление новых объектов;
DELETE – удаление объектов.
Собственно, все как в стандартном SQL.
Соответственно, комбинируя данные привилегии, можно задать пользователю право только на создание или изменение уже существующих объектов, или возможность для полного редактирования.
Далее выставляем права на таблицы с пространственной информацией:
GRANT SELECT ON geometry_columns TO user1;
GRANT SELECT ON spatial_ref_sys TO user1;
Если задать только SELECT, то пользователь только будет просматривать слои. Если ALL — то может создавать свои таблицы (например, слой с автобусными остановками). Дадим второму пользователю такую привилегию:
GRANT ALL ON geometry_columns TO user2;
GRANT ALL ON spatial_ref_sys TO user2;
Для того чтобы пользователь мог создавать записи в таблице (редактировать карту), разрешаем ему использование последовательности таблицы:
GRANT USAGE ON SEQUENCE road1_gid_seq TO user1;
GRANT USAGE ON SEQUENCE building1_gid_seq TO user1;
То же самое можно сделать и для второго пользователя.
Так как в БД используется больше, чем одна схема, то при назначении прав таблице указываем до нее полный путь: schema.table.
Теперь у нас есть БД с пространственными данными и с пользователями, которые имеют разный доступ к ним: от полного, до «только посмотреть». Что, собственно, нам и было нужно.
В следующей статье рассмотрим аудит таблиц с пространственными объектами.
