GML, KML, GeoJSON - Tốc độ hiển thị 3109 đa giác?


12

Tôi đang làm việc với Geoserver, phục vụ các quận dưới 48 của Hoa Kỳ cho các lớp mở (3109 đa giác - nhiều đỉnh hơn). Các hạt được tải vào cơ sở dữ liệu postgis. Tôi tò mò về trải nghiệm của nhà phát triển khi cố gắng đẩy số lượng đỉnh đó cho khách hàng.

Định dạng WFS nào bạn đã đạt được kết quả tốt nhất với? Đã điều chỉnh bổ sung cho Geoserver đã được sử dụng?

Tôi nhận ra rằng WMS được lát gạch sẽ nhanh hơn, nhưng tôi muốn cho phép thay đổi động trong bản đồ choropleth bằng cách sử dụng openLayers, tức là. người dùng gửi biểu mẫu, tập lệnh Python được gọi và các thùng dữ liệu mới được trả về cho các trình mở để tải lại div bản đồ. Tôi cũng muốn thử điều này ở dạng phân giải đầy đủ trước khi giảm độ phức tạp đa giác trong các lớp mở.

Câu trả lời:


4

Có thể điều này kích hoạt một số ý tưởng mới: Tôi đã có một ứng dụng đang chạy, nơi người dùng có thể chỉnh sửa bản đồ với nhiều yếu tố.

Thay vì gửi tất cả dữ liệu dưới dạng WFS, tôi sử dụng bản đồ WMS và khi người dùng nhấp hoặc vẽ một lựa chọn, tôi tìm nạp các mục đã chọn dưới dạng WFS .

Sau khi gửi bản cập nhật trở lại máy chủ, tôi làm mới lớp WMS.

Có một số ví dụ về OpenLayers thể hiện cách bạn có thể làm điều đó. Có thể bạn sẽ phải điều chỉnh nó một chút, nhưng OpenLayers + GeoServer sẽ giải quyết phần khó khăn cho bạn. Dữ liệu được gửi gzipped, vì vậy định dạng ban đầu thậm chí không quan trọng; Đó không phải là nút cổ chai. Hãy để OpenLayers và GeoServer tìm ra định dạng họ sử dụng để trao đổi thông tin.

Cách tiếp cận này quy mô khá tốt. Ngay cả những người có kết nối chậm và máy tính chậm cũng có thể sử dụng nó để chỉnh sửa bản đồ. Tìm nạp hàng trăm phần tử rất nhanh chóng và có thể bạn sẽ không cần nhiều hơn thế để đồng thời chỉnh sửa.

Cuối cùng .. ngoài chủ đề, nhưng khi bạn có ý định thực hiện công cụ phía máy khách với dữ liệu bản đồ: Hãy nhớ rằng IE7 và thấp hơn sẽ gặp vấn đề nếu bạn muốn vẽ đa giác bằng OpenLayers. OpenLayers sử dụng SVG cho bản vẽ phía máy khách và IE7 trở xuống không có hỗ trợ tích hợp. Những người dùng đó sẽ được yêu cầu tải xuống một plugin cũ tệ hại. Tất cả các trình duyệt khác đều ổn.


IE8 sẽ gần như tồi tệ. OpenLayers có một số trình kết xuất và đối với các trình duyệt không hỗ trợ Canvas hoặc SVG sẽ dùng đến VML, IE7 không hỗ trợ. Các trình kết xuất khác nhau cho hiệu suất tốt hơn và kém hơn ở các vị trí khác nhau, ví dụ: kết xuất so với phát hiện nhấp chuột & nhấp chuột
tomfumb

3

GEOJSON theo ý kiến ​​của tôi, định dạng tốt nhất, dễ đọc, dễ sử dụng trong javascript và thường có kích thước nhỏ hơn GML / KML. Nó thậm chí có thể chứa thông tin về phong cách, xem ở đây .

Nó không phải là một tiêu chuẩn chính thức, nhưng nó được hỗ trợ trên cả tờ rơi và openlayers và trên nhiều ứng dụng máy tính để bàn như qgis.


2

Sử dụng GeoJSON là một khởi đầu tốt để tăng tốc hệ thống của bạn nhưng nó có thể không đủ. Bạn nên xem xét việc xây dựng một số phiên bản của lớp dữ liệu của mình, một phiên bản cho mỗi lớp thu phóng và áp dụng các phương pháp tổng quát hóa / đơn giản hóa cho mỗi phiên bản. Khách hàng nên yêu cầu lớp liên quan tùy thuộc vào mức thu phóng được chọn. Điều đó sẽ đảm bảo mức độ chi tiết của dữ liệu được trao đổi giữa máy chủ và máy khách là phù hợp và nó sẽ tăng đáng kể hơn cả việc chuyển mạng và kết xuất. Để đi xa hơn, bạn có thể mở rộng hệ thống của mình bằng cách xếp vectơ và lập chỉ mục không gian như được mô tả trong tài liệu này , nhưng tôi không chắc chắn các trình mở và máy chủ địa lý có thể xử lý nó ... chưa!

Để chắc chắn: Quên GML.


Đây là phương pháp dự phòng của tôi khi WFS độ phân giải đầy đủ quá chậm. Tôi quan tâm đến các vấn đề ở kích thước này và muốn có thể báo cáo cả tốc độ phân giải đầy đủ và, nếu cần, tốc độ phân giải giảm.
Jay Laura

2

Tại sao không sử dụng tập lệnh python của bạn để tạo tệp SLD mới và gửi nó đến máy chủ WMS với yêu cầu của bạn.

Có một ví dụ ở đây .


Tôi đã xem xét điều này, và có khả năng sẽ kiểm tra tùy chọn này về tốc độ. Đây không phải là để phát triển, nhưng để nghiên cứu, vì vậy tôi muốn thử WFS.
Jay Laura

1

Tôi đã đi xuống một con đường tương tự hai lần và kết xuất phía máy khách cho bất cứ điều gì nhiều hơn một số điểm nhỏ hoặc đa giác thực sự đơn giản không phải là một ý tưởng hay. Khi bạn đã tự trói mình vào kiến ​​trúc đó, sẽ rất tốn kém để sao lưu và trong bất kỳ dự án nào, bạn có thể thấy sự thay đổi về yêu cầu hoặc tăng khối lượng dữ liệu khi các bên liên quan / giám sát viên khác nhau bắt đầu thấy khả năng của hệ thống của bạn. Phương pháp kết xuất phía máy khách dựa trên trình duyệt không mở rộng.

Nếu bạn muốn kết xuất động, tôi sẽ tiếp cận lần thứ hai @ iant. Trước đây tôi đã mô tả một số tùy chọn cho một vấn đề khác nhau nhưng có liên quan ở đây . Tôi cũng đã sử dụng tổng quát hóa đa giác để hỗ trợ kết xuất phía máy khách và, trong khi nó chắc chắn có ích, nó tạo ra nhiều vấn đề khó khăn hơn, như nếu bạn muốn kéo xuống đa giác không khái quát khi người dùng của bạn phóng to hơn.

Ngay cả khi bạn đang làm việc với một nền tảng đã biết - ví dụ: bạn biết phần cứng, phiên bản trình duyệt và plugin của tất cả các máy khách - điều đó là không thể, bạn không biết những máy khách đó đang tải loại nào. Cách tiếp cận này yêu cầu trình duyệt có thể có nhiều thời gian CPU để duy trì trải nghiệm người dùng và mọi thứ khác sẽ gây khó chịu cho người dùng của bạn.

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.