การสร้าง Vector Polygons ด้วยประสิทธิภาพการแสดงผลเช่น GISCloud?

ฉันกำลังมองหาวิธีแก้ปัญหาที่มั่นคงซึ่งจะทำให้ฉันสามารถสร้างแผนที่เว็บและรูปหลายเหลี่ยมเวกเตอร์ซ้อนทับโดยไม่ต้องโหลดข้อมูลดังกล่าวตลอดไปโดยมีเป้าหมายที่จะทำให้ฉันสามารถสร้างรูปหลายเหลี่ยมแต่ละสีในเหตุการณ์โฮเวอร์

เท่าที่ฉันทราบมี 3 ตัวเลือกเฉพาะเพื่อให้บรรลุสิ่งนี้ผ่านทั้งผ้าใบ SVG และแฟลช

ดูเหมือนว่า Flash จะเป็นทางออกที่ดีที่สุดหากใช้กับ apple iphones / ipads เนื่องจากดูเหมือนว่าจะให้การเรนเดอร์ที่เร็วที่สุดและการแสดงผลที่สะอาดที่สุด Canvas ดูเหมือนจะเป็นตัวเลือกที่ดีที่สุดอันดับสอง แต่ใช้เวลานานมากถ้าคุณมีรูปหลายเหลี่ยมหลายร้อยรูปที่แสดงบนแผนที่ในขณะที่ SVG ใช้เวลาในการเรนเดอร์นานกว่า

ฉันเกือบหมดหวังในการหาวิธีแก้ไขปัญหานี้แต่วันนี้ฉันเจอ บริษัท ที่ชื่อว่า GISCloud http://www.giscloud.com (ปัจจุบันอยู่ในรุ่นเบต้าพร้อมสมัครฟรี)

บริษัท นี้มี SOMEHOW สามารถหาวิธีที่น่าทึ่งในการแสดงเวกเตอร์นับร้อยบนแผนที่ในเวลาจริง ฉันรู้สึกประหลาดใจกับวิธีการของพวกเขาและคำถามของฉันเกี่ยวกับชุมชนเกี่ยวข้องกับวิธีที่เราสามารถทำซ้ำวิธีการของพวกเขาสำหรับใช้กับเทคโนโลยีที่มีอยู่เช่นแผ่นพับ openlayers ขี้ผึ้ง ...

ลองดูด้วยตัวคุณเองโดยดูการสาธิตที่น่าทึ่งนี้: http://www.giscloud.com/map/284/africa

ตรวจสอบให้แน่ใจว่าคุณวางเมาส์เหนือรูปหลายเหลี่ยมบนหน้าและทดสอบการควบคุมการซูมเพื่อดูว่ารูปหลายเหลี่ยมเหล่านี้เป็นเวกเตอร์แน่นอน

สิ่งที่ฉันสังเกตเห็นจากการดูคำขอด้วย firebug คือแผนที่กำลังร้องขอไฟล์ json เฉพาะ ดูเหมือนว่าขึ้นอยู่กับระดับการซูม / พื้นที่ที่มีไฟล์ json จำนวนมากที่ถูกร้องขอ

ฉันควรพูดถึงที่นี่ว่าเมื่อ giscloud โหลดข้อมูลบนหน้าเว็บที่โฮเวอร์เหนือเวกเตอร์จะเปลี่ยนสีทันทีโดยไม่ต้องสร้างคำขอใหม่

ตัวอย่าง:

• 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

ฉันกำลังสมมติว่าโครงสร้าง url เป็นไปตามตรรกะการเรียงต่อกันบริการมาตรฐาน (ตัวอย่างเช่นโฟลเดอร์ที่ 3 ถึงโฟลเดอร์สุดท้ายคือระดับการย่อ / ขยาย ... )

ไม่ว่าในกรณีใดฉันได้วิเคราะห์ข้อมูลจริงของไฟล์ json เหล่านี้และดูเหมือนว่าตรรกะที่พวกเขากำลังใช้อยู่มีตรรกะบางประเภทที่พวกเขาสร้างเวกเตอร์ของพวกเขาโดยใช้ค่าข้อมูลเหล่านี้:

