Централізація даних формфайлу в базу даних


13

У мене є сотні форм-файлів з різних різних проектів ГІС, які я хочу почати консолідувати в єдину платформу баз даних, в даний час намагаюся зробити це за допомогою Postgres / PostGIS.

Навряд чи будь-яка з даних є стандартизованою - це означає, що це багато одних і тих же типів даних , але окремі імена / типи атрибутів не відповідають.

З чого я повинен почати вирішувати це? Чи варто розробити стандартну модель для міграції кожного файлу форм у першу (наприклад, Hydro_line, transport_line, Hydro_poly стандарти тощо)?

Альтернативою є просто імпортувати кожен файл файлів у Postgres окремо, тому кожен shp стає таблицею в базі даних, але я не впевнений у цьому щодо продуктивності та організації. Відчуває себе як би затягуючи неминуче ...

Будь-яка порада щодо вирішення цього грізного завдання?

Відповіді:


7

Погляньте на програмне забезпечення просторової 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, тому відповідь здається гарною.
underdark

Я робив аналогічну роботу з цим у класах функцій ESRI Sde та SQL Server 2008 (з / рідною геометрією) - спершу я створив клас класів, а потім завантажую серію операторів вставки. IIRC, мені довелося експортувати функціональний клас наприкінці до нового классу, тому що я не міг генерувати нові об’єкти правильно. як тільки я це зробив, як завжди.
Jay Cummins

4

Моя пропозиція полягає в тому, щоб вибрати 2-5 ваших більш важких використовуваних шарів даних (shapefiles) і перемістити їх до rdbms.
Досліджуйте та застосовуйте робочі коси для цих даних. Звикання до ліймітацій та вимог даних на основі файлів rdbms vs.

Обмеження включають: необхідний експорт, зону посадки, coordsys, тип файлу для співпраці.

Є багато корисних для того, що ви пропонуєте.
Сторона ПРИМІТКА: (Мій дідусь сказав моїм батькам витратити 6 мільйонів на пошук будинку, перш ніж купувати) вважайте, що ви шукаєте будинок (довгостроковий) за ваші дані, ви не хочете платити за щось 30 років з того моменту, як ви не подобається.

Моєю рекомендацією було б записати (цифровий або аналоговий) деревцевий список ваших джерел даних і переглянути їх у великій картині, це повинно дозволяти вам організувати дані в більш стислі групи.

У аркгізі є методи (моє припущення: ви не вказали бажану систему), щоб інтегрувати різні дані.

Ви можете спробувати трохи цієї інформації, якщо вам цікаво вивчити хороші практики дизайну ...

Огляд дизайну баз даних
геоданих
Існує також кілька подібних посилань на дугу 10.
Ресурсний центр
geodatabase arc10

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.