數據量：
鑑於你想要的0.1米分辨率，這意味着你需要能夠放大，直到像素代表小到0.1×0.1微米。
由於您希望在觀看區域爲100 x 100 m時使用該分辨率，這意味着該區域將至少表示1000 x 1000像素。這是您的視口的最小尺寸。
在此分辨率下，縮放級別和視圖端口大小，50 x 100 m的矩形將包含不是50k，但是500k點。
如果你要每一點單獨編碼，你需要記憶，如：
- 比方說，你的「價值」 1個字節。
- 緯度值：地球圓周/分辨率= 2 * Pi * 6378137 m/0.1 m =一圈內有大約400百萬個不同的值（假設地球是一個球體），即十進制度數到小數點後第七位。所以一個形式爲「DDD.ddddddd」的數字，即12個字節。
- 經度：假設與簡化的緯度相同，即12個字節。
- 每個點總共1 + 12 + 12 = 25個字節，即25×500k = 12.5 MB未壓縮，僅用於100×100m的1個可視區域。
總在整個地圖：
如果你縮小時不降低分辨率，就需要50000米/ 0.1 M = 500k的像素側的一個單一的「圖像」。它將包含一個50m * 50,000m /（0.1m）2 = 250百萬點數據的矩形。
每更新
數據：
250更新的分*每點25個字節=每更新6.25 KB。
數據傳輸：
既然你說你正在開發一個web應用程序，你就必須通過網絡爲每個地圖視圖來傳輸數據（12.5 MB）的量......不是真正的實時友善。即使很明顯，在每次更新時都不必刷新所有這些要點，但您仍然需要這一數量來進行初始顯示和導航。
此數據傳輸問題的常用解決方法是在服務器端創建熱圖：服務器不是單獨編碼每個數據點（這使得需要指定每個點的地理座標），而是創建一個圖像。
另一個（以及某種程度上類似的）解決方案可以是UTFGrid。您可以直接訪問每個「像素」（實際上是4x4像素的正方形）的數據，而不是基本圖像，以便實現更多的交互性（explanations on Mapbox website）。
數據顯示：
當你發現，每個點的顯示單獨的不可擴展在所有與你的數據量。
如果您在服務器上實現將熱圖創建爲圖像，那麼您將基本上找到一個解決方案來瀏覽它（縮放，平移）。網上應該有很多解決方案來完成這項工作（如OpenSeadragon）。
但是，考慮到整個地圖的大小（至少500k x 500k像素），您肯定需要一種方法來降低服務器和客戶端的分辨率，以避免必須管理整個250萬個點的數據集。
因此，您需要服務器和客戶端根據縮放級別來管理不同的數據（熱圖的圖像）。平鋪也會有很大的幫助。 OpenSeadragon和Leaflet應該能夠管理它。
數據更新：
在50毫秒刷新間隔（即由路很短，但對於您的更新量，這仍然可能是可控的），你需要的帶寬：
如果您單獨編碼每個數據點，則每更新6.25 kB/50 ms = 125 kB/s，即1 Mbit/s（未壓縮）。
如果您的250條更新遍佈整個地圖，您最好找到一種方法來僅傳輸當前客戶端視圖端口中的更新。對於顯示此新數據，您可以遠離創建單個DOM元素，方法是在熱圖上繪製畫布。
Leaflet can manage a tiled canvas就好像它是一個正常的瓦片層。您需要implement yourself畫布瓷磚的創建和更新。
您可能也有興趣Leaflet Realtime plugin。
最後，您可能會發現更合適的Leaflet plugins來實現實時熱圖。
祝你好運！
關於DOM的管理，您可以查看React.js以儘量減少DOM調用並更好地管理渲染。 –