30.000 titik data ... dapatkah ini dilayani secara wajar menggunakan openlayer?

Saya mencoba mengatasi masalah SIG web dan perlu mencari tahu strategi terbaik. Saya memiliki peta dengan 30.000 sel di atasnya membentuk kisi-kisi untuk provinsi Alberta. Saya memiliki daftar titik data untuk setiap sel - sekitar 50 bidang indikator dan nilai untuk setiap sel. Sebagai contoh, satu nilai mungkin populasi manusia, sehingga setiap sel akan memiliki nilai populasi manusia untuk sel itu. Saya ingin membuat peta interaktif yang dapat menunjukkan nilai-nilai itu secara visual baik dengan kotak untuk sel, atau jenis tampilan peta panas campuran. Lebih dari itu, saya ingin dapat membuat perhitungan majemuk pada semua titik data dan menggunakan perhitungan itu untuk membuat peta tambahan. Mempertimbangkan perhitungan, ada sekitar 300.000 permutasi pada peta. Terlebih lagi, itu juga temporal; ada 16 irisan waktu yang berbeda.

Strategi saya sejauh ini:

1) Di sisi server, hitung nilai sel secara dinamis pada waktu berjalan dan kirim nilai ke klien (semuanya 30.000 di antaranya). Ini menerjemahkan kira-kira nilai untuk setiap persegi 3x3 piksel dalam gambar 525px x 525px di layar.

2) Di sisi klien dengan lapisan terbuka, gunakan png 1px yang dapat diubah ukurannya dan minta nilai alfa disesuaikan sesuai kebutuhan untuk menampilkan gradien warna yang berbeda sesuai dengan nilai data untuk setiap sel. Png akan diubah ukurannya saat peta memperbesar atau memperkecil. Secara teoritis mereka akan diposisikan secara tepat untuk membentuk cakupan selimut peta sebagai kuadrat atau menggunakan pendekatan peta panas mereka akan tumpang tindih satu sama lain untuk membentuk cakupan selimut.

Pertanyaan:

Apakah masuk akal untuk menghitung nilai-nilai sel secara dinamis di server dan kemudian mengirim ke antarmuka OpenLayers secara real time? Saya yakin server dapat melakukan perhitungan, tetapi bisakah OpenLayers secara wajar menampilkan 30.000 titik data pada suatu waktu di peta? Apakah masuk akal untuk berharap dapat membuat cakupan selimut menggunakan data titik? Saya kira saya sedang mencoba untuk membuat yang setara dengan peta vektor yang memiliki 30.000 bentuk memberikan cakupan selimut 100% dari peta, tetapi menggunakan data titik untuk menyederhanakannya.

Strategi alternatif dalam pikiran saya adalah:

a) untuk menghasilkan peta secara real time di server dan mengirim layer raster ke klien

b) untuk menghasilkan semua permutasi sebelumnya dan menyimpannya di server sebagai peta raster

Adakah pikiran? Apakah pendekatan saya jauh dan menggonggong pohon yang salah? Adakah saran tentang metode yang lebih baik?

Saya pasti akan menghargai setiap pemikiran tentang masalah ini! Jika Anda tertarik, saya bahkan mungkin ingin mengontrak pengembang untuk membantunya.

Terima kasih banyak!

Nuh

Pertanyaan-pertanyaan ini telah ditanyakan beberapa kali. 30k poin, lurus ke atas, tidak akan berfungsi pada peta OL. Atau bahkan pada peta Flash / Silverlight.

Urutan angka kasar yang kasar untuk diingat - 100 poin pada peta JS (pembuka), 1.000 poin dalam Peta Flash (mis. ArcGIS Flash atau Silverlight), 10.000 poin pada aplikasi desktop (ArcGIS Desktop) adalah performa terbaik Anda level. Ini adalah poin "aktual", tidak disembunyikan atau dipalsukan seperti diuraikan di bawah ini.

Tidak hanya itu, itu tidak terlalu baik untuk berinteraksi dengan poin 30k. Bagaimana cara mengakses marker "yang" di belakang marker lain?

Anda memiliki 2 opsi:

1) Buat raster, seperti yang Anda sebutkan, di server. Sajikan layanan WMS dan ketika pengguna Anda mengklik / mengarahkan sesuatu, kembali ke server untuk mendapatkan data

2) Kurangi # poin yang Anda tampilkan. Terutama melalui pengelompokan SERVER-SIDE dan juga melalui pemangkasan kotak pembatas. Pengelompokan sisi klien "ok" dan "lucu" tetapi tidak akan membantu Anda pada 30k poin. Itu akan lambat. Jadi Anda mengatur lapisan Anda dengan strategi bbox dan OL akan membuat panggilan ke server di pan / zoom untuk Anda, dan Anda mengembalikan set data baru yang dipangkas ke titik di mana Anda mengembalikan kurang dari 100-300 poin.

Dari sudut pandang UI dan UX, 30.000 titik individual pada peta bukanlah representasi terbaik dari data Anda.

Anda juga dapat memilih untuk menggunakan kisi UTF8 di atas data titik raster Anda. Namun, resolusi grid Anda dan jumlah poin pasti akan membuat pemilihan data sangat tidak terduga dan bukan UX terbaik. http://mapbox.com/developers/utfgrid/

Kombinasi OL Clusters dengan UTF8 Grids akan menarik. Ini dapat dilakukan oleh beberapa pengelompokan ukuran server data yang mengembalikan cluster raster daripada yang kemudian dapat dipilih melalui penggunaan Grid UTF8. Pilihan manipulasi Anda melewati titik ini mungkin untuk memperbesar lebih jauh (seperti dalam metode pengelompokan vektor sisi klien klasik seperti di OL). Anda mungkin juga ingin memproses beberapa data seperti menghitung nilai rata-rata di dalam kluster itu dan menyajikannya kepada pengguna.

Seperti yang telah disebutkan 30.000 fitur melalui OL adalah ide yang sangat buruk. Saya telah mengelola 10.000 poin menggunakan rendering kanvas di Chrome dan itu berkinerja baik, tetapi beralih ke marker grafis (.png) menyebabkannya merayap.

Saya hanya ingin memberikan saran untuk pendekatan sisi server Anda. Jelas Anda tidak dapat melakukan pra-hasilkan semua 300.000 permutasi di muka, dan ruang lingkup Anda pada akhirnya akan tumbuh. Jika Anda ingin menggunakan WMS dengan SLD Anda dapat menggunakan pendekatan berikut untuk menghasilkan peta apa pun.

Klien (misalnya OpenLayers) membuat permintaan gambar WMS ke server. URL untuk permintaan menyertakan parameter ...&SLD=http://app-server/sld?time=2010&measure=population...- di sini parameter SLD adalah URL (yang harus dikodekan-URL) untuk menghasilkan SLD saat itu juga. Ketika server WMS mendapatkan permintaan Anda, ia meminta server aplikasi Anda untuk SLD unik dan mendapat respons XML. Ini kemudian menghasilkan permutasi mana pun yang diminta pengguna Anda.

Saya sudah melakukan ini dengan GeoServer untuk WMS dan PHP menghasilkan SLD dan kinerja baik-baik saja (tapi kemudian saya tidak punya alasan mengapa tidak, situasi Anda mungkin berbeda).