Tạo đa giác Vector với hiệu suất kết xuất như GISCloud?


59

Tôi đã tìm kiếm một giải pháp vững chắc cho phép tôi tạo một bản đồ web và đa giác vector mà không mất thời gian để tải dữ liệu đó với mục tiêu cho phép tôi làm cho mỗi đa giác hiển thị một màu khác nhau trên một sự kiện di chuột.

Theo như tôi biết, có 3 tùy chọn cụ thể để đạt được điều này thông qua canvas, SVG, Flash.

Flash có vẻ như sẽ là giải pháp tốt nhất nếu nó hoạt động trên apple iphones / ipad vì nó dường như cung cấp kết xuất nhanh nhất và hiển thị sạch nhất. Canvas dường như là lựa chọn tốt thứ hai nhưng mất nhiều thời gian nếu bạn có hàng trăm đa giác được hiển thị trên bản đồ trong khi SVG thậm chí còn mất nhiều thời gian hơn để kết xuất.

Tôi gần như mất hy vọng trong việc tìm giải pháp cho vấn đề này nhưng hôm nay tôi tình cờ gặp một công ty có tên là GISCloud http://www.giscloud.com (hiện đang trong giai đoạn thử nghiệm với đăng ký miễn phí).

Công ty này đã SOMEHOW quản lý để tìm ra một cách tuyệt vời để hiển thị hàng trăm vectơ trên bản đồ trong thời gian gần. Tôi đã rất ngạc nhiên với cách tiếp cận của họ và câu hỏi của tôi đối với cộng đồng liên quan đến cách chúng ta có thể sao chép cách tiếp cận của họ để sử dụng với các công nghệ hiện có như tờ rơi, tờ mở, sáp ...

Hãy tự mình xem bằng cách xem bản demo tuyệt vời này: http://www.giscloud.com/map/284/africa

Hãy chắc chắn rằng bạn di chuột qua bất kỳ đa giác nào trên trang và kiểm tra các điều khiển thu phóng để thấy rằng các đa giác này thực sự là vectơ.

Những gì tôi đã nhận thấy bằng cách xem xét các yêu cầu với fireorms là bản đồ đang yêu cầu các tệp json cụ thể. Có vẻ như tùy thuộc vào mức / mức thu phóng, có nhiều tệp json được yêu cầu.


Tôi cũng nên đề cập ở đây rằng một khi giscloud tải dữ liệu trên trang di chuột qua một vectơ ngay lập tức thay đổi màu sắc mà không tạo yêu cầu mới.

VÍ DỤ:

Tôi giả sử cấu trúc url tuân theo logic dịch vụ ốp lát tiêu chuẩn (ví dụ: thư mục thứ 3 đến thư mục cuối cùng là mức thu phóng ...).

Trong mọi trường hợp, tôi đã phân tích dữ liệu thực tế của các tệp json này và có vẻ như logic họ đang sử dụng tuân theo một số loại logic mà họ tạo ra các vectơ của họ chỉ dựa trên các giá trị dữ liệu này:

  • chiều rộng / chiều cao: chúng xác định chiều rộng và chiều cao của dữ liệu được phục vụ trong mỗi yêu cầu json
  • pixel: ở đây họ xác định các giá trị pixel mà tôi giả sử bằng cách nào đó liên quan đến một số tọa độ pixel x / y chung cho các mức điểm tổng quát? Tôi đoán rằng bằng cách nào đó họ có cách tự động đơn giản hóa khu vực tùy thuộc vào mức thu phóng. Tôi giả sử họ sử dụng tọa độ pixel Tôi đoán rằng họ đang giảm đáng kể kích thước của dữ liệu cần được tải so với dữ liệu lat / long.
  • kiểu: ở đây họ xác định hai giá trị css RGB. "F" đại diện cho màu tệp đa giác và "S" đại diện cho màu viền đa giác.
  • geom: đây là nơi tôi đoán họ bằng cách nào đó xác định cụ thể xác định từng đa giác trong ô đang được tải trong đó dữ liệu đó được xác định dựa trên cửa sổ chứa bản đồ. Điều thú vị nữa là mỗi mục nhập có một giá trị "S" mà tôi giả sử được sử dụng làm thuộc tính tùy chọn hoặc giá trị liên kết tính năng và ở cuối mỗi mục ở đây có một khu vực dường như xác định một ID vector cụ thể cùng với ID lớp mà tôi đoán được sử dụng để bằng cách nào đó tham gia dữ liệu từ mỗi yêu cầu gạch json được gọi.