• width / height:พวกเขากำหนดความกว้างและความสูงของข้อมูลที่ให้บริการในการร้องขอ json แต่ละ
• พิกเซล:ที่นี่พวกเขากำหนดค่าพิกเซลที่ฉันสมมติว่าเกี่ยวข้องกับพิกัดพิกเซล x / y ทั่วไปสำหรับระดับจุดทั่วไป? ฉันเดาว่าพวกเขามีวิธีทำให้ภูมิภาคง่ายขึ้นโดยอัตโนมัติตามระดับการซูม ฉันสันนิษฐานว่าพวกเขาใช้พิกัดพิกเซลฉันเดาว่าพวกเขากำลังลดขนาดของข้อมูลที่ต้องโหลดเทียบกับ lat / long data อย่างมาก
• สไตล์:ที่นี่พวกเขากำหนดสองค่า RGB css "F" แทนสีไฟล์รูปหลายเหลี่ยมและ "S" แทนสีเส้นขอบรูปหลายเหลี่ยม
• geom:นี่คือที่ฉันคาดเดาว่าพวกเขากำลังกำหนดเฉพาะรูปหลายเหลี่ยมแต่ละภายในกระเบื้องที่กำลังโหลดที่ข้อมูลดังกล่าวจะถูกกำหนดตามหน้าต่างภาชนะแผนที่ มีอะไรน่าสนใจอีกอย่างคือแต่ละรายการมีค่า "S" ซึ่งฉันถือว่าใช้เป็นแอตทริบิวต์หรือตัวเลือกลิงก์ค่าคุณลักษณะและในตอนท้ายของแต่ละรายการที่นี่จะมีพื้นที่ซึ่งดูเหมือนจะกำหนดรหัสเฉพาะต่อเวกเตอร์พร้อมกับ ID ของเลเยอร์ที่ฉันคาดเดาถูกนำมาใช้เพื่อเข้าร่วมข้อมูลจากการร้องขอไทล์ json แต่ละครั้งที่ถูกเรียก

ฉันยังสมมติว่าพวกเขาได้หาวิธีในการกำหนดและแยกข้อมูลที่จำเป็นต้องโหลดสำหรับแต่ละไทล์โดยขึ้นอยู่กับขนาดของข้อมูลที่จะต้องโหลดสำหรับไทล์ที่ร้องขอโดยอัตโนมัติ

นี่คือการแยกย่อยของหนึ่งในคำขอเหล่านี้:

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

เราจะทำซ้ำความเร็วประเภทเดียวกัน (หรือคล้ายกัน) โดยใช้ postgis (ซึ่งฉันใช้กับสิ่งที่พวกเขาใช้)?

ฉันเคยเห็นเทคนิคนี้ใช้ในอดีต มันอธิบายให้ฉันโดย Zain Memon (จาก Trulia) ผู้ช่วยให้ความเห็นเมื่อ Michal Migurski กำลังสร้าง TileStache Zain เดินไปได้ในขณะที่การอธิบายสาธิต Trulia ของเขาที่ใช้เทคนิคนี้ที่หนึ่งของรุ่นเก่าของเราประชุม SF GeoMeetup บางเวลากลับ อันที่จริง, ถ้าคุณอยู่ใน SF สัปดาห์หน้า (นี่เป็นความพยายามที่อ่อนแอของฉันที่ปลั๊ก, เขาจะแตะบนสิ่งนี้ , ดังนั้นอย่าลังเลที่จะแสดง :)

ตกลงตอนนี้คำอธิบาย

ก่อนอื่นคุณมองผิดที่เล็กน้อยเมื่อดูไฟล์ json ด้านบน

ให้ฉันอธิบาย (สั้นที่สุด) ทำไม

กระเบื้องถูกส่งผ่านเช่นเดียวกับการแสดงผลปกติไม่มีเรื่องใหญ่เรารู้วิธีการทำเช่นนั้นและดังนั้นฉันไม่จำเป็นต้องอธิบาย

หากคุณตรวจสอบได้ใน Firebug คุณจะเห็นว่าคุณยังได้รับทั้งกลุ่มของภาพที่ดูเหมือนจะเป็นที่ว่างเปล่าเช่นนี้

ทำไมมันว่างเปล่า มันไม่ใช่. พิกเซลมีข้อมูล - ไม่ใช่ข้อมูลภาพแบบดั้งเดิมที่มองเห็นได้ พวกเขาใช้เทคนิคที่ฉลาดมากในการส่งผ่านข้อมูลที่เข้ารหัสในพิกเซลตัวเอง

