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

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

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

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

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

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

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

алло

Я бы сначала импортировал его в 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;

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

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

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

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

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

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

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

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

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