Tôi cũng giả định rằng bằng cách nào đó họ đã tìm ra cách tự động xác định và phân tách dữ liệu cần được tải cho mỗi ô tùy thuộc vào kích thước của dữ liệu cần được tải cho ô được yêu cầu.

Dưới đây là phân tích trích xuất của một trong những yêu cầu sau:

{"width":256,"height":256,"tile":
{"pixels":
[0,6461,-1,0,5,148,0,509,-1,10715,-1,1,-1,251,-1,1,-1,1,-1,251,-2,3,-1,255,-1,249,-2,5,-2,247,-1,509,-3,251,-1,2,-2,253,-2,252,-2,254,-1,255,-1,254,-1,255,-1,1276,-2,13,-1,233,-1,2,-1,253,-1,1,-1,255,-1,247,-1,1306,-1,1533,-1,1269,-1,1276,-1,2303,-1]},

"styles":
[{"f":"rgb(99,230,101)","s":"rgb(5,148,0)","lw":"0"}],

"geom":
[
{"s":0,"p":[4,143,5,144,3,146,1,146,2,143,4,143],"c":"layer1156_5098"},
{"s":0,"p":[-2,143,0,140,2,141,2,144,1,146,-2,144,-2,143],"c":"layer1156_5067"},
{"s":0,"p":[7,143,5,144,4,143,2,143,2,141,5,138,6,139,5,141,7,143],"c":"layer1156_5051"},
{"s":0,"p":[10,141,11,137,12,137,14,137,12,142,9,143,9,142,10,141],"c":"layer1156_5041"},
{"s":0,"p":[1,136,0,140,-2,143,-2,136,1,136],"c":"layer1156_5038"},
{"s":0,"p":[8,143,5,141,5,137,8,136,10,137,10,141,8,143],"c":"layer1156_5033"},
{"s":0,"p":[5,137,2,141,0,140,1,136,1,136,2,135,3,136,5,137],"c":"layer1156_5028"},
{"s":0,"p":[10,134,12,136,11,138,8,135,10,134],"c":"layer1156_5020"},
{"s":0,"p":[-2,133,0,136,-2,136,-2,133],"c":"layer1156_5005"},
{...}
...
]
}

Làm thế nào chúng ta có thể sao chép cùng một loại tốc độ (hoặc tương tự) bằng cách sử dụng postgis (mà tôi dường như cũng đang sử dụng)?


Ah! Đừng nhìn vào tệp JSON, hãy nhìn vào những hình ảnh dường như không quan trọng khác được truyền qua :) Xem câu trả lời của tôi dưới đây.
Ragi Yaser Burhum

"Có 3 lựa chọn cụ thể" ... Vậy Silverlight, gan băm nhỏ là gì?
Kirk Kuykendall

Silverlight yêu cầu plugin của nó hoạt động và tôi không nghĩ nó thực sự nhanh hơn giải pháp mà giscloud sử dụng nhưng tôi chưa thực hiện bất kỳ so sánh trực tiếp nào.
NetConstructor.com

2
Câu hỏi này đưa ra rất nhiều điều thú vị để nói về những điều không phù hợp với định dạng Hỏi và Đáp thông thường. Hãy trò chuyện về họ trong việc sử dụng vectơ trong thế giới bản đồ web
matt wilkie

@RagiYaserBurhum Có một lời giải thích tốt đẹp của cách này đã được sử dụng để lập bản đồ du lịch đường đẳng thời gian sử dụng một kỹ thuật tương tự: mysociety.org/2012/11/08/...
djq

Câu trả lời:


56