สิ่งที่เกิดขึ้นในทศวรรษที่ผ่านมาคือผู้คนซื้อขายแลกเปลี่ยนข้อมูลความสามารถในการอ่านและการพกพาของรูปแบบโดยเสียค่าใช้จ่ายอย่างมีประสิทธิภาพ

นำตัวอย่างข้อมูล 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>

ตกลงมีจำนวนเท่าใดในการถ่ายโอนนี้ โดยมีเงื่อนไขว่าเราเป็น utf8 (1 ไบต์ต่อตัวละครเมื่อจัดการกับเนื้อหานี้) ทีนี้เรามี 176 chars (ไม่นับแท็บหรือเว้นวรรค) ซึ่งทำให้176 bytes (นี่คือแง่ดีด้วยเหตุผลต่าง ๆ ที่ฉันจะละเว้นเพราะความเรียบง่าย) ใจคุณนี่คือ 2 คะแนน!

ถึงกระนั้นสมาร์ทบางตัวที่ไม่เข้าใจสิ่งที่เขาพูดถึงจะอ้างว่า "json ให้แรงอัดที่มากกว่า"

เอาล่ะสมมุติว่า xml ไร้สาระเหมือน json:

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

ที่นี่มีกี่ไบต์? พูดประมาณ 115 ตัวอักษร ฉันก็โกงนิดหน่อยและทำให้มันเล็กลง

สมมติว่าพื้นที่ของฉันครอบคลุม 256x256 พิกเซลและฉันอยู่ที่ระดับการซูมสูงมากเพื่อให้แต่ละคุณสมบัติแสดงผลเป็นหนึ่งพิกเซลและฉันมีคุณสมบัติมากมายจนเต็ม ฉันต้องใช้ข้อมูลมากแค่ไหนในการแสดงฟีเจอร์ 65,536 นั้น

54 ตัวอักษร (หรือ UTF ไบต์ - และฉันยังไม่สนใจสิ่งอื่น ๆ ) ต่อรายการ "คุณสมบัติ" คูณ x 65,536 = 3,538,944 หรือประมาณ 3.3MB

ฉันคิดว่าคุณได้รับภาพ

แต่นี่คือวิธีที่เราขนส่งข้อมูลในสถาปัตยกรรมที่มุ่งเน้นบริการ อึป่องที่อ่านได้

ถ้าฉันต้องการขนส่งทุกอย่างในระบบเลขฐานสองที่ฉันคิดค้นเองล่ะ พูดอย่างนั้นแทนฉันเข้ารหัสข้อมูลนั้นในรูปวงเดี่ยว (เช่นขาวดำ) และฉันตัดสินใจว่า 0 หมายถึงขายและ 1 หมายความว่าใช้ได้และ 2 หมายถึงฉันไม่รู้ Heck ใน 1 ไบต์ฉันมี 256 ตัวเลือกที่ฉันสามารถใช้ได้ - และฉันใช้ 2 หรือสามตัวเท่านั้นสำหรับตัวอย่างนี้

ค่าใช้จ่ายในการจัดเก็บของที่คืออะไร? 256x256x 1 (หนึ่งวงเท่านั้น) 65,536 ไบต์หรือ 0.06MB และนี่ก็ไม่ได้คำนึงถึงเทคนิคการบีบอัดอื่น ๆ ที่ฉันได้รับฟรีจากการวิจัยหลายทศวรรษในการบีบอัดภาพ

ณ จุดนี้คุณควรถามตัวเองว่าทำไมผู้คนไม่เพียงแค่ส่งข้อมูลที่เข้ารหัสในรูปแบบไบนารี่แทนการทำให้เป็นอนุกรมกับ json ก่อนอื่นปรากฎว่าจาวาสคริปต์ใช้เวลาในการขนส่งข้อมูลไบนารี่เป็นอย่างมากดังนั้นนี่คือสาเหตุที่ผู้คนไม่ได้ทำสิ่งนี้มาก่อน

เป็นงานที่น่ากลัวไปรอบ ๆ ได้ถูกใช้โดยคนบางคนเมื่อคุณสมบัติใหม่ของHTML5 ออกมาโดยเฉพาะอย่างยิ่งผ้าใบ แล้วการทำงานที่ยอดเยี่ยมนี้คืออะไร ปรากฎว่าคุณสามารถส่งข้อมูลผ่านสายที่เข้ารหัสในสิ่งที่ดูเหมือนเป็นภาพจากนั้นคุณสามารถดันภาพนั้นเป็นผ้าใบ HTML5 ซึ่งช่วยให้คุณสามารถจัดการพิกเซลได้โดยตรง ! ตอนนี้คุณมีวิธีที่จะคว้าข้อมูลนั้นถอดรหัสมันในฝั่งไคลเอ็นต์และสร้างวัตถุ json ในไคลเอนต์

