Hướng tới một giao thức mã hóa dữ liệu vector dưới dạng hình ảnh


16

Đây là câu hỏi tiếp theo cho câu hỏi này: Tạo đa giác Vector với hiệu suất kết xuất như GISCloud?

Trong câu trả lời của mình, Yagi phác thảo một lý do để mã hóa thông tin địa lý theo định dạng hình ảnh và giải mã nó trong trình duyệt. Anh ấy quan sát rằng "Hiện tại, để làm điều này, bạn phải tự lăn". Ông cũng quan sát rằng hiện tại không có tiêu chuẩn cho việc này.

Với hiệu suất tuyệt vời đang được chứng minh, có vẻ như cộng đồng có thể được hưởng lợi từ một tiêu chuẩn. Từ hiểu biết của tôi về vấn đề này, có vẻ như một cách xử lý tiêu chuẩn có thể được thực hiện. Gọi nó là B-WFS.

Câu hỏi của tôi, sau đó: một giao thức hữu ích để mã hóa dữ liệu vectơ như hình ảnh trông như thế nào? Có điều gì đó làm cho nó quá phức tạp để giải quyết một cách hữu ích, hay đó chỉ là một trường hợp "chưa có ai làm điều này"?


Tôi xin lỗi vì sự thiếu hiểu biết của tôi, có lẽ tôi đã không nhận được điểm, nhưng, một geotiff với bảng màu vết thương không làm việc?
Pablo

2
Xin lỗi vì sự thiếu hiểu biết của tôi, quá;) Tôi không chắc bảng màu là gì, nhưng tôi không nghĩ vậy. Mục tiêu không phải là vượt qua một hình ảnh với siêu dữ liệu tương ứng. Như bạn đề cập, đó là một vấn đề được giải quyết. Mục tiêu là truyền dữ liệu vectơ với siêu dữ liệu ở định dạng nhỏ gọn hơn UTF-8 có thể đọc được của con người. Do JavaScript không được trang bị để xử lý dữ liệu nhị phân, cách giải quyết được đặt ra là mã hóa dữ liệu trong tệp nhị phân hình ảnh và giải mã nó bằng HTML 5 Canvas để giải mã hình ảnh và sau đó biến nó thành các đối tượng vector.
canisrufus

1
@Pablo Giả sử rằng I / O mạng (chứ không phải phân tích cú pháp) là nút cổ chai trong việc xử lý các vectơ trên web, có một cách thiết lập để xử lý các vectơ được mã hóa nhị phân phải giúp viết bản đồ web hiệu quả tốt hơn.
canisrufus

Thật thú vị, bây giờ tôi hiểu rồi ... Bây giờ tôi bắt đầu làm việc với webmap và tôi vẫn đang học những điều cơ bản. BTW, một colortable hoặc colormap là một bảng liên kết giá trị ô raster với một lớp.
Pablo

1
@monkut Vâng, nó khác. :) Rasterizing một tập các vectơ chỉ là hiển thị nó. Voila. Raster! Những gì tôi đã nói về câu hỏi này là khác nhau. Bạn nên đọc câu trả lời của Ragi trong câu hỏi tôi liên kết đến; Điều đó sẽ bắt đầu để giải thích những gì tôi có ý nghĩa. Nếu bạn thấy nó vẫn chưa rõ ràng, tôi sẽ dành chút thời gian để viết lên một câu trả lời thực sự.
canisrufus

Câu trả lời:


5

Nó chỉ ra rằng đây là một công việc không cần thiết xung quanh. XHR2, một phần của việc nâng cấp lên javascript, sẽ cho phép nhập và phân tích dữ liệu nhị phân mà không ép buộc bất cứ điều gì.


4

Nó không cần phải là một tiêu chuẩn riêng biệt như vậy, bởi vì Đặc tả kỹ thuật triển khai WFS 04-094, điều khoản 9,4 nói:

Các định dạng đầu ra khác (bao gồm các phiên bản cũ hơn của GML, không phải XML, định dạng nhị phân và nhà cung cấp cụ thể) cũng có thể miễn là các giá trị thích hợp cho thuộc tính outputFormat được quảng cáo trong tài liệu khả năng [điều 13]. Thông số kỹ thuật này khuyến nghị rằng một tường thuật mô tả [sic] nên được bao gồm trong tài liệu khả năng cho từng định dạng đầu ra được liệt kê ở đó.

Cách dễ nhất để thêm hỗ trợ nhị phân là chỉ GZIP một luồng JSON, trong đó việc giải nén được xử lý tự động bởi hầu hết các trình duyệt. Điều đó nói rằng, tôi đã không thử nó, nhưng nó sẽ yêu cầu công việc tối thiểu ở cả phía máy chủ và máy khách, giả sử cả hai đều hỗ trợ JSON không nén.


+1 cho điểm về tiêu chuẩn. Nén không phải là mã hóa nhị phân theo nghĩa tương tự. Các câu hỏi về ý nghĩa hiệu suất giữa hai cách tiếp cận, một gejson được nén và hình học được mã hóa trong một hình ảnh, chắc chắn đáng để khám phá.
canisrufus

Bạn nói đúng, điều này làm giảm tắc nghẽn mạng, nhưng gây ra tải lớn hơn cho máy khách và máy chủ. Nhưng mã hóa dữ liệu vectơ trong một hình ảnh là IMO, một cách tiếp cận tối ưu phụ vì độ dài thay đổi của dữ liệu vectơ. Nó cũng làm xáo trộn bản chất của dữ liệu vectơ. Một cách tiếp cận tốt hơn có thể là có hai luồng dữ liệu song song, một cho vectơ và một cho raster, có thể được xử lý bởi các máy chủ và thiết bị lưu trữ khác nhau và sau đó được kết hợp bởi máy khách.
MerseyViking

Vấn đề về độ dài thay đổi của dữ liệu vectơ có thể được xử lý về cơ bản giống như cách các mạng xử lý việc gửi các gói. Tôi đồng ý rằng nó không tối ưu, nhưng dường như chúng ta bị đẩy vào đó bởi thực tế là JS không xử lý tốt với nhị phân. Tôi sẽ chỉ viết và thực hiện một cái gì đó cho mình, khi tôi có thời gian. Tôi sẽ đặt nó ở đây khi tôi làm việc gì đó ...
canisrufus

1
Tôi thực sự nghĩ rằng Ragi đã định nghĩa nó rõ ràng trong câu trả lời của mình. Tôi đồng ý rằng tôi đã không làm thế. :) Có thể giả thuyết rằng định dạng nhị phân có thể là định dạng truyền dữ liệu nhanh hơn nói chung là sai. Sự khác biệt chỉ có thể là không đáng kể. Tôi đã nói rằng "ý nghĩa hiệu suất ... là đáng để khám phá." Rõ ràng tôi không thể chỉ định nghĩa một định dạng nhị phân và sau đó tuyên bố chiến thắng. Chúng ta sẽ thấy!
canisrufus

1
@MerseyViking Không cần phải lặp lại câu trả lời của mình, hãy để tôi đặt câu hỏi này theo quan điểm về chu kỳ CPU (vì giả định của bạn là về tối ưu hóa sớm). Truy cập L1 Cache = 1 chu kỳ CPU, L2 = 14 chu kỳ, RAM ~ 250 chu kỳ, Đĩa = 41.000.000, Mạng (tùy thuộc vào băng thông, vì vậy hãy tử tế) = 240.000.000. I / O, cho dù dựa trên đĩa hoặc dựa trên mạng (trường hợp của chúng tôi) là các đơn đặt hàng có cường độ chậm hơn. Làm thế nào để chuyển tải từ phần cuối của quang phổ sang phần đầu tiên "sớm" theo bất kỳ tỷ lệ nào?
Ragi Yaser Burhum
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.