Tôi đã thấy kỹ thuật này được sử dụng trong quá khứ. Điều đó đã được giải thích với tôi bởi Zain Memon (từ Trulia), người đã giúp đưa ra một số thông tin đầu vào khi Michal Migurski đang tạo ra TileStache. Zain đã xem qua nó trong khi giải thích bản demo Trulia sử dụng kỹ thuật này tại một trong những cuộc họp SF GeoMeetup cũ của chúng tôi một thời gian trước đó . Trên thực tế, nếu bạn ở SF vào tuần tới (đây là nỗ lực khập khiễng của tôi tại một phích cắm, anh ấy sẽ chạm vào nó , vì vậy hãy thoải mái xuất hiện :)

OK, bây giờ để giải thích.

Đầu tiên, bạn đang nhìn hơi sai chỗ khi nhìn vào các tập tin json ở trên.

Hãy để tôi giải thích (càng ngắn càng tốt), tại sao.

Các gạch đang được thông qua giống như các gạch được kết xuất thông thường, không có vấn đề gì lớn, chúng tôi biết cách làm điều đó và vì vậy tôi không cần phải giải thích điều đó.

Nếu bạn kiểm tra nó trong Fireorms, bạn sẽ thấy rằng bạn cũng nhận được một loạt các hình ảnh dường như trống, như thế này .

Tại sao nó trống? Không phải vậy. Các pixel chứa dữ liệu - chỉ không phải dữ liệu hình ảnh hiển thị truyền thống. Họ đang sử dụng một kỹ thuật rất thông minh để truyền dữ liệu được mã hóa theo pixel.

Những gì đã diễn ra trong thập kỷ qua, là mọi người đã giao dịch với dữ liệu dễ đọc và tính di động của các định dạng với chi phí hiệu quả lưu trữ.

Lấy ví dụ này về dữ liệu mẫu xml:

<data>

  <feature>
    <point>
      <x> -32.1231 </x>
      <y> 10.31243 </y>
    </point>
    <type> 
      sold
    </type>
   </feature>

  <feature>
    <point>
      <x> -33.1231 </x>
      <y> 11.31243 </y>
    </point>
    <type> 
      available
    </type>
   </feature>

</data>

OK, có bao nhiêu vết cắn để chuyển cái này? Với điều kiện chúng tôi là utf8 (1 byte cho mỗi ký tự khi xử lý nội dung này). Chà, chúng tôi có khoảng 176 ký tự (không tính các tab hoặc khoảng trắng) tạo ra 176 byte này (điều này rất lạc quan vì nhiều lý do mà tôi sẽ bỏ qua vì đơn giản). Tâm trí bạn, đây là cho 2 điểm!

Tuy nhiên, một số người thông minh không hiểu anh ta đang nói về điều gì, ở đâu đó, sẽ cho rằng "json mang lại cho bạn sức nén cao hơn".

Tốt thôi, hãy đặt xml vô nghĩa giống như json:

{ "data": [
            "feature" : { "x" : -32.1231, "y" : 10.31243 , "type": "sold" },
            "feature" : { "x" : -33.1231, "y" :11.31243, "type": "avail" },
          ]
}

Có bao nhiêu byte ở đây? Nói ~ 115 ký tự. Tôi thậm chí đã lừa dối một chút và làm cho nó nhỏ hơn.

Giả sử rằng khu vực của tôi có 256x256 pixel và tôi ở mức thu phóng cao đến mức mỗi tính năng hiển thị dưới dạng một pixel và tôi có rất nhiều tính năng, nó đã đầy. Tôi cần bao nhiêu dữ liệu để hiển thị 65.536 tính năng?

54 ký tự (hoặc byte utf - và tôi thậm chí còn bỏ qua một số thứ khác) cho mỗi mục nhập "tính năng" nhân với x 65,536 = 3,538,944 hoặc khoảng 3,3 MB

Tôi nghĩ bạn lấy bức tranh.

Nhưng đây là cách chúng tôi vận chuyển dữ liệu trong một kiến ​​trúc hướng dịch vụ. Crap cồng kềnh có thể đọc được.

Điều gì sẽ xảy ra nếu tôi muốn vận chuyển mọi thứ trong sơ đồ nhị phân mà tôi tự phát minh ra? Thay vào đó, tôi đã mã hóa thông tin đó trong hình ảnh một dải (tức là đen trắng). Và tôi đã quyết định rằng 0 có nghĩa là được bán và 1 có nghĩa là có sẵn và 2 có nghĩa là tôi không biết. Heck, trong 1 byte, tôi có 256 tùy chọn mà tôi có thể sử dụng - và tôi chỉ sử dụng 2 hoặc ba trong số chúng cho ví dụ này.