หยุดสักครู่แล้วคิดเกี่ยวกับสิ่งนี้

คุณมีวิธีการเข้ารหัสข้อมูลอ้างอิงทางภูมิศาสตร์ที่มีความหมายจำนวนมากในรูปแบบที่มีการบีบอัดสูงลำดับของขนาดที่เล็กกว่าสิ่งอื่นใดที่ทำแบบดั้งเดิมในเว็บแอปพลิเคชันและจัดการกับมันใน javascript

ผืนผ้าใบ HTML ไม่จำเป็นต้องใช้ในการวาดมันใช้เป็นกลไกการถอดรหัสแบบไบนารีเท่านั้น!

นั่นคือภาพทั้งหมดที่คุณเห็นใน Firebug เกี่ยวกับ หนึ่งภาพที่มีการเข้ารหัสข้อมูลสำหรับไทล์ทุกไฟล์ที่ดาวน์โหลด มันเล็กมาก แต่มีข้อมูลที่มีความหมาย

ดังนั้นคุณจะเข้ารหัสสิ่งเหล่านี้ในฝั่งเซิร์ฟเวอร์ได้อย่างไร คุณจำเป็นต้องทำให้ข้อมูลทั่วไปในฝั่งเซิร์ฟเวอร์และสร้างไทล์ที่มีความหมายสำหรับทุกระดับการซูมที่มีการเข้ารหัสข้อมูล ในปัจจุบันการทำเช่นนี้คุณต้องทำของคุณเอง - ไม่มีวิธีการแก้ปัญหาโอเพนซอร์ซโอเพนซอร์ส แต่คุณมีเครื่องมือทั้งหมดที่คุณต้องใช้ในการทำสิ่งนี้ PostGIS จะทำการวางแนวทั่วไปผ่าน GEOS TileCache สามารถใช้เพื่อแคชและช่วยให้คุณเริ่มการสร้างไทล์ ในฝั่งไคลเอ็นต์คุณจะต้องใช้ HTML5 Canvas เพื่อส่งผ่าน "ไทล์ปลอม" พิเศษจากนั้นคุณสามารถใช้ OpenLayers เพื่อสร้างออบเจ็กต์จาวาสคริปต์ที่ฝั่งไคลเอ็นต์จริง ๆ

หากคุณต้องการเข้ารหัสข้อมูลเพิ่มเติมโปรดจำไว้ว่าคุณสามารถสร้างภาพ RGBA ต่อพิกเซลได้ตลอดเวลา (ซึ่งให้ 4 ไบต์ต่อพิกเซลหรือ 4,294,967,296 หมายเลขที่คุณสามารถแสดงต่อพิกเซลได้ ) ฉันคิดหลายวิธีที่จะใช้มัน :)

อัปเดต : ตอบคำถาม QGIS ด้านล่าง

QGIS เหมือนกับDesktop GISอื่น ๆ ส่วนใหญ่ไม่มีระดับการซูมคงที่ พวกเขามีความยืดหยุ่นในการซูมในทุกขนาดและเพียงแค่แสดงผล พวกเขาสามารถแสดงข้อมูลจาก WMS หรือแหล่งที่มาของไทล์ได้หรือไม่ แน่นอนว่าพวกเขาสามารถทำได้ แต่ส่วนใหญ่แล้วพวกเขาจะเป็นใบ้เกี่ยวกับเรื่องนี้: ซูมในระดับที่แตกต่างกันคำนวณกล่องขอบเขตคำนวณกระเบื้องที่ต้องการจับพวกเขาแสดง เวลาส่วนใหญ่ที่พวกเขาเพิกเฉยสิ่งอื่น ๆ เช่นแคชส่วนหัว http ที่จะทำให้มันเพื่อให้พวกเขาไม่ต้องเรียก บางครั้งพวกเขาใช้กลไกแคชอย่างง่าย (เก็บไทล์หากคุณขอให้ตรวจสอบไทล์อย่าถามมัน) แต่นี่ยังไม่เพียงพอ

