Централизация данных шейп-файла в базе данных


13

У меня есть сотни шейп-файлов из различных ГИС-проектов, которые я хочу начать консолидировать в единую платформу базы данных, в настоящее время пытаюсь сделать это с помощью Postgres / PostGIS.

Вряд ли какие-либо данные стандартизированы - это означает, что это много одинаковых типов данных , но конкретные имена / типы атрибутов не совпадают.

С чего мне начать заниматься этим? Должен ли я разработать стандартную модель для переноса каждого шейп-файла в первый (например, стандарты Hydro_line, transport_line, Hydro_poly и т. Д.)?

Альтернатива - просто импортировать каждый шейп-файл в Postgres по отдельности, чтобы каждый shp становился таблицей в базе данных, но я не уверен в этом с точки зрения производительности и организации. Похоже на задержку неизбежного ...

Любой совет по решению этой сложной задачи?

Ответы:


7

Взгляните на программы Spatial ETL (Extract - Transform - Load), они предназначены для таких задач. Наиболее известным является FME от Safe, но теперь доступны некоторые альтернативы с открытым исходным кодом (частичные), такие как SDI (Spatial Data Integrator) и GeoKettle .


2
Я попросил сравнить в предыдущем вопросе, поэтому, если вы идете по этому пути, пожалуйста, сделайте рецензию. gis.stackexchange.com/questions/5049/spatial-etl-comparisons
RyanKDalton

Я взял пробную версию FME и установил SDI и GeoKettle. Я попробую их и посмотрю, смогу ли я понять их. FME выглядит как решение для супа с орехами, но сначала мне придется преодолеть кривую обучения :).
Colemanm

1
@ colemanm- Что ты в итоге сделал с этим? Какой продукт вы нашли наиболее полезным?
RyanKDalton

6

алло

Я бы сначала импортировал его в PostGIS. Есть инструменты для загрузки нескольких фигур в отдельные таблицы. Расширение косы QGIS - одно. Новый графический shp2pgsql в магистрали PostGIS или экспериментальных двоичных файлах является другой альтернативой. Или вы можете просто написать пакетный скрипт с shp2pgsql.

Я бы начал там, импортировать все в схему, называемую оригинальной или что-то в этом роде. Тогда из этого я бы структурировал данные. Слияние воедино в таблицах, где подходит и так далее.

Хорошая вещь в этом состоит в том, что если вы сохраняете все запросы, которые используете для этих преобразований, у вас есть отличная документация об истории ваших данных. Это также очень легко переделать, если это необходимо. Когда вы будете готовы к работе по организации, вы создадите резервную копию вашей «оригинальной» схемы и где-нибудь ее отложите.

Я думаю, что это структурированный и чистый способ сделать это. И, как уже было сказано, вы получите очень точную документацию о том, какое поле изменило имя на какое новое, какие исходные таблицы объединены в эту большую новую и так далее.

В FME и подобном программном обеспечении вы, конечно, можете также сохранить то, что вы сделали, но, несмотря на то, что он очень медленный по сравнению с внутренними запросами к базе данных, это не тот универсальный способ документирования, который выполняется в виде sql-запросов. Их можно будет использовать и читать, пока есть текстовые файлы и реляционные базы данных.

Я использую, чтобы в итоге текстовые файлы выглядели примерно так:

-- A query to merge all roads in Norway

Create table road_tables.all_roads as
SELECT id as roadid, status, the_geom from original.big_roads
union all
SELECT rid as roadid, condition as status, the_geom from original.small_roads;

и так далее. Это сохранено как текстовый файл имеет большое значение через несколько лет.

С уважением Никлас


1
+1 Я думаю, что это очень хороший подход. Все сделано в Postgres, очень прозрачно и легко воспроизводимо при необходимости.
Подземье

1
не очень хорошая рекомендация для ГИС на основе ESRI. С открытым исходным кодом "только" это было бы приемлемо. ESRI имеет много других зависимостей, которые не будут доступны через этот метод. прямое подключение к postgis недопустимо без взаимодействия, gis-сервера или arcsde.
Брэд Несом

2
@Brad Хм, мне интересно, является ли это аргументом против того, чтобы делать вещи прозрачным и воспроизводимым и быстрым способом, или аргументом против того, чтобы быть запертым, помещая sde между мной и моими данными ... ;-)
Nicklas Avén

1
@Brad: Colemanm не упомянул ESRI, поэтому ответ кажется хорошим.
Подземье

Я проделал аналогичную работу с классами объектов ESRI Sde и SQL Server 2008 (с собственной геометрией) - сначала я создал класс объектов, а затем загрузил серию операторов вставки. IIRC, мне пришлось экспортировать класс объектов в конце в новый класс объектов, потому что я не мог правильно сгенерировать новые объекты. как только я это сделал, дела как обычно.
Джей Камминс

4

Мое предложение было бы выбрать 2-5 из ваших более тяжелых используемых слоев данных (шейп-файлы) и перенести их в rdbms.
Изучите и внедрите рабочие процессы для этих данных. Привыкание к ограничениям и требованиям данных на основе файлов rdbms.

Ограничения: обязательный экспорт, зона посадки, координаты, тип файла для совместной работы.

Есть много преимуществ для того, что вы предлагаете.
Примечание: (мой дедушка сказал моим родителям потратить 6 месяцев на поиски дома перед покупкой) подумайте, что вы ищете дом (на длительный срок) для своих данных, вы не хотите платить за что-то через 30 лет после того, как вы не нравится

Я бы порекомендовал записать (цифровой или аналоговый) древовидный список ваших источников данных и просмотреть их в целом, это позволит вам упорядочить данные в более сжатые группы.

В Arcgis есть методы (мое предположение: вы не указали предпочитаемую вами систему) для интеграции разнородных данных.

Вы можете попробовать некоторые из этой информации, если вы заинтересованы в изучении передовых методов проектирования ...

Обзор проекта базы
геоданных Документация по базе геоданных
Есть несколько похожих ссылок и для arc 10.
Ресурсный центр
базы геоданных arc10

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.