Chi phí lưu trữ của điều đó là gì? 256x256x 1 (chỉ một băng tần). 65,536 byte hoặc 0,06MB. Và điều này thậm chí không xem xét các kỹ thuật nén khác mà tôi có được miễn phí từ nhiều thập kỷ nghiên cứu về nén hình ảnh.

Tại thời điểm này, bạn nên tự hỏi tại sao mọi người không chỉ đơn giản gửi dữ liệu được mã hóa ở định dạng nhị phân thay vì nối tiếp đến json? Đầu tiên, hóa ra, javascript hút thời gian lớn để vận chuyển dữ liệu nhị phân , vì vậy đó là lý do tại sao mọi người không làm điều này trong lịch sử.

Một số công việc tuyệt vời đã được một số người sử dụng khi các tính năng mới của HTML5 xuất hiện, đặc biệt là canvas . Vì vậy, công việc tuyệt vời này là gì? Hóa ra, bạn có thể gửi dữ liệu qua dây được mã hóa trên hình ảnh có vẻ là hình ảnh, sau đó bạn có thể chuyển hình ảnh đó vào Canvas HTML5, cho phép bạn thao tác trực tiếp với các pixel ! Bây giờ bạn có một cách để lấy dữ liệu đó, giải mã nó ở phía máy khách và tạo các đối tượng json trong máy khách.

Dừng lại một chút và suy nghĩ về điều này.

Bạn có cách mã hóa một lượng lớn dữ liệu tham chiếu địa lý có ý nghĩa ở định dạng nén cao, các đơn đặt hàng có cường độ nhỏ hơn bất kỳ thứ gì khác được thực hiện trong các ứng dụng web và thao tác chúng trong javascript.

Canvas HTML thậm chí không cần được sử dụng để vẽ, nó chỉ được sử dụng như một cơ chế giải mã nhị phân!

Đó là những gì tất cả những hình ảnh mà bạn nhìn thấy trong Fireorms là về. Một hình ảnh, với dữ liệu được mã hóa cho mỗi ô được tải xuống. Chúng siêu nhỏ, nhưng chúng có dữ liệu có ý nghĩa.

Vì vậy, làm thế nào để bạn mã hóa những thứ này ở phía máy chủ? Vâng, bạn cần phải khái quát hóa dữ liệu ở phía máy chủ và tạo một ô có ý nghĩa cho mọi mức thu phóng có dữ liệu được mã hóa. Hiện tại, để làm điều này, bạn phải tự thực hiện - một giải pháp nguồn mở ngoài hộp không tồn tại, nhưng bạn có tất cả các công cụ bạn cần để làm điều này có sẵn. PostGIS sẽ thực hiện việc khái quát hóa thông qua GEOS, TileCache có thể được sử dụng để lưu trữ bộ đệm và giúp bạn kích hoạt việc tạo các ô. Về phía máy khách, bạn sẽ cần sử dụng HTML5 Canvas để truyền "gạch giả" đặc biệt và sau đó bạn có thể sử dụng OpenLayers để tạo các đối tượng javascript phía máy khách thực sự đại diện cho các vectơ có hiệu ứng di chuột qua.

Nếu bạn cần mã hóa nhiều dữ liệu hơn, hãy nhớ rằng bạn luôn có thể tạo hình ảnh RGBA trên mỗi pixel (cung cấp cho bạn 4 byte cho mỗi pixel hoặc 4.294.967.296 số bạn có thể đại diện cho mỗi pixel ). Tôi có thể nghĩ ra một số cách để sử dụng nó :)

Cập nhật : Trả lời câu hỏi của QGIS dưới đây.

