PostGIS sẽ cung cấp một lợi thế so với MySQL cho một ứng dụng nông trại?


23

Tôi có một ứng dụng web lưu trữ các vị trí của các trang trại ở Tây Michigan. Bạn có thể tìm kiếm một sản phẩm (ví dụ "bông cải xanh") và nó sẽ cho bạn thấy tất cả các trang trại phát triển sản phẩm đó.

Hiện tại tôi đang sử dụng MySQL và sử dụng lượng giác để tính toán sự khác biệt giữa vị trí của người dùng và vị trí của mỗi trang trại. Đó không phải là một cách tồi để đi nhưng nó đã làm một số việc.

Một điều nữa tôi muốn làm sớm là vạch ra các mùa phát triển cho các sản phẩm khác nhau cho các khu vực khác nhau. (Ví dụ, tôi muốn chứng minh rằng bơ phát triển vào một thời điểm nhất định trong năm tại California nhưng không bao giờ Ohio.)

Tôi nhận ra đây là một câu hỏi mở và có thể ngây thơ, nhưng có đáng để tôi chuyển sang PostgreQuery / PostGIS để tận dụng các khả năng không gian của nó không?


1
Bạn đang lên kế hoạch cho bản đồ "mùa" động hay bản đồ tĩnh?
underdark

Nếu tôi hiểu những gì bạn đang hỏi, năng động. Ví dụ: mùa sinh trưởng của Táo gần Grand Rapids, MI là tháng 8 đến tháng 10.
Jason Swett

Câu trả lời:


21

Tôi là một người hâm mộ PostGIS tuyệt vời và không có kinh nghiệm với MySQL vì vậy tôi không được thiên vị.

Nhưng từ những gì bạn viết tôi nghĩ đến hai lý do để chuyển đổi.

đầu tiên, chắc chắn sẽ dễ dàng hơn nhiều để thực hiện các tính năng mới như bản đồ mùa bạn đã đề cập.

thứ hai, khi bạn thực hiện các phép tính lượng giác của mình, tôi đoán bạn đang thực hiện nó bên ngoài db. nếu bạn làm tất cả những điều đó trong db thay vào đó bạn sẽ tự do hơn rất nhiều trong việc phát triển các ứng dụng lớp phủ.

bạn có thể sẽ không phải thực hiện bất kỳ tính toán nào ngoài db nếu bạn chạy postgis.

điều mùa bạn đề cập có thể có thể thực hiện được trong MySQL vì nghe có vẻ rất cơ bản nhưng bạn sẽ có được sự linh hoạt của mmore trong PostGIS với quyền truy cập vào tất cả các chức năng không gian.

/ Nicklas


18

Nếu chỉ vì bạn sẽ có nhiều sự lựa chọn hơn trong các ứng dụng của bên thứ ba để tạo bản đồ thông tin của bạn (mapserver, geoserver, v.v.), tải dữ liệu (ogr2ogr, fme, v.v.) PostGIS sẽ là lựa chọn tốt hơn. MySQL sẽ chỉ phù hợp nếu nhu cầu của bạn tiếp tục tương đối hạn chế.


FME hỗ trợ MySQL cũng như PostGIS.
Quạ

8

MySQL cũng có một phần mở rộng không gian , nhưng theo như tôi biết (tôi chưa bao giờ sử dụng nó), không có tính năng phong phú và ổn định như PostGIS .

Nếu bạn đang cân nhắc sử dụng cơ sở dữ liệu không gian, PostGIS là một lựa chọn tốt và nỗ lực chuyển đổi sẽ có giá trị.

Mặc dù MySQL đã cung cấp một số chức năng để lưu trữ và vận hành trên dữ liệu không gian địa lý, nhưng chức năng này còn khá nhiều điều mong muốn và còn lâu mới cung cấp khả năng tương thích OpenGIS đầy đủ.

Đáng chú ý nhất là tất cả các chức năng truy vấn dữ liệu không gian chỉ hoạt động trên MBR (hình chữ nhật giới hạn tối thiểu), để đơn giản hóa các hoạt động.

http://forge.mysql.com/wiki/GIS_Fifts


6

Trận chiến MySQL vs Postgis lại trỗi dậy một lần nữa:

http://ambergis.wordpress.com/2008/02/19/mysql-vs-postgis/

Lưu ý hầu hết người bình luận là từ đây (gis stack exchange.)

liên kết quá

http://www.spativelyadjusted.com/2008/02/05/browing-open-source-gis-into-an-esri-shop/#comment-32680

Đã có nhiều triển khai thành công với postgis hơn mysql. (phụ thuộc vào khách hàng thiết lập và những gì họ đang cố gắng đạt được)

Gợi ý duy nhất của tôi cho Paul Ramsey (và nhóm PostGIS) là một GUI đẹp cho postgis thông qua PGAdmin (v4 ..?) Với một trình hiển thị (như FME của phần mềm an toàn) - không chỉ các thuộc tính sẽ là điểm cộng chính. Hiện đang sử dụng QGIS để trực quan hóa dữ liệu postgis.

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.