Membuat Vektor Poligon dengan kinerja rendering seperti GISCloud?

Saya telah mencari solusi yang solid yang akan memungkinkan saya untuk membuat peta web dan overlay poligon vektor tanpa mengambil selamanya untuk memuat data tersebut dengan tujuan memungkinkan saya untuk membuat setiap poligon menampilkan warna yang berbeda pada acara melayang.

Sejauh yang saya ketahui ada 3 opsi spesifik untuk mencapai ini melalui kanvas, SVG, Flash.

Flash sepertinya itu akan menjadi solusi terbaik jika itu akan berfungsi pada iPhone / iPad apel karena tampaknya memberikan tampilan rendering tercepat dan terbersih. Kanvas tampaknya menjadi pilihan terbaik kedua tetapi membutuhkan waktu SANGAT lama jika Anda memiliki ratusan poligon yang ditampilkan di peta sedangkan SVG membutuhkan waktu lebih lama untuk di-render.

Saya hampir kehilangan harapan untuk menemukan solusi untuk masalah ini, tetapi hari ini saya menemukan perusahaan bernama GISCloud http://www.giscloud.com (saat ini dalam versi beta dengan pendaftaran gratis).

Perusahaan ini telah SOMEHOW berhasil menemukan cara yang luar biasa untuk membuat ratusan vektor pada peta dalam waktu dekat. Saya kagum dengan pendekatan mereka dan pertanyaan saya kepada masyarakat terkait dengan bagaimana kita dapat meniru pendekatan mereka untuk digunakan dengan teknologi yang ada seperti selebaran, pembuka, lilin ...

Lihatlah sendiri dengan melihat demo luar biasa ini: http://www.giscloud.com/map/284/africa

Pastikan Anda mengarahkan kursor ke salah satu poligon di halaman dan menguji kontrol zoom untuk melihat bahwa poligon ini memang vektor.

Apa yang saya perhatikan dengan melihat permintaan dengan firebug adalah bahwa peta tersebut meminta file json tertentu. Tampaknya tergantung pada level / area pembesaran ada beberapa file json yang diminta.

Saya juga harus menyebutkan di sini bahwa sekali giscloud memuat data pada halaman yang melayang di atas vektor segera mengubah warna tanpa membuat permintaan baru.

CONTOH:

• http://cft1.giscloud.com/t/1316509973/map284/layer1156/3/3/3.json
• http://cft1.giscloud.com/t/1316509973/map284/layer1156/3/5/3.json
• http://cft1.giscloud.com/t/1316509973/map284/layer1156/3/4/4.json
• http://cft1.giscloud.com/t/1316509973/map284/layer1156/3/3/4.json
• http://cft1.giscloud.com/t/1316509973/map284/layer1156/3/5/4.json

Saya mengasumsikan struktur url mengikuti logika layanan ubin standar (misalnya folder ke-3 ke terakhir adalah tingkat zoom ...).

Bagaimanapun saya telah menganalisis data aktual dari file-file json ini dan tampaknya logika yang mereka gunakan mengikuti beberapa jenis logika yang dengannya mereka membuat vektor hanya berdasarkan nilai-nilai data ini:

• width / height: mereka menentukan lebar dan tinggi data yang dilayani di setiap permintaan json
• piksel: di sini mereka menentukan nilai piksel yang saya asumsikan terkait dengan beberapa koordinat piksel x / y umum untuk tingkat titik umum? Saya kira mereka entah bagaimana memiliki cara menyederhanakan wilayah secara otomatis tergantung pada tingkat zoom. Saya berasumsi oleh mereka menggunakan koordinat piksel Saya kira mereka secara dramatis mengurangi ukuran data yang perlu dimuat dibandingkan dengan data lat / panjang.
• styles: di sini mereka mendefinisikan dua nilai RGB css. "F" mewakili warna file poligon dan "S" mewakili warna batas poligon.
• geom: di sinilah saya menebak mereka entah bagaimana mendefinisikan secara spesifik mendefinisikan setiap poligon di dalam ubin yang dimuat di mana data tersebut sedang ditentukan berdasarkan dari jendela wadah peta. Yang juga menarik adalah bahwa setiap entri memiliki nilai "S" yang saya asumsikan digunakan sebagai atribut opsional atau nilai tautan fitur dan pada akhir setiap entri di sini ada area yang tampaknya mendefinisikan spesifik per vektor ID bersama dengan ID lapisan yang saya tebak digunakan entah bagaimana untuk bergabung dengan data dari setiap permintaan ubin json dipanggil.