QGIS giống như hầu hết các máy tính để bàn khác , không có một mức thu phóng cố định. Chúng có tính linh hoạt thu phóng ở bất kỳ tỷ lệ nào và chỉ hiển thị. Họ có thể hiển thị dữ liệu từ WMS hoặc các nguồn dựa trên gạch không? Chắc chắn họ có thể, nhưng hầu hết thời gian họ thực sự ngớ ngẩn về điều đó: Thu phóng đến một mức độ khác, tính toán hộp giới hạn, tính toán lát gạch cần thiết, lấy chúng, hiển thị chúng. Hầu hết thời gian họ bỏ qua những thứ khác, như bộ đệm tiêu đề http sẽ làm cho nó để họ không phải tải lại. Đôi khi, họ thực hiện một cơ chế bộ đệm đơn giản (lưu trữ ô, nếu bạn yêu cầu, hãy kiểm tra ô đó, đừng yêu cầu). Nhưng điều này là không đủ.

Với kỹ thuật này, các ô và vectơ cần được nạp lại ở mọi mức thu phóng . Tại sao? Bởi vì các vectơ đã được khái quát hóa thành các mức thu phóng.

Theo như toàn bộ thủ thuật đặt các ô lên một khung vẽ HTML5 để bạn có thể truy cập vào bộ đệm, thì toàn bộ điều đó là không cần thiết. QGIS cho phép bạn viết mã bằng Python và C ++, cả hai ngôn ngữ đều hỗ trợ tuyệt vời để xử lý bộ đệm nhị phân, vì vậy công việc này thực sự không liên quan đến nền tảng này.

* CẬP NHẬT 2 **:

Có một câu hỏi về cách tạo các ô vectơ tổng quát ở vị trí đầu tiên (bé bước 1 trước khi có thể nối tiếp các kết quả thành hình ảnh). Có lẽ tôi đã không làm rõ đủ. Tilestache sẽ cho phép bạn tạo các "vectơ" dữ liệu hiệu quả ở mọi mức thu phóng (thậm chí nó còn có tùy chọn cho phép bạn cắt hoặc không cắt dữ liệu khi vượt qua ranh giới ô). Điều này quan tâm đến việc tách các vectơ thành các ô ở các mức thu phóng khác nhau. Tôi sẽ chọn tùy chọn "không clip" (nhưng nó sẽ chọn một ô tùy ý trong đó nó bao phủ nhiều diện tích hơn). Sau đó, bạn có thể cung cấp mọi vectơ thông qua tùy chọn tổng quát hóa GEOS với một số lượng lớn, trên thực tế, bạn muốn nó đủ lớn để các polylines và đa giác tự sụp đổ, bởi vì nếu có, bạn có thể loại bỏ chúng khỏi mức thu phóng từ giai đoạn đó không liên quan. Tilestache thậm chí cho phép bạn viết các nhà cung cấp dữ liệu pythonic dễ dàng, nơi bạn có thể đặt logic này. Ở giai đoạn đó, bạn có thể chọn phân phát chúng dưới dạng tệp json (giống như chúng làm với một số mẫu bản đồ châu Phi) hoặc dưới dạng hình học nối tiếp vào pngs, giống như chúng làm trong các mẫu khác (hoặc mẫu Trulia) tôi đã đưa ra ở trên.


2
Cho đến nay, mọi người mà tôi đã thấy sử dụng kỹ thuật này đều không đăng mã. IMHO, vì phần quan trọng đang thực sự xảy ra trên máy chủ và không có "tiêu chuẩn" nào cho việc này và vì việc chọn từng pixel có nghĩa là gì (1 = đã bán, 2 = tận dụng, v.v.) rất cụ thể cho bản đồ hiện tại của bạn rằng mã này là rất có thể không "chung chung".
Ragi Yaser Burhum

1
Theo như QGIS, câu trả lời có liên quan nhiều hơn một chút, tôi sẽ cập nhật câu trả lời của tôi trên đường đi làm. Đừng sợ hãi, tôi đi tàu, vì vậy không lái xe trong khi trả lời GIS.SE cho tôi :)
Ragi Yaser Burhum

12
+1 Cảm ơn bạn đã không nén phản hồi rất dễ đọc này :)
Kirk Kuykendall

1
Bạn có thể làm điều này với Silverlight hoặc Flash chắc chắn. Tuy nhiên, hãy nhớ rằng một phần quan trọng đang xảy ra trên máy chủ để Flash hoặc Silverlight sẽ không có của nhiều của một sự giúp đỡ.
Ragi Yaser Burhum