ด้วยเทคนิคนี้กระเบื้องและเวกเตอร์จะต้องมีการ refetched ที่ระดับการซูมทุก ทำไม? เนื่องจากเวคเตอร์ได้รับการวางนัยทั่วไปเพื่อรองรับระดับการซูม

เท่าที่เคล็ดลับทั้งหมดของการวางไทล์ลงบนผืนผ้าใบ HTML5 เพื่อให้คุณสามารถเข้าถึงบัฟเฟอร์สิ่งทั้งหมดนั้นไม่จำเป็น QGIS อนุญาตให้คุณเขียนโค้ดใน Python และ C ++ ทั้งสองภาษามีการสนับสนุนที่ยอดเยี่ยมสำหรับการจัดการกับบัฟเฟอร์แบบไบนารีดังนั้นการทำงานนี้ไม่เกี่ยวข้องกับแพลตฟอร์มนี้จริงๆ

* อัพเดท 2 **:

มีคำถามเกี่ยวกับวิธีการสร้างแผ่นกระเบื้องแบบเวกเตอร์ทั่วไปในตอนแรก (ขั้นตอนเด็ก 1 ก่อนที่จะสามารถทำให้ผลลัพธ์เป็นภาพเป็นลำดับ) บางทีฉันก็ไม่ได้ชี้แจงเพียงพอ Tilestache จะช่วยให้คุณสร้าง "ไทล์เวกเตอร์" ที่มีประสิทธิภาพของข้อมูลของคุณในทุกระดับการซูม (แม้จะมีตัวเลือกที่ช่วยให้คุณสามารถคลิปหรือไม่คลิปข้อมูลเมื่อมันผ่านขอบเขตกระเบื้อง) วิธีนี้จะช่วยแยกเวกเตอร์ออกเป็นแผ่นกระเบื้องที่ระดับการซูมต่างๆ ฉันจะเลือกตัวเลือก "ไม่ใช่คลิป" (แต่จะเลือกไทล์แบบสุ่มที่ครอบคลุมพื้นที่มากขึ้น) จากนั้นคุณสามารถป้อนทุกเวกเตอร์ผ่านตัวเลือกทั่วไปของ GEOS โดยทั่วไปแล้วในความเป็นจริงคุณต้องการให้มันใหญ่พอที่ polylines และรูปหลายเหลี่ยมยุบตัวเองเพราะถ้าพวกมันทำคุณสามารถลบมันออกจากระดับการซูมได้ ที่ไม่เกี่ยวข้อง Tilestache ยังช่วยให้คุณเขียนผู้ให้บริการข้อมูล pythonic ที่คุณสามารถใส่ตรรกะนี้ได้ ในขั้นตอนนั้นคุณสามารถเลือกที่จะให้บริการพวกเขาเป็นไฟล์ json (เช่นที่พวกเขาทำกับตัวอย่างแผนที่แอฟริกาบางส่วน) หรือเป็นรูปทรงเรขาคณิตต่อเนื่องใน pngs เช่นที่พวกเขาทำในตัวอย่างอื่น ๆ (หรือหนึ่ง Trulia) ที่ฉันให้ไว้ข้างต้น

ส่งตรงจากนักพัฒนา Dino Ravnic บนโพสต์จดหมายข่าวล่าสุด:

ไม่ใช่ความลับที่ยิ่งใหญ่ที่เราทำดังนั้นฉันจึงยินดีที่จะแบ่งปันสิ่งนี้กับคุณ .. กุญแจสำคัญในสองสิ่ง:

1. การลบเวกเตอร์ทั้งหมดที่มีขนาดเล็กให้มองเห็นได้คือพื้นที่ของพวกมันเมื่อคำนวณเป็นพิกเซลจะน้อยกว่า 1px ดังนั้นเราจึงวางเวกเตอร์ดังกล่าวและแทนที่จะวางพิกเซลดังนั้นจึงมีคุณสมบัติ "พิกเซล" ในไทล์ json ของเรา

2. เวกเตอร์ซึ่งจะมองเห็นได้จริงกำลังถูกวางนัยทั่วไปแล้วเขียนลงในไทล์ที่มีพิกัดเป็นพิกเซล

ในส่วนของลูกค้าเราแสดงผลบนพิกเซลแบบคงที่และเวกเตอร์ที่มองเห็นได้ ด้านบนของเวกเตอร์เราใช้การจัดการเหตุการณ์เมาส์เพื่อให้เกิดการโฉบเช่นการโต้ตอบ และนั่นคือมัน