Saya juga berasumsi mereka entah bagaimana menemukan cara untuk secara otomatis menentukan dan membagi data yang perlu dimuat untuk setiap ubin tergantung pada ukuran data yang perlu dimuat untuk ubin yang diminta.

Berikut ini rincian yang diekstraksi dari salah satu permintaan ini:

{"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"},
{...}
...
]
}

Bagaimana kita bisa meniru jenis kecepatan yang sama (atau serupa) menggunakan postgis (yang saya juga terlihat seperti apa yang mereka gunakan)?

Saya telah melihat teknik ini digunakan di masa lalu. Itu dijelaskan kepada saya oleh Zain Memon (dari Trulia) yang membantu memberikan beberapa masukan ketika Michal Migurski menciptakan TileStache. Zain membahasnya sambil menjelaskan demo Trulia-nya yang menggunakan teknik ini di salah satu pertemuan SF GeoMeetup lama kami beberapa waktu lalu . Bahkan, jika Anda berada di SF minggu depan (ini adalah usaha timpang saya di colokan, dia akan menyentuh ini , jadi jangan ragu untuk muncul :)

OK, sekarang penjelasannya.

Pertama, Anda mencari sedikit di tempat yang salah ketika melihat file json di atas.

Biarkan saya jelaskan (sesingkat mungkin), mengapa.

Ubin-ubin itu disahkan seperti ubin yang diberikan biasa, bukan masalah besar di sana, kita tahu bagaimana melakukan itu dan jadi saya tidak perlu menjelaskannya.

Jika Anda memeriksanya di Firebug, Anda akan melihat bahwa Anda juga mendapatkan sejumlah besar gambar yang tampaknya kosong, seperti ini .

Kenapa itu kosong? Bukan itu. Pixel berisi data - tidak hanya data gambar terlihat tradisional. Mereka menggunakan teknik yang sangat pintar untuk melewatkan data yang dikodekan dalam piksel itu sendiri.

Apa yang telah terjadi dalam dekade terakhir, adalah bahwa orang-orang telah memperdagangkan data keterbacaan dan portabilitas dari format dengan mengorbankan efisiensi penyimpanan.

Ambil contoh data sampel xml ini:

<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, berapa banyak gigitan untuk mentransfer ini? Asalkan kita utf8 (1 byte per karakter saat berurusan dengan konten ini). Yah, kami memiliki sekitar 176 karakter (tanpa menghitung tab atau spasi) yang membuat 176 byte ini (ini menjadi optimis karena berbagai alasan yang saya akan hilangkan demi kesederhanaan). Pikiran Anda, ini untuk 2 poin!

Namun, beberapa keledai cerdas yang tidak mengerti apa yang dia bicarakan, di suatu tempat, akan mengklaim bahwa "json memberi Anda kompresi yang lebih tinggi".

Baik, mari kita letakkan xml omong kosong yang sama dengan json:

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

Berapa byte di sini? Katakan ~ 115 karakter. Aku bahkan sedikit curang dan membuatnya lebih kecil.

Katakanlah area saya mencakup 256x256 piksel dan saya berada pada level zoom yang sangat tinggi sehingga setiap fitur dirender sebagai satu piksel dan saya memiliki begitu banyak fitur, sehingga penuh. Berapa banyak data yang saya perlukan untuk menunjukkan bahwa 65.536 fitur?

54 karakter (atau utf byte - dan saya bahkan mengabaikan beberapa hal lain) per entri "fitur" dikalikan x 65.536 = 3.538.944 atau sekitar 3,3MB

Saya pikir Anda mendapatkan fotonya.

Tapi ini adalah cara kami mengangkut data dalam arsitektur berorientasi layanan. Omong kosong yang mudah dibaca.

Bagaimana jika saya ingin mengangkut semuanya dalam skema biner yang saya temukan sendiri? Katakan itu sebagai gantinya, saya menyandikan informasi itu dalam gambar band tunggal (yaitu hitam dan putih). Dan saya memutuskan bahwa 0 berarti dijual, dan 1 berarti tersedia, dan 2 berarti saya tidak tahu. Heck, dalam 1 byte, saya punya 256 opsi yang bisa saya gunakan - dan saya hanya menggunakan 2 atau tiga dari mereka untuk contoh ini.