2
Bốn năm sau có nhiều điều đã phát triển và hộp văn bản này chỉ có ~ 500 ký tự để giải thích nó. Tóm tắt là WebGL đã trưởng thành và, ngoài các kỹ thuật tuần tự hóa, mọi người đã áp dụng mã hóa delta chính xác cố định (như chúng ta đã từng sử dụng trong thập niên 60) ở các định dạng như Topojson. Đây là một điều tốt . Tôi rất muốn thấy một số trong những điều này trong một tiêu chuẩn từ OGC ... tuy nhiên, chính trị xung quanh OGC gần đây rất phức tạp. Đây là cảm xúc của tôi từ hai năm trước: blog.burhum.com/post/50036141569/the-ogc-is-stuck-in-1999
Ragi Yaser Burhum

23

Trực tiếp từ nhà phát triển Dino Ravnic trên một bài đăng danh sách gửi thư gần đây :

Đó không phải là một bí mật lớn về cách chúng tôi đã làm điều đó vì vậy tôi sẽ rất vui khi chia sẻ điều đó với bạn .. chìa khóa nằm ở hai điều:

  1. loại bỏ khỏi ô tất cả các vectơ nhỏ để có thể nhìn thấy, tức là diện tích của chúng khi được tính thành pixel nhỏ hơn 1px. vì vậy chúng tôi thả một vectơ như vậy và thay vì nó đặt một pixel do đó có thuộc tính "pixel" trong ô json của chúng tôi

  2. các vectơ sẽ thực sự nhìn thấy được đang được khái quát hóa và sau đó được viết thành một ô với tọa độ của chúng bằng pixel

Trên phần máy khách, chúng tôi kết xuất trên canvas những pixel tĩnh và vectơ hiển thị. Trên đầu các vectơ, chúng tôi đã triển khai xử lý sự kiện chuột để đạt được sự lơ lửng tức là tính tương tác. và đó là nó.

Công cụ bản đồ phụ trợ của chúng tôi thực hiện tất cả các công việc nặng nhọc vì chúng tôi không sử dụng bất kỳ sự ngăn chặn nào và tất cả các ô đang được tạo ra khi đang bay. điều rất quan trọng đối với chúng tôi là có một bản đồ có thể được làm mới nhanh chóng.

Vì vậy, có vẻ như phía khách hàng là phần dễ dàng. Thật ấn tượng khi dữ liệu được hiển thị mà không có bất kỳ bộ nhớ đệm.

Ông cũng đề cập đến một dịch vụ lưu trữ có thể được bạn quan tâm. Bạn có thể muốn cân nhắc chi phí cố gắng tạo lại điều này với chi phí sử dụng một dịch vụ làm sẵn.


Điều khiến tôi bối rối ở đây là có vẻ như các yêu cầu đang được gửi tới postgis và thay vì nhận Geojson tiêu chuẩn với các giá trị lat / long trở lại, chúng dường như (trong thời gian thực) chuyển đổi các giá trị lat / long thành tọa độ xyz và phun chúng ra dựa trên mức thu phóng và gạch bản đồ cần thiết. Các bạn nghĩ gì đang được sử dụng để có được những tốc độ này?
NetConstructor.com

@netconstructor Có lẽ hình học đã được lưu trữ trong hình học xyz nên không cần chuyển đổi?
geographika

tọa độ xyz tương đối có khả năng ngắn hơn so với lat / long cần băng thông ít hơn.
Matthew Snape

đúng nhưng họ đang chuyển đổi dữ liệu đó một cách nhanh chóng
NetConstructor.com

17

Như tôi đã mô tả trong danh sách OSGeo, chìa khóa là trong việc cung cấp dữ liệu dưới dạng các ô vector JSON có các pixel cho hình học subpixel và hình học tổng quát cho các tính năng đó sẽ thực sự hiển thị ở một mức độ nhất định. Hiệu suất là tuyệt vời vì kỹ thuật này giúp loại bỏ tất cả thông tin vectơ không cần thiết và chỉ để lại những vectơ thực sự sẽ có tác động trực quan trên bản đồ. Các pixel ở đó để lấp đầy các khoảng trống và được đặt thay vì các vectơ subpixel đó. Đó là nó liên quan đến định dạng gạch.