เอ็นจิ้นแผนที่แบ็กเอนด์ของเราทำหน้าที่ยกของหนักเพราะเราไม่ได้ใช้ precaching ใด ๆ และไทล์ทั้งหมดจะถูกสร้างขึ้นทันที มันสำคัญมากที่เราจะต้องมีแผนที่ที่สามารถรีเฟรชได้อย่างรวดเร็ว

ดูเหมือนว่าฝั่งไคลเอ็นต์จะเป็นส่วนที่ง่าย เป็นที่น่าประทับใจว่าข้อมูลจะถูกแสดงผลโดยไม่มีการแคชใด ๆ

เขายังกล่าวถึงบริการโฮสติ้งที่คุณอาจสนใจ คุณอาจต้องการชั่งน้ำหนักค่าใช้จ่ายในการพยายามสร้างสิ่งนี้ใหม่ด้วยต้นทุนการใช้บริการสำเร็จรูป

ดังที่ฉันได้อธิบายไว้ในรายการ OSGeo ที่สำคัญคือการส่งมอบข้อมูลเป็นไทล์ JSON แบบเวกเตอร์ที่มีพิกเซลสำหรับเรขาคณิตย่อยพิกเซลและเรขาคณิตทั่วไปสำหรับคุณสมบัติเหล่านั้นที่จะมองเห็นได้จริงในระดับหนึ่ง ประสิทธิภาพดีมากเนื่องจากเทคนิคนี้กำจัดข้อมูลเวกเตอร์ที่ไม่จำเป็นทั้งหมดและปล่อยเฉพาะเวกเตอร์เหล่านั้นที่จะส่งผลกระทบต่อภาพในแผนที่ พิกเซลอยู่ที่นั่นเพื่อเติมเต็มช่องว่างและวางแทนเวกเตอร์พิกเซลย่อยเหล่านั้น นั่นคือเกี่ยวกับรูปแบบไทล์

ด้านแบ็คเอนด์คือการยกของหนักอย่างแท้จริง เราไม่ได้ใช้ TileStache หรือเอ็นจิ้นแผนที่อื่น ๆ เนื่องจากเราเขียนของเราเองที่สามารถสร้างกราฟิกเวกเตอร์ดังกล่าวในแบบเรียลไทม์

ก่อนอื่นเราเริ่มต้นด้วยการส่งแผ่นแผนที่เป็น SWF และเมื่อเร็ว ๆ นี้เราเพิ่งเปิดใช้งานการส่งออกไปยัง JSON เพื่อให้เราสามารถใช้ HTML5 Canvas เพื่อแสดงกราฟิก คุณสามารถดูด้านล่างมาตรฐานเปรียบเทียบเทคโนโลยีเวกเตอร์ชนิดนี้กับเทคโนโลยีแรสเตอร์ (mapnik) สำหรับการเปรียบเทียบอย่างยุติธรรมเพียงมองหาผลลัพธ์ในโหมด CGI

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

เราวางแผนที่จะให้บริการเทคโนโลยีนี้เป็นบริการโฮสต์แผนที่ย่อย แนวคิดคือการโฮสต์ข้อมูลทางภูมิศาสตร์ของคุณบนคลาวด์และผ่าน HTML5 ให้ส่งไปยังไคลเอนต์แผนที่ใด ๆ ด้วยความเร็วสูงโดยไม่จำเป็นต้องทำการปูกระเบื้องล่วงหน้า หากคุณสนใจที่จะเข้าร่วมเบต้านี้โปรดติดต่อเราที่นี่: http://www.giscloud.com/contact/

ดูเหมือนว่าคำถามที่คล้ายกันนี้ถูกถามเมื่อไม่นานมานี้ในฟอรัม OSGeo Open Layersโดยผู้พัฒนา GIS Cloud อธิบายวิธีการของพวกเขาซึ่งเป็นการผสมผสานที่น่าสนใจของ GeoJSON geometries และพิกเซลคงที่ พวกเขาสร้างกระเบื้องเวกเตอร์ทั้งหมดได้ทันทีแทนที่จะใช้แคชที่สร้างไว้ล่วงหน้าของไฟล์ GeoJSON

Esri ได้ใช้วิธีการที่คล้ายกันโดยใช้ArcGIS Server และ Feature Layersซึ่งสามารถสรุปรูปทรงเรขาคณิตได้ทันทีและส่งผ่านสายเป็น JSON

สำหรับวิธีการตรงไปข้างหน้าจริงที่คุณสามารถใช้ในขณะนี้คุณสามารถสร้างกระเบื้องเวกเตอร์กับTilestache (ซึ่งมีการสนับสนุน PostGIS ) และใช้พวกเขาในPolymaps Polymaps ใช้ SVG แต่ประสิทธิภาพค่อนข้างดีและ CSS ใช้กฎในการจัดองค์ประกอบของแผนที่เพื่อให้คุณสมบัติการแสดงผลขึ้นอยู่กับคุณทั้งหมด นี่คือการโพสต์บล็อกที่ทำงานผ่านสิ่งที่คล้ายกับสิ่งที่คุณถาม

ฉันได้เล่นกับ OpenLayers โดยใช้ Canvas และได้ผลลัพธ์ที่สมเหตุสมผล

ดังที่ได้กล่าวไว้ในคำตอบอื่น ๆ : การส่งมอบและแสดงเวกเตอร์ได้ทันที - พวกเขาจำเป็นต้องวางหลักเกณฑ์สำหรับแต่ละระดับการซูมและแต่ละชุดข้อมูล นอกจากนี้คุณสามารถใช้การเข้ารหัส polyline ของ Google เพื่อลดขนาดลงได้อย่างมาก

ฉันใช้กลไกการส่งที่เรียบง่าย แต่ละรูปทรงเรขาคณิตเป็นฟังก์ชัน JavaScript ภายในการตอบกลับ JavaScript HTTP ไม่สูงเท่ากับการส่งเวกเตอร์แบบเรียงต่อกัน แต่ง่ายและโอเพ่นซอร์ส!

ฉันไม่ได้ลองใช้ Google Maps v3 ด้วย Canvas แต่ได้เห็นการสาธิตของNew York Timesสองสามรายการ ที่สร้างความประทับใจ

ฉันไม่ทราบว่า บริษัท นี้ใช้โซลูชันใด (คุณอาจถามพวกเขาโดยตรง) แต่ฉันมีความคิด

ทางออกที่สำคัญในการปรับปรุงการถ่ายโอนเครือข่ายและการเรนเดอร์ความเร็วของข้อมูลเวคเตอร์คือการทำให้เป็นไปตามระดับการซูม: การถ่ายโอนและเรนเดอร์ที่ระดับการซูมสูงพันวัตถุที่ออกแบบมาสำหรับการซูมระดับต่ำ ไร้ประโยชน์เนื่องจากการแสดงผลขั้นสุดท้ายมักไม่ชัดเจน - ดูตัวอย่างภาพนี้ ) ในการปรับใช้นั้นฐานข้อมูลเซิร์ฟเวอร์ postgis ของคุณต้องมีหลายขนาด : สำหรับแต่ละระดับการซูมควรมีการแสดงวัตถุที่เหมาะสมสำหรับระดับการซูมนี้ การแทนค่าที่ต่างกันเหล่านี้สามารถคำนวณได้โดยอัตโนมัติโดยใช้เทคนิคการวางนัยทั่วไป. นอกจากนี้ข้อมูลเวกเตอร์ที่ส่งโดยเซิร์ฟเวอร์ไปยังไคลเอนต์ไม่ควรขึ้นอยู่กับการขยายพื้นที่ แต่รวมถึงระดับการซูม: เซิร์ฟเวอร์จะส่งข้อมูลที่เหมาะสมขึ้นอยู่กับระดับการซูม นี่คือวิธีการที่ได้รับการปกป้องในบทความที่ยอดเยี่ยมนี้ :-)

มีกระดาษที่น่าสนใจตัวอย่างและซอร์สโค้ดของซอฟต์แวร์ที่พัฒนาโดย Stanford Visualization Group ที่ใช้ดาต้าเบสสำหรับแต่ละไทล์เพื่อที่จะเห็นภาพและสำรวจชุดข้อมูลทางภูมิศาสตร์ขนาดใหญ่ มันสามารถใช้สำหรับชุดข้อมูลแบบจุดเท่านั้น แต่อาจเป็นวิธีที่น่าสนใจ

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

ความคลั่งไคล้กับแพลตฟอร์ม CartoDB ของพวกเขาและห้องสมุดที่ชื่อว่า Torque กำลังทดลองด้วยวิธีการดึงข้อมูลปริมาณสูง

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