WebGIS應用需要和空間應用服務器進行大量交互，簡單的如漫遊、查詢、搜索，複雜的有地理編碼、路徑計算、空間分析，在發佈面向企業的地圖服務時，多臺空間應用服務器做負載均衡是家常便飯，更不用說面向公衆的地圖服務。三四年前大家配置好服務器後，能在客戶端看到地圖顯示，做一些基本查詢就覺得非常新鮮了，沒有過多去關心用戶體驗，後來爲了適應大量用戶訪問的需要，WebGIS開始應用多級緩存技術，其中切片或瓦片就是其中關鍵技術之一，簡單易用，同時Ajax的出現被立即證明它和WebGIS是不可分割的，所有WebGIS基本功能都可以基於Ajax方式去實現，緩存技術和Ajax在減輕空間應用服務器負載的同時大大改善了原有的用戶體驗，成爲支撐現在WebGIS的經典技術（Ajax暫且也稱爲技術吧）。
Ajax和WebGIS頗有淵源的，兩者幾乎是在同一時期開始流行，2006年我參與的一個項目就用Ajax異步調用的方法實現地理查詢和動態顯示，當時還沒有多少項目使用prototype，更不用提mootools、jquery了，全部手工去寫，現在大家看來都非常easy，那時確實給客戶留下了深刻印象。現在小結一些基本Ajax+WebGIS應用模式：
1.地圖漫遊。放大、縮小、全圖、移動，曾經這些基本操作可是要刷新整個頁面的，等待地圖加載時彈出一個GIF進度條，現在大家已經習慣了Ajax帶來的體驗，包括執行每個操作時漸變平滑的效果
2.Identity查詢。鼠標點擊地圖，和指定圖層地理要素進行Intersect查詢，查詢結果以div形式異步彈出，顯示要素的基本信息，並給出詳細信息鏈接。
3.搜索。在文本框中輸入搜索條件，然後在地圖上顯示查詢結果的位置並高亮顯示。
4.根據屬性記錄定位地理要素。在浮動列表中顯示一系列屬性記錄，鼠標移動到列表中某一記錄時，地圖動態居中顯示該記錄的地理位置，並高亮顯示。
5.鷹眼。鷹眼和地圖之間的平滑聯動效果。
6.放大鏡。不至於執行一次放大鏡操作刷新全圖吧，移動放大鏡框和按照指定倍數放大地圖理所當然應該通過Ajax實現。
7.距離面積量算。動態在地圖上繪製出量算範圍，並計算結果。
8.地理編碼。Geocoding和Reverse Geocoding，在地圖上異步顯示查詢結果，如座標位置或具體地址。
9.路徑計算。路徑計算目前有兩種實現方式，一種是查詢之後刷新整個Map，並返回文字描述信息，一種是查詢之後不刷新Map，直接返回文字描述信息。
10.空間分析。空間分析是一個綜合名詞，緩衝區分析、疊加分析、服務區分析都可以認爲是空間分析，空間分析計算量一般相對較大，Ajax異步顯示分析結果理所當然。
11.其他。不一一列舉了。
確實，簡單的幾個技術組合將WebGIS向前推進了一大步，直接提升了客戶對WebGIS應用的認識和要求，在經過新鮮感的過渡期之後，越來越多的客戶需要將WebGIS和具體業務緊密結合在一起，最典型的應用之一是在WebGIS基礎去查詢或管理業務POI。過去，咱們都是在體驗Ajax帶給WebGIS的便捷，現在開始出現困惑了，例如WebGIS查詢，當查詢POI結果有幾千到幾萬時，就會出現性能問題，客戶端要異步刷新顯示成千上萬個POI點，會對客戶端會造成較大的壓力，如果還要基於這些點進行分級渲染，壓力就更大了，有時在稍微年長一點的電腦上根本無法完成。抽稀是一種解決方法，以網狀結點去代表每個比例尺級別周圍臨近的POI點，但這種方法不能適用於所有情況，有的應用非常關心POI點所在的位置有沒有超出規定界限，這時抽稀反而帶來了顯示結果的不準確性。
對於這個問題曾想過很多辦法，最後發現自己陷入了固定思維的泥潭，Ajax和WebGIS是天生一對，但在這種模式下，用傳統地圖請求響應模式比Ajax有效，一萬個點在服務器端生成好後，以圖片形式傳給客戶端，網絡傳輸加上客戶端的壓力和對十個點查詢的壓力基本相同，壓力拋給服務器去處理，看來WebGIS也有不適應Ajax的時候。綜合考慮，當請求不多時可以考慮這種模式，當請求量很大時，服務器壓力會大大增加，也不是一種萬能的方法，不知道有沒有更好的技術方案？
現在WebGIS Flex客戶端已經開始流行，WebGIS在Flex中同樣是基於異步的調用，一萬個點仍然是可望不可及的事情，除非提升客戶端電腦的配置，如果從開發技術上去實現有沒有更好的方法？