Về phía phụ trợ là nâng nặng thực sự. Chúng tôi không sử dụng TileStache hoặc bất kỳ công cụ bản đồ nào khác kể từ khi chúng tôi tự viết, có thể, với một số tối ưu hóa, tạo ra đồ họa vector như vậy trong thời gian thực.

Đầu tiên chúng tôi bắt đầu với việc phân phối các lát bản đồ dưới dạng SWF và gần đây chúng tôi chỉ kích hoạt đầu ra cho JSON để chúng tôi có thể sử dụng HTML5 Canvas để kết xuất đồ họa. Bạn có thể tìm thấy bên dưới điểm chuẩn so sánh loại công nghệ vectơ này với công nghệ raster (mapnik). Để so sánh công bằng chỉ tìm kết quả trong chế độ CGI.

http://www.giscloud.com/blog/realtime-map-tile-rendering-benchmark-rasters-vs-vector/

Chúng tôi đang lên kế hoạch cung cấp công nghệ này như một dịch vụ lưu trữ gạch bản đồ. Ý tưởng là lưu trữ dữ liệu địa lý của bạn trên đám mây và thông qua HTML5 cung cấp dữ liệu đó cho bất kỳ ứng dụng khách bản đồ nào ở tốc độ cao mà không cần phải xử lý trước các ô. Nếu bạn muốn tham gia bản beta này, vui lòng liên hệ với chúng tôi tại đây: http://www.giscloud.com/contact/


1
Ý tưởng sử dụng gạch cho dữ liệu vectơ rất thú vị (có vẻ như một từ ngữ khác cho "lập chỉ mục không gian"). Làm thế nào để bạn đối phó với các tính năng vượt qua một số gạch? Họ có bị cắt không?
julien

3
vâng, vectơ được kẹp vào gạch
Dino Ravnic

14

Có vẻ như một câu hỏi tương tự gần đây đã được hỏi trên diễn đàn Lớp mở OSGeo , với các nhà phát triển GIS Cloud mô tả cách tiếp cận của họ, đây là sự pha trộn thú vị của hình học GeoJSON và pixel tĩnh. Họ thực sự tạo ra tất cả các ô vectơ một cách nhanh chóng thay vì sử dụng bộ đệm được tạo sẵn của các tệp GeoJSON.

Esri đã thực hiện một cách tiếp cận tương tự, sử dụng ArcGIS Server và Feature Layer , có thể khái quát hóa hình học khi đang bay và gửi chúng qua dây dưới dạng JSON.

Đối với một phương pháp chuyển tiếp thẳng mà bạn thực sự có thể thực hiện ngay bây giờ, bạn có thể xây dựng các vectơ bằng Tilestache (có hỗ trợ PostGIS ) và sử dụng chúng trong Polymaps . Polymaps sử dụng SVG, nhưng hiệu suất khá tốt và CSS tuân thủ các yếu tố bản đồ, do đó việc hiển thị tính năng hoàn toàn phụ thuộc vào bạn. Đây là một bài viết blog làm việc thông qua một cái gì đó tương tự như những gì bạn đang yêu cầu.


1
@wwnick - Cảm ơn câu trả lời của bạn nhưng có vẻ như GisCloud.com đang sử dụng một số phương pháp bổ sung cho phép chúng có sức mạnh xử lý tuyệt vời như vậy mà không phải lưu trữ các yếu tố có nghĩa là mọi thứ đều là thời gian thực. Tôi đã thêm một tiền thưởng cho câu hỏi và hy vọng bạn có thể sẵn sàng tham gia cung cấp một giải pháp chuyên sâu. Cảm ơn phản hồi của bạn cho đến nay!
NetConstructor.com

6

Tôi đã chơi với OpenLayers bằng Canvas và nhận được kết quả hợp lý.

