Dữ liệu OSM thô được xử lý như thế nào cho openstreetmap.org

Bất cứ ai cũng có thể cung cấp cái nhìn sâu sắc về cách dữ liệu OSM được xử lý hoặc hiển thị cho www.openstreetmap.org?

Một ví dụ cụ thể ... Tôi đã trích xuất dữ liệu từ bộ dữ liệu hành tinh Post.IS gần đây cho một khu vực ở Missouri. Dữ liệu OSM cần được làm sạch rất nhiều trước khi có thể được hiển thị bằng cách sử dụng đúng kiểu. Nhiều vùng nước được lưu trữ dưới dạng các chuỗi dòng không đóng đúng cách, vì vậy tôi phải sử dụng FME để chụp và sau đó xây dựng đa giác để tôi có thể có sông / hồ đầy màu xanh.

Nếu tôi nhìn vào cùng một dữ liệu ở đây, các vùng nước được hiển thị như mong đợi.

Tôi gặp khó khăn trong việc xác định tất cả các trường hợp bắt buộc phải chụp (ví dụ: loại 'Tự nhiên' yêu cầu điều đó và dung sai phải là bao nhiêu). Ngoài ra tôi nghi ngờ có nhiều vấn đề dữ liệu khác mà tôi sẽ không bao giờ thấy khi tôi đang đối phó với tất cả Bắc Mỹ.

Có phải tất cả mọi người tải xuống và sử dụng dữ liệu OSM đều trải qua quá trình dọn dẹp của riêng họ? Có ai biết cách dọn dẹp này được xử lý bởi www.openstreetmap.org không? Có vẻ như quá trình của họ sẽ được thông báo tốt nhất và được thử nghiệm nhiều nhất.

Bất kỳ cái nhìn sâu sắc nhiều đánh giá cao.

EDIT : Đây là thông tin thêm về quy trình làm việc của tôi

Một tập tin Planet.osm được tải xuống và tải vào PostGIS, bằng cách sử dụng Osmosis, vào lược đồ pssql. Sau đó tôi trích xuất OSM xml từ PostGIS cho nhiều khu vực nhỏ, một lần nữa sử dụng Thẩm thấu. Mỗi tệp xml nhỏ này sau đó được chuyển đổi thành Shapefiles bằng FME và các loại tính năng rộng của nó. Đây là giai đoạn (OSM xml -> Shp qua FME) mà tôi đang mong đợi để chuyển đổi các dòng thành đa giác và thực hiện việc dọn dẹp dữ liệu khác.

Các Shapefiles này được cung cấp thông qua GeoServer (và được lưu trữ bằng cách sử dụng GWC).

Được rồi, có một vài góc độ khác nhau về vấn đề này và vì không rõ bạn đang xử lý dữ liệu ban đầu như thế nào, tôi đoán tôi sẽ chỉ đưa ra một cái nhìn tổng quan.

Có hai cách chính để tiêu thụ dữ liệu OSM - bằng cách sử dụng osm2pgsql , một tiện ích cũ hơn hỗ trợ 'bản định kiểu' và cập nhật vi sai, và Imposem , một hệ thống dựa trên Python mới hơn hỗ trợ chuyển đổi biểu định kiểu dựa trên Python. Khi mọi người xử lý, rất nhiều trong số đó là loại kịch bản đó. Chẳng hạn, đây là một ánh xạ áp đặt cho osm-sáng , biểu định kiểu mà MapBox Streets (tiết lộ / nhân viên) dựa trên.

Để cụ thể hơn với những gì bạn gặp phải, có khả năng là bạn không xử lý đúng các mối quan hệ osm , trong mô hình dữ liệu là những gì cho phép nhiều linestrings tạo thành đa giác. Các công cụ như Imposem và osm2pgsql thường xử lý loại chuyển đổi dữ liệu này cho bạn.

Theo như cách mà OSM.org tự thực hiện: các chỉnh sửa nằm trong cơ sở dữ liệu Postgres 'ngữ nghĩa' và liên tục được nhập vào cơ sở dữ liệu PostGIS với tính thẩm thấu và được hiển thị bằng Mapnik . Không có bước dọn dẹp thủ công giữa cơ sở dữ liệu và kết xuất bản đồ, vì cả hai được kết hợp chặt chẽ và bản đồ nhằm mục đích cập nhật.

Nói chung, bạn không cần "chụp nhanh" như vậy, vì dữ liệu OSM ban đầu được tổ chức theo cấu trúc liên kết - ví dụ, một đa giác (= cách OSM) được xác định thông qua danh sách các chỉ số nút (chứ không phải trực tiếp theo tọa độ của chúng) - vì vậy nếu các chỉ số bắt đầu và kết thúc giống nhau, thì đó được coi là một đa giác khép kín. Mặt khác, nó là một đa tuyến (như một con đường).

Các cơ quan lớn hơn (như sông Osage trong trường hợp của bạn) thường được xác định thông qua đa hệ OSM , bao gồm một loạt các cách OSM (linestrings) xác định hình dạng và lỗ (nếu có). Có một số vấn đề tiềm ẩn với đa hệ điều hành OSM:

1. Có nhiều hơn một cách để xác định chúng (chỉ cần nhìn vào thông số kỹ thuật). Những người khác nhau sử dụng các quy tắc khác nhau.
2. Các quy tắc là ngầm định - bạn cần đọc qua các tài liệu wiki OSM để cố gắng hiểu cách xử lý chúng.
3. Nếu bạn sử dụng trích xuất dữ liệu OSM, một số phần của đa đường có thể bị thiếu (vì chúng không nằm trong vùng địa lý bên trong tiểu bang Missouri). Vì vậy, bạn cần tìm cách đóng đa giác thân nước (bằng cách cắt nó bằng cách sử dụng ranh giới trạng thái hoặc đóng thủ công bằng một số công cụ GUI).

Vâng, có những vấn đề dữ liệu khác, quá. Chủ yếu chúng xuất phát từ chính bản chất của lập bản đồ OSM: những người khác nhau lập bản đồ mọi thứ khác nhau và không có quy tắc cụ thể nào về cách thực hiện. Đó ít nhiều là một tình trạng hỗn loạn tự tổ chức;)

Bản thân tôi không bao giờ làm việc với dữ liệu OSM được làm phẳng do osm2pgsql tạo ra - Tôi luôn bắt đầu với dữ liệu tô pô gốc ở dạng OSM XML và viết mã để xử lý nó thành dạng tôi cần. Nhưng một lần nữa, tôi không sử dụng Mapnik để kết xuất, vì vậy tôi có lẽ là thiểu số.

Nếu bạn sử dụng lược đồ cơ sở dữ liệu ban đầu từ osm2pgsql, bạn có các mô hình dữ liệu osm liên quan 'cách khép kín' và 'quan hệ đa đường' được chuyển thành đa giác và đặt vào một bảng có tên là 'hành tinh_polygon'. Các cách và nút nằm trong 'hành tinh_line' và 'hành tinh_point'. Bạn có thể truy cập các bảng này thông qua Quantum GIS và xuất chúng trực tiếp sang shapefiles. Bạn cũng có thể thực hiện các truy vấn SQL từ bên trong Quantum GIS để lọc dữ liệu.

Tôi sẽ không sử dụng thẩm thấu cho điều đó. Nó không có xử lý đa giác như osm2pgsql. Thẩm thấu lưu trữ dữ liệu theo cùng cách mà những người đóng góp đối phó với chúng (Nút, cách thức và quan hệ). Nó không phải là một lược đồ cơ sở dữ liệu phù hợp để kết xuất.