Berapa biaya penyimpanan itu? 256x256x 1 (hanya satu band). 65.536 byte atau 0,06MB. Dan ini bahkan tidak mempertimbangkan teknik kompresi lain yang saya dapatkan secara gratis dari beberapa dekade penelitian dalam kompresi gambar.

Pada titik ini, Anda harus bertanya pada diri sendiri mengapa orang tidak hanya mengirim data yang disandikan dalam format biner alih-alih membuat serial ke json? Yah pertama-tama, ternyata, javascript menyebalkan waktu besar untuk mengangkut data biner , jadi itu sebabnya orang tidak melakukan ini secara historis.

Sebuah karya yang luar biasa telah digunakan oleh beberapa orang ketika fitur-fitur baru HTML5 keluar, khususnya kanvas . Jadi apa yang bisa dilakukan? Ternyata, Anda dapat mengirim data melalui kabel yang dikodekan pada apa yang tampak sebagai gambar, lalu Anda dapat mendorong gambar itu ke dalam Kanvas HTML5, yang memungkinkan Anda untuk memanipulasi piksel secara langsung ! Sekarang Anda memiliki cara untuk mengambil data itu, mendekodekannya di sisi klien, dan menghasilkan objek json di klien.

Berhentilah sejenak dan pikirkan hal ini.

Anda memiliki cara untuk menyandikan sejumlah besar data geo-referensi bermakna dalam format yang sangat terkompresi, urutan besarnya lebih kecil dari apa pun yang dilakukan secara tradisional dalam aplikasi web, dan memanipulasi mereka dalam javascript.

Kanvas HTML bahkan tidak perlu digunakan untuk menggambar, itu hanya digunakan sebagai mekanisme decoding biner!

Itulah semua gambar yang Anda lihat di Firebug. Satu gambar, dengan data yang disandikan untuk setiap ubin yang diunduh. Mereka super kecil, tetapi mereka memiliki data yang bermakna.

Jadi, bagaimana Anda menyandikan ini di sisi server? Anda perlu menggeneralisasi data di sisi server, dan membuat ubin yang berarti untuk setiap level zoom yang memiliki data yang dikodekan. Saat ini, untuk melakukan ini, Anda harus memutar sendiri - solusi open source di luar kotak tidak ada, tetapi Anda memiliki semua alat yang Anda butuhkan untuk melakukan ini tersedia. PostGIS akan melakukan generalisasi melalui GEOS, TileCache dapat digunakan untuk melakukan cache dan membantu Anda memicu pembuatan ubin. Di sisi klien, Anda harus menggunakan HTML5 Canvas untuk meneruskan "ubin palsu" khusus dan kemudian Anda dapat menggunakan OpenLayers untuk membuat objek javascript sisi klien nyata yang mewakili vektor dengan efek mouse-over.

Jika Anda perlu menyandikan lebih banyak data, ingatlah bahwa Anda selalu dapat menghasilkan gambar RGBA per piksel (yang memberi Anda 4 byte per piksel atau 4.294.967.296 angka yang dapat Anda wakili per piksel ). Saya dapat memikirkan beberapa cara untuk menggunakannya :)

Pembaruan : Menjawab pertanyaan QGIS di bawah ini.

QGIS seperti kebanyakan GIS Desktop lainnya , tidak memiliki tingkat zoom yang ditetapkan. Mereka memiliki fleksibilitas zoom pada skala apa pun dan hanya membuat. Bisakah mereka menampilkan data dari WMS atau sumber berbasis ubin? Tentu mereka bisa, tetapi sebagian besar waktu mereka benar-benar bodoh tentang hal itu: Memperbesar ke tingkat yang berbeda, menghitung kotak pembatas, menghitung ubin yang diperlukan, ambil mereka, tunjukkan. Sebagian besar waktu mereka mengabaikan hal-hal lain, seperti cache header http yang akan membuatnya jadi mereka tidak perlu mengambil ulang. Kadang-kadang mereka menerapkan mekanisme cache sederhana (menyimpan ubin, jika Anda memintanya, periksa ubin, jangan memintanya). Tetapi ini tidak cukup.

Dengan teknik ini ubin dan vektor perlu dibuat ulang di setiap tingkat zoom . Mengapa? Karena vektor telah digeneralisasi untuk mengakomodasi level zoom.