Như đã đề cập trong các câu trả lời khác: để phân phối và hiển thị các vectơ một cách nhanh chóng - chúng cần được khái quát hóa cho từng mức thu phóng và từng tập dữ liệu. Ngoài ra, bạn có thể sử dụng mã hóa đa tuyến của Google để giảm kích thước đáng kể.

Tôi đã sử dụng một cơ chế giao hàng đơn giản. Mỗi hình học là một hàm JavaScript trong phản hồi HTTP HTTP. không tiên tiến như phân phối véc tơ dựa trên gạch, nhưng đơn giản và Nguồn mở!

Tôi đã không dùng thử Google Maps v3 với Canvas, nhưng đã thấy một vài bản demo của Thời báo New York rất ấn tượng.


Vấn đề với cách tiếp cận này là nó không nhanh như giải pháp của họ khi xử lý 500.000 đa giác và tức là hiệu suất thực sự rất tệ
NetConstructor.com

xin vui lòng chú ý tiền thưởng thêm và nếu bạn có thể vui lòng cung cấp một giải pháp chi tiết. BTW Thời báo New York trong khi rất tuyệt vời sử dụng đèn flash không giống như giải pháp mà giscloud.com đang sử dụng.
NetConstructor.com

liên kết của bạn đang ngoại tuyến
NetConstructor.com

Đúng, xin lỗi về điều đó - "sở thích" của tôi giờ đã kết thúc sau 4 năm mày mò với đa giác! GISCloud cho bạn thấy công nghệ đã đi được bao xa kể từ khi bản demo điều tra dân số của tôi ra mắt cách đây vài năm ... Tôi đã xóa các tham chiếu đến nó trong nhận xét trên.
trừ34

1
Dù sao thì thà muộn còn hơn không! Tôi đã cập nhật mọi thứ ở mức "vượt trội" nhất có thể và đăng mã phía máy khách lên GitHub . Thiết lập cho mã mới đã được viết blog . Hiện tại, nó đọc các đa giác trực tiếp từ PostGIS và áp dụng việc làm mỏng thông qua Khung dịch vụ Web RESTful của PostGIS ( PRWSF ) cho máy khách API API của Leaflet. Hầu như không cần mã hóa phụ trợ!
trừ34

6

Tôi không biết chính xác giải pháp nào được sử dụng bởi công ty này (bạn có thể hỏi họ trực tiếp) nhưng tôi có một ý kiến.

Giải pháp chính để cải thiện tốc độ truyền và tốc độ kết xuất của dữ liệu vectơ là tổng quát hóa chúng theo mức thu phóng: Truyền và kết xuất ở mức thu phóng cao, hàng nghìn đối tượng được thiết kế cho mức thu phóng thấp hơn nhiều thường rất tốn thời gian (và cũng vô dụng vì màn hình cuối cùng thường không rõ ràng - xem ví dụ hình ảnh này ). Để thực hiện điều đó, cơ sở dữ liệu máy chủ postgis của bạn phải có nhiều tỷ lệ : Đối với mỗi mức thu phóng, cần có một đại diện của đối tượng phù hợp với mức thu phóng này. Các biểu diễn khác nhau này có thể được tính toán tự động bằng cách sử dụng các kỹ thuật tổng quát hóa. Hơn nữa, dữ liệu vectơ được máy chủ gửi đến máy khách không chỉ phụ thuộc vào phần mở rộng không gian mà còn phụ thuộc vào mức thu phóng: Máy chủ gửi dữ liệu phù hợp tùy thuộc vào mức thu phóng. Đây là cách tiếp cận được bảo vệ trong bài báo xuất sắc này :-)


0

Có một bài báo thú vị, một bản demo và mã nguồn của một phần mềm được phát triển bởi Stanford Visualization Group sử dụng datacube cho mỗi ô để trực quan hóa và khám phá một bộ dữ liệu địa lý lớn. Nó chỉ có thể được sử dụng cho dữ liệu điểm nhưng có thể là một cách thú vị.

http://vis.stanford.edu/ con / intens

Vizzuality với nền tảng CartoDB của họ và thư viện có tên Torque cũng đang thử nghiệm bằng cách nào đó làm thế nào để thu được khối lượng dữ liệu cao.

http://cartodb.github.io/torque/
https://github.com/CartoDB/torque/tree/new_torque

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.