Làm cách nào để sử dụng PostGIS để xử lý các quy trình công việc địa lý phức tạp?

12

Tổ chức của chúng tôi đang xem xét chuyển quy trình xử lý địa lý của chúng tôi sang PostGIS. Chúng tôi hiện đang sử dụng ArcGIS, với rất nhiều công cụ Python tùy chỉnh được sử dụng trong ModelBuilder. Chúng tôi đang chuyển phần lớn dữ liệu của mình vào PostGIS để được sử dụng bởi nhiều ứng dụng khác nhau và bây giờ chúng tôi đang hỏi liệu điều đó có hợp lý để thực hiện xử lý dữ liệu ở đó không.

Chúng tôi xử lý dữ liệu để tương thích với phần mềm của chúng tôi. Một khách hàng mua phần mềm của chúng tôi, cung cấp cho chúng tôi dữ liệu của họ và chúng tôi xử lý phần mềm này để được tối ưu hóa để sử dụng trong phần mềm của chúng tôi. Điều này đòi hỏi chúng tôi xây dựng nhiều công cụ khác nhau để xử lý các chất lượng khác nhau của dữ liệu đầu vào. Chúng tôi không thể mong đợi nhận dữ liệu theo một định dạng hoặc lược đồ cụ thể, vì vậy chúng tôi xây dựng các công cụ để ánh xạ các trường đầu vào thành các trường đầu ra, phân tích các trường đơn lẻ thành nhiều trường, hợp nhất nhiều bộ dữ liệu, v.v. và các trường liên kết, và nhiều hoạt động phổ biến khác. PostGIS dường như hoàn toàn có khả năng thực hiện tất cả các nhu cầu xử lý của chúng tôi.

Đối với những người sử dụng PostGIS để xử lý dữ liệu của bạn, bạn có lời khuyên nào cho tổ chức, công cụ sử dụng, v.v. không?

Bạn có sử dụng nó cùng với xử lý python không?
Có phải mọi người đang sử dụng ORM Python để xử lý không phải web? Tôi đã nghiêng về việc sử dụng GeoDjango vì nó có ORM Python cho PostGIS. Thử nghiệm ban đầu của chúng tôi về việc sử dụng PostGIS để xử lý dữ liệu có nhiều khối văn bản SQL lớn trong mã Python và chúng tôi nghĩ rằng GeoDjango ORM có thể giúp tạo mã dễ quản lý và dễ đọc hơn. Ngoài ra còn có ORM GeoAlchemy tương tác tương tự với PostGIS và dường như không đặc trưng cho web như Django.

Tôi chưa nghe nói về những người sử dụng PostGIS để xử lý địa lý nhiều như tôi thấy mọi người sử dụng QGIS hoặc ArcGIS, vì vậy tôi muốn biết liệu đây có phải là một giải pháp thay thế tương đương không.

— Thợ thuộc da
nguồn

1

Là tất cả quá trình của bạn "phụ trợ"? Tôi không phải là người dùng Django hoặc GeoDjango, nhưng tôi nghĩ về những sản phẩm đó chỉ để phát triển trang web (và rắc rối hơn giá trị của chúng, IMHO). Tại sao không chỉ là một loạt các kịch bản shell hoặc python chạy tại dòng lệnh (dĩ nhiên là Unix) hoặc định kỳ thông qua "cron"? (Ít clickey-clickey luôn tốt hơn trong tâm trí của tôi.) Bạn có thể muốn tổ chức những hệ thống này, ít nhất là bằng luồng dữ liệu đến. Ngoài ra, Postgis có thể cắt và xé dữ liệu của bạn mà không cần QGIS - bạn có ý định loại hoạt động cụ thể nào?

— chờ đợi

1

Vâng, xử lý của chúng tôi là phụ trợ. Tuy nhiên, cuối cùng chúng tôi sẽ có một bản đồ web OpenLayers để khách hàng xem và chỉnh sửa dữ liệu của họ. Chúng tôi có thể sử dụng Django cho tài khoản người dùng và quản trị viên của ứng dụng. Nếu vậy, tôi nghĩ đó có thể là một lý do khác để xem xét GeoDjango để xử lý, mặc dù Django được xây dựng chủ yếu cho các trang web. Xử lý quy mô lớn với bản trình bày Django cho thấy Django không chỉ dành cho các trang web: sl

— Tanner

1

Đối với công việc phụ trợ, tôi sẽ sử dụng PostGIS, một ít ogr2ogr, một ngôn ngữ kịch bản (Python, Ruby, Tcl, bất cứ điều gì) và một dòng lệnh unix. Tôi sẽ tránh cố gắng trộn Django vào đó ngoại trừ để giữ cho cơ sở dữ liệu của bạn tương thích nhất có thể với nó. Sau đó, đặt một mặt trước vào nó nếu bạn cần nó. Quy tắc của tôi là: ít clickey = năng suất cao hơn (mặc dù các nhà phân tích của GIS cảm thấy thoải mái hơn với clickey-clickey crap ... Tôi có nghĩa là "giao diện trực quan").

— chờ đợi

Về trình chiếu - có vẻ phức tạp một cách điên rồ, và có thể phù hợp nếu bạn đang đánh thuế sức mạnh xử lý của mình để cố gắng theo kịp, nhưng nếu không thì sẽ gặp ác mộng.

— chờ đợi

1

Một vài câu hỏi etl chung chung mà bạn có thể thấy hữu ích: " So sánh ETL không gian " và " Có lựa chọn thay thế an toàn nào không? "

— RyanKDalton

8

Tôi thực sự thích sử dụng PostGIS cho mục đích địa lý.

Hai bản chính của tôi là:

1) Việc thực hiện các tác vụ phức tạp trong cơ sở dữ liệu thường nhanh hơn rất nhiều vì bạn nhận được sự trợ giúp của trình hoạch định truy vấn để thực hiện mọi việc theo đúng thứ tự.

2) Chỉ cần lưu các dòng sql bạn đã sử dụng trong một tệp văn bản và bạn có một tài liệu rất tốt về những gì bạn đã làm.

Quy trình công việc của tôi, nếu các tác vụ liên quan đến nhiều "bước" được sử dụng để trở thành một cái gì đó như:
1- Xây dựng các phần của truy vấn hoặc tất cả tùy thuộc vào bản chất của nhiệm vụ
2- Kiểm tra truy vấn trên một phần nhỏ của tập dữ liệu để xem cách nó thực hiện
3- Thực hiện một số điều chỉnh nếu cần
4- Chạy truy vấn trên toàn bộ tập dữ liệu
5- Lưu các dòng trong tệp văn bản với một số ghi chú.
Tất cả điều này thường nhanh như khởi động ArcGIS và chờ giấy phép từ máy chủ cấp phép.

— Nicklas Avén
nguồn

5

Chúng tôi sử dụng PostGIS và một số loại môi trường lập trình Python cho một số dịch vụ web xử lý địa lý sản xuất mà chúng tôi đã phát triển; không phàn nàn!

GeoDjango là một lựa chọn tuyệt vời nếu bạn đang làm việc chủ yếu (hoặc độc quyền) với các tính năng cho một ứng dụng web. Nó không hỗ trợ kiểu dữ liệu raster của PostGIS Raster hoặc PostGIS 2.0. Nó thực sự đi kèm với phiên bản mới nhất của Django. Bạn có thể bù đắp cho việc thiếu hỗ trợ raster và độ mạnh tổng thể bằng cách sử dụng các truy vấn SQL thô, tùy chỉnh trong Django.

Đối với các ứng dụng xử lý địa lý mạnh mẽ hơn và đặc biệt nếu bạn đang muốn sử dụng mô hình quan hệ đối tượng, hãy thử GeoAlchemy2. Thư viện GeoAlchemy ban đầu, mở rộng SQLAlchemy, cung cấp hỗ trợ cho dữ liệu tính năng; GeoAlchemy2 mở rộng nó bằng cách cung cấp (giới hạn) hỗ trợ cho kiểu dữ liệu raster mới trong PostGIS 2.0.

Và sau đó, luôn có các ràng buộc Python cho GDAL và OGR!

— Arthur
nguồn

YMMV, nhưng tôi thấy các thư viện quan hệ đối tượng không thực sự thêm bất cứ thứ gì vào SQL cũ đơn giản. Như tôi đã nói trong một bình luận khác, sẽ rất thú vị khi nghe chi tiết cụ thể.

— chờ đợi vào

4

Tôi có thể mô tả một trường hợp nghiên cứu: một dịch vụ web để tạo đầu vào raster cho mô hình xói mòn sau hỏa hoạn. Về cơ bản, một số raster cần phải được đặt lại và thêm vào nhau. Tôi đã chọn GeoAlchemy2 (GA2) để giao tiếp với PostGIS, nơi dữ liệu được lưu trữ. Sử dụng GA2, tôi có thể tạo các truy vấn PostGIS nhỏ gọn, có thể sử dụng lại. Một truy vấn sẽ tạo ra một sản phẩm "đốt đất" (một bản tóm tắt của lớp phủ đất, tập hợp con). Sản phẩm này là cần thiết cho một số mô hình, nhưng cũng được thêm vào một raster khác, một lớp đất, để tạo ra một sản phẩm đầu ra thứ ba. GA2 cho phép tôi trộn, kết hợp và tuần tự hóa trong Python.

— Arthur

3

Mặc dù có thể, thật khó để tưởng tượng rằng bạn sẽ muốn thực hiện nhiều công việc địa lý bên trong một công cụ cơ sở dữ liệu hoặc khung web. Tôi khuyên bạn nên xem các thư viện mã cơ bản - geos, proj.4 và gdal. Có các ràng buộc Python hoặc thư viện cho cả ba. Một tùy chọn khác để xem xét là plugin công cụ địa lý Sextante cho QGIS, vì nó cho phép xây dựng mô hình / quy trình công việc.

Một số suy nghĩ khác:

Đừng loại trừ việc sử dụng PostGIS. Nó cung cấp khả năng lưu trữ và máy chủ tốt và hiển thị một số chức năng geos và proj.4 mặc dù SQL. Nó cũng chơi tốt với các công cụ khác được đề cập: Django, QGIS và Python.

Bên cạnh việc có thể sử dụng plugin Sextante đã nói ở trên, QGIS rất tốt cho việc trực quan hóa, có một số công cụ để làm việc với postgres và cũng bao gồm bảng điều khiển Python.

Nếu bạn đang tìm kiếm ORM và muốn một giao diện người dùng web, Django sẽ làm điều đó. Nếu bạn không quan tâm đến giao diện kém hấp dẫn, các trang quản trị sẽ cung cấp cho bạn giao diện CRUD với rất ít nỗ lực - thậm chí chỉnh sửa hình học nếu bạn sử dụng GeoDjango.

— Scro
nguồn

2

Mặc dù tôi đồng ý rằng người ta sẽ không sử dụng khung web để xử lý địa lý, tôi không đồng ý rằng người ta sẽ không sử dụng PostGIS (hoặc một công cụ cơ sở dữ liệu khác) để xử lý địa lý. Chúng tôi cần các chi tiết cụ thể để tiến lên trong cuộc thảo luận, nhưng tôi thực hiện một số lượng lớn phân tích / cắt hình học và phân tích điểm trong poly bằng PostGIS và SQL.

— chờ đợi

2

@forkandwait Oh, tôi đồng ý với bạn trên PostGIS. Tuy nhiên, tôi có ấn tượng rằng họ sử dụng một số tập lệnh nhỏ mà họ có thể xâu chuỗi khác nhau cho mỗi dự án. Mục tiêu của tôi là khiến họ điều tra các thư viện cơ bản để họ có thể chọn môi trường nào hoạt động tốt nhất.

— Scro

3

Hãy xem ETL , cụ thể là FME cho các hoạt động không gian (hoặc GeoK Ấm mã nguồn mở ).

Tôi thực sự thích sử dụng FME, vì nó tạo ra một quy trình trực quan và bạn có thể tách ra logic cho các hoạt động không gian, tham gia, hợp nhất ... mọi thứ và bạn có thể làm việc với các định dạng không phải cơ sở dữ liệu và các cơ sở dữ liệu khác nhau ... Bạn có thể làm rất nhiều, và dễ dàng, và nhanh chóng. Nếu bạn có kinh nghiệm xây dựng mô hình wtih, bạn sẽ nhanh chóng nhận được nó, cộng với có rất nhiều tài liệu trực tuyến.

Nhược điểm duy nhất của FME là tốn tiền. Nhưng tôi nghĩ nó đáng giá.

Một cách khác để sử dụng FME có lẽ là GDAL và OGR cùng với có lẽ Python để liên kết nó lại với nhau. Hoặc, như bạn nói, làm tất cả trong PostgreSQL. Tôi nghĩ rằng một ETL có một vai trò mạnh mẽ trong việc xáo trộn dữ liệu không gian và nó thực hiện rất nhiều thứ mà bạn không thể làm chỉ trong cơ sở dữ liệu của mình.

Tôi chưa sử dụng nó, nhưng GeoServer cung cấp triển khai WPS , tôi chưa sử dụng cái này, nhưng những người khác có thể nhận xét về cách nó có thể hữu ích cho bạn?

Tôi không thể nhận xét về việc sử dụng GeoDjango, nhưng tôi nghĩ đó là một CMS, giống như một giao diện người dùng để xem dữ liệu.

— Alex Leith
nguồn