Sejauh seluruh trik menempatkan ubin ke kanvas HTML5 sehingga Anda dapat mengakses buffer, semuanya tidak diperlukan. QGIS memungkinkan Anda untuk menulis kode dalam Python dan C ++, kedua bahasa memiliki dukungan yang sangat baik untuk menangani buffer biner, sehingga pekerjaan ini benar-benar tidak relevan untuk platform ini.

* PEMBARUAN 2 **:

Ada pertanyaan tentang cara membuat ubin vektor umum di tempat pertama (langkah bayi 1 sebelum bisa membuat serial hasil menjadi gambar). Mungkin saya tidak cukup menjelaskan. Tilestache akan memungkinkan Anda membuat "ubin vektor" yang efektif dari data Anda di setiap level zoom (bahkan memiliki opsi yang memungkinkan Anda untuk klip atau tidak klip data ketika melewati batas ubin). Ini menangani pemisahan vektor ke ubin di berbagai tingkat zoom. Saya akan memilih opsi "not clip" (tetapi akan memilih ubin sewenang-wenang di mana ia mencakup lebih banyak wilayah). Kemudian Anda dapat memberi makan setiap vektor melalui opsi generalisasi GEOS dengan jumlah besar, pada kenyataannya, Anda menginginkannya cukup besar sehingga polylines dan polygon runtuh ke dirinya sendiri, karena jika mereka melakukannya, Anda dapat menghapusnya dari level zoom karena untuk tahap itu mereka tidak relevan. Tilestache bahkan memungkinkan Anda untuk menulis penyedia data pythonic yang mudah di mana Anda dapat menempatkan logika ini. Pada tahap itu, Anda dapat memilih untuk menyajikannya sebagai file json (seperti yang mereka lakukan dengan beberapa sampel peta Afrika) atau sebagai geometri berseri ke png, seperti yang mereka lakukan pada sampel lain (atau yang Trulia) yang saya berikan di atas.

Langsung dari pengembang Dino Ravnic di pos milis terbaru :

Bukan rahasia besar bagaimana kami melakukannya sehingga saya akan dengan senang hati berbagi dengan Anda..kuncinya ada dalam dua hal:

1. menghapus dari ubin semua vektor yang kecil agar terlihat yaitu daerah mereka ketika dihitung menjadi piksel kurang dari 1px. jadi kita menjatuhkan vektor seperti itu dan bukannya menempatkan pixel maka ada properti "piksel" di ubin json kami

2. vektor yang akan benar-benar terlihat sedang digeneralisasi dan kemudian ditulis ke dalam ubin dengan koordinatnya dalam piksel

Pada bagian klien, kami membuat piksel statis dan vektor yang terlihat di atas kanvas. Di atas vektor kami menerapkan penanganan acara mouse untuk mencapai melayang yaitu interaktivitas. dan hanya itu.

Mesin peta backend kami melakukan semua pengangkatan berat karena kami tidak menggunakan pengintaian dan semua ubin dihasilkan dengan cepat. sangat penting bagi kami untuk memiliki peta yang dapat di-refresh dengan cepat.

Jadi sepertinya sisi klien adalah bagian yang mudah. Sangat mengesankan bahwa data ditampilkan tanpa caching.

Dia juga menyebutkan layanan hosting yang mungkin menarik bagi Anda. Anda mungkin ingin mempertimbangkan biaya untuk mencoba membuat ulang ini dengan biaya menggunakan layanan yang sudah jadi.

Seperti yang saya jelaskan pada daftar OSGeo kuncinya adalah dalam memberikan data sebagai ubin JSON vektor yang memiliki piksel untuk geometri subpiksel dan geometri umum untuk fitur-fitur yang akan benar-benar terlihat pada tingkat tertentu. Performa hebat karena teknik ini menghilangkan semua informasi vektor yang tidak perlu dan hanya menyisakan vektor yang benar-benar akan memiliki dampak visual pada peta. Pixel ada untuk mengisi celah dan ditempatkan bukan vektor subpixel tersebut. Itu tentang format ubin.

Di sisi backend adalah benar-benar berat. Kami tidak menggunakan TileStache atau mesin peta lainnya karena kami menulis sendiri yang dapat, dengan sejumlah optimasi, menghasilkan grafik vektor seperti itu secara real-time.

Pertama kami mulai dengan mengirimkan petak peta sebagai SWF dan akhir-akhir ini kami hanya mengaktifkan output ke JSON sehingga kami dapat menggunakan HTML5 Canvas untuk membuat grafik. Anda dapat menemukan di bawah benchmark yang membandingkan teknologi vektor semacam ini dengan teknologi raster (mapnik). Untuk perbandingan yang adil, hanya mencari hasil dalam mode CGI.

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

Kami berencana untuk menyediakan teknologi ini sebagai layanan hosting ubin peta. Idenya adalah untuk meng-host data geo Anda di cloud dan melalui HTML5 mengirimkannya ke klien peta mana pun dengan kecepatan tinggi, tanpa perlu memprioritaskan ubin. Jika Anda tertarik untuk bergabung dengan beta ini, jangan ragu untuk menghubungi kami di sini: http://www.giscloud.com/contact/

Sepertinya pertanyaan yang sangat mirip baru-baru ini diajukan di forum OSGeo Open Layers , dengan pengembang GIS Cloud menjelaskan pendekatan mereka, yang merupakan campuran menarik dari geometri GeoJSON dan piksel statis. Mereka benar-benar menghasilkan semua ubin vektor dengan cepat alih-alih menggunakan cache GeoJSON yang sudah dibangun sebelumnya.

Esri telah menerapkan pendekatan serupa, menggunakan ArcGIS Server dan Feature Layers , yang dapat menggeneralisasi geometri dengan cepat dan mengirimkannya melalui kawat sebagai JSON.

Untuk metode langsung yang benar-benar dapat Anda terapkan sekarang, Anda dapat membangun petak vektor dengan Tilestache (yang memiliki dukungan PostGIS ) dan mengkonsumsinya dalam Polymaps . Polymaps menggunakan SVG, tetapi kinerjanya cukup baik , dan itu aturan CSS untuk gaya elemen peta, sehingga rendering fitur sepenuhnya terserah Anda. Berikut adalah posting blog yang mengerjakan sesuatu yang mirip dengan apa yang Anda minta.

Saya bermain dengan OpenLayers menggunakan Canvas dan mendapatkan hasil yang masuk akal.

Seperti disebutkan dalam jawaban lain: untuk mengirim dan menampilkan vektor dengan cepat - mereka perlu digeneralisasi untuk setiap level zoom dan setiap dataset. Anda juga dapat menggunakan pengodean polyline Google untuk mengurangi ukurannya secara signifikan.

Saya menggunakan mekanisme pengiriman sederhana. Setiap geometri adalah fungsi JavaScript dalam respons HTTP JavaScript. tidak semaju pengiriman vektor berbasis ubin, tetapi sederhana dan Open Source!

Saya tidak bisa mencoba Google Maps v3 dengan Canvas, tetapi telah melihat beberapa demo New York Times yang mengesankan.

Saya tidak tahu persis solusi mana yang digunakan oleh perusahaan ini (Anda mungkin bisa bertanya langsung kepada mereka) tetapi saya punya ide.

Solusi utama untuk meningkatkan transfer jaringan dan kecepatan rendering data vektor adalah menggeneralisasikannya sesuai dengan tingkat zoom: Mentransfer dan merender pada tingkat zoom tinggi ribuan objek yang dirancang untuk tingkat zoom jauh lebih rendah seringkali sangat memakan waktu (dan juga tidak berguna karena tampilan akhir biasanya tidak terbaca - lihat misalnya gambar ini ). Untuk mengimplementasikannya, database server postgis Anda harus multi-skala : Untuk setiap level zoom, harus ada satu representasi objek yang cocok untuk level zoom ini. Representasi yang berbeda ini dapat dihitung secara otomatis menggunakan teknik generalisasi. Selain itu, data vektor yang dikirim oleh server ke klien tidak hanya bergantung pada perluasan spasial, tetapi juga pada tingkat zoom: Server mengirimkan data yang sesuai tergantung pada tingkat zoom. Ini adalah pendekatan yang dipertahankan dalam makalah yang luar biasa ini :-)

Ada kertas yang menarik, demo dan kode sumber dari perangkat lunak yang dikembangkan oleh Stanford Visualization Group yang menggunakan datacube untuk setiap ubin untuk memvisualisasikan dan mengeksplorasi dataset geografis yang besar. Ini dapat digunakan hanya untuk dataset titik tetapi bisa menjadi cara yang menarik.

http://vis.stanford.edu/papers/immens

Vizzualitas dengan platform CartoDB mereka dan perpustakaan yang disebut Torque juga bereksperimen bagaimana cara menggambar data volume tinggi.

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