Tập trung dữ liệu shapefile vào cơ sở dữ liệu


13

Tôi đã nhận được hàng trăm shapefile từ các dự án GIS khác nhau mà tôi muốn bắt đầu hợp nhất thành một nền tảng cơ sở dữ liệu duy nhất, hiện đang thử điều này với Postgres / PostGIS.

Hầu như không có dữ liệu nào được chuẩn hóa - có nghĩa là rất nhiều loại dữ liệu giống nhau , nhưng tên / loại thuộc tính cụ thể không khớp.

Tôi nên bắt đầu giải quyết vấn đề này ở đâu? Tôi có nên phát triển một mô hình chuẩn để di chuyển từng shapefile thành đầu tiên (ví dụ: các tiêu chuẩn Hydro_line, Transport_line, Hydro_poly, v.v.) không?

Một cách khác là chỉ nhập từng shapefile vào Postgres riêng lẻ, vì vậy mỗi shp trở thành một bảng trong cơ sở dữ liệu, nhưng tôi không chắc về điều này về hiệu suất và tổ chức. Cảm thấy giống như trì hoãn không thể tránh khỏi ...

Bất kỳ lời khuyên về việc đối phó với nhiệm vụ khó khăn này?

Câu trả lời:


7

Hãy xem phần mềm Spatial ETL (Extract - Transform - Load), chúng được dành riêng cho các tác vụ như vậy. Được biết đến nhiều nhất là FME từ Safe, nhưng một số lựa chọn thay thế nguồn mở (một phần) hiện có sẵn, như SDI (Bộ tích hợp dữ liệu không gian) và GeoK Ấm .


2
Tôi đã yêu cầu so sánh trong một câu hỏi trước đó, vì vậy nếu bạn đi theo con đường này, xin vui lòng viết thư. gis.stackexchange.com/questions/5049/spatial-etl-comparisons
RyanKDalton

Tôi đã lấy phiên bản dùng thử của FME và cài đặt cả SDI và GeoK Ấm. Tôi sẽ thử chúng và xem liệu tôi có thể hiểu ý nghĩa của chúng không. FME trông giống như một giải pháp súp-to-nut, nhưng trước tiên tôi sẽ phải vượt qua giai đoạn học tập :).
colemanm

1
@ colemanm- Rốt cuộc bạn đã làm gì trên này? Sản phẩm nào bạn thấy hữu ích nhất?
RyanKDalton

6

Ê

Tôi sẽ nhập nó vào PostGIS trước. Có các công cụ để tải nhiều hình dạng vào các bảng riêng lẻ. Mở rộng nhổ của QGIS là một. Đồ họa mới shp2pgsql trong thân cây PostGIS hoặc nhị phân thử nghiệm là một lựa chọn khác. Hoặc bạn chỉ có thể viết một tập lệnh bó với shp2pgsql.

Tôi sẽ bắt đầu ở đó, nhập mọi thứ vào một lược đồ gọi là bản gốc hoặc một cái gì đó tương tự. Sau đó, từ đó tôi sẽ cấu trúc dữ liệu. Sáp nhập với nhau trong các bảng phù hợp và như vậy.

Điều tuyệt vời khi làm điều đó là nếu bạn lưu tất cả các truy vấn bạn sử dụng để thực hiện các chuyển đổi đó, bạn có một tài liệu tuyệt vời về lịch sử dữ liệu của mình. Nó cũng rất dễ dàng để làm lại nếu cần. Khi bạn đã sẵn sàng với công việc tổ chức của mình, bạn đổ một bản sao lưu của lược đồ "gốc" của bạn và cất đi đâu đó.

Tôi nghĩ rằng đây là một cách có cấu trúc và sạch sẽ để làm điều đó. Và như đã nói trước đây, bạn sẽ nhận được một tài liệu rất chắc chắn về trường đã đổi tên thành tên mới nào và các bảng gốc nào được hợp nhất vào tên mới lớn đó, v.v.

Trong FME và phần mềm như vậy, tất nhiên bạn cũng có thể lưu những gì bạn đã làm, nhưng bên cạnh việc rất chậm so với các truy vấn cơ sở dữ liệu nội bộ thì đó không phải là cách phổ biến của tài liệu được thực hiện dưới dạng truy vấn sql. Chúng sẽ có thể sử dụng và đọc được miễn là có tệp văn bản và cơ sở dữ liệu quan hệ.

Tôi sử dụng để kết thúc với các tệp văn bản trông giống như:

-- 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;

và như thế. Điều này được lưu dưới dạng tệp văn bản có giá trị lớn sau một vài năm.

Trân trọng Nicklas


1
+1 Tôi nghĩ rằng đây là một cách tiếp cận rất tốt. Mọi thứ đều được thực hiện trong Postgres, rất minh bạch và dễ dàng tái tạo nếu cần.
underdark

1
không phải là một khuyến nghị tốt cho GIS dựa trên ESRI. Nguồn mở "chỉ" điều này sẽ được chấp nhận. ESRI có nhiều phụ thuộc hơn mà không thể truy cập được thông qua phương thức này. kết nối trực tiếp với postgis không được phép nếu không có máy chủ interop, gis hoặc arcsde.
Brad Nesom

2
@Brad Hmm, tôi tự hỏi liệu đó có phải là một cuộc tranh cãi khi thực hiện mọi thứ một cách nhanh chóng và có thể lặp lại hoặc một cuộc tranh cãi để bị khóa bằng cách đặt sde vào giữa tôi và dữ liệu của tôi ... ;-)
Nicklas Avén

1
@Brad: colemanm không đề cập đến ESRI, vì vậy câu trả lời có vẻ tốt.
underdark

Tôi đã thực hiện công việc tương tự với ESRI Sde featureclass và SQL Server 2008 (w / hình học tự nhiên) - Trước tiên tôi đã tạo ra featureclass, sau đó tải với một loạt các câu lệnh chèn. IIRC, tôi đã phải xuất khẩu featureclass ở cuối sang một featureclass mới vì tôi không thể tạo ra các vật thể mới một cách chính xác. một khi tôi đã làm điều đó, kinh doanh như bình thường.
Jay Cummins

4

Đề xuất của tôi sẽ là chọn 2-5 lớp dữ liệu được sử dụng nặng hơn (shapefiles) và di chuyển chúng sang rdbms.
Điều tra và thực hiện các công việc cho các dữ liệu đó. Làm quen với các lời nói dối và yêu cầu của rdbms so với dữ liệu dựa trên tệp.

Hạn chế bao gồm: xuất khẩu bắt buộc, vùng hạ cánh, coordsys, loại tệp để cộng tác.

Có rất nhiều lợi ích cho những gì bạn đang đề xuất.
LƯU Ý: (Ông tôi bảo bố mẹ tôi dành 6 triệu đồng để tìm nhà trước khi mua) xem xét bạn đang tìm nhà (dài hạn) cho dữ liệu của bạn, bạn không muốn trả tiền cho 30 năm kể từ bây giờ không thích

Đề nghị của tôi sẽ là viết ra (kỹ thuật số hoặc tương tự) một danh sách cây các nguồn dữ liệu của bạn và xem chúng trong một bức tranh lớn, điều này sẽ cho phép bạn sắp xếp dữ liệu theo các nhóm ngắn gọn hơn.

Có các phương pháp trong arcgis (giả định của tôi: bạn chưa chỉ định hệ thống ưa thích của mình) để tích hợp dữ liệu khác nhau.

Bạn có thể thử một số thông tin này nếu bạn muốn tìm hiểu các thực hành thiết kế tốt ...

Tổng quan về thiết kế
cơ sở dữ liệu địa lý Tài liệu cơ sở dữ liệu địa lý
Có một số liinks tương tự cho cung 10 cũng có.
Trung tâm tài nguyên
cơ sở dữ liệu